Flows - enhancing-automated-valet-parking/ai-parking-cloud GitHub Wiki

Introduction

This document provides a walkthrough through different use cases identified by the EAVP platform team. It follows the flow of the Customer Journey and provides request and response examples based on the underlying APDS API. Visit this API specification to find additional details on the engaged model classes and their attributes.

The document is currently work in progress. Updates to it are possible (and likely) as the workgroup continues.

Inventory Information Server (Parking Aggregator / Operator)

This is a system holding inventory information about connected parking locations.
The information is stored in an APDS conformant hierarchy.

Example: an airport has two car parks, one capable of AVP and another one (regular car park with no additional services)

Any system acting as a user/client towards the inventory server can read this hierarchy information and e.g. store it locally (and refresh it sporadically).

Use Case 1: Manual Parking

This is the basic use case where a traditional vehicle is being used. An overview of the identified use cases can be found here. In this section, we'll look at the following steps of this use case:

  • Before and while driving
    • Where is the parking facility?
    • How much does it cost?
    • Selection of a parking facility
    • Activation of in-vehicle navigation to entry
  • Arriving/Entry
    • Open barrier
    • start parking transaction
  • Where is the spot?
    • Occupancy information about area
    • Occupancy information about spot
  • Navigation to spot
    • Guiding of customer within garage and 3D navigation map to free slot
  • Park in/out
    • Manual park in/out
    • In slot or manual relocation for charging and other value-added services
  • Charging
    • Manual plugin of cable
    • Manual selection of tariff
    • Manual start of charging service
  • Navigation to exit
    • Guiding of customer within garage and 3D navigation map from slot to exit
  • Exit
    • Open barrier
    • Stop parking transaction
  • Payment
    • Charge parking fee to customer account
    • Charge charging fee to customer account

Before and while driving: where is the parking facility?

When the GET /places request is made, certain filter criteria can be specified in the query to narrow the search result down.

Example

The user backend serving a vehicle's user frontend wants to find parking options available at a specific destination (and in its vicinity):

GET /places?expand=all&latitude=48.177624&longitude=11.556482&radius=1000
  • the expand parameter value of all indicates that the response shall include all details about the matching places
  • the latitude, longitude and radius parameters specify the destination and the acceptable radius around it

The inventory system will respond with something like this:

{
  "meta": {
    "referenceInstant": 1741612330,
    "offset": 0,
    "pageSize": 100,
    "total": 1
  },
  "data": [
    {
      "id": "carPark1Id",
      "version": 1,
      "name": [
        {
          "language": "de",
          "string": "BMW Welt Parkhaus Nordwest"
        }
      ],
      "rightSpecifications": [
        { 
          "id": "publicParkingRightSpec",
          "version": 1
        }
      ],
      "indicativePointLocation": {
        "type": "Point",
        "coordinates": [
          11.552002,
          48.1858071
        ]
      },
      "description": [
        {
          "language": "en",
          "string": "The preferred parking location for visitors to the BMW Welt"
        }
      ],
      
      "areaType": "generalParking",
      "characteristics": {
        "accessControlled": true,
        "evChargingPoints": 15,
        "openToPublic": true,
        "spacesTotal": 552,
        "structureGrade": "underGround",
        "structureType": "offStreetStructure"
      },
      "contacts": [
        {
          "organisationName": [
            {
              "language": "de",
              "string": "BMW"
            }
          ],
          "type": "operator",
          "emails": [
            {
              "address": "[email protected]",
              "typeCode": "customerService"
            }
          ]
        }
      ],
      "paymentMethods": [
        {
          "paymentMode": [
            "payAfterExit", "payAndExit"
          ]
        }
      ],
      "placeStreetAddress": {
        "postCode": "80809",
        "city": [
          {
            "language": "de",
            "string": "München"
          },
          {
            "language": "en",
            "string": "Munich"
          }
        ],
        "countryCode": "DE",
        "addressLines": [
          {
            "type": "street",
            "order": 0,
            "text": "Moosacher Straße 61"
          }
        ]
      }      
    }
  ]
}

The caller will then have to query the details of the referenced right specification(s). Right Specifications provide further details on constraints and eligibility criteria that apply in a certain place.

GET /rights/specs/publicParkingRightSpec?expand=all

The inventory system will provide the requested details:

{
  "id": "publicParkingRightSpec",
  "version": 1,
  "rateEligibility": [
    {
      "eligibility": [
        {
          "qualifications": [
            {
              "withReservation": true,
            } 
          ]
        }
      ],
      "rateTable": {
        "id": "publicTariffId",
        "version": 1
      },
      "hierarchyElements": [
        {
          "id": "carPark1Id",
          "version": 1
        }
      ]
    }
  ],
  "validity": {
    "validityStatus": "definedByValidityTimeSpec",
    "validityTimeSpecification": {
      "overallStartTime": "2025-01-01T00:00:00Z"
    }
  },
  "transferable": false
}

