OCPP 2.0.

1
Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06
Table of Contents
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Version History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Goal of this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. 3-tier model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Device Model: Addressing Components and Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Characteristics and Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Standardized lists of Components and Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. Minimum Device Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Information Model vs. Device Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Using OCPP for other purposes than EV charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. EVSE numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Connector numbering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Transaction IDs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Topologies supported by OCPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Charging Station(s) directly connected to CSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Multiple Charging Stations connected to CSMS via Local Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. Multiple Charging Stations connected to CSMS via Local Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. Non-OCPP Charging Stations connected to CSMS via OCPP Local Controller. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.5. DSO control signals to CSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.6. Parallel control by CSMS and EMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9. Part 1 Appendix: OCPP Information Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Explanation of UML representation and message generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Visual Representation of OCPP Information Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Edition 3 FINAL, 2024-05-06

Disclaimer
Copyright © 2010 – 2024 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).

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 1/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

Version History
Version Date Description

2.0.1 Edition 3 2024-05-06 OCPP 2.0.1 Edition 3. All errata from OCPP 2.0.1 Part 1 until and including Errata
2024-04 have been merged into this version of the specification.

2.0.1 2020-03-31 Final version of OCPP 2.0.1

2.0 2018-04-11 OCPP 2.0 April 2018

First release of this Architecture & Topology document

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 2/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

1. Introduction
1.1. Goal of this document
The goal of this document is to describe a number of architecture related topics for OCPP 2.0.1.

OCPP was originally intended for two way communication between a backoffice, in OCPP the Charging Station Management System
(in this document: CSMS) and a Charging Station. The protocol has become more advanced and with every new revision new
functionalities and options are added. It has evolved into a protocol that can be used in different architectures for different types of
Charging Stations.
This document describes, in addition to the original "simple" setup CSMS <> Charging Station, a number of topologies as an
additional explanation for using OCPP. Furthermore, the Device Management concept to configure and monitor any type of
Charging Station, the OCPP Information Model and the 3-tier model are explained.

This document is partially informative and partially normative and is not intended to limit the use of OCPP. However, it does add an
explanation what kind of use of OCPP the creators of OCPP had in mind when creating this version of the specification. This
document is therefore also intended to support the reader of the protocol specification in Part 2 of OCPP to understand how it can
be used.

1.2. Terms and abbreviations

This section contains the terminology and abbreviations that are used throughout this document.

1.2.1. Terms
Term Meaning
Charging Station The Charging Station is the physical system where EVs can be charged. A Charging Station
has one or more EVSEs.
Connector The term Connector, as used in this specification, refers to an independently operated and
managed electrical outlet on a Charging Station. In other words, this corresponds to a single
physical Connector. In some cases an EVSE may have multiple physical socket types and/or
tethered cable/Connector arrangements(i.e. Connectors) to facilitate different vehicle types
(e.g. four-wheeled EVs and electric scooters).
EVSE An EVSE is considered as an independently operated and managed part of the Charging
Station that can deliver energy to one EV at a time.
Local port Smart Meter The Local port on a Smart Meter is a port (for example serial) on a digital electricity meter
that provides access to information about meter readings and usage.

1.2.2. Abbreviations
Abbreviation Meaning
DSO Distribution System Operator
CSO Charging Station Operator
CSMS Charging Station Management System
EMS Energy Management System. In this document this is defined as a device that manages the local loads
(consumption an production) based on local and/or contractual constraints and/or contractual incentives. It
has additional inputs, such as sensors and controls from e.g. PV, battery storage.
EVSE Electric Vehicle Supply Equipment
LC Local Controller. In this document this is defined as a device that can send messages to its Charging
Stations, independently of the CSMS. A typical usage for this is the local smart charging case described in
the Smart Charging chapter of Part 2 of OCPP, where a Local Controller can impose charge limits on its
Charging Stations.
LP Local Proxy. Acts as a message router.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 3/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

2. 3-tier model
This section is informative.

To understand the terminology in the OCPP specification, it is important to understand the starting point of this specification. The
OCPP specification uses the term Charging Station as the physical system where EVs can be charged. A Charging Station can have
one or more EVSEs (Electric Vehicle Supply Equipment). An EVSE is considered as a part of the Charging Station that can deliver
energy to one EV at a time. The term Connector, as used in this specification, refers to an independently operated and managed
electrical outlet on a Charging Station, in other words, this corresponds to a single physical Connector. In some cases an EVSE may
have multiple physical socket types and/or tethered cable/connector arrangements to facilitate different vehicle types (e.g. four-
wheeled EVs and electric scooters). This setup is referred to as the 3-tier model and visualized in the figure below.

Figure 1. 3-tier model as used in OCPP

This section describes the charging infrastructure on a logical level for communication purposes. We do not wish
to impose a mapping onto physical hardware. This is a manufacturer’s choice. For example, the EVSE might be
integrated into a Charging Station and to look as just a part of that device, but it might just as well have its own
NOTE
casing and live outside of the physical entity Charging Station, for example a charging plaza with 20 EVSEs and
Connectors which communicates via 1 modem as 1 Charging Station to the CSMS is seen by OCPP as 1 Charging
Station.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 4/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

3. Information Model
This section is informative.

Given the growing complexity of the messages of OCPP, OCPP 2.0.1 is based on an Information Model as a blueprint for the
messages and inherent schemas of OCPP. With an information model, we mean a logical object set, describing real objects with all
their properties. This provides an informative representation of information structure in the protocol. Furthermore, it enables
making objects within OCPP reusable and enables consistent definition of messages and automatically generated message
schemas (Part 3).
The Information Model is a model, also called Domain Model or Core Model, based on which the OCPP messages and datatypes
are generated. These datatypes are extracted from the the OCPP 1.6 specification and are named Core DataTypes and Qualified
DataTypes. The figure below illustrates how the DataTypes in the information model are built up.

In part 2 - Specification, chapter Datatypes, some DataTypes have the Common: prefix. This originates from the Information Model.
It means that the DataType is able to be shared among other DataTypes and Messages. This has no impact on the OCPP
implementation of a device.

anySimpleType string
«XSDsimpleType» «XSDsimpleType»
XSDDatatypes::decimal XSDDatatypes::normalizedString

«PRIMSimpleType» «PRIMSimpleType»
Decimal NormalizedString

(from PrimitiveDataTypes) (from PrimitiveDataTypes)

«CDTComplexType,LDT,ECDMChange,CDT»
IdentifierType

«Supplementary»
+ identificationScheme: String [0..1]
«CDTComplexType,ECDMChange,... «CDTComplexType,LDT,ECDMChange,... + identificationScheme.Agency: String [0..1]
«CDTSimpleType,LDT,EC... AmountType MeasureType + identificationScheme.AgencyName: String [0..1]
NumericType + identificationScheme.Name: String [0..1]
«Supplementary» «Supplementary» + identificationScheme.UniformResource: String [0..1]
«Supplementary» + currency: String [0..1] + measureUnit: String [0..1] + identificationScheme.Version: String [0..1]
+ format: String [0..1] + currencyCodeListVersion: String [0..1] + measureUnit.CodeListVersion: String [0..1] + identificationSchemeData.UniformResource: String [0..1]

