Building OCPP tracing on top of OpenTelemetry

[xBlaz3kx]

This project got me thinking if there is a non-invasive way to instrument OCPP exchange, that would be generic enough for each use case and with minimal effort. I think its worth considering a convention on top of OpenTelemetry.

Why building a convention on top of OpenTelemetry might be a better choice:

1. Plug and play solution - can plug into OpenTelemetry-compatible backend to reconstruct messages with full context
2. Doesn't need dedicated SDKs, can simply be a convention vendors should follow
3. Would integrate nicely in existing vendor flows (if they already support OpenTelemetry)

Traces in OTel are emitted via HTTP headers (trace id, span parent id and current span id - multiple possible formats).

How I would implement it (two possible ways):

• For OCPP 1.6-J / Legacy: Use the WS handshake headers to trace the connection session, and rely on standard OCPP identifiers (connectorId, transactionId, messageId) extracted at the proxy/CSMS boundary to reconstruct spans.
• Via customData JSON field (constrained to OCPP 2.0.1 and above)

Proposed OTel attributes:

rpc.system: "ocpp"
rpc.service: "CSMS" or "ChargePoint"
rpc.method: Action name (e.g., "BootNotification", "Authorize", "TransactionEvent")
rpc.ocpp.charge_point_id: "{CP_ID}"
rpc.ocpp.protocol_version: "1.6J" or "2.0.1"
rpc.ocpp.message_type: 2 (Call), 3 (CallResult), or 4 (CallError)
rpc.ocpp.transaction_id: Standardized string representation of the transaction identifier.
rpc.ocpp.connector_id: Optional integer specifying the EVSE/connector port.

[xBlaz3kx]

cc @juherr