Please note that - in this first simple example - the system only returns a single parking location with just one generic right specification that applies there.

Before and while driving: how much does it cost?

Depending on the user interaction design of the user frontend, the system would now query tariff details to answer the "How much does it cost?" question (or do this later when requesting a quote in preparation of a reservation).

Example

Read the rate/tariff details. The corresponding reference can be taken from the Right Specification details.

GET /rates/publicTariffId?expand=all

{
    "id": "publicTariffId",
    "version": 1,
    "rateTableName": [
        {
            "language": "en",
            "string": "Public Parking Tariff"
        }
    ],
    "rateLineCollections": [
        {
            "applicableCurrency": "EUR",
            "collectionSequence": 0,
            "maxTime": "PT12H",
            "rateLines": [
                {
                    "sequence": 0,
                    "description": [
                        {
                            "language": "en",
                            "string": "up to 1 hour"
                        }
                    ],
                    "rateLineType": "incrementingRate",
                    "value": 10.0,
                    "incrementPeriod": "PT1H"
                },
                {
                    "sequence": 1,
                    "description": [
                        {
                            "language": "en",
                            "string": "up to 2 hours"
                        }
                    ],
                    "rateLineType": "incrementingRate",
                    "value": 10.0,
                    "incrementPeriod": "PT1H"
                },
                {
                  "sequence": 2,
                  "description": [
                    {
                      "language": "en",
                      "string": "any following hour"
                    }
                  ],
                  "rateLineType": "incrementingRate",
                  "value": 4.0,
                  "incrementPeriod": "PT1H"
                }
            ],
            "relativeTimes": true
        }
    ],
    "availability": "public",
    "rateResponsibleParty": "BMW"
}

Before and while driving: selecting a parking facility (book)

Once the driver has - based on the previously obtained inventory information - decided to use the car park at the destination, the user backend will have to

  • obtain a binding offer (APDS term: quote) and then
  • confirm this (i.e. book it)

Example: obtain a quote

When the POST /quotes QuoteRightRequest is sent, the right specification to be applied shall be referenced. The list of available right specifications was retrieved earlier during the discovery process (in our first example, it was just one).

POST /quotes

(the request body contains a so-called QuoteRightRequest)

{
  "id": "requestId",
  "version": 1,
  "periodStart": "2025-03-31T17:00:00Z",
  "periodEnd": "2025-04-02T10:00:00Z",
  "requestTime": "2025-03-10T18:32:12Z",
  "referencedRightSpecification": {
    "id": "publicParkingRightSpec",
    "version": 1
  }
}

Based on this request, the parking aggregator / the parking operator backend system will check availability of parking services in this car park during this period of time.

The backend will then respond with a corresponding QuoteRightResponse:

{
  "id": "responseId",
  "version": 1,
  "start": "2025-03-31T17:00:00Z",
  "end": "2025-04-02T10:00:00Z",
  "requestTime": "2025-03-10T18:32:12Z",
  "quoteRequestId": "requestId",
  "responseTime": "2025-03-10T18:33:02:01Z",
  "options": [
    {
      "elementId": {
        "id": "opt1",
        "version": 1
      }, 
      "exact": true,
      "quoteExpiration": "2025-03-10T22:00:00Z",
      "financialQuote": {
        "id": "finQuote1",
        "version": 1,
        "serviceProvider": {
          "id": "QPARK",
          "version": 1
        },
        "transactionId": "CONF982379278340782347",
        "value": {
          "currencyType": "EUR",
          "currencyValue": 30
        },
        "taxIncluded": true
      }
    }
  ]
}

Example: accept the quote, and make a binding booking

In our example, the requested options can be met. The user backend is informed about the availability and the associated costs for this service. The received quote remains binding until 10pm the same day.

The user backend can then confirm the booking by asking the parking backend to create a corresponding APDS assigned right.

POST /rights/assigned

The request body contains the reference to the previously obtained quote as well as identification information of the vehicle.

{
  "id": "parkingRightId",
  "version": 1,
  "rightHolder": {
    "credentials": [
      {
        "type": "licensePlate",
        "identifier": {
          "id": "MG-MM 267",
          "className": "DELicensePlate"
        }
      }
    ]
  }
  "quoteResponseId": {
    "id": "responseId",
    "version": 1
  }
}

The parking system will then have to confirm this:

{
  "code": 201,
  "status": "ok",
  "message": "booking confirmed"
}

With that, the parking service has been booked, and the car park should be awaiting the drivers arrival at the specified date and time.

Before and while driving: Activation of in-vehicle navigation to entry

This process takes place entirely under the control of the OEM and does not require joint standardisation.

Arriving/Entry: open barrier

This process takes place entirely under the control of the Parking Operator's management system and does not require joint standardisation. Obviously, the parking facility will have to be equipped with ANPR technology (or other means of identification like e.g. RFID) to recognize the vehicle and the associated booking.

Arriving/Entry: start parking transaction

