Charge Point Controller vs Charge Point Management System

A charge point controller is the embedded control board inside the charging station; a charge point management system (CPMS) is the server software that operates a fleet of stations. They are two separate products, bought from two different kinds of supplier, and connected to each other by OCPP. The Open Charge Point Protocol specification, published by the Open Charge Alliance, names these two endpoints the Charging Station and the Charging Station Management System (CSMS); "CPMS" is the commercial term for the same server role.

Which side does what

The split is not a matter of vendor preference. A function belongs to the controller when it requires physical measurement, physical switching, or a response time shorter than a backend round trip. It belongs to the management system when it requires knowledge of users, money or other stations.

Station side

Charge point controller

  • IEC 61851-1 control pilot signalling and state machine; contactor switching and welded-contact detection
  • Energy measurement; residual current detection (an RDC-DD to IEC 62955 removes the need for an external Type B RCD in the installation)
  • Local authorisation: RFID read, local whitelist, offline authorisation cache
  • OCPP client; ISO 15118 communication stack where Plug and Charge is required
  • Enforcement of the stored charging profile, including when the backend link is down
  • Firmware, diagnostics, temperature and fault handling
See eectec controller boards →
Server side

Charge point management system

  • User accounts, RFID token database, remote authorisation decisions
  • Tariffs, billing, invoicing, and roaming between networks (typically over OCPI)
  • Fleet-level smart charging: issuing charging profiles to stations, site load management across multiple stations
  • Remote start and stop, reservations, remote diagnostics and firmware campaigns
  • Reporting, uptime statistics and the data feeds national access points expect
Related questions in our FAQ →

Four functions that cannot be moved into software

This is the practical reason the distinction matters during procurement. Each of the following is decided when the controller is selected, and no management system can add it afterwards.

  • The OCPP version the station speaks. OCPP 1.6 and OCPP 2.0.1 are not interoperable: a station running 1.6 cannot talk natively to a 2.0.1-only backend, and the reverse is also true. OCPP 2.0.1 introduces a hierarchical device model — Charging Station, EVSE, connector — and three security profiles, none of which a 1.6 station can present. Moving between versions is a firmware and, in some designs, a hardware question on the station side — see OCPP 1.6 vs 2.0.1 vs 2.1 on the hardware side for what each version costs on the board.
  • ISO 15118 Plug and Charge. Certificate handling and the high-level communication stack run on the station. If the controller has no ISO 15118 stack and no PLC modem on the control pilot line, Plug and Charge is not available regardless of backend support — see ISO 15118 for charger manufacturers for what the standard demands of the hardware.
  • Protective functions. Residual current detection, welded-contact detection and over-temperature shutdown must act in milliseconds, locally. They are type-tested as part of the product, not configured in a backend.
  • Metering accuracy and its legal status. Billing accuracy is a property of the meter and its integration in the station. Where national metrology law applies to the transaction, the conformity applies to the hardware, not to the software that reads it.

Where grid-side obligations are actually executed

Charging profiles in OCPP are transmitted to the charging station and stored there, which means the controller continues to enforce the last valid current limit after the connection to the backend drops. The consequence for procurement is specific: an obligation that requires a guaranteed limit — a network operator's control command in Germany under §14a EnWG, a site connection limit, or a dynamic tariff schedule — is issued by the backend but executed by the controller. If the controller cannot receive, store and apply the limit locally, the obligation is not met when the link fails, which is exactly when it matters.

The same logic applies to payment. Regulation (EU) 2023/1804 (AFIR) Article 5 requires operators of newly deployed publicly accessible recharging points to accept ad hoc electronic payment: below 50 kW, a payment card reader, a contactless device that can at least read payment cards, or a QR code; at 50 kW and above, a payment card reader or a contactless device that can read payment cards. The reader is hardware, wired to and powered by the station; the settlement is a backend function. Specifying one without the other leaves a product that cannot be deployed by an operator subject to the regulation. The Commission's questions and answers on the regulation set out the obligation in full.

How the two are procured

A brand owner buys the controller, or a complete charger built around it, from a hardware manufacturer or ODM. It subscribes to a management system from a software vendor, or operates its own. Because OCPP sits between them, the two decisions are independent, provided the OCPP version and the feature profiles match on both sides.

  • Check version alignment first. Agree the OCPP version, the feature profiles and the security profile with both suppliers before either contract is signed. This single check prevents the most common integration failure.
  • Ask the hardware supplier for its protocol status in writing. A shipping version is not the same as a roadmap version, and neither is the same as a certificate issued by a third party.
  • Decide who owns the certification file. The party that places the charger on the EU market under its own name or trademark carries the manufacturer's obligations, including CE marking — see ODM vs OEM vs white label for what that means in each sourcing model.

Where eectec sits in this split

