OCPP1.6 v2 之 ocpp-1.6-errata-sheet （中文翻译）

OCPP 1.6勘误表

版本 4.0，发布日期：2019-10-23

勘误表：适用于OCPP版本 1.6 第2版及1.6最终版

版权所有 © 2010 – 2019 Open Charge Alliance。保留所有权利。

本文档遵循《创作共享版权协议-禁止演绎4.0 国际版》（Creative Commons Attribution-NoDerivatives 4.0International Public License），可通过以下网址查看法律条款：CC BY-ND 4.0 Legal Code | Attribution-NoDerivs 4.0 International | Creative Commons。

版本变更历史

版本	日期	作者	描述
v4.0 Release	2019-10-23	Robert de Leeuw (ihomer) Franc Buve (ElaadNL)	勘误表的第4次发布 新版本勘误标记为v4.0。
v3.0 Release	2017-09-08	Robert de Leeuw (IHomer)	勘误表的第3次发布 新版本勘误标记为v3.0。
v2.0 Release	2017-03-27	Robert de Leeuw (IHomer) Klaas van Zuuren (ELaadNL) Brendan McMahon (ESB)	勘误表的第2次发布 勘误已重新排序以匹配1.6规范的发布时间顺序。
v1.0 Release	2016-03-31	Robert de Leeuw (IHomer) Klaas van Zuuren (ELaadNL)	首次发布

1. 范围 本文档包含OCPP 1.6规范的勘误。自本勘误表v3.0版之后添加的任何勘误均针对OCPP 1.6第2版，并且也适用于OCPP 1.6最终版（即第一版），除非另有说明。

1.1 术语和约定加粗：在需要澄清差异时，可能会使用加粗文本。自文档版本v3.0起，勘误会标记版本号，以表明勘误的添加时间。

1. 主要勘误 协议的消息、类和枚举的内容/定义中存在的问题。 目前已知无此类问题
2. 次要勘误 对协议（应）如何工作的描述所做的改进。

3.1 第7页，章节：2.2：智能充电可能考虑的因素不仅仅限于IEC 15118“组合充电计划”的定义中提到“可能会考虑IEC 15118的限制”，但也可能考虑其他限制。

旧文本	此外，也可能会考虑IEC 15118的限制。
新文本	本地限制可能也会被考虑。

3.2 第10页，章节：3.2：特性配置文件应为规范性

在勘误表v4.0中增加：在第二版中，特性配置文件的消息表格列被混淆了。

旧文本	新文本
REMOTE TRIGGER	RESERVATION
RESERVATION	SMART CHARGING
SMART CHARGING	REMOTE TRIGGER

3.3 第10页，章节：3.2：特性配置文件应为规范性

特性配置文件段落提到它是“信息性的”，但实际上它是“规范性的”。

旧文本	这一节是信息性的。
新文本	这一节是规范性的。

3.4 第13页，章节：3.5.1：缺少要求，缓存持久化重置

在勘误表v4.0中添加

OCPP 1.6最终版 第16页，章节3.4.1

在3.4.1节中有关于缓存持久化的要求，但没有提到“重置”

旧文本	缓存值应该存储在非易失性存储器中，并且应该在重新启动和断电后保持持久性。
新文本	缓存值应该存储在非易失性存储器中，并且在重新启动、重置和断电后应该保持持久性。

3.5 第15页，章节：3.5.4：在StartTransaction.conf中收到无效ID后解锁充电线，应使用相同的标识符。

在勘误表v4.0中添加

OCPP 1.6最终版 第18页，章节3.4.4

解释充电点在收到StartTransaction.conf时应如何操作的文本并未完全明确，应使用相同的标识符，而不是同一所有者的标识符。

旧文本	它应该保持充电线锁定，直到车主出示其标识符。
新文本	它应该保持充电线锁定，直到使用相同的标识符（或具有相同ParentIdTag的标识符）来启动交易（StartTransaction.req）才被出示。

3.6 第18页，章节3.5：如何确定能量传输期开始/结束的更好描述

在勘误表v3.0中添加

关于中央系统如何确定能量传输期开始/结束的描述可以改进。

旧文本	中央系统可以通过在交易期间发送的MeterValues推断出能量传输期的开始和结束。
新文本	中央系统可以通过以下方式推断能量传输期的开始和结束：在交易期间发送的MeterValues、状态通知（如：Charging、SuspendedEV和/或SuspendedEVSE等）。中央系统的实现需要考虑以下因素：一些电动车不会进入SuspendedEV状态，它们可能会继续涓流充电。一些充电点甚至没有电能表。

3.7 第18页，章节3.12.2：添加无持续时间的叠加描述

在勘误表v3.0中添加

当使用叠加进行智能充电时：一个高叠加级别但没有持续时间将导致较低的配置文件永远不会被执行。

在3.12.2节末尾添加注释。

新文本	注意：如果在没有持续时间的情况下使用叠加，在最高叠加级别上，充电点将永远不会回落到较低的叠加级别配置文件。

3.8 第20页，章节3.13.1：在交易期间更新或删除TxDefaultProfile的效果未定义

在勘误表v4.0中添加

没有明确说明新的TxDefaultProfile不仅适用于具有TxDefaultProfile的正在运行的交易，还适用于没有ChargingProfile的正在运行的交易。此外，删除TxDefaultProfile将导致正在运行的交易在没有TxDefaultProfile的情况下继续。

为了最好地澄清这一点，需要添加两个额外的段落。

页	章节	附加文本
20	3.13.1	当接收到新的或更新的TxDefaultProfile时，如果有一个正在进行的交易没有使用ChargingProfile或使用当前的TxDefaultProfile，则该交易将继续进行，但将切换到使用新的或更新的TxDefaultProfile。如果移除了TxDefaultProfile，那么使用该配置文件开始的正在运行的交易将继续进行，但不使用TxDefaultProfile。
54	5.16.3	当正在进行的交易没有使用ChargingProfile或正在使用TxDefaultProfile，并且接收到新的或更新的TxDefaultProfile时，该交易将继续进行，但将切换到使用新的或更新的TxDefaultProfile。

3.9 第29页，章节：3.1.6：缺少建议，如果可用则发送电表寄存器值

在勘误表v4.0中添加

如果充电点有一个允许读取电表寄存器（计数器）值的电表，那么最好发送这个值，而不是每次交易都从0开始。

附加文本	如果一个充电点包含一个电表，其拥有一个可读取的寄存器（而不是通过计数脉冲或其他方式测量能量等），则建议在每次发送MeterValue时发送该寄存器值，而不是每次交易都从0开始。

3.10. 第33页，关于时间表示法的新章节

除了“3.13 时区”之外，还应该添加以下内容关于时间表示法：

新文本	3.14 时间表示法 实现必须使用ISO 8601日期时间表示法。消息接收者必须能够处理小数秒和时区偏移（其他实现可能会使用它们）。消息发送者可以通过省略不重要的秒的小数部分来节省数据使用。

3.11. 第35页，章节：4.2：启动通知：关于未被中央系统接受时的行为说明

旧文本	在被中央系统接受之前，如果充电点配置为允许这样做，它可以根据“本地授权与离线行为”章节中的描述允许本地授权的交易。想要实现此行为的各方必须意识到，这些交易是否能够传递给中央系统是不确定的。
新文本	充电点运营商可以选择配置充电点，以便在充电点被中央系统接受之前接受交易。想要选择实现此行为的各方应该意识到，这些交易是否能够传递给中央系统是不确定的。 在重启后（例如由于远程重置命令、断电、固件更新、软件错误等原因），充电点必须再次与中央系统联系，并应发送BootNotification请求。如果充电点未能从中央系统接收到BootNotification.conf，并且没有内置的非易失性实时时钟硬件且该硬件已正确预设，那么充电点可能没有有效的日期/时间设置，使得以后无法确定交易的日期/时间。 还可能出现的情况是（例如由于配置错误），中央系统在很长一段时间内或无限期地指示除“已接受”之外的其他状态。 如果充电点以前从未被中央系统（使用当前的连接设置、URL等）接受过，那么通常建议拒绝充电点上的所有充电服务，因为用户无法进行身份验证，并且正在进行的交易可能与配置过程发生冲突。

3.12. 第37页，章节：4.5：缺少FirmwareStatusNotification.req和FirmwareUpdate.req之间的关系描述

在规范中，没有关于FirmwareUpdate.req和FirmwareStatusNotification.req之间关系的描述。

附加文本	FirmwareStatusNotification.req PDU（协议数据单元）应当被发送，以便使中央系统了解由中央系统通过FirmwareUpdate.req PDU启动的更新过程的状态。

3.13. 第38页，章节：4.7：缺少MeterValues配置键的描述

有几个必需的配置键对MeterValues的工作方式有重大影响，但在4.7 Meter Values（电表值）中并没有关于它们的引用或描述：

• ClockAlignedDataInterval

• MeterValuesAlignedData

• MeterValuesAlignedDataMaxLength

• MeterValuesSampledData

• MeterValuesSampledDataMaxLength

• MeterValueSampleInterval

• StopTxnAlignedData

• StopTxnAlignedDataMaxLength

• StopTxnSampledData

• StopTxnSampledDataMaxLength

需要在规范中添加新章节：

3.14: 计量数据

本节是规范性的。

根据预期用途，与充电会话相关的广泛计量数据可以以不同的方式记录和传输。有两个明显的用例（但计量值的使用不仅限于这两个）：

• 充电会话计量值

• 时钟对齐计量值

这两种类型的计量读数都可以在独立的MeterValues.req消息中（在交易期间）以及/或者作为StopTransaction.req PDU的transactionData元素的一部分进行报告。

3.14.1 充电会话计量值

频繁（例如，每1-5分钟）测量的计量读数并实时传输到中央系统，以允许其通过网页、应用程序、短信等方式向电动汽车用户（通常不在充电点）提供充电会话进度的信息更新。在OCPP（开放充电点协议）中，这被称为“采样计量数据”，因为只要“足够频繁”，读数的确切频率和时间并不是非常重要。“采样计量数据”可以通过以下配置键进行配置：

• MeterValuesSampledData

