OCPP 2.0.1 Edition 4 Section N

Diagnostics Flows - CSMS Developer Guide

Based on OCPP 2.0.1 Edition 4 Specification (Part 2, Section N, pages 321-341). This guide covers all diagnostics flows from the CSMS perspective including logging, monitoring, events, and customer information management.

7 Sections
10 Use Cases
N01 - N10

1. Overview

Introduction

The Diagnostics functional block enables remote diagnostics of problems with a Charging Station. It covers logging, monitoring, event notifications, and customer information management. The CSMS is either the initiator of diagnostic requests or the receiver of notifications from Charging Stations.

Diagnostic Areas

Logging (N01)

Requesting log file uploads from Charging Stations. The CSMS initiates a log retrieval request and receives status notifications during the upload process.

Monitoring (N02-N06)

Configuring, querying, and clearing variable monitors on Charging Stations. Includes setting monitoring bases, individual variable monitors, monitoring levels, and clearing monitors.

Events (N07-N08)

Receiving alert and periodic event notifications from Charging Stations. Events are triggered by configured monitors when thresholds are crossed, deltas detected, or periodic intervals fire.

Customer Information (N09-N10)

Retrieving and clearing customer-related data stored on Charging Stations. Useful for GDPR data access and "right to be forgotten" requests.

Message Direction Convention

Direction OCPP Term Meaning
CSMS -> CS CALL (type 2) CSMS sends a request to Charging Station
CS -> CSMS CALL (type 2) Charging Station sends a request to CSMS
Response CALLRESULT (type 3) Response to a CALL

Severity Levels (used across monitoring flows)

Lower number = higher severity. These levels are used for monitoring events (N04, N07, N08) and for filtering via SetMonitoringLevel (N05).

Level Name Description
0 Danger Lives potentially in danger. Urgent action needed immediately.
1 Hardware Failure Unable to continue due to hardware issues. Action required.
2 System Failure Unable to continue due to software/minor hardware. Action required.
3 Critical Critical error. Action required.
4 Error Non-urgent error. Action required.
5 Alert Alert event. Default severity for monitoring events.
6 Warning Warning event. Action may be required.
7 Notice Unusual event. No immediate action required.
8 Informational Regular operational event. No action required.
9 Debug Debug information. Not useful during operations.

2. Logging

N01
N01

Retrieve Log Information

The CSMS requests a Charging Station to upload a log file (diagnostics or security) to a given URL. The Charging Station uploads the file and sends status notifications during the process.

CSMS Role: Initiator (sends GetLogRequest), then receives LogStatusNotificationRequest updates.

Sequence Diagram 
CSMS                                          Charging Station
 |                                                  |
 |--- GetLogRequest(logType, requestId, log) ------>|
 |<-- GetLogResponse(status, filename) -------------|
 |                                                  |
 |                                    [Uploading...]|
 |                                                  |
 |<-- LogStatusNotificationRequest(Uploading, id) --|
 |--- LogStatusNotificationResponse() ------------->|
 |                                                  |
 |                                     [Uploaded...]|
 |                                                  |
 |<-- LogStatusNotificationRequest(Uploaded, id) ---|
 |--- LogStatusNotificationResponse() ------------->|

Step 1: CSMS sends GetLogRequest

CSMS --> Charging Station

Action string: "GetLog"

Field Type Required Description
logType LogEnumType ✓ Type of log to retrieve
requestId integer ✓ Unique ID for this request. Used to correlate LogStatusNotification messages.
log LogParametersType ✓ Log upload parameters
retries integer Number of upload retry attempts. If absent, CS decides.
retryInterval integer Seconds between retry attempts. If absent, CS decides.

LogEnumType:

"DiagnosticsLog" General diagnostics log | "SecurityLog" Security-specific log

LogParametersType:

Field Type Required Description
remoteLocation string (max 512) ✓ URL where the CS should upload the log file
oldestTimestamp dateTime Only include logs from this time onward
latestTimestamp dateTime Only include logs up to this time
Example GetLogRequest 
{
  "logType": "DiagnosticsLog",
  "requestId": 123,
  "log": {
    "remoteLocation": "https://logs.example.com/uploads/cs001/",
    "oldestTimestamp": "2025-01-01T00:00:00Z",
    "latestTimestamp": "2025-01-31T23:59:59Z"
  },
  "retries": 3,
  "retryInterval": 60
}

