EV Charging Protocols: Understanding of the communication layers within a charging project

Sep 22, 2026

Leave a message

EV Charging Protocols and Their Impact on Charging Station Design | SINELINK

Home  /  Insights  /  EV Charging

EV CHARGING INSIGHTS

EV Charging Protocols and Their Impact on Charging Station Design

A planning guide to OCPP. Understanding of the communication layers within a charging project

SINELINK   |   Technical Guide

 info-832-726

A charging station can connect successfully to its management platform and still fail to work with the site's dynamic load balancing controller. For developers, EPC contractors and facility owners, that gap can mean additional integration work, restricted equipment choices or changes to the control architecture after installation.

Protocol selection should therefore begin with the intended operation of the site. Establish which system will allocate charging capacity, how the chargers will receive limits, and what should happen when communication fails. Then verify that the selected hardware and software support those requirements together.

Understand the communication layers

Several communication links coexist within a charging project. Each carries different information and serves a different purpose.

Connection
Typical protocols or interfaces
Main purpose
Vehicle to charger
IEC 61851 control signalling; ISO 15118, DIN SPEC 70121 or applicable regional protocols
Establish and manage the vehicle charging process
Charger to management system
OCPP or a platform-specific protocol
Authorization, transactions, monitoring and remote commands
Charger to local controller
Local OCPP, Modbus, EEBUS or a manufacturer interface
Exchange charging limits and operating feedback
Meter to controller
Modbus or a supported meter interface
Measure site and circuit demand
Platform to platform
OCPI and other roaming interfaces
Exchange authorization, session and charging-service information

For example, OCPI operates between charging service platforms. Its presence does not establish how an individual charger receives a local power limit. Vehicle communication also requires its own compatibility checks; support for OCPP does not determine which vehicles or vehicle communication features a charger supports.

Ethernet, Wi-Fi, cellular communication and RS485 describe connectivity rather than the complete control interface. Two devices can share a network and still use different commands, data formats and access permissions.

Choose OCPP by the functions the project needs

The Open Charge Point Protocol defines communication between charging stations and a charging station management system, or CSMS. The Open Charge Alliance reports that OCPP 1.6 remains widely used while adoption moves toward OCPP 2.x.

OCPP 1.6 already includes Smart Charging mechanisms for charging profiles and load control. OCPP 2.0.1 adds stronger device management, transaction handling, security and smart charging capabilities, including support related to ISO 15118. OCPP 2.1, released in 2025, extends support for bidirectional charging and distributed energy resource control.

OCPP 1.6J

Established deployments; verify the functions required by your project.

OCPP 2.0.1

Device management, security and smart charging capabilities.

OCPP 2.1

Bidirectional charging and distributed energy resource control.

OCPP 1.6 and 2.0.1 are not directly compatible. A platform serving both needs the appropriate protocol implementations. If a supplier offers a future upgrade, confirm the supported hardware, delivery conditions and required platform changes.

For new commercial sites, OCPP 2.0.1 is a useful starting point for evaluation. A verified 1.6J implementation, using JSON over WebSocket, can also meet a defined project's requirements. Projects considering bidirectional charging should assess OCPP 2.1 alongside vehicle communication, power hardware and the applicable grid requirements.

The certification scope matters as much as the version. Under the OCPP 2.0.1 certification programme, Smart Charging, Advanced Security and ISO 15118 Support are optional profiles. A Core certificate alone does not establish that those functions have been tested. Request the certificate and implementation statement covering the delivered model and firmware.

Review certification scope →

Define dynamic load management as a complete control loop

Dynamic load management adjusts the charging allocation as other site loads change. It needs measurements, an allocation algorithm, a command path and feedback confirming the result.

Consider a simplified site with a 300 kW import limit and a 20 kW operating margin. When non-charging demand is 180 kW, the available charging allocation is 100 kW. If that demand rises to 240 kW, the allocation falls to 40 kW.

SIMPLIFIED SITE ALLOCATION

180 kW other demand

300 − 20 − 180

100 kW available

240 kW other demand

300 − 20 − 240

40 kW available

300 kW import limit · 20 kW operating margin · AC-side active power · No on-site generation or storage

This example uses AC-side active power and assumes no on-site generation or storage. An actual design must also check phase currents, branch limits and transformer constraints. DC charger input includes conversion losses and auxiliary consumption. Where solar or storage is present, the metering boundary must be clear so that energy flows are not counted twice.

The controller decides how to distribute the available capacity. Equal sharing, vehicle priority and departure-time scheduling require different operating logic. The communication protocol carries that decision to the chargers; it does not, by itself, supply the allocation algorithm.

Confirm the full response time from measurement to actual power adjustment. Meter sampling, network delay, controller processing and charger or vehicle response all contribute. A successful command acknowledgement is insufficient evidence that the requested limit has taken effect. Load management must also be coordinated with the site's electrical protection design.

Check what the local interface actually allows

A charger may offer separate interfaces for its management platform and its local energy management system (EMS). Phoenix Contact describes an arrangement using OCPP for backend communication and Modbus TCP for dynamic current allocation from a building management system.