(from CoreDataTypes) (from CoreDataTypes) (from CoreDataTypes) (from CoreDataTypes)

«BDTSimpleType» «BDTSimpleType» «BDTComplexType» «BDTComplexType» «BDTComplexType»

IntegerType PercentageType PositiveAmount PowerType CertificateSerialNumberType

«Facet» «Facet» «Facet» «Facet»

+ fractionDigits = 0 {readOnly} + fractionDigits = 0 {readOnly} + fractionDigits = 0 {readOnly} + maxLength = 20 {readOnly}
+ minInclusive = 0 {readOnly} + minInclusive = 0 {readOnly}
(from QualifiedDataTypes) + maxInclusive = 100 {readOnly} (from QualifiedDataTypes) (from QualifiedDataTypes)
(from QualifiedDataTypes)
(from QualifiedDataTypes)

Figure 2. Example datatypes

The Information Model is divided into a number of "functions" to have a better overview of the model (thus for readability):

• Transactions
• SmartCharging
• Metering
• Security (Profiles/Authorization)
• Communication
• SecondaryActorSchedule

For more details about the actual model per function, please refer to the appendix.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 5/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

4. Device Model: Addressing Components and Variables

The Device Model refers to a generalized mechanism within OCPP to enable any model of Charging Station to report how it is build
up, so it can be managed from any CSMS. To manage a Charging Station with the Device Model (i.e. "to manage a device") a
number of messages and use cases is defined to configure and monitor a Charging Station in detail, without defining the structure
of the Charging Station in advance. To be able do do this, OCPP provides a generalized mechanism to allow the exchange of a wide
range of information about Charging Station. This version of the Device Model has the 3-tier model (Charging Station, EVSE,
Connector) as its starting point, which means that any description created with the Device Model follows these three tiers. The
remainder of this chapter describes how the data (and associated meta-data) looks like that can be exchanged between a Charging
Station and a CSMS. The use cases and messages that are used to manage a device are not described here, but in Part 2 of the
specification. This chapter only focuses on the data model.

4.1. Components
In OCPP 2.0.1, a Charging Station is modelled as a set of "Components", typically representing physical devices (including any
external equipment to which it is connected for data gathering and/or control), logical functionality, or logical data entities.
Components of different types are primarily identified by a ComponentName, that is either the name of a standardized component
(see OCPP part 2c), or a custom/non-standardized component name, for new, pre-standardized equipment, vendor specific
extensions, etc.
ChargingStation (TopLevel), EVSE, and Connector represent the three major "tiers" of a Charging Station, and constitute an implicit
"location-based" addressing scheme that is widely used in many OCPP data structures. Each "tier" has a component of the same
name, which represents the tier. For example, EVSE 1 on a Charging Station is represented by the component named "EVSE" (no
instance name) with "evseId = 1". In the same manner, Connector 1 on EVSE 1 is represented by the component named "Connector"
(no instance name) with "evseId = 1, connectorId = 1".
By default, all components are located at the ChargingStation tier, but individual instances of any component can be associated with
a specific EVSE, or a specific Connector (on a specific EVSE) by including EVSE or EVSE and Connector identification numbers as
part of a component addressing reference.
Additionally, there can be more than one instance of a component (in the functional dimension), representing multi-occurrence
physical or logical components (e.g. power converter modules, fan banks, resident firmware images, etc.).
Each distinct component instance is uniquely identified by an (optional) componentInstance addressing key. When no
componentInstance is provided, then the default or only instance of a component is referenced.
Components do not in themselves hold data: all externally accessible data associated with each component instance is
represented by a set of variables that can be read, set, and/or monitored for changes. The relationship of a Component with one or
more Variables is illustrated in below.

«BusinessComponent» «BusinessComponent»
ComponentType EVSEType

+ Instance: NameIdentifierType [0..1] + ConnectorId: NumericIdentifierType [0..1]

+ Name: NameIdentifierType 0 1 «Content»
+ MRID: NumericIdentifierType

*
«BusinessComponent»
VariableType
+ Instance: NameIdentifierType [0..1]
+ Name: NameIdentifierType

Figure 3. Component and variables

The table below illustrates some common components (by their standardized component-names), and examples of the hierarchical
location levels at which they typically occur for a basic home charger and a typical public Charging Station.

Basic home charger example configuration

ChargingStation tier EVSE tier Connector tier
ChargingStation (itself, as a whole) EVSE (itself, as a whole) Connector (itself, as a whole)
RadioLink ControlMetering PlugRetentionLock
TokenReader OverCurrentBreaker
Controller RCD

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 6/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

Basic home charger example configuration

ChargingStatusIndicator

Public Charging Station example configuration

ChargingStation tier EVSE tier Connector tier
ChargingStation (itself, as a whole) EVSE (itself, as a whole) Connector (itself, as a whole)
ElectricalFeed ElectricalFeed AccessProtection
TokenReader TokenReader PlugRetentionLock
Display Display
FiscalMetering FiscalMetering
Clock ControlMetering
Controller OverCurrentBreaker
RCD
ChargingStatusIndicator

4.2. Variables
Every component has a number of variables, that can, as appropriate, be used to hold, set, read, and/or report on all (externally
visible) data applicable to that component, including configuration parameters, measured values (e.g. a current or a temperature)
and/or monitored changes to variable values.
Although many components can have associated variables that are, by their nature, specific to the component type (e.g.
ConnectorType for a Connector component), there are a minimal set of standardized variables that are used to provide standardized
high level event notification and state/status reporting (e.g. Problem, Active) on a global and/or selective basis, and also to report
component presence, availability, etc. during the inventorying/discovery process (e.g. Available, Enabled). A Charging Station is not
required to report the base variables: Present, Available and Enabled when they are readonly and set to true. When a Charging
Station does not report: Present, Available and/or Enabled the Central System SHALL assume them to be readonly and set to true
Variables can be any of a range of common general-purpose data types (boolean, integer, decimal, date-time, string), but also can
have their allowable values constrained to particular ranges, enumeration lists, sets, or ordered lists.
To support complex components, there can be more than one instance of any given variable name associated with any
components (e.g. power converter modules reporting temperature, current, or voltage at multiple points).
Each distinct variable instance is uniquely identified by an (optional) variableInstance addressing key string value. When no
variableInstance is provided, then the default or only instance of a variable is referenced.

4.3. Characteristics and Attributes

Each variable, in addition to its primary ("Actual") value, can have a set of associated secondary data that is linked to the same
primary variable name and variableInstance.
This greatly avoids cluttering the variables namespace with confusing clusters of ancillary variable names (e.g. FanSpeed,
FanSpeedUnits, MinimumFanSpeed, BaseFanSpeed) that lack consistence and discoverability.
The ancillary variable data includes:

• Variable characteristics meta-data (read-only)

◦ Unit of measure (V,W,kW,kWh, etc.)

◦ Data type (Integer, Decimal, String, Date, OptionList, etc.)
◦ Lower limit
◦ Upper limit
◦ List of allowed values for enumerated variables
• Variable attributes (read-write):

◦ Actual value
◦ Target value
◦ Configured lower limit
◦ Configured upper limit
◦ Mutability (whether the value can be altered or not, e.g. ReadOnly or ReadWrite)
◦ Persistence (whether the value is preserved in case of a reboot or power loss)

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 7/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06
The relationship of a Variable with one or more VariableAttributes is illustrated in the figure below.

