OCPP - 1.6 - JSON - Specification 中文 - 图文

Open Charge Point Protocol JSON 1.6,

OCPP-J 1.6 Specification

1

目录

1.

简介 .......................................................................................................................................... 4 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 2. 3.

本文件的目的 ............................................................................................................... 4 目标观众....................................................................................................................... 4 OCPP-S and OCPP-J ........................................................................................................ 4 协议 .............................................................................................................................. 4 定义及缩写................................................................................................................... 5 文献 .............................................................................................................................. 6

效益与问题 .............................................................................................................................. 7 连接 .......................................................................................................................................... 7 3.1.

客户端请求................................................................................................................... 7 3.1.1. 3.1.2. 3.1.3. 3.2. 3.3.

连接URL ........................................................................................................... 7 OCPP 版本 ........................................................................................................ 8 一个开放的HTTP请求的例子 ........................................................................ 9

服务器响应................................................................................................................... 9 更多信息..................................................................................................................... 10

4. RPC框架 ..................................................................................................................................... 10

4.1. 介绍 ............................................................................................................................ 10

4.1.1. Synchronicity 同步性 ........................................................................................ 11 4.1.2. 字符编码 ............................................................................................................. 11 4.1.3．消息类型 ............................................................................................................ 11 4.2. 用于不同消息类型的消息结构 ..................................................................................... 12

4.2.1. CALL ....................................................................................................................... 12 4.2.2. CallResult ............................................................................................................ 13 4.2.3. CallError ................................................................................................................ 14

5． 连接 ........................................................................................................................................ 17

5.1. 压缩 .............................................................................................................................. 17 5.2. 数据的完整性 ................................................................................................................ 17 5.3. WebSocket Ping与OCPP的Heartbeat ....................................................................... 17

2

5.4. 重新连接 ...................................................................................................................... 18 5.5. 网络节点的层次结构 ................................................................................................... 18 6. 安全 ........................................................................................................................................... 18

6.1. Network-level security 网络级安全 ............................................................................ 18 6.2. OCPP-J over TLS ............................................................................................................. 18

6.2.1. 加密 ................................................................................................................... 19 6.2.2. 充电点认证 ......................................................................................................... 19 6.2.3. 它的安全性和不安全性 ...................................................................................... 23 6.2.4. 适用于OCPP-S ..................................................................................................... 23

7. 配置 ........................................................................................................................................... 24

3

1. 简介

1.1. 本文件的目的

本文档的目的是向读者提供创建正确信息所需的信息。

JSON实现互操作的开放充电协议（OCPP-J）。我们将试图解释什么是强制性的，什么是好的做法和不应该做的，根据我们自己的经验。毫无疑问误解或含糊不清仍然存在，但通过本文件，我们的目的是尽可能防止他们。

1.2. 目标观众

本文件的目的是为开发人员希望了解一个和/或实现OCPP JSON正确互操作方式。在服务器上实现Web服务的基本知识假定嵌入式设备。

1.3. OCPP-S and OCPP-J

随着介绍OCPP 1.6，有两种不同味道的OCPP下基于SOAP协议实现，有可能使用更紧凑的JSON替代方案。为了避免混乱，在通信的类型实现我们建议使用不同的后缀j和s表示JSON或SOAP。一般来说， OCPP-J表示JSON和OCPP-S来表示SOAP。特定版本的术语将OCPP1.6J或OCPP1.2S。如果没有后缀规定是OCPP1.2或1.5,那么必须实现SOAP。从版本1.6来看，这不再是隐式的并应该永远清楚。如果一个系统同时支持JSON和SOAP变量，则此版本则被认为是好的标签OCPP1.6JS而不是OCPP1.6。

本文档介绍了OCPP-J，如果想了解OCPP-S请查看文档：[ OCPP_IMP_S ]

1.4. 协议

本文件中的“必须”、“不得”、“必要”、“应当”、“不应该” “建议”、“可能”和“可选” 等关键词应将被解释如在[ RFC2119 ]所描述的一样。

4

