ocpp device management profile - oasis · device management profile this section is normative. 1....

OCPP Device Management Profilev0.3 DRAFT, 2016-11-09

Table of ContentsDevice Management Profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1. Naming Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. The Charge Point Device Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1. Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3. Get Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1. Asynchronous ReportNotice Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2. Inventory Discovery Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4. Set Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1. Asynchronous ConfigurationNotice Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2. Standardized Configuration Component.Variables Combinations . . . . . . . . . . . . . . . . . . . . . . 16

5. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.1. Variable Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2. Set Monitoring: Configuration of Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3. Monitor Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.4. Get Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.5. Base Monitoring Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.6. Monitoring Level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6. Minimum Device Model Support Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.1. ConfigurationNotice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.2. EventNotice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

7.3. GetMonitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.4. GetReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7.5. ReportNotice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.6. SetConfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.7. SetMonitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

7.8. SetMonitoringBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7.9. SetMonitoringLevel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8. Device Model Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.1. ClearedEvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.2. ComponentCriterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

8.3. ConfigurationStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8.4. Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

8.5. Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.6. MonitoringBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

8.7. ReportBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.8. SetData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

8.9. Severity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8.10. Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

8.11. Variable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.12. VariableAttribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

8.13. VariableData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.14. VariableMutability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

8.15. VariableParameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.16. VariableReference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8.17. VariableStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8.18. VariableType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

9. Appendix A: Standardized Component Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

10. Appendix B: Standard Enumerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

10.1. AvailabilityState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

10.2. ChargeProtocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

10.3. ConnectorType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

10.4. PhaseRotation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.5. PowerType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

10.6. SupplyPhases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

11. Appendix C: Standardized Variable Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

11.1. Boolean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

11.2. Decimal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

11.3. DateTime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

11.4. Enumerations (Standardized Names) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

11.5. Enumeration Lists (Standardized Names). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

11.6. Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

11.7. Integer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

11.8. Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Copyright 2010 - 2016 Open Charge Alliance. All rights reserved.

