推荐一套企业级开源充电桩平台：完整代码包含多租户、硬件模拟器、多运营商、多小程序，汽车 电动自行车、云快充协议；——(慧哥)慧知开源充电桩平台；https://liwenhui.blog.csdn.net/article/details/134773779?spm=1001.2014.3001.5502

**Version History

版本历史**

1. Scope

1.范围

This document defines the protocol used between aCharge PointandCentral System. If the protocol requires a certain action or response from one side or the other, then this will be stated in this document.

本文档定义了充电桩和中央系统之间使用的协议。如果协议要求一方或另一方采取某种行动或作出回应，则将在本文件中予以说明。

The specification does not define the communication technology. Any technology will do, as long as it supports TCP/IP connectivity.

该规范没有定义通信技术。任何技术都可以，只要它支持TCP/IP连接。

2. Terminology and Conventions

2.术语和惯例

2.1. Conventions

2.1. 习俗

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]], subject to the following additional clarification clause:

本文档中的关键字“必须”、“不得”、“必需”、“应”、“不应”、《应该》、《不应该》、“推荐”、“可能”和“可选”应按照[RFC2119]]中的描述进行解释，但须遵守以下附加澄清条款：

The phrase “valid reasons in particular circumstances” relating to the usage of the terms “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, and “NOT RECOMMENDED” is to be taken to mean technically valid reasons, such as the absence of necessary hardware to support a function from a charge point design: for the purposes of this specification it specifically excludes decisions made on commercial, or other non-technical grounds, such as cost of implementation, or likelihood of use.

与“应该”、“不应该”、《建议》和《不建议》等术语的使用有关的“特定情况下的有效理由”一词应被视为技术上有效的理由，例如缺乏支持充电点设计功能的必要硬件：就本规范而言，它明确排除了基于商业或其他非技术原因（如实施成本或使用可能性）做出的决定。

All sections and appendixes, except “Scope” and “Terminology and Conventions”, are normative, unless they are explicitly indicated to be informative.

除“范围”和“术语和惯例”外，所有章节和附录都是规范性的，除非明确指出是信息性的。

2.2. Definitions

2.2. 定义

This section contains the terminology that is used throughout this document.

本节包含本文档中使用的术语。

2.3. Abbreviations

2.3. 缩写

2.4. References

2.4. 工具书类

3.导言

This is the specification for OCPP version 1.6.

这是OCPP 1.6版本的规范。

OCPP is a standard open protocol for communication between Charge Points and a Central System and is designed to accommodate any type of charging technique.

OCPP是充电点和中央系统之间通信的标准开放协议，旨在适应任何类型的充电技术。

OCPP 1.6 introduces new features to accommodate the market: Smart Charging, OCPP using JSON over Websockets, better diagnostics possibilities (Reason), more Charge PointStatuses andTriggerMessage. OCPP 1.6 is based on OCPP 1.5, with some new features and a lot of textual improvements, clarifications and fixes for all known ambiguities. Due to improvements and new features, OCPP 1.6 is not backward compatible with OCPP 1.5.

OCPP 1.6引入了新功能以适应市场：智能充电、使用JSON over Websockets的OCPP、更好的诊断可能性（Reason）、更多的充电桩Statuses和TriggerMessage。OCPP 1.6基于OCPP 1.5，具有一些新功能，并对所有已知的歧义进行了大量的文本改进、澄清和修复。由于改进和新功能，OCPP 1.6与OCPP 1.5不向后兼容。

For a full list of changes, see:New in OCPP 1.6.

有关更改的完整列表，请参阅：New in OCPP 1.6。

Some basic concepts are explained in the sections below in this introductory chapter. The chapters:Operations Initiated by Charge Point and Operations Initiated by Central System describe the operations supported by the protocol. The exact messages and their parameters are detailed in the chapter:Messages and data types are described in chapter:Types. Defined configuration keys are described in the chapter:Standard Configuration Key Names & Values.

本介绍性章节的以下部分解释了一些基本概念。章节：Operations Initiated by Charge Point并Operations Initiated by Central System描述协议支持的操作。第章详细介绍了确切的消息及其参数，第章描述了数据类型Types。Messages定义的配置键在以下章节中进行了描述：Standard Configuration Key Names & Values。

3.1. Document structure

3.1. 文档结构