«BusinessComponent»
ComponentType «BusinessComponent»
EVSEType
+ Instance: NameIdentifierType [0..1]
+ Name: NameIdentifierType + ConnectorId: NumericIdentifierType [0..1]
0 1
«Content»
+ MRID: NumericIdentifierType
1

*
«BusinessComponent»
VariableType
+ Instance: NameIdentifierType [0..1]
+ Name: NameIdentifierType
1 1

0..1
1..*
«BusinessComponent»
«BusinessComponent» VariableCharacteristicsType
VariableAttributeType
+ DataType: DataEnumType
+ Constant: IndicatorType + MaxLimit: AmountType [0..1]
+ Mutability: MutabilityEnumType [0..1] + MinLimit: AmountType [0..1]
+ Persistent: IndicatorType + SupportsMonitoring: IndicatorType
+ Type: AttributeEnumType [0..1] + Unit: MeasurementUnitType [0..1]
+ Value: Base64String2500Type + ValuesList: CI1000TextType [0..1]

Figure 4. Variable attributes and characteristics

There is a difference between how to implement (physical) devices and (virtual) controller components, using the DeviceModel. A
(virtual) controller component has to be implementing as described in part 2 chapter the "Referenced Components and Variables".
These kind of components/variables are only using the variableAttribute type 'Actual'. Depending on if this variableAttribute is
writable, the CSMS can use this to set a new value.

(Physical) devices are a bit more complex to implement. For example, there is a fan with a fan speed, that has a (physical) limit with
a range of 0 - 1000. But it should not be allowed to set the value below 200, because the fan can stop functioning. And it should not
be set above 500, because that would be bad for the fan on the long run. When implementing this device using the DeviceModel, it
can be defined as follows:

Component name Fan

Variable name FanSpeed
variableAttribute 1 type Actual
value <The current fan speed value of the fan.>
mutability ReadOnly
variableAttribute 2 type Target
value <The CSMS can use this value to adjust the fan
speed. The Charging Station SHALL try to keep the
actual value at the target value.>
mutability ReadWrite
variableAttribute 3 type MaxSet
value <The value '500' from the example. The target may
not be set above this value.>
variableAttribute 4 type MinSet
value <The value '200' from the example. The target may
not be set below this value.>
variableCharacteristics maxLimit <The value '1000' from the example. This could be the
physical max limit of the fan.>
minLimit <The value '0' from the example. This could be the
physical min limit of the fan. This could also be -1000,
if the fan is also able to rotate in the other direction.>
Description This is an example of how a fan could be defined using the DeviceModel.

When trying to set the target with value 600, the Charging Station will first check the allowed min and max values/limits and reject

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 8/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06
the set. If the target value is set to 500, the value is within range and the Charging Station will allow the set and start to adjust the
actual fan speed. If the actual fan speed is measured to be 502, it’s out of range. But it should be reported to the CSMS, so the
actual value of a physical component should be updated without checking the min and max values/limits.

4.4. Monitoring
Optional monitoring settings can be associated with a variable, that allow changes to variable (Actual) values are to be reported to
the CSMS as event notifications.
These include:

• Monitoring value
• Monitoring type: upper threshold, lower threshold, delta, periodic
• Severity level when reporting the event

The following table show which MonitorType/dataType combinations are possible.

string decimal integer dateTime boolean OptionList SequenceList MemberList

UpperThresh X X
old
LowerThresh X X
old
Delta X X X X X X X X
Periodic X X X X X X X
PeriodicCloc X X X X X X X
kAligned

• For UpperThreshold and LowerThreshold the value represents the to be exceeded value by the actual value of the variable.
• For Delta this value represents the change in value comparing with the actual value from the moment the monitor was set.

◦ When the dataType of the variable is integer or decimal, this value represents the difference to be reached to trigger
the monitor.

◦ When the dataType of the variable is dateTime the unit of measure will be in seconds.
◦ When the dataType of the variable is string, boolean, OptionList, SequenceList or MemberList, this value is ignored.
The monitor will be triggered by every change in the actual value.
• When a delta monitor is triggered OR when the Charging Station has rebooted, the Charging Station shall set a new
momentary value.
• For Periodic and PeriodicClockAligned the value represents the interval in seconds.

The relationship between a Variable and one or more VariableMonitoring elements is illustrated in the figure below.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 9/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«BusinessComponent» «BusinessComponent»
ComponentType EVSEType
+ Instance: NameIdentifierType [0..1] + ConnectorId: NumericIdentifierType [0..1]
+ Name: NameIdentifierType 0 1
«Content»
+ MRID: NumericIdentifierType

*
«BusinessComponent»
VariableType
+ Instance: NameIdentifierType [0..1]
+ Name: NameIdentifierType

1 1 1

1..* 0..1 *
«BusinessComponent» «BusinessComponent» «BusinessComponent»
VariableAttributeType VariableCharacteristicsType VariableMonitoringType
+ Constant: IndicatorType + DataType: DataEnumType + Id: NumericIdentifierType
+ Mutability: MutabilityEnumType [0..1] + MaxLimit: AmountType [0..1] + Severity: NumericIdentifierType
+ Persistent: IndicatorType + MinLimit: AmountType [0..1] + Transaction: IndicatorType
+ Type: AttributeEnumType [0..1] + SupportsMonitoring: IndicatorType + Type: MonitorEnumType
+ Value: Base64String2500Type + Unit: MeasurementUnitType [0..1] + Value: MeasureType
+ ValuesList: CI1000TextType [0..1]

Figure 5. Variables and monitoring

4.5. Standardized lists of Components and Variables

To provide some level of interoperability between different Charging Stations and CSMSs, besides the above defined model of
Components and Variables, part 2 - appendices of the OCPP specification provides a list of standardized names for Components
and Variables. The idea of this lists is to make sure that if a Charging Station and CSMS want to exchange information about a
component, they both use the same name and description if it is listed in the OCPP specification. For names of a Components or
Variables that are not listed in the specification, bilateral appointments between Charging Station manufacturer and CSMS are to be
made. In these cases it is advised to provide feedback to the Open Charge Alliance to be able to include new/additional
Components and Variables in new versions of OCPP.

4.6. Minimum Device Model

Since the Device Model is a generalized mechanism which can be applied to any model of Charging Station, the complexity of
different implementations can vary. It consists of a number of use cases and messages that are not all required. This section
describes the minimum part of the Device Model that needs to be implemented to create a working implementation of OCPP 2.0.1.

The Device Model introduces Components and Variables that can be used for configuring and monitoring a Charging Station. A
number of these Components and Variables are included in the list of Referenced Components and Variables (grouped by
Functional Block) in Part 2 of the specification. When implementing a Functional Block, ALL required Configuration Variables that
belong to a Functional Block SHALL be implemented. The required Configuration Variables from the General section SHALL also be
implemented for all implementations of OCPP 2.0.1.

The following table describes which messages are required or optional to implement for all use cases that are part of the Device
Model implementation.

