Understanding OCPP 1.6: Implementation and Functionality

Understanding the Implementation of OCPP 1.6 Protocol for Charging Stations

The Open Charge Point Protocol (OCPP) is a pivotal standard for communication between electric vehicle (EV) charging stations and central management systems. This blog post delves into the implementation details of OCPP 1.6, highlighting its components, communication flow, and key functionalities.

Charging Points and Charging Stations

• Terminology: OCPP 1.6 refers to charging units as “charge points,” while OCPP 2.0 updates the terminology to “Charging Stations.”
• Connectors: Charging stations can have multiple connectors, which may include sockets, fixed cables, and various charging standards like CSS, ChaDeMo, Type 2, and Bharat EV chargers.
• Connectivity: These stations connect to the internet via LAN, Wi-Fi, or mobile networks.

Central System

The Central System is the IT infrastructure responsible for managing multiple charging stations. Its primary functions include:

• Authorization: Managing user access and permissions.
• Communication: Acting as a WebSocket server, the Central System communicates with charging stations, which function as WebSocket clients.

• Configuration: The Central System is accessed via a URL, such as:

  ws://cs.chargeking.in/ocpp
  

  Charging stations use this URL to establish a WebSocket connection with the Central System. Connections are initiated by the charging stations, not the other way around.

OCPP Protocol

OCPP is a standardized protocol that facilitates communication between charging stations and central systems. Key aspects include:

• Message Format: OCPP defines the JSON messages exchanged over WebSocket connections.
• Versions: The protocol has two main versions: 1.6 and 2.1. While OCPP 1.6 is expected to be in use until 2024, newer charging stations are encouraged to implement OCPP 2.1 to leverage updated features.
• Connector Details: OCPP 1.6 does not provide details about the type and number of connectors, but the Central System can manage this information using the charging station’s unique identity.

Connecting Stations to the Central System

Connecting a charging station to the Central System involves two primary steps:

1. Open WebSocket Connection: The charging station initiates a connection to the Central System using its embedded URL configuration.

   ws://cs.chargeking.in/ocpp/CK_XXX_0001
   

   Here, CK_XXX_0001 is the unique identifier for the charging station.

2. Boot Notification: Once connected, the charging station sends a BootNotification message containing details like the vendor and model.

OCPP Message Structure

[2, "CK_XX_0001-654321", "BootNotification", {"chargePointVendor": "Vendor01", "chargePointModel": "BH-0001"}]

• Message Type (2): Indicates a CALL from client to server.
• Unique ID: Binds the request and response.
• Action: Specifies the type of message, e.g., BootNotification, StartTransaction, StopTransaction.
• Payload: Contains mandatory and optional fields, such as chargePointVendor and chargePointModel.

Boot Notification Response

[3, "CK_XX_0001-654321", {"status": "Accepted", "interval": "60", "currentTime": "2023-12-12T11:06:21Z"}]

The Central System responds with a status, a message interval for heartbeat and meter values, and the current time.

Heartbeats

Heartbeats are periodic messages sent by the charging station to confirm it is functioning correctly.

• Heartbeat Request:

  [2, "CK_XX_0001-654321", "Heartbeat", {}]
  

• Heartbeat Response:

  [3, "CK_XX_0001-654321", {"currentTime": "2023-12-12T11:06:21Z"}]
  

Charging Station Statuses

OCPP 1.6 defines various statuses for charging stations:

• Available
• Preparing
• Charging
• SuspendedEVSE: EVSE has paused charging despite the vehicle being plugged in.
• SuspendedEV: Vehicle is connected but not accepting power.
• Finishing
• Reserved
• Unavailable
• Faulted

Each status is tied to a specific connector within the station. For instance, one connector might be “Available” while another is “Charging.”

Status Notification

Charging stations report their statuses using the StatusNotification message.

Status Notification Request

Contains:

• connector_id
• error_code
• status: ChargePointStatus

Optional fields:

• timestamp: When the status changed.
• info: Additional error information (up to 50 characters).
• vendor_id: Vendor-specific code.
• vendor_error_code: Vendor-specific error code.

Status Notification Response

[3, "CK_XX_0001-654321", {}]

An empty response serves as an acknowledgment from the Central System. If no confirmation is received, the charging station will resend the status notification.

Authorization and Starting a Charge

Authorization Methods

• RFID Tags: Can be insecure.
• Mobile Apps
• Plug & Charge: Requires both the vehicle and charging station to support the ISO 15118 standard.

Authorization Flow

1. Authorize Request: Sent from the charge point to the Central System with an IdTag.
2. Authorize Response: Can be Accepted, Blocked, Expired, or Invalid.

RFID Charging Flow

![RFID charging flow]

1. Driver connects the cable after authorization.
2. Station sends a StartTransaction message to the Central System.
3. Central System authorizes the start and responds with a transactionId.
4. EV begins charging.

Note: Authorization occurs twice—during the Authorize message and the StartTransaction message. Stations may use an authorization cache to authorize drivers locally if needed.

Start Transaction

