OCPP 1.6 Integration Guide: WebSocket, JSON Messages and Java Implementation

A Practical Guide to Connecting EV Charging Stations with a Central Management System Using OCPP 1.6J

Introduction

As electric vehicle charging infrastructure continues to expand, charging station manufacturers and charging network operators require reliable communication between charging equipment and centralized management platforms.

The Open Charge Point Protocol (OCPP) provides a standardized communication interface between EV charging stations and backend management systems.

Developed and maintained by the Open Charge Alliance (OCA), OCPP enables charging stations and central systems from different manufacturers to exchange operational data and execute supported remote management functions.

OCPP 1.6 is widely implemented in commercial charging infrastructure and includes functionality for device registration, remote transaction control, meter data reporting, configuration management, firmware updates, and smart charging.

This technical guide explains how to implement OCPP 1.6J integration, focusing on JSON over WebSocket, essential protocol messages, Java-based software architecture, testing, and practical charging management applications.

1. What Is OCPP 1.6?

OCPP stands for Open Charge Point Protocol.

It defines communication between an EV charging station, traditionally called a Charge Point, and a backend management platform, called a Central System in OCPP 1.6.

A Central System may form part of a broader Charging Station Management System (CSMS).

OCPP 1.6 supports two communication bindings:

• OCPP 1.6 SOAP: Uses SOAP/XML-based messaging.
• OCPP 1.6J: Uses JSON messages transported over WebSocket.

This article focuses on OCPP 1.6J, a commonly used implementation for modern EV charging projects.

1.1 Main Features of OCPP 1.6

OCPP 1.6 provides functionality including:

Charge Point Registration

Allows a charging station to identify itself to the Central System using BootNotification.

Remote Transaction Management

Supports remote charging requests through actions such as RemoteStartTransaction and RemoteStopTransaction.

Charging Status Monitoring

Uses StatusNotification to report connector status and operational conditions.

Meter Data Reporting

Uses MeterValues to communicate electrical measurements and energy consumption data.

Configuration Management

Supports reading and modifying relevant charging station configuration keys.

Firmware Management

Includes messages for initiating firmware download and reporting firmware update status.

Smart Charging

Supports charging profiles and charging schedules for suitable load management applications.

The specific functions available in a charging station depend on its firmware, supported OCPP profiles, and hardware capabilities.

2. Preparing the OCPP 1.6 Integration Environment

Before connecting an EV charging station to a Central System, both hardware and software requirements should be verified.

2.1 Hardware Requirements

The charging equipment should provide:

• A main controller or gateway supporting OCPP 1.6
• A suitable network interface, such as Ethernet or cellular connectivity
• Access to connector status and charging control information
• Relevant electrical metering data
• Appropriate storage for configuration and transaction information
• A reliable firmware update mechanism, if firmware management is required

For DC charging stations, the OCPP function typically operates within the main charger controller or an associated communication gateway.

The SECC manages vehicle-to-charger high-level communication, while the OCPP implementation manages communication between the charging station and backend system.

These communication functions serve different purposes.

2.2 Software Requirements

A typical OCPP 1.6J integration requires:

• A WebSocket client on the Charge Point side
• A WebSocket server on the Central System side
• OCPP JSON message encoding and decoding
• Message validation against the relevant OCPP schemas
• Transaction and connector state management
• Persistent configuration and transaction storage where necessary
• Logging, error handling, and reconnection mechanisms

2.3 Network and Security Configuration

For production deployments, encrypted WebSocket communication using wss:// is strongly recommended.

Appropriate authentication, certificate validation, and credential management should also be implemented according to the selected security architecture.

Security requirements should be evaluated using the relevant OCPP 1.6 Security Whitepaper and the operator’s deployment requirements.

3. Establishing the OCPP 1.6 WebSocket Connection

The first step is to establish communication between the Charge Point and the Central System.

