OCPP 1.6 Protocol Architecture and JSON Implementation Guide
Documentation Set Overview
The authoritative specification corresponds to the December 2019 release package. This suite comprises several key components:
- Core Protocol: Defines Open Charge Point Protocol 1.6 standards.
- Errata Sheets: Updates for both JSON and SOAP specifications.
- Specifications: Separate documents for OCPP-J (JSON) and OCPP-S (SOAP).
- Schemas: Describes message structures for both implementations.
While all versions exist, this documentation focuses on the JSON variant due to its prevalence in modern deployments.
Transport Layer Configuration
Connectivity relies on WebSocket channels established over TCP sockets. In this topology, the Charging Station acts as the initiating client, while the Central Management System functions as the listening server.
Endpoint URIs typically follow a unique identifier pattern:
wss://manager.grid-network.io/v1/charger/A042
Handshake Sequence
Client Request
GET /v1/charger/A042 HTTP/1.1
Host: manager.grid-network.io:33033
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: MzQxNDUyNTY3OA==
Sec-WebSocket-Version: 13
Server Response
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: kD8rP4sT6fH2jL9mN0vB5xQ=
Sec-WebSocket-Protocol: ocpp1.6
Keepalive Settings
Connection stability is monitored using WebSocket PING/PONG frames. Configuration parameters allow disabling this feature or setting the interval duration in seconds.
| Configuration Key | Valid Range | Behavior |
|---|---|---|
WebSocketPingInterval |
0 | Disables Client Ping |
WebSocketPingInterval |
> 0 | Sets Interval (Seconds) |
Message Flow Logic
Transactions rely on three state identifiers mapped to numeric types:
- CALL (2): Initiated request sent by either party.
- CALLRESULT (3): Successful outcome returned by receiver.
- CALLERROR (4): Failure report sent back to initiator.
Strict sequnecing dictates that responses must complete before new calls are issued on the same session. All payloads utilize UTF-8 encoding.
Message IDs must be unique per connection for outgoing calls. Responses must echo the ID of the corresponding request exactly.
Format Structures
- Call:
[2, "<UUID>", "<ActionName>", {Payload}] - Result:
[3, "<UUID>", {Payload}] - Error:
[4, "<UUID>", "<ErrorCode>", "<Description>", {Details}]
Error Classifications
Failures are categorized into distinct error codes managed by the system.
| Error Code | Definition |
|---|---|
NotImplemented |
Action is unrecognized by receiver |
NotSupported |
Action known but currently unsupported |
InternalError |
Processing failure within receiver component |
ProtocolError |
Payload structure is incomplete |
SecurityError |
Authentication or safety violation occurred |
FormationViolation |
Syntax mismatch or invalid structure |
PropertyConstraintViolation |
Field contains invalid data value |
OccurenceConstraintViolation |
Violation of field occurrence rules |
TypeConstraintViolation |
Data type does not match schema |
GenericError |
Exception not covered by specific codes |