This document is made available under the *Creative Commons Attribution-NoDerivatives 4.0 International Public License*(https://creativecommons.org/licenses/by-nd/4.0/legalcode).

Version History

Version Date Author Description

0.3 2016-11-09 Robert de LeeuwIHomer

Improved Monitoring,Configuration and Inventory.


Fixed pdf generation, addedstyling


Initial version, based on OCPP2.0 RC3

1

https://creativecommons.org/licenses/by-nd/4.0/legalcode

Device Management ProfileThis section is normative.

1. IntroductionThis section is informative.

OCPP 2.0 is extended with a new “Device Model” that represents a standardized logical view of themany hardware and software “Components” that make up a typical charge point. Depending on itsnature, each Component can have a number of “Variable” values that are used to represent andcontrol significant aspects of its behavior, its current “State”, and to report significant “Events”.

Using the Device Model, Charge Points can report information ranging from very static “state” (e.g.Component presence, hardware model numbers, etc.), through configuration settings, datamonitoring (e.g. supply voltage variations), and highly transient and/or urgent event situations.

All event, state and configuration information is communicated from the Charge Point to theCentral System using ReportNotices.

The Device Model also provides a rational structured framework for setting and reporting ofconfiguration of fine grained device configuration information.

A Central System can use the fine-grained Component & Variable addressing capability of theDevice Model to:

• Discover all available information about the logical structure of a charge point, allowing “Plug &Play” enrollment of new charge points, and elimination of expensive, time-consuming and errorprone manual data-entry.

• Obtain detailed information on the current state of a charge point by requesting a report on anyor all Component Variables

• Receive event notifications with fine-grained detail about problem and operational “events”that occur at a charge point

• Obtain detailed information on which events and problem values a charge point monitors andreports, and the parameters for such reporting (e.g. access door opened, temperature limit Xexceeded)

• Change the monitoring configuration, to report just the events and problem values of interest

• Change the configuration of Components of a charge point to enable, disable, or modify itsfunctionality.

Overall, this enables a Central System to monitor and control a Charge Point in a structured way,and to more easily diagnose “how the charge point is doing” and “what has happened”, whensomething goes wrong. State and Event reporting helps to improve customer experience and lowermaintenance costs by providing better, more structured and standardized (near) real-timediagnostics.

2

Important: Full implementation of all features is not required. The goal of the device model is tohave whatever is implemented, function in a standardized, predictable way that is consistent acrossCharge Points. From a Central System point of view this is very useful to properly support differentbrands of Charge Points in a single system.

1.1. Naming ProposalsThere are currently 2 naming proposals for message, data types, field names etc in the DeviceManagement profile The OASIS OCPP TC has to take a decision on this.

This proposal is written using proposal 1.

Type Proposal 1 Proposal 2 Description

Message ConfigurationNotice ConfigNotice

Fieldname

ConfigurationNotice.req →requestId

ConfigurationNotice.req →refId

Fieldname

SetConfiguration.req →requestId

SetConfiguration.req →refId

Fieldname

SetMonitoring.req →variableReference

SetMonitoring.req → cvRef

Fieldname

SetMonitoring.req →monitoring

SetMonitoring.req →cvMonitoring

Data type ConfigurationStatus CvRefStatus

Data type Monitoring CvMonitoring

Data type Variable CvRefData

Fieldname

Variable → reference CvRefData → cvRef

Fieldname

Variable → data CvRefData → vAttrData

Fieldname

Variable → parameters CvRefData → vParms

Fieldname

Variable → monitoring CvRefData → cvMonitoring

Data type VariableData VAttrData

Fieldname

VariableData → value VAttrData → datum

Data type VariableParameters VParms

Data type VariableReference CvRef

Fieldname

VariableReference →componentName

CvRef → comp

3

Type Proposal 1 Proposal 2 Description

Fieldname

VariableReference →componentKey

CvRef → cKey

Fieldname

VariableReference →variableName

CvRef → var

Fieldname

VariableReference →variableKey

CvRef → vKey

Fieldname

SetData → attribute SetData → attr

Fieldname

SetData → value SetData → datum

Fieldname

SetData → variableReference SetData → cvRef

2. The Charge Point Device ModelThe Device Model is a standardized logical description of a Charge Point. It allows for unambiguousdescription of the state, configuration, and monitoring settings of the Charge Point, and the precisereporting of significant events. A Charge Point consists of Components. Components have propertiesthat are described by Variables.

The Charge Point reports this the other way around: a list of Variables. Every Variable has aComponent to which it belongs. By going over the full list of Variables the Central System canretrieve the list of Components reported by the Charge Point.

TODO: Do we still need this: For convenience & brevity, the notation used in this document forreferring to components' variables, and their values, is: Component[evse[connector]][key].Variable[key] [=Value].

The Value of a Variable can be something that is sensed, measured, or known by the Charge Point(e.g. PlugRetentionLock.Active = true) or something that can be configured by the Central System(e.g. Controller.Interval = 600).

A Charge Point can report events on its Components by sending EventNotices using theEventNotifice.req message. A Central System can set the Values of certain Variables using theSetConfiguration.req message.

2.1. ComponentsLogical Components constitute the primary entities of the Device Model and represent both typicalreal-world (sub-)components, such as controller, RFID reader, energy meter, etc., and virtuallogical/software components, with standardized component names, such as. TokenReader,FiscalMetering, CoolingSystem.

Only components that are present MAY be reported. A manufacturer is not required to report all

4

components of a Charge Point.

2.1.1. Standardized Components

A Charge Point is build up of a lot of different components. A Charge Point manufacturer is free todefine what components are reported via the Device Model.

There is a list of "standardized" Components defined in Appendix A: Standardized ComponentNames. For interoperability reasons: when giving a name to a component (name field ofComponent) a manufacturer SHALL use a name from the list of standardized components, if itcontains a component that (almost) matches the functionality of that component. Simply put, if youuse a component, use the standardized name (if available).

The Standardized Component Names list contains components like:

• CoolingSystem

• Clock

• EVSE

• OutOfServiceInput

• OverCurrentBreaker etc.

2.1.2. Component Occurrence Levels

Components may occur at any of three hierarchical levels in the logical structure of a Charge Point:

• Charge Point

• EVSE(s)

• Connector(s)

The occurrence level is a characteristic of each specific Component instance. Components (even ofthe same type) can occur on different levels, and more than once.

An example of this is metering: Metering could (at least theoretically) occur on any of these levels.There might be EVSE-specific meters for transactional purposes, but additionally there might alsobe a meter on the Charge Point level monitoring the total consumption of the Charge Point, and/or aseparate meter recording only the standby energy consumption.

Note that ChargePoint, EVSE and Connector also exist as Components in order to report onproperties of the entire Charge Point or EVSE, such as AvailabilityState.

TODO: Because we don’t have a Component tree, it is needed to have these Components (ChargePoint,EVSE and Connector) as well. Would be better do have a component tree, but how to create thatwithout making things more complex then they already are… Would also make things like profile andconfigurationKey replacements much easier.

There is no mandatory relation between any given level and a (sub) set of Components.

Manufacturers SHALL place their logical device model Components on a level that reflects their

5

logical position in the Charge Point hardware/software design.

The following table, populated with arbitrary Components, illustrates the structure of the DeviceModel components.

Charge Point

TokenReader

RadioLink

OverCurrentBreaker

EmergencyStopSensor

ShockSensor

TiltSensor

Controller

AreaVentilation

EVSE #1

StartButton

StopButton

CPPWMController

ISO15118Controller

BayOccupancyDetector

ACDCConverter

CoolingSystem

Connector #1

ConnectorType

ConnectorProtection

PlugRetentionLock

As stated, this hierarchy can be used flexibly:

• Charge Points can have multiple EVSEs with multiple Connectors.

• Components can occur on multiple levels and multiple times per level.

2.1.3. Keyed Addressing of Component Instances

Where multiple instances of a Component with the same name exist on the same "Level"(ChargePoint, EVSE, Connector), each instance SHALL be given a key that is unique on that "Level".

Static Component instance key values are not standardized, but, where used, SHOULD follow the"UpperCamelCase" (UCC) naming convention. Typical values may be positional adjectives, (e.g. Top,

6

Bottom, Upper, Lower, Left, Right, Front, Rear, or combinations thereof).

For example: 2 Ventilators on ChargePoint "Level". They should both have a unique key, forexample:

• Ventilator[Top]

• Ventilator[Bottom]

2.1.4. Profile Management Components

TODO: Depending on how OCPP 2.0 "profiles" are defined/named we need a workable solution onhow to report to the Central System which "profiles" are implemented.

We might make a component per "profile", and give these "profile components" a number ofrequired and optional parameters that a Charge Point must/may implemented.

We also need to move to old configuration keys that are relevant to this.

OLD TEXT:

Each OCPP Profile has one or more associated logical components that represent theimplementation of the profile functionality in the charge point.

These facilitate the Central System in discovering which Profiles a Charge Point supports, alongwith associated operating sub-modes/options, and cardinality limits that apply to repeatingelements in related OCPP messages and data structures in the charge point.

The currently defined Profiles and their associated Components, together with sample cardinalityand mode variables are shown in the table below.

Profile Components Modes, #Cardinality, etc.

Core TransactionManager #Transactions (Queued)

DeviceManager #MaxComponentsPerGetReport#MaxPerSetConfigurationetc

Firmware FirmwareManager DownloadProtocols

LocalList LocalListManager #ListEntries#MaxListEntries#MaxMsgEntries

Reservations Reservations #Reservations

SmartCharging SmartChargingManager #ChargingProfiles#MaxChargingProfiles#MaxMasgChargingProfilesetc.

7

2.1.5. Default component behavior: Explicit Active, Available and Enabled

All component have by default the following Variables (without having to report them):

• Active

• Available

• Enabled

With the following defaults:

Field Value Description

value 1 True

mutability Fixed

This means that all Components are by default in active state, operational, and can be used. When acomponent does not have this default behavior, the component SHALL report these variables thathave different values.

Examples:

• An InternalTemperatureSensor that always reports the current temperature, cannot be turnedoff: doesn’t have to report one of these 3 variables.

• An OutOfServiceInput should not default report Active=1, default it should be 0. And if thisOutOfServiceInput can be turned of, it also needs to report this. So it should report:

• Active with value=0 when not activated, and mutability: ReadOnly.

• Enabled with value=1, mutability: ReadWrite

2.2. VariablesA Component has certain properties (called "Variables" in OCPP) that are used to report on theevents and state of a Component, and control its operating configuration. Examples are Booleanvariables like Active, analogue variables like Temperature and enumerations like ConnectorType.

2.2.1. Standardized Variables

There is a list of "standardized" Variables defined in Appendix B: Standardized Component Names.For interoperability reasons: when giving a name to a variable (name field of Variable) amanufacturer SHALL use a name from the list of standardized variables, if it contains a variablethat (almost) matches the wanted variable. Simply put, if you use a variable, use the standardizedname (if available).

The Standardized Component Names list contains variables like:

• ACCurrent

• ConnectorType

8

• Model

• SignalStrength

• Temperature etc.

2.2.2. Keying of Variables

Where multiple instances of a Variable with the same name exist within the same Componentinstance, etc., textual key strings SHALL be used to denote and address each instance of theVariable.

Examples of keyed Variables are the Time and TimeOffset variables of the Clock Component.These contain the current time and also the date & time at which to execute the next time zonetransition (e.g. start of Daylight Saving Time) and the associated time offsets:

• Clock.Time[Now] = 2013-12-09T12:34:56Z (Current date/time)

• Clock.Time[NextTransition] = 2014-03-30T02:00:00Z (Start of next time shift: e.g. DaylightSaving Time)

• Clock.TimeOffset[Now] = +00:00 (Current time offset )

• Clock.TimeOffset[NextTransition] = +01:00 (Daylight Saving Time Offset)

The key field values are standardized for common configuration value cases, but in other cases,custom vendor/model specific keys may be assigned by the Charge Point and reported duringInventory discovery operations.

All standardized key values follow the "UpperCamelCase" (UCC) naming convention, we advicecustom keys to follow the same naming convention.

2.2.3. Variable Attribute

In addition to its primary Value, every instance of a Variable may also have one or more of anumber of well defined associated secondary "modal" values. These sub-modes of a variable areprimarily used to report and configure/control the operating range and/or valid values of thevariable’s primary mode ("Value").

The attribute field (VariableAttribute enumeration type) of a Variable element specifies theprimary or secondary value to be addressed.

Note: a Charge Point MAY prohibit the updating of certain Variables. For example, it is perfectlyvalid to request the value of InternalTemperatureSensor.Temperature, but it does not makesense to update it to another value. For such cases, the Charge Point MUST return appropriate value(ReadOnly) of the variable’s mutability (data type VariableMutability) field during Inventorydiscovery reporting.

Where a Central System incorrectly attempts to change an immutable Variable value (usingSetConfiguration) the Charge Point must respond with a status: NotSupported

Some example of the use of VariableAttributes are:

9

• Report on the current power of AC-DC converter of EVSE 1:EVSE[1].AcDcConverter.Power(Value)=4kW or EVSE[1].AcDcConverter.Power=4kW

• Report or set the acceptable maximum power of AC-DC converter of EVSE 1:EVSE[1].AcDcConverter.Power(MaxSet)=5kW

• Report the design limit of power of AC-DC converter of EVSE 1: EVSE[1].AcDcConverter.Power(MaxLimit)=10kW

2.2.4. Variable Persistence

From every Variable of a Component that is writable (ReadWrite or WriteOnly) it is important toknow if the value is persistent, is it stored in non-volatile memory, will the value remain the sameeven when there is a reboot or power-failure.

During Inventory discovery operations, Charge Points SHALL report this persistence informationfor every Variable that is ReadWrite or WriteOnly, unless when the variable is persistent, then itMAY be omitted because the default is true.

2.2.5. Variable Mutability

Every Charge Point Variable instance (including secondary modes) has specific characteristics as towhether its value(s) can be be reported (read) and/or set/configured (write) that are a consequenceof the hardware and software design.

It is important for Central Systems (and their technical users) to know which Variables it canconfigure, and which it can only observe. This information can be used in conjunction withvariable Persistence data to allow the Central System to restore a Charge Point’s configurationefficiently, using the minimum amount of message traffic, after a configuration disrupting eventoccurs.

During Inventory discovery operations, Charge Points SHALL report the mutability characteristicsfor all configuration related variables (and modes) using the Variable element’s mutability fieldwhen the mutability is not the default: Fixed.

Valid mutability values are: Fixed, ReadOnly, WriteOnly, ReadWrite.

2.2.6. Enumerations

Variables that are enumerations have a list of options, of which 1 value can be active/selected. To letthe Central System known what to possible values of the enumeration are, the Charge Point SHALLsend the list of possible values via a Variable with VariableData:

• attribute set to OptionList

• type set to CSL

• value contains a CSL of all the possible values.

Enumeration values can only contain letters, number and -: [a-z][A-Z][0-0][-].

These SHALL to follow the "UpperCamelCase" (UCC) naming convention.

10

Standard Enumerations

There are a couple of standard enumerations in OCPP, these can be found in an appendix. For thesestandard enumerations, the Charge Point SHALL NOT send a list of possible values via anOptionList.

Standardized Enumerations Names

There is a list of standardized enumerations names, these are enumerations of which the name isfixed, but the list of options is not fixed. The list can be found in an appendix.

For these type of variables, the Charge Point SHALL use the method described here.

Enumeration Lists

Some variables might have a value that consists of a list of possible values. These values will berepresented as CSL (Comma Separated List)

A Variable that reports a value that consists of a list SHALL have the type field set to CSL.

The list of standardized enumeration lists can be found in the appendix.

3. Get ReportA Central System MAY request a Charge Point for its configuration/component build up using theGetReport command message. The Central System can uses this command to request informationon the current state and values of Component Variables (i.e. ChargePoint.AvailabilityState) and/orthe Monitoring criteria in effect on the Variables of the Charge Point and its sub-Components. Thiscan be used for real-time ad-hoc drill-down diagnosis of specific problems.

The set of Components and their Variables to be reported can be explicitly specified, or can bedynamically selected by the Charge Point to match specified state-based selection criteria.

In addition, the Central System can request a report for Components in a specific state or withVariables that can be configured or are used for monitoring. See ComponentCriterion for moreinformation.

3.1. Asynchronous ReportNotice ReportingA report request MUST be initially parsed (synchronously) by the charge point to determinewhether it can be processed: if the request can not be successfully parsed, a status value ofRejected MUST be returned; if it is parsed successfully, an Accepted response MUST be returned,and any failures to retrieve explicitly specified data MUST be reported in detail in the resultingreturned Notice (see below).

Since a GetReport.req can result in a lot of data to be send from the Charge Point to the CentralSystem The data asked for is send asynchronous with one or more ReportNotice.req messages. Thisalso helps for information that the Charge Point controller needs to request from sub-componentswhich may have slow response times,

11

Central System Charge Point

GetReport.req(requestId = 10)

GetReport.req(status = Accepted)

loop [more then 1 possible]

ReportNotice.req(requestId = 10)

ReportNotice.conf()

The Charge Point MAY use multiple ReportNotices to report all requested information. AllReportNotice.req messages (except the last) SHALL have the field tbc set to true to designate moreinformation will follow. The last Notice MAY contain the field tbc, if so, it SHALL be set to false.

3.2. Inventory Discovery ReportingA Charge Point can provide a huge amount on information through the GetReport/ReportNoticemessages. To limit the amount of information the Central System wants to receive in a certainscenario. By using the optional ReportBase element of a GetReport.req, a Central System canrequire a Charge Point to provide any of five standard forms of extensive self descriptioninformation:

• Capability Inventory: Supported Profiles, Options, and Associated Limits

• Configuration Inventory: Supported Configuration Settings

• Charging Inventory: Charging Capabilities

• Summary Inventory: Charge Point Availability & Condition

• Full Inventory: All Charge Point Components & Variables (Default)

3.2.1. Capability Inventory: Supported Profiles, Options, and AssociatedLimits

A Central System can use the CapabilityInventory ReportBase to discover a high-level view ofwhich OCPP Profiles a Charge Point supports, along with associated operating sub-modes/options,and cardinality limits that apply to repeating elements in related OCPP messages and datastructures in the Charge Point.

A GetReport.req message with ReportBase = "CapabilityInventory" requires the Charge Point toreturn a report containing:

TODO: Describe what should be reported here, should be representing what is described in: ProfileManagement Component. Including all message/list limits, min/max values etc.

12

TODO: Charge Points that do not implement the Monitoring & Control MUST respond by returning acorresponding Notice, but are NOT REQUIRED to include any specific data, except to report thesupported OCPP Profiles, (using the Profile Management Components), and also any standardizedbehavioral/semantic options relating to supported Profiles. In addition, the cardinality limitsapplicable to each profile must be reported using the standardized cardinality count variablesassociated with each Profile Management Component.

TODO: Charge Points are NOT REQUIRED to include any Values, MinSet, MaxSet, or Target data. Thisallows the response to be a pre-prepared static string.

3.2.2. Configuration Inventory: Supported Configuration Settings

A Central System can use the ConfigurationInventory ReportBase to discover which facets of aCharge Point are externally controllable/configurable via SetConfiguration.req. The Charge PointSHALL return a comprehensive report containing an exhaustive enumeration of all configurableoptions on a Charge Point.

In addition to reporting the current value of each supported configuration variable, Charge PointsMUST also report the supported range of settable values, min/max, possible values (CSL)

3.2.3. Charging Inventory: Charging Capabilities

A Central System can use the ChargingInventory ReportBase to discover all the information fromthe Charge Point about its charging capabilities.

For the ChargePoint Component, all of the following Variables.

• Power(MaxLimit) (design/locally configured)+ Power(MaxSet) if different

• Current(MaxLimit) (design/locally configured)+ (MaxSet) if different (per Phase)

• PowerType

• Voltage (Incoming)+ per phase, if available

• SupplyPhases (MaxLimit=design, MaxSet=Incoming)

• PhaseRotation, relative to nominal incoming reference (for groups/pools)

For each EVSE Component:

• {Available, Enabled, Problem } boolean state variables

• Charge Controllers:

• {CPPWMController,CHAdeMOController,ISO15118Controller}

• {Available, Enabled, Problem} boolean status flags

• Where different from ChargePoint

• Power(MaxLimit) + (MaxSet) if different

13

• Current(MaxLimit) + (MaxSet) if different (per Phase)

• PowerType

• SupplyPhases (Incoming)

• PhaseRotation

For each Connector Component (per EVSE):

• {Available, Enabled, Problem } boolean state variables

• ConnectorType

• Where different from parent EVSE

• Power(MaxLimit)+ (MaxSet) if different

• Current(MaxLimit)+ (MaxSet) if different (per Phase)

• SupplyPhases (used)

• PhaseRotation

• Charge Controllers:

• {CPPWMController,CHAdeMOController,ISO15118Controller}

• {Available, Enabled, Problem} boolean status flags

Components that are (physically/logically) present, but non operational (Available=0) due to localconfiguration or problems MUST be reported as such.

3.2.4. Summary Inventory: Charge Point Availability & Condition

A Central System can use the SummaryInventory ReportBase to retrieve a summary reportrelating to the Charge Points current charging availability, and to any existing problem conditions.

• For the ChargePoint Component:

• AvailabilityState of Charge Point (overall)

• For each EVSE Component:

• AvailabilityState

• For each Connector Component:

• AvailabilityState [if known and different from EVSE]

• For all Components in an abnormal State

• Active {Problem, Tripped, Overload, Fallback} variables

• Any other diagnostically relevant Variables of the Component

• Including TechInfo where available

14

• All monitored Component.Variables in Critical or Alert state

3.2.5. Full Inventory: All Charge Point Components & Variables

This is the default value for ReportBase when omitted in a GetReport.req. No limit on what toreport: The Charge Point SHALL fully describe itself, so that a comprehensive logical model of itscapabilities, configuration, and state can be automatically built up in the Central System.

It is typically used immediately after a successful BootNotification for a Charge Point that is beingnewly enrolled, or has been out of contact for an extended period of time, or after the CentralSystem has lost its confidence in its previously held version of the Charge Point’s State (e.g. after anextended outage or system failure of the Central System).

A GetReport message with ReportBase = "FullInventory" requires the Charge Point to return acomprehensive report of its capabilities, configuration, and state.

The report can still be limited via the other fields in a GetReport.req message.

4. Set ConfigurationA Central System may request a Charge Point to change its current configuration state using theSetConfiguration.req command message.

This can be used, for example, to adjust common configuration parameters (e.g. Heartbeat interval),to disable specific faulty sub-components (e.g. Connector 2 of EVSE 2), and/or to enable/disableparticular functionality (e.g. Local Pricing, under-frequency charging suspension).

Each SetConfiguration.req PDU can contain information to change one or more Variables.

A SetConfiguration command request SHALL be initially parsed (synchronously) by the ChargePoint to determine whether every Component/Variable instance combination is known. Each failedComponent Variable instance combination MUST be repeated with all addressing fields in theSetConfiguration.conf, but with an appropriate VariableStatus value, such as InvalidValue,NonExistent, etc. See VariableStatus for all possible values.

Setting Variables can be optionally qualified using the variableAttribute field (See section 7.13.21) toset lower and upper ranges, where appropriate.

Note: This mechanism replaces the ChangeConfiguration key-value based mechanism of previousOCPP versions.

4.1. Asynchronous ConfigurationNotice ReportingA Charge Point SHALL respond to a SetConfiguration.req as soon as possible with aSetConfiguration.conf. There might be hardware in a Charge Point that takes longer to makechanges to then that. To cope with this, another message has been introduced: ConfigurationNotice.By answering in the SetConfiguration.conf with the status: Pending, the Charge Point can notify theCentral System that the requested change has not yet been made and that a ConfigurationNotice.reqwill be send to update the Central System.

15

A Charge Point is not required to implement this asynchronous mechanism if there is no hardwarethat is "slow" to update.


SetConfiguration.req(requestId = 10)

SetConfiguration.req(status = Pending)

opt Asynchronous notifications


ConfigurationNotice.req(requestId = 10)

ConfigurationNotice.conf()

The Charge Point MAY use multiple ConfigurationNotices to report on all outstanding requestedchanges. All ConfigurationNotice.req messages (except the last) SHALL have the field tbc set to trueto designate more information will follow. The last Notice MAY contain the field tbc, if so, it SHALLbe set to false.

4.2. Standardized Configuration Component.VariablesCombinationsThe table below describes standardized Component.Variable configuration settings that a ChargePoint MAY support. (See sections 7.3.3 and 7.4.5 for detailed definitions and examples of thesemantics of standardized Component / Variable combinations).

Implementers are NOT REQUIRED to support Component.Variable combinations that are notrelevant to the capabilities of the Charge Point design/specification.

Conversely, where standardized functionality is part of the Charge Point design/specification,implementers are REQUIRED to support the standardized mechanism for the control/reporting ofthat functionality.

TODO: The 1.6 Configuration Keys need to be mapped to DeviceModel Variables, including whichare required and optional.

Examples:

• All Charge Points must send Heartbeats if/when required: therefore, support for the heartbeatinverval configuration setting of the main controller is mandatory:

• Controller.Interval[Heartbeat]

• A Charge Point that is specified/warranted/advertised as supporting Time Zone Offsets and

16

Daylight Saving Time must support:

• Clock.TimeOffset[Now]

• Clock.TimeOffset[NextTransition]

• Clock.Time[Now]

• Clock.Time[NextTransition]

Component Variable Variable Key Values

BeaconLighting Percent Intensity

ChargePoint Power(MaxSet)

Now

ChargePoint Current(MaxSet)

Now

ChargingStatusIndicator

Count BlinkRepeat

Clock Time Now

Clock Time NextTransition

Clock TimeOffset Now

Clock TimeOffset NextTransition

Controller\{} Interval Heartbeat

Controller\{} Interval Reboot

Controller\{} Time Reboot

Controller\{} Tries ResetTries

ControlMetering\{[EVSE]}

OptionsSet MeterValueSampledData


OptionsSet TxnStoppedSampledData


Interval MeterValueSampleInterval

Display HeightInChars Height

Display WidthInChars Width

EVSE Power(MaxSet)

Now

EVSE Current(MaxSet)

Now

Firmware VersionNumber FirmwareVersion

17


FiscalMetering\{[EVSE]} Interval ClockAlignedDataInterval

FiscalMetering\{[EVSE]} DataText MeterValuesAlignedData

FiscalMetering\{[EVSE]} DataText TxnStoppedAlignedData

LocalPowerController Enabled

LocalPowerController Mode UFLSMode Autonomous,Confirmed, Central

LocalPowerController Interval AUFLSStartWait

LocalPowerController Interval AUFLSStopWait

LocalPowerController Frequency AUFLSStartConstraint

LocalPowerController Frequency AUFLSStopConstraint

OverCurrentBreakerRecloser

Enabled Reclose


Mode RecloseMode None, Auto,Commanded


Count AttemptsAllowed


Interval RetryWait


Interval BackoffWait


Interval OvercurrentTestInterval

PlugRetentionLock Enabled RetainPlug

RadioLink ICCID CurrentICCID

RadioLink ServiceURL CentralSystemNow

RadioLink ServiceURL CentralSystemNext

RadioLink PLMN PLMNNow

RadioLink PLMN PLMNPref1

RadioLink PLMN PLMNPref2

RCDRecloser Enabled Reclose

RCDRecloser Mode RecloseMode None, Auto,Commanded

18


RCDRecloser Count AttemptsAllowed

RCDRecloser Interval RetryWait

RCDRecloser Interval BackoffWait

RCDRecloser Interval RCDSelfTestInterval

SelfTest Interval SelfTestInterval

SessionCoster Enabled DoCostDisplay

SessionCoster Interval GetCost

TokenReader Enabled TokensRequired

WiredLink ServiceURL CentralSystemNow

WiredLink ServiceURL CentralSystemNext

5. Monitoring"Monitoring" is the collective term for any of the mechanisms that a Charge Point may use tobecome aware that a significant change or condition is occurring that must be reported to theCentral System, if enabled by configuration to do so.

In practice, Monitoring activity in a Charge Point is typically triggered in the controller byhardware interrupts, polling of input sensors, or by a controller receiving an error value from anintelligent component (e.g. RFID reader module) or sub-controller.

The following tables shows all the messages that are part of Monitoring. (Also which message arerequired to be implemented.)

Message Required Description

EventNotice Yes See: Monitor Reporting

GetMonitoring No See: Get Monitoring

SetMonitoring No See: Set Monitoring: Configuration of Monitoring

SetMonitoringBase No See: Base Monitoring Configurations

SetMonitoringLevel No See: Monitoring Level

5.1. Variable MonitorsIn the Device Model, monitoring is controlled by the optional monitoring field of a Variable. Thisfield of type <<monitoring-class,Monitoring, consists of the following fields:

Monitoring

19

alertUpper

alertLower

criticalUpper

criticalLower

delta

deltaSeverity

periodic

clockAligned

With these monitoring types alerting (alert, critical), delta monitoring and periodic monitoring ispossible.

5.1.1. Alerting: Alert & Critical Monitoring

"Alerting" is the detection that a monitored Component’s Variable’s value has exceeded a reportingthreshold. Alerting is primarily intended to apply to Variables that have the characteristics of acontinuous analogue quantity, such as Voltage, Temperature, etc.

There are two grades of seriousness of alerting, Alert and Critical, and two possible directions ofmovement away from the normal range (Upper and Lower), so there are four alerting thresholdsthat can be configured: alertLower, alertUpper, criticalLower, criticalUpper.

5.1.2. Delta Value Change Monitoring

Delta Value monitoring is the detection that a Variable’s current Value has changed (up or down) bymore than the configured delta threshold from the last reported delta monitoring value. Deltamonitoring is useful when it is desired to gather data over time about changes in the value of aVariable that has a wide range of acceptable values. The (absolute) change in value of a Variablethat will trigger a Delta reporting Notice is specified using the Component Variable’s delta field.

A typical use of delta monitoring, especially when troubleshooting, would be to capture progressivechanges in Charge Point supply voltage or device temperature.

Delta monitoring with an integer delta value of 1 (one) can be specified for a Boolean variable thatonly has values of 1 and 0 (true and false). This can be applied to important Component Variablessuch as Problem and Active to enable the reporting of every change in such variables (e.g.Component entering/leaving a problem/fault state; Component active/inactive.

Similarly, delta monitoring of Enumeration type Variables can be activated by setting delta=1: i.e.every valid value of an enumeration type variable is considered to have an equivalent (unstated)integer numeric index.

5.1.3. Periodic Monitoring

In some cases it is desirable to capture the value of particular Variables at regular intervals,

20

irrespective of whether they have changed or not.

"Periodic" monitoring allows the reporting of the value of specific Variables at fixed intervals.

The sampling interval (in seconds) is specified using the Component Variable’s periodic field. Whenthe clockaligned field is true, periodic sampling is clock-aligned to trigger at midnight and eachsuccessive periodic interval from midnight.

5.2. Set Monitoring: Configuration of MonitoringA Central System can use the SetMonitoring.req message to configure/tune the Monitoring criteriafor a Variable.

For each specified Component Variable, the Monitoring control fields (alertUpper, criticalUpper,alertLower, criticalLower, delta, periodic, and clockaligned) can be specified to control how andwhen the Variable’s state or state change events are reported.

5.3. Monitor ReportingWhen any monitor is triggered, the Charge Point SHALL send an EventNotice.req

The Charge Point MAY combine a set of (related) events into a single EventNotice.req, but is free touse multiple EventNotices.

Events that are related to an ongoing transaction SHALL contain the related transactionId in theEvent.

Events with the field: trigger set to: Periodic SHALL have the field: severity set to Notice.

5.3.1. Cleared Event Reporting

Events with Trigger: Alerting will have a begin and an end. Example: A certain variable going overa certain "critical" level is the beginning of an event. When the variable goes below the "critical"level that will be the end of the event.

Events that have been reported with Trigger: Alerting SHALL be reported "cleared" when the eventis over.

Cleared events SHALL be reported in an EventNotice.req in the field: ClearedEvent.

When the monitoring configuration is changed: Monitoring Level, Monitoring Base or SetMonitor,while an event was not yet cleared, the Charge Point SHALL still send an "event cleared", when theevent is cleared, even when the Monitor would no longer be trigger due to changed monitoringconfiguration.

TODO: Should we require a Charge Point to report any not cleared event after an acceptedBootNotification.conf? So the Central System knowns which Event is not cleared? (Basicly theCentral System can mark any not cleared event as cleared if it is not reported after abootnotification…)

21

5.4. Get MonitoringA Central System can request a Charge Point to report its current Monitoring configuration usingthe GetMonitoring message. The Charge Point replies to the Central System with a GenericStatus toindicate whether the request is Accepted, Rejected, or Not-Supported.

The main information "reply" to a GetMonitoring is sent asynchronously by the Charge Point, usingone (or more) ReportNotices.


GetMonitoring.req(requestId = 10)

GetMonitoring.req(status = Accepted)


ReportNotice.req(requestId = 10)

ReportNotice.conf()

The Charge Point SHALL report all Variable/Component combinations that have Monitoring setup.(Factory default or set via SetMonitoring.)

By setting the Monitoring Base (SetMonitoringBase.req) and then calling GetMonitoring.req theCentral System can retrieve the factory installed monitors for the different monitoring baseconfigurations.

5.5. Base Monitoring ConfigurationsCalling SetMonitoringBase.req is like calling a factory reset on all the configured monitors, and inthe same time setting a new set of factory default monitors.

It is desirable to avoid Charge Point network operators having to specify Monitoring configurationfrom scratch, for every make and model of Charge Point. A Charge Point’s designers are best placedto know what variable values and states can be measured inside the Charge Point, and to decide onan initial default set of events/states that can and should be monitored in normal operation.

This is the FactoryDefault monitoring configuration, for normal operational use. Other standardstarting configurations are None, Minimum and All.

The monitoring base configuration can be set with the message: SetMonitoringBase.req. When aCharge Point receives and accepts the new monitoring base with a SetMonitoringBase.conf, theCharge Point SHALL set the monitors to the factory configured set belonging to the givenmonitoring base. This means that any monitor set via the SetMonitor.req message SHALL beremoved, and/or replaced by the monitor from the select monitoring base.

22

It is allowed for manufacturers of Charge Point to make no difference between All, FactoryDefaultand/or Minimum, meaning, for example: switching from monitoring base: FactoryDefault toMinimum will make no difference.

5.6. Monitoring LevelTo have some more control over the amounts of EventNotice.req send from the Charge Point to theCentral System, the Central System can set a monitoring level on the Charge Point by sending aSetMonitoringLevel.req.

After the Charge Point receiving this request, it SHALL only report events via EventNotice.req witha severity level equal or lower than the set level.

The default level set in a Charge Point SHALL be: Warning.

The set Monitoring Level SHALL be persistent over power cycles/resets etc.

TODO: Do we need a way to retieve the current MonitoringLevel of a Charge Point?

6. Minimum Device Model SupportRequirementsTODO define exactly what is minimum. Replacement for required Configuration Keys should berequired. The following messages should be required: SetConfiguration(sync only), GetReport,ReportNotice and EventNotice messages Al the rest can be optional, so configurable monitoring canbe optional.

old text:

Since designs of Charge Points can vary widely in complexity, not all components are present in allCharge Points. It is therefore neither useful nor necessary to require manufacturers to report on allpossible components. In addition, depending on the sophistication of a charge point’s design, it mayhave the ability to report on few or many of its internal components using the Device Model.

Note: Notwithstanding the above, to enable fully effective "Plug and Play" usability, procurers ofCharge Points, and/or procurement specification writers (such as a network operators) MAY requirethat Charge Points MUST report the presence, availability, and type of some or all significantcomponents, including those that may be incapable of reporting their condition or being controlledvia OCPP.

Even for Charge Points not implementing the Device Management profile, there is a minimum setof logical Components and associated Variables that MUST always be represented in the model.These provide a minimal replacement for the equivalent functionality of the obsolete and removedStatusNotification message that was used in previous versions of OCPP. This minimum "basic"device model is described in the Core Profile in Chapter 5.3 Minimum(Basic) Device Model.

23

7. Messages

7.1. ConfigurationNoticeSee: Asynchronous ConfigurationNotice Reporting for more details.

7.1.1. ConfigurationNotice.req

TODO

Field Name Field Type Card. Description

requestId String40 0..1 Optional. SHALL be set to the value of the requestId inthe SetConfiguration.req that triggered this change, if itwas set.

at dateTime 1..1 Required. Timestamp for the moment these changeswere made.

tbc boolean 0..1 Optional. (To Be Continued) (false when omitted) whenset to true, this indicates the ConfigurationNotice is splitover multiple messages.

status ConfigurationStatus 1..* Required. Details of the result of the (attempted)change(s) that were reported earlier in aSetConfiguration.conf with a status Pending.

7.1.2. ConfigurationNotice.conf

This contains the field definition of the ConfigurationNotice.conf sent by the Central System to theCharge Point as response to a ConfigurationNotice.req PDU.

No fields are defined.

7.2. EventNoticeTODO

See Monitor Reporting for a more detailed description.

7.2.1. EventNotice.req

TODO


tbc boolean 0..1 Optional. (To Be Continued) (false when omitted) whenset to true, this indicates the EventNotice is split overmultiple messages.

24


event Event 0..* Optional. List of (new) events, one EventNotice messagecan contain a number of notices, it is up to the ChargePoint to combine one or more Notices in 1 EventNoticesas the Charge Point sees fit.

cleared ClearedEvent 0..* Optional. List of cleared notices, one EventNoticemessage can contain a number of cleared notices.

7.2.2. EventNotice.conf

This contains the field definition of the EventNotice.conf sent by the Central System to the ChargePoint as response to a EventNotice.req PDU.


7.3. GetMonitoringThis message requests that the Charge Point send one (or more) ReportNotices describing allMonitoring currently in effect, including both hardwired and configurable monitoring ofcontinuous/analogue variables, and reported transitions of logical state Variables such as Activeand Problem.

See Get Monitoring for a more detailed description.

7.3.1. GetMonitoring.req


componentCriterion

ComponentCriterion

0..* Optional. If specified, Monitoring criteria only apply toComponents that, at the time, match at least one of thegiven Component overall States. When one or moreComponentCriterion are given, they should belogically ORed.

variableReference

VariableReference 0..* Optional. A filter for limiting the response based on thevariable references given. Wildcards can be used asfollows: If componentKey is "", monitors for allcomponents will be reported. If valueKey is "",monitors for all values of that component will bereported. If EVSE is not specified, events for all EVSE’swill be reported. If Connector is not specified, eventsfor all Connectors will be reported.

requestId String40 0..* Optional. Provides a unique request reference to beincluded as the requestId field on resultingReportNotices, to facilitate their processing by theCentral System.

25

7.3.2. GetMonitoring.conf

This is the reply of the Charge Point after receiving a GetMonitoring.req.


status GenericStatus 1..1 Required. Indicates whether the report request wasAccepted, Rejected, or Not Supported

7.4. GetReportSee: Get Report for more details.

7.4.1. GetReport.req

This contains the field definition of the GetReport.req PDU sent by the Central System to the ChargePoint.


reportBase ReportBase 0..1 Optional. Specifies one of the common preset reportingsets:, or None

componentCriterion

ComponentCriterion

0..* Optional. If specified, Component criteria only apply toComponents that, at the time (in the future), match atleast one of the given Component overall States. Whenone or more ComponentCriterion are given, theyshould be logically ORed.

variableReference

VariableReference 0..* Optional. A filter for limiting the response based on thevariable references given. Wildcards can be used asfollows: If componentKey is "", all components will bereported. If valueKey is "", all variables of matchingcomponent will be reported. If EVSE is not specified,components/variables for all EVSE’s will be reported. IfConnector is not specified, components/variables for allConnectors will be reported.

requestId String40 0..1 Optional. Provides a unique request reference to beincluded as the requestId field on resultingReportNotices, to facilitate their processing by theCentral System.

7.4.2. GetReport.conf

This is the reply of the Charge Point after receiving a StateReport.req.

26


status GenericStatus 1..1 Required. Indicates whether the report request wasAccepted, Rejected, or Not Supported. Details of therequested data and any failures are reportedasynchronously in one or more EventNotice.req PDUs.

7.5. ReportNotice

7.5.1. ReportNotice.req

This contains the field definition of the ReportNotice.req PDU sent by the Charge Point to theCentral System.


requestId String40 0..1 Optional. An id that can be used to refer to the specificevent. UUIDs MAY be used.

at dateTime 1..1 Required. Timestamp for the event.

tbc boolean 0..1 Optional. (To Be Continued) (false when omitted) whenset to true, this indicates the ReportNotice is split overmultiple messages.

variable Variable 1..* Required. TODO

7.5.2. ReportNotice.conf

This contains the field definition of the ReportNotice.conf PDU sent by the Central System to theCharge Point as response to a ReportNotice.req PDU.


7.6. SetConfigurationSee: Set Configuration for more details.

7.6.1. SetConfiguration.req

This contains the field definition of the SetConfiguration.req PDU sent by Central System to ChargePoint.


setData SetData 1..* Required. Information about the Component/Variableinstance to be changed.

27


requestId String40 0..1 Optional. Provides a unique request reference to beincluded as the requestId field on the optionalresulting ConfigurationNotices when the result isreturn asynchronous, to facilitate their processing bythe Central System.

7.6.2. SetConfiguration.conf

This contains the field definition of the SetConfiguration.conf PDU returned from Charge Point toCentral System.


status ConfigurationStatus 1..* Details of the result of the (attempted) change(s), if aVariable or Component instance defined in theSetConfiguration.req is not known by the Charge Point,this field should return any unknownComponent/Variable here.

7.7. SetMonitoringThis message enables the Central System to tune/configure Monitoring criteria for a Variable.

See: Set Monitoring: Configuration of Monitoring for more details

7.7.1. SetMonitoring.req


variableReference

VariableReference 1..1 Required. Contains reference information about thevariable: name and key, and to which component thisvariable belongs (again name and key).

monitoring Monitoring 0..1 Optional. Carries the current monitoring criteria forthis Variable. If omitted all monitoring criteria SHALLbe cleared/removed, even factory installed monitorscurrently active/set.

7.7.2. SetMonitoring.conf

TODO


status GenericStatus 1..1 Required. Returns whether Monitoring change hasbeen accepted and processed

28

7.8. SetMonitoringBaseTODO

See: Base Monitoring Configurations

7.8.1. SetMonitoringBase.req

TODO


monitoringBase

MonitoringBase 1..1 Required. Requested monitoring base to be set.

7.8.2. SetMonitoringBase.conf

TODO


status GenericStatus 1..1 Required. Returns whether monitoring base change hasbeen accepted.

7.9. SetMonitoringLevelTODO

See: Monitoring Level

7.9.1. SetMonitoringLevel.req

Request the Charge Point to set a monitoring severity level. After the Charge Point receives thisrequest it SHALL only report events via EventNotice.req with a severity level equal or lower thanthe set level.


severityLevel

Severity 1..1 Required. Monitoring level to be set.

7.9.2. SetMonitoringLevel.conf

TODO


status GenericStatus 1..1 Required. Returns whether monitoring level change hasbeen accepted.

29

8. Device Model TypesThe Device Model is organized around Components, Variables and Values as shown the followingfigure:

TODO Add new class diagram,show how a variable is build up.

8.1. ClearedEventClass

Used to notify the Central System about an Event being cleared.

See Cleared Event Reporting for more details.

Used in: EventNotice.req


id String40 1..1 Required. Unique id of the Event this is now cleared.UUIDs MAY be used.

at dateTime 1..1 Required. Timestamp when this event was cleared.

8.2. ComponentCriterionEnumeration

It is used GetMonitoring.req, GetReport.req and SetMonitoring.req. It specifies values (orcombinations of values) of the common component state boolean variables (Available, Active,Fallback, Problem) and the presence of active Monitoring on any of the component’s Variables asqualification criteria for selection.

Where multiple ComponentCriterion values are used in combination, the result is the logical "OR"of the individual criteria.

Value Description

Active Component is in Active state (Available)

Available Component is Available (but not necessarily remotely Enabled)

Enabled Component is Enabled (Remotely or hard wired)

Fallback Component is in Fallback state (e.g. backup mode) (implies Available)

Problem Component is in Problem state (implies Available)

AnyAlertVariables

Report all Variables and Components where the monitoring field of the Variable isalertUpper or alertLower.

30

Value Description

AnyCriticalVariables

Report all Variables and Components where the monitoring field of the Variable iscriticalUpper or criticalLower.

AnyDeltaVariables

Report all Variables and Components where the monitoring field of the Variable isdelta.

AnyPeriodicVariables

Report all Variables and Components where the monitoring field of the Variable isperiodic.

8.3. ConfigurationStatusClass

TODO

Used in: ConfigurationNotice.req and SetConfiguration.conf


variableReference

VariableReference 1..1 Required. Reference of the variable this status updatebelongs to.

status VariableStatus 1..1 Required. Status of the request change.

8.4. EventClass

An Event contains the information about a monitor being triggered.

Used in: EventNotice.req


id String40 0..1 Optional. Unique id that can be used to refer to thespecific event. UUIDs MAY be used.Required for events with trigger: Alerting, because thisid is needed to clear the event.

cause String50 0..1 Optional. Cause of the event.

trigger Trigger 1..1 Required. Indicates why the event message wastriggered.When this field is set to: Periodic the field: severitySHALL be set to: Notice

severity Severity 1..1 Required. Indicates the severity level of the event.

at dateTime 1..1 Required. Timestamp for the event.

31


transactionId

TransactionId 0..1 Optional. When this notice is relevant for a transaction,and the TransactionId is known, this field SHALL be setto the relevant TransactionId. (TODO: is this the correcttype?)

variableReference

VariableReference 1..1 Required. Reference to the Variable/Component thisevent belongs to.

value String255 1..1 Required. contains the value of this variable on themoment the monitor was triggered.

8.5. MonitoringClass

Used in: SetMonitoring.req and Variable


alertUpper decimal 0..1 Optional. Upper alerting level threshold

alertLower decimal 0..1 Optional. Lower alerting level threshold

criticalUpper

decimal 0..1 Optional. Upper critical level threshold

criticalLower

decimal 0..1 Optional. Lower critical level threshold

delta decimal 0..1 Optional. Minimum absolute variable value change(from previously reported) to trigger further report.Monitoring and reporting of changes in Boolean (1/0)and Enumeration type state variables of anyComponent (e.g. Active, ChargeProtocol) can beactivated by setting delta=1

deltaSeverity

Severity 0..1 Optional. Sets the severity level of a change eventtriggered by the set delta

periodic integer 0..1 Optional. Time interval, in seconds, between periodicreports of Variable value.

clockAligned

boolean 0..1 Optional. When true, periodic sampling is clock-alignedto trigger at midnight and each successive periodicinterval from midnight

8.6. MonitoringBaseEnumeration

Possible values for standard monitoring configurations

32

Used in: SetMonitoringBase.req

Value Description

All Monitor & report everything that can be reported

FactoryDefault

Standard monitoring for normal operational use

None No monitoring base: no factory monitors. Only explicitly specified monitorsconfigured after setting monitoring base None.

Minimal Only monitor & report critical states and fault events that impact the safety orusability of the Charge Point

8.7. ReportBaseEnumeration

Standard reporting configurations for GetReport

See Section 7.7 for definition of Summary Inventory contents, including derogations applicablewhen Monitoring & Control profile is not implemented.

Used in: GetReport.req.

Value Description

CapabilityInventory

See Capability Inventory: Supported Profiles, Options, and Associated Limits for adetailed definition of the content.

ChargingInventory

See Charging Inventory: Charging Capabilities for a detailed definition of thecontent.

ConfigurationInventory

See Configuration Inventory: Supported Configuration Settings for a detaileddefinition of the content.

FullInventory Default. Full Inventory: All Charge Point Components & Variables See for adetailed definition of the content.

SummaryInventory

See Summary Inventory: Charge Point Availability & Condition for a detaileddefinition of the content.

8.8. SetDataClass

TODO

Used in: ConfigurationNotice.req and SetConfiguration.req

33


variableReference

VariableReference 1..1 Required. TODO

attribute VariableAttribute 0..1 Optional. TODO

value CiString255 1..1 Required. The value that is requested to be set. TODO

8.9. SeverityEnumeration

Severity of an event This contains the field definition of the

Used in: SetMonitoringLevel.req, Event and Monitoring

Value Level Description

Emergency 0 System is unusable

Alert 1 Action must be taken immediately

Critical 2 Critical conditions

Error 3 Error conditions

Warning 4 Warning conditions

Notice 5 Normal but significant condition

Informational

6 Informational messages

Debug 7 Debug-level messages

8.10. TriggerEnumeration

Reason category for creation of Notice

Used in: Event

Value Description

Alerting Monitored variable has passed an Alert or Critical threshold. An event if this typeneeds to be explicitly cleared.

Delta Delta Monitored Variable value has changed by more than specified amount

Periodic Periodic Monitored Variable has been sampled for reporting at the specifiedinterval

34

8.11. VariableClass

Used in: ReportNotice.req


reference VariableReference 1..1 Required. Contains reference information about thevariable: name and key, and to which component thisvariable belongs (again name and key).

data VariableData 1..* Required. TODO Do we really need a list of these? listwithin a list? If not, should we move value (or datumto this class?

parameters VariableParameters 0..1 Optional. TODO

monitoring Monitoring 0..1 Optional. Carries the current monitoring criteria forthis Variable. If omitted this Variable has no monitoringcapabilities. So no monitoring is in place and nomonitoring can be set.

8.12. VariableAttributeEnumeration

Specifies a particular sub-mode of a device model Variable instance being referenced duringreporting (read) and setting (write) operations.

See Variable Attribute for a description on the use of VariableAttribute.

Used in: VariableData

Value Description

Value(default)

From Charge Point: _ Actual Variable Value (e.g. configuration setting or sensorreading). To Charge Point: Configuration "Setting" or "Target" value(see entries below) _ Value is the implicit default for Variable data value transfersand need not be specified.

Target Value is (specified or default) modifiable and reportable target set-point.Read/reported values may differ from the Target, typically where a (closed loop)control system provides feedback reading values.

MinSet Minimum value configured for variable. Specifies configuration setting of lowerlimit of allowable range when sent to a Charge Point.

MaxSet Maximum value configured for variable. Specifies configuration setting of upperlimit of allowable range when sent to a Charge Point.

OptionList Supported/allowed values for a single choice enumerated Variable, like anenumeration.

35

8.13. VariableDataClass

TODO

Used in: Variable


attribute VariableAttribute 0..1 Optional. Used to specify whether this variable containsthe actual value of the Variable (Attribute is "Value") orone of the associated attributes of this variable, such asMaxSet, MaxLimit, etc.Default, when omitted: Value

mutability VariableMutability 0..1 Optional. Used to specify setting (default), or rangeminimum, or maximum for values, and to report thenature of the reported data. Default, when omitted:Fixed This field is used only in PDUs sent by a ChargePoint.

persistence boolean 0..1 Optional. SHALL only be used for Variables with withmutability: WriteOnly or ReadWrite. Used to specify ifthis variable is persistent, in other words, is it stored innon-volatile memory, will the value remain the sameeven when there is a reboot or power-failure. Default,when omitted: true This field is used only in PDUs sentby a Charge Point.

type VariableType 1..1 Required. data type of this variable. Helps to interpretthe value correctly.

value String255 1..1 Required. contains the value of this variable.

techInfo String500 0..1 Optional. Can contain helpful information, for example:ID/code used by the manufacturer to describe a state ofthis Variable. It is commonly contextual technical dataassociated with an event/fault and is usually specific tothe manufacturer/model of the component.

8.14. VariableMutabilityEnumeration

Specifies the mutability characteristics of a Variable of a device model Component Variableinstance.

This field of the Variable type is used only on messages from Charge Points.

See also Variable Mutability.


36

Value Description

Fixed Unchanging read-only fixed value

ReadOnly Value may be read but not remotely set/modified. Value can change over time.

WriteOnly Value may be set/modified but can not be read back

ReadWrite Value may be reported (read) and set/modified. The value might change after ithas been set (write). For example: a clock will continue to run after it has been setto a certain value.

8.15. VariableParametersClass

TODO

Used in: Variable


unit UnitOfMeasure 0..1 Optional. Unit in which this value ismeasured/expressed.

minLimit integer 0..1 Optional. Minimum limit value for variable (e.g. designlimit)

maxLimit integer 0..1 Optional. Maximum limit value for variable (e.g. designlimit)

8.16. VariableReferenceClass

TODO

Used in: GetMonitoring.req, GetReport.req, SetMonitoring.req, ConfigurationStatus, Event, Variable


evse integer 0..1 Optional. Optional. The index of the EVSE in which thecomponent is located. If not specified, it indicates thatthe component is NOT part of an EVSE: i.e. it exists atthe overall Charge Point level. When used in a selectioncriteria context, a value of 0 (zero) means selection ofall existing "evse" values (e.g. 1 and 2)

37


connector integer 0..1 Optional. The index of the Connector in which thecomponent is located. If not specified, it indicates thatthe component is NOT part of a Connector: i.e. it existsat EVSE level, or above. When used in a selectioncriteria context, a value of 0 (zero) means selection ofall existing "connector" values (e.g. 1 and 2)

componentName

CiString50 1..1 Required. The name of the component. If possible, aname from the Standardized Component Names listSHALL be used.

componentKey

CiString50 0..1 Optional. Key to identify instance of component.

variableName

CiString50 1..1 Required. The name of the variable. If possible, a namefrom the Standardized Variable Names list SHALL beused.

variableKey CiString50 0..1 Optional. Key to identify instance of variable.

8.17. VariableStatusEnumeration

Specifies the success or failure of attempts to set or read the value(s) of a Variable of a device modelComponent Variable instance.

This field of the Variable type is used only on messages from Charge Points.

See Section 7.4.3 for more an overview of VariableStatus.

Used in: ConfigurationStatus

Value Description

OK (Default) Set/Read operation successful. This is the default value implied when an optionalVariableStatus is omitted.

InvalidValue Attempted setting/modification of Variable was rejected because the value wasinvalid (e.g. malformed, invalid datatype, etc.)

NonExistent Component[evse][connector][key].Variable[key] does not exist.

NotAvailable Value data logically exists but is not (currently) available (e.g. because theresponsible hardware is disabled/powered off)

NotSupported The functionality associated with an attempted configuration setting Value cannot be executed/activated because it is not supported.

OutOfRange Attempted setting/modification of Variable was rejected because the value wasout of range.

38

Value Description

Pending Making changes to this variable have not been finished, result will be reported ina ConfigurationNotice.req. This value is set in a SetConfiguration.conf when makethe changes takes (too) long.

ReadFailed Value data logically exists but is not (currently) available due to a read problemfrom a device (sensor/sub-controller)

SetFailed Attempted setting/modification of Variable was not successful for reasons otherthan data validity

OtherFailure Set/Read failed for other reason.

8.18. VariableTypeEnumeration

Specifies the datatype of a variable.


Value Description

Boolean Variable is of the type Boolean, allowed values: "0" and "1", were "0" is false and"1" is true.

CiString Variable is a case insensitive text.

CSL Variable is a Comma Separated List. (Only used to report all the possible Enumvalues, or the value if multiple enumeration can be selected simultaneous.

DateTime Variable is a ISO 8601 DateTime value ([YYYY]-[MM]-[DD]T[hh]:[mm]:[ss]).

Decimal Variable is a double precision floating-point format. TODO add correct REGEX.

Enum Variable is an enumeration, represented as a String, but can only have a limitedset of possible values.

Event Not really a variable, value will always be 1. Variable only used to report an eventbegin triggered etc.

Integer Variable is a integer value, positive or negative. TODO add correct REGEX.

String Variable is a case sensitive text.

9. Appendix A: Standardized ComponentNamesThe following table contains the current list of standardized names for Charge Point components.When a component name is reported by a Charge Point it SHALL use one of the standardizednames in this list, if possible.

39

If you do come across a component that is not in the list that you want to report using OCPP, you areallowed to use your own defined name. You are kindly asked to give the Open Charge Alliance anotice of this, so we might put it into this list in the future.

The table also contains common variables for every component. These variables are not required tobe reported by a Charge Point (unless otherwise stated), but should be seen as a list that helpsimplementers get an idea of the different variables that might be use in their implementation.

Note: References to values of specific Component Variables suffixed with "(Set)" refer to the settingof that Variable to that value, either explicitly by the Central System, or as a side effect of any bulkreconfiguration (e.g. factory-reset, major firmware update).

Name Description Common Variables

AccessSensor Reports when an access door/panelis open. This may be a simpleswitch, or may also involvecircuitry and/or code that allowsthe sensor to be disarmed inadvance from generating an alertwhen a service visit is expected.

Available: Access sensor is wiredupEnabled: Access sensor isenabled to detect/reportopening/closing of accessdoor/panel.Enabled(Set)=0: Disable reportingof access.Active: Access door/panel is openTripped: An access door/panel thatneeds manual reset action hasbeen activated.Problem: A fault exists in theSensor mechanism itself.

40


AcDcConverter An AC to DC Power Converter is acomplex electromagnetic & powerelectronics component thattypically simulates a variablecurrent DC current source to forceenergy directly into an EV batterystack(s), under tight control of theEV’s battery management system.Some DC Charge Points havemonolithic power converters (e.g.single 50kW converter) perindependent EVSE, while othersmay use a "modular" approach,with the total DC output currentbeing the sum of the outputs frommultiple semi-independentmodules (e.g. 5 x 10kW). Formodular designs, eachAcDcConverter exists as a separateinstance, addressed by appropriatekey. Due to their complexity, powerconverters often contain multiplesub-systems, and have their ownsub-controller, temperaturemonitoring and cooling.

Available: Available for useEnabled: (not commanded Out ofService)Problem: some problem/faultexistsTripped: A problem requiringintervention has occurredOverload: Excessivecurrent/power consumptionDC Voltage: measured DC voltagekey: "Main": main DC outputvoltageDC Current: measured DC currentkey: "Main": main DC outputcurrentPower: measured power:key: "Main": Input powerTemperature: temperature ofconverterkey: "Main": main (e.g. IGBTheatsink)FanSpeed: Speed (RPM) of coolingfan(s)key: "Main": main/primary fan[bank]

AreaVentilation Fans (or equivalent devices) usedto ensure that EVs that requireventilation during charging, assignaled by IEC 61851 State D (+3V)(e.g. non-sealed lead-acid) are notcharged in a closed space.

Available: Area ventilationequipment wired-inEnabled: Area ventilation enabledActive: Ventilation runningProblem: fault: e.g. fanstalled/slowFanSpeed: measured or inferredfan RPM

BayOccupancySensor Charge Points (and standaloneEVSE units) can use sensors(optical, ground loop, ultrasonic,etc.) to detect whether theassociated parking/charging bay isphysically vacant, or is occupied bya vehicle or other obstruction. Thisinformation can be used make(and report) an EVSE asUnavailable

Available: Occupancy sensorequipment wired-inEnabled: Sensor is sensing foroccupancyActive: BayOccupiedPercent: percentage obstruction(for analogue sensors).

41


BeaconLighting The Beacon Lighting component, ifpresent, helps EV drivers to locatenearby charging places, and/or todetermine charging availablitystate, usually by color variation.The lighting level may beadjustable based on ambient lightlevels to maintain daytime visiblitywithout providing nuisance levelsof light intensity at night.

Available: Beacon lightinghardware wired-in Enabled:Beacon Lighting operationalEnabled(Set)=0 : Disable beaconlighting Active: OnProblem: Beacon lighting faultPercent: Lighting Level (% ofmaximum)Percent(Set)=x%: Lighting Level(% of maximum)Power: Lighting WattageColor: Displayed color (key is theAvailabilityState:Available, Faulted, Inoperative,Occupied, Reserved, Unknown.Example:BeaconLighting.Color[Available]="00FF00" (Green)BeaconLighting.Color[Occupied]="0000FF" (Blue)

CableBreakawaySensor A sensor that detects when acharging cable (captive orremovable) has been forciblypulled from the Charge Point.Although all series production EVscontain interlock circuitry toprevent the vehicle from beingdriven away while "plugged in",this could still happen due to an EVinterlock failure, a non-standardEV, impact by another vehicle, orother reasons.

Available: Hardware wired-inEnabled: Breakaway sensoroperationalActive: Breakaway (force) detectedTripped: Breakaway detected:manual check/fix required

Cache The Cache logical componentrepresents the implementation oflocal authorization responsecaching in a Charge Point, ifimplemented

Available: Cache not locallydisabledEnabled: Caching in operationActive: Entries present in CacheCount: Number of active entries incacheCount(MaxLimit): Maximumcache entries supportedInterval: Time for which cacheentries maintained

42


CHAdeMOController A CHAdeMO Controller componentcommunicates with an EV usingthe wired CANbus protocol toexchange information an controlcharging using the CHAdeMOprotocol.

Available: CHAdeMO controllerwired-up Enabled: CHAdeMOcontroller enabledActive: EV connectedComplete: Protocol session endednormallyTripped: CHAdeMO protocolterminated abnormallyProblem: CHAdeMO controllerfault

ChargePoint The entire Charge Point as a logicalentity.

Available: not faultedEnabled: Available for use (notcommanded Out of Service)Problem: Some problem/faultexistsTripped: A problem requiringlocal/manual intervention hasoccurred.Overload: Excessivecurrent/power consumptionSupplyPhases: Number of ACsupply phases connectedSupplyPhases(MaxLimit):Number of AC supply phasessupported.PhaseRotation:AC Voltage: Measured incomingAC voltage [per phase]AC Voltage(MaxLimit): Designmaximum AC voltage AC Current:Measured total AC current [perphase]Power: Measured/calculated totalpower being consumed, includingstandby/ancilliary loads.Power(MaxLimit): Total designload power, includingstandby/ancilliary loads.VoltageImbalance:CurrentImbalance:Manufacturer:Model:ECVariant:SerialNumber:OperatingTimes:OptionsSet[ComplianceProfiles]:Compliance profiles supported bycharge point (comma separatedlist)

43


ChargingStatusIndicator The Charging Status Indicator,when present, provides visiblefeedback to the user about theconnection and charging status ofan EVSE/Connector. This iscommonly in the form of multi-colored lighting.

Active: On (displaying)Color: Displayed color/intensitySee Beacon Lighting.Color

Clock The Clock component represents areal time clock component. Clocksusually (but not always) maintainaccurate time during poweroutages.

Available: TODOActive: RTC running; Fallback:running on backup power;Fallback(MaxLimit): RTC is batterybackedProblem: RTC faultTime[Now]: Current Date Time (inCentral System time)Time[Now](Set): Set local realtime clock (in Central System time)Time[NextTransition]: Nexttransition date/time (in CentralSystem time) TimeOffset[Now]:Current local time zone offset fromCentral System timeTimeOffset[Now](Set): Configurecurrent local time zone offsetTimeOffset[NextTransition]:local time zone offset from centraltime after next transitionNetworkAddress: NTP server fortime synchronization

Connector A connector denotes a means toconnect an EV to a Charge Pointwith either a socket, an attachedcable & inline connector, or aninductive coil. An EVSE cansupport multiple connectors, butonly a single connector may be"connected" (Active) and used tocommunicate and/or deliverpower at any one time. Eachconnector (per EVSE) isidentified/addressed by evse andkey fields. Logical sub-componentsof a connector (e.g.ConnectorProtection) areidentified/addressed by evse,connector, and, if necessary keyfields.

Available: Conector (n) wired-upEnabled: Connector available foruse (not commanded Out ofService);Problem: problem/fault exists(e.g. over-temperature)Tripped: A problem requiringintervention has occurred.ConnectorType: Type ofConnector (e.g. sType2)SupplyPhases: AC phasesconnectedSupplyPhases(MaxLimit): ACphases MaxPhaseRotation: AC wiring phaserotation

44


ConnectorProtection Many Charge Point designs haveConnectors that have an externalprotective mechanism to preventcontact with conductors that maybecome "live" under other failuremodes. Such protectionmechanisms are mandatory insome jurisdictions, and can takethe form of an external shutter orsliding "door" that islocked/unlocked electrically(solenoid) or mechanically (motor).For attached cable designs, aconnector holster lock mechanismmay perform a similar function.

Enabled: Protection in effect(locked except when in use)Active: UnlockedProblem: Lock/Unlock mechanismfaultTripped: protective mechanismtriggered (fuse)

Controller An embedded logic controller,usually at the ChargePoint and/orEVSE level.

Active: Controller running OKProblem: Controller faultInterval[Heartbeat]: HeartbeatintervalManufacturer: Controllermanufacturer nameModel: Controller model numberECVariant: Engineering ChangevariantSerialNumber: Controllerhardware serial numberVersionNumber: Hardwareversion numberVersionDate: Hardware versiondateMaxMsgElements: Array ofimplementation-defined limits tothe number of elements of specifictype that the Charge Point canaccept in one message. Example:MaxMsgElements[AuthorizationData]: Maximum number ofAuthorizationData elements theCharge Point can receive in onemessage.

45


ControlMetering Charge Points (and subsidiaryEVSEs) commonly use dedicatedelectrical/electronic circuitry tomonitor the electrical behavior ofcharging EVs in near real time (e.g.to check for excessive currentdraw). This logical component isoften separate from a (certified)Fiscal Meter, because the lattercannot provide overload signals orinterrupts sufficiently quickly.

Enabled: Transient overloadmonitoring activePower: Measured powerACCurrent:Measured AC current[per phase]DCCurrent: Measured DC currentDCVoltage: Measured DC voltageOptionsSet[MeterValueSampledData]: Set ofmeasurands to sample and reportwhile charging. OptionsSet[TxnStoppedSampledData]: Setof measurands to sample whilecharging and reported inTransactionStopped

CoolingSystem Fans (or equivalent devices) usedto provide cooling airflow,typically to a Charge Point overall,or to specific EVSEs.

Available: Cooling hardwarewired inEnabled: Fan(s) enabled to runActive: Fan(s) runningProblem: fault: e.g. fanstalled/slow;FanSpeed: measured or inferredfan RPM

46


Display The Display component, if present,provides information andfeedback to the user.

Available: Display wired inEnabled: Display configured toshow informationProblem: Display fault;Color: Display color(monochrome/backlighting)Count[HeightInChars]: Displayheight (characters)0 indicates no displayCount[WidthInChars]: Displaywidth (characters)0 indicates no displayDataText[Visible]: CurrentDisplay Contents LocalizedText[2-N/{State}]: State:Alphanumericcode indicating current messagepurpose: BootingVendorInfoOperatorInfoHostInfo FaultUnavailableReserved IdleWaitPresentTokenTokenReadContactingCSContactedCSAuthorizing InvalidBlockedExpiredAcceptedCallSupport SelectSchemeSelectProfileSelectConnectorConnectEVEVConnectedConnectTimeoutNegotiatingWaiting StartingChargingSuspendedConstrainedEVNotChargingEVStoppedEVOverloadTimeLimitEnergyLimitCreditLimitTerminatedDisconnectEVEVDisconnectedSummaryGoodbye

47


ELVSupply The ELV Supply componentrepresents the low voltage powersupply (typically 12V DC and oftenother ELV voltages) that providesoperating power for controllers,relays, and other electricalcomponents. It may have a backupcapability to continue to powercritical components during shortpower outages.

EnergyImportRegister:Standby/house energy meterregister readingPower: instantaneous standbypower consumptionPower(MaxLimit): Designmaximium standby powerconsumptionFallback: Running on backupenergy;Fallback(MaxLimit): =1: hasbackupStateOfCharge: backup batterySOC;Time: (estimated) operating timeon backup energy

EmergencyStopSensor Many high-power/DC ChargePoints include a highly visible"Emergency Stop" button, thatshould be pressed by the user orother nearby persons if seriousfaulty behavior is observed (e.g.smoke/flames from EV or ChargePoint). Common "Emergency Stop"button designs are usuallymechanically latching whenpushed, and require to bemanually reset. They are oftenbehind a "push to break"transparent cover, to discourageimproper use.

Active: Stop Button currentlypressedTripped: Needs manual reset

EVRetentionLock Many electric vehicle inletconnectors (especially for DCcharging) have a lockingmechanism as a safety measure toprevent it being disconnectedwhile high currents are flowing.Note: Not to be confused with thePlugRetentionLock component ,that provides equivalentfunctionality for EVSE socketslocated on the charge point.

Enabled: Retention lockingdetection in effectActive: Inlet lock active (Locked)Complete: Has unlockedProblem: Lock Problem (e.g. failedto lock/unlock)

48


EVSE The EVSE is a logical/virtualcomponent that represents theentire chain of componentsresponsible for transportingenergy from the incoming supplyto the electric vehicle (or viceversa). A Charge Point can havemultiple EVSE’s, that may be ableto communicate with and chargemultiple EVs simultaneously. Eachdistinct EVSE isidentified/addressed by key field.Logical sub-components of anEVSE (e.g. Connector, Controller)are identified/addressed by evse,and (if required) key fields.

Enabled: Ready for use (notcommanded Out of Service)Problem: some problem/faultexistsTripped: A problem requiringintervention has occurredOverload: Excessivecurrent/power consumptionSupplyPhases:PhaseRotation:AC Voltage:AC Current:DC Voltage:DC Current:Power:VoltageImbalance:CurrentImbalance:

ExternalTemperatureSensor

An external temperature sensorreports ambient air temperature,and may be used (possibly inconjunction with humiditysensor(s)) to control Ventilatorsand Fans.

Problem: Temperature sensorfaultTemperature: ambienttemperature

Firmware The Firmware componentrepresents the software installedin a controller (ChargePoint orEVSE level). Where a controllersupports multiple firmwareimages (e.g. "primary" and"backup"), keyed instances areused to represent the alternates.

Problem: Problem (e.g. boot fail,lockup detected)VersionNumber:VersionDate:

49


FiscalMetering A (usually certified) Fiscal Meterprovides energy transfer readingsthat are the basis for billing. Insimple cases, energy readings maybe taken only at start and end of acharging session, but whencomplex Time-of-Use tariffs are ineffect, intermediate readings mustbe acquired during chargingsessions.

Problem: Metering Fault (e.g. readerror)EnergyImport: Energy transferredto EV during sessionEnergyImportRegister: Energyregister readingManufacturer[Meter]: Metermanufacturer nameManufacturer[CT]: Currenttransformer manufacturer nameModel[Meter]: Meter modelnumberModel[CT]: Current transformermodel numberECVariant: Meter engineeringchange variantSerialNumber[Meter]: Meterserial numberSerialNumber[CT]: Currenttransformer serial number(s)OptionsSet[MeterValueAlignedData]: Set ofmeasurands to read and report atclock-aligned time intervals whilecharging. OptionsSet[TxnStoppedAlignedData]: Set ofmeasurands to be read at clock-aligned time intervals whilecharging and reported inTransactionStopped

FloodSensor A sensor reporting whether theCharge Point is experiencing wateringress/pooling.

Active: Water level isunacceptably highTripped: Water level safety sensortrippedHeight: Absolute water heightabove reference (ground) level.Percent: Height as percentagebetween reference minimum (0%)and maximum allowable (100%).Values below 0% and above 100%are possible.

GroundIsolationTester Some Charge Points (especially DC)may include an Isolation Tester aspart of their own self testmechanisms, to confirm theisolation of floating circuitry whenno Evs are connected (especiallyduring startup self-test).

Enabled: Electrical isolationtesting enabledActive: Isolation test in progressComplete: Isolation test completedProblem: Isolation faultImpedance: Isolationresistance/impedance

50


Heater Heaters are sometimes present inCharge Points, usually to ensurereliable operation in coldenvironments.

Enabled: Heater hardwareoperation enabledActive: Heater onProblem: Heater faultTripped: Heater equipmentpermanent faultPower: Instantaneous heaterpower levelPower(MaxLimit): Maximumheater powerPower(MaxSet): Configuredheater powerTemperature(MinSet): Cut-intemperatureTemperature(MaxSet): Cut-outtemperature

HumiditySensor A humidity sensor reports relativeair humidity, and may be used(possibly in conjunction withtemperature sensor(s)) to controlVentilators and Fans.

Enabled: TODOProblem: Humidity sensor faultHumidity: RH(%)

InternalTemperatureSensor

An internal temperature sensorreports the air temperature withinan enclosure (ChargePoint orspoke EVSE), and may be used(possibly in conjunction withhumidity sensor(s)) to controlVentilators and Fans.

Problem: Internal temperaturesensor fault Temperature:enclosure temperature

ISO15118Controller An ISO 15118 Controllercomponent communicates (wiredor wirelessly) with an EV toexchange information and controlcharging using the ISO 15118protocol.

Active: EV communicating usingISO15118Tripped: ISO15118 communicationsession abortedComplete: ISO15118communication session endedProblem: ISO15118 controllerfault

LightSensor A Light Sensor reports ambientlight levels. This may be used bythe Charge Point to regulate theon/off or brightness state ofintegral or external environmentallighting: e.g. Charge Pointbeacon/availability lighting, orambient courtesy lighting forusers, based on the environmentallight conditions.

Problem: Lighting sensor faultLight: light level (Lux)

51


LocalList The LocalList logical componentrepresents the implementation ofLocal List Profile functionality

Enabled: Local List enabled foruseActive: Entries present in LocalListCount: Number of active entries inLocal List Count(MaxLimit):Maximum LocalList entriessupported

LocalPowerController The Local Power Controllercomponent represents any locallyimplemented capability tomanage/constrain powerconsumption from the distributionnetwork for safety or otherreasons. Such control willnormally preempt and constrict orsuspend the ongoing charging ofEVs, irrespective of any centrallyspecified smart charging plan.Constraint may be completelyautonomous (e.g. based onincoming power supply frequencyalone) or may be influenced bylocal power availabilitycommunication mechanisms, suchas PLC or ZigBee signaling from alocal distribution transformersubstation.

Enabled: Local power control(override) may occurActive: Constraint in EffectComplete: Constraint in EffectProblem: Local power controllerfaultPower: Available Power;Power(MaxSet): MaximumAvailable Power;Enabled[AUFLS]: AUFLS enabledFrequency[AUFLSStartConstraint]: Autonomous Under FrequencyLoad Shedding Start ConstraintFrequency[AUFLSStopConstraint]:Autonomous Under FrequencyLoad Shedding Start ConstraintInterval[2]: UFLS StartWaitInterval[AUFLSStartConstraint]:UFLS StopWait

CPPWMController A Control Pilot PWM Controllercomponent provides and sensesthe IEC 61851-1 / SAE J1772 lowvoltage DC and PWM signalingbetween an EVSE and EV over acontrol pilot line.

Enabled: TODOActive: EV connectedProblem: CP PWM controller faultDCVoltage: Control Pilot wire DCVoltage (0-12V)State:IEC 61851-1 states ("A" to "E")Percentage: 1kHz Duty Cycle

OutOfServiceInput An OutOfServiceInput, whenpresent, can allow the host siteoperator to control the actualtimes of operation of the ChargePoint. Activation of this inputcauses the Charge Point to make(and report) itself unavailable forcharging.

Enabled: Out-of-service inputsensing in operationActive: Out-of-service statecommandedProblem: Out-of-service sensingcircuit error

52


OverCurrentBreaker Over-Current Breaker(s) protectequipment (and life) bydisconnecting the electrical supplywhen the current drawn (on anyphase) exceeds the rated value to asubstantial degree. Over-currentbreakers are not normally used tointerrupt cases where an EVexceeds the signalled maximumcurrent by a moderate amount.

Tripped: Breaker opened (manualreset required)Operated: Breaker opened andauto-reclosed


Over-Current Breakers may have amotorized recloser mechanismthat may be configured to performre-arm retries after a trip (up tosome specified number), or may beset for remotely controlled re-arming on command.

Enabled: Auto reclosing enabledActive: ReclosingActive(Set): Initiate manualrecloseComplete: Reclose cycle completedProblem: Recloser FaultMode: Reclose Mode (None, Auto,Commanded)Tries: (Re)tries taken on lastattemptTries(SetLimit): Configured autoretry count Tries(MaxLimit):Maximum auto retry count

PlugRetentionLock Many socket type connectors havelocking mechanisms to retain aninserted plug, both to prevent on-load disconnection, and to preventtheft of charging cables. Thelocking mechanism may besolenoid or motor operated, andusually has self monitoring andretry mechanisms.

Active: LockedProblem: Locking FailedTripped: Stall protection fuseblown, etc.Tries: (Re)tries taken on lastattemptTries(SetLimit): Configured autoretry count Tries(MaxLimit):Maximum auto retry count

53


PowerContactor Each EVSE channel (and/orpossibly each Connector) musthave a main Power Contactor thatswitches on and off the power tothe EV after all authorization andsafety requirements have beenmet. Power Contactors are distinctfrom safety/protection breakers,because they are designed tomake/break the maximum loadcurrent(s) on a regular basis.Because of their high switchingpower and regular operation, theyare more likely to fail than otherelectromechanical components,and one common failure mode("welded contacts") is potentiallydangerous as it can leaveconnectors energized when theyshould be safe. For this reasonPower Contactors often have so-called "mirror contacts", that allowthe detection of the "stuck closed"state.

Active: Contactor Closed (Poweron);Tripped: Mirror contact protectiontrippedProblem: Close/Open failed

PricingManager PricingManager is a logicalcomponent that represents thecapabilities of a Charge Point/EVSEto perform pricing and chargingsession costing actions (e.g.calculations and/or display). It, inconjunction with theSessionCoster componentrepresent the OCPP CompliancePricing Profile.

Enabled: Pricing (display) isenabled.Active: Pricing display is inprogressCount[PriceSchemes]: Activeprice schemesCount[PriceSchemes](MaxLimit): Maximum number of priceschemes allowed

54


RadioLink A Radio Link component providesa communications link from aCharge Point to a Central System. Itcommonly uses data modes ofmobile telephony infrastructure,such as GPRS. High resilienceimplementations may includeprovision for fallbackarrangements, such as multipleSIMs, and can be reported asmultiple RadioLink components.

Active: Radio link connectedFallback: Using BackupSIM/Network PreferenceComplete: Redio link connectionterminatedProblem: Radio communicationsfaultIMSI:ICCID;NetworkAddress: Currentnetwork addressSignalStrength:ServiceURL[1]: Current URL ofOCPP Central System service onthis link.ServiceURL[2]: New URL of OCPPCentral System service on this link,after next reboot, howsoevertriggered.

RCD A Residual Current Device (US:ground fault breaker) protectshuman life and/or downstreamequipment by quickly detectingabnormal curent flows (usuallyindicative in earth faults) in theCharge Point, cable, or EV duringcharging.

Tripped: Breaker opened (manualreset required)Operated: Breaker opened andauto-reclosed

RCDRecloser RCD devices sometimes have amotorized recloser mechanismthat may be configured to performre-arm retries after a trip (up tosome specified number), or may beset for remotely controlled re-arming on command.

Active: Reclosing in progressActive(Set): Initiate manualrecloseComplete: Reclose cycle completedProblem: Recloser FaultTries: (Re)tries taken on lastattemptTries(SetLimit): Configured auto(re)try count Tries(MaxLimit):Maximum auto (re)try count

ReservationManager ReservationManager is a logicalcomponent that represents thecapabilities of a Charge Point/EVSEto perform reservation actions.

Enabled: Reservation activity isenabled.Active: Active Reservations existCount[Reservations]: Number ofactive reservationsCount[Reservations](MaxLimit):Maximum number of reservationsallowed.

55


SelfTest SelfTest is a virtual component,representing self test mechanismsof the equipment (hardwareand/or software).

Active: Self test runningActive(Set):Start self-testComplete: Self-test endednormallyTripped: Self-test endedabnormallyProblem: Self-test fault

SessionCoster SessionCoster is a logicalcomponent, representing thecapabilities of the ChargePoint/EVSE to perform chargingsession costing calculation and/ordisplay, either locally or with theassistance of a Central System).It, in conjunction with thePricingManager componentrepresent the OCPP CompliancePricing Profile.

Enabled: Local session costingenabledActive: Local session costing inprogressComplete: Local session costingcompletedProblem: Session costingerror/fault

ShockSensor Measures impactforces/accelerations experienced(e.g. by ChargePoint or spokeEVSE), indicative of possibledamage.

Enabled: Shock sensing enabledActive: Shock event detectedForce: detected force

SmartCharging The SmartCharging logicalcomponent represents theimplementation of Smart ChargingProfile functionality

Enabled: Smart Charging enabledfor useActive: Smart Charging session(s)is in progressCount:Number of active sessionsCount(MaxLimit): Maximumsimultaneous sessions.Count[ChargingProfiles]:Charging Profiles presentCount[ChargingProfiles](MaxLimit):Maximum Charging Profilessupported

StartButton Some Charge Points (especiallyhigh power DC) may include anexplicit "Start" button (either aphysical button or a virtual buttonon a graphical user interfacedisplay) that must be pressed bythe user to commence charging.

Enabled: User must press Startbutton to begin chargingOperated: Button has beenpressedActive: Button is in the pressedstate

56


StopButton Some Charge Points (especiallyhigh power DC) may include anexplicit "Stop" button (either aphysical button or a virtual buttonon a graphical user interfacedisplay) that can or must bepressed by the user to terminatethe charging session.

Enabled: User must press Startbutton to begin chargingOperated: Button has beenpressedActive: Button is in the pressedstate

TiltSensor Measures Tilt angle from normalreference position (normally 90degree vertical), in degrees.

Enabled: Tilt sensing enabledActive: Abnormal tilt detectedAngle: Measured tilt

TokenReader Charge Points (and individualEVSEs) may have an authorizationtoken reader component,commonly an industry standardRFID reader.

Enabled: Token reader enabledEnabled(Set)=0: Token readerdisabled: allow charging withouttoken authentication/authorizationOperated: token data read eventProblem: token reader faultTokenInfo: Token data

UpstreamProtectionTrigger

Charge Points or physicallyseparate (spoke) EVSEs mayinclude circuitry designed totrigger the disconnection of powerto the structure by an upstreamprotection device after a severeproblem has been detected(usually impact shock and/or tilt(usually an upstream RCD, bycreating a deliberate controlledearth fault).

Active(Set): Force triggering ofupstream protectionTripped: Upstream protectiontriggeredProblem: Upstream protectionfault

WiredLink A Wired Link componentrepresents a fixed infrastructurecommunications link from aCharge Point to a Central System. Itcommonly uses shared networkinginfrastructure (including thepublic internet), and protocolssuch as Ethernet, xDSL, etc. Highresilience implementations mayinclude provision for fallbackarrangements, such as multiplerouting paths.

Active: Wired link connectedFallback: Using BackupSIM/Network PreferenceComplete: Wired link connectionterminatedProblem: Wired communicationsfaultNetworkAddress: Currentnetwork addressSignalStrength: Data Quality (1-BER)%ServiceURL[Current]: CurrentURL of OCPP Central Systemservice on this link.ServiceURL[Next]: New URL ofOCPP Central System service onthis link, after next reboot,howsoever triggered.

57

10. Appendix B: Standard EnumerationsThis Appendix contains the OCPP standardized enumerations. See Standard Enumerations on howto use these.

10.1. AvailabilityStateEnumeration

Allowed values (states) of the AvailabilityState Variable.

Replicates the ChargePointStatus values reported by the StatusNotification in OCPP 1.5.If a component is unavailable its parent can still be available. E.g. if a Charge Point has 2 EVSE’s and1 is unavailable the Charge Point is available. If part of the EVSE’s is reserved and part is occupiedthe ChargePoint is reported reserved. |Connector. Inoperative: Connector has been commandedinto Inoperative state. Occupied: connector is connected ("plugged in").

TODO match OCPP 1.6!

Value Description

Available Available for use, as none of the other states are applicable. This is the defaultstate.

Faulted Unable to provide charging session due to a fault/problem condition.

NotReady Not Available, for reasons other than any of the other AvailabilityState values.Unable to begin (new) charging session(s). This state must be used to reportpending "OnIdle" reset, re-boot in progress, etc.

Occupied Physically or logically occupied (e.g. connected or charging bay area not free)

OccupiedEnding

sub-variant of "Occupied" Currently Occupied, but will NOT become Available oncompletion: e.g. soft Reset or scheduled reboot pending; future: becoming (non-immediate) Reserved

Reserved Not Available when otherwise would be because of specific or aggregatereservation in effect

Unavailable Commanded "out of service" (by ChangeAvailability or equivalent device modelconfiguration setting). This state MUST NOT be used to indicate unavailability forany other reason (fault, rebooting, etc.)

10.2. ChargeProtocolEnumeration

Valid values of the ChargeProtocol data type

The Charging Control Protocol applicable to the Charge Point, EVSE, or Connector.

58

NOTE orthogonal to ConnectorType.

Value Description

CHAdeMO CHAdeMO protocol

CPPWM IEC61851-1 / SAE J1772 protocol (ELV DC & PWM signalling via Control Pilot wire)

ISO15118 ISO15118 V2G protocol (wired or wireless) as used with CCS

Uncontrolled No charging power management applies (e.g. Schuko socket)

Undetermined Yet to be determined (e.g. before plugged in)

Unknown Unknown; Not determinable

10.3. ConnectorTypeEnumeration

Valid values of the ConnectorType

Specific type of connector, including sub-variant information. NOTE: Distinct and orthogonal toCharging Protocol, Power Type, Phases. a| Connector: type of Connector

When reported for an EVSE: ConnectorType currently in use.

Value Description

cCCS1 Combined Charging System 1 (captive cabled) a.k.a. Combo 1

cCCS2 Combined Charging System 2 (captive cabled) a.k.a. Combo 2

cG105 JARI G105-1993 (captive cabled) a.k.a. CHAdeMO

cTesla Tesla Connector (captive cabled)

cType1 IEC62196-2 Type 1 connector (captive cabled) a.k.a. J1772

cType2 IEC62196-2 Type 2 connector (captive cabled) a.k.a. Mennekes socket

s309-1P-16A 16A 1 phase IEC60309 socket




sBS1361 UK domestic socket a.k.a. 13Amp

sCEE-7-7 CEE 7/7 16A socket. May represent 7/4 & 7/5 a.k.a Schuko

sType2 IEC62196-2 Type 2 socket a.k.a. Mennekes connector

sType3 IEC62196-2 Type 2 socket a.k.a. Scame

59

Value Description

Other1PhMax16A

Other single phase (domestic) sockets not mentioned above, rated at no more than16A. CEE7/17, AS3112, NEMA 5-15, NEMA 5-20, JISC8303, TIS166, SI 32, CPCS-CCC,SEV1011, etc.

Other1PhOver16A

Other single phase sockets not mentioned above (over 16A)

Other3Ph Other 3 phase sockets not mentioned above

NEMA14-30 , NEMA14-50

wInductive Wireless inductively coupled connection (generic)

wResonant Wireless resonant coupled connection (generic)


Unknown Unknown; not determinable

10.4. PhaseRotationEnumeration

Allowed values of the PhaseRotation Variable

The relative phase wiring of EVSE’s and/or Connectors with respect to the incoming Charge Point 3-phase supply.

For Charge Points, the 3-phase wiring relative relative to other charge points on the same 3-phasesupply (or to the upstream feed reference).

For EVSEs or Connectors, the 3-phase wiring relative relative to the incoming Charge Point powersupply.

Value Description

Unknown Unknown; e.g. not yet determined

RST Standard Reference phasing

RTS Reversed Reference phasing

SRT Reversed 240 degree rotation

STR Standard 120 degree rotation

TRS Standard 240 degree rotation

TSR Reversed 120 degree rotation

10.5. PowerTypeEnumeration

60

Allowed values of the PowerType Variable

The type of power available from Charge Point, EVSE, or Connector

Value Description

AC Alternating Current (single or 3-phase)

ACDC AC and/or DC

DC Direct Current



10.6. SupplyPhasesEnumeration

Allowed values of the SupplyPhases Variable

Number of alternating current phases connected/available. 1 or 3 for AC, 0 means DC (noalternating phases). Null value indicates that the number of phases (e.g. in use) is unknown.

Value Description

0 DC

1 Single Phase

3 Three Phase



11. Appendix C: Standardized VariableNamesThe following table contains the current list of standardized names for variables. When a variableis reported by a Charge Point it SHALL use one of the standardized names in this list, if possible.

If you do come across a variable name that is not in the list that you want to report using OCPP, youare allowed to use your own defined name. You are kindly asked to give the Open Charge Alliance anotice of this, so we might put it into this list in the future.

11.1. Boolean

The following list contains the standardized Boolean variables. If not specified otherwise, thedefault for a variable of type: boolean is: 0 (false).

61

Name Description Examples

Active Component is in its non-resting / activestate: E.g: On, Engaged, Locked. Onlycomponents that are Available, andEnabled- can be in the Active state.Monitoring and reporting of changes in theActive boolean state of any Component canbe achieved by enabling monitoring with adelta=1

ConnectorProtection: shutter open.PlugRetentionLock: locking pinengaged. Power contactor: relayclosed. AcDcConverter: unit "on".EmergencyStopSensor: buttondepressed. AccessDetector: dooropen

Available The Component is locally configured for use(e.g. reset, fuse replaced, not Tripped), butis not necessarily (remotely) Enabled.

ChargePoint, EVSE or Connector:Not Faulted AvailabilityStateAcDcConverter: Functional (Single-shot) ShockSensor: Capable ofgenerating a Shock event.

Enabled The Component is Available, and Enabledfor operation. For Available componentsthat cannot be selectively (remotely)enabled / disabled, this value is always true.Logically, Enabled=1 implies Available=1

ChargePoint, EVSE or Connector:In normal operation (not Faultedor Inoperative AvailabilityStates)BayOccupancySensor: Activelysensing (occupancy eventreporting depends on Monitoringstatus of Active state)

Fallback Component is operating in a fallback, orbackup mode. In an Inventory report, aValue of 1 for the MaxLimitVariableAttribute indicates that thecomponent can enter a fallback state (i.e. afallback mode is present).

ELVSupply: on battery power.Controller: on backup firmwareimage. RadioLink: using backupprovider/SIM.

Overload Component is in Overload state. EVSE, Connector taking highercurrent than allowed.

Problem Component itself is in a "Problem"condition.This is distinct from a problem at the parentlevel. E.g. if the plug is not locket theconnector can still function. Monitoring andreporting of changes in the Problemboolean state of any Component can beachieved by enabling monitoring with adelta=1

Fiscal Meter: cannot be readVentilator: fan slow/stalled.RadioLink: communicationsmodule cannot connect.

11.2. Decimal

The following list contains the list of standardized Decimal variables.

62

Name (Unit) Description Examples

ACCurrent(Ampere (RMS))

RMS AC Current (in amperes):1 value: single phase current, orrated/average AC current for all phases ifmulti-phase. When used for current in amulti-phases scenario, the key field SHALLbe used to specify the phase by using one ofthe following keys: L1, L2, L3, N.

ChargePoint: Total Current (allEVSE’s + ancillaries)EVSE: "Billable" current to EV:includes losses (AC→DC) andancillaries (e.g. fans) Values arelisted in the order as described bythe PhaseRotation variable of thecomponent (ChargePoint, EVSE,Connector). Note: Where theComponent has been declared(using SupplyPhases) to be multi-phase, then, as a data reductionshorthand, especially whenreporting and setting non-measured values (e.g. rated limit),a single specified ACCurrent valueis applicable to each phase.

ACVoltage(Volt (RMS))

RMS AC Voltage (in volts):1 value: single phase to neutral, orrated/nominal average AC voltage for allphases if multi-phase.

When used for Voltages over multiple-phases, the key field SHALL be used tospecify the phase by using one of thefollowing keys: L1, L2, L3, N.

ChargePoint: Input Voltage Valuesare listed in the order as describedby the PhaseRotation variable ofthe component (ChargePoint,EVSE, Connector). Note 1: Wherethe Component has been declaredto be multi-phase (usingSupplyPhases>1), as a datareduction shorthand, especiallywhen reporting nominal/ratedlimits, etc., a single ACVoltagevalue without a key, is to be takenas applying equally to each phase.

CurrentImbalance(Percent)

Percentage current imbalance in threephase supply

DCCurrent(Ampere)

Instantaneous DC Current (in amperes) EVSE: output current

DCVoltage(Volt)

Instantaneous DC Voltage (volts) EVSE: DC output voltage

Duration(Seconds)

Total time duration (in seconds).

63


Force(g or Newton)

Reports (impact) force/ acceleration values(estimates) in one or more directions, inunits of Newton (default) or "g". When usedthe report a force in multiple dimensions,the key field SHALL be used to specify theangle by using one of the following key: X, Y,Z. Where X is defined as: rightwards, Y isdefined as: forwards and Z is defined as:upwards.

Conveys how hard a ChargePointwas hit by a car and may explainmalfunctions.

Frequency(Hertz)

Frequency of AC power or signal (usuallygrid frequency)

Height(meter)

Height above(+)/below(-) reference level(ground level unless context demandsotherwise).

FloodSensor: Water Height

Percent(Percent)

Can be used by miscellaneous analogueinput sensors and/or output controllers.Where the nominal 0-100% range is a subsetof the actual minimum to maximum range,values outside the range 0-100 max exist

BayOccupancySensor: Strength of"occupied" signal, BeaconLighting:Relative lighting intensity

Power(kW or W)

Instantaneous (real) Power(measured/calculated, including powerfactor for AC) (in kW). Where a component(e.g. AC to DC Power Converter) has both"input" power and "output":key: "Input" = Inputkey: "Output" = Output

ChargePoint: total powerconsumption (all EVSE’sancillaries).EVSE: "Billable" power to EV:includes losses (AC→DC) andancillaries (e.g. fans)

Temperature(Celsius orFahrenheit)

Temperature(s) of component (in Celsius, bydefault). Components may have multipletemperature sensors.

AcDcPowerConverter:Temperature sensor(s) on IGBTheatsink

11.3. DateTime

The following list contains the list of standardized DateTime variables.


Time Time, in ISO 8601 datetime format. Timezone optional.

Clock:Time[1]: Current Time+ Valueexample:+ 2013-09-27T20:12:34+01:00

VersionDate Issue date or DateTime ofsoftware/firmware, in ISO8601 format

11.4. Enumerations (Standardized Names)

See: Standardized Enumerations Names for how to use these.

64


Mode Operating mode string from among validoptions (communicated by OptionListVariableAttribute duringcapability/configuration discovery)

- SessionCoster: Local, Central- TokenReader:Controller[evse=2]: Operatingmode of 2nd EVSE sub-controller

State A state code or name identifier string, toallow the internal state of components to bereported and/or controlled

CPPWMController: IEC61851Control Pilot "State" (A-F)Controller[evse=2]: State of 2nd

EVSE sub-controller

11.5. Enumeration Lists (Standardized Names)

See: Enumerations Lists for how to use these.


OptionsSet Set of Options, represented as multiplevalue(s), selected from valid optionscommunicated by MembersList(VariableAttribute) duringcapability/configuration discovery

ChargePoint.OptionsSet[ComplianceProfiles]:Compliance profiles supported bycharge point (comma separatedlist) ControlMetering:MeterValueSampledDataTokenReader:Card Types accepted SampledData

Sequence Order sensitive set of Options, representedas multiple value(s), selected from validoptions communicated by SequenceList(VariableAttribute) duringcapability/configuration discovery

RadioLink.Sequence[ImsiPreference]

11.6. Event

The following list contains the list of standardized Event variables.


Complete Component’s operation cycle hascompleted. Used only in event reports,where it is always true.

Selftest: self-test sequencecompleted

Operated The Component operated in aninstantaneous, transient, or immediatelyself-resetting pattern. Used only in eventreports, where it is always true.

TokenReader: detected an RFIDcard. StopButton: pressed.RCDRecloser: re-closed.ShockSensor: significantacceleration value detected

Tripped Single-shot device requires explicitintervention to re-prime/activate to normal.

OverCurrentBreaker: tripped.RCD: tripped.

65

11.7. Integer

The following list contains the list of standardized Integer variables.


Angle(degrees)

Tilt angle from vertical. First angle isrightwards and second angle forwards.When used the report an angle in multipledimensions, the key field SHALL be used tospecify the angle by using one of thefollowing key: forward, rightwards.

Conveys how far the Charge Pointis tilted after an accident and canbe used to disable a Charge Pointfor safety reasons.

Count General purpose integer count ChargingStatusIndicator:[BlinkRepeat] Display:[HeightInChars][WidthInChars]

FanSpeed(RPM)

Fan Speed in RPM. A fan speed of 0represents stopped/stalled. {Null} meansunknown.

As ubiquitous but delicate movingcomponents fans are a frequentsource of problems.

Humidity(Percentage)

The relative humidity in %. Note: Notabsolute humidity or specific humidity

ChargePoint: Internal ambient airrelative humidity

Impedance(Ohm)

Impedance in Ohm: Either real (resistive)impedance (single value), or a compleximpedance (at nominal mains frequency)with resistive and reactive(inductive/capacitative) parts, as two values.

GroundIsolationTester: IsolationImpedance

Interval(second)

Repeat interval (e.g for componentoperation) The value is in seconds

Controller: Heartbeat Interval

Light(Lux)

The ambient light level. The value is in Lux. Regulate the on/off or brightnessstate of integral or externalenvironmental lighting.

SignalStrength(ASU, dB(dBmW) or Pct)

Mobile Radio data signal strength, in ASU(typically 0-31 or 99 for unknown). OrdbmW (typically -140 to -50)

RadioLink: Signal strength asreported by mobile data module.WiredLink: Data Quality (1-BER)%

StateOfCharge(Percentage)

State of Charge Percentage value, asreported by EV

ELVSupply: rechargeable backupbattery SOC

Tries For self-monitoring electro-mechanicalequipment, etc. Tries reported is thenumber of tries (INCLUDING the originalattempt) in the last successful, or attempted,cycle of operation. The maximum allowedTries can be specified in SetConfigurationusing the MaxSet VariableAttribute

RCDRecloser: Number of times re-tried on last re-close. E.g.indicative for actuators starting tofail.

Timeout(Seconds)

Timeout for Component operation (inseconds)

66


VoltageImbalance(Percentage)

Percentage voltage imbalance in threephase supply

ChargePoint: Imbalancepercentage of incoming supplyvoltages

11.8. Text

The following list contains the list of standardized Text variables.


Color Reg Green Blue color intensity , expressedas standard 24 bit hexadecimal RGB values:3 * 00-FF (0-255), in order RRGGBB).Examples:000000: BlackFF0000: Red00FF00: Green0000FF: BlueFFFF00:YellowFFFFFF: White008000: Medium intensity green.

Beacon Lighting: Displayed ColorChargingStatusIndicator:Displayed Color

DataText General purpose miscellaneous data from aComponent, in text form

ICCID ICCID (Integrated Circuit Card IDentifier) ofmobile data SIM card.

IMSI IMSI (International Mobile SubscriberIdentity) number of mobile data SIM card

NetworkAddress

Assigned network address ofcommunications link of a specificcomponent. IPv4 in dotted-decimalnotation, IPv6 in RFC 5952 notation

RadioLink: 192.168.23.45WiredLink: 2001:db8:0000:0:1::1

Manufacturer Component Manufacturer name

Model Manufacturer’s Model code/number ofComponent, including suffixes etc. toidentify functional, regional or linguisticvariation.

OperatingTimes Recurring operating times in iCalendarRRULE format. (RFC 2445)

ChargePoint: operating times

SerialNumber Serial number of Component

67


ServiceURL URL for network service. RadioLink.ServiceURL[1]: CurrentCentral System service URLRadioLink.ServiceURL[2]: NewCentral System service URL to takeeffect on next reboot, howsoevertriggered. Controller.ServiceURL:Charge Point Service URL

TokenInfo A typed authorization Id structure

TimeOffset Time Offset with respect to CoordinatedUniversal Time (aka UTC or GreenwichMean Time) in the form of an ISO 8601 time(zone) offset suffix, including themandatory "" or "-" prefix (/-[hh]:[mm]).

Clock: TimeOffset represents theconfigured operating timezone of aCharge Point.

Variant Model variant, reflecting internal designchanges or sub-component substitutions notaffecting external functionality.

VersionNumber Version Number of software/firmware

68

ocpp device management profile - oasis · device management profile this section is normative. 1....

Documents