1.5. 定义及缩写

IANA 因特网编号管理局 （www.iana.org） OCPP-J OCPP在使用JSON的Web Socket通信。 具体的OCPP版本上应注明J延伸。ocpp1.5j意味着我们正在谈论1.5的JSON / WebSocket实现。 OCPP-S OCPP communication over SOAP and HTTP(S). As of version 1.6 this should explicitly mentioned. Older versions are assumed to be S unless clearly specified otherwise, e.g. OCPP1.5 is the same as OCPP1.5S OCPP通信在SOAP和HTTP（S）。由于版本1.6中应该明确提到。除非清楚另有规定，旧版本假定为S，如ocpp1.5是和ocpp1.5s一样的 RPS WAMP 远程过程调用 服务器是一个开放的WebSocket协议来提供消息传递模式来处理异步数据。

5

1.6. 文献

[JSON] [OCPP_IMP_S] [RFC2119] http://www.json.org/ OCPP SOAP implementation specification “Key words for use in RFCs to Indicate Requirement Levels”. S. Bradner. March 1997. http://www.ietf.org/RFC/RFC2119.txt [RFC2616] “Hypertext Transfer Protocol?—?HTTP/1.1”. http://tools.ietf.org/html/RFC2616 [RFC2617] “HTTP Authentication: Basic and Digest Access Authentication”. http://tools.ietf.org/html/RFC2617 [RFC3629] “UTF-8, a transformation format of ISO 10646”. http://tools.ietf.org/html/RFC3629 [RFC3986] “Uniform Resource Identifier (URI): Generic Syntax”. http://tools.ietf.org/html/RFC3986 [RFC5246] “The Transport Layer Security (TLS) Protocol; Version1.2”. http://tools.ietf.org/html/RFC5246 [RFC6455] “The WebSocket Protocol”. http://tools.ietf.org/html/RFC6455 [WAMP] [WIKIWS] [WS]

6

http://wamp.ws/ http://en.wikipedia.org/wiki/WebSocket http://www.websocket.org/ 2. 效益与问题

Web Socket协议在【RFC6455】里有定义。早期的草案工作实现Web-Socket规范的存在，但OCPP-J实现使用在 [ RFC6455]描述的协议。

注意，WebSocket TCP之上的定义自己的消息结构。在TCP级别，通过WebSocket发送的数据，被包裹在一个WebSocket帧头。使用框架时，这是完全透明的。然而对于一个嵌入式系统工作时， WebSocket图书馆不可用并且她/他必须依据[RFC6455] 正确地框架信息。

3. 连接

用OCPP-J连接一个充电点和一个中央系统，中央系统扮演一个WebSocket服务器，充电点扮演WebSocket客户端。

3.1. 客户端请求

建立一个连接，充电点启动一个WebSocket连接如在[ RFC6455 ] 第4节“所描述的：开场握手”。

OCPP-J在URL和WebSocket子协议施加额外的约束，在下面的4.1.1和4.1.2这两个部分会详细介绍。

3.1.1. 连接URL

为了启动一个WebSocket连接，充电点需要一个URL（[ RFC3986 ]）连接。这个URL从此被称为“连接URL”。这个连接URL是特定于充电点的。充电点的连接URL包含充电点身份使中枢系统知道充电点属于哪一个WebSocket连接。

支持OCPP-J的中央系统必须至少提供一个OCPP-J端点URL，从该点电荷应该得到它的URL连接。这OCPP-J端点URL可以是任何以“ws”或“wss”方案URL。充电点如何获得OCPP-J端点URL不是本文档的范围。

为了得到连接URL，充电点通过添加到路径“/”， 然后识别唯一地充电点串来修改OCPP-J端点URL（U + 002f固相线）。这种独特的标识字符串必须成编码如在 [RFC3986 ] 描述中一样有必要。

7

例1：身份为”CP001”的一个点电荷连接到一个中央系统OCPP-J端点URL”ws://centralsystem.example.com/ocpp”这会给出下面的连接URL： ws://centralsystem.example.com/ocpp/CP001