Use cases / messages that are part of a minimium Device Model implementation
Use case Messages
B05 Set Variables SetVariables message MUST be implemented
B06 Get Variables GetVariables message MUST be implemented.
B07 Get Base Report GetBaseReport message MUST be implemented and MUST support ConfigurationInventory
and FullInventory. The content of these reports depends on the implementation of the
Charging Station. It is up to the implementer to decide which components and variables exist
in the implementation.
Additional use cases / messages that are not part of a minimium Device Model implementation
Use case Messages
B08 Get Custom Report GetCustomReport message is optional.
N02 Get Monitoring Report GetMonitoringReportRequest message is optional.
N03 Set Monitoring Base SetMonitoringBaseRequest message is optional.
N04 Set Variable Monitoring SetVariableMonitoringRequest message is optional.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 10/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

Use cases / messages that are part of a minimium Device Model implementation
N05 Set Monitoring Level SetMonitoringLevelRequest message is optional.
N06 Clear/Remove Monitoring ClearVariableMonitoringRequest message is optional.
N07 Alert Event it is RECOMMENDED that NotifyEventRequest is implemented in the Charging Station even
when monitoring is not implemented, so that this can be used to report built-in monitoring
events.
N08 Periodic Event see N07.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 11/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

5. Information Model vs. Device Model

As described above, the terms Information Model and Device Model refer to different concepts. The Information Model refers to a
model of the information structure upon which the messages and datatypes in OCPP are based, whereas the Device Model refers
to a generalized mechanism within OCPP to enable any model of Charging Station to report how it is build up so, it can be managed
from any CSMS without defining the structure of the Charging Station in advance.
The messages that are used for Device Management are therefore part of the Information Model and the objects that are used for
modelling a device ('Component' and 'Variable') are also part of the Information Model.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 12/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

6. Using OCPP for other purposes than EV charging

As indicated in the introduction of this document, OCPP is primarily intended for two way communication between a CSMS and a
Charging Station. However, with the addition of the Device Model as described in the chapter Device Model, OCPP can additionally
be used for other purposes. For example, the reporting of Events or Status changes in transformers or stand-alone battery packs
might also be useful for companies that are rolling out EV charging infrastructure. In this example, a BootNotification could be used
to connect these devices to a management system. In the device model a device that is not a Charging Station, can be recognized
by the fact that the component Charging Station is not present at the top level. At the moment the OCPP specification does not
provide use cases for non Charging Station devices. However, they may be added in a future version of OCPP.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 13/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

7. Numbering
This section is normative.

7.1. EVSE numbering

To enable the CSMS to address all the EVSEs of a Charging Station, EVSEs MUST always be numbered in the same way.

EVSEs numbering (evseIds) MUST be as follows:

• The EVSEs MUST be sequentially numbered, starting from 1 at every Charging Station (no numbers may be skipped).
• evseIds MUST never be higher than the total number of EVSEs of a Charging Station
• For operations initiated by the CSMS, evseId 0 is reserved for addressing the entire Charging Station.
• For operations initiated by the Charging Station (when reporting), evseId 0 is reserved for the Charging Station main
controller.

Example: A Charging Station with 3 EVSEs: All EVSEs MUST be numbered with the IDs: 1, 2 and 3. It is advisable to number the
EVSEs of a Charging Station in a logical way: from left to right, top to bottom incrementing.

7.2. Connector numbering

To enable the CSMS to address all the Connectors of a Charging Station, Connectors MUST always be numbered in the same way.

Connector numbering (connectorIds) MUST be as follows:

• The connectors are numbered (increasing) starting at connectorId 1 on every EVSE

• Every connector per EVSE has a unique number
• ID of the first Connector of an EVSE MUST be 1
• Additional Connectors of the same EVSE MUST be sequentially numbered (no numbers may be skipped)
• connectorIds MUST never be higher than the total number of connectors on that EVSE

Example: A Charging Station with 3 EVSEs that each have 2 connectors, is numbered as follows:

• EVSE 1 has connectors with connectorId 1 and 2

• EVSE 2 has connectors with connectorId 1 and 2
• EVSE 3 has connectors with connectorId 1 and 2

7.3. Transaction IDs

TransactionIds are now generated by the Charging Station and MUST be unique on this Charging Station for every started
transaction.

In OCPP 1.x this was done by the CSMS.

The format of the transaction ID is left to implementation. This MAY for example be an incremental number or an UUID.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 14/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

8. Topologies supported by OCPP

This chapter shows a number of topologies for using OCPP. As indicated in the introduction, OCPP was originally used for a setup
where each Charging Station communicates directly with the CSMS. It is important to keep in mind that OCPP has no knowledge of
the topology of the Charging Station network. The following figure shows the possible components in a setup using OCPP and the
relations between these components:

Figure 6. Possible components in a setup using OCPP

8.1. Charging Station(s) directly connected to CSMS

Description
This is the basic setup for using OCPP.

OCPP
Charging
CSMS
Station

Figure 7. Charging Station directly connected to CSMS

8.2. Multiple Charging Stations connected to CSMS via Local Proxy

Description
In some situations it is desirable to route all communications for a group of Charging Stations through a single network node (i.e.
modem, router, etc.). A typical example is the situation where a number of a Charging Stations are located in an underground
parking garage with little or no access to the mobile network. In order to provide access to mobile data the Charging Stations are
linked to a central data communications unit over a LAN. This central unit connects to the mobile network and acts as a proxy
between CSMS and Charging Stations. Such a unit is called a "local proxy" (LP) in OCPP. A local proxy acts as a message router.
Neither the CSMS nor the Charging Stations are aware of the topology of the network. For the Charging Stations in the group the
local proxy "is" the CSMS. Similarly, for the CSMS the local proxy "is" the Charging Station. The diagram below illustrates this
configuration.

Charging
OCPP Station 1
OCPP
CSMS LP OCPP

Charging
Station n

Figure 8. Multiple Charging Stations connected to CSMS via Local Proxy

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 15/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

8.3. Multiple Charging Stations connected to CSMS via Local Controller

Description
Whereas a local proxy does little more than route OCPP messages, a Local Controller can send messages to its Charging Stations,
independently of the CSMS. A typical usage for this is the local smart charging case described in the Smart Charging chapter of
Part 2 of OCPP, where a Local Controller can impose charge limits on its Charging Stations. In order for a Local Controller to be
addressed by the CSMS, it needs to have its own Charging Station identity. From the point of view from OCPP, the Local Controller
will just be a Charging Station (without any EVSEs/Connectors). The CSMS will possess the logic to deal with the Local Controller in
order to support, for example, local smart charging. It is up to the implementation of the CSMS, whether the group topology is
manually configured or deduced from the network based on IP addresses and information in BootNotifications. The diagram below
illustrate this configuration.

Charging
OCPP Station 1
OCPP
CSMS LC OCPP

Charging
Station n

Figure 9. Multiple Charging Stations connected to CSMS via Local Controller

Technically this topology can be realized in multiple ways. When using this setup with websockets, this implies
that when a Charging Station connects to the Local Controller, it should open a websocket connection with the
same address to the CSMS. The advantages of this approach is that the Local Controller can see all the
NOTE messages and act on it, messages don’t have to wait, firmware updates etc. on the Charging Stations are
possible and the CSMS does not need special software. It could (in big installations) lead to a lot of websocket
connections between CSMS and LC needed. For further information, please refer to OCPP implementation guide
in Part 4.

