Trace Format

DebugKit accepts three trace formats. All formats use the OCPP 1.6 JSON message structure. It also reads and writes the vendor-neutral Open OCPP Trace interchange format, described below.

JSON Object Format

The primary format — a structured file with metadata and events:

{
  "traceId": "trace-001",
  "metadata": {
    "stationId": "CS-SYNTHETIC-001",
    "ocppVersion": "1.6",
    "source": "csms-log"
  },
  "events": [
    {
      "timestamp": "2024-01-15T10:30:00.000Z",
      "direction": "CS_TO_CSMS",
      "message": [2, "msg-001", "BootNotification", {
        "chargePointVendor": "SyntheticVendor",
        "chargePointModel": "SM-100"
      }]
    },
    {
      "timestamp": "2024-01-15T10:30:00.500Z",
      "direction": "CSMS_TO_CS",
      "message": [3, "msg-001", {
        "currentTime": "2024-01-15T10:30:00.500Z",
        "status": "Accepted"
      }]
    }
  ]
}

JSONL Format

One event per line — useful for CSMS logs and streaming captures:

{"timestamp":"2024-01-15T10:30:00.000Z","direction":"CS_TO_CSMS","message":[2,"msg-001","BootNotification",{}]}
{"timestamp":"2024-01-15T10:30:00.500Z","direction":"CSMS_TO_CS","message":[3,"msg-001",{"status":"Accepted"}]}

Blank lines are ignored. Malformed lines produce parse warnings but don't fail.

Bare Array Format

A JSON array of raw OCPP messages — convenience for quick testing:

[
  [2, "msg-001", "BootNotification", {}],
  [3, "msg-001", {"status": "Accepted"}]
]

Direction is inferred; timestamps are null.

Open OCPP Trace Format

The vendor-neutral Open OCPP Trace interchange format lets traces move between DebugKit and other OCPP tools. It is a stream of records (JSONL or a JSON array), one frame per record:

{"schemaVersion":"1.1","timestamp":"2024-01-15T10:30:00.000Z","transport":"json","direction":"cp-to-csms","messageType":"CALL","messageId":"msg-001","action":"BootNotification","payload":{"chargePointVendor":"SyntheticVendor","chargePointModel":"SM-100"}}
{"schemaVersion":"1.1","timestamp":"2024-01-15T10:30:00.500Z","transport":"json","direction":"csms-to-cp","messageType":"CALLRESULT","messageId":"msg-001","payload":{"status":"Accepted"}}

Each record also carries a raw field with the verbatim frame, so byte-exact or malformed frames survive the round trip. The inspector auto-detects this format on paste; write it back out with the convertCLI command. The parser and exporter are checked against the format's conformance fixtures in CI.

OCPP 1.6 JSON Message Structure

Three message types are supported:

• Call (2): [2, UniqueId, Action, Payload]
• CallResult (3): [3, UniqueId, Payload]
• CallError (4): [4, UniqueId, ErrorCode, ErrorDescription, ErrorDetails]

Timestamps

Accepted formats:

• ISO 8601 (UTC): 2024-01-15T10:30:00.000Z
• ISO 8601 (offset): 2024-01-15T12:00:00+02:00
• Unix epoch (ms): 1705312200000
• Unix epoch (s): 1705312200
• Missing/null — event timestamp is null

Limits

Direction Inference

When direction is not specified, it is inferred from the action name:

• CS_TO_CSMS — BootNotification, Authorize, StartTransaction, StopTransaction, StatusNotification, MeterValues, Heartbeat, etc.
• CSMS_TO_CS — Reset, RemoteStartTransaction, GetConfiguration, ChangeConfiguration, etc.
• UNKNOWN — unrecognized actions

For CallResult/CallError, direction is inferred from the matching Call.