OCPP-1.6-JSON-Specification-中文

('OpenChargePointProtocolJSON1.6,OCPP-J1.6Specification1目录1.简介..........................................................................................................................................31.1.本文件的目的..............................................................................................................31.2.目标观众......................................................................................................................31.3.OCPP-SandOCPP-J.......................................................................................................31.4.协议..............................................................................................................................31.5.定义及缩写..................................................................................................................31.6.文献..............................................................................................................................42.效益与问题..............................................................................................................................53.连接..........................................................................................................................................63.1.客户端请求..................................................................................................................63.1.1.连接URL...........................................................................................................63.1.2.OCPP版本.........................................................................................................63.1.3.一个开放的HTTP请求的例子.........................................................................73.2.服务器响应..................................................................................................................73.3.更多信息......................................................................................................................84.RPC框架.......................................................................................................................................84.1.介绍.................................................................................................................................84.1.1.Synchronicity同步性.............................................................................................84.1.2.字符编码................................................................................................................94.1.3．消息类型..............................................................................................................94.2.用于不同消息类型的消息结构........................................................................................94.2.1.CALL.........................................................................................................................94.2.2.CallResult..............................................................................................................104.2.3.CallError................................................................................................................115．连接.........................................................................................................................................125.1.压缩................................................................................................................................125.2.数据的完整性.................................................................................................................135.3.WebSocketPing与OCPP的Heartbeat..........................................................................135.4.重新连接........................................................................................................................135.5.网络节点的层次结构.....................................................................................................136.安全............................................................................................................................................1326.1.Network-levelsecurity网络级安全................................................................................136.2.OCPP-JoverTLS...............................................................................................................146.2.1.加密.....................................................................................................................146.2.2.充电点认证..........................................................................................................146.2.3.它的安全性和不安全性.......................................................................................176.2.4.适用于OCPP-S......................................................................................................177.配置............................................................................................................................................1731.简介1.1.本文件的目的本文档的目的是向读者提供创建正确信息所需的信息。JSON实现互操作的开放充电协议（OCPP-J）。我们将试图解释什么是强制性的，什么是好的做法和不应该做的，根据我们自己的经验。毫无疑问误解或含糊不清仍然存在，但通过本文件，我们的目的是尽可能防止他们。1.2.目标观众本文件的目的是为开发人员希望了解一个和/或实现OCPPJSON正确互操作方式。在服务器上实现Web服务的基本知识假定嵌入式设备。1.3.OCPP-SandOCPP-J随着介绍OCPP1.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]所描述的一样。41.5.定义及缩写IANA因特网编号管理局（www.iana.org）OCPP-JOCPP在使用JSON的WebSocket通信。具体的OCPP版本上应注明J延伸。ocpp1.5j意味着我们正在谈论1.5的JSON/WebSocket实现。OCPP-SOCPPcommunicationoverSOAPandHTTP(S).Asofversion1.6thisshouldexplicitlymentioned.OlderversionsareassumedtobeSunlessclearlyspecifiedotherwise,e.g.OCPP1.5isthesameasOCPP1.5SOCPP通信在SOAP和HTTP（S）。由于版本1.6中应该明确提到。除非清楚另有规定，旧版本假定为S，如ocpp1.5是和ocpp1.5s一样的RPS远程过程调用WAMP服务器是一个开放的WebSocket协议来提供消息传递模式来处理异步数据。51.6.文献[JSON]http://www.json.org/[OCPP_IMP_S]OCPPSOAPimplementationspecification[RFC2119]“KeywordsforuseinRFCstoIndicateRequirementLevels”.S.Bradner.March1997.http://www.ietf.org/RFC/RFC2119.txt[RFC2616]“HypertextTransferProtocol—HTTP/1.1”.http://tools.ietf.org/html/RFC2616[RFC2617]“HTTPAuthentication:BasicandDigestAccessAuthentication”.http://tools.ietf.org/html/RFC2617[RFC3629]“UTF-8,atransformationformatofISO10646”.http://tools.ietf.org/html/RFC3629[RFC3986]“UniformResourceIdentifier(URI):GenericSyntax”.http://tools.ietf.org/html/RFC3986[RFC5246]“TheTransportLayerSecurity(TLS)Protocol;Version1.2”.http://tools.ietf.org/html/RFC5246[RFC6455]“TheWebSocketProtocol”.http://tools.ietf.org/html/RFC6455[WAMP]http://wamp.ws/[WIKIWS]http://en.wikipedia.org/wiki/WebSocket[WS]http://www.websocket.org/62.效益与问题WebSocket协议在【RFC6455】里有定义。早期的草案工作实现Web-Socket规范的存在，但OCPP-J实现使用在[RFC6455]描述的协议。注意，WebSocketTCP之上的定义自己的消息结构。在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-J7端点URL（U+002f固相线）。这种独特的标识字符串必须成编码如在[RFC3986]描述中一样有必要。例1：身份为”CP001”的一个点电荷连接到一个中央系统OCPP-J端点URL”ws://centralsystem.example.com/ocpp”这会给出下面的连接URL：ws://centralsystem.example.com/ocpp/CP001例2：身份为“RDAM123”的一个点电荷连接到一个中央系统OCPP-J端点URLwss://centralsystem.example.com/ocppj”这将给以下网址：wss://centralsystem.example.com/ocppj/RDAM%201233.1.2.OCPP版本精确的OCPP版必须在SEC-WebSocket协议字段指定。这应该是下列值之一：表1：OCPP版本版本Websocket子协议名称1.2OCPP1.21.5OCPP1.51.6OCPP1.62.0OCPP2.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版本，这是没有必要的课程。83.1.3.一个开放的HTTP请求的例子以下是一个OCPP-J连接握手的开放HTTP请求的例子：GET/webServices/ocpp/CP3211HTTP/1.1Host:some.server.com:33033Upgrade:websocketConnection:UpgradeSec-WebSocket-Key:x3JJHMbDL1EzLkh9GBhXDw==Sec-WebSocket-Protocol:ocpp1.6,ocpp1.5Sec-WebSocket-Version:13黑体部分是在每一个WebSocket握手请求时会出现，其他部分都是具体的例子。在这个例子中，中央系统的OCPP-J端点URL是"ws://some.server.com:33033/webServices/ocpp"。充电点的唯一标识符”CP3211”，因此请求路径为"webServices/ocpp/CP3211"。根据sec-WebSocket协议报头，充电点在这里显示，它可以使用OCPP1.6J和OCPP1.5J，更偏向于前者。在这个例子中，另一头是HTTP和WebSocket协议的一部分，与那些实施OCPP-J除第三方WebSocket库之外无关。这些标题的作用在[RFC2616]和[RFC6455]中有解释。3.2.服务器响应在接收充电点的要求，中央系统与响应完成握手如在[RFC6455]描述。以下为OCPP-J-specific申请条件：\uf06c如果中央系统不能识别URL路径中的点电荷标识符，它应该发送状态404的HTTP响应和中断WebSocket连接如在[RFC6455]所描述。\uf06c如果中央系统不同意使用一个由客户提供的子协议，它必须与一个反应不一秒WebSocket协议头，然后立即关闭WebSocket连接完整的WebSocket握手。所以如果中央系统接受上述例子的要求并且同意使用充电点OCPP1.6J，中央系统的响应将如下所示：HTTP/1.1101SwitchingProtocols9Upgrade:websocketConnection:UpgradeSec-WebSocket-Accept:s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Sec-WebSocket-Protocol:OCPP1.6黑体部分是在每一个WebSocket握手响应中找到，其他部分都是具体的例子。Sec-WebSocket-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消息本身。104.1.1.Synchronicity同步性一个充电点或中央系统不应该向另一方发送呼叫信息，除非它之前发送的所有呼叫消息已被回复或超时。一个电话的消息已经回应了，当callerror或callresult消息已收到了调用消息的消息ID。当出现以下情况是会出现消息回复超时：\uf06c已经回复过\uf06c自发送消息以来，依赖于实现的超时间隔已经过去了。实现可以自由选择此超时间隔。建议他们考虑某种与另一方通信的网络。移动网络通常比固定线路有更长的最坏情况往返时间。注意：上述规定不排除当充电点或中心系统在等待一个callerror或callresult时，会接收对方呼叫的信息。这种情况很难预防，因为双方的通话信息总是相互交叉的。4.1.2.字符编码所有的信息包括包装和有效载荷的必须是有效的JSON与UTF-8编码（见[RFC3629]）的字符编码。请注意，所有有效的US-ASCII文本也是有效的UTF-8，所以如果一个系统只发送US-ASCII文本，它发送的所有信息符合UTF-8的要求。一个充电点或中央系统应该只使用字符不是US-ASCII发送自然语言文本。这样的自然语言文本的一个例子是在OCPP2.0中localizedtext型文本。4.1.3．消息类型为了标识消息的类型，必须使用以下消息类型号之一。表2：消息类型11消息类型编号方向CALL2CLIENT-TO-SERVERCALLRESULT3SERVER-TO-CLIENTCALLERROR4SERVER-TO-CLIENT当服务器收到一个消息，该列表中没有消息类型号时，它将忽略消息有效负载。每个消息类型可能有额外的必填字段。4.1.4.ThemessageID消息ID消息ID用于标识请求。一个CALL消息ID必须不同于所有以前通过同一个websocket连接发送CALL消息的消息ID，消息ID为callresult或callerror消息必须等于响应该CALL消息的callresult或callerror消息。表3：特殊消息ID名称数据类型限制消息ID串最大为36字允许GUIDS4.2.用于不同消息类型的消息结构注意：在下面的段落中，您可能会发现充电点标识丢失。WebSocket连接握手过程中，标识被交换，也是一种连接的属性。每个消息都是由这个标识发送或指向的。因此，没有必要在每条消息中重复。4.2.1.CALLCALL总是包含4个要素：标准的元素message和uniqueID，另一方需要的具体ACTION，payload，Action的论据。调用的语法如下所示：[,"","",{}]表4：CALL领域领域意义12Uniqueid这是一个惟一的标识符，用于匹配请求和结果Action远程过程或操作的名称。这将是一个区分大小写的字符串，它包含与SOAP消息中的动作字段相同的值，没有前面的斜杠。PayloadPayload是一个JSON对象，包含与Action相关的参数。如果没有Payload，JSON允许两种不同的符号：null或空对象\\{}。虽然看起来很琐碎，但我们认为只使用空对象语句是好习惯。null通常表示未定义的事物，这与空的不同，而且\\{}比较短。例如，一个Bootnotification请求可能看起来像这样：[2,"19223201","BootNotification",{"chargePointVendor":"VendorX","chargePointModel":"SingleSocketCharger"}]4.2.2.CallResult如果CALL能正确处理，其结果将是一个普通callresult。被OCPP响应所覆盖的错误情况在此文中是不被考虑在内的。他们是正规的结果这样会被视为正常的callresult，即使结果是不可取的。一个callresult总是包含3个要素：标准的元素messagetypeidUniqueId和Payload，包含在原来的呼叫响应的Action。调用的语法如下所示：[,"",{}]表5：CALLRESULT领域领域意义13UniqueID这必须是调用请求中完全相同的ID，以便接收方能够匹配请求和结果。PayloadPayload是一个JSON对象，包含Action动作的结果。如果没有Payload，JSON允许两种不同的符号：null或空对象\\{}。虽然看起来微不足道,但我们考虑只使用空对象语句是很好的实践。null通常表示未定义的事物，这与空的不同，并且也是\\{}比较短。例如，一个bootnotification响应可能看起来像这样：[3,"19223201",{"status":"Accepted","currentTime":"2013-02-01T20:53:32.486Z","heartbeatInterval":300}]4.2.3.CallError我们在两种情况下只使用callerror：在传输消息期间发生错误。这可能是一个网络问题，一个可用的服务问题，等等。接收到该调用，但该调用的内容不符合适当消息的要求。这可能缺少强制性字段，现有的具有相同唯一标识符的调用是已经处理，唯一标识符太长，等等。一个callerror总是包含5个要素：标准的元素messagetypeid和UniqueID，一个错误代码字符串(errorcodestring)，一个错误描述字符串(errordescriptionstring)和一个errordetails对象。调用的语法如下所示：[,"","","",{}]表6：CALLERROR领域领域意义14UniqueId这必须是调用请求中完全相同的ID，以便接收方能够匹配请求和结果。ErrorCode该字段必须包含以下字符串错误代码表ErrorDescription如果可能，应填写，否则为空字符串“”。ErrorDetails这个JSON对象以未定义的方式描述错误细节。如果没有错误详细信息，则必须填写一个空对象{}。表7：ValidErrorCodes有效的错误代码ERRORCODE错误代码描述descriptionNotImplemented未实现RequestedActionisnotknownbyreceiver请求的操作没有被接收NotSupportedRequestedActionisrecognizedbutnotsupportedbythereceiver被请求的操作被认可，但接收方不支持。InternalErrorAninternalerroroccurredandthereceiverwasnotabletoprocesstherequestedActionsuccessfully发生内部错误，接收方无法成功处理请求的Action。ProtocolErrorPayloadforActionisincompleteAction的Payload是不完整的SecurityErrorDuringtheprocessingofAction,asecurityissueoccurredpreventingreceiverfrom15completingtheActionsuccessfully在处理Action过程中，发生了一个安全问题，成功地阻止接收方完成Action。FormationViolationPayloadforActionissyntacticallyincorrectornotconformthePDUstructureforActionAction的Payload在语法上是不正确的或不合格的PDU结构PropertyConstraintViolationPayloadissyntacticallycorrectbutatleastonefieldcontainsaninvalidvaluePayload在语法上是正确的，但至少在一个领域中包含无效值OccurenceConstraintViolationPayloadforActionissyntacticallycorrectbutatleastoneofthefieldsviolatesoccurenceconstraintsPayload在语法上是正确的，但是至少一个领域违反发生限制TypeConstraintViolationPayloadforActionissyntacticallycorrectbutatleastoneofthefieldsviolatesdatatypeconstraints(e.g.“somestring”:12)Action的Payload在语法上是正确的，但是至少一个领域违反数据类型的限制（如“somestring”：12）GenericErrorAnyothererrornotcoveredbythepreviousones前一种未涵盖的任何其他错误165．连接5.1.压缩由于JSON非常紧凑，作为WebSocket[RFC6455]规范的一部分，我们不建议以其他任何形式使用压缩而是允许，否则可能危及互操作性。5.2.数据的完整性对于数据完整性，我们依赖于底层TCP/IP传输层机制。5.3.WebSocketPing与OCPP的HeartbeatWebsSocket规范定义了Ping和Pong帧，Ping和Pong是用来检查远程端点仍能响应。在实践中，这种机制还可以防止网络操作员在某一段不活动之后悄悄关闭底层网络连接。这WebSocket功能可以用于大多数的OCPPHeartbeat信息的替代品，但不能代替其所有功能。Heartbeat响应的一个重要方面是时间同步。ping和Pong帧不能用于此，因此建议每天至少有一条原始Heartbeat，以确保在充电点上设置正确的时钟设置。5.4.重新连接当重新连接一个充电点时，不应该发送一个Bootnotification，除非Bootnotification一个或更多的元素自上次联系已经发生变化。以往的基于SOAP的解决方案，这被认为是好的做法，然而当使用WebsSocket时，服务器已经在认同和沟通渠道之间匹配，与此同时，已经建立连接，不需要附加信息。5.5.网络节点的层次结构物理网络拓扑不受JSON或SOAP选择的影响。然而，在JSON的情况下，网络地址转换17（NAT）的问题通过让充电点打开与中央系统连接的TCP来解决，并保持这种连接打开，由中央系统发起沟通。因此，不再需要有一个能够解释和重定向中央系统和充电点之间的SOAP调用的智能设备。6.安全OCPP-J安全存在两种方法.一个可以依靠的Network-levelsecurity（网络级安全），或者使用OCPP-JoverTLS（优于TLS的OCPP-J）。下面描述这两种方法：重要的是，在任何时候，都可以使用其中任何一种方法。实际上，这意味着中央系统不应该侦听传入连接互联网上的未加密的OCPP-J。6.1.Network-levelsecurity网络级安全为了安全，thesecurityatanetworklevel可以依赖网络级别上的安全性。历史上OCPP-S一直是这么做的，网络上，适当的设置也可以使用没有额外的加密或认证措施的OCPP-J.6.2.OCPP-JoverTLS然而，有时充电站和中央系统之间没有安全的网络。在这种情况下，就可以使用OCPP-JoverTLS。本节解释这是如何完成的。OCPP通信需要的安全实际上是两个独立的功能：加密和充电点认证。加密意味着OCPP消息进行加密，所以只有经授权的第三方才可以看到交换的消息。充电点认证是指中央系统可以对充电点的身份进行验证，以致经授权的第三方可以假装为充电点，并向中心系统发送恶意消息。6.2.1.加密互联网上的加密的行业标准是传输层安全TransportLayerSecurity(TLS)[RFC5246]。18因此OCPP也采用加密的中央系统和充电点之间的连接协议。有WebSocket的TLS有库图书的广泛支持，客户应该比使用未加密的WebSocket更难。当使用TLS时，中央系统也可以提供一个充电点可以用来验证中央系统的身份签名凭证。由于一些充电点实现使用有限的计算资源的嵌入式系统，我们对服务器端的TLS配置施加了额外的限制：•TLS证书应为RSA证书，其大小不大于2048字节。6.2.2.充电点认证对于认证，OCPP-JoverTLS使用HTTP基本认证方案（[RFC2617]）。可以使用相对简单的HTTP基本身份验证，因为连接已经TLS加密，因此不需要第二次加密凭据。当使用HTTP基本身份验证时，客户，比如充电点，必须根据请求提供用户名和密码。用户名等于充电点身份，这是识别充电点的字符串作为它用它在OCPP-J连接URL。密码则是存储在充电点上的20字节密钥。例子：如果我们有一个充电点：\uf06c充电点身份“AL1000”\uf06cauthorizationkey授权密钥0001020304050607FFFFFFFFFFFFFFFFFFFFFFFFtheHTTPauthorizationheadershouldbe:HTTP授权标头应该是：Authorization:BasicQUwxMDAwOgABAgMEBQYH////////////////关于加密的一点注记：通过HTTP基本身份验证的认证机制将用于TLS加密连接。在未加密的连接使用这种机制意味着任何可以看到充电点与中心系统中网络流量的人也可以看到充电点凭据，因此可以模拟充电点。19设置充电点的凭证对于这个充电点认证方案，充电点需要有一个认证密钥。这个认证密钥必须以某种方式传输到充电点。什么是好方法取决于充电点制造商和中央系统运营商的商业模式。安装期间或安装前的设置理想的安全情况是每个充电点都有自己独特的授权密钥。如果授权密钥是不唯一的，攻击者发现一个充电点的授权密钥可以模仿在运营商的中央系统的许多甚至所有充电点。实现这一点最简单的方法是在制造或安装过程中在充电点上安装授权密钥。在这种情况下通过沟通渠道，密钥将安全地在中央系统运营商和系统安装程序或制造商之间传递，除OCPP以外。这种情况下是安全的，因为密钥是不要通过所谓的安全发送，所以攻击者窃听连接之间的充电点与中心系统，不能模拟充电点。设置密钥overOCPP如果一个充电点的制造、销售和安装过程不在中央系统操作员的控制之下，就不可能在每个充电点上安装唯一的钥匙。还要确保中央系统操作员知道这些钥匙和它们所属的充电点。对于这样的场景，当一个系列的所有充电点离开工厂并安装时，都有相同的“主”键，或者使用相同的算法从充电点标识导出密钥，这是可取的。如果主密钥被泄露，中央系统运营商会让对手模仿一系列的所有充电点。在这种情况下，充电点安装后，有一种可能性就是通过OCPP，充电点发送一个特殊密钥给中枢系统。通过OCPP来设置一个充电点的授权密钥，中央系统将给充电点发送changeconfiguration.req消息与关键的AuthorizationKey和作为价值的40个字符十六进制和20字节授权密钥的表示法。如果充电点响应ChangeConfiguration.req与changeconfiguration.conf为Accepted，中央系统应假定授权密钥更改成功，并且不再接受以前由收费点使用的凭据。如果充电点响应ChangeConfiguration.req与changeconfiguration.conf状态为Rejected或者NotSupported，中央系统应当接受旧的凭据。而中央系统仍然要接受这样一个OCPP-J充电点连接，它可以不同对待充电点的OCPP信息，如不接受充电点的启动通知20充电点不应该归还授权密钥来回应getconfiguration请求。它要么不可以报告authorizationkey要么归还与实际的授权密钥不相关的值。请注意，虽然在通道上要安全地发送一个密钥通常被认为是不好的做法，我们认为在这里至少应该提供这样做的可能性。通常，当中央系统上的“充电点”首次登机时，将设置授权密钥。如果充电点后来产生了在登机时设置的钥匙，至少意味着这是在登机过程中连接的相同的系统。虽然它可能给知道所有新的电荷点单“主”键的对手成功登机了一个伪造的新的充电点，它是不可能假装已经安装和运行充电点。这仍使得许多无法想象的攻击成21为可能：通过对被标记为占用的消息进行欺骗来对收费点进行“保留”将你刚开始的会议标记在公共充电点上，这样你就不必付那么多钱了。发送许多欺骗性的交易，和（或）已经登上充电点的错误来混淆中央系统操作员的操作用另一个人的id给中枢系统产生经济损失的id的主人发送伪造的交易建议中央系统操作员使得设置一个充电点授权密钥为充电点登机程序的一部分，使用新的OCPP1.6待定值Pendingvalue在bootnotification.conf登记状况。新连接的充电点在第一个bootnotification.conf，将首先得到一个Pending待注册状态。中央系统将设置带有changeconfiguration.req充电点独特授权密钥。只有当这个ChangeConfiguration.req已经回应了一个状态接受changeconfiguration.conf，中央系统将响应与接受登记状态启动通知。建议中央系统操作员检查新连接充电点的异常情况。因此，他可以尝试检测攻击者是否窃取了主密钥或密钥派生算法，以及已登记的充电点身份的列表。例如，如果新充电点连接的速率突然增加，这可能意味着攻击。存储的凭据重要的是，凭据必须以不易丢失或重置的方式存储在充电点上。如果凭据被丢失、删除或更改，则充电点不能连接到中央系统，并需要现场服务来安装新凭据。对中枢系统这方面来说，建议存储授权密钥散列，用一种独特的“salt”，使用加密哈希算法设计的安全存储密码。这确保了如果包含充电点的授权密钥的数据库被泄露了，攻击者仍然不能对中央系统的充电点进行身份验证。6.2.3.它的安全性和不安全性这些安全措施的范围仅限于对充电点和中央系统之间的连接的认证和加密。它没有解决电动汽车充电过程中的每一个当前安全问题。它确实提供了以下内容：\uf06c对中央系统的充电点的认证（使用HTTP基本身份验证）\uf06c充电点与中心系统之间的连接的加密\uf06c中央系统对充电点的认证（使用TLS证书）22它不提供：\uf06c保证电表值不受电表和中央系统之间的干扰。\uf06c对司机的认证\uf06c防止人为篡改充电点6.2.4.适用于OCPP-S在对OCPP-JoverTLS方法不能应用于OCPP-S的原因有二。首先，在OCPP-S中，新的TCP连接为每个请求-响应交换创造。因此，每一个这样的请求-响应交换都需要执行一个新的TLS握手，这会带来很大的带宽开销。其次，在OCPP-S，充电点也作为一个服务器，因此就需要一个服务器证书。追踪如此多的服务器证书和它们所属的收费点将是一个巨大的行政负担。7.配置下列项目在OCPPGet/changeconfiguration消息添加到控制JSON/WebSockets行为：表8：附加OCPP的Key：KeyValueWebSocketPingIntervalintegerAvalueof0disablesclientsidewebsocketPing/Pong.Inthiscasethereiseithernoping/pongortheserverinitiatesthepingandclientrespondswithPong.Positivevaluesareinterpretedasnumberofsecondsbetweenpings.Negativevaluesarenotallowed.ChangeConfigurationisexpectedtoreturnaREJECTEDresult.整数值为0禁用客户端WebSocketPing/Pong。在这种情况下，不存在ping23/Pong或服务器启动ping，而客户机响应Pong。正值解释为Ping之间的秒数。不允许负值。changeconfiguration有望返回一个拒绝的结果。24',)