8.4. Non-OCPP Charging Stations connected to CSMS via OCPP Local

Controller
Description
This setup has multiple non-OCPP Charging Stations that are abstracted away using a OCPP enabled Local Controller. When
applying OCPP in this situation, the LC should be considered as a Charging Station with many EVSEs or the LC should act as
multiple OCPP Charging Stations (having their own Charging Station Identity).

Charging
non-OCPP Station 1
OCPP
CSMS LC non-OCPP

Charging
Station n

Figure 10. Multiple non-OCPP Charging Stations connected to CSMS via Local Controller

8.5. DSO control signals to CSMS

Description
This is a set up in which the CSMS is the only application sending signals to a its Charging Stations, but the CSMS receives smart
charging signals from a DSO based on (most likely) grid constraints. This means that a non-OCPP signal such as OpenADR or
OSCP is received and based on this signal, the CSMS limits charging on its Charging Stations. CSOs that want full control over their
Charging Station use this architecture, this way they are in control of the amount of energy being used by their Charging Stations.
This can be done by sending charging profiles / charging schedules to Charging Stations.

Non-OCPP (e.g. OpenADR or OSCP) OCPP Charging

DSO CSMS
Station

Figure 11. Smart Charging - DSO control signals to CSMS

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 16/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

8.6. Parallel control by CSMS and EMS

Description
In a (semi-)private situation where a Charging Station is not only connected to the CSMS, but also to an Energy Management
System, some form of parallel control should be supported. OCPP should at least be used for Charging Station maintenance, but
OCPP 2.0.1 also supports reporting external smart charging control limits. So if the Energy Management System decides that
charging at a later time is "better", the Energy Management System can impose an external limit (e.g. 0) to a Charging Station,
which the Charging Station in turn can report to the CSMS via OCPP. The Energy Management System might get input from e.g.
Local port of Smart Meter to prevent overloading connection but can also have other reasons for not charging (e.g. weather
conditions).

OCPP Charging OCPP or other

CSMS EMS
Station

Figure 12. Parallel control by CSMS and EMS

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 17/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

9. Part 1 Appendix: OCPP Information Model

9.1. Explanation of UML representation and message generation
In the next paragraph, the UML schemes of the OCPP Information Model are shown. The model is based on the Common
Information Model (CIM) and to some extent to the CEFACT naming standards (only part of the standard). The objects in the model
are named BusinessComponents and inherit properties from the CIM IdentifiedObject, such as MRID and Name. In the UML
diagrams the attributes that are inherited from IdentifiedObject are shown under the IdentifiedObject stereotype (between < < > >).
Other attributes are listed under the stereotype < < Content > >.
The messages in OCPP are derived from the model represented in the next paragraph, in a 3 step process:

Specification

Information Model Message Model

Schemas

Figure 13. Process from information Model to Messages / schemes

After creating the Information Model, the messages are created based on the Information Model. However, in this transition (first
arrow), some rules are (manually) applied for modelling messages. The most important rule that is applied, is that messages
containing a reference to a <class> with only one <field>, are replaced by a field with the name <class><field>. For example, if a
message contains a Transaction, with only an Id, this is replaced by a transactionId.
In the next step, when generating the messages and datatypes section of Part 2 of the specification, for readability, all Core
DataTypes such as CounterType, are replaced by the Primitive DataType they refer to (except for enumerations) in this example
integer.

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 18/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

9.2. Visual Representation of OCPP Information Model

«BusinessComponent» +TxnStartSampledValue «BusinessComponent»
Components::IdentifiedObject Metering::SampledValueType
0..*
«Content» «Content»
+ MRID: NumericIdentifierType [0..1] + Value: MeasureType [0..1]
+ ObjectID: IdentifierType [0..*] +TxnStopSampledValue
+ Context: ReadingContextEnumType [0..1]
+ Name: NameType [0..1] + Measurand: MeasurandEnumType [0..1]
0..*
+ AliasName: NameType [0..*] + Phase: PhaseEnumType [0..1]
«BusinessComponent»
+ Description: TextType [0..*] + Location: LocationEnumType [0..1]
Components::MessageInfoType
+TxnUpdateSampledValue
«Content»
+ Priority: MessagePriorityEnumType [0..1] 0..*
+Message
+ State: MessageStateEnumType [0..1]
+ StartDateTime: DateTimeType [0..1] 0..*
+ EndDateTime: DateTimeType [0..1] «BusinessComponent» DeviceType
+Transaction TransactionType «BusinessComponent»
RootModel::EVSEType
0..1 «Content»
DeviceFunctionType + ConnectorId: NumericIdentifierType [0..1] +EVSE
+ SeqNo: CounterType [0..1]
«BusinessComponent» + ChargingState: ChargingStateEnumType [0..1] +Transaction +EVSE
+MeteringFunction +Transaction «Content»
+ Offline: IndicatorType [0..1] 0..1
Metering::MeteringFunctionType
0..* 0..1 + Switch3To1PhaseSupported: IndicatorType [0..1]
0..* 0..* + StartedTimestamp: DateTimeType [0..1]
+ StoppedTimestamp: DateTimeType [0..1]
+ TimeSpentCharging: SecondsType [0..1]
+ StoppedReason: ReasonEnumType [0..1] +EVSE 0..1
«BusinessComponent» +EV +Transaction
+ NumberOfPhasesUsed: CounterType [0..1]
RootModel::EVType + MaxAllowedHours: SecondsType [0..1]
0..1 0..1 +Transaction
+ MaxAllowedKwh: PowerType [0..1]
+Transaction 0..*
+EV 0..* + TriggerReason: TriggerReasonEnumType [0..1]
+ RemoteStartID: RequestIdType [0..1]
0..1
+ Id: TransactionIdType [0..1]
+ RunningCost: AmountType [0..1]
+ TotalCost: AmountType [0..1]
+Reservation 0..*
+Transaction 0..1 +Transaction 0..1
+Reservation «BusinessComponent»
ReservationType
+ChargingProfile 0..*
0..1
«BusinessComponent» +IDToken 0..* «Content»
SmartCharging::ChargingProfileType + CreationTimestamp: DateTimeType [0..1]
«BusinessComponent» +IDToken +Reservation + ExpiryDateTime: DateTimeType [0..1]
+ TransactionId: TransactionIdType [0..1] +ChargingProfile Security::IDTokenType ::IdentifiedObject
0..1 0..*
«Content» + MRID: NumericIdentifierType [0..1]
0..1 + IDToken: TokenType [0..1]
+ StackLevel: CounterType [0..1] + ObjectID: IdentifierType [0..*]
+ Type: IDTokenEnumType [0..1] +GroupIDToken +Reservation + Name: NameType [0..1]
+ Primary: IndicatorType [0..1]
+ TimeBase: DateTimeType [0..1] + AliasName: NameType [0..*]
0..1 0..*
+ ChargingProfilePurpose: + Description: TextType [0..*]
ChargingProfilePurposeEnumType [0..1]
+ ChargingProfileKind: ChargingProfileKindEnumType +IDToken 0..1 +Reservation 0..*
[0..1]
+ RecurrencyKind: RecurrencyKindEnumType [0..1]
+ ValidFrom: DateTimeType [0..1]
+ ValidTo: DateTimeType [0..1] +IDTokenInfo 0..1 +Connector 0..1
+ ChargingLimitSource: ChargingLimitSourceEnumType
«BusinessComponent» DeviceType
[0..*]
Security::IDTokenInfoType «BusinessComponent»
+Connector
+ChargingProfile 0..* RootModel::ConnectorType
«Content»
0..1
+ Status: AuthorizationStatusEnumType [0..1] «Content»
+ CacheExpiryDateTime: DateTimeType [0..1] + ConnectorType: ConnectorEnumType [0..1]
+ Language1: LanguageType [0..1] + CableCapacity: CurrentType [0..*]
+ Language2: LanguageType [0..1]
+ ChargingPriority: NumericIdentifierType [0..1]
+ ListID: IdentifierType [0..1]
+ ListEntryTimestamp: DateTimeType [0..1]

