The device model offers an entirely new way for operators to see inside a charging station, decreasing maintenance costs and station downtime by exposing specific errors directly to the operator. The device model is a key differentiator between OCPP 2.0.1 and previous versions such as OCPP 1.6.
When implementing OCPP 2.0.1 for either a CS or CSMS the storage and visualisation of the device model is a key challenge due to the tiered model and various data points related to device model variables. The article below will outline the key considerations when designing and implementing a device model on either a CS or CSMS.
The device model is described in more detail in the various OCPP 2.0.1 specification documents:
OCPP-2.0.1_part1_architecture_topology.pdf describes the 3 tier model and the device model at a high level. This should be the first step when trying to understand the functionality and structure of the device model.OCPP-2.0.1_part2_appendices.pdf outlines the standardised component names and associated variables. This specifies that for example if a CS has an air cooling system it should be called AirCoolingSystem and then the CSMS can display this in a standard and relevant way for all charging stations with that optional component.OCPP-2.0.1_part2_specification.pdf specifies the channels of communication between the CS and CSMS such as "B07 - Get Base Report". It also lists the components and variables which are used in these use cases and specifies which are required in the Referenced Components and Variables section.The concepts of the device model start with the 3 tier model which describes all charging stations.
Source: OCPP 2.0.1 Part 1 - Architecture Topology
Each Charging Station contains EVSEs which each contain Connectors. Typically each station will have 1-2 EVSEs which each have 1-2 Connectors, but there is no logical limitation on these numbers in the specification.
The Charging Station is the physical interface that the user interacts with. Components that exist on the charging station level may include a screen or a payment terminal for example.
The EVSE is the power point and can deliver energy to a vehicle independently, so a station with 2 EVSEs can charge 2 vehicles simultaneously. Components on the EVSE level are most likely to do with power delivery such as a fuse or a cooling fan.
The Connector is just a cable and a socket of a particular type. Multiple connectors on an EVSE are just alternative options for the driver, but cannot be used at the same time. An example of a connector level component could be a cable lock.
Any device model component can be assigned to any of these three levels through EVSE and Connector addressing fields. They’re also all Physical Components themselves and can have their own variables with states, for example Problem which can indicate if the station, evse, or connector has some general problem or fault.
All components in the device model can be categorised as either “Physical” or “Controller” components. Components can be required, non required but with standardised naming, or entirely custom. The CSMS software can have special visualisations or interactions with the standardised components due to their rigid definitions in the specification. The custom components should still be handled by the CSMS due to the standardised structure, but will lack any specific visualisation by default.
These are real hardware components, they may be on the charging station or they may be other hardware associated with it like a solar panel or a car park access barrier.
The only required physical components for every charging station are one each of Charging Station, EVSE, and Connector. These describe the three tier structure of that particular station and should be used for the setting and sending of connector availability statuses for example.
Other physical components are entirely optional but encouraged where relevant. The more physical components are made available by the charging station the more visibility and control is available for the charge point operator.
These can be thought of as groupings of settings which control aspects of the stations operation. They always end in the suffix "Ctrlr" and often contain other abbreviations, for example “TxCtrlr” is for transaction settings.
There are a number of required controller components covering a variety of configurations for the charging station. A number of these need special handling and overlap with some other variables which may be present in the codebase, such as the AuthCtrlr.BasicAuthPassword which is used to authenticate the CS with the CSMS.
The details of each controller component and their variables is described in the Referenced Components and Variables section of the specification.
Variables are used for storing information and component settings and must always be linked to a component. Like components there is huge flexibility in their use, there are some components which have required variables but charger OEMs can also add an unlimited number of uniquely named variables for each component on the station.
A number of commonly used variables are standardised by the specification so that all chargers use the same name, datatype, and unit to describe the same variable. These can be found in Part 2 - Appendices.
The relationship diagram below describes how variables are structures and how they relate to components. The complex definition of a variable allows for a high degree of flexibility and control over the definition of a variable, for example allowing users to set a maximum, minimum, or target value.
The monitoring entity in the diagram is used for setting monitors on variable values in order to alert users on the CSMS side of important events. This is another feature new to OCPP 2.0.1 which is explained fully in the OCPP 2.0.1 Monitoring article.
Source: OCPP 2.0.1 Part 1 - Architecture Topology
Excluding monitoring for now, the messages required to communicate the device model between CS and CSMS are relatively simple. The CSMS requests the device model and the CS sends it, sometimes in multiple parts due to the size of the payload.
The message the CSMS sends to the CS to ask it to send across its device model. This is typically sent during the boot sequence but can be sent at any time. The CSMS can specify the “report base” which is returned by the CS; FullInventory, ConfigurationInventory, or SummaryInventory
Notify is the message the charging station sends to the CSMS which contains all of its device model information. A NotifyReport is sent always after the CSMS requests it using a GetBaseReport and is likely the longest message a CS will ever send to a CSMS. Due to its length there are pagination options, indicated by the tbc flag at the end of the example below.
The following is an example NotifyReport for a charging station with 2 EVSEs each with 2 connectors.
When implementing a device model it’s important on both the CS and the CSMS side to store the components, variables, and variable data points in a way which makes them easy to access and respects the relationships between them.
Typically this would be done in a relational database with tables for each of the objects shown in the diagram above; Component, Variable, VariableAttribute, VariableCharacteristic, VariableMonitoring. As there can be a maximum of one VariableCharacteristic for each Variable then a further simplification can be made by combining these tables, with each VariableCharacteristic column being optional.
Other storage solutions are possible, and on the CS side there is more flexibility to store and retrieve the values as best suits the architecture. When the base report is sent from CS to CSMS the CS retrieves its various data points and packages it up into the NotifyReport JSON structure shown above and then the CSMS must unpack this and store in its own database.
The CSMS has the unenviable job of unpacking the NotifyReport JSON into a (probably relational) database and then accessing this data per charger in a format which is easy for its API/Frontend/user to read and interpret.
For example, if a user wants to see the current TxStopPoint and change it from a list of options the CSMS must fetch and display the TxCtrlr component and each of the related variables including the TxStopPoint. Then it must fetch and display the variable attributes, find the one which is of type Actual and display that value. If the attribute mutability is ReadWrite then it can be changed, the list of options comes from the variable characteristics ValuesList.
As this shows the implementation of the device model is not trivial, and especially on the CSMS side it can be a challenge to properly represent it on a user interface which is intuitive and easy to use. However this is an integral part of the OCPP 2.0.1 CSMS experience so it’s important for CSMS developers to focus on.