With the introduction of OCPP 1.6, there are two different flavours of OCPP; next to the SOAP based implementations, there is the possibility to use the much more compact JSON alternative. To avoid confusion in communication on the type of implementation we recommend using the distinct suffixes -J and -S to indicate JSON or SOAP. In generic terms this would be OCPP-J for JSON and OCPP-S for SOAP.

随着OCPP 1.6的推出，OCPP有两种不同的口味；除了基于SOAP的实现之外，还可以使用更紧凑的JSON替代方案。为了避免在通信中混淆实现类型，我们建议使用不同的后缀-J和-S来表示JSON或SOAP。一般来说，这将是JSON的OCPP-J和SOAP的OCPP-S。

To support the different flavours, the OCPP standard is divided in multiple documents. The base document (the one you are reading now) contains the technical protocol specification. The technical protocol specification must be used with one of the transport protocol specifications. theOCPP SOAP Specification contains the implementation specification needed to make a OCPP-S implementation. For OCPP-J, theOCPP JSON Specification must be used.

为了支持不同的口味，OCPP标准被分为多个文档。基础文档（您现在正在阅读的文档）包含技术协议规范。技术协议规范必须与传输协议规范之一一起使用。包含进行OCPP-S实现所需的实现规范。对于OCPP-J，必须使用。

For improved interoperabillity between the Central Systems and Charge Points, it is adviced to meet the requirements stated in theOCPP 1.6 Compliance testing documentation.

为了提高中央系统和充电点之间的互操作性，建议满足文件中规定的要求。

3.2. Feature Profiles

3.2. 功能配置文件

This section is informative.

本节内容丰富。

In OCPP 1.6 features and associated messages are grouped inprofiles. Depending on the required functionality, implementers can choose to implement one or more of the following profiles.

在OCPP 1.6中，功能和相关消息在配置文件中分组。根据所需的功能，实现者可以选择实现以下一个或多个配置文件。

These profiles can be used by a customer to determine if a OCPP 1.6 product has the required functionality for their business case. Compliance testing will test per profile if a product is compliant with the OCPP 1.6 specification.

客户可以使用这些配置文件来确定OCPP 1.6产品是否具有其业务案例所需的功能。如果产品符合OCPP 1.6规范，合规性测试将根据配置文件进行测试。

Implementation of the Core profile is required. Other profiles are optional.

需要实施核心配置文件。其他配置文件是可选的。

When the profilesCore,Firmware Management,Local Auth List ManagementandReservationare implemented, all functions originating from OCPP 1.5[OCPP1.5] are covered.

当实施配置文件核心、固件管理、本地授权列表管理和保留时，涵盖了源自OCPP 1.5[OCPP1.5]的所有功能。

The grouping of all messages in their profiles can be found in the table below.

下表列出了配置文件中所有消息的分组。

The support for the specific charging profiles is reported by theSupportedFeatureProfiles configuration key.

配置键报告了对特定充电配置文件的支持。

3.3. General views of operation

3.3. 运营概况

This section is informative.

本节内容丰富。

The following figures describe the general views of the operations between Charge Point and Central System for two cases:

下图描述了两种情况下充电桩和中央系统之间操作的一般视图：

1. a Charge Point requesting authentication of a card and sending charge transaction status,

1.收费点请求卡的认证并发送收费交易状态，

2. Central System requesting a Charge Point to update its firmware.

2.中央系统请求充电桩更新其固件。

The arrow labels in the following figures indicate the PDUs exchanged during the invocations of the operations. These PDUs are defined in detail in theMessages section.

下图中的箭头标签表示在操作调用期间交换的PDU。这些PDU在本Messages节中有详细定义。

Figure 1. Sequence Diagram: Example of starting and stopping a transaction

图1。序列图：启动和停止事务的示例

When a Charge Point needs to charge an electric vehicle, it needs to authenticate the user first before the charging can be started. If the user is authorized the Charge Point informs the Central System that it has started with charging.

当充电桩需要为电动汽车充电时，它需要先对用户进行身份验证，然后才能开始充电。如果用户获得授权，充电桩会通知中央系统它已开始充电。

When a user wishes to unplug the electric vehicle from the Charge Point, the Charge Point needs to verify that the user is either the one that initiated the charging or that the user is in the same group and thus allowed to terminate the charging. Once authorized, the Charge Point informs the Central System that the charging has been stopped.