In OCPP 1.6J, the charging station normally initiates the WebSocket connection to the Central System.

3.1 WebSocket Endpoint

An illustrative connection endpoint is:

wss://csms.example.com/ocpp/CP001

Here:

• wss:// indicates WebSocket over TLS.
• csms.example.com represents the management server.
• /ocpp/ is an example server route.
• CP001 identifies the charging station.

The actual endpoint structure depends on the backend system.

3.2 WebSocket Subprotocol

During the WebSocket handshake, the client identifies the required OCPP subprotocol:

Sec-WebSocket-Protocol: ocpp1.6

The server must negotiate the supported protocol correctly.

A successful TCP connection alone does not establish a valid OCPP 1.6J session.

3.3 OCPP 1.6 JSON Message Structure

OCPP 1.6J uses three main message types.

CALL — Request

[2, "unique-id", "ActionName", {"parameter": "value"}]

CALLRESULT — Successful Response

[3, "unique-id", {"result": "value"}]

CALLERROR — Error Response

[4, "unique-id", "ErrorCode", "Description", {}]

The unique message identifier associates a request with its corresponding response.

Both the Charge Point and Central System can initiate supported CALL messages.

4. BootNotification: Registering a Charging Station

After establishing the WebSocket connection, a Charge Point sends BootNotification to inform the Central System that the device has started or restarted.

This message communicates information such as the manufacturer and model.

4.1 BootNotification Request

An illustrative OCPP 1.6J message is:

[2, "boot-001", "BootNotification", {
  "chargePointVendor": "Share Charging",
  "chargePointModel": "DC Charger"
}]

The Central System checks whether the charging station is recognized and permitted to operate.

4.2 BootNotification Response

A successful response may look like:

[3, "boot-001", {
  "status": "Accepted",
  "currentTime": "2026-10-16T09:00:00Z",
  "interval": 300
}]

The response includes:

• status: Registration result
• currentTime: Central System time
• interval: Heartbeat interval in seconds

Possible registration statuses include Accepted, Pending, and Rejected.

The Charge Point must respond appropriately to each status according to the protocol requirements.

Original Figure 1 — BootNotification JSON example.

5. Authorize: Verifying Charging Authorization

Charging authorization determines whether an identifier can be used to initiate an authorized charging transaction.

Depending on the system architecture, authorization may involve RFID identification, remote authorization, local authorization lists, or other supported mechanisms.

5.1 Authorize Request

An illustrative request is:

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

The idTag identifies the authorization credential.

5.2 Authorize Response

The Central System may respond:

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

The response communicates the authorization result.

An Authorize message is not necessarily sent immediately after inserting a charging connector. Its use depends on the implemented authorization flow.

Original Figure 2 — Authorize JSON example.

6. StartTransaction: Starting a Charging Transaction

OCPP 1.6 uses StartTransaction to establish a transaction record with the Central System.

The message includes information such as the connector, authorization identifier, initial meter reading, and transaction timestamp.

6.1 StartTransaction Request

[2, "start-001", "StartTransaction", {
  "connectorId": 1,
  "idTag": "RFID123456",
  "meterStart": 0,
  "timestamp": "2026-10-16T09:05:00Z"
}]

6.2 StartTransaction Response

[3, "start-001", {
  "transactionId": 10001,
  "idTagInfo": {
    "status": "Accepted"
  }
}]

The Central System assigns a transaction identifier.

This identifier is used in subsequent transaction-related communication.

StartTransaction is part of transaction management; physical energy delivery is controlled by the charging equipment and relevant safety systems.

Original Figure 3 — StartTransaction JSON example.

7. MeterValues: Reporting Charging Data

MeterValues allows the Charge Point to send electrical measurement data to the Central System.

Depending on the configuration, reported values can include:

• Accumulated electrical energy
• Voltage
• Current
• Power
• Other supported meter measurements

7.1 MeterValues Request

The following example reports an accumulated energy reading.