In APDS, a Session is the act of making use of a previously-obtained Assigned Right (parking right). In our case, this happened during the booking process. Now that the vehicle has entered the facility, the Parking Operator's management system will have to start a Parking Session backed by the aforementioned Assigned Right. All stakeholders with a need-to-know shall be informed about this. To do so, the Parking Operator's management system sends a new Session record to the Platform.

Example: send new Session

POST /sessions

{
  "id": "parkingSessionId",
  "version": 1,
  "actualStart": "2025-03-31T17:00:00Z",
  "initiator": "BMW",
  "hierarchyElement": {
    "id": "carPark1Id",
    "version": 1
  },
  "credentials": [
    {
      "type": "licensePlate",
      "identifier": {
        "id": "MG-MM 267",
        "className": "DELicensePlate"
      }
    } 
  ],
  "segments": [
    {
      "id": "parkingSessiondId-001",
      "version": 1,
      "actualStart": "2025-03-31T17:00:00Z",
      "assignedRight": {
        "id": "parkingRightId",
        "version": 1
      },
      "validationType": [ "licensePlate"]
    }
  ]
}

Note: even though the booking was made for a specific time window, this doesn't necessarily mean that the customer will exactly behave like this. Therefore, the communicated Session record doesn't yet include an end time (neither for the Session, nor for the one Segment).

Where is the spot: Occupancy information

If the local parking system provides this type of data, up-to-date occupancy information can be queried for better guidance.

Example: occupancy information about the area

GET /places/carParkId1?expand=occupancy

{
  "id": "carParkId",
  "version": 1,
  "supply": {
    "supplyQuantity": 552,
    "supplyViewType": "spaceView"
  },
  "demandTable": {
    "frequency": "PT3M",
    "timestamp": "2025-03-31T17:01:00Z",
    "demandType": [
      {
        "count": 234,
        "occupancyCalculation": "counted",
        "recordDateTime": "2025-03-31T17:01:00Z",
      }
    ]
  }
}

Navigation to spot: guiding of customer within garage