• MeterValuesSampledDataMaxLength

• MeterValueSampleInterval

• StopTxnSampledData

• StopTxnSampledDataMaxLength

MeterValueSampleInterval 是两次采样计量（或其他）数据之间的时间（以秒为单位），这些数据意图通过“MeterValues”PDU进行传输。从充电交易开始起，以这个间隔周期性地获取和传输样本。

按惯例，“0”（数字零）的值表示不应传输任何采样数据。

MeterValuesSampledData 是一个逗号分隔的列表，它规定了每MeterValueSampleInterval秒应包含在MeterValues.reqPDU中的一组测量值。充电点可以通过MeterValuesSampledDataMaxLength报告MeterValuesSampledData列表中的最大元素数量。

StopTxnSampledData 是一个逗号分隔的列表，它规定了从充电会话开始起每MeterValueSampleInterval秒应包含在StopTransaction.reqPDU的TransactionData元素中的采样测量值。充电点可以通过StopTxnSampledDataMaxLength报告StopTxnSampledData列表中的最大元素数量。

3.14.2 时钟对齐计量值

电网运营商可能要求从财政认证的能源计量表获取计量读数，并在特定的时钟对齐时间（通常是每十五分钟或半小时）进行。

“时钟对齐计费数据”可以通过以下配置键进行配置：

• ClockAlignedDataInterval

• MeterValuesAlignedData

• MeterValuesAlignedDataMaxLength

• StopTxnAlignedData

• StopTxnAlignedDataMaxLength

ClockAlignedDataInterval 是时钟对齐数据间隔的大小（以秒为单位）。这定义了从00:00:00（午夜）开始，每天的一组等距分布的计量数据聚合间隔。

例如，值为900（15分钟）表示每天应被分割为96个15分钟间隔。按惯例，值“0”（数字零）表示不应传输任何时钟对齐数据。

MeterValuesAlignedData 是一个逗号分隔的列表，它规定了每ClockAlignedDataInterval秒应包含在MeterValues.reqPDU中的一组测量值。MeterValuesAlignedData列表中的最大元素数量可以通过Charge Point报告的MeterValuesAlignedDataMaxLength获得。

StopTxnAlignedData 是一个逗号分隔的列表，它规定了充电会话的每个ClockAlignedDataInterval应包含在StopTransaction.reqPDU的TransactionData元素中的一组时钟对齐周期性测量值。StopTxnAlignedData列表中的最大元素数量可以通过Charge Point报告的StopTxnAlignedDataMaxLength获得。

3.14.3 多个位置/相位

当充电点能够在多个位置或相位上测量相同的测量值时，如果通过相关配置键进行了配置，则应报告所有可能的位置和/或相位。

例如：一个充电点能够测量入口（所有3个相位）（电网连接）和出口（其两个连接器上每个连接器3个相位）的Current.Import（电流输入）。Current.Import 设置在 MeterValuesSampledData 中。MeterValueSampleInterval 设置为 300（秒）。然后，充电点应发送：

• 一个 MeterValue.req 消息，其中：connectorId = 0；包含3个SampledValue 元素，每个相位一个，位置 = Inlet（入口）。

• 一个 MeterValue.req 消息，其中：connectorId = 1；包含3个SampledValue 元素，每个相位一个，位置 = Outlet（出口）。

•（注意：这里的 "connectorId = 2" 可能是一个错误或误解，因为通常一个充电点不会有 "connectorId = 2" 除非它确实有第三个连接器。但在此示例中，我们假设充电点只有两个连接器。）

（如果确实存在第三个连接器，并且它也有三个相位用于测量Current.Import，则还应发送另一个 MeterValue.req 消息，其中 connectorId = 2，并包含相应的 SampledValue 元素。）

3.14.4 不支持的测量值

当中央系统向充电点发送一个包含以下配置键之一的ChangeConfiguration.req 请求时：

• MeterValuesAlignedData

• MeterValuesSampledData

• StopTxnAlignedData

• StopTxnSampledData

如果逗号分隔的列表中包含一个或多个该充电点不支持的测量值，充电点应响应：ChangeConfiguration.conf，其中 status = Rejected（拒绝）。当前配置不应进行任何更改。

（注：此内容在勘误表 v3.0 中添加）

3.14.5 停止交易中无计量数据

当配置键 StopTxnAlignedData 和 StopTxnSampledData 被设置为空字符串时，充电点不应在StopTransaction.req PDU 中包含计量值。

3.14. 页码31，章节：3.16.5：缺少 StopTransaction.req 中开始和停止计量值的描述

在勘误表 v4.0 中添加

应在 3.16 部分中添加额外章节：

3.16.6 StopTransaction.req 中的开始和停止计量值

当充电点配置为在 StopTransaction.req 中提供计量数据时，建议充电点始终提供每个已配置测量值的开始（Transaction.Begin）和停止（Transaction.End）值。

如果充电点因为内存不足而不得不丢弃计量值，建议不丢弃开始和停止值。

3.15. 页码36，章节：4.7：更明确地指出如果已配置则需要提供 MeterValues

在勘误表 v4.0 中添加

第4.7节的第一段写道：

“充电点可以采样电表或其他传感器/转换器硬件以提供有关其计量值的额外信息。充电点可以自行决定何时发送计量值。这可以通过使用ChangeConfiguration.req 消息来配置数据采集间隔，并指定要获取和报告的数据。”

这段文字中的“可以”（MAY）一词暗示发送 MeterValues 是可选的。但是，当配置变量MeterValueSampleInterval 的值被设置为大于零时，发送 MeterValues 就是强制性的。

附加文本 在第一节之后：

当配置变量 MeterValueSampleInterval 和/或 ClockAlignedDataInterval 的值被设置为大于零时，充电点应在给定的间隔内发送 MeterValues。

3.16. 页码36，章节：4.7：在 MeterValue 中使用哪个事务 ID 不够明确（间隔期间存在多个事务）

在勘误表 v4.0 中添加

OCPP 1.6 最终版 页码 38

在时钟对齐的计量值样本的 MeterValue.req 消息中，对于在样本之间的最后一个时间段内前一个事务已经结束并且新事务已经开始的情况，使用哪个 transactionId 并不够明确。

附加文本 第2点

事务ID总是指采样计量值时正在该连接器上进行的事务的ID。当设置了事务ID时，只能报告与该事务相关的计量值。如果值是从主能量表获取的，建议不要添加事务ID。 对于报告连接器ID为0（主能量表）的计量值时，建议不要添加事务ID。

3.17. 页码37，章节：4.8：不清楚如何处理：StartTransaction.conf 中 idTagInfo 未被接受的情况。

在勘误表 v4.0 中添加

OCPP 1.6 最终版 页码 40

当充电点在线时，收到授权状态非“已接受”的 StartTransaction.conf时，没有（明确地）规定充电点应该如何操作。

虽然已经有一段文字描述了充电点应该怎么做，但这段文字现在位于解释充电点离线时应如何操作的部分。但由于它位于那个部分，所以不清楚当充电点在线时，它是否也应该以同样的方式处理相同的情况。

以下文本应从：页码15，章节：3.5.4（OCPP 1.6 最终版 页码18，章节3.4.4）移动到：页码37，章节4.8（OCPP 1.6 最终版页码40）

当 StartTransaction.conf 中的授权状态不是“已接受”，并且事务仍在进行时，充电点应该：

• 如果 StopTransactionOnInvalidId 设置为 true：则按照 Stop Transaction 中所述的方式正常停止事务。Stop Transaction 请求中的 Reason 字段应设置为 DeAuthorized（已取消授权）。如果充电点具有锁定充电电缆的能力，它应该保持充电电缆锁定状态，直到车主出示其标识符。

• 如果 StopTransactionOnInvalidId 设置为 false：则仅停止向车辆输送能源。

注意：在标识符无效的情况下，运营商可以选择向电动汽车收取最低额度的能源费用，以确保电动汽车能够驶离。这个最低额度的控制由可选的配置键 MaxEnergyOnInvalidId 来设定。

3.18. 页码37，章节：4.8：当不知道 transactionId 时，如何发送与事务相关的消息。

在勘误表 v4.0 中添加

该章节末尾提到，如果没有响应 StartTransaction.conf，则充电点会尝试重试多次。但是，当发生这种情况时，没有说明如何处理不知道 transactionId 的与事务相关的消息。

在 4.8 章节末尾添加以下文本：

附加文本	如果充电点尽管多次尝试仍无法发送 StartTransaction.req，或者如果中央系统无法发送 StartTransaction.conf 响应，那么充电点将不会收到 transactionId。 在这种情况下，充电点应该向中央系统发送与该事务相关的任何消息，并在其中使用 transactionId = -1。中央系统应该像这些消息引用了一个有效的 transactionId 那样进行响应，以便充电点不会被此阻塞。

3.19. 页码38，章节：4.9：未规定 StatusNotification 必须始终发送。

在勘误表 v4.0 中添加

OCPP 1.6 最终版 页码 40

第38页的规定写道：“下表描述了从一个先前状态（左列）到一个新状态（上排）的更改，在这些更改上，充电点可以向中央系统发送 StatusNotification.req PDU。”

但一直以来，当状态发生更改时，充电点必须发送 StatusNotification。

旧文本	充电点可以向中央系统发送 StatusNotification.req PDU。
新文本	考虑到一些最小状态持续时间，充电点必须向中央系统发送 StatusNotification.req PDU。

3.20. 页码41，章节：4.9：从“准备”状态到“完成”状态（B6）的转换是可能的

在勘误表 v3.0 中添加

原始的1.6版本不允许从“准备”状态直接转换到“完成”状态（B6）。但有一个使用场景是可能的：

一个拥有2个连接器和1个RFID阅读器的充电点。司机1连接了他的充电电缆，状态变为“准备”。用户未进行授权，导致超时。然后充电点必须进入“完成”状态。它不应该进入“可用”状态。因为如果充电电缆仍然插着，并且另一个电动汽车司机在插入电缆之前用他的RFID卡进行了刷卡，那么这将会在已经插上的电缆上开始一个事务。通过进入“完成”状态可以防止这种情况发生。