GetLogResponse

Field Type Required Description
status LogStatusEnumType ✓ Whether the CS accepted the request
statusInfo StatusInfoType Additional status information
filename string (max 255) Name of the log file to be uploaded. Absent if no log info available.

LogStatusEnumType:

Value Meaning
"Accepted" Log info available, will begin upload
"Rejected" Log info not available
"AcceptedCanceled" Accepted but previous ongoing upload was canceled

CSMS Implementation Notes:

  1. Generate a unique requestId for each GetLog request. Store it to correlate incoming LogStatusNotification messages.
  2. Provide a reachable upload URL in log.remoteLocation. The URL protocol must be supported by the CS (check FileTransferProtocols configuration variable). HTTP(S) is recommended.
  3. Accept both PUT and POST requests from Charging Stations for log file uploads (N01.FR.18).
  4. If URL ends with /, the CS will append the filename from GetLogResponse to the URL (N01.FR.21).
  5. Handle Expect: 100-continue header — CS may send this for files > 1MB (N01.FR.22).
  6. Use a different basic auth password for log uploads than for OCPP connectivity to avoid leaking credentials (N01.FR.17).
  7. When sending a new GetLogRequest while upload is ongoing, the CS SHOULD cancel the current upload and respond with AcceptedCanceled.

Step 2: CSMS handles LogStatusNotificationRequest

Charging Station --> CSMS

Action string: "LogStatusNotification"

Field Type Required Description
status UploadLogStatusEnumType ✓ Current upload status
requestId integer No* The requestId from the GetLogRequest that initiated this upload

Note: requestId is mandatory unless the message was triggered by a TriggerMessageRequest AND there is no log upload ongoing.

UploadLogStatusEnumType:

Value Meaning CSMS Action
"Idle" No log upload in progress Note idle state
"Uploading" Upload started/in progress Track upload progress
"Uploaded" Upload completed successfully Process/store the log file
"UploadFailure" Upload failed Log error, possibly retry
"BadMessage" Bad request from CS Investigate
"NotSupportedOperation" Operation not supported Log capability gap
"PermissionDenied" Permission denied on upload Check URL/credentials
"AcceptedCanceled" Previous upload was canceled Acknowledge cancellation

The response is an empty object (no fields other than optional customData). The CSMS simply acknowledges receipt.

LogStatusNotificationResponse 
{}

CSMS Implementation Notes for LogStatusNotification:

  1. Correlate by requestId: Match each LogStatusNotificationRequest to the original GetLogRequest using the requestId.
  2. Track state machine: Idle -> Uploading -> Uploaded (success) or error states.
  3. Log all status transitions for audit trail.
  4. On failure statuses (UploadFailure, BadMessage, PermissionDenied, NotSupportedOperation): the CS is recommended to send these only after all retry attempts have failed.

3. Monitoring

N02-N06
N02

Get Monitoring Report

The CSMS requests a report of configured monitoring settings from a Charging Station. The CS responds with acceptance, then sends the report data via one or more NotifyMonitoringReportRequest messages.

CSMS Role: Initiator (sends GetMonitoringReportRequest), then receives NotifyMonitoringReportRequest messages.

Sequence Diagram 
CSO         CSMS                                    Charging Station
 |            |                                           |
 |--request-->|                                           |
 |            |--- GetMonitoringReportRequest ----------->|
 |            |<-- GetMonitoringReportResponse(status) ---|
 |            |                                           |
 |            |   [loop: for each report part]            |
 |            |<-- NotifyMonitoringReportRequest ---------|
 |            |--- NotifyMonitoringReportResponse() ----->|
 |            |   [end loop when tbc=false]               |

Step 1: CSMS sends GetMonitoringReportRequest

CSMS --> Charging Station

Action string: "GetMonitoringReport"

Field Type Required Description
requestId integer ✓ Unique ID for this request
monitoringCriteria MonitoringCriterionEnumType[] (max 3) Filter by monitor type
componentVariable ComponentVariableType[] (min 1) Filter by specific component-variables