Figure 14. OCPP Information Model: Transactions

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 19/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«BusinessComponent»
ChargingSchedulePeriodType
«BusinessComponent»
ChargingLimitType
«Content»
«Content» + StartPeriod: SecondsType [0..1]
+ChargingLimit+ Limit: SingleFractionDigitNumericType [0..1] + Limit: MeasureType [0..1]
+ ChargingRateUnit: ChargingRateUnitEnumType [0..1] + NumberPhases: CounterType [0..1]
0..1 + + PhaseToUse: NumericType [0..1]
ChargingLimitSource: ChargingLimitSourceEnumType [0..1]
+ IsGridCritical: IndicatorType [0..1] +ChargingSchedulePeriod 0..*

+ChargingSchedule0..*
«BusinessComponent»
CompositeScheduleType IdentifiedObject
+CompositeSchedule +ChargingSchedule «BusinessComponent»
«Content»
ChargingScheduleType
0..* + Duration: SecondsType [0..1] 0..1
+ ChargingRateUnit: ChargingRateUnitEnumType [0..1]
«Content»
+ StartDateTime: DateTimeType [0..1]
+EVSE 0..* +EVSE 0..1 + StartSchedule: DateTimeType [0..1]
+CompositeSchedule 0..* + Duration: SecondsType [0..1]
DeviceType + ChargingRateUnit: ChargingRateUnitEnumType [0..1]
«BusinessComponent» + MinChargingRate: NumericType [0..1]
RootModel::EVSEType +ChargingSchedule 0..1
IdentifiedObject
+ ConnectorId: NumericIdentifierType [0..1] «BusinessComponent»
«Content» Transactions::TransactionType +ChargePoint0..1
+ Switch3To1PhaseSupported: IndicatorType [0..1]
«Content» DeviceType
+ SeqNo: CounterType [0..1] «BusinessComponent»
+ ChargingState: ChargingStateEnumType [0..1] RootModel::ChargingStationType
+EVSE
+EVSE 0..1
0..1 +EVSE 0..1
+ Offline: IndicatorType [0..1]
+ StartedTimestamp: DateTimeType [0..1]
+ StoppedTimestamp: DateTimeType [0..1] +ChargePoint 0..1
+Transaction
+ TimeSpentCharging: SecondsType [0..1]
+ StoppedReason: ReasonEnumType [0..1]
0..1 +ChargingProfile 0..* +ChargingProfile 0..*
+ NumberOfPhasesUsed: CounterType [0..1]
+Transaction + MaxAllowedHours: SecondsType [0..1] IdentifiedObject
+ MaxAllowedKwh: PowerType [0..1]
+ChargingProfile «BusinessComponent»
0..* + TriggerReason: TriggerReasonEnumType [0..1]
+Transaction ChargingProfileType
+ RemoteStartID: RequestIdType [0..1] 0..1
+ Id: TransactionIdType [0..1] + TransactionId: TransactionIdType [0..1]
0..* + RunningCost: AmountType [0..1]
«Content»
+ TotalCost: AmountType [0..1]
+ChargingProfile + StackLevel: CounterType [0..1]
{ConnectorUse} + Primary: IndicatorType [0..1]
+Transaction 0..1 0..* + TimeBase: DateTimeType [0..1]
+ ChargingProfilePurpose: ChargingProfilePurposeEnumType [0..1]
+EV 0..1
+ ChargingProfileKind: ChargingProfileKindEnumType [0..1]
+EV + RecurrencyKind: RecurrencyKindEnumType [0..1]
+EV «BusinessComponent»
+ ValidFrom: DateTimeType [0..1]
+EV RootModel::EVType 0..*
0..1 + ValidTo: DateTimeType [0..1]
0..1 + ChargingLimitSource: ChargingLimitSourceEnumType [0..*]
+Connector +Connector
0..*+Connector0..1
0..1 +EV
«BusinessComponent»
DeviceType 0..1
ChargingNeedsType
«BusinessComponent» +EV 0..1 +ChargingNeeds
RootModel::ConnectorType «Content»
0..1
+ RequestedEnergyTransfer: EnergyTransferModeEnumType [0..1]
«Content» + DepartureTime: DateTimeType [0..1]
+ ConnectorType: ConnectorEnumType [0..1] +EVCC 0..1
+ CableCapacity: CurrentType [0..*] +ChargingNeeds 0..* 0..* +ChargingNeeds
«BusinessComponent»
RootModel::EVCCType

«Content» +ACChargingParameters
+ EMAID: ChargingContractIdentifierType [0..1]
0..1
+ ContractSignatureEncryptedPrivateKey: SmallBinaryObjectType [0..1]
+ DHPublicKey: PublicKeyType [0..1] «BusinessComponent»
+ Signature: SignatureType [0..1] ACChargingParametersType

«Content»
+RootCertificate 0..* + EnergyAmount: EnergyAmountType [0..1]
+ EVMinCurrent: CurrentType [0..1]
+ContractSignatureCertificateChain 0..1 «BusinessComponent»
+ EVMaxCurrent: CurrentType [0..1]
Security::X509IssuerSerialType
+ EVMaxVoltage: VoltageType [0..1]
IdentifiedObject
«BusinessComponent» «Content»
+SAProvisioningCertificateChain Security::CertificateChainType + X509IssuerName: IssuerIdentifierType [0..1]
+ X509SerialNumber: IntegerType [0..1]
+DCChargingParameters
0..1 «Content»
0..1
+CertificateChain + Certificate: Base64String800Type [0..1]
+ CertificateSerial: CI20TextType [0..1]
«BusinessComponent»
0..* + ExpiryDate: DateType [0..1]
DCChargingParametersType
+OEMProvisioningCertificate ::IdentifiedObject
+ MRID: NumericIdentifierType [0..1] «Content»
0..1 + ObjectID: IdentifierType [0..*] + EVMaxCurrent: NumericIdentifierType [0..1]
+ Name: NameType [0..1] +ParentCertificate 0..1 + EVMaxVoltage: NumericIdentifierType [0..1]
+ AliasName: NameType [0..*] + EnergyAmount: NumericIdentifierType [0..1]
+ Description: TextType [0..*] + EVMaxPower: NumericIdentifierType [0..1]
+ StateOfCharge: PercentageType [0..1]
+ChildCertificate 0..*
+ EVEnergyCapacity: NumericIdentifierType [0..1]
+ FullSoC: PercentageType [0..1]
+ BulkSoC: PercentageType [0..1]