This is currently not standardised (and most of it probably won't be with the exception of a potential map interface standard).

Park in/out: manuall park in/out

Done by the customer (driver).

Navigation to exit: guiding of customer within garage

This is currently not standardised (and most of it probably won't be with the exception of a potential map interface standard).

Exit: open barrier

Handled by the local parking management system. A variety of (local) policies might have to be checked before open the barrier. This is currently out of scope.

Exit: Stop parking transaction

Now that the vehicle has left the parking location, the Parking Operator's management system will provide an update of the Session, this time including the actual end time of the parking session.

PUT /sessions/parkingSessionId

{
  "id": "parkingSessionId",
  "version": 1,
  "actualStart": "2025-03-31T17:00:00Z",
  "actualEnd": "2025-04-02T09:55:00Z",
  "initiator": "BMW",
  "hierarchyElement": {
    "id": "carPark1Id",
    "version": 1
  },
  "credentials": [
    {
      "type": "licensePlate",
      "identifier": {
        "id": "MG-MM 267",
        "className": "DELicensePlate"
      }
    } 
  ],
  "segments": [
    {
      "id": "parkingSessiondId-001",
      "version": 1,
      "actualStart": "2025-03-31T17:00:00Z",
      "actualEnd": "2025-04-02T09:55:00Z",
      "assignedRight": {
        "id": "parkingRightId",
        "version": 1
      },
      "validationType": [ "licensePlate"]
    }
  ]
}

Payment: charge parking fee to customer account

The details of payment flow require further discussion in the team as there are many different ways of handling this.

Provided the booking boundaries haven't been exceeded, the monetary value of the parking session is known at this point. It was already communicated along the lines of the quote and booking process. See Example: obtain a quote.

During the booking, an Assigned Right was created (with id "parkingRightId"). At any time in the process, payments can be attached to this Assigned Right. Details to be discussed.

Example: posting a payment

Below is an example for a payment posted to the previously-issued Assigned Right. In APDS, a Payment and its Payment Lines offer identifiers which can be used to "tag" payments and facilitate the processing in connected billing and accounting systems. This will require agreed-upon conventions and identifiers that are not standardised by APDS but are rather specific to a particular, use case / eco system / project.

PUT /rights/assigned/parkingRightId

{
  "id": "parkingRightId",
  "version": 1,

  "payments": [
    {
      "id": "payment1Id",
      "version": 1,
      "dateCollected": "2025-03-31T17:00:00Z",
      "dateAuthorised": "2025-03-31T16:57:00Z",
      "transactionID": "TXparkingRightIdpayment1Id-001",
      "idCode": "INTERPROVIDERPAYMENT",
      "startPeriodCovered": "2025-03-31T17:00:00Z",
      "endPeriodCovered": "2025-04-02T09:55:00Z",
      "paymentLines": [
          "id": "paymentLine1Id",
          "version": 1,
          "identifierId": "TBD",
          "idCode": "TBD",
          "paymentType": "payment",
          "value": {
            "currencyType": "EUR",
            "currencyValue": 30
          }
      ]
    }
  ]
}

Payment: charge charging fee to customer account

(will be looked at at a later point)

Use Case 2: Manual Parking (L2 parking assistance)

(not final yet)
This is the use case where a vehicle equipped with L2 parking assistance is being used. The use case is almost identical to to Use Case 1. An overview of the identified use cases can be found here. In this section, we'll look at the following steps of this use case:

  • Before and while driving
    • Where is the parking facility?
    • How much does it cost?
    • Selection of a parking facility
    • Activation of in-vehicle navigation to entry
  • Arriving/Entry
    • Open barrier
    • start parking transaction
  • Where is the spot?
    • Occupancy information about area
    • Occupancy information about spot
  • Navigation to spot
    • Guiding and driving (L2) of customer within garage and 3D navigation map to free slot
  • Park in/out
    • L2 park in/out
    • In slot or L2-assisted relocation for charging and other value-added services
  • Charging
    • Manual plugin of cable
    • Manual selection of tariff
    • Manual start of charging service
  • Navigation to exit
    • Guiding and driving (L2) of customer within garage and 3D navigation map from slot to exit
  • Exit
    • Open barrier
    • Stop parking transaction
  • Payment
    • Charge parking fee to customer account
    • Charge charging fee to customer account

Before and while driving: where is the parking facility?

When the GET /places request is made, certain filter criteria can be specified in the query to narrow the search result down.

Example

The user backend serving a vehicle's user frontend wants to find parking options available at a specific destination (and in its vicinity):

GET /places?expand=all&latitude=48.177624&longitude=11.556482&radius=1000
  • the expand parameter value of all indicates that the response shall include all details about the matching places
  • the latitude, longitude and radius parameters specify the destination and the acceptable radius around it

The inventory system will respond with something like this:

{
  "meta": {
    "referenceInstant": 1741612330,
    "offset": 0,
    "pageSize": 100,
    "total": 1
  },
  "data": [
    {
      "id": "carPark1Id",
      "version": 1,
      "name": [
        {
          "language": "de",
          "string": "BMW Welt Parkhaus Nordwest"
        }
      ],
      "rightSpecifications": [
        { 
          "id": "publicParkingRightSpec",
          "version": 1
        }
      ],
      "indicativePointLocation": {
        "type": "Point",
        "coordinates": [
          11.552002,
          48.1858071
        ]
      },
      "description": [
        {
          "language": "en",
          "string": "The preferred parking location for visitors to the BMW Welt"
        }
      ],
      
      "areaType": "generalParking",
      "characteristics": {
        "accessControlled": true,
        "evChargingPoints": 15,
        "openToPublic": true,
        "spacesTotal": 552,
        "structureGrade": "underGround",
        "structureType": "offStreetStructure"
      },
      "contacts": [
        {
          "organisationName": [
            {
              "language": "de",
              "string": "BMW"
            }
          ],
          "type": "operator",
          "emails": [
            {
              "address": "[email protected]",
              "typeCode": "customerService"
            }
          ]
        }
      ],
      "paymentMethods": [
        {
          "paymentMode": [
            "payAfterExit", "payAndExit"
          ]
        }
      ],
      "placeStreetAddress": {
        "postCode": "80809",
        "city": [
          {
            "language": "de",
            "string": "München"
          },
          {
            "language": "en",
            "string": "Munich"
          }
        ],
        "countryCode": "DE",
        "addressLines": [
          {
            "type": "street",
            "order": 0,
            "text": "Moosacher Straße 61"
          }
        ]
      }      
    }
  ]
}

The caller will then have to query the details of the referenced right specification(s). Right Specifications provide further details on constraints and eligibility criteria that apply in a certain place.

GET /rights/specs/publicParkingRightSpec?expand=all

The inventory system will provide the requested details:

{
  "id": "publicParkingRightSpec",
  "version": 1,
  "rateEligibility": [
    {
      "eligibility": [
        {
          "qualifications": [
            {
              "withReservation": true,
            } 
          ]
        }
      ],
      "rateTable": {
        "id": "publicTariffId",
        "version": 1
      },
      "hierarchyElements": [
        {
          "id": "carPark1Id",
          "version": 1
        }
      ]
    }
  ],
  "validity": {
    "validityStatus": "definedByValidityTimeSpec",
    "validityTimeSpecification": {
      "overallStartTime": "2025-01-01T00:00:00Z"
    }
  },
  "transferable": false
}

Please note that - in this first simple example - the system only returns a single parking location with just one generic right specification that applies there.

Before and while driving: how much does it cost?

Depending on the user interaction design of the user frontend, the system would now query tariff details to answer the "How much does it cost?" question (or do this later when requesting a quote in preparation of a reservation).

Example

{
    "id": "publicTariffId",
    "version": 1,
    "rateTableName": [
        {
            "language": "en",
            "string": "Public Parking Tariff"
        }
    ],
    "rateLineCollections": [
        {
            "applicableCurrency": "EUR",
            "collectionSequence": 0,
            "maxTime": "PT12H",
            "rateLines": [
                {
                    "sequence": 0,
                    "description": [
                        {
                            "language": "en",
                            "string": "up to 1 hour"
                        }
                    ],
                    "rateLineType": "incrementingRate",
                    "value": 10.0,
                    "incrementPeriod": "PT1H"
                },
                {
                    "sequence": 1,
                    "description": [
                        {
                            "language": "en",
                            "string": "up to 2 hours"
                        }
                    ],
                    "rateLineType": "incrementingRate",
                    "value": 10.0,
                    "incrementPeriod": "PT1H"
                },
                {
                  "sequence": 2,
                  "description": [
                    {
                      "language": "en",
                      "string": "any following hour"
                    }
                  ],
                  "rateLineType": "incrementingRate",
                  "value": 4.0,
                  "incrementPeriod": "PT1H"
                }
            ],
            "relativeTimes": true
        }
    ],
    "availability": "public",
    "rateResponsibleParty": "BMW"
}

Before and while driving: selecting a parking facility (book)

Once the driver has - based on the previously obtained inventory information - decided to use the car park at the destination, the user backend will have to

  • obtain a binding offer (APDS term: quote) and then
  • confirm this (i.e. book it)

Example: obtain a quote

When the POST /quotes QuoteRightRequest is sent, the right specification to be applied shall be referenced. The list of available right specifications was retrieved earlier during the discovery process (in our first example, it was just one).

POST /quotes

(the request body contains a so-called QuoteRightRequest)

{
  "id": "requestId",
  "version": 1,
  "periodStart": "2025-03-31T17:00:00Z",
  "periodEnd": "2025-04-02T10:00:00Z",
  "requestTime": "2025-03-10T18:32:12Z",
  "referencedRightSpecification": {
    "id": "publicParkingRightSpec",
    "version": 1
  }
}

Based on this request, the parking aggregator / the parking operator backend system will check availability of parking services in this car park during this period of time.

The backend will then respond with a corresponding QuoteRightResponse:

{
  "id": "responseId",
  "version": 1,
  "start": "2025-03-31T17:00:00Z",
  "end": "2025-04-02T10:00:00Z",
  "requestTime": "2025-03-10T18:32:12Z",
  "quoteRequestId": "requestId",
  "responseTime": "2025-03-10T18:33:02:01Z",
  "options": [
    {
      "elementId": {
        "id": "opt1",
        "version": 1
      }, 
      "exact": true,
      "quoteExpiration": "2025-03-10T22:00:00Z",
      "financialQuote": {
        "id": "finQuote1",
        "version": 1,
        "serviceProvider": {
          "id": "QPARK",
          "version": 1
        },
        "transactionId": "CONF982379278340782347",
        "value": {
          "currencyType": "EUR",
          "currencyValue": 30
        },
        "taxIncluded": true
      }
    }
  ]
}

Example: accept the quote, and make a binding booking

In our example, the requested options can be met. The user backend is informed about the availability and the associated costs for this service. The received quote remains binding until 10pm the same day.

The user backend can then confirm the booking by asking the parking backend to create a corresponding APDS assigned right.

POST /rights/assigned

The request body contains the reference to the previously obtained quote as well as identification information of the vehicle.

{
  "id": "parkingRightId",
  "version": 1,
  "rightHolder": {
    "credentials": [
      {
        "type": "licensePlate",
        "identifier": {
          "id": "MG-MM 267",
          "className": "DELicensePlate"
        }
      }
    ]
  }
  "quoteResponseId": {
    "id": "responseId",
    "version": 1
  }
}

The parking system will then have to confirm this:

{
  "code": 201,
  "status": "ok",
  "message": "booking confirmed"
}

With that, the parking service has been booked, and the car park should be awaiting the drivers arrival at the specified date and time.

Before and while driving: Activation of in-vehicle navigation to entry

This process takes place entirely under the control of the OEM and does not require joint standardisation.

Arriving/Entry: open barrier

This process takes place entirely under the control of the Parking Operator's management system and does not require joint standardisation. Obviously, the parking facility will have to be equipped with ANPR technology (or other means of identification like e.g. RFID) to recognize the vehicle and the associated booking.

Arriving/Entry: start parking transaction

In APDS, a Session is the act of making use of a previously-obtained Assigned Right (parking right). In our case, this happened during the booking process. Now that the vehicle has entered the facility, the Parking Operator's management system will have to start a Parking Session backed by the aforementioned Assigned Right. All stakeholders with a need-to-know shall be informed about this. To do so, the Parking Operator's management system sends a new Session record to the Platform.

Example: send new Session

POST /sessions

{
  "id": "parkingSessionId",
  "version": 1,
  "actualStart": "2025-03-31T17:00:00Z",
  "initiator": "BMW",
  "hierarchyElement": {
    "id": "carPark1Id",
    "version": 1
  },
  "credentials": [
    {
      "type": "licensePlate",
      "identifier": {
        "id": "MG-MM 267",
        "className": "DELicensePlate"
      }
    } 
  ],
  "segments": [
    {
      "id": "parkingSessiondId-001",
      "version": 1,
      "actualStart": "2025-03-31T17:00:00Z",
      "assignedRight": {
        "id": "parkingRightId",
        "version": 1
      },
      "validationType": [ "licensePlate"]
    }
  ]
}

Note: even though the booking was made for a specific time window, this doesn't necessarily mean that the customer will exactly behave like this. Therefore, the communicated Session record doesn't yet include an end time (neither for the Session, nor for the one Segment).

Where is the spot: Occupancy information

If the local parking system provides this type of data, up-to-date occupancy information can be queried for better guidance.

Example: occupancy information about the area

GET /places/carParkId1?expand=occupancy

{
  "id": "carParkId",
  "version": 1,
  "supply": {
    "supplyQuantity": 552,
    "supplyViewType": "spaceView"
  },
  "demandTable": {
    "frequency": "PT3M",
    "timestamp": "2025-03-31T17:01:00Z",
    "demandType": [
      {
        "count": 234,
        "occupancyCalculation": "counted",
        "recordDateTime": "2025-03-31T17:01:00Z",
      }
    ]
  }
}

Navigation to spot: guiding of customer within garage

This is currently not standardised (and most of it probably won't be with the exception of a potential map interface standard).

Park in/out: manuall park in/out

Done by the customer (driver).

Navigation to exit: guiding of customer within garage

This is currently not standardised (and most of it probably won't be with the exception of a potential map interface standard).

Exit: open barrier

Handled by the local parking management system. A variety of (local) policies might have to be checked before open the barrier. This is currently out of scope.

Exit: Stop parking transaction

Now that the vehicle has left the parking location, the Parking Operator's management system will provide an update of the Session, this time including the actual end time of the parking session.

PUT /sessions/parkingSessionId

{
  "id": "parkingSessionId",
  "version": 1,
  "actualStart": "2025-03-31T17:00:00Z",
  "actualEnd": "2025-04-02T09:55:00Z",
  "initiator": "BMW",
  "hierarchyElement": {
    "id": "carPark1Id",
    "version": 1
  },
  "credentials": [
    {
      "type": "licensePlate",
      "identifier": {
        "id": "MG-MM 267",
        "className": "DELicensePlate"
      }
    } 
  ],
  "segments": [
    {
      "id": "parkingSessiondId-001",
      "version": 1,
      "actualStart": "2025-03-31T17:00:00Z",
      "actualEnd": "2025-04-02T09:55:00Z",
      "assignedRight": {
        "id": "parkingRightId",
        "version": 1
      },
      "validationType": [ "licensePlate"]
    }
  ]
}

Payment: charge parking fee to customer account

The details of payment flow require further discussion in the team as there are many different ways of handling this.

Provided the booking boundaries haven't been exceeded, the monetary value of the parking session is known at this point. It was already communicated along the lines of the quote and booking process. See Example: obtain a quote.

During the booking, an Assigned Right was created (with id "parkingRightId"). At any time in the process, payments can be attached to this Assigned Right. Details to be discussed.

Example: posting a payment

PUT /rights/assigned/parkingRightId

{
  "id": "parkingRightId",
  "version": 1,

  "payments": [
    {
      "id": "payment1Id",
      "version": 1,
      "dateCollected": "2025-03-31T17:00:00Z",
      "dateAuthorised": "2025-03-31T16:57:00Z",
      "transactionID": "TXparkingRightIdpayment1Id-001",
      "idCode": "INTERPROVIDERPAYMENT",
      "startPeriodCovered": "2025-03-31T17:00:00Z",
      "endPeriodCovered": "2025-04-02T09:55:00Z",
      "paymentLines": [
          "id": "paymentLine1Id",
          "version": 1,
          "identifierId": "TBD",
          "idCode": "TBD",
          "paymentType": "payment",
          "value": {
            "currencyType": "EUR",
            "currencyValue": 30
          }
      ]
    }
  ]
}

Payment: charge charging fee to customer account

(will be looked at at a later point)

Use Case 3: AVP Parking L4 (type 1,2,3)

(not final yet)
This is the use case where a vehicle or a vehicle equipped with L4 capabilities is being used. An overview of the identified use cases can be found here. In this section, we'll look at the following steps of this use case:

  • Before and while driving
    • Where is the AVP parking facility?
    • How much does it cost?
    • Selection of a parking facility
    • Activation of in-vehicle navigation to entry
  • Arriving/Entry
    • Open barrier
    • start parking transaction
  • Where is the spot?
    • Occupancy information about area
    • Occupancy information about spot
  • Navigationto spot
    • Guiding and driving (L4) of customer within garage and 3D navigation map to free spot
  • Park in/out
    • Automated park in/out
    • Automated relocation for charging and other services
  • Charging
    • Automated plugin of cable
    • Automated selection of tariff
    • Automatic start of charging service
  • Navigation to exit
    • Guiding and driving (L4) of customer within garage and 3D navigation map from slot to exit
  • Exit
    • Open barrier
    • Stop parking transaction
  • Payment
    • Charge parking fee to customer account
    • Charge charging fee to customer account

Availability query (where is the parking facility, and how much does it cost?)

When the GET /places request is made, desired service types can be specified in the query. The caller can differentiate between required qualifications and optional qualifications.

If none of the parking locations in the inventory matches the required qualifications, the result set will be empty. If the qualifications are tagged as optional, the result might as well include non-AVP locations. Especially in the early days of publicly available AVP, this might be required/helpful due to an initially low number of matching locations.

Example

The user backend serving a vehicle's user frontend wants to find out if AVP services are available at a specific destination:

GET /places \
    ?expand=all&latitude=48.177624&longitude=11.556482&radius=1000\
    &required_qualifications=avp\
    &vehicle_classification=avpVehicleType001
  • the expand parameter value of all indicates that the response shall include all details about the matching places
  • the latitude, longitude and radius parameters specify the destination and the acceptable radius around it
  • the required_qualifications parameter indicates that the caller is only interested in locations that offer AVP services
  • the vehicle_classification parameter specifies the AVP vehicle profile under which the vehicle falls (the classification identifiers are to be mutually defined by the OEMs)

The inventory system will respond with something like this:

{
  "meta": {
    "referenceInstant": 1741612330,
    "offset": 0,
    "pageSize": 100,
    "total": 1
  },
  "data": [
    {
      "id": "carPark1Id",
      "version": 1,
      "name": [
        {
          "language": "de",
          "string": "BMW Welt Parkhaus Nordwest"
        }
      ],
      "rightSpecifications": [
        { 
          "id": "avpRightSpec",
          "version": 1
        }
      ],
      "indicativePointLocation": {
        "type": "Point",
        "coordinates": [
          11.552002,
          48.1858071
        ]
      },
      "description": [
        {
          "language": "en",
          "string": "The preferred parking location for visitors to the BMW Welt"
        }
      ],
      
      "areaType": "generalParking",
      "characteristics": {
        "accessControlled": true,
        "evChargingPoints": 15,
        "openToPublic": true,
        "spacesTotal": 552,
        "structureGrade": "underGround",
        "structureType": "offStreetStructure"
      },
      "contacts": [
        {
          "organisationName": [
            {
              "language": "de",
              "string": "BMW"
            }
          ],
          "type": "operator",
          "emails": [
            {
              "address": "[email protected]",
              "typeCode": "customerService"
            }
          ]
        }
      ],
      "paymentMethods": [
        {
          "paymentMode": [
            "payAfterExit", "payAndExit"
          ]
        }
      ],
      "placeStreetAddress": {
        "postCode": "80809",
        "city": [
          {
            "language": "de",
            "string": "München"
          },
          {
            "language": "en",
            "string": "Munich"
          }
        ],
        "countryCode": "DE",
        "addressLines": [
          {
            "type": "street",
            "order": 0,
            "text": "Moosacher Straße 61"
          }
        ]
      }      
    }
  ]
}

The caller will then have to query the details of the referenced right specification.

GET /rights/specs/avpRightSpec?expand=all

The inventory system will provide the requested details:

{
  "id": "avpRightSpec",
  "version": 1,
  "rateEligibility": [
    {
      "eligibility": [
        {
          "qualifications": [
            {
              "withReservation": true,
              "vehicleCharacteristics": [
                {
                  "avpClassification": {
                    "entryDefinedValue": "avpVehicleType001"
                  }
                },
                {
                  "avpClassification": {
                    "entryDefinedValue": "avpVehicleType002"
                  }
                }
              ] 
            } 
          ]
        }
      ],
      "rateTable": {
        "id": "avpTariffId",
        "version": 1
      },
      "hierarchyElements": [
        {
          "id": "carPark1Id",
          "version": 1
        }
      ]
    }
  ],
  "validity": {
    "validityStatus": "definedByValidityTimeSpec",
    "validityTimeSpecification": {
      "overallStartTime": "2025-01-01T00:00:00Z"
    }
  },
  "transferable": false
}

From this response, the caller can see that his vehicle is eligible to use AVP services in the car park.
Depending on the user interaction design of the user frontend, the system could now query tariff details (or do this later when requesting a quote in preparation of a reservation).

{
    "id": "avpTariffId",
    "version": 1,
    "rateTableName": [
        {
            "language": "en",
            "string": "AVP Parking Tariff"
        }
    ],
    "rateLineCollections": [
        {
            "applicableCurrency": "EUR",
            "collectionSequence": 0,
            "maxTime": "PT12H",
            "rateLines": [
                {
                    "sequence": 0,
                    "description": [
                        {
                            "language": "en",
                            "string": "up to 1 hour"
                        }
                    ],
                    "rateLineType": "incrementingRate",
                    "value": 10.0,
                    "incrementPeriod": "PT1H"
                },
                {
                    "sequence": 1,
                    "description": [
                        {
                            "language": "en",
                            "string": "up to 2 hours"
                        }
                    ],
                    "rateLineType": "incrementingRate",
                    "value": 10.0,
                    "incrementPeriod": "PT1H"
                },
                {
                  "sequence": 2,
                  "description": [
                    {
                      "language": "en",
                      "string": "any following hour"
                    }
                  ],
                  "rateLineType": "incrementingRate",
                  "value": 4.0,
                  "incrementPeriod": "PT1H"
                }
            ],
            "relativeTimes": true
        }
    ],
    "availability": "public",
    "rateResponsibleParty": "BMW"
}

Making a reservation

Once the driver has - based on the previously obtained inventory information - decided to use the AVP car park at the destination, the user backend will have to

  • obtain a binding offer (APDS term: quote) and then
  • confirm this (i.e. book it)

When the POST /quotes QuoteRightRequest is sent, a right specification shall be used that has a matching vehicleCharacteristics. The list of available right specifications was retrieved earlier during the discovery process.

POST /quotes

(the request body contains a so-called QuoteRightRequest)

{
  "id": "requestId",
  "version": 1,
  "periodStart": "2025-03-31T17:00:00Z",
  "periodEnd": "2025-04-02T10:00:00Z",
  "requestTime": "2025-03-10T18:32:12Z",
  "eligibility": {
    "qualifications": [
      {
        "vehicleCharacteristics": [
          {
            "avpClassification": {
              "entryDefinedValue": "avpVehicleType001"
            }
          }
        ]
      }
    ]
  },
  "referencedRightSpecification": {
    "id": "avpRightSpec",
    "version": 1
  }
}

Based on this request, the parking aggregator / the parking operator backend system will check availability of AVP services in this car park for this period of time.

The backend will then respond with a corresponding QuoteRightResponse:

{
  "id": "responseId",
  "version": 1,
  "start": "2025-03-31T17:00:00Z",
  "end": "2025-04-02T10:00:00Z",
  "requestTime": "2025-03-10T18:32:12Z",
  "quoteRequestId": "requestId",
  "responseTime": "2025-03-10T18:33:02:01Z",
  "options": [
    {
      "elementId": {
        "id": "opt1",
        "version": 1
      }, 
      "exact": true,
      "quoteExpiration": "2025-03-10T22:00:00Z",
      "financialQuote": {
        "id": "finQuote1",
        "version": 1,
        "serviceProvider": {
          "id": "QPARK",
          "version": 1
        },
        "transactionId": "CONF982379278340782347",
        "value": {
          "currencyType": "EUR",
          "currencyValue": 30
        },
        "taxIncluded": true
      }
    }
  ]
}

In our example, the requested options can be met. The user backend is informed about the availability and the associated costs for this service. The received quote remains binding until 10pm the same day.

The user backend can then confirm the booking by asking the parking backend to create a corresponding APDS assigned right.

POST /rights/assigned

The request body contains the reference to the previously obtained quote

{
  "quoteResponseId": {
    "id": "responseId",
    "version": 1
  }
}

The parking system will then have to confirm this:

{
  "code": 201,
  "status": "ok",
  "message": "booking confirmed"
}

With that, the AVP parking service has been booked, and the car park should be awaiting the drivers arrival at the specified date and time.

Prerequisites and Conventions

Parking Operator Management System

It is the common understanding that all participating PMSes (Parking Management Systems) must be cloud-connected and that communication between other stakeholders and the Parking Operator will by default happen via the Parking Operator's cloud backend system.

ANPR

While technically - and APDS-wise - a variety of identification methods could be supported, we are currently focusing on ANPR (Automated Number Plate Recognition).

OEM-defined Vehicle Classification

The OEMs offering AVP will have to mutually maintain a publicly available list of AVP vehicle classifications.

Example:

{
  "id": "AVP-CLASSIFICATION-LIST",
  "version": 1,
  "creator": {
    "id": "CarOEMs",
    "version": 1
  },
  "locator": "https://codelists.oemrepository.online",
  "userDefinedCodeListEntries": [
    {
      "entryIndex": 0,
      "definedValue": "avpVehicleType001",
      "entryDescription": "optional description of the AVP vehicle classification"
    },
    {
      "entryIndex": 1,
      "definedValue": "avpVehicleType002",
      "entryDescription": "optional description of the AVP vehicle classification"
    }
  ]
}

Payment Processing

In APDS, a Payment and its Payment Lines offer identifiers which can be used to "tag" payments and facilitate the processing in connected billing and accounting systems. This will require agreed-upon conventions and identifiers that are not standardised by APDS but are rather specific to a particular, use case / eco system / project.