表格顶部，页码41	增加B6
表格顶部，页码42	B6: 超时。已经启动了使用（例如插入插头，车位占用检测），但在超时时间内未呈现 idTag（身份标签）。

3.21. 页码42，章节：4.9（B1）：缺少对配置键"ConnectionTimeOut" 的引用

该规范中从未引用配置键 "ConnectionTimeOut"，4.9 章节需要添加一个说明，解释状态 "Preparing" 和配置键 "ConnectionTimeOut" 如何协同工作。

旧文本	预期的使用已经结束（例如，插头已拔出，车位不再被占用，第二次呈现 idTag，预期的用户操作超时）
新文本	预期的使用已经结束（例如，插头已拔出，车位不再被占用，第二次呈现 idTag，预期的用户操作超时（由配置键 ConnectionTimeOut 配置））

3.22. 页码43，章节：4.9：未规定在 BootNotification 被接受后应始终发送 StatusNotification。

在勘误表 v4.0 中添加

OCPP 1.6 最终版 页码 45

规范中没有描述每个已知的 OCPP 实现所期望和实现的行为：在通过 BootNotification.conf(Accepted) 被接受后，充电点必须报告其当前状态。

附加文本	当中央系统通过发送带有状态“Accepted”的 BootNotification.conf 接受一个充电点后，充电点必须为连接器ID 0以及所有具有当前状态的连接器发送 StatusNotification.req PDU。

3.23. 页码46，章节：5.4。当未实现缓存时清除缓存未定义。

在勘误表 v4.0 中添加

OCPP 1.6 最终版 页码 49

在 OCPP 1.6 中，缓存不是必需的，但消息：ClearCache.req 是要求实现的。OCPP 没有定义预期的行为是什么。

附加文本	当授权缓存未实现且充电点收到 ClearCache.req 消息时，充电点应以状态 "Rejected" 回应 ClearCache.conf 消息。

3.24. 页码46，章节5.8：在 GetCompositeSchedule 中缺少对 chargingRateUnit 的要求

在勘误表 v4.0 中添加

必须在此章节末尾添加以下注释：

🔔

如果在 GetCompositeSchedule.req 中对 chargingRateUnit 使用了无效值，例如，当chargingRateUnit 的值不是 'A' 或 'W'时，充电点应以 RPC 框架的 CALLERROR:PropertyConstraintViolation（JSON）或 SOAP Fault: Sender, ProtocolError（SOAP）进行响应。

3.25. 页码47，章节5.5：如何匹配 ClearChargingProfile 请求中的字段不明确

在勘误表 v4.0 中添加

必须在此章节末尾添加以下注释：

🔔

如果在 ClearChargingProfile.req 消息中没有指定任何字段，则充电点应清除所有充电配置文件（ChargingProfiles）。如果在ClearChargingProfile.req 消息中指定了一个或多个字段，则充电点应清除与提供的所有字段都匹配（逻辑与）的所有充电配置文件。

3.26. 页码63，章节6.13：如何匹配 ClearChargingProfile 请求中的字段不明确

在勘误表 v4.0 中添加

在描述 ClearChargingProfile.req 的内容中，以下句子必须用新文本替换：

旧文本	中央系统可以使用此消息来清除（移除）特定的充电配置文件（由id表示）或者匹配可选的connectorId、stackLevel和chargingProfilePurpose字段值的充电配置文件的选择集。
新文本	中央系统可以使用此消息来清除（删除）特定的充电配置文件（由id指定）或选择与可选的connectorId、stackLevel和chargingProfilePurpose字段值相匹配（逻辑与）的充电配置文件。 如果没有提供任何字段，则将清除所有充电配置文件。 如果指定了id，则忽略所有其他字段。

3.27. 页码50，章节：5.7：智能充电可能会考虑除了IEC 15118之外的其他标准。

文中提到“可能会考虑IEC 15118的限制”，但也可能考虑其他限制。

旧文本	同样地，也可能会考虑IEC 15118的限制。
新文本	本地限制可能会被考虑。

3.28. 页码51，章节：5.7：获取组合计划：第一句描述不清晰

在“获取组合计划”的描述中，计划将要发送的起始和结束时间点并不清晰。

旧文本	在接收到 GetCompositeSchedule.req 请求后，充电点应当计算达到 Duration 指定的时间间隔，并将它们发送到中央系统。
新文本	在接收到 GetCompositeSchedule.req 请求后，充电点应当从接收到请求PDU的时刻（时间X）开始，计算组合充电计划的时间间隔，直到X + Duration，并将它们包含在 GetCompositeSchedule.conf PDU 中发送给中央系统。

3.29. 页码51，章节：5.7：获取组合计划：第一句描述不清晰

在勘误表 v4.0 中添加

关于“获取组合计划”的描述可以更加明确一些。

旧文本	在接收到 GetCompositeSchedule.req 请求后，充电点应从接收到请求PDU的时刻（时间X）开始，计算组合充电计划的时间间隔，直到X + Duration，并将这些时间间隔包含在 GetCompositeSchedule.conf PDU 中发送给中央系统。
新文本	在接收到 GetCompositeSchedule.req 请求后，充电点应计算从消息接收时刻开始到 Duration（以秒为单位）的预定时间间隔，并将它们发送给中央系统。

3.30. 页码51，章节：5.7：改进在 GetCompositeSchedule 中使用 connectorId '0'

在描述 GetCompositeSchedule 中使用 connectorId '0' 时，没有明确说明它也可以表示充电点报告的是电流而不是功率。

旧文本	如果请求中的 ConnectorId 设置为 '0'，则充电点应报告在请求的时间段内充电点的总预期能量流。
新文本	如果请求中的 ConnectorId 设置为 '0'，则充电点应报告在请求的时间段内，充电点预期从电网中消耗的总预期功率或电流。

3.31. 第51页，部分：5.9：缺少GetDiagnostics.req和DiagnosticsStatusNotification.req之间的关系描述。

在规范中没有关于GetDiagnostics.req和DiagnosticsStatusNotification.req之间关系的描述。

以下图表应该替换5.9中的图表。

图1. 序列图：获取诊断信息

附加文本	在上传诊断文件期间，充电点必须发送DiagnosticsStatusNotification.req PDU以向中央系统更新上传过程的状态。

3.32. 第52页，部分：5.11. 远程启动事务：.conf状态为已接受的请求

旧文本	中央系统可以通过发送RemoteStartTransaction.req请求充电点开始一个事务。在收到请求后，充电点应当回复RemoteStartTransaction.conf，并通过状态指示它是否能够开始一个事务。
新文本	中央系统可以通过发送RemoteStartTransaction.req请求充电点开始一个事务。在收到请求后，充电点应当回复RemoteStartTransaction.conf以及一个状态，表明它是否已接受请求并将尝试开始一个事务。

3.33. 第54页，部分：5.12. 远程停止事务：.conf状态为已接受的请求

旧文本	向充电点发送RemoteStopTransaction.req请求，其中包含事务的标识符。充电点应当回复RemoteStopTransaction.conf以指示它是否确实能够停止该事务。
新文本	向充电点发送带有事务标识符的RemoteStopTransaction.req请求。充电点应当回复RemoteStopTransaction.conf以及一个状态，表明它是否已接受请求，并且具有给定transactionId的事务正在进行中并将被停止。

3.34. 第54页，部分：5.16. 未定义充电点应如何处理包含比实际使用更多的相位的充电配置文件。

（此问题已在勘误表v4.0中添加）

附加文本	当充电点收到一个“numberPhases”（相位数量）高于当前使用的相位数量或该充电点可以使用的最大相位数量的充电配置文件时，充电点应当使用给定的“limit”（限制值），用于正在使用或可用于充电的相位数量。充电点不应当基于“numberPhases”字段中给出的可能相位数量来计算新的“limit”。

3.35. 第55页，部分：5.17. 被接受后的触发消息（BootNotification）可能会被拒绝

（此问题已在勘误表v4.0中添加）

在OCPP 1.6中未定义以下场景：“当充电点被中央系统接受，并且中央系统发送一个触发消息来请求BootNotification时。充电点将接受这个触发消息并向中央系统发送BootNotification.req。当中央系统以Pending（挂起）或Rejected（拒绝）状态响应时，充电点应该如何行为？”

由于这可能会导致许多令人困惑的情况，例如如何处理正在进行的事务等，因此允许拒绝这样的TriggerMessage.req。

附加文本	在充电点收到BootNotification.conf（已接受）之后，直到下一次重置/重启/重新连接之前，建议充电点拒绝用于BootNotification的TriggerMessage请求。

3.36. 第56页，部分：5.14：改进了软/硬重置的描述

（此改进已在勘误表v3.0中添加）

软/硬重置的描述可以改进，两者之间的区别不是很清楚。

附加文本， 在段落1和段落2之间

在收到Reset.req请求后，充电点应当在进行重置之前，对任何正在进行的事务发送StopTransaction.req请求。如果充电点未能从中央系统接收到StopTransaction.conf响应，它应当排队等待StopTransaction.req请求。

旧文本	在接收到软重置后，充电点应当回到刚开机时的状态。如果有任何事务正在进行，它应当在重置之前正常终止这些事务，就像执行停止事务操作一样。
新文本	在接收到软重置请求后，充电点应当优雅地停止所有正在进行的事务，并为每个正在进行的事务发送StopTransaction.req请求。之后，它应该重启应用软件（如果可能的话，否则重启处理器/控制器）。

旧文本	在接收到硬重置时，充电点应当尝试正常终止任何正在进行的事务（如同执行StopTransaction一样），然后执行重启。
新文本	在接收到硬重置请求时，充电点应当重启（所有）硬件，不要求优雅地停止正在进行的事务。如果可能的话，充电点在重启并通过BootNotification.conf被中央系统接受后，会为之前正在进行的事务发送StopTransaction.req请求。这是一种对于未能正常工作的充电点的最后解决方案，通过发送“硬”重置，（排队的）信息可能会丢失。

3.37. 第53页，部分：5.16：不明确的充电配置文件应在重启后持续存在

（此问题已在勘误表v4.0中添加）

没有文本解释期望充电点将充电配置文件存储在持久性存储器中。