例2：身份为“RDAM123”的一个点电荷连接到一个中央系统OCPP-J端点URL wss://centralsystem.example.com/ocppj”这将给以下网址： wss://centralsystem.example.com/ocppj/RDAM 123

3.1.2. OCPP 版本

精确的OCPP版必须在SEC- WebSocket协议字段指定。这应该是下列值之一： 表1：OCPP版本 版本 1.2 1.5 1.6 2.0

对于OCPP1.2，1.5和2.0是官方WebSocket子协议名称的值。他们本身注册在因特网编号管理局。

注意：OCPP1.2和1.5在列表中。由于WebSocket解决方案中的JSON是独立的实际消息内容，所以也可用于旧版本OCP。请记住，在这些情况下，实现还应该保持对基于SOAP的解决方案的支持，以便互操作。

将OCPP版包含在OCPP-J端点URL字符串的一部分是很好的实践。如果你运行一个Web服务，可以在同一个OCPP-J端点URL处理多个OCPP版本，这是没有必要的课程。

8

Websocket 子协议名称 OCPP1.2 OCPP1.5 OCPP1.6 OCPP2.0

3.1.3. 一个开放的HTTP请求的例子

以下是一个OCPP-J连接握手的开放HTTP请求的例子： GET /webServices/ocpp/CP3211 HTTP/1.1

Host: some.server.com:33033 Upgrade: websocket Connection: Upgrade

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: ocpp1.6, ocpp1.5 Sec-WebSocket-Version: 13

黑体部分是在每一个WebSocket握手请求时会出现，其他部分都是具体的例子。 在

这

个

例

子

中

，

中

央

系

统

的

OCPP-J

端

点

URL

是

\。充电点的唯一标识符”CP3211”，因此请求路径为\。

根据sec- WebSocket 协议报头，充电点在这里显示，它可以使用OCPP1.6J和OCPP1.5J，更偏向于前者。

在这个例子中，另一头是HTTP和WebSocket协议的一部分，与那些实施OCPP-J除第三方WebSocket库之外无关。这些标题的作用在[RFC2616] 和 [RFC6455]中有解释。

3.2. 服务器响应

在接收充电点的要求，中央系统与响应完成握手如在[RFC6455] 描述。 以下为OCPP-J-specific申请条件：

? 如果中央系统不能识别URL路径中的点电荷标识符，它应该发送状态404的HTTP响应

和中断WebSocket连接如在[ RFC6455 ]所描述。

? 如果中央系统不同意使用一个由客户提供的子协议，它必须与一个反应不一秒

WebSocket协议头，然后立即关闭WebSocket连接完整的WebSocket握手。

所以如果中央系统接受上述例子的要求并且同意使用充电点OCPP1.6J，中央系统的响应将如下所示：

9

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade

Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: OCPP1.6

黑体部分是在每一个WebSocket握手响应中找到，其他部分都是具体的例子。 Sec-Web Socket-Accept的作用在[ RFC6455 ]中有解释。 SEC -WebSocket协议头指示服务器将在此连接使用OCPP1.6J。

3.3. 更多信息

对于那些做自己实现WebSocket握手的，[WS]和[ WIKIWS ]给更多关于WebSocket协议的信息。

4. RPC框架

4.1. 介绍

一个WebSocket是一个全双工连接，简单来说就是数据可以从管道中的进出，进出之间没有明确的关系。根据请求和响应，WebSocket协议本身没有提供任何方法与消息。对这些请求/响应关系，我们需要在顶部的WebSocket有个小协议。这个问题发生在WebSocket更多的案例，所以有现有的方案去解决它。使用最广泛的是WAMP（见[WAMP]）。但随着现有的版本框架处理RPC不是WAMP兼容当前版本。由于所需的框架很简单我们决定定义自己的框架，受到WAMP的启发，删除了我们不需要的并加上了我们发现所丢失的。