MonitoringCriterionEnumType:

Value Returns monitors with type
"ThresholdMonitoring" UpperThreshold or LowerThreshold
"DeltaMonitoring" Delta, TargetDelta, TargetDeltaRelative
"PeriodicMonitoring" Periodic or PeriodicClockAligned

Filtering behavior: If both monitoringCriteria and componentVariable are present, the result is the intersection. If only one is present, it filters accordingly. If both are absent, ALL existing monitors are returned.

Example GetMonitoringReportRequest 
{
  "requestId": 456,
  "monitoringCriteria": ["ThresholdMonitoring"],
  "componentVariable": [
    {
      "component": { "name": "Connector", "evse": { "id": 1, "connectorId": 1 } },
      "variable": { "name": "Temperature" }
    }
  ]
}

GetMonitoringReportResponse

Field Type Required Description
status GenericDeviceModelStatusEnumType ✓ Whether the request was accepted
statusInfo StatusInfoType Additional info

Status values:

"Accepted" - Request accepted, report will follow
"Rejected" - Request rejected
"NotSupported" - Monitoring criteria not supported
"EmptyResultSet" - No matching monitors

Step 2: CSMS handles NotifyMonitoringReportRequest

Charging Station --> CSMS

Action string: "NotifyMonitoringReport"

Field Type Required Description
requestId integer ✓ The requestId from the GetMonitoringReportRequest
seqNo integer ✓ Sequence number (starts at 0, incremental)
generatedAt dateTime ✓ When the report was generated
tbc boolean "To be continued" — true if more parts follow. Default: false
monitor MonitoringDataType[] (min 1) The monitoring data (absent only if no data)
MonitoringDataType & VariableMonitoringType

MonitoringDataType:

Field Type Description
component ComponentType The monitored component
variable VariableType The monitored variable
variableMonitoring VariableMonitoringType[] (min 1) The monitoring settings

VariableMonitoringType:

Field Type Description
id integer Monitor identifier
transaction boolean Only active during transactions
value number Threshold/delta value, or interval in seconds for periodic
type MonitorEnumType Monitor type
severity integer (0-9) Severity level
NotifyMonitoringReportResponse 
{}

CSMS Implementation Notes:

  1. Store monitoring data indexed by requestId. Reassemble multi-part reports using seqNo ordering.
  2. Check tbc flag: Keep listening for more parts until tbc is false or absent.
  3. Track monitor IDs: The id in VariableMonitoringType is assigned by the CS and is needed for ClearVariableMonitoring (N06) and to correlate with NotifyEvent messages (N07/N08).
  4. After CS reboot, send a new GetMonitoringReportRequest — custom monitors persist across reboots but IDs may change (N04.FR.19).
N03

Set Monitoring Base

The CSMS requests the Charging Station to activate a set of preconfigured monitoring settings by setting the MonitoringBase value.

CSMS Role: Initiator (sends SetMonitoringBaseRequest).

Sequence Diagram 
CSO         CSMS                                    Charging Station
 |            |                                           |
 |--request-->|                                           |
 |            |--- SetMonitoringBaseRequest(base) ------->|
 |            |<-- SetMonitoringBaseResponse(status) -----|

SetMonitoringBaseRequest

CSMS --> Charging Station

Action string: "SetMonitoringBase"

Field Type Required Description
monitoringBase MonitoringBaseEnumType ✓ Which monitoring base to set

MonitoringBaseEnumType:

Value Effect on Charging Station
"All" Activate all pre-configured monitors AND leave previously configured CustomMonitor monitors intact (including custom monitors created when changing a pre-configured monitor).
"FactoryDefault" (Re)activate all PreconfiguredMonitor monitors AND remove all custom monitors (including overruled pre-configured monitors).
"HardWiredOnly" Clear all custom and disable all pre-configured monitors. Only HardWiredMonitor monitors remain active.
Example SetMonitoringBaseRequest 
{
  "monitoringBase": "FactoryDefault"
}

SetMonitoringBaseResponse

Status values: "Accepted", "Rejected", "NotSupported", "EmptyResultSet"