附加文本	通过SetChargingProfile.req设置的充电配置文件应当在重启/电源循环后保持持久性。

3.38. 第55页，部分5.16：关于ChargingSchedule的ChargingRateUnit的要求缺失

（此问题已在勘误表v4.0中添加）

必须在本节末尾添加以下注释：

⚠

如果在ChargingProfile或ChargingSchedule的枚举中使用无效的值，例如，当使用chargingRateUnit的值不是'A'或'W'时，充电点应当使用RPC框架的CALLERROR:PropertyConstraintViolation（JSON）或SOAP Fault: Sender, ProtocolError（SOAP）来响应。

3.39. 第55页，部分：5.16：SetChargingProfile请求可能会被拒绝

（此问题已在勘误表v4.0中添加）

必须在本节末尾添加以下注释：

⚠

如果在SetChargingProfile.req请求中使用了无效的connectorId值，那么充电点应当使用RPC框架的CALLERROR: PropertyConstraintViolation（JSON）或SOAP Fault: Sender, ProtocolError（SOAP）来响应。

⚠

如果充电点不支持智能充电，那么它应当使用RPC框架的CALLERROR: NotSupported（JSON）或SOAP Fault: Receiver, NotSupported（SOAP）来响应。

3.40. 第56页，部分：5.18：在BootNotificationResponse(Accepted)之后不允许TriggerMessage(BootNotification)

（此问题已在勘误表v4.0中添加）

在本节末尾添加以下注释：

⚠

一旦中央管理系统（CSMS）向充电点发送了带有status registrationStatus = Accepted的BootNotification.conf消息，那么在充电点发送BootNotification.req消息之前，CSMS不应当发送TriggerMessage来请求新的BootNotification。

3.41. 第58页，部分：5.16.2：使用ChargingProfile的RemoteStart：不应设置TransactionId

在使用ChargingProfile的remoteStartTransaction.req请求中，TransactionId是否应被设置并不明确。

旧文本	如果中央系统包含了一个充电配置文件（ChargingProfile），那么充电配置文件用途（ChargingProfilePurpose）必须被设置为TxProfile。
新文本	如果中央系统包含了一个充电配置文件（ChargingProfile），那么充电配置文件用途（ChargingProfilePurpose）必须被设置为TxProfile，并且不应设置transactionId。

3.42. 第58页，部分：5.16.2：使用充电配置文件的RemoteStart中的注释意义不明确

在描述带有充电配置文件的RemoteStartTransaction时，有一个注释，但该注释的意义并不明确。

旧文本	充电点应当在向中央系统报告交易后，将TransactionId添加到接收到的配置文件中。
新文本	充电点应当将给定的配置文件应用于新启动的交易。该交易将通过startTransaction.conf由中央系统分配一个transactionId。 当充电点接收到一个setChargingProfile.req请求，其中包含与remoteStartTransaction.req中给出的配置文件具有相同StackLevel的该交易的transactionId时，充电点应当替换现有的充电配置文件，否则它应当在已经存在的配置文件旁边安装/堆叠该配置文件。

3.43. 第58页，部分5.16.4：智能充电回退到默认设置不明确

（此问题已在勘误表v3.0中添加）

旧文本	当recurrencyKind与充电计划持续时间结合使用，且充电计划持续时间短于recurrencyKind的周期时，充电点在充电计划持续时间结束后应当回退到默认行为。
新文本	当recurrencyKind与充电计划持续时间结合使用，且充电计划持续时间短于recurrencyKind的周期时，充电点在充电计划持续时间结束后应当回退到默认行为。这种回退意味着充电点（如果可用）应当使用一个具有较低stackLevel的充电配置文件。如果没有其他充电配置文件可用，充电点应当允许充电，就好像没有安装充电配置文件一样。如果充电计划周期和/或持续时间长于recurrencyKind周期，剩余的周期将不会被执行。

3.44. 第58页，部分5.16.4：未定义充电计划周期长于重复周期时如何处理

（此问题已在勘误表v3.0中添加）

对于充电计划周期和/或持续时间超过重复周期时应当如何处理没有明确的定义。

在“chargingSchedulePeriod长于duration”的注记后添加以下注记：

新文本	注记：当recurrencyKind与充电计划周期和/或持续时间结合使用，且充电计划周期和/或持续时间超过重复周期时，剩余的周期将不会被执行。

3.45. 第58页，部分5.16.4：第一个ChargingSchedulePeriod的StartSchedule应该为0（此问题已在勘误表v3.0中添加）明显未定义的内容是：在充电计划中，第一个ChargingSchedulePeriod的StartSchedule应该为0。在“chargingSchedulePeriod长于duration”的注记后添加以下注记：

新文本	注记：在充电计划中，第一个ChargingSchedulePeriod的startPeriod应当始终为0。

3.46. 第60页，部分：5.17：对MeterValues的TriggerMessage的描述不明确

当充电点接收到包含requestedMessage: MeterValues的TriggerMessage.req PDU时，关于充电点应该做什么的描述并不明确。

旧文本	以这种方式触发的MeterValues消息应该返回在配置键MeterValuesSampledData中配置的所有测量值的最新测量数据。
新文本	以这种方式触发的MeterValues消息应该返回在配置键MeterValuesSampledData中配置的所有测量量的最新测量数据。

3.47. 第61页，部分：5.19：缺少FirmwareUpdate.req与FirmwareStatusNotification.req之间的关系。

在规范中，没有描述FirmwareUpdate.req与FirmwareStatusNotification.req之间的关系。在第15页的3.3段中，有一个更详细的固件更新图，包括UpdateFirmware.req与FirmwareStatusNotification.req之间的关系，但该段是信息性的。

以下图表应替换5.19中的图表。

图2. 序列图：固件更新

附加文本	在固件下载和安装期间，充电点必须发送FirmwareStatusNotification.req PDU以保持中央系统更新固件更新过程的状态。 上面的序列图是一个示例。一种好的做法是先重启充电点，以检查新固件是否正在启动并能够连接到中央系统，然后再发送状态：已安装。但这并不是强制要求。

3.48. 第61页，部分：5.19：没有描述应该安装新固件的要求。

对于新固件的安装没有要求。

附加文本	充电点如果“验证”了新固件映像的有效性，则应尽快安装新固件。

3.49. 第61页，部分：5.19. 充电期间进行固件安装

建议不要在安装新固件时停止充电会话，而应等待会话结束后再进行。

附加文本	如果在固件安装过程中无法继续充电，建议在充电会话结束（充电点空闲）之前等待，然后开始安装。建议在充电点等待会话结束时，将未使用的连接器设置为“不可用”。

此勘误说明也适用于OCPP版本1.2和1.5。

3.50. 第66页，部分：6.25：重试描述错误

（此问题已在勘误表v4.0中添加）

在retries字段的描述中，“try”应该改为“retry”。

旧文本	（可选）这指定了充电点在放弃之前必须尝试上传诊断信息的次数。如果此字段不存在，则由充电点自行决定要重试多少次。
新文本	（可选）这指定了充电点在放弃之前必须重试上传诊断信息的次数。如果此字段不存在，则由充电点自行决定要重试多少次。

3.51. 第70页，部分：6.22：不清楚何时在GetCompositeSchedule.conf中使用scheduleStart和chargingSchedule字段。

消息：GetCompositeSchedule.conf包含3个可选字段，其中两个字段：“scheduleStart”和“chargingSchedule”的使用时机并不明确：

在描述中添加字段：scheduleStart	如果状态为“Rejected（拒绝）”，此字段可能不存在。
在描述中添加字段：chargingSchedule	如果状态是“Rejected（拒绝）”，则此字段可能不存在。

3.52. 第70页，部分：6.41：SendLocalList列表版本不应为0

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第77页

在GetLocalListVersion.conf中，listVersion=0和-1具有特殊含义，因此不应在SetLocalList.req中使用它们。

旧文本	（必填）如果是完全更新，这是完整列表的版本号。如果是差异更新，则是更新后列表的版本号。
新文本	（必填）如果是完全更新，这是完整列表的版本号。如果是差异更新，则是在应用更新后列表的版本号。不应为-1或0，因为它们在GetLocalListVersion.conf中具有特殊含义。

3.53. 第70页，部分：6.43：SetChargingProfile.req中的connectorId = 0的描述会导致混淆

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第78页

SetChargingProfile.req中connectorId的描述没有考虑到它也可以用于设置TxDefaultProfile。它似乎只考虑了ChargePointMaxProfile。

旧文本	如果connectorId = 0，则该消息包含充电点的整体限制。
新文本	如果connectorId = 0，并且消息包含ChargePointMaxProfile，则它包含充电点的整体限制。如果connectorId = 0，并且消息包含TxDefaultProfile，则它包含用于该充电点任何连接器上任何新事务的限制。

3.54. 第71页，部分：6.46：事务ID的有用值不清晰

（此问题已在勘误表v4.0中添加）

对于一些人来说，事务ID的期望值是唯一的正整数，这一点并不清晰。

旧描述	（必填）这包含中央系统提供的事务ID。
新描述	（必填）这包含中央系统提供的事务ID。 建议使用唯一的正数作为事务ID。负数和零（0）是可能的，但它们对充电点没有特殊含义（它们并不意味着事务被拒绝或类似情况）。请注意，当充电点无法成功发送StartTransaction.req时，它可能会在与事务相关的消息中使用transactionId = -1。

3.55. 第77页，部分：7.7：SuspendedEV的定义过于混淆

（此问题已在勘误表v4.0中添加）

SuspendedEV的新文本过于混淆。现在的描述方式暗示，即使EVSE处于充电状态（C2，接触器闭合），而EV没有消耗任何电力，该状态也应被视为SuspendedEV。

SuspendedEV	旧文本	当电动汽车（EV）连接到电动汽车供电设备（EVSE）上，且EVSE正在提供能源，但EV没有消耗任何能源时。（正在运行）
SuspendedEV	新文本	当电动汽车（EV）连接到电动汽车供电设备（EVSE）上，且EVSE愿意并准备好提供能源，但EV没有请求或消耗能源时。例如：使用模式3的充电点：如果EV处于B2状态，这也表示SuspendedEV。（正在运行）