Start Transaction Request

Required fields:

• connector_id
• id_tag
• meter_start
• timestamp

Optional field:

• reservation_id: If reservation is implemented.

Start Transaction Response

Includes:

• status
• transactionId: A unique identifier (not based solely on timestamp to avoid duplication).

Mobile App/Admin Panel Charging Flow

1. The Central System initiates charging with a RemoteStartTransaction request.
2. If authorized, the response is Accepted or Rejected.
3. The driver connects the charging cable.
4. The station sends a StartTransaction request.
5. The Central System responds with an Accepted status and a unique TransactionId, initiating the charge.

Managing Charging Data

Efficient data handling involves aggregating values in a single message rather than multiple responses.

Required Fields

• value: Energy usage in Wh.
• context: Context of the measurement (e.g., Sample.Periodic, Transaction.Begin, Transaction.End).

Optional Fields

• format: Defaults to raw. Can be signed binary.
• measurand: Type of measurement (e.g., "Energy.Active.Import.Register", "Voltage", "Current", "Temperature").
• phase: Relevant for multiphase electricity connections.
• location: Indicates where the measurement was taken (Body or Outlet).
• unit: Unit of measurement (Wh, A, V).

Stopping a Charge

Locally

1. RFID: Use the card again to stop the transaction.
2. Mobile App
3. Plug & Charge

Stop Transaction Request Using RFID

Required fields:

• meter_stop: Energy meter value in Wh.
• timestamp: When the transaction stopped.
• transaction_id: Matches the one from the StartTransaction message.

Optional fields:

• reason
• id_tag
• transaction_data: Detailed transaction information.

Calculating Usage

• Cumulative Usage: Based on the total energy measured by the meter.
• Transaction-Based: meter_start always starts at 0.

Note: The Central System cannot reject a StopTransaction request. If charging is paused by the EV, the station should send a new StatusNotification (e.g., SuspendEV) instead of stopping the transaction.

Remote Stop Using Mobile App or Admin Panel

1. The mobile app or admin panel sends a RemoteStopTransaction request to the Central System.
2. The charging station responds with Accepted or Rejected.
3. An Accepted response does not guarantee that charging has stopped; the station will send a StopTransaction request once the charge is halted.

Resetting a Station

Issues like an open WebSocket connection without receiving heartbeats can be resolved by rebooting the charging station.

Reset Methods

1. Hard Reset: Immediately stops all operations without gracefully ending ongoing transactions, risking data loss.
2. Soft Reset: Attempts to gracefully stop transactions before resetting.

Local Authorization Cache

Charging stations can manage authorizations locally, especially when offline or experiencing connectivity issues.

Offline Behaviors

1. Station Unavailable:
   • Simple to implement.
   • Zero risk of misuse.
   • Poor customer experience.
   • Suitable for stations with reliable networks.
2. Accept All Authorizations Using RFID Tags:
   • Simple implementation.
   • Transactions can be invoiced later.
   • Potential for some free charging.
   • Good user experience with minor financial loss.
3. Local Authorization Cache:
   • Allows recent users to charge offline.
   • Simple implementation.
   • Good user experience with limited financial loss.
   • Charging unavailable if the user hasn’t charged recently.
4. Local Authorization List:
   • Provides detailed control over RFID tags.
   • New customers can charge.
   • No financial risk.
   • Requires maintenance of the list.
   • Limited memory for storing the list.

Managing Authorization Cache

• Enable/Disable: The Central System can toggle the authorization cache using the ChangeConfiguration message with the key AuthorizationCacheEnabled.
• Response: The station responds with Accepted, Rejected, NotSupported, or RebootRequired.
• Expiration: The Central System can set an expiration time using the expiryDate parameter.

Local Authorization Lists

Updated via the SendLocalList message, which includes:

• list_version
• update_type: Full or Differential.
• local_authorization_list: Contains idTag, status, and expiryDate.

Charging stations manage configuration keys to support local lists:

• SupportedFeatureProfile: Indicates if local lists are supported.
• LocalAuthListMaxLength: Maximum number of idTags in the local list.
• SendLocalListMaxLength: Maximum number of idTags that can be updated in a single request.
• LocalAuthListEnabled: Indicates if local lists are currently enabled.

Reservations

Reservations allow users to reserve a charging connector for a specific duration.

Limitations

• Reservations can only be made from the present moment for a predefined time duration.
• Future reservations are not supported.

Reservation Process

1. ReserveNow Message:
   • connector_id
   • expiry_date
   • id_tag
   • reservation_id
   • parent_id_tag (optional)
2. ReserveNow Response:
   • Status: Accepted or Rejected

3. Transaction: When the EV uses its reserved privilege, the StartTransaction response includes a reservationID.

4. Cancel Reservation: The Central System can cancel a reservation using the CancelReservation message with the reservationID.

Definitions

• EVSE (Electric Vehicle Supply Equipment): Each EVSE can use one connector at a time.
• CSMS (Charging Station Management System): The IT system that controls multiple charging stations.