CSMS Implementation Notes:

  1. Use FactoryDefault on initial setup to reset to a known state.
  2. Use All to re-enable pre-configured monitors without disturbing custom monitors.
  3. Use HardWiredOnly for minimal monitoring (only hardware-level monitors).
  4. After setting the base, consider sending a GetMonitoringReportRequest (N02) to verify the active monitors.
N04

Set Variable Monitoring

The CSMS requests the Charging Station to set monitoring triggers on specific variables. Multiple triggers can be set for upper/lower thresholds, delta changes, or periodic reporting.

CSMS Role: Initiator (sends SetVariableMonitoringRequest).

Sequence Diagram 
CSO         CSMS                                        Charging Station
 |            |                                               |
 |--request-->|                                               |
 |            |--- SetVariableMonitoringRequest(data[]) ----->|
 |            |<-- SetVariableMonitoringResponse(result[]) ---|

SetVariableMonitoringRequest

CSMS --> Charging Station

Action string: "SetVariableMonitoring"

SetMonitoringDataType:

Field Type Required Description
id integer Provide ONLY to replace an existing monitor. CS generates IDs for new monitors.
transaction boolean If true, monitor only active during transactions. Default: false.
value number ✓ Threshold/delta value, or interval in seconds for Periodic/PeriodicClockAligned
type MonitorEnumType ✓ Type of monitor
severity integer (0-9) ✓ Severity level for triggered events
component ComponentType ✓ Target component
variable VariableType ✓ Target variable
Example — set an upper temperature threshold and periodic power monitor 
{
  "setMonitoringData": [
    {
      "value": 85.0,
      "type": "UpperThreshold",
      "severity": 4,
      "component": { "name": "Connector", "evse": { "id": 1, "connectorId": 1 } },
      "variable": { "name": "Temperature" }
    },
    {
      "value": 300,
      "type": "Periodic",
      "severity": 8,
      "component": { "name": "Connector", "evse": { "id": 1 } },
      "variable": { "name": "Power" },
      "transaction": true
    }
  ]
}

SetVariableMonitoringResponse

SetMonitoringResultType fields
Field Type Required Description
id integer Monitor ID (only present when status = Accepted)
status SetMonitoringStatusEnumType ✓ Result status
type MonitorEnumType ✓ Echo of the requested monitor type
severity integer (0-9) ✓ Echo of the requested severity
component ComponentType ✓ Echo of the target component
variable VariableType ✓ Echo of the target variable
statusInfo StatusInfoType Additional info on rejection

SetMonitoringStatusEnumType:

Value Meaning
"Accepted" Monitor was set successfully. id field contains the assigned ID.
"UnknownComponent" The specified component is unknown to the CS.
"UnknownVariable" The variable is unknown for the given component.
"UnsupportedMonitorType" The variable doesn't support this monitor type.
"Rejected" Rejected (e.g., value out of range, conflicts with safety, delta value is zero or negative).
"Duplicate" A monitor with the same type and severity already exists for this component/variable (different ID).

CSMS Implementation Notes:

  1. Store the returned id from accepted results — needed for future ClearVariableMonitoring (N06) and correlating events.
  2. To replace a monitor, include the id field in SetMonitoringData. The component/variable combination MUST match the existing monitor (N04.FR.16).
  3. Cannot change a HardWiredMonitor — will be rejected (N04.FR.18).
  4. For Delta monitors on non-numeric variables, use a value of 1 (triggers on any change) (N04.FR.17).
  5. Delta value of 0 or negative will be rejected (N04.FR.14, N04.FR.20).
  6. Duplicate detection: Cannot have two monitors of the same type AND severity on the same component/variable (N04.FR.10).
  7. Monitors persist across reboots but IDs may change after firmware updates. Send GetMonitoringReportRequest after reboot to refresh IDs (N04.FR.19).
  8. Replaced pre-configured monitors become CustomMonitor until reset by SetMonitoringBaseRequest (N04.FR.15).
  9. Max items per message is constrained by ItemsPerMessageSetVariableMonitoring and BytesPerMessageSetVariableMonitoring configuration variables (N04.FR.09).
N05

Set Monitoring Level