3.56. 第79页，部分：7.8：recurrencyKind 仅在 chargingProfileKind 为 "Recurring"时使用

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第90页

没有描述/解释说明字段"recurrencyKind" 仅在"chargingProfileKind" 为 "Recurring"时使用。

旧描述	（可选）指示重复的起始点。
新描述	（可选）指示重复的起始点。 仅当字段：recurrencyKind 设置为：Recurring 时使用。

3.57. 第80页，部分：7.13：GetCompositeScheduleResponse 不清楚如何/何时使用哪个开始字段

（此问题已在勘误表v4.0中添加）

startSchedule字段的描述必须替换为以下内容。

旧文本	（可选）绝对计划的起始点。如果缺失，计划将相对于充电开始时间。
新文本	（可选）绝对计划的起始点。如果缺失，计划将相对于充电开始时间。当ChargingSchedule用作GetCompositeSchedule.conf消息的一部分时，该字段必须省略。

3.58. 第81页，部分：7.15：改进字符串类型的定义：CiString20Type。

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第94页

CiString20Type的描述现在可以解读为：“一个必须恰好为20个字符长度的字符串。”这是一个最大长度，而不是必需的长度。

旧文本	通用的不区分大小写的20个字符字符串。
新文本	一个不区分大小写的字符串，最大长度为20个字符。

3.59. 第81页，部分：7.16：改进字符串类型的定义：CiString25Type。

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第94页

CiString25Type的描述现在可以解读为：“一个必须恰好为25个字符长度的字符串。”这是最大长度，而不是必需的长度。

旧文本	通用的不区分大小写的25个字符字符串。
新文本	一个不区分大小写的字符串，最大长度为25个字符。

3.60. 第82页，部分：7.17：改进字符串类型的定义：CiString50Type。

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第94页

CiString50Type的描述现在可以解读为：“一个必须恰好为50个字符长度的字符串。”这是最大长度，而不是必需的长度。

旧文本	通用的不区分大小写的50个字符字符串。
新文本	一个不区分大小写的字符串，最大长度为50个字符。

3.61. 第82页，部分：7.18：改进字符串类型的定义：CiString255Type。

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第95页

CiString255Type的描述现在可以解读为：“一个必须最多为255个字符长度的字符串。” 这是一个最大长度，而不是必需的长度。

旧文本	通用的不区分大小写的255个字符字符串。
新文本	一个不区分大小写的字符串，最大长度为255个字符。

3.62. 第82页，部分：7.19：改进字符串类型的定义：CiString500Type。

（此问题已在勘误表v4.0中添加）

OCPP 1.6 最终版 第95页

CiString500Type的描述现在可以解读为：“一个最多为500个字符长度的字符串。”这是一个最大长度，而不是必需的长度。

旧文本	通用的不区分大小写的500个字符字符串。
新文本	一个不区分大小写的字符串，最大长度为500个字符。

3.63. 第84页，部分：6.55：UpdateFirmware.req的描述中：retrieveDate 描述不明确

字段“retrieveDate”的描述不明确。它不应该是“必须”，而应该是“可以”或者“允许”。

旧文本	必填项。这包含充电站必须检索（新）固件的日期和时间之后的时间点。
新文本	必填项。这包含充电站被允许检索（新）固件的日期和时间之后的时间点。

3.64. 第88页，部分：7.7：SuspendedEVSE和SuspendedEV的描述过于严格，并非所有充电器都有接触器

SuspendedEVSE和SuspendedEV的描述似乎暗示EVSE具有接触器，但情况并非总是如此，例如：无线充电。

SuspendedEVSE	旧文本	当充电器的连接器接触器根据EVSE的请求打开时，例如由于智能充电限制或StartTransaction.conf指示不允许充电（可操作）时
SuspendedEVSE	新文本	当电动汽车（EV）连接到电动汽车供电设备（EVSE）但EVSE没有向EV提供能量时，例如由于智能充电限制、当地供电功率限制，或由于StartTransaction.conf指示不允许充电等原因（可操作状态）。
SuspendedEV	旧文本	当电动汽车供电设备（EVSE）准备好提供能量但接触器是打开的状态时，例如电动汽车（EV）尚未准备好。
SuspendedEV	新文本	当电动汽车（EV）连接到电动汽车供电设备（EVSE）并且EVSE正在提供能量，但EV没有接收任何能量时。（可操作状态）

3.65. 第90页，部分：7.8：TxProfiles允许使用validFrom字段。

在ChargingProfile的类定义中，字段“validFrom”被定义为：“当ChargingProfilePurpose是TxProfile时不应使用。”该规范指出，字段ValidTo和ValidFrom不应与profiletypeTxProfile一起使用。这一注释应该在最终版本中被删除。随着决定支持ProfileTypeTxProfile的堆叠使用，ValidFrom和ValidTo字段的使用是不可避免的，因为否则具有最高StackLevel的配置文件将保持活动状态，直到它被卸载。

旧文本	可选。配置文件开始有效的时间点。如果缺失，配置文件将在充电站收到时立即生效。当ChargingProfilePurpose是TxProfile时不应使用。
新文本	可选。配置文件开始有效的时间点。如果缺失，配置文件将在被充电站接收后立即生效。

3.66. 第91页，部分：7.8：TxProfiles允许使用validTo字段。

在ChargingProfile的类定义中，字段“validTo”被定义为：“当ChargingProfilePurpose是TxProfile时不应使用。”该规范指出，字段ValidTo和ValidFrom不应与profiletypeTxProfile一起使用。这一注释应该在最终版本中被删除。随着决定支持ProfileTypeTxProfile的堆叠使用，ValidFrom和ValidTo字段的使用是不可避免的，因为否则具有最高优先级的配置文件将保持活动状态，直到它被卸载。

旧文本	可选。配置文件停止有效的时间点。如果缺失，配置文件将保持有效直到被另一个配置文件替换。当ChargingProfilePurpose是TxProfile时不应使用。
新文本	可选。配置文件停止有效的时间点。如果缺失，配置文件将保持有效直到被另一个配置文件替换。

3.67. 第91页，部分：7.10：关于ChargingProfilePurposeType中TxProfile/TxDefaultProfile的描述与RemoteStartTransaction的关系不明确

在remoteStartTransaction.req中，正确的ProfilePurpose应该是什么并不完全清楚。

TxDefaultProfile	旧文本	用于新交易的默认配置文件。
TxDefaultProfile	新文本	在充电站中可以配置的默认配置文件。当启动新交易时，除非是通过remoteStartTransaction.req启动的交易且该交易附带充电站接受的ChargeProfile，否则应使用此配置文件。
TxProfile	旧文本	此配置文件包含充电站对当前交易施加的限制。具有此目的的配置文件在交易终止时将不再有效。
TxProfile	新文本	该配置文件包含充电站对当前交易，或者当新交易通过带有ChargingProfile的RemoteStartTransaction.req启动时，对交易施加的限制。具有此目的的配置文件在交易终止时将不再有效。

3.68. 第92页，部分：7.12：需要更详细地澄清ChargingRateUnit的值描述

对于交流充电，使用ChargingRateUnit的W单位可能会非常复杂，如果使用该单位，计算将变得棘手。应该改进ChargingRateUnit的值的描述。

值	旧描述	新描述
W	瓦特（功率）。	瓦特（功率）。 这是允许的总充电功率。 如果用于交流充电，应通过以下方式计算每相电流：每相电流 = 功率 /（线路电压 * 相数）。计算中使用的“线路电压”不是测量的电压，而是该区域的设定电压（因此，是230或110伏特）。“相数”是ChargingSchedulePeriod中的numberPhases。对于直流充电，通常使用此方式更为方便。 请注意，如果ChargingSchedulePeriod中的numberPhases缺失，则应假定为3。
A	安培（电流）。	安培（电流）。 每相的安培数，而不是所有相的总和。 通常，这更适用于交流充电。

3.69. 第93页，部分：7.13：第一个ChargingSchedulePeriod应以StartSchedule = 0开始

（已在勘误表v3.0中添加）

没有要求解释显而易见的事实：第一个ChargingSchedulePeriod应以StartSchedule = 0开始。

chargingSchedulePeriod字段的更新描述：

旧文本	必填项。定义随时间变化的最大功率或电流使用的ChargingSchedulePeriod元素列表。
新文本	必填项。定义随时间变化的最大功率或电流使用的ChargingSchedulePeriod元素列表。第一个ChargingSchedulePeriod的StartSchedule必须始终为0。

3.70. 第94页，部分：7.14 ChargingSchedulePeriod的限制也可以以瓦特为单位

ChargingSchedulePeriod字段：限制可以以瓦特或安培为单位。

旧文本	必填项。调度周期内的功率限制，以安培为单位。最多接受一位小数（例如8.1）。
新文本	必填项。调度周期内的充电速率限制，以适用的chargingRateUnit为单位，例如安培或瓦特。最多接受一位小数（例如8.1）。

3.71. 在第94-95页，章节：7.15-7.19，CiStringXXXType 应该被定义为一个类型。

但是，CiStringXXTypes 被定义为了类，这些类包含一个名为 Name 的字段，但它们本应该被定义为一个类型（不包含字段 Name）。

受影响的段落：

• 7.15 CiString20Type

• 7.16 CiString25Type

• 7.17 CiString50Type

• 7.18 CiString255Type

• 7.19 CiString500Type

旧的定义是：

7.15 CiString20Type

类（Class）

通用情况下，不区分大小写的20字符字符串。

字段名	字段类型	描述
cistring20	CiString[20]	字符串是不区分大小写的。

新的定义是：

7.15 CiString20Type

类型(Type)

通用的不区分大小写的20字符字符串。

字段类型	描述
CiString[20]	字符串是不区分大小写的。

这些更改对WSDL和JSON定义没有影响，它们在WSDL和JSON模式中已经被正确定义。

3.72. 第98页，章节：7.27：IdTagInfo的定义缺少了基数（Cardinality）

在OCPP 1.6的每个类定义中，都包含了一个名为“基数”（Card.）的列，但在IdTagInfo的定义中缺少这一列。