[2, "meter-001", "MeterValues", {
  "connectorId": 1,
  "transactionId": 10001,
  "meterValue": [
    {
      "timestamp": "2026-10-16T09:10:00Z",
      "sampledValue": [
        {
          "value": "1250",
          "measurand": "Energy.Active.Import.Register",
          "unit": "Wh"
        }
      ]
    }
  ]
}]

7.2 MeterValues Response

[3, "meter-001", {}]

The Central System acknowledges the message.

7.3 Meter Data Integration

Reliable metering integration requires the charging station software to correctly map physical meter readings to OCPP measurands and units.

Engineers should also verify:

• Measurement accuracy
• Meter communication stability
• Sampling configuration
• Timestamp synchronization
• Transaction-to-meter data association

For commercial charging systems, the applicable legal metrology and billing requirements must be evaluated separately.

Original Figure 4 — MeterValues JSON example.

8. Heartbeat and StatusNotification

In addition to transaction-related messages, OCPP uses periodic and event-driven messages to monitor charging equipment.

8.1 Heartbeat

The Charge Point initiates Heartbeat requests at the relevant configured interval.

Example request:

[2, "heartbeat-001", "Heartbeat", {}]

The Central System responds with its current time:

[3, "heartbeat-001", {"currentTime": "2026-10-16T09:15:00Z"}]

Heartbeat helps support basic communication monitoring and time synchronization.

8.2 StatusNotification

StatusNotification reports changes in connector state.

OCPP 1.6 connector statuses include values such as:

• Available
• Preparing
• Charging
• SuspendedEV
• SuspendedEVSE
• Finishing
• Reserved
• Unavailable
• Faulted

Correct status reporting is important for customer-facing charging applications and backend operations.

9. Remote Management Functions

OCPP 1.6 enables a Central System to send supported management requests to a charging station.

9.1 RemoteStartTransaction

A Central System can request a remote transaction start.

Successful remote start depends on authorization, connector availability, charging station configuration, and other operational conditions.

9.2 RemoteStopTransaction

A Central System can request the termination of an active transaction using its transaction identifier.

9.3 ChangeConfiguration

The Central System can request modifications to supported configuration keys.

Not every configuration value is writable.

9.4 GetConfiguration

GetConfiguration allows the Central System to retrieve supported configuration keys and their available values.

9.5 UpdateFirmware

A Central System can initiate a firmware update using UpdateFirmware.

The request typically supplies a firmware download location and retrieval timing information.

The Charge Point is responsible for downloading and applying the firmware according to its implementation.

FirmwareStatusNotification can be used to report relevant update progress or results.

Remote firmware management must be implemented with suitable security, integrity verification, and recovery mechanisms.

10. Implementing OCPP 1.6J with Java and Spring Boot

A Java-based OCPP implementation can use a Spring Boot backend with WebSocket support and a suitable JSON processing library such as Jackson.

The exact software architecture depends on whether the application implements the Charge Point client or the Central System server.

10.1 Create the Basic Application Structure

A simplified Central System may include:

• WebSocket connection handler
• Charge Point session registry
• OCPP message dispatcher
• Request and response models
• Authorization service
• Transaction management service
• Metering data processing service
• Configuration and firmware management services

Each charging station should be associated with its authenticated identity and active communication session.

Original Figure 5 — Java charging station and Central System class structure.

10.2 Define OCPP Message Models

Incoming WebSocket messages must be interpreted using the OCPP 1.6J message framing format.

For CALL messages, the application should extract:

• Message type
• Unique message identifier
• OCPP action name
• Action payload

The payload must then be validated against the schema associated with that action.

Original Figure 6 — Java message model implementation.

10.3 JSON Serialization and Deserialization

Jackson can be used to parse incoming JSON data into a structured representation.

For example:

ObjectMapper mapper = new ObjectMapper();
JsonNode frame = mapper.readTree(message);
int messageType = frame.get(0).asInt();
String messageId = frame.get(1).asText();

For incoming CALL messages, the action name can be extracted from the next array element.

The example is only an illustration of message parsing, not a complete OCPP implementation.

Production applications also require message validation, connection management, authorization, state handling, and suitable exception processing.

Original Figure 7 — JSON serialization and deserialization with Java.

10.4 Implement Message Handling

After identifying the action, the Central System dispatches the request to the appropriate handler.

For example, a BootNotification handler should:

1. Validate the request payload.
2. Identify the Charge Point.
3. Check the device registration policy.
4. Determine the registration status.
5. Prepare the required BootNotification response.
6. Return a CALLRESULT using the original message identifier.

Handlers for other OCPP actions follow their own schema and business logic requirements.

Original Figure 8 — OCPP message handling implementation.

11. Transaction Management and Billing Integration

OCPP 1.6 provides messages for tracking charging transactions, but it does not itself operate a complete payment system.

A charging management platform may use transaction and metering information for:

• Energy consumption monitoring
• Charging session history
• Customer account management
• Tariff application
• Invoice generation
• Payment processing
• Operational reporting

The implementation of these functions depends on the backend platform.

StopTransaction

When the charging transaction ends, the Charge Point reports relevant termination information through StopTransaction.

This generally includes the transaction identifier, final meter value, and timestamp.

The Central System acknowledges the end of the transaction.

Final billing and payment settlement remain responsibilities of the applicable backend commercial systems.

12. EV Charging App and Management Platform Integration

An OCPP-compatible charging station can form part of a wider software ecosystem.

This may include a driver-facing mobile application and an operator-facing management platform.

12.1 Driver Mobile Application

Depending on the software platform, a mobile application may provide:

• Charging station discovery
• Charging status information
• Session monitoring
• Charging history
• Account management
• Wallet or payment functionality

The mobile application generally communicates with the backend platform rather than exchanging OCPP messages directly with the charging station.

Original Figure 9 — EV charging app home and wallet screens.

12.2 Charging Operations Platform

A Central System or associated platform may provide operational functions such as:

• Charging station monitoring
• Connector availability
• Remote transaction management
• Charging session reporting
• Metering and energy analytics
• Equipment management
• Operational statistics

Original Figure 10 — Charging operations platform dashboard.

12.3 Transaction and Order Management

A commercial charging platform can associate OCPP transaction information with customer charging orders.

The platform may record transaction identifiers, charging duration, energy consumption, and billing information.

Original Figure 11 — Charging order details interface.

The screenshots illustrate potential application interfaces. Specific functionality depends on the actual software product.

13. Common OCPP 1.6 Integration Problems

During practical integration, engineering teams may encounter communication and software issues.

WebSocket Connection Failure

Possible investigation areas include:

• Incorrect server URL
• Network connectivity
• TLS configuration
• Unsupported WebSocket subprotocol
• Authentication failure
• Invalid Charge Point identity

BootNotification Rejected

Check whether the charging station is registered and whether the Central System accepts its identity and configuration.

Transaction Cannot Start

Investigate authorization status, connector state, local charging conditions, transaction handling, and backend responses.

Incorrect MeterValues Data

Check meter interface mapping, units, timestamps, sampled value configuration, and transaction associations.

RemoteStartTransaction Does Not Work

Verify whether the Charge Point supports the request and whether operational conditions allow a remote start.

An accepted remote start request does not necessarily guarantee that physical charging will begin.

Connection Loss During Charging

Implement appropriate reconnection behavior, transaction persistence, and recovery procedures.

Reliable handling of interrupted connections is particularly important for commercial charging systems.

14. Testing and Validation

Before deploying an OCPP 1.6 charging system, engineers should perform structured testing.

Functional Testing

Verify registration, authorization, transaction messages, status updates, and relevant remote functions.

Protocol Validation