当用户希望将电动汽车从充电桩拔下时，充电桩需要验证用户是发起充电的人，还是用户属于同一组，从而允许终止充电。一旦获得授权，充电桩会通知中央系统充电已停止。

NOTE

注：

A Charge Point MUST NOT send anAuthorize.req before stopping a transaction if the presented idTag is the same as the idTag presented to start the transaction.

如果提供的idTag与开始交易时提供的idTag相同，则充电桩在停止交易之前不得发送。

Figure 2. Sequence Diagram: Example of a firmware update

图2:序列图：固件更新示例

When a Charge Point needs to be updated with new firmware, the Central System informs the Charge Point of the time at which the Charge Point can start downloading the new firmware. The Charge Point SHALL notify the Central System after each step as it downloads and installs the new firmware.

当充电桩需要用新固件更新时，中央系统会通知充电桩可以开始下载新固件的时间。充电桩应在下载和安装新固件的每个步骤后通知中央系统。

3.4. Local Authorization & Offline Behavior

3.4. 本地授权和离线行为

This section is normative.

本节是规范性的。

In the event of unavailability of the communications or even of the Central System, the Charge Point is designed to operate stand-alone. In that situation, the Charge Point is said to beoffline.

如果通信甚至中央系统不可用，充电桩设计为独立运行。在这种情况下，充电桩被称为离线。

To improve the experience for users, a Charge Point MAY support local authorization of identifiers, using anAuthorization Cache and/or aLocal Authorization List.

为了改善用户体验，充电桩可以使用和/或支持标识符的本地授权Local Authorization List。

This allows (a) authorization of a user whenoffline, and (b) faster (apparent) authorization response time when communication between Charge Point and Central System is slow.

这允许（a）离线时对用户进行授权，以及（b）当充电桩和中央系统之间的通信缓慢时，更快（明显）的授权响应时间。

TheLocalAuthorizeOffline configuration key controls whether a Charge Point will authorize a user whenoffline using the Authorization Cache and/or the Local Authorization List.

配置键控制充电桩在离线时是否使用授权缓存和/或本地授权列表授权用户。

TheLocalPreAuthorize configuration key controls whether a Charge Point will use the Authorization Cache and/or the Local Authorization List to start a transaction without waiting for an authorization response from the Central System.

配置键控制充电桩是否将使用授权缓存和/或本地授权列表来启动交易，而无需等待来自中央系统的授权响应。

A Charge Point MAY support the (automatic) authorization of any presented identifier whenoffline, to avoid refusal of charging to bona-fide users that cannot be explicitly authorized by Local Authorization List/Authorization Cache entries. This functionality is explained in more detail inUnknown Offline Authorization.

充电桩可以在离线时支持对任何呈现的标识符进行（自动）授权，以避免拒绝向无法通过本地授权列表/授权缓存条目明确授权的善意用户收费。此功能在中Unknown Offline有更详细的解释Authorization。

3.4.1. Authorization Cache

3.4.1. 授权缓存

A Charge Point MAY implement an Authorization Cache that autonomously maintains a record of previously presented identifiers that have been successfully authorized by the Central System. (Successfully meaning: a response received on a message containing an idTag)

充电桩可以实现授权缓存，该缓存自主维护先前已被中央系统成功授权的标识符的记录。（成功意味着：在包含idTag的消息上收到的响应）

If implemented, the Authorization Cache SHOULD conform to the following semantics:

如果实现，授权缓存应符合以下语义：

• The Cache contains all the latest received identifiers (i.e. valid and NOT-valid).
  缓存包含所有最新接收到的标识符（即有效和无效）。

• The Cache is updated using all receivedIdTagInfo (fromAuthorize.conf, StartTransaction.conf andStopTransaction.conf)
  使用所有接收到IdTagInfo的（来自Authorize.conf,StartTransaction.conf和StopTransaction.conf）数据更新缓存

• When the validity of a Cache entry expires, it SHALL be changed to expired in the Cache.
  当缓存条目的有效期到期时，应在缓存中将其更改为已过期。

• When anIdTagInfo is received for an identifier in the Cache, it SHALL be updated.
  当收到缓存中某个IdTagInfo标识符的请求时，应进行更新。

• If new identifier authorization data is received and the Authorization Cache is full, the Charge Point SHALL remove any NOT-valid entries, and then, if necessary, the oldest valid entries to make
  如果收到新的标识符授权数据，并且授权缓存已满，充电桩应删除任何无效条目，然后在必要时删除最旧的有效条目