新定义：

7.27 IdTagInfo

类

包含关于标识符的状态信息。它在授权、开始交易和停止交易的响应中返回。

如果未给出expiryDate，则该状态没有结束日期。

字段名	字段类型	Card.	描述
expiryDate	日期	0..1	可选。这包含了idTag应从授权缓存中移除的日期。
parentIdTag	IdToken	0..1	可选。这包含了父标识符。
status	授权状态	1..1	必需。这包含了中央系统是否已接受idTag。

3.73. 第98页，章节：7.28。idToken字段的类型错误

字段：idToken应该为CiString20Type类型，因为它是不区分大小写的。

旧文本	String[20]
新文本	CiString20Type

为了防止互操作性问题：请不要更新WSDL文件！

注意：对于未来版本：在添加CiStringXXTypes时遗漏了idToken。可能会将其从类型中移除，然后其他类中所有类型为idToken的字段都将被替换为CiString20Type。

3.74. 第98页，章节：7.28：IdToken应该被定义为类型

IdToken被定义为一个类，包含一个名为Name的字段，但它们本应该被定义为一个类型（不包含字段名）。WSDL和JSON模式是正确的，只是在规范中出现了错误。（在OCPP 1.5中也存在此错误）

新定义：

7.28 IdToken

类型

包含用于授权的标识符。它是一个不区分大小写的字符串。在未来的版本中，它可能会变成一个复杂类型，以支持多种形式的标识符。

字段类型	描述
CiString20Type	IdToken 是不区分大小写的。

3.75. 第98页，章节：9.1.5：关于MeterValue持续时间的文本描述错误

在勘误表v4.0中补充

OCPP 1.6 最终版 第111页

在配置键ClockAlignedDataInterval的描述中，有一些关于MeterValue持续时间的文本描述。但是MeterValue没有持续时间这一属性。这是从OCPP 1.5中遗留的旧文本，在OCPP 1.5中已经是错误的。这段文本应该被移除。

忽略错误的文本：

“以及（可选的）持续时间间隔值，按照ISO8601标准表示”

3.76. 第98页，章节：9.1.6：改进配置键的描述：“ConnectionTimeOut”

在勘误表v4.0中补充

配置键“ConnectionTimeOut”的描述可以进一步改进。

旧文本	从“准备”状态开始，到由于电动汽车驾驶员未能（正确）将充电电缆连接器插入相应的插座，初始会话被自动取消的这段时间。充电点应返回到原始状态，可能是“空闲”状态。
新文本	从“准备”状态开始，到由于电动汽车驾驶员未能（正确）将充电电缆连接器插入适当的插座而导致初始会话被自动取消的这段时间。充电点应返回到原始状态，通常是“空闲”状态。

3.77. 第99页，章节：7.31：没有定义.register和.interval

有几个测量值被定义为.register或.interval，但没有定义这些后缀的具体含义。

旧定义：

值	描述
Energy.Active.Export.Register	电动汽车导出的能量（Wh 或 kWh）
Energy.Active.Import.Register	电动汽车导入的能量（Wh 或 kWh）
Energy.Reactive.Export.Register	电动汽车导出的无功能量（varh 或 kvarh）
Energy.Reactive.Import.Register	电动汽车导入的无功能量（varh 或 kvarh）
Energy.Active.Export.Interval	电动汽车导出的能量（Wh 或 kWh）
Energy.Active.Import.Interval	电动汽车导入的能量（Wh 或 kWh）
Energy.Reactive.Export.Interval	电动汽车导出的无功能量（varh 或 kvarh）
Energy.Reactive.Import.Interval	电动汽车导入的无功能量（varh 或 kvarh）

新定义：

导入是电网到充电点、电动汽车或其他负载的能量流动。导出是电动汽车到充电点，以及/或者从充电点到电网的能量流动。

值	描述
Energy.Active.Export.Register	从（最具权威性的）电表“有功电能”（Wh 或 kWh）寄存器中读取的数值，该电表用于测量导出的能量（到电网）。
Energy.Active.Import.Register	从（最具权威性的）电表“有功电能”（Wh 或 kWh）寄存器中读取的数值，该电表用于测量从电网供应导入的能量。
Energy.Reactive.Export.Register	从（最具权威性的）电表“无功能量”（VARh 或 kVARh）寄存器中读取的数值，该电表用于测量导出的能量（到电网）。
Energy.Reactive.Import.Register	从（最具权威性的）电表“无功能量”（VARh 或 kVARh）寄存器中读取的数值，该电表用于测量从电网供应导入的能量。
Energy.Active.Export.Interval	在由MeterValues的ReadingContext指定的相关时间“间隔”内，以及适用于“ClockAlignedDataInterval”和“MeterValueSampleInterval”的配置值（以秒为单位）下，“有功电能”（Wh或kWh）的绝对导出量（到电网）。
Energy.Active.Import.Interval	在由MeterValues的ReadingContext指定的相关时间“间隔”内，以及适用于“ClockAlignedDataInterval”和“MeterValueSampleInterval”的配置值（以秒为单位）下，“有功电能”（Wh或kWh）的绝对导入量（从电网供应）。
Energy.Reactive.Export.Interval	在由MeterValues的ReadingContext指定的相关时间“间隔”内，以及适用于“ClockAlignedDataInterval”和“MeterValueSampleInterval”的配置值（以秒为单位）下，“无功能量”（VARh或kVARh）的绝对导出量（到电网）。
Energy.Reactive.Import.Interval	在由MeterValues的ReadingContext指定的相关时间“间隔”内，以及适用于“ClockAlignedDataInterval”和“MeterValueSampleInterval”的配置值（以秒为单位）下，“无功能量”（VARh或kVARh）的绝对导入量（从电网供应）。

注意：

与单个充电交易或非交易性消费者（例如充电点内部电源、整体电源）相关的所有“寄存器”值必须在时间上单调递增。

对应于报告的“.Register”值的实际能量量计算为：该寄存器值减去在交易开始或其他相关起始时间点记录/报告的寄存器值。为了改进可审计性，“.Register”值应该直接按照从电能计量硬件的非易失性寄存器中读取的值来报告，并且不应在交易开始时重新归零。这允许中央系统通过确认任何交易的起始寄存器值与同一连接器上前一个交易的结束寄存器值相同，来识别由于硬件故障、错误接线、欺诈等原因导致的连续交易之间的“缺失能量”。

3.78. 第103页，章节：7.37：RecurrencyKindType 的定义存在歧义。

已在勘误表v3.0中添加

RecurrencyKindType 的定义存在歧义。不清楚何时应该重复充电配置文件。

对表格的修改：

值	旧的描述	新的描述
Daily	该计划将在次日开始时重新开始。	该计划每24小时重新启动一次，与startSchedule中的时间相同。
Weekly	该计划将在下周一开始时（定义为周一早晨）重新启动。	该计划每7天重新启动一次，与startSchedule中的时间和星期几相同。

3.79. 第103页，章节：9.1.23：配置键：“StopTransactionOnEVSideDisconnect”不应为必需项

已添加在勘误表v4.0

OCPP 1.6 最终版 第116页

配置键“StopTransactionOnEVSideDisconnect”的描述是必需的。它被添加到OCPP中以支持车辆侧没有锁定的电动汽车。但现在这种情况已经不存在了，只有在使用三菱欧蓝德PHEV的第一版时才是这样。

德国的eichrecht（电气法）不允许实现这个配置键。

旧值：必填/可选	必填（或必需的）required
新值：必填/可选	可选的 optional
旧值：可访问性（Accessibility）	可读写的 RW
新值：可访问性（Accessibility）	R（可读）或RW（可读写）。选择取决于充电点的实现。

3.80. 第104页，章节：9.1.30：不必要的配置键：“SupportedFeatureProfilesMaxLength”

已添加在勘误表v4.0

配置键“SupportedFeatureProfilesMaxLength”的描述没有用处。

“SupportedFeatureProfiles”是一个只读配置键。可以从规范中移除“SupportedFeatureProfilesMaxLength”。

表格前的附加文本

注：这个配置键不需要被实现。它本不应成为OCPP 1.6的一部分，“SupportedFeatureProfiles”是一个只读配置键。

3.81. 第105页，章节：7.42：改进了软/硬重置的描述

已添加在勘误表v3.0

软/硬重置的描述可以改进，两者之间的区别并不十分明确。

对表格的修改：

值	旧的描述	新的描述
Hard	充电点软件的完全重启。	重启（所有）硬件，充电点不需要优雅地停止正在进行的交易。如果可能的话，充电点在重启并通过BootNotification.conf被中央系统接受后，会为之前正在进行的交易发送一个StopTransaction.req请求。这是对功能不正常的充电点采取的最后一种解决方案，通过发送“硬”重置，（排队）的信息可能会丢失。
Soft	返回到初始状态，并优雅地终止任何正在进行的交易。	优雅地停止正在进行的交易，并为每个正在进行的交易发送StopTransaction.req请求。然后，它应该重启应用软件（如果可能的话，否则重启处理器/控制器）。

3.82. 第105页，章节：9.1：缺少消息超时的标准配置键

已添加在勘误表v4.0

OCPP没有定义所需的消息超时是多少。由于OCPP用于许多不同的传输层，从3G到光纤，时间可能会有很大差异。充电点运营商（CPO）需要根据所使用的网络来配置这一点。但OCPP并没有为此定义标准的配置键。因此，现在几乎每个充电点制造商都为同一事物定义了自己的名称。

新定义：

9.1 核心配置文件

9.1.15 MessageTimeout（消息超时）

必要/可选	可选的
可访问性	RW 可读写的
类型	整数
描述	定义OCPP消息的超时时间（以秒为单位）。 如果充电点在此超时时间内没有收到对请求的响应，则充电点应认为该请求已超时。

3.83. 第105页，章节：9.1.33：如何实现带固定电缆的充电点的UnlockConnectorOnEVSideDisconnect功能尚不清楚

已添加在勘误表v4.0

在描述变量UnlockConnectorOnEVSideDisconnect的表格中，更改以下行的文本：