Figure 15. OCPP Information Model: SmartCharging

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 20/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«PRIMSimpleType»

(from PrimitiveDataTypes)

IdentifiedObject «BusinessComponent» «CDTComplexType,LDT,ECDMChange,...

«BusinessComponent» MeterValueType
RootModel::DeviceFunctionType
«Content» «Supplementary»
+ Timestamp: DateTimeType [0..1] + measureUnit: String [0..1]
+ measureUnit.CodeListVersion: String [0..1]
+MeterValue 0..* +MeterValue 0..*
+SampledValue 0..* (from CoreDataTypes)
«BusinessComponent»
SampledValueType

«Content»
«BusinessComponent» + Value: MeasureType [0..1]
MeteringFunctionType +MeteringFunction + Context: ReadingContextEnumType [0..1]
+ Measurand: MeasurandEnumType [0..1]
0..1
+ Phase: PhaseEnumType [0..1]
+ Location: LocationEnumType [0..1]

+Meter 0..1 +Meter 0..1

DeviceType 0..1
«BusinessComponent»
«BusinessComponent» +SampledValue
ClockAlignedMeteringFunctionType
MeterType
«Content»
«Content»
+ ClockAlignedDataInterval: SecondsType [0..1]
+ Location: LocationEnumType [0..1] +SignedMeterValue + MeterValueSignature: Base64String2500Type [0..1]
+ MeterValuesAlignedData: MeasurandEnumType [0..*]
+ SupportedMeasurands: MeasurandEnumType [0..*] + SignatureMethod: SignatureMethodEnumType
+ MeterValuesAlignedDataMaxLength: CounterType [0..1]
+ TxnStoppedAlignedData: MeasurandEnumType [0..*] 0..1 + EncodingMethod: EncodingMethodEnumType [0..1]
+ TxnStoppedAlignedDataMaxLength: CounterType [0..1] + EncodedMeterValue: Base64String512Type [0..1]
+UnitOfMeasure 0..1

«BusinessComponent»
UnitOfMeasureType

+ Unit: CI20TextType [0..1]

+ Multiplier: IntegerType [0..1]

Figure 16. OCPP Information Model: Metering

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 21/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«BusinessComponent»
ComponentType

+ Name: CI50TextType [0..1]

+ Instance: CI50TextType [0..1]
+ evse: NumericIdentifierType [0..1]
+ connector: NumericIdentifierType [0..1]

+Component 0..*

+Variable 0..1

«BusinessComponent»
+Variable
VariableType
1
+ Name: CI50TextType [0..1]
+ Instance: CI50TextType [0..1]

+Variable 0..1 0..1 +Variable

+VariableMonitoring1..* +VariableAttribute 0..*

«BusinessComponent» «BusinessComponent»
VariableMonitoringType VariableAttributeType

+ Value: MeasureType + Type: AttributeEnumType [0..1] = Actual

+ Type: MonitorEnumType + Value: CI255TextType
+ Severity: SeverityEnumType + Mutability: MutabilityEnumType [0..1]
+ Cleared: IndicatorType [0..1] = false + Persistence: IndicatorType [0..1]
+ Transaction: IndicatorType [0..1] + Constant: IndicatorType

+VariableCharacteristics 0..*

«BusinessComponent»
VariableCharacteristicsType

+ Units: MeasurementUnitType
+ DataType: DataEnumType
+ MinLimit: IntegerType [0..1]
+ MaxLimit: IntegerType [0..1]
+ ValuesList: CI500TextType [0..1]
+ SupportsMonitoring: IndicatorType

Figure 17. OCPP Information Model: Device Model

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 22/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

DeviceType
«BusinessComponent» IdentifiedObject
RootModel::ChargingStationType «BusinessComponent»
IdentifiedObject
Components::LogType
«BusinessComponent» «deprecated, Content» +SecurityLog
SecurityProfileType + ChargeBoxSerialNumber: SerialNumberType [0..1] «Content»
0..1
«Content» + Filename: FilenameType [0..1]
«Content» + EVSECount: CounterType [0..1] + RemoteLocation: URIType [0..1]
::IdentifiedObject + LogStartedDateTime: DateTimeType [0..1]
+ChargePoint 0..1
+ MRID: NumericIdentifierType [0..1] + LogStoppedDateTime: DateTimeType
+ ObjectID: IdentifierType [0..*] + OldestTimestamp: DateTimeType [0..1]
+ Name: NameType [0..1] +SecurityProfile + LatestTimestamp: DateTimeType [0..1]
+ AliasName: NameType [0..*]
+ Description: TextType [0..*] 0..1

+ManufacturerHierarchy +ChargePointOperatorHierarchy
0..1 0..1

«BusinessComponent» «BusinessComponent» «BusinessComponent»

BasicAuthenticationProfileType TLSDigestProfileType CertificateHierarchyType

«Content» «Content» «Content»

+ UserName: UserNameType [0..1] + ChargePointCertificate: X509CertificateDigestType [0..1] + Type: CertificateHierarchyCodeType [0..1]
+ Password: PasswordType [0..1] + CentralServerCertificate: X509CertificateDigestType [0..1]

+CertificateChain 0..*

IdentifiedObject
+CentralServerCertificate
«BusinessComponent»
0..1 CertificateChainType +RootCertificate 0..*
+ChargePointCertificate
«BusinessComponent» «Content» «BusinessComponent»
0..1 + Certificate: Base64String800Type [0..1] X509IssuerSerialType
TLSBasicAuthenticationProfileType
+CentralServerCertificate + CertificateSerial: CI20TextType [0..1] +RootCertificate
+ ExpiryDate: DateType [0..1] «Content»
0..1 0..1
+ X509IssuerName: IssuerIdentifierType [0..1]
+ X509SerialNumber: IntegerType [0..1]
+FirmwareSigningCertificate
IdentifiedObject
0..1
«BusinessComponent»
Components::FirmwareType +ParentCertificate 0..1

«Content»
+ Version: VersionType [0..1]
+ChildCertificate 0..*
+ Status: FirmwareStatusEnumType [0..1]
+ Location: URIType [0..1]
+ RetrieveDateTime: DateTimeType [0..1]
+ InstallDateTime: DateTimeType [0..1]
+ Signature: Base64String800Type [0..1]
+ ServiceURL: URIType [0..1]

Figure 18. OCPP Information Model: Security-Profiles

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 23/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«BusinessComponent»
Components::IdentifiedObject

«Content»
+ MRID: NumericIdentifierType [0..1]
+ ObjectID: IdentifierType [0..*]
+ Name: NameType [0..1]
+ AliasName: NameType [0..*]
+ Description: TextType [0..*]

«BusinessComponent» «BusinessComponent»
RootModel::DeviceFunctionType OCSPRequestDataType

+ HashAlgorithm: HashAlgorithmEnumType [0..1]

