OCPP 1.6-J勘误表
v1.0 发布，2019-12-04
勘误表：适用于OCPP 1.6-J规范。
版权所有 © 2010 – 2019 Open Charge Alliance。保留所有权利。
本文档遵循*《知识共享署名-禁止演绎 4.0 国际许可协议》*（CC BY-ND 4.0 Legal Code | Attribution-NoDerivs 4.0 International | Creative Commons）进行发布。
版本历史记录
| 版本 | 日期 | 作者 | 描述 |
| v1.0 Release | 2019-12-04 | Robert de Leeuw IHomer | 发布OCPP-J勘误表 |
- 范围 本文档包含OCPP 1.6-J规范（JSON）和JSON架构文件的勘误表。
1.1. JSON架构文件随着本勘误表（v1.0）版本的发布，也发布了新的OCPP1.6 JSON架构文件。所有文件都添加了版本信息：ID字段。对于这个版本，它们被标记为："urn:OCPP:1.6:2019:12"
1.2. 术语和约定下划线：当需要澄清差异时，它们可能会被加下划线。
- 主要勘误 协议中消息、类和枚举的内容和/或定义的问题。
2.1. MeterValues.json 和 StopTransaction.json 中对“Celsius”的错误拼写
最初发布的OCPP 1.6 JSON架构消息定义集中存在一个拼写错误，导致它与书面的OCPP 1.6规范和SOAP/XML Schema/WSDL架构定义都不一致。
在MeterValues和StopTransaction消息结构（位于MeterValues.json和StopTransaction.json中），作为单位的“Celsius”被错误地拼写为：“Celcius”。
我们建议OCPP 1.6 JSON中央系统的实现者将正确的拼写（Celsius）添加到枚举中。这样，您的实现将同时支持正确和错误的拼写。如果有人正在实现OCPP1.6 JSON充电点，并使用WSDL文件生成的对象来序列化JSON，他们可能会向中央系统发送正确的拼写。
我们建议OCPP 1.6 JSON充电点的实现者修正这个拼写错误。
⚠️ 这个问题在未来的架构文件中将不会被修复，中央系统需要同时支持两种拼写。
2.2. SendLocalList.json 架构文件不正确
SendLocalList 的OCPP 1.6 JSON 架构文件不正确，因为它不是一个有效的 JSON Schema draft-04。
定义“idTagInfo”的部分不正确：“expiryDate”和“parentIdTag”应该是 properties 的一部分。
不正确的
"idTagInfo": {
"type":"object",
"expiryDate":{
"type":"string",
"format":"date-time"
}，
"parentIdTag":{
"type":"string",
"maxLength":20
}，
"properties":{
"status":{
"type":"string",
"enum":[
"Accepted",
"Blocked",
"Expired",
"Invalid",
"ConcurrentTx"
]
}
},
"required":[
"status"
]
}
正确的
"idTagInfo":{
"type":"object",
"properties":{
"expiryDate":{
"type":"string",
"format":"date-time"
},
"parentIdTag":{
"type":"string",
"maxLength":20
},
"status":{
"type":"string",
"enum":[
"Accepted",
"Blocked",
"Expired",
"Invalid",
"ConcurrentTx"
]
}
},
"required":[
"status"
]
}
将会提供一个更新的JSON Schema。当使用JSON Schema时，必须使用这个更新的Schema，因为（大多数）JSON Schema工具无法解析旧版本的Schema。
2.3. BootNotificationResponse.json的Schema文件不正确
OCPP 1.6的BootNotificationResponse的JSON Schema文件包含一个错误。字段“interval”被定义为'number'（数字），但应该被定义为'integer'（整数）。
OCPP-S的WSDL文件是正确的。
错误的
正确的
2.4. UpdateFirmware.json的Schema文件不正确
OCPP 1.6的UpdateFirmware的JSON Schema文件包含两个错误。字段“retries”（重试次数）和“retryInterval”（重试间隔）被定义为了'number'（数字），但它们应该被定义为'integer'（整数）。
OCPP-S的WSDL文件是正确的。
错误的
正确的
2.5. StopTransaction.json 中的 "reason" 字段错误地设置为必填项OCPP 1.6的JSON Schema消息定义集在最初发布时包含一个错误，导致它与OCPP 1.6书面规范以及SOAP/XML Schema/WSDL的Schema定义不一致。在StopTransactionRequest消息结构（StopTransaction.json）中，“reason”元素错误地被标记为“必填项”，而人类可读的协议规范文档和SOAP WSDL服务定义文件都明确地将它定义为“可选项”，并明确给出了一个隐含的默认值（“Local”），如OCPP 1.6规范的第4.10节（第46页）和第6.49节（第82页）所述。我们建议OCPP 1.6 JSON的实现者从文件底部的必填字段列表中移除“reason”字段，或者从OCA网站上下载正确的JSON Schema集合。根据TWG（技术工作组）的理解，只有当现有的OCPP 1.6实现中的中央系统当前强制要求接收到的JSON StopTransaction请求中的“reason”字段为“必填项”，并且它控制着一个包含使用OCPP1.6 JSON的充电点的网络，但这些充电点在StopTransaction请求中省略了“reason”字段（这是规范所允许的）时，这个更正才会影响到这些实现。
- 小的勘误 对协议（应该）如何工作的描述进行改进。
3.1. JSON Schema文件允许内部对象中存在额外的字段。在OCPP消息中添加额外的字段/值是不允许的，这可能会导致现场出现互操作性问题。WSDL文件是正确的，但原始的JSON Schema文件允许在内部对象中添加额外的字段，并在枚举中添加额外的值，这并不是预期的。
大多数JSON Schema文件已经更新以修复此问题。在所有对象和枚举定义中添加了“additionalProperties”: false 这一行。
3.2. 未定义：“无法处理消息”
OCPP 1.6规范指向OCPP-J规范以获取关于JSON实现应如何响应请求以指示“无法处理消息”的定义，但OCPP-J规范中并没有“无法处理消息”的定义。
以下文本应添加到：第9页，第3.2段：
“关于服务器应如何报告‘无法处理消息’的定义，请参见：CallError”
以下文本应添加到：第13页，第4.2.3段：
“当服务器需要报告‘无法处理消息’时，服务器应使用消息类型：CallError（MessageTypeNumber = 4）。”
3.3. 第8页，部分：3.2：缺少在接收到HTTP 404后充电点应重试的说明。
当充电点尝试连接到中央系统时，如果中央系统不认识该充电点，可能会通过返回HTTP404来拒绝连接，如第3.2节所定义。
然后，期望充电点像BootNotification一样每X次重试连接，但这一点并未指定。
在第3.2节第一个要点中添加的文本：
[cols="2,10"]（此处原文可能有遗漏或格式错误，因为通常cols="2,10"是用于指定表格列宽的，但在此上下文中没有给出具体的表格内容。如果这是指添加纯文本内容，则可能无需包含cols属性。）
（注：根据上下文，这里可能需要补充具体的文本内容来说明充电点在收到HTTP 404后应如何重试连接，但原文并未给出具体的文本内容。）
| 附加文本 | 充电点应当使用适当的退避机制重试连接，以防止对中央系统造成过载。 |
3.4. 第10页，部分：4.1.1：同步性解释可以改进
不是所有实现者都清楚，当中央系统向充电站2发送信息时，它不需要等待来自充电站1的响应。
需要在第一段末尾添加以下内容：
| 附加文本 | 这并不意味着中央系统在等待第一个充电点的响应时不能向另一个充电点发送消息，这一规则是针对每个OCPP-J连接的。 |
3.5. 第10页，第4.1.3段：“客户端到服务器”和“服务器到客户端”令人困惑。
第9页的表格包含了OCPP RPC框架中三种不同类型消息的定义。但是，方向令人困惑。在使用WebSocket时，在WebSocket层面，中央系统始终是服务器。
| 旧文本 | 新文本 |
| 方向 | 描述 |
| 客户端到服务器 | 请求消息 |
| 服务器到客户端（CALLRESULT） | 响应消息 |
| 服务器到客户端（CALLERROR） | 对请求消息的错误响应 |
3.6. 第11页，第4.2段：没有引用JSON模式
OCPP-J规范没有引用JSON模式和模式版本。
在第3页的1.6引用部分添加额外的引用：
| [JSON_SCHEMA] |
附加文本：
4.2.4 模式文件
与本文档一同提供的还有JSON模式文件。这些模式文件可用于验证OCPP-J消息。
OCPP-J 1.6模式文件是[JSON_SCHEMA]draft-04规范的模式文件。
（注：[JSON_SCHEMA] 是一个占位符，实际使用时应替换为具体的JSON模式文件的链接或引用）
3.7. 第14页，部分：4.2.3：没有CallError的示例
文档中没有CallError的示例，以下是一个示例：
[4,
"162376037",
"NotSupported",
"SendLocalList.req not implemented",
{}
]
3.8. 第15页，部分：5：解释在充电点被接受之前如何响应消息。
文档中没有解释中央系统在被充电点接受之前应该如何响应来自充电点的任何CALL消息（除了BootNotification.req之外）。
| 附加章节 | 5.6 充电点在接受前的CALL消息 当中央系统在接受充电点之前收到来自充电点的CALL消息（除了BootNotification之外），中央系统被建议以RPC CallError: SecurityError作为响应。 |
3.9. 第20页，部分：7：如何处理半开连接不清晰
有时WebSocket连接可能没有被正确打开或关闭。当这种情况发生时，WebSocket ping应该能检测到这一点并导致WebSocket被关闭。通过定期发送WebSocket pings，应该可以避免因为半开连接而丢失消息的情况。
| 附加文本 | 建议配置：WebSocketPingInterval 小于 TransactionMessageAttempts * TransactionMessageRetryInterval。 |
3.10. 第20页，部分：7：缺少配置键：AuthorizationKey
在第17页上提到了一个配置键（ConfigKey），但它在第20页上的列表中并未列出：
新文本：
| 键 | 值 |
| AuthorizationKey | 字符串 仅写入 充电站用于在使用HTTP基本身份验证时进行自我身份验证的密码的十六进制表示。最大字符串长度为40个字符。 此配置键仅可写入，以便在读取所有配置键时，中央系统不会意外地以明文形式存储它。 |
4. 错别字
错别字、对不正确链接/引用的修正，以及对所用术语的改进等，这些都不会影响协议工作方式的描述。
目前已知：无
5.已知但将不予修复的问题
5.1. 第14页，第4.2.3段：CallError：枚举中的错别字
枚举中的错别字：OccurenceConstraintViolation（应为 OccurrenceConstraintViolation）
| 旧文本 | OccurenceConstraintViolation |
| 新文本 | OccurrenceConstraintViolation |
不要修复，这是一个消息级别的更改，可能会破坏现有的实现。
注意：在OCPP的下一个版本中，我们将添加正确的拼写并将不正确的（错别字）值标记为已弃用。
5.2. 第14页，第4.2.3段。CallError：枚举中的名称错误：FormationViolation
枚举中的名称错误：FormationViolation（应为正确的名称，但此处似乎是一个错误）
| 旧文本 | FormationViolation |
| 新文本 | FormatViolation |
不要修复，这是一个消息级别的更改，可能会破坏现有的实现。
注意：在OCPP的下一个版本中，我们将添加正确的拼写，并将错误的（错别字）值标记为已弃用。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