基本上，我们需要的是非常简单的：我们需要发送一个消息（电话）和收到回复（callresult）或解释为什么信息不能妥善处理（callerror）。对于未来可能的兼容性我们将对这些消息进行编号同步服务器。我们实际的OCPP消息将被放入一个至少包含消息的类型的包装，一个独特的消息ID和有效载荷，该OCPP消息本身。

10

successfully 发生内部错误，接收方无法成功处理请求的Action。 ProtocolError SecurityError Payload for Action is incomplete Action的Payload是不完整的 During the processing of Action, a security issue occurred preventing receiver from completing the Action successfully 在处理Action过程中，发生了一个安全问题，成功地阻止接收方完成Action。 FormationViolation Payload for Action is syntactically incorrect or not conform the PDU structure for Action Action的Payload在语法上是不正确的或不合格的PDU结构 PropertyConstraintViolation Payload is syntactically correct but at least one field contains an invalid value Payload在语法上是正确的，但至少在一个领域中包含无效值 OccurenceConstraintViolation Payload for Action is syntactically correct but at least one of the fields violates occurence constraints Payload在语法上是正确的，但是至少一个领域违反发生限制 TypeConstraintViolation 16

Payload for Action is syntactically correct but at least one of the fields violates data type constraints (e.g. “somestring”: 12) Action的Payload在语法上是正确的，但是至少一个领域违反数据类型的限制（如“somestring”：12） GenericError Any other error not covered by the previous ones 前一种未涵盖的任何其他错误

5． 连接

5.1. 压缩

由于JSON非常紧凑，作为WebSocket [ RFC6455 ]规范的一部分，我们不建议以其他任何形式使用压缩而是允许，否则可能危及互操作性。

5.2. 数据的完整性

对于数据完整性，我们依赖于底层TCP/IP传输层机制。

5.3. WebSocket Ping与OCPP的Heartbeat

WebsSocket规范定义了Ping和Pong帧，Ping和Pong是用来检查远程端点仍能响应。在实践中，这种机制还可以防止网络操作员在某一段不活动之后悄悄关闭底层网络连接。这WebSocket功能可以用于大多数的OCPPHeartbeat信息的替代品，但不能代替其所有功能。 Heartbeat响应的一个重要方面是时间同步。ping和Pong帧不能用于此，因此建议每天至少有一条原始Heartbeat，以确保在充电点上设置正确的时钟设置。

17

5.4. 重新连接

当重新连接一个充电点时，不应该发送一个Bootnotification，除非Bootnotification一个或更多的元素自上次联系已经发生变化。以往的基于SOAP的解决方案，这被认为是好的做法，然而当使用WebsSocket时，服务器已经在认同和沟通渠道之间匹配，与此同时，已经建立连接，不需要附加信息。

5.5. 网络节点的层次结构

物理网络拓扑不受JSON或SOAP选择的影响。然而，在JSON的情况下，网络地址转换（NAT）的问题通过让充电点打开与中央系统连接的TCP来解决，并保持这种连接打开，由中央系统发起沟通。因此，不再需要有一个能够解释和重定向中央系统和充电点之间的SOAP调用的智能设备。

6. 安全

OCPP-J安全存在两种方法.一个可以依靠的Network-level security（网络级安全），或者使用OCPP-J over TLS（优于TLS 的OCPP-J）。下面描述这两种方法：

重要的是，在任何时候，都可以使用其中任何一种方法。实际上，这意味着中央系统不应该侦听传入连接互联网上的未加密的OCPP-J。

6.1. Network-level security 网络级安全

为了安全，the security at a network level可以依赖网络级别上的安全性。历史上OCPP-S一直是这么做的，网络上，适当的设置也可以使用没有额外的加密或认证措施的OCPP-J.

6.2. OCPP-J over TLS

然而，有时充电站和中央系统之间没有安全的网络。在这种情况下，就可以使用OCPP-J over TLS。本节解释这是如何完成的。

OCPP通信需要的安全实际上是两个独立的功能：加密和充电点认证。

18

加密意味着OCPP消息进行加密，所以只有经授权的第三方才可以看到交换的消息。 充电点认证是指中央系统可以对充电点的身份进行验证，以致经授权的第三方可以假装为充电点，并向中心系统发送恶意消息。

