Heartbeat

Source: OCPP 2.0.1 Part 2 — Specification (Edition 2, 2022-12-15) Use Case G02 — Heartbeat (Functional Block G. Availability), Section 1.29 (Messages)

Overview

This use case describes a way to let the CSMS know the Charging Station is still connected: a Charging Station sends a heartbeat after a configurable time interval. Depending on the configuration, the Heartbeat can also be used for time synchronisation.

Actors: Charging Station, CSMS

Scenario:

If there is no activity for a certain time, the Charging Station sends HeartbeatRequest so that the CSMS knows that the Charging Station is still alive.
Upon receipt of HeartbeatRequest, the CSMS responds with HeartbeatResponse. The response contains the current time of the CSMS, which the Charging Station MAY use to synchronize its internal clock.

Prerequisite(s): The heartbeat interval is set.

Postconditions:

Success: The CSMS knows the Charging Station is still connected.
Failure: The CSMS concludes that the Charging Station is offline.

NOTE: With JSON over WebSocket, sending heartbeats is not instrumental to keeping WebSockets alive — WebSockets already provide a mechanism for that. However, if the Charging Station uses the heartbeat for time synchronization, it is advised to send at least one heartbeat per 24 hours.

Sequence Diagram

Figure 75. Sequence Diagram: Heartbeat

Charging Station  ──── HeartbeatRequest ────▶  CSMS
Charging Station  ◀─── HeartbeatResponse ────  CSMS
                       (currentTime)

Initiator

Charging Station → CSMS

Fields

This contains the field definition of the HeartbeatRequest PDU sent by the Charging Station to the CSMS.

No fields are defined.

This contains the field definition of the HeartbeatResponse PDU sent by the CSMS to the Charging Station in response to a HeartbeatRequest.

Field Name	Field Type	Card.	Description
currentTime	dateTime	1..1	Required. Contains the current time of the CSMS.

Requirements (G02.FR.xx)

ID	Precondition	Requirement
G02.FR.01	When the CSMS responds with `BootNotificationResponse` with status `Accepted`.	The Charging Station SHALL adjust the heartbeat interval in accordance with the interval from the response message.
G02.FR.02	—	The Charging Station SHALL send `HeartbeatRequest` after a configurable time interval, to ensure the CSMS knows it is alive.
G02.FR.03	—	The `HeartbeatResponse` message SHALL contain the current time of the CSMS.
G02.FR.04	Whenever a message from a Charging Station has been received.	The CSMS SHALL assume availability of that Charging Station.
G02.FR.05	—	It is RECOMMENDED that the Charging Station resets its heartbeat interval timer when another message has been sent to the CSMS.
G02.FR.06	When the Charging Station receives a `HeartbeatResponse`.	It is RECOMMENDED that the Charging Station uses the current time to synchronize its internal clock.
G02.FR.07	When the heartbeat interval timer is continuously reset because of continuous sending of messages, AND `HeartbeatRequest` is used for time synchronisation.	It is RECOMMENDED that the Charging Station sends a `HeartbeatRequest` at least once every 24 hours to synchronise the clock.

Examples

{}

{
  "currentTime": "2026-04-27T12:34:56Z"
}

Schema

Source: schemas/HeartbeatRequest.json, schemas/HeartbeatResponse.json (OCPP 2.0.1 FINAL)

Request schema (JSON Schema)

Response schema (JSON Schema)

BootNotification — BootNotificationResponse.interval defines the heartbeat interval that the Charging Station applies after a successful boot.
Device Model — heartbeat interval is also exposed via the HeartbeatInterval variable on the OCPPCommCtrlr controller component (configurable via SetVariables / GetVariables).