eectec builds the station side and does not sell a management system. We design and manufacture AC and DC charging controller boards and complete chargers for brand owners, and our boards are used by more than 1,500 charger builders, with over 1,000,000 AC and DC boards delivered to date and a rolling 12-month hardware failure rate of 880 PPM. Our charging platform runs OCPP 1.6 in large-scale commercial operation, with OCPP 2.0.1 support in final development — first delivery scheduled for December 2026. We hold no Open Charge Alliance certificate for either version; where a tender requires one, that should be established before design work starts.

Because we do not sell the backend, an eectec-based charger connects to the management system the brand owner has already chosen. Typical development time on an existing platform is 3 months for an AC controller and 4 months for a DC controller, with a serial production lead time of 45 days.

If the split above is settled and the next step is writing the requirement down, the fifteen questions a controller specification has to answer sets out what to ask, what a checkable answer looks like, and which four answers should stop a selection.

Ask a specific integration question → Controller specifications

Questions we are asked about this

What is the difference between a charge point controller and a charge point management system?

A charge point controller is the embedded control board inside the charging station: it runs the IEC 61851-1 control pilot, switches the contactor, reads the meter, authenticates the user locally and acts as the OCPP client. A charge point management system (CPMS) is server software that talks to many charging stations over OCPP and handles user accounts, tariffs, billing, roaming and reporting. The OCPP specification calls these two endpoints the Charging Station and the Charging Station Management System (CSMS); CPMS is the commercial term for the same server role.

Can a charge point management system add functions the controller does not have?

No. Anything that requires physical measurement, switching or a protocol stack running on the station must exist in the controller. ISO 15118 Plug and Charge, residual current detection, contactor welding detection, metering accuracy and the OCPP version supported are all controller-side properties. A management system can schedule, price and report, but it cannot add a capability the hardware does not have.

Which one does a charging brand buy, and from whom?

A brand owner sources the controller — or a complete charger built around it — from a hardware manufacturer or ODM, and separately subscribes to a management system from a software vendor, or operates its own. The two are connected by OCPP, so they can be procured independently as long as the OCPP version and profiles match. eectec supplies the station side only and does not sell a management system.

What happens to smart charging when the charger loses its connection to the management system?

Under OCPP, charging profiles are sent to the charging station and stored there, so the controller keeps enforcing the last valid current limit when the backend link drops. This is why grid-side obligations that require a guaranteed current limit are executed in the controller rather than in the management system, even when the command originates in the backend.

Does the management system handle AFIR payment requirements?

Only partly. Regulation (EU) 2023/1804 (AFIR) Article 5 obliges operators of newly deployed publicly accessible recharging points to accept ad hoc electronic payment: below 50 kW a payment card reader, a contactless device able to read payment cards, or a QR code; at 50 kW and above a payment card reader or a contactless device able to read payment cards. The reader is hardware wired to the controller; the payment transaction is settled by the backend. Both sides have to be specified together.

Can a management system add functions the controller does not have?

No. Anything that requires physical measurement, physical switching or a protocol stack running on the station must exist in the controller. ISO 15118 Plug and Charge, residual current detection, contactor welding detection, metering accuracy and the OCPP version supported are all controller-side properties. A management system can schedule, price and report; it cannot add a capability the hardware does not have.

Is a controller the same thing as an EVSE?

No. In the OCPP 2.0.1 device model, a Charging Station contains one or more EVSEs, and each EVSE contains one or more connectors. The controller is the electronics that implement that station: a single controller board commonly drives more than one EVSE. When a specification says "per EVSE", it is describing an energy delivery path, not a circuit board.

Do we need a management system at all for private or workplace charging?

Not in every case. A controller with local authorisation and a stored charging profile can operate without a backend connection. A management system becomes necessary when charging has to be billed to identified users, reimbursed, roamed to other networks, or reported. The technical question to settle first is whether the controller can authorise and limit current offline, because that determines what happens on the days the connection is unavailable.

If we change management system later, do we replace the chargers?

Not if the OCPP version and profiles are common to both backends, since OCPP is the interface between them. Migration effort concentrates in two places: the security profile, because certificates and credentials are provisioned per station, and any vendor-specific data the previous backend relied on. Confirm both before signing, and confirm that the controller supports remote reconfiguration of its backend endpoint.

What does an upgrade from OCPP 1.6 to 2.0.1 involve on an installed charger?

It is a station-side project, not a backend setting. The station needs firmware implementing the 2.0.1 device model and security profiles, sufficient memory and processing headroom to run it, and a provisioning path for certificates. On eectec platforms, OCPP 1.6 is what runs in large-scale commercial operation today, and OCPP 2.0.1 is in final development with first delivery scheduled for December 2026; on some installed products the route is an added communication module rather than a firmware update alone.

Specifying a charger against a backend you already run?

Send us the requirement →