space for the new entry.

新条目的空间。

• Cache values SHOULD be stored in non-volatile memory, and SHOULD be persisted across reboots and power outages.
  缓存值应存储在非易失性存储器中，并应在重新启动和断电时保持不变。

• When an identifier is presented that is stored in the cache as NOT-valid, and the Charge Point isonline: anAuthorize.req SHOULD be sent to the central System to check the current state of the identifier.
  当缓存中存储的标识符显示为无效，且充电桩在线时：应向中央系统发送一个Authorize.req，以检查标识符的当前状态。

Operation of the Authorization Cache, when present, is reported (and controlled, where possible) by theAuthorizationCacheEnabled configuration key.

授权缓存的操作（如果存在）由配置密钥报告（并在可能的情况下进行控制）。

3.4.2. Local Authorization List

3.4.2. 本地授权列表

The Local Authorization List is a list of identifiers that can be synchronized with the Central System.

本地授权列表是可以与中央系统同步的标识符列表。

The list contains the authorization status of all (or a selection of) identifiers and the authorization status/expiration date.

该列表包含所有（或部分）标识符的授权状态和授权状态/到期日期。

Identifiers in the Local Authorization list can be marked asvalid,expired,(temporarily) blocked, orblacklisted, corresponding to IdTagInfo statusvaluesAccepted/ConcurrentTx,Expired,Blocked, andInvalid, respectively.

本地授权列表中的标识符可以标记为有效、过期、（暂时）被阻止或被列入黑名单，分别对应于IdTagInfo状态值Accepted/ConcurrentTx、expired、blocked和Invalid。

These values may be used to provide more fine grained information to users (e.g. by display message) during local authorization.

这些值可用于在本地授权期间向用户提供更细粒度的信息（例如通过显示消息）。

The Local Authorization List SHOULD be maintained by the Charge Point in non-volatile memory, and SHOULD be persisted across reboots and power outages.

本地授权列表应由充电桩在非易失性存储器中维护，并应在重启和断电时保持不变。

A Charge Point that supports Local Authorization List SHOULD implement the configuration key:LocalAuthListMaxLength This gives the Central System a way to known the the maximum possible

支持本地授权列表的充电桩应实现配置密钥：LocalAuthListMaxLength这为中央系统提供了一种了解最大可能配置密钥的方法

number of Local Authorization List elements in a Charge Point

充电桩中本地授权列表元素的数量

The Charge Point indicates whether the Local Authorization List is supported by the presence or absence of theLocalAuthListManagementelement in the value of the SupportedFeatureProfiles configuration key. Whether the Local Authorization List is enabled is reported and controlled by theLocalAuthListEnabled configuration key.

充电桩指示配置密钥的值中是否存在LocalAuthListManagement元素来支持本地授权列表。本地授权列表是否启用由配置密钥报告和控制。

The Central System can synchronize this list by either (1) sending a complete list of identifiers to replace the Local Authorization List or (2) by sending a list of changes (add, update, delete) to apply to the Local Authorization List. The operations to support this areGet Local List Version andSend Local List.

中央系统可以通过以下方式同步此列表：（1）发送完整的标识符列表以替换本地授权列表，或（2）发送更改列表（添加、更新、删除）以应用于本地授权列表。支持这一点的行动是Get Local List Version和Send LocalList。

Figure 4. Sequence Diagram: Example of a differential local authorization list update

图4。序列图：差异本地授权列表更新示例

The Charge Point SHALL NOT modify the contents of the Authorization List by any other means than upon a the receipt of a SendLocalList PDU from the Central System.

充电桩不得通过任何其他方式修改授权列表的内容，除非从中央系统收到SendLocalList PDU。

Conflicts between the local authorization list and the validity reported in, for instance, aStartTransaction.conf message might occur. When this happens the Charge Point SHALL inform the Central System by sending aStatusNotification with ConnectorId set to 0, and ErrorCode set to 'LocalListConflict'.

3.4.3. Relation between Authorization Cache and Local Authorization List

3.4.3. 授权缓存与本地授权列表的关系

The Authorization Cache and Local Authorization List are distinct logical data structures. Identifiers known in the Local Authorization List SHALL NOT be added to the Authorization Cache.