Modbus is a practical option for industrial integration, but the register map still needs review. Check whether the interface exposes writable charging limits, their units and permitted range, the control level, and the timeout behaviour. Reading a Modbus electricity meter and accepting commands from an external Modbus controller are different capabilities.

EEBUS provides energy-management use cases such as power limitation and solar self-consumption optimization. Its suitability depends on the use cases and versions implemented by both devices. A general EEBUS claim should be followed by a specific compatibility review.

Manufacturer APIs and proprietary protocols can also support effective local control. Their usefulness depends on accessible documentation, implementation rights, available functions and stable support. Ask whether local commands remain available without a cloud subscription and whether firmware changes can alter the interface.

Firmware deserves particular attention. For example, Alfen's AHP 2.6.0 release notes introduced Modbus TCP/IP EMS control for specified products and documented a single simultaneous EMS connection. The same notes specify matching software requirements within a Smart Charging Network. Compatibility should therefore be recorded by model and firmware, including for equipment from one brand.

Backend connectivity does not automatically establish local control compatibility.

Select an architecture with clear control ownership

OCPP can operate on a local network. The OCA's local-controller architecture describes a controller positioned between chargers and the upstream management system. This creates several options for station design.

Architecture
Where charging allocation runs
Key planning consideration
Cloud control
Remote management platform
Define local limits and fallback behaviour during network loss
Local OCPP controller
On-site controller connected to chargers and the upstream platform
Verify command handling, transaction continuity and controller recovery
OCPP plus a separate local interface
Site controller or EMS, alongside the operational backend
Establish priority between local and remote commands
Manufacturer charger network
Main charger or manufacturer controller
Check supported models, group capacity and expansion restrictions

For capacity-constrained commercial sites, local control is often a sensible engineering choice because the measurement and control path can continue without a working internet connection. That benefit must be verified in the selected implementation.

Where several systems can set limits, document their authority. A site capacity limit, an operator schedule and an internal charger limit may all be active. Define how they are combined, how long each remains valid and how obsolete commands are removed.

This is a documented integration issue. KEBA's connectivity guidance warns that external control can interfere with the built-in load management of certain master-client configurations. Multiple supported interfaces do not establish that every combination of controllers is supported.

Assess the effect on construction and lifetime cost

Protocol decisions influence the equipment list and communication infrastructure. Local control may require additional meters, a site controller, network switches, communication cabling and commissioning access. Include these items before comparing charger quotations.

Dynamic management can improve the use of an existing supply, but it cannot create additional capacity. Whether it avoids an electrical upgrade depends on demand, simultaneous charging needs and acceptable waiting times. Vehicle charging performance must remain part of the design assessment.

For expansion, establish whether new chargers can join the existing control system individually or only through another manufacturer's group controller. Check whether mixed AC and DC equipment can be controlled at the required level and whether one failed device affects the rest of the group.

For platform replacement, confirm ownership of server configuration, credentials and certificates. Clarify access to transaction exports and whether essential local control depends on a continuing subscription. Include interface licences, integration work, firmware maintenance and regression testing in the operating cost estimate.

Security is also an operational requirement. Specify device identity, encrypted communication where supported, certificate renewal and update responsibilities. The OCA Security Operations Guide provides implementation guidance. Local interfaces should be protected through appropriate network access controls; being on a local network does not remove the need to manage access.

Turn protocol claims into acceptance requirements

Before ordering equipment, ask the charger and controller suppliers to confirm the proposed configuration together. A useful technical submission should contain:

✓

Exact charger model, firmware version and applicable OCPP certificate scope.

✓

Local interface documentation, access conditions and required licences.

✓

Supported current or power limits, units, adjustment range and control granularity.

✓

Meter compatibility, measurement location, data freshness and end-to-end response requirements.

✓

Priority rules when the backend, local controller and charger management functions operate together.

✓

Communication timeout, fallback, restart and reconnection behaviour.

✓

Platform migration arrangements and the supported upgrade process.

Commissioning should test a sudden increase in building demand, simultaneous charging, internet loss, meter communication failure, controller restart and conflicting control requests. Measure the resulting current or power, record the response time and confirm recovery without unintended charging increases.

Treat continued charging, authorization of new sessions and transaction recovery as separate offline requirements. A system may support one without supporting the others. For sites with different charger brands, run the tests on the complete proposed combination before wider deployment.

Connect the selected chargers to the site control system

An existing load balancing controller may already provide the required allocation logic while the chosen chargers expose different command formats and feedback data. In that situation, a charger-specific integration layer can connect the controller's requirements to the functions available on each selected device.

SINELINK's Multi Brand EV Charger Control Integration Solution focuses on this connection. Each integration is assessed against the charger model and firmware, available protocol documentation, customer-side interface and required behaviour. Share those details with SINELINK to discuss the development scope and validation needed for your charging station.

RELATED SOLUTION

Connect your controller to compatible chargers

Explore charger-specific command and feedback integration for your selected hardware and site requirements.

Explore the integration solution   →

Multi Brand EV Charger Control Integration Solution

SINELINK

Solar · Storage · EV Charging

© 2026 SINELINK. All rights reserved.

Contact