6.2.1. 加密

互联网上的加密的行业标准是传输层安全Transport Layer Security (TLS) [RFC5246]。 因此OCPP也采用加密的中央系统和充电点之间的连接协议。有WebSocket的 TLS有库图书的广泛支持，客户应该比使用未加密的WebSocket更难。

当使用TLS时，中央系统也可以提供一个充电点可以用来验证中央系统的身份签名凭证。 由于一些充电点实现使用有限的计算资源的嵌入式系统，我们对服务器端的TLS配置施加了额外的限制：

?TLS证书应为RSA证书，其大小不大于2048字节。

6.2.2. 充电点认证

对于认证，OCPP-J over TLS使用HTTP基本认证方案（[ RFC2617 ]）。可以使用相对简单的HTTP基本身份验证，因为连接已经TLS加密，因此不需要第二次加密凭据。

当使用HTTP基本身份验证时，客户，比如充电点，必须根据请求提供用户名和密码。用户名等于充电点身份，这是识别充电点的字符串作为它用它在OCPP-J连接URL。密码则是存储在充电点上的20字节密钥。 例子：

如果我们有一个充电点： ? 充电点身份“AL1000”

? authorization key 授权密钥 0001020304050607FFFFFFFFFFFFFFFFFFFFFFFF

the HTTP authorization header should be: HTTP授权标头应该是： Authorization: Basic QUwxMDAwOgABAgMEBQYH////////////////

19

关于加密的一点注记：

通过HTTP基本身份验证的认证机制将用于TLS加密连接。在未加密的连接使用这种机制意味着任何可以看到充电点与中心系统中网络流量的人也可以看到充电点凭据，因此可以模拟充电点。 设置充电点的凭证

对于这个充电点认证方案，充电点需要有一个认证密钥。这个认证密钥必须以某种方式传输到充电点。什么是好方法取决于充电点制造商和中央系统运营商的商业模式。 安装期间或安装前的设置

理想的安全情况是每个充电点都有自己独特的授权密钥。如果授权密钥是不唯一的，攻击者发现一个充电点的授权密钥可以模仿在运营商的中央系统的许多甚至所有充电点。 实现这一点最简单的方法是在制造或安装过程中在充电点上安装授权密钥。在这种情况下，通过沟通渠道，密钥将安全地在中央系统运营商和系统安装程序或制造商之间传递，除OCPP以外。这种情况下是安全的，因为密钥是不要通过所谓的安全发送，所以攻击者窃听连接之间的充电点与中心系统，不能模拟充电点。 设置密钥 over OCPP

如果一个充电点的制造、销售和安装过程不在中央系统操作员的控制之下，就不可能在每个充电点上安装唯一的钥匙。还要确保中央系统操作员知道这些钥匙和它们所属的充电点。对于这样的场景，当一个系列的所有充电点离开工厂并安装时，都有相同的“主”键，或者使用相同的算法从充电点标识导出密钥，这是可取的。如果主密钥被泄露，中央系统运营商会让对手模仿一系列的所有充电点。在这种情况下，充电点安装后，有一种可能性就是通过OCPP，充电点发送一个特殊密钥给中枢系统。

通过OCPP来设置一个充电点的授权密钥，中央系统将给充电点发送changeconfiguration.req

20

消息与关键的AuthorizationKey和作为价值的40个字符十六进制和20字节授权密钥的表示法。如果充电点响应ChangeConfiguration.req与changeconfiguration.conf 为Accepted，中央系统应假定授权密钥更改成功，并且不再接受以前由收费点使用的凭据。如果充电点响应ChangeConfiguration.req与changeconfiguration.conf状态为Rejected 或者NotSupported，中央系统应当接受旧的凭据。而中央系统仍然要接受这样一个OCPP-J充电点连接，它可以不同对待充电点的OCPP信息，如不接受充电点的启动通知

21

充电点不应该归还授权密钥来回应getconfiguration请求。它要么不可以报告