可访问性	RW（在固定电缆的情况下为RO）
描述描述	当设置为true时，如果电缆在电动汽车端被拔掉，充电点应解锁充电点端的电缆。带有固定电缆的充电点应始终将此值报告为false，并且不应允许更改此值。

3.84. 第106页，章节：7.45：测量量“频率”没有单位。

测量量“频率”没有单位。

在第100页，章节：7.31中，为“频率”的描述添加：

OCPP 1.6没有为频率定义单位，任何具有测量量“频率”的SampledValue的单位都是赫兹。

3.85. 第107页，章节：7.42：对未知的ConnectorId执行UnlockConnector操作

已添加在勘误表v3.0

没有规定当中央系统请求为未知的ConnectorId解锁连接器时，充电点应该如何响应。

最好是返回“已拒绝”的响应，因此这将在OCPP 2.0中添加。对于OCPP 1.6，我们不能添加额外的状态，所以我们只能使用“不支持”。“UnlockFailed”不应用于此情况，“UnlockFailed”真的是当锁定机制检测到解锁尝试失败时使用的。

对表格的修改：

值	旧的描述	新的描述
UnlockFailed	无法解锁连接器。	解锁连接器失败：充电点已尝试解锁连接器，并检测到连接器仍然被锁定或解锁机制出现故障。
NotSupported	充电点没有连接器锁	充电点没有连接器锁，或者ConnectorId未知。

3.86. 第107页，章节：9.4.2：配置键：“ChargingScheduleAllowedChargingRateUnit”的值令人困惑

已添加在勘误表v4.0

配置键：“ChargingScheduleAllowedChargingRateUnit”有两个允许的值：“Current”和“Power”。然而，ChargingRateUnitType（第80页，章节：7.12）的可能值为：“A”和“W”。这令人困惑。

如果“ChargingScheduleAllowedChargingRateUnit”的允许值也是“A”和“W”，那么会更好。这将是OCPP2.0的解决方案。

对于OCPP 1.6，将添加额外的解释。

额外描述	“Current”意味着仅允许使用充电速率单位为“A”（安培）的充电计划 “Power”意味着仅允许使用充电速率单位为“W”（瓦特）的充电计划

3.87. 第112页，章节：9.1.6：改进配置键“ConnectionTimeOut”的描述

配置键“ConnectionTimeOut”的描述可以改进。

旧的文本	（从成功授权起）的间隔时间，如果电动汽车用户未能（正确）将充电电缆连接器插入适当的连接器中，则即将开始的充电会话将自动取消。
新的文本	从“准备”状态开始的时间间隔，直到由于电动汽车驾驶员未能（正确）将充电电缆连接器插入适当的插座，导致即将开始的充电会话自动取消。充电点应返回到原始状态，可能是“空闲”状态。

3.88. 第121页，章节：9：缺少对SupportedFileTransferProtocols的定义

在错误修正表v4.0中已添加

在第八章的第96页（OCPP 1.6 最终版：第109页）中，有一个关于配置键的引用：

SupportedFileTransferProtocols。这个配置键在第九章中并没有定义。

新定义：

9.5 固件管理

9.5.1 SupportedFileTransferProtocols

必要/可选	可选的 optional
可访问性	只读 R
类型	Charge Station Language (充电站语言)   CSL
描述	这个配置键告诉中央系统充电点支持哪些文件传输协议。允许的值包括：'FTP'、'FTPS'、'HTTP' 和 'HTTPS'。

3.89. 第121页，章节：9.1：中央系统需要知道在StopTransaction中支持的最大计量值数量

在错误修正表v4.0中添加

当充电点配置为通过StopTxnSampledData和/或StopTxnAlignedData在StopTransaction中提供计量值时，如果交易时间非常长（比如：电动汽车在机场停车数日）或ClockAlignedDataInterval或MeterValueSampleInterval中配置的时间间隔值较低，充电点可能会收集到比其能够存储或发送在StopTransaction中的更多的计量值。在这种情况下，充电点需要丢弃中间值以防止崩溃等。但中央系统需要知道在何时发生这种情况。

新定义：

9.1 核心配置文件（CoreProfile）

9.1.23 StopTransactionMaxMeterValues

必要/可选	可选的 optional
可访问性	只读的 R
类型	整数
描述	此充电点在StopTransaction.req的transactionData字段中可以报告的计量值的最大数量。 当为某次交易收集的计量值数量超过StopTransactionMaxMeterValues时，充电点可能会丢弃中间的计量值，以防止内存耗尽或无法发送StopTransaction.req（超出传输缓冲区大小）。但起始和停止的计量值永远不会被丢弃。 当充电点需要存储的中间值数量超过StopTransactionMaxMeterValues时，建议不要从开头开始丢弃消息或停止存储新值。更好的做法是首先丢弃中间的消息（例如，第1条消息、第3条消息、第5条消息等），或者使用智能算法，例如首先删除重复的值等。

4. 拼写错误

拼写错误、对不正确链接/引用的修正、对使用术语的改进等，这些都不影响协议工作方式的描述。

4.1. 通用：拼写错误

字段类型：DateTime 应为dateTime

dateTime 字段类型在少数地方被错误地拼写为：DateTime（D字母大写）

页	章节	消息/类	字段名
24	3.12.2	注：添加到底部	validFrom
70	6.22	GetCompositeSchedule.conf	scheduleStart
90	7.8	ChargingProfile	validFrom
91	7.8	ChargingProfile	validTo
93	7.13	ChargingProfile	startSchedule

4.2. 通用：能量表与功率表的使用

在整个规范中使用了能量表（Energy Meter）和功率表（Power Meter）这两个术语，但它们的使用并不一致，而“电能表”（Electrical Meter）这一术语似乎更适合于大多数情况。

以下是对此进行的所有文本改进列表：

[此处应列出具体的文本改进内容，但在此翻译中并未给出具体内容。]

页	章节	旧的文本	新的文本
8	2.2	定义了能源表（如果不存在，则为电网连接）与充电点连接器之间的各相位的接线顺序。	定义了电表（如果不存在，则为电网连接）与充电点连接器之间的各相位的接线顺序。
38	4.7	充电点可以采样能源表或其他传感器/转换器硬件，以提供有关其计量值的额外信息。	充电点可以采样电表或其他传感器/转换器硬件，以提供有关其计量值的额外信息。
38	4.7	充电点应报告从功率表（或不存在时从电网连接点）的视角出发的所有与相号相关的值。	充电点应报告从电表（或不存在时从电网连接点）的视角出发的所有与相号相关的值。
63	6.3	这包含了充电点主功率表的序列号。	这包含了充电点主电能表的序列号。
63	6.3	这包含了充电点主功率表的类型。	这包含了充电点主电能表的类型。
87	7.6	无法读取功率表。	无法读取电能/能量/功率表。
116	9.1.21	每个连接器相对于连接器所连接的能源表（如果不存在，则为电网连接）的相位旋转。	每个连接器相对于连接器所连接的电能表（如果不存在，则为电网连接）的相位旋转。

4.3. 第13页，章节：3.2：关于SupportedFeatureProfiles的文本中的拼写错误

在消息与特性配置文件映射表格的下方，有一个拼写错误：“chargingprofiles”而不是“feature profiles”。

旧的文本	特定充电配置文件的支持情况由SupportedFeatureProfiles配置键报告。
新的文本	特定特性配置文件的支持情况由SupportedFeatureProfiles配置键报告。

4.4. 第18页，章节：3.4.4：未知离线授权文本中的拼写错误

关于未知离线授权的文本中有一个拼写错误。

旧的文本	当与中央服务器的连接恢复时
新的文本	当与中央服务器的连接恢复时

4.5. 第19页，章节：3.5：缺少OCPP事务、会话、EnergyOfferPeriod等的定义

在第19页的表格中，有一些术语在规范中从未被描述过。

第19页图表中的更改：

旧的文本	新的文本
Session	Charging Session
OCPP Transaction	Transaction

更新第19页章节3.5的图表：

对第7页章节2.2中定义表的更改：

术语	旧的描述	新的描述
Charging Session	在交易的一部分期间，电动汽车被允许请求能量	当首次与用户或电动汽车进行交互时，充电会话开始。这可能是一次刷卡、远程启动交易、连接电缆和/或电动汽车、停车位占用检测器等。

对第7页章节2.2中定义表的补充：

术语	描述
Energy Offer Period	当电动汽车供电设备（EVSE）准备好并愿意供电时，能量提供期开始。
Energy Offer SuspendPeriod	在交易过程中，电动汽车供电设备（EVSE）可能会暂停向电动汽车提供能量，例如由于智能充电或本地平衡需求。

在整个规范中进行了更改，以纠正术语使用的不当之处。

页	小节	旧的文本	新的文本
42	4.9	C6：充电会话被用户或远程停止交易消息停止，需要进一步的用户操作（例如，移除电缆，离开停车位）	C6：交易被用户或远程停止交易消息停止，需要进一步的用户操作（例如，移除电缆，离开停车位）
42	4.9	D6：充电会话已停止，需要进一步的用户操作	D6：交易已停止，需要进一步的用户操作
43	4.9	E6：充电会话已停止，需要进一步的用户操作	E6：交易已停止，需要进一步的用户操作
43	4.9	F2：用户重新启动充电会话（例如，重新连接电缆，再次出示idTag）	F2：用户重新启动充电会话（例如，重新连接电缆，再次出示idTag），从而创建一个新的交易
88	7.7	准备中：当一个连接器不再可供新用户使用时，但当前没有激活的充电会话。通常，当用户出示标签、插入电缆或车辆占用停车位时，连接器会处于占用状态。	准备中：当一个连接器不再可供新用户使用时（但尚未有正在进行的交易）。通常，当用户出示标签、插入电缆或车辆占用停车位时，连接器会处于准备状态。
88	7.7	完成中：当在连接器上的充电会话已停止，但连接器尚未可供新用户使用时，例如电缆尚未移除或车辆尚未离开停车位。	完成中：当连接器上的交易已停止，但连接器尚未可供新用户使用时，例如电缆尚未移除或车辆尚未离开停车位。
91	7.9	例如会话的开始	例如交易的开始
111	9.1.5	或在充电会话的开始或结束时，部分时间间隔	或在交易的开始或结束时，部分时间间隔
112	9.1.6	（从成功授权开始）到由于电动汽车用户未能（正确）将充电电缆连接器插入到相应的连接器中而导致初始充电会话自动取消的间隔。	（从成功授权开始）到由于电动汽车用户未能（正确）将充电电缆连接器插入到相应的连接器中而导致初始交易自动取消的间隔。
117	9.1.25	在每个充电会话的ClockAlignedDataInterval中，需要在StopTransaction.req的TransactionData元素以及MeterValues.req协议数据单元（PDU）中包含时钟对齐的周期性测量值。	在每个交易的ClockAlignedDataInterval期间，时钟对齐的周期性测量值需要被包含在StopTransaction.req的TransactionData元素以及MeterValues.req协议数据单元（PDU）中。
117	9.1.27	在StopTransaction.req PDU的TransactionData元素中，需要包含从充电会话开始起，每隔MeterValueSampleInterval秒采样一次的测量值。	在StopTransaction.req PDU的TransactionData元素中，需要包含从交易开始起，每隔MeterValueSampleInterval秒采样一次的测量值。
121	9.4.4	如果已定义且为真，则该充电点支持在充电会话期间从三相切换到单相。	如果已定义且为真，则该充电点支持在交易期间从三相切换到单相。