+ IssuerNameHash: IssuerNameType [0..1]
+ IssuerKeyHash: HashType [0..1]
+ SerialNumber: SerialNumberType [0..1]
«BusinessComponent» +AuthorizationList
+ ResponderURL: URIType [0..1]
AuthorizationListType
0..* +OCSPCertificateHash 0..*
«Content»
+ VersionNumber: IntegerType [0..1] +AuthorizationCache
+ MaxLength: CounterType [0..1]
+ MaxTransmitCount: CounterType [0..1] 0..1
+ LocalAuthListEnabled: IndicatorType [0..1]
+ LocalAuthListMaxLength: CounterType [0..1]
+ SendLocalListMaxLength: CounterType [0..1] «BusinessComponent» +AuthorizationFunction «BusinessComponent»
AuthorizationFunctionType Transactions::TransactionType
+AuthorizationList 0..1 0..*
«Content» «Content»
+ AuthorizationListSupported: IndicatorType [0..1] + SeqNo: CounterType [0..1]
+ LocalAuthorizationEnabled: IndicatorType [0..1] + ChargingState: ChargingStateEnumType [0..1]
+Transaction
+ LocalAuthorizeOffline: IndicatorType [0..1] + Offline: IndicatorType [0..1]
+ LocalPreAuthorize: IndicatorType [0..1] 0..* + StartedTimestamp: DateTimeType [0..1]
+ AuthorizationCacheEnabled: IndicatorType [0..1] + StoppedTimestamp: DateTimeType [0..1]
+ AllowOfflineTxForUnknownID: IndicatorType [0..1]+AuthorizationFunction + TimeSpentCharging: SecondsType [0..1]
+ AuthorizeRequestTxRequests: IndicatorType [0..1] 0..1 + StoppedReason: ReasonEnumType [0..1]
+ LawEnforcementGroupId: TokenType [0..1] + NumberOfPhasesUsed: CounterType [0..1]
+ MaxAllowedHours: SecondsType [0..1]
+ MaxAllowedKwh: PowerType [0..1]
+ TriggerReason: TriggerReasonEnumType [0..1]
+ RemoteStartID: RequestIdType [0..1]
+ Id: TransactionIdType [0..1]
+ RunningCost: AmountType [0..1]
«BusinessComponent» + TotalCost: AmountType [0..1]
+LocalAuthorization IDTokenType +IDToken
+Transaction 0..1
0..* + IDToken: TokenType [0..1] 0..*
+ Type: IDTokenEnumType [0..1]

+IDToken 0..1
«enumeration,BDTEnu...
CodeLists::
«enumeration,BDT...
AuthorizationStatusEnumType +IDTokenInfo 0..1
CodeLists::
IDTokenEnumType
«enum, Facet» «BusinessComponent»
Accepted IDTokenInfoType
«enum, Facet»
Blocked «BusinessComponent»
Central
Expired «Content» Components::MessageContentType
eMAID +IDTokenInfo +TariffMessage
Invalid + Status: AuthorizationStatusEnumType [0..1]
ISO14443
NoCredit + CacheExpiryDateTime: DateTimeType [0..1] 0..* 0..1 «Content»
ISO15693 + Language1: LanguageType [0..1]
NotAllowedTypeEVSE + Format: MessageFormatEnumType [0..1]
Local + Language2: LanguageType [0..1] +IDTokenInfo+PersonalMessage
NotAtThisLocation + Language: LanguageType [0..1]
NoAuthorization
NotAtThisTime + ChargingPriority: NumericIdentifierType [0..1]
KeyCode 0..* 0..1 + Content: MessageType [0..1]
ConcurrentTx + ListID: IdentifierType [0..1]
Unknown + ListEntryTimestamp: DateTimeType [0..1]

Figure 19. OCPP Information Model: Security-Authorization

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 24/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«BusinessComponent»
Components::IdentifiedObject

«Content»
+ MRID: NumericIdentifierType [0..1]
+ ObjectID: IdentifierType [0..*]
+ Name: NameType [0..1]
+ AliasName: NameType [0..*]
+ Description: TextType [0..*]
«BusinessComponent»
VPNType

«Content»
+ Server: URIType [0..1] «BusinessComponent»
+ User: UserNameType [0..1] RootModel::DeviceFunctionType
+ Group: GroupNameType [0..1]
+ Password: PasswordType [0..1]
+ Key: VPNKeyType [0..1]
+ Type: VPNCodeType [0..1]

+VPN 0..1
«BusinessComponent»
NetworkConnectionProfileType
«BusinessComponent»
«Content» TriggerType
+Receiver +Trigger
+ Priority: IntegerType [0..1]
+ HeartbeatInterval: SecondsType [0..1] 0..* 0..* «Content»
+ OcppVersion: OCPPVersionCodeType [0..1] + TriggerCode: MessageTriggerEnumType [0..1]
+ OcppTransport: OCPPTransportCodeType [0..1]
«BusinessComponent» + OcppCsmsUrl: URIType [0..*]
APNType + OcppInterface: OCPPInterfaceCodeType [0..1]

«Content»
+ APN: URIType [0..1] +CommunicationFunction 0..*
+ APNUserName: UserNameType [0..1]
+ APNPassword: PasswordType [0..1]
+ SimPin: PINEnumType [0..1]
+ PreferredNetwork: MobileNetworkIDType [0..1]
+ UseOnlyPreferredNetwork: IndicatorType [0..1]
+ APNAuthentication: APNAuthenticationCodeType [0..1]

+APN 0..1

+CommunicationModule 0..1

«BusinessComponent»
ModemType

«Content»
+ ICCID: SimIdentifierType [0..1]
+ IMSI: SimIdentifierType [0..1]

Figure 20. OCPP Information Model: Communication

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 25/26 Part 1 - Architecture & Topology
Edition 3 FINAL, 2024-05-06

«BusinessComponent»
Components::IdentifiedObject

«Content»
+ MRID: NumericIdentifierType [0..1]
+ ObjectID: IdentifierType [0..*]
+ Name: NameType [0..1]
+ AliasName: NameType [0..*]
+ Description: TextType [0..*]

«BusinessComponent»
SAScheduleType

+SASchedule 0..*

«BusinessComponent» +SalesTariff
SalesTariffType
0..1
«Content»
+ SalesTariffDescription: TariffDescriptionType [0..1]
+ NumEPriceLevels: CounterType [0..1]

0..1

+SalesTariffEntry 1..1024

«BusinessComponent»
SalesTariffEntryType «BusinessComponent»
PMaxScheduleType
+ EPriceLevel: UnsignedIntegerType [0..1]
«Content»
0..* 0..1 + PMax: PowerType [0..1]

+ConsumptionCost 0..3 +RelativeTimeInterval 0..1

+RelativeTimeInterval
«BusinessComponent» 0..1 «BusinessComponent»
ConsumptionCostType RelativeTimeIntervalType

«Content» «Content»
+ StartValue: NumericType [0..1] + Start: SecondsType [0..1]
+ Duration: SecondsType [0..1]

+Cost 0..*

«BusinessComponent»
CostType

«Content»
+ CostKind: CostKindCodeType [0..1]
+ Amount: AmountType [0..1]
+ AmountMultiplier: IntegerType [0..1]

Figure 21. OCPP Information Model: SecondaryActorSchedule

OCPP 2.0.1 Edition 3 - © Open Charge Alliance 2024 26/26 Part 1 - Architecture & Topology