Open Charge Point Protocol (OCPP): 1.6 vs 2.0.1 use cases

What is Open Charge Point Protocol (OCPP)?

Open Charge Point Protocol, usually called OCPP, is an open communication standard between an EV charging station and a charging station management system. In practice, it is the language that lets a charger report its status, start or stop a session, send meter values, receive configuration, and stay connected to the operator's backend.

For charge point operators, hotels, fleets, parking operators, and companies building charging networks, OCPP matters because the charger is only one part of the service. The operational layer needs charging station management software, payments, tariffs, invoices, access control, reports, and monitoring.

The standard is developed by the Open Charge Alliance, and the most common production versions today are OCPP 1.6 and OCPP 2.0.1.

Quick navigation:

• OCPP 1.6 vs OCPP 2.0.1
• OCPP 2.0.1 changes
• OCPP use case matrix
• Sample implemented use cases
• OCPP implementation problems
• OCPP FAQ

Why OCPP is important for charging station owners

Without a standard protocol, the owner of a charging station can become locked into one hardware vendor or one closed software platform. OCPP reduces that risk because many chargers and management systems can communicate through a shared protocol.

For a business owner, this has practical value:

• easier charger onboarding,
• better remote monitoring,
• remote configuration and diagnostics,
• less dependence on one hardware supplier,
• the ability to connect chargers with payments, access control, and reporting,
• a simpler path to scale from one location to a charging network.

EV24 uses OCPP as part of the operational layer for EV charging. The EV24 documentation on charger configuration shows how OCPP settings sit next to tariffs, authorization methods, address, QR code, and country requirements.

OCPP 1.6 vs OCPP 2.0.1

OCPP 1.6 is still widely used and supported by many AC and DC chargers. OCPP 2.0.1 adds stronger capabilities for large networks, device management, security, ISO 15118, smart charging, and richer transaction handling. The Open Charge Alliance notes that OCPP 2.0.1 is not backward compatible with OCPP 1.6, so version choice should be checked before hardware purchase or backend migration.

What changed in OCPP 2.0.1

The older article focused heavily on OCPP 2.0 use cases. The important point is not that every operator needs every feature on day one. The point is that OCPP 2.0.1 gives larger charging networks a more structured way to manage chargers, security, transactions, tariffs, diagnostics, and ISO 15118.

Key changes include:

• Device management - inventory reporting, improved configuration, better error visibility, variables, and monitoring.
• Transaction handling - a more structured TransactionEvent approach instead of separate start, stop, meter, and status messages.
• Security profiles - stronger support for charger authentication, secure communication, certificates, security logs, and secure firmware updates.
• Smart charging - better support for energy management systems, local controllers, and advanced charging profiles.
• ISO 15118 support - better foundation for Plug & Charge and EV-side smart charging communication.
• Driver experience - more authorization options, tariff visibility, cost display, and station messages.

For procurement and implementation teams, the OCPP certification program is also worth checking. Certification does not replace field testing, but it helps verify that a charger or CSMS implementation follows the protocol specification.

OCPP 1.6 vs OCPP 2.0.1 use cases

The original technical table listed detailed OCPP use cases by category. For a business blog, the useful version is a map of which operational areas were already possible in OCPP 1.6 and which areas were added or expanded in OCPP 2.0.1.

Detailed OCPP use case matrix

For teams comparing protocol versions during charger selection or backend integration, the detailed view is also useful. The table below keeps the original structure: use case ID, use case name, whether it exists in OCPP 1.6, and whether it is new in OCPP 2.0.

Sample of implemented use cases

A use case matrix is useful for specification work, but implementation teams usually start with a smaller set of flows that prove the charger and CSMS can communicate reliably. These are the practical OCPP scenarios worth testing first.

Source code examples

The examples below show the shape of OCPP-J messages over WebSocket. They are simplified for readability, but they reflect the practical implementation pattern: CALL from one side, then CALLRESULT from the other side with the same message ID.

1. Charging station boots and connects to CSMS

[2, "boot-001", "BootNotification", {
  "chargePointVendor": "ExampleVendor",
  "chargePointModel": "AC22",
  "chargePointSerialNumber": "EV24-DEMO-001",
  "firmwareVersion": "1.6.0"
}]

[3, "boot-001", {
  "currentTime": "2026-04-28T10:00:00Z",
  "interval": 60,
  "status": "Accepted"
}]

2. Driver is authorized by RFID or another idTag

[2, "auth-001", "Authorize", {
  "idTag": "RFID-123456"
}]

[3, "auth-001", {
  "idTagInfo": {
    "status": "Accepted"
  }
}]

3. Backend starts a session remotely

[2, "remote-start-001", "RemoteStartTransaction", {
  "connectorId": 1,
  "idTag": "APP-USER-42"
}]

[3, "remote-start-001", {
  "status": "Accepted"
}]

4. Charger sends meter values during the transaction

[2, "meter-001", "MeterValues", {
  "connectorId": 1,
  "transactionId": 987654,
  "meterValue": [{
    "timestamp": "2026-04-28T10:15:00Z",
    "sampledValue": [{
      "value": "12.84",
      "measurand": "Energy.Active.Import.Register",
      "unit": "kWh"
    }]
  }]
}]