Check JSON message structure, required fields, supported actions, and error responses.

Network Testing

Evaluate reconnection, delayed responses, and communication interruption scenarios.

Transaction Recovery Testing

Verify that the charging station maintains appropriate transaction records when network communication fails.

Interoperability Testing

Test integration with the intended charging management platform.

Security Testing

Evaluate connection security, authentication, credential handling, and applicable firmware update mechanisms.

The Open Charge Alliance provides official protocol documents and testing resources that can support compliance and interoperability evaluation.

15. OCPP 1.6 and OCPP 2.0.1: Key Differences

OCPP 2.0.1 introduces significant changes compared with OCPP 1.6.

Manufacturers supporting both protocol versions generally require corresponding software implementations and integration testing.

16. Frequently Asked Questions About OCPP 1.6

What is OCPP 1.6 used for?

OCPP 1.6 enables charging stations and Central Systems to exchange operational messages for device registration, transaction control, metering, monitoring, and supported remote management functions.

What is the difference between OCPP 1.6 and OCPP 1.6J?

OCPP 1.6 refers to the protocol version.

OCPP 1.6J specifically refers to the JSON-over-WebSocket implementation.

Does OCPP 1.6 support smart charging?

Yes. OCPP 1.6 includes smart charging functionality involving charging profiles and schedules.

Actual functionality depends on the supported profile and charging station implementation.

Does OCPP 1.6 require an internet connection?

Communication with a remote Central System normally requires network connectivity.

Local charging behavior during an outage depends on the Charge Point’s configuration and offline capabilities.

Can OCPP 1.6 be implemented using Java?

Yes. Java can be used to develop an OCPP 1.6 Central System or Charge Point application using suitable WebSocket and JSON libraries.

Can OCPP 1.6 support remote firmware updates?

Yes. OCPP 1.6 provides firmware management messages.

The charging station must implement a suitable firmware download, validation, installation, and recovery process.

Is OCPP the same as ISO 15118?

No.

OCPP manages communication between charging equipment and backend systems.

ISO 15118 defines relevant communication between the electric vehicle and charging equipment.

Both technologies may be used within the same EV charging infrastructure.

Does OCPP certification guarantee complete system compatibility?

Certification provides evidence of conformance to the tested protocol requirements and profiles.

Complete interoperability also depends on the specific software functions, backend integration, hardware behavior, and application requirements.

17. Conclusion

OCPP 1.6 integration is an important part of building interoperable and manageable EV charging infrastructure.

By implementing the relevant OCPP 1.6J WebSocket communication procedures, charging station manufacturers can connect their equipment to compatible Central Systems and support essential operational functions.

Successful integration requires more than establishing a network connection.

Engineers must correctly implement protocol messages, authorization workflows, transaction states, meter data reporting, error handling, and communication recovery.

Java and Spring Boot provide one possible software development environment, while appropriate testing tools and OCPP documentation can support implementation and validation.

For EV charging manufacturers, system integrators, and charging network operators, a reliable OCPP implementation provides the foundation for coordinated charging operations and platform connectivity.

OCPP Integration and EV Charging Control Solutions from Share Charging

Share Charging — EV Charging Controllers, Communication Modules and Integration Solutions

Share Charging develops EV charging control and communication solutions for charging equipment manufacturers and engineering companies.

Our technical scope includes:

• AC and DC charging controllers
• OCPP 1.6J and OCPP 2.0.1 integration
• SECC communication modules
• ISO 15118 charging communication
• Charging controller development
• OEM/ODM engineering cooperation
• Charging system integration support

Whether you are developing a new charging station, integrating an existing charger with a management platform, or evaluating OCPP-compatible control hardware, our team can discuss your project requirements.

Explore EV Charging Products

Contact Share Charging

Technical note: OCPP protocol support, optional features, certification status, and platform interoperability depend on the specific charging controller model, firmware version, and system implementation.