Skip to content
Documentation Menu

Boot Notification

Source: OCPP 1.6 Specification — Section 4.2 (Operation), Sections 6.3 / 6.4 (Messages)

Overview

After start-up, a Charge Point SHALL send a request to the Central System with information about its configuration (e.g. version, vendor, etc.). The Central System SHALL respond to indicate whether it will accept the Charge Point.

The Charge Point SHALL send a BootNotification.req PDU each time it boots or reboots. Between the physical power-on/reboot and the successful completion of a BootNotification, where Central System returns Accepted or Pending, the Charge Point SHALL NOT send any other request to the Central System. This includes cached messages that are still present in the Charge Point from before.

When the Central System responds with a BootNotification.conf with a status Accepted, the Charge Point will adjust the heartbeat interval in accordance with the interval from the response PDU and it is RECOMMENDED to synchronize its internal clock with the supplied Central System's current time. If the Central System returns something other than Accepted, the value of the interval field indicates the minimum wait time before sending a next BootNotification request. If that interval value is zero, the Charge Point chooses a waiting interval on its own, in a way that avoids flooding the Central System with requests. A Charge Point SHOULD NOT send a BootNotification.req earlier, unless requested to do so with a TriggerMessage.req.

If the Central System returns the status Rejected, the Charge Point SHALL NOT send any OCPP message to the Central System until the aforementioned retry interval has expired. During this interval the Charge Point may no longer be reachable from the Central System. It MAY for instance close its communication channel or shut down its communication hardware. Also the Central System MAY close the communication channel, for instance to free up system resources. While Rejected, the Charge Point SHALL NOT respond to any Central System initiated message. The Central System SHOULD NOT initiate any.

The Central System MAY also return a Pending registration status to indicate that it wants to retrieve or set certain information on the Charge Point before the Central System will accept the Charge Point. If the Central System returns the Pending status, the communication channel SHOULD NOT be closed by either the Charge Point or the Central System. The Central System MAY send request messages to retrieve information from the Charge Point or change its configuration. The Charge Point SHOULD respond to these messages. The Charge Point SHALL NOT send request messages to the Central System unless it has been instructed by the Central System to do so with a TriggerMessage.req request.

While in pending state, the following Central System initiated messages are not allowed: RemoteStartTransaction.req and RemoteStopTransaction.req.

NOTE: While not yet accepted by the Central System, the Charge Point may allow locally-authorized transactions if it is configured to do so, as described in Local Authorization & Offline Behavior. Parties who want to implement this behavior must realize that it is uncertain if those transactions can ever be delivered to the Central System.

Sequence Diagram

Figure 13. Sequence Diagram: Boot Notification

Charge Point  ──── BootNotification.req ────▶  Central System
Charge Point  ◀─── BootNotification.conf ────  Central System
                   (currentTime, interval, status)

Initiator

Charge Point → Central System

Fields

This contains the field definition of the BootNotification.req PDU sent by the Charge Point to the Central System.

Field NameField TypeCard.Description
chargePointVendorCiString20Type1..1Required. This contains a value that identifies the vendor of the ChargePoint.
chargePointModelCiString20Type1..1Required. This contains a value that identifies the model of the ChargePoint.
chargePointSerialNumberCiString25Type0..1Optional. This contains a value that identifies the serial number of the Charge Point.
chargeBoxSerialNumberCiString25Type0..1Optional. This contains a value that identifies the serial number of the Charge Box inside the Charge Point. Deprecated, will be removed in future version.
firmwareVersionCiString50Type0..1Optional. This contains the firmware version of the Charge Point.
iccidCiString20Type0..1Optional. This contains the ICCID of the modem's SIM card.
imsiCiString20Type0..1Optional. This contains the IMSI of the modem's SIM card.
meterSerialNumberCiString25Type0..1Optional. This contains the serial number of the main power meter of the Charge Point.
meterTypeCiString25Type0..1Optional. This contains the type of the main power meter of the Charge Point.

RegistrationStatus values

  • Accepted — Charge Point is accepted by the Central System.
  • Pending — Central System is not yet ready to accept the Charge Point. Central System may send messages to retrieve information or change configuration.
  • Rejected — Charge Point is not accepted by the Central System. This may happen when the Charge Point id is not known by the Central System.

Examples

{
  "chargePointVendor": "VendorX",
  "chargePointModel": "ModelY-1000",
  "chargePointSerialNumber": "CP-2026-000123",
  "firmwareVersion": "1.4.2",
  "iccid": "8931080019073512345",
  "imsi": "204043388888888",
  "meterSerialNumber": "MSN-998877",
  "meterType": "AC Type-2"
}

Behavior Summary

StatusCharge Point may send other PDUs?Action
AcceptedYesSync clock from currentTime, use interval as heartbeat interval.
PendingOnly in response to CSMS requestsWait; respond to CSMS configuration/info requests.
RejectedNoWait at least interval seconds before retrying BootNotification.

Schema

Source: schemas/BootNotification.json, schemas/BootNotificationResponse.json (OCPP 1.6, JSON Schema draft-04)

Request schema (JSON Schema)
Response schema (JSON Schema)