authorizationkey要么归还与实际的授权密钥不相关的值。

请注意，虽然在通道上要安全地发送一个密钥通常被认为是不好的做法，我们认为在这里至少应该提供这样做的可能性。通常，当中央系统上的“充电点”首次登机时，将设置授权密钥。如果充电点后来产生了在登机时设置的钥匙，至少意味着这是在登机过程中连接的相同的系统。虽然它可能给知道所有新的电荷点单“主”键的对手成功登机了一个伪造的新的充电点，它是不可能假装已经安装和运行充电点。这仍使得许多无法想象的攻击成为可能： 通过对被标记为占用的消息进行欺骗来对收费点进行“保留” 将你刚开始的会议标记在公共充电点上，这样你就不必付那么多钱了。

发送许多欺骗性的交易，和（或）已经登上充电点的错误来混淆中央系统操作员的操作 用另一个人的id给中枢系统产生经济损失的id的主人发送伪造的交易

建议中央系统操作员使得设置一个充电点授权密钥为充电点登机程序的一部分，使用新的OCPP1.6 待定值Pending value在bootnotification.conf登记状况。新连接的充电点在第一个bootnotification.conf，将首先得到一个Pending待注册状态。中央系统将设置带有changeconfiguration.req充电点独特授权密钥。只有当这个ChangeConfiguration.req已经回应了一个状态接受changeconfiguration.conf，中央系统将响应与接受登记状态启动通知。 建议中央系统操作员检查新连接充电点的异常情况。因此，他可以尝试检测攻击者是否窃取了主密钥或密钥派生算法，以及已登记的充电点身份的列表。例如，如果新充电点连接的速率突然增加，这可能意味着攻击。

存储的凭据

22

重要的是，凭据必须以不易丢失或重置的方式存储在充电点上。如果凭据被丢失、删除或更改，则充电点不能连接到中央系统，并需要现场服务来安装新凭据。

对中枢系统这方面来说，建议存储授权密钥散列，用一种独特的“salt”，使用加密哈希算法设计的安全存储密码。这确保了如果包含充电点的授权密钥的数据库被泄露了，攻击者仍然不能对中央系统的充电点进行身份验证。

6.2.3. 它的安全性和不安全性

这些安全措施的范围仅限于对充电点和中央系统之间的连接的认证和加密。它没有解决电动汽车充电过程中的每一个当前安全问题。 它确实提供了以下内容：

? 对中央系统的充电点的认证（使用HTTP基本身份验证） ? 充电点与中心系统之间的连接的加密 ? 中央系统对充电点的认证（使用TLS证书）

它不提供：

? 保证电表值不受电表和中央系统之间的干扰。 ? 对司机的认证 ? 防止人为篡改充电点

6.2.4. 适用于OCPP-S

在对OCPP-J over TLS方法不能应用于OCPP-S的原因有二。

首先，在OCPP-S中，新的TCP连接为每个请求-响应交换创造。因此，每一个这样的请求-响应交换都需要执行一个新的TLS握手，这会带来很大的带宽开销。

其次，在OCPP-S，充电点也作为一个服务器，因此就需要一个服务器证书。追踪如此多的服务器证书和它们所属的收费点将是一个巨大的行政负担。

23

7. 配置

下列项目在OCPP Get/ changeconfiguration消息添加到控制JSON / WebSockets行为： 表8：附加OCPP的Key：

Key WebSocketPingInterval Value integer A value of 0 disables client side websocket Ping / Pong. In this case there is either no ping /pong or the server initiates the ping and client responds with Pong. Positive values are interpreted as number of seconds between pings. Negative values are not allowed. ChangeConfiguration is expected to return a REJECTED result. 整数值为0禁用客户端WebSocket Ping/ Pong。在这种情况下，不存在ping /Pong或服务器启动ping，而客户机响应Pong。正值解释为Ping之间的秒数。不允许负值。 changeconfiguration有望返回一个拒绝的结果。

24

本文来源：https://www.bwwdw.com/article/pmxp.html