The CSMS requests the Charging Station to restrict event reporting to only those monitors with a severity number less than or equal to the specified level (lower number = higher severity).

CSMS Role: Initiator (sends SetMonitoringLevelRequest).

Sequence Diagram 
CSMS                                    Charging Station
 |                                           |
 |--- SetMonitoringLevelRequest(severity) -->|
 |<-- SetMonitoringLevelResponse(status) ----|

SetMonitoringLevelRequest

CSMS --> Charging Station

Action string: "SetMonitoringLevel"

Field Type Required Description
severity integer (0-9) ✓ Only report events with severity <= this value
Example — only report errors and above (severity 0-4) 
{
  "severity": 4
}
Example — report everything including debug 
{
  "severity": 9
}

SetMonitoringLevelResponse

Status values: "Accepted" (level was set) or "Rejected" (request rejected)

CSMS Implementation Notes:

  1. This controls the NotifyEventRequest filtering — the CS will only send events for monitors with severity <= the set level.
  2. Default severity is 5 (Alert) — to get more verbose reporting, increase the level.
  3. Does NOT affect which monitors exist — only controls which events are reported. Monitors remain configured.
  4. Set to 9 for debugging, reduce in production to avoid event flooding.
N06

Clear / Remove Monitoring

The CSMS requests the Charging Station to remove specific monitors by their IDs.

CSMS Role: Initiator (sends ClearVariableMonitoringRequest).

Sequence Diagram 
CSMS                                              Charging Station
 |                                                      |
 |--- ClearVariableMonitoringRequest(ids[]) ----------->|
 |<-- ClearVariableMonitoringResponse(results[]) -------|

ClearVariableMonitoringRequest

CSMS --> Charging Station

Action string: "ClearVariableMonitoring"

Field Type Required Description
id integer[] (min 1) ✓ List of monitor IDs to clear
Example ClearVariableMonitoringRequest 
{
  "id": [101, 102, 103]
}

ClearVariableMonitoringResponse

ClearMonitoringResultType fields
Field Type Required Description
status ClearMonitoringStatusEnumType ✓ Result for this monitor
id integer ✓ The monitor ID this result refers to
statusInfo StatusInfoType Additional info

ClearMonitoringStatusEnumType:

"Accepted" - Monitor was cleared
"Rejected" - Monitor cannot be removed (e.g., it's a hardwired monitor)
"NotFound" - No monitor with this ID exists

CSMS Implementation Notes:

  1. Get monitor IDs first via GetMonitoringReportRequest (N02) or from SetVariableMonitoringResponse (N04).
  2. Hardwired monitors cannot be cleared — they will return Rejected.
  3. IDs of removed monitors may be reused by the CS for new monitors.
  4. Process each result individually — some may succeed while others fail.

4. Events

N07-N08
N07

Alert Event

The Charging Station sends event notifications to the CSMS when a monitored variable crosses a threshold (upper or lower) or changes by a delta amount. This is a CS-initiated flow.

CSMS Role: Receiver — handle incoming NotifyEventRequest messages.

Sequence Diagram 
CSMS                                          Charging Station
 |                                                  |
 |                              [threshold crossed] |
 |<-- NotifyEventRequest(eventData[]) --------------|
 |--- NotifyEventResponse() ----------------------->|
 |                                                  |
 |                        [condition cleared]        |
 |<-- NotifyEventRequest(eventData[cleared=true]) --|
 |--- NotifyEventResponse() ----------------------->|

CSMS handles NotifyEventRequest

Charging Station --> CSMS

Action string: "NotifyEvent"

Field Type Required Description
generatedAt dateTime ✓ When the message was generated
seqNo integer ✓ Sequence number (starts at 0)
tbc boolean "To be continued" — more parts follow. Default: false
eventData EventDataType[] (min 1) ✓ The event data
EventDataType fields
Field Type Required Description
eventId integer ✓ Unique event identifier. Other events can reference this as cause.
timestamp dateTime ✓ When the event occurred
trigger EventTriggerEnumType ✓ What triggered this event
actualValue string (max 2500) ✓ Current value of the variable
eventNotificationType EventNotificationEnumType ✓ Source type of the notification
component ComponentType ✓ The component that generated the event
variable VariableType ✓ The variable that triggered the event
cause integer eventId of the event that caused this one
techCode string (max 50) Technical error code
techInfo string (max 500) Technical detail information
cleared boolean true = the monitored situation has returned to normal
transactionId string (max 36) If linked to a specific transaction
variableMonitoringId integer ID of the VariableMonitoring that triggered this event

EventTriggerEnumType:

Value Meaning
"Alerting" Threshold was exceeded (UpperThreshold or LowerThreshold)
"Delta" Value changed by the delta amount
"Periodic" Periodic timer triggered

EventNotificationEnumType:

Value Meaning
"HardWiredNotification" Event from a hardwired notification source (not a monitor)
"HardWiredMonitor" Event from a hardwired monitor
"PreconfiguredMonitor" Event from a preconfigured monitor
"CustomMonitor" Event from a custom (CSMS-configured) monitor
Example incoming event (temperature alert) 
{
  "generatedAt": "2025-06-15T14:30:00Z",
  "seqNo": 0,
  "eventData": [
    {
      "eventId": 42,
      "timestamp": "2025-06-15T14:29:58Z",
      "trigger": "Alerting",
      "actualValue": "87.5",
      "eventNotificationType": "CustomMonitor",
      "component": { "name": "Connector", "evse": { "id": 1, "connectorId": 1 } },
      "variable": { "name": "Temperature" },
      "variableMonitoringId": 101,
      "techCode": "OverTemp",
      "techInfo": "Connector temperature exceeds 85C threshold"
    }
  ]
}
NotifyEventResponse 
{}

CSMS Implementation Notes:

  1. Store events with full context: eventId, timestamp, component, variable, actualValue, severity (from the monitor config).
  2. Track cleared flag: When cleared=true, it means the condition has returned to normal. Update the event/alarm status.
  3. Correlate via variableMonitoringId to link events to their configured monitors.
  4. Correlate via cause to build event chains (cascading failures).
  5. Link to transactions using transactionId when present.
  6. Multi-part events: If tbc=true, wait for the next message with incremented seqNo.
  7. Alerting actions based on severity and event type:
Severity Recommended Action
0-2 Immediate alerts to operations team
3-4 Create tickets/work orders
5-6 Log and monitor
7-9 Informational logging
N08

Periodic Event

Same message format as N07 (Alert Event), but triggered by periodic or clock-aligned monitors. The Charging Station periodically reports variable values.

CSMS Role: Receiver — handle incoming NotifyEventRequest messages with trigger = "Periodic".

Sequence Diagram 
CSMS                                          Charging Station
 |                                                  |
 |                            [periodic interval]   |
 |<-- NotifyEventRequest(trigger=Periodic) ---------|
 |--- NotifyEventResponse() ----------------------->|
 |                                                  |
 |                            [next interval]       |
 |<-- NotifyEventRequest(trigger=Periodic) ---------|
 |--- NotifyEventResponse() ----------------------->|

Uses the exact same NotifyEventRequest/NotifyEventResponse as N07 - Alert Event. The key differences are: trigger = "Periodic" instead of "Alerting" or "Delta", and actualValue contains the current value at the time of the periodic report.

CSMS Implementation Notes:

  1. Use periodic events for time-series data collection: power, energy, temperature, etc.
  2. Store values with timestamps for trending and analytics.
  3. Configure periodic monitors via N04 with type: "Periodic" or "PeriodicClockAligned" and value set to the desired interval in seconds.
  4. PeriodicClockAligned triggers at clock-aligned intervals (e.g., every 15 minutes aligned to the hour).
  5. Transaction-scoped monitors (transaction: true in N04) only report during active transactions.

5. Customer Information

N09-N10
N09

Get Customer Information

The CSMS requests the Charging Station to report customer-related information stored locally. The CS responds with acceptance, then sends the data via NotifyCustomerInformationRequest messages.

CSMS Role: Initiator (sends CustomerInformationRequest with report=true), then receives NotifyCustomerInformationRequest.

Sequence Diagram 
CSMS                                              Charging Station
 |                                                      |
 |--- CustomerInformationRequest(report=true) --------->|
 |<-- CustomerInformationResponse(status) --------------|
 |                                                      |
 |   [loop: for each report part]                       |
 |<-- NotifyCustomerInformationRequest(data) -----------|
 |--- NotifyCustomerInformationResponse() ------------->|
 |   [end loop when tbc=false]                          |

Step 1: CSMS sends CustomerInformationRequest

CSMS --> Charging Station

Action string: "CustomerInformation"

Field Type Required Description
requestId integer ✓ Unique ID for this request
report boolean ✓ Set to true to request customer info report
clear boolean ✓ Set to false for N09 (retrieval only). Set to true for N10 (clear).
customerIdentifier string (max 64) Vendor-specific customer identifier
idToken IdTokenType Customer's IdToken
customerCertificate CertificateHashDataType Customer's certificate hash

At least one of customerIdentifier, idToken, or customerCertificate SHOULD be provided to identify the customer.

IdTokenType, AdditionalInfoType & CertificateHashDataType

IdTokenType:

Field Type Description
idToken string (max 36) The token value (case insensitive)
type IdTokenEnumType Token type
additionalInfo AdditionalInfoType[] Additional identification info

IdTokenEnumType: "Central", "eMAID", "ISO14443", "ISO15693", "KeyCode", "Local", "MacAddress", "NoAuthorization"

AdditionalInfoType:

Field Type Description
additionalIdToken string (max 36) Additional token value for this identification
type string (max 50) Type of the additional token (defines how to interpret additionalIdToken)

CertificateHashDataType:

Field Type Description
hashAlgorithm HashAlgorithmEnumType "SHA256", "SHA384", or "SHA512"
issuerNameHash string (max 128) Hashed Issuer DN
issuerKeyHash string (max 128) Hashed issuer public key
serialNumber string (max 40) Certificate serial number
Example — get customer info by IdToken 
{
  "requestId": 789,
  "report": true,
  "clear": false,
  "idToken": {
    "idToken": "AA12BB34",
    "type": "ISO14443"
  }
}

CustomerInformationResponse

Status values: "Accepted" (request accepted, report will follow), "Rejected" (request rejected), "Invalid" (invalid identifier combination)

Step 2: CSMS handles NotifyCustomerInformationRequest

Charging Station --> CSMS

Action string: "NotifyCustomerInformation"

Field Type Required Description
data string (max 512) ✓ (Part of) the customer information. Human readable, no prescribed format.
seqNo integer ✓ Sequence number (starts at 0)
generatedAt dateTime ✓ When the message was generated
requestId integer ✓ The requestId from the original CustomerInformationRequest
tbc boolean "To be continued" — more parts follow. Default: false
NotifyCustomerInformationResponse 
{}

CSMS Implementation Notes:

  1. Concatenate multi-part data: data is limited to 512 chars per message. Use seqNo to reassemble in order; continue until tbc=false.
  2. Correlate by requestId to match with the original request.
  3. Data format is unstructured — it's human-readable text. Parse as needed based on your CS vendor's format.
  4. This is useful for GDPR data access requests — retrieving all personal data stored on a CS.
  5. Customer identification can be done via three methods (at least one should be provided): idToken (RFID card, eMAID, etc.), customerCertificate (ISO 15118 certificate), or customerIdentifier (vendor-specific).
N10

Clear Customer Information

The CSMS requests the Charging Station to clear all customer-related information for a specific customer. Uses the same CustomerInformationRequest but with clear=true.

CSMS Role: Initiator (sends CustomerInformationRequest with clear=true).

Sequence Diagram 
CSMS                                              Charging Station
 |                                                      |
 |--- CustomerInformationRequest(clear=true) ---------->|
 |<-- CustomerInformationResponse(status) --------------|
 |                                                      |
 |   [optionally, if report=true also set]              |
 |<-- NotifyCustomerInformationRequest(data) -----------|
 |--- NotifyCustomerInformationResponse() ------------->|
Example — clear customer data 
{
  "requestId": 790,
  "report": false,
  "clear": true,
  "idToken": {
    "idToken": "AA12BB34",
    "type": "ISO14443"
  }
}
Example — clear AND report (get data before clearing) 
{
  "requestId": 791,
  "report": true,
  "clear": true,
  "idToken": {
    "idToken": "AA12BB34",
    "type": "ISO14443"
  }
}

Same response/notification flow as N09: CustomerInformationResponse with Accepted/Rejected/Invalid. If report=true, NotifyCustomerInformationRequest messages follow with the cleared data.

CSMS Implementation Notes:

  1. Combine report=true and clear=true to get the data before it's deleted (for audit/compliance).
  2. This is useful for GDPR "right to be forgotten" requests.
  3. The CS clears ALL customer-related data matching the identifier — authorization cache entries, transaction history references, etc.
  4. Clearing only affects data on the CS — CSMS-side data must be handled separately.

6. Shared Enumerations Reference

Reference

GenericDeviceModelStatusEnumType

Used by: N02, N03

Value Description
Accepted Request accepted
Rejected Request rejected
NotSupported Feature not supported
EmptyResultSet No matching data

GenericStatusEnumType

Used by: N05

Value Description
Accepted Request accepted
Rejected Request rejected

MonitorEnumType

Used by: N02, N04, N07, N08

Value Description
UpperThreshold Triggers when value > threshold
LowerThreshold Triggers when value < threshold
Delta Triggers on delta change
Periodic Triggers at intervals
PeriodicClockAligned Triggers at clock-aligned intervals

EventNotificationEnumType

Used by: N07, N08

Value Description
HardWiredNotification From hardware notification (not a monitor)
HardWiredMonitor From hardware monitor
PreconfiguredMonitor From preconfigured monitor
CustomMonitor From CSMS-configured monitor

EventTriggerEnumType

Used by: N07, N08

Value Description
Alerting Threshold crossed
Delta Delta change detected
Periodic Periodic timer fired

7. Shared Data Types Reference

Reference

StatusInfoType

Field Type Required Description
reasonCode string (max 20) ✓ Predefined reason code (case insensitive)
additionalInfo string (max 512) Human-readable detail

ComponentType

Field Type Required Description
name string (max 50) ✓ Component name (case insensitive, CamelCase recommended)
instance string (max 50) Instance name for multi-instance components
evse EVSEType EVSE scope

VariableType

Field Type Required Description
name string (max 50) ✓ Variable name (case insensitive, CamelCase recommended)
instance string (max 50) Instance name for multi-instance variables

EVSEType

Field Type Required Description
id integer ✓ EVSE identifier (> 0)
connectorId integer Connector index number

OCPP Message Actions Quick Reference

Flow CSMS Sends (Action) CS Sends (Action) CSMS Receives (Action)
N01 GetLog — LogStatusNotification
N02 GetMonitoringReport — NotifyMonitoringReport
N03 SetMonitoringBase — —
N04 SetVariableMonitoring — —
N05 SetMonitoringLevel — —
N06 ClearVariableMonitoring — —
N07 — NotifyEvent NotifyEvent
N08 — NotifyEvent NotifyEvent
N09 CustomerInformation — NotifyCustomerInformation
N10 CustomerInformation — NotifyCustomerInformation

Routing Summary

Messages CSMS initiates (sends as CALL, receives CALLRESULT)

  • GetLog -> GetLogResponse
  • GetMonitoringReport -> GetMonitoringReportResponse
  • SetMonitoringBase -> SetMonitoringBaseResponse
  • SetVariableMonitoring -> SetVariableMonitoringResponse
  • SetMonitoringLevel -> SetMonitoringLevelResponse
  • ClearVariableMonitoring -> ClearVariableMonitoringResponse
  • CustomerInformation -> CustomerInformationResponse

Messages CSMS handles (receives as CALL, sends CALLRESULT)

  • LogStatusNotification -> LogStatusNotificationResponse (empty)
  • NotifyMonitoringReport -> NotifyMonitoringReportResponse (empty)
  • NotifyEvent -> NotifyEventResponse (empty)
  • NotifyCustomerInformation -> NotifyCustomerInformationResponse (empty)

OCPP 2.0.1 Diagnostics Flows - CSMS Developer Guide. Based on OCPP 2.0.1 Edition 4 Specification (Part 2, Section N).