4.6. 第34页，部分：4.2：引导通知图：间隔

图13：“序列图：引导通知”包含一个拼写错误。

旧的文本	BootNotification.conf(currentTime, heartbeatInterval, status)
新的文本	BootNotification.conf(currentTime, interval, status)

4.7. 第35页，部分：4.21：描述中的拼写错误

已在勘误表v4.0中添加

此勘误不影响OCPP 1.6最终版（第一版）

文本中包含：“this such”这是错误的。

旧的文本	想要实现这种行为的各方必须意识到，这些交易是否能够送达中央系统是不确定的。
新的文本	想要实现这种行为的各方必须意识到，这些交易是否能够成功发送到中央系统是不确定的。

4.8. 第35页，部分：4.5. 更新固件的消息名称错误

已在勘误表v4.0中添加

此勘误不影响OCPP 1.6最终版（第一版）

该节的最后一句引用了UpdateFirmware.req，但消息名称不正确。

旧的文本	由中央系统通过FirmwareUpdate.req PDU启动的
新的文本	由中央系统通过UpdateFirmware.req PDU启动的

4.9. 第39页，部分：4.9. 表格中的拼写错误：准备中

已在勘误表v4.0中添加

此勘误不影响OCPP 1.6最终版（第一版）

第2列的标题包含拼写错误。

旧的文本	Prepairing
新的文本	Preparing

4.10. 第47页，部分：4.10：停止交易描述中的拼写错误

在将StopTransactionOnEVSideDisconnect设置为true的描述中存在拼写错误。

旧的文本	将StopTransactionOnEVSideDisconnect设置为true将防止通过拔掉电动汽车侧未锁定的电缆来破坏能源流动的破坏行为。
新的文本	将StopTransactionOnEVSideDisconnect设置为true将防止通过拔掉电动汽车侧未锁定的电缆来阻止能源流动的破坏行为。

4.11. 第50页，部分：5.5：清除充电配置文件序列图：错误的.conf消息

第50页上关于清除充电配置文件的序列图包含一个拼写错误。它包含了错误的响应：“ClearCache.conf”，而正确的应该是“ClearChargingProfile.conf”。

请更新第50页上5.5部分的序列图：

图3. 更新的序列图：清除充电配置文件

4.12. 第55页，部分：5.13：在描述预约的父idTag时缺少“MAY”

在通过Authorize.req获取预约的父id（parent-id）的描述中缺少了“MAY”这个词。

旧的文本	Authorize.conf 响应包含父ID（parent-id）。
新的文本	Authorize.conf 响应可能包含父ID（parent-id）。

4.13. 第55页，部分：5.16.4：关于第一个chargingSchedulePeriod的注释中存在拼写错误

已在勘误表v4.0中添加

此勘误不影响OCPP 1.6最终版（第一版）

关于第一个chargingSchedulePeriod的注释中存在拼写错误。

旧的文本	在充电计划中的第一个chargingSchedulePeriod的StartSchedule总是应该为0。
新的文本	在充电计划中的第一个chargingSchedulePeriod的startPeriod总是应该为0。

4.14. 第56页，部分：5.14：重置描述中的拼写错误

已在勘误表v3.0中添加

Reset响应的描述中存在拼写错误。

旧的文本	响应PDU应包含充电点是否会尝试自行重置的信息。 The response PDU SHALL include whether the Charge Point is will attempt to reset itself.
新的文本	响应PDU应包含充电点是否会尝试自行重置的信息。 The response PDU SHALL include whether the Charge Point will attempt to reset itself.

4.15. 第60页，部分：5.18：中央系统发送解锁连接器

在关于解锁连接器的段落中，“充电点”和“中央服务器”混淆了。

旧的文本	要执行此操作，充电点应发送
新的文本	要执行此操作，中央系统应发送

4.16. 第71页，部分：6.23：GetConfiguration.req中的拼写错误

关于GetConfiguration.req的文本中存在拼写错误。

旧的文本	这包含了中央系统发送给充电点的GetConfiguration.req PDU的字段定义。
新的文本	这包含了由中央系统发送给充电点的GetConfiguration.req PDU的字段定义。

4.17. 第81页，部分：7.13：ChargingSchedule chargingSchedulePeriod描述中的拼写错误

已在勘误表v4.0中添加

chargingSchedulePeriod的描述中存在拼写错误。

旧的文本	第一个ChargingSchedulePeriod的startSchedule总是应该为0。
新的文本	第一个ChargingSchedulePeriod的startPeriod总是应该为0。

4.18. 第91页，部分：7.9：ChargingProfileKindType缺少描述和“在哪里使用”

在ChargingProfileKindType的定义中没有“在哪里使用”的说明。

额外文本	充电配置文件的类型，用于：ChargingProfile

4.19. 第91页，部分：7.10：ChargingProfilePurposeType中的ChargePointMaxProfile描述包含未使用的词语

在ChargingProfilePurposeType的ChargePointMaxProfile描述中包含了一些本不应该出现的词语。

旧的文本	用于整个充电点的最大可用功率或电流的配置。SetChargingProfile.req消息。
新的文本	整个充电点可用的最大功率或电流的配置。

4.20. 第91页，部分：7.10：ChargingProfilePurposeType缺少描述和“在哪里使用”

在ChargingProfilePurposeType的定义中没有“在哪里使用”的说明。

额外文本	充电配置文件的用途，用于：ChargingProfile

4.21. 第92页，部分：7.13：ChargingSchedule缺少描述和“在哪里使用”

在ChargingSchedule的定义中没有“在哪里使用”的说明。

额外文本	充电计划结构定义了一个充电周期列表，用于：GetCompositeSchedule.conf和ChargingProfile。

4.22. 第93页，部分：7.14：ChargingSchedulePeriod缺少描述和“在哪里使用”

在ChargingSchedulePeriod的定义中没有“在哪里使用”的说明。

附加文本 / 额外文本

充电计划周期结构定义了充电计划中的一个时间段，用于：ChargingSchedule。

4.23. 第96页，部分：7.22. 描述中的拼写错误 ConfigurationStatus

在ConfigurationStatus的描述中缺少单词“is”

旧的文本	新的文本
Configuration key supported and setting has been changed.	Configuration key is supported and setting has been changed.
Configuration key supported, but setting could not be changed.	Configuration key is supported, but setting could not be changed.
Configuration key supported and setting has been changed,

4.24. 第101页，部分：7.33：MeterValue缺少在StopTransaction.req中的使用

在MeterValue的描述中，有一个关于MeterValue使用情况的链接：MeterValue.req，但实际上MeterValue也在StopTransaction.req中使用。

旧的文本	MeterValues.req中的一个或多个采样值的集合。
新的文本	MeterValues.req和StopTransaction.req中的一个或多个采样值的集合。

4.25. 第102页，部分：7.35：Transaction.Begin和Transaction.End的描述混淆了

Transaction.Begin和Transaction.End的描述混淆了。

旧文本：

值	描述
Transaction.Begin	交易结束时的值
Transaction.End	交易开始时的值

新文本：

值	描述
Transaction.Begin	交易开始时的值
Transaction.End	交易结束时的值

4.26. 第106页，部分：7.45：UnitOfMeasure链接到错误的使用场景

在UnitOfMeasure的描述中，有关于UnitOfMeasure使用场景的链接。这些链接错误地指出：

MeterValues.req和StopTransaction.req，应该是：SampledValue

旧的文本	“unit”字段的可选值，用于MeterValues.req和StopTransaction.req消息中的Value元素。
新的文本	“unit”字段的可选值，用于SampledValue中的Value元素。

4.27. 第110页，部分：9：标准配置键名称和值的文本中存在拼写错误

关于标准配置键名称和值的文本中存在一个拼写错误。

旧的文本	如果可访问性是读写，中央系统也可以使用ChangeConfiguration写入键的值 In case the the accessibility is read-write, the Central System can also write the value for the key using ChangeConfiguration
新的文本	如果可访问性是读写，中央系统也可以使用ChangeConfiguration写入键的值。 In case the accessibility is read-write, the Central System can also write the value for the key using ChangeConfiguration.

4.28. 第121页，部分：9.4.4：ConnectorSwitch3to1PhaseSupported：类型应为布尔值

配置键ConnectorSwitch3to1PhaseSupported的类型定义中存在一个拼写错误：类型应为布尔值（boolean），但现在是bool。

旧的类型	bool  布尔
新的类型	Boolean 布尔

4.29. 第123页，部分：A.1：在新增枚举值列表中缺少Power.Factor

在枚举Measurand的新增值列表中，缺少值：Power.Factor，应该添加。

旧的文本	新增枚举Current.Offered, Frequency, Power.Offered, RPM 和 SoC
新的文本	新增枚举Current.Offered, Frequency, Power.Factor, Power.Offered, RPM 和 SoC

5.已知但将不会修复的问题

目前无已知问题