An EV charging station is not much use on its own. It needs to authorize drivers, report faults, meter energy for billing, and take instructions from an operator who may be nowhere near it. OCPP, the Open Charge Point Protocol, is the open standard that connects charging stations to the central system that manages them, so that any compliant charger can talk to any compliant backend regardless of who made it. This page introduces what OCPP does, what the widely deployed OCPP 1.6J carries compared to the newer 2.0.1, and how a site-monitoring platform ingests OCPP telemetry to track charger uptime, faults, and energy delivered.
OCPP in one line: OCPP, the Open Charge Point Protocol, is an open, vendor-neutral communication standard that links EV charging stations, known as EVSE, to a central charge point management system. Over OCPP the charger reports its status, meter readings, and faults, while the backend can authorize sessions, remotely start and stop charging, push firmware, and set charging profiles. Because it is open, an operator can mix chargers from different manufacturers behind one management system, and a monitoring platform can ingest the same OCPP messages to track uptime, faults, and energy delivered.
OCPP defines the conversation between two parties: the charging station, formally the electric vehicle supply equipment or EVSE, and the central system that manages a fleet of them, usually called a charge point management system or CPMS. The charger initiates a persistent connection to the backend and then the two exchange messages in both directions. The charger sends events such as a driver plugging in, a session starting, periodic meter readings, and fault notifications, while the backend sends commands such as authorizing a card, starting or stopping a session remotely, changing a configuration, or pushing new firmware. This two-way exchange is what turns a standalone charger into a managed asset in a network.
The value of OCPP being an open standard is that it breaks the tie between the hardware and the software. Before open protocols, an operator who bought chargers from one vendor was often locked into that vendor's backend, and adding a different brand of charger meant running a second system. Because OCPP is a published, vendor-neutral standard, a compliant charger from one manufacturer can be managed by a compliant backend from another, so operators can choose hardware and management software independently and mix brands across a network. That interoperability is the entire point of the protocol and the reason it has become the common language of the charging industry.
The connection itself is typically made over the internet using WebSockets, with the charger acting as the client that dials into the backend. This matters for how the messages flow, because the persistent connection lets the backend push a command to a charger at any time and lets the charger report an event the instant it happens rather than waiting to be polled. It also means the health of that connection is itself meaningful: a charger whose OCPP connection has dropped is effectively invisible to its operator and cannot be controlled, which is why connection state is one of the first things any monitoring of an OCPP network watches.
The version of OCPP that most deployed chargers speak is 1.6, and specifically the JSON-over-WebSocket variant usually written as 1.6J. OCPP 1.6 covers the core of what a network needs: the charger reports its connector status through a set of defined states, sends meter values for energy and other measurands, notifies the backend of faults, and starts and stops transactions, while the backend authorizes tags, triggers remote start and stop, changes configuration keys, and manages firmware updates. It also includes smart charging in the form of charging profiles, which let the backend limit how much power a charger or connector may draw. For a large share of the installed base, 1.6J is the working standard.
OCPP 2.0.1 is the newer generation and expands the protocol in several directions rather than merely adding messages. It restructures the device model so the backend has a much richer picture of the charger's components and variables, improves the handling of transactions and metering, and adds more capable smart charging. It also brings stronger security provisions, including a defined approach to secure the connection and manage certificates, and improved firmware and diagnostics handling. For operators dealing with complex sites, plug-and-charge style authorization, and tighter security expectations, 2.0.1 provides capabilities that 1.6 does not.
In practice a network often spans both versions, because chargers have long service lives and the installed base migrates gradually. A management system and a monitoring layer therefore usually have to speak both 1.6 and 2.0.1 and normalize the differences so that a station's status, faults, and energy look consistent regardless of which version it uses. The choice between versions for new hardware weighs the richer device model and security of 2.0.1 against the maturity and broad support of 1.6, but from a monitoring standpoint the important thing is that both carry the same essential facts, connector status, meter values, and faults, that an operator needs to run the site.
Everything an operator wants to know about a charging site is already flowing over OCPP, which makes the protocol a natural source for a monitoring platform. The connector status notifications tell you whether each connector is available, occupied, charging, or faulted. The meter values tell you energy delivered and often power, voltage, and current during a session. The fault and error notifications tell you when a charger reports a problem, and the transaction messages let you reconstruct each session from plug-in to unplug. A platform that ingests this stream can present the live state of every charger and connector in a network from one place, without needing any additional sensors on the hardware.
The most operationally important thing this telemetry reveals is reliability. By watching connection state and status notifications, a monitoring platform can tell which chargers are online, which have gone silent, and which are sitting in a faulted state that blocks a driver from charging. By reading meter values it can confirm that a session that started actually delivered energy rather than stalling, and by tracking faults over time it can surface a charger that repeatedly errors even if it recovers each time. These are the signals behind uptime and session-success metrics, and they come directly from the OCPP messages the charger is already sending.
A cloud SCADA and site-monitoring platform such as Merobix can act as, or sit alongside, the OCPP backend for exactly this purpose, ingesting the protocol's telemetry to give an operator uptime, fault, and energy visibility across a mixed fleet of chargers and, where the same site has other equipment, alongside it. Because OCPP is open and normalized, the platform can treat chargers from different vendors uniformly, alert on a station that has dropped its connection or is stuck faulted, and keep the historical record of energy delivered and downtime that both operations and reporting depend on. The protocol carries the facts, and the platform turns them into the live status, alarms, and history an operator uses to run the network.
OCPP is the open protocol that connects charging stations to the central system that manages them. Over it, a charger reports connector status, meter values, and faults, while the backend authorizes drivers, remotely starts and stops sessions, changes configuration, and pushes firmware. Because it is a vendor-neutral standard, an operator can manage chargers from different manufacturers behind one management system rather than being locked to a single vendor's hardware and software.
OCPP 1.6, usually the 1.6J JSON variant, is the widely deployed version and covers status, meter values, faults, transactions, remote start and stop, firmware, and smart charging profiles. OCPP 2.0.1 is the newer generation with a richer device model, improved metering and smart charging, stronger security and certificate handling, and better diagnostics. Networks often span both versions because chargers have long lives, so management and monitoring systems typically speak both and normalize the differences.
Yes. The status notifications, meter values, fault messages, and transaction events an operator needs are already flowing over OCPP, so a platform that ingests that stream can show the live state of every charger and connector without extra sensors. From those messages it can derive uptime, detect chargers that have gone silent or are stuck faulted, confirm that sessions delivered energy, and keep the historical record of energy and downtime, treating chargers from different vendors uniformly because the protocol is open.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.