EV Charging Protocols and Their Impact on Charging Station Design | SINELINK
Home / Insights / EV Charging
EV CHARGING INSIGHTS
A planning guide to OCPP. Understanding of the communication layers within a charging project
SINELINK | Technical Guide
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.
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.
SINELINK
Solar · Storage · EV Charging
© 2026 SINELINK. All rights reserved.
Contact