5. OCPP 2.0.1 transaction event sample

[2, "txevent-001", "TransactionEvent", {
  "eventType": "Updated",
  "timestamp": "2026-04-28T10:15:00Z",
  "triggerReason": "MeterValuePeriodic",
  "seqNo": 7,
  "transactionInfo": {
    "transactionId": "TX-987654"
  },
  "evse": {
    "id": 1,
    "connectorId": 1
  },
  "meterValue": [{
    "timestamp": "2026-04-28T10:15:00Z",
    "sampledValue": [{
      "value": 12.84,
      "measurand": "Energy.Active.Import.Register",
      "unitOfMeasure": {
        "unit": "kWh"
      }
    }]
  }]
}]

What OCPP does during a charging session

A driver sees a simple process: scan a QR code, pay, plug in, and charge. Behind that process, the charger and the backend exchange multiple messages.

Typical OCPP charging flow

Connectcharger establishes communication with the management system

→

Authorizedriver starts with app, QR, RFID, PIN, terminal, or remote command

→

Chargesession status and meter values are sent to the backend

→

Settlesession data supports payment, invoice, report, or fleet billing

What to check before buying an OCPP charger

Not every “OCPP compatible” charger behaves the same way. Before buying hardware, check whether the charger has been tested with the management system you plan to use.

The most important questions are:

• which OCPP version is supported,
• whether the charger uses JSON over WebSocket,
• whether remote start and remote stop work reliably,
• how meter values are reported,
• whether connector statuses are accurate,
• whether firmware updates and diagnostics are available,
• how the charger handles offline sessions,
• whether payment terminal, QR, RFID, and PIN flows are supported.

For a broader hardware decision, start with how to choose an EV charging station. OCPP compatibility is necessary, but it is not the only criterion.

OCPP and payments

OCPP does not replace a payment system. It sends the charging session data that the payment and billing layer needs: authorization result, start time, stop time, connector, meter values, and status.

That is why operators should think about OCPP together with the business model. Public charging often needs payment terminals, QR payment, ad-hoc access, invoices, and settlement reports. Private charging may need access groups, RFID, PIN, employee billing, or fleet reports.

The EV24 charging app and charge point management system connect the driver-facing process with the operational backend, so OCPP data can support payments, tariffs, invoices, and reporting.

OCPP for integrations and custom EV apps

For larger projects, OCPP is only one integration layer. Companies may also need APIs for mobile apps, parking systems, CRM, accounting, or partner portals.

The EV24 Partner API supports these scenarios on top of the charging operations layer. For technical onboarding, the EV24 API documentation for integrators explains access, tokens, and base API requirements.

Common OCPP implementation problems

Most problems appear not in the specification but in implementation. Different chargers can interpret timing, statuses, meter values, and edge cases differently.

Common issues include:

• charger connects but does not report connector status correctly,
• remote start works only in some authorization modes,
• meter values are too rare or inconsistent,
• the station loses connectivity during a session,
• offline transactions are not synchronized cleanly,
• firmware changes alter message behavior,
• payment status and charging status are not aligned.

This is why OCPP testing should cover real charging sessions, failed payments, remote actions, offline behavior, and restart scenarios, not only a successful first connection.

Summary

Open Charge Point Protocol is one of the foundations of modern EV charging infrastructure. It helps connect chargers with a management system, reduces vendor lock-in, and enables monitoring, configuration, sessions, and metering.

For station owners, the key question is not only whether a charger supports OCPP. The real question is whether the whole operating model works: charger, backend, payments, access, reporting, support, and integrations.

FAQ

What does OCPP stand for?+

OCPP stands for Open Charge Point Protocol. It is a communication protocol between an EV charging station and a charging station management system.

What is the difference between OCPP 1.6 and OCPP 2.0.1?+

OCPP 1.6 is widely used and works well for many existing charging networks. OCPP 2.0.1 adds a more advanced device model, improved transaction handling, stronger security, ISO 15118 support, richer smart charging, and better driver facing information.

Are OCPP 1.6 and OCPP 2.0.1 compatible?+

No. OCPP 2.0.1 is not backward compatible with OCPP 1.6. Before buying chargers or migrating a backend, the operator should confirm which OCPP version the charger and CSMS support.

Which OCPP use cases are new in OCPP 2.0?+

New or expanded use cases include certificate management, security event notifications, variables and reports, PIN and payment terminal authorization, transaction status checks, tariff and cost display, advanced smart charging, ISO 15118 certificate management, and richer diagnostics.

Does OCPP handle payments?+

OCPP does not replace a payment system. It provides session, authorization, status, and meter data that payment, invoice, settlement, and reporting systems can use.

Why does OCPP matter for charge point operators?+

OCPP reduces vendor lock in and helps operators connect chargers with management software, monitoring, remote actions, tariffs, access control, payments, reports, and integrations.

How does EV24 use OCPP?+

EV24 uses OCPP as part of the charging operations layer. OCPP data from chargers can support station monitoring, session handling, tariffs, authorization, payments, billing, reporting, and integrations through the EV24 platform.