授权缓存和本地授权列表是不同的逻辑数据结构。本地授权列表中已知的标识符不得添加到授权缓存中。

Where both Authorization Cache and Local Authorization List are supported, a Charge Point SHALL treat Local Authorization List entries as having priority over Authorization Cache entries for the same identifiers.

如果同时支持授权缓存和本地授权列表，充电桩应将本地授权列表条目视为对相同标识符具有比授权缓存条目更高的优先级。

3.4.4. Unknown Offline Authorization

3.4.4. 未知离线授权

Whenoffline, a Charge Point MAY allow automatic authorization of any "unknown" identifiers that cannot be explicitly authorized by Local Authorization List or Authorization Cache entries. Identifiers that are present in a Local Authorization List that have a status other than “Accepted” (Invalid, Blocked, Expired) MUST be rejected. Identifiers that were valid but are apparently expired due to passage of time MUST also be rejected.

离线时，充电桩可能允许自动授权任何无法通过本地授权列表或授权缓存条目明确授权的“未知”标识符。必须拒绝本地授权列表中状态不是“已接受”（无效、已阻止、已过期）的标识符。有效但因时间推移而明显过期的标识符也必须被拒绝。

Operation of the Unknown Offline Authorization capability, when supported, is reported (and controlled, where possible) by theAllowOfflineTxForUnknownId configuration key.

在支持的情况下，未知脱机授权功能的操作由配置密钥报告（并在可能的情况下进行控制）。

When connection the the Central Server is restored, the Charge Point SHALL send aStart Transaction request for any transaction that was authorizedoffline, as required bytransaction-related message handling. When the authorization status in theStartTransaction.conf is not Accepted, and the transaction is still ongoing, the Charge Point SHOULD:

当中央服务器的连接恢复时，充电桩应按照要求发送离线授权的任何交易请求handling。当中的StartTransaction.conf授权状态为未接受，且交易仍在进行时，充电桩应：

• when StopTransactionOnInvalidId is set to true: stop the transaction normally as stated inStop Transaction. TheReason field in theStop Transaction request should be set toDeAuthorized. If the Charge Point has the possibility to lock the Charging Cable, it SHOULD keep the Charging Cable locked until the owner presents his identifier.
  何时StopTransactionOnInvalidId设置为true：按照中Stop所述正常停止交易Transaction。请求中的字段应设置为DeAuthorized。如果充电桩有可能锁定充电电缆，则应保持充电电缆锁定，直到所有者出示其标识符。

• when StopTransactionOnInvalidId is set tofalse: only stop energy delivery to the vehicle.
  何时StopTransactionOnInvalidId设置为false：仅停止向车辆输送能量。

In the case of an invalid identifier, an operator MAY choose to charge the EV with a minimum amount of energy so the EV is able to drive away. This amount is controlled by the optional configuration key:MaxEnergyOnInvalidId.

在标识符无效的情况下，操作员可以选择用最少的能量给电动汽车充电，这样电动汽车就可以开走了。此金额由可选配置键控制：MaxEnergyOnInvalidId。

3.5. Transaction in relation to Energy Transfer Period

3.5. 与能量转移期有关的交易

This section is informative.

本节内容丰富。

The Energy Transfer Period is a period of time during wich energy is transferred between the EV and the EVSE. There MAY be multiple Energy Transfer Periods during aTransaction.

这Energy Transfer Period是电动汽车和电动汽车供电设备之间传递能量的一段时间。在一个过程中可能有多个能量转移期Transaction。

Multiple Energy Transfer Periods can be separated by either:

多个能量转移期可以通过以下方式分隔：

• an EVSE-initiated supense of transfer during which de EVSE does not offer energy transfer
  电动汽车供电设备启动了传输限制，在此期间电动汽车供电系统不提供能量传输

• an EV-initiated suspense of transfer during which the EV remains electrically connected to the EVSE
  电动汽车启动的转移暂停，在此期间电动汽车保持与电动汽车供电设备的电气连接

• an EV-initiated suspense of transfer during which the EV is not electrically connected to the EVSE.
  电动汽车启动的转移暂停，在此期间电动汽车未与电动汽车供电设备电连接。

A Central System MAY deduce the start and end of an Energy Transfer Period from the MeterValues that are sent during the Transaction.

中央系统可以从交易期间发送的MeterValues中推断出能量传输期的开始和结束。

内容较多，完整版本私信我。