《ISO15118资料整理.docx》由会员分享，可在线阅读，更多相关《ISO15118资料整理.docx（60页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、ISO15118资料整理60ISO15118资料整理by 吕海博 v1.0目 录ISO15118资料整理1前言4第一篇 背景及架构5（1）基本框架5（2）关键定义5第二篇 通信10（1）连接通信模式半在线（Semi-online）12（2）连接通信模式在线（online）13（3）第七层应用层V2GMessage15（4）第六层表示层EXI15（5）第五层会话层V2G Transfer Protocol23（6）第四层传输层TCP、UDP、TLS24第三篇 证书与安全30（1）数字证书30（2）证书责任链31（3）证书签名认证和以及签名计算方法32（4）ISO15118证书种类33（5）ISO
2、15118证书关系33第四篇 会话交互36（1）握手36（2）消息结构定义38（3）会话39（4）V2G基本消息43（5）直流相关消息45（6）交流相关消息45（7）充电识别模式和消息集定义46（8）时序和错误处理50（9）消息序列和错误处理68附录A OPENSSL 测试证书生成79前言ISO15118协议过于庞大，单纯从协议本身，较难描述清楚各个部分主要的职责。因此，编写此文档，用于整理ISO15118协议下各个部分的功能要点，以便进行测试时有据可依。第一篇 背景及架构本篇主要从欧标充电桩使用的场景叙述整个ISO15118的应用架构、应用场景。作为使用EVCC或SECC之前的一些铺垫内容。
3、（1） 基本框架ISO15118出现的背景，就是为了制定一个“全面”的电动车（EV，Electric Vehicle）与电动车充电桩（EVSE，Electric Vehicle Supply Equipment）的交互协议。ISO15118设计的目的是用于详细制定EV与EVSE之间的通信细节，包含在通信网络中探测并发现车辆，而后建立桩通信控制器（SECC，Supply Equipment Communication Controller）和车辆通讯控制器（EVCC，Electric Vehicle Communication Controller）之间基于IP（Internet Protoco
4、l）协议的通信。图1-1 ISO15118架构总览图1-1说明了ISO15118的一个基本定位，ISO15118主要是用来处理EVCC及SECC之间的通信。这里EVCC到SECC之间的通信支持有线或无线的HLC（Hign Level Communication，高级双边数字通信）通信。这个文档同时适用于从充电桩为电动汽车电池充电以及反向电动汽车电池通过充电桩将电能反馈给家庭或者分布式电网。纵观整个协议，主要阐述了智能识别、无线协商、充电与反向充电控制、优化、支付、负载均衡、网络安全和私密性等多方面内容。它提供了电动汽车与充电桩之间彼此协作的交互接口。但是并未涉及电动车内部电池与其他部件的通信。
5、（2） 关键定义l 次要角色SA这里牵扯到了次要角色（SA，Secondary Actor）。如果单纯是EVCC与SECC之间的交互，15118也就不值得专门编写一篇文档了。所以对于次要角色，增加了协议的整体复杂度。而此处，次要角色还不是必要的，有些场景没有次要角色，所以不论SECC还是EVCC均应该可以智能地处理与次要角色之间的关系。EVCC及SECC后续文章会继续整理介绍。现在，此处对次要角色SA进行一下扩展。 什么是SA？ 什么情况下需要与何种SA通信？次要角色SA，相对于主要角色（PA，Primary Actory）。是指在充电过程中，间接起作用或者需要进行间接交互的角色。共有如下几种
6、次要角色：缩写全称功能EMOCHE-Mobility Operator Clearing House电动车运营清算所。其具备的功能有：1、验证授权（Authentication and Authorization）。2、数据结算（Data Clearing）。3、财务结算（Financial Clearing）。4、漫游管理（Roaming Management）。参考URL：DCHDemand Clearing House电网需求清算所。其功能主要是：1、收集电网的电能需求。2、根据电网状况反馈给SECC或EVCC。3、对接入的EV提供充电计划安排建议。OEMOriginal Equipme
7、nt Manufacturer设备制造商。FOFleet Operator车队调度管理员或机构。主要从事多辆电动车的营运工作。可与电动车服务提供商（EMSP，E-Mobility Service Provider）签订服务合同。可以理解为交运公司。EMSPE-Mobility Service Provider电动车服务提供商。其主要功能是：1、包含常用电量购买（EP）等功能。2、可以验证来自于EMOCH的EMAIDs。3、可以发行EMAID。DSODistribution System Operator电网系统管理机构。其对分布式电网的电压稳定性负责。涉及到的主要功能为：将电流从干线分配给终端
8、用户。可以理解为配电柜。MOMeter Operator电表管理员。职责是安装及维护电表。EPElectricity Provider供电局。EMSEnergy Management System电能管理系统。用于管理控制电网功率传输。CSOCharging Station Operator充电站。运营充电桩。表1-1 SA种类列表名词释义：E-Mobility，全称Electro Mobility，即电动车，包含了混动、氢动等新能源车辆。Clearing House，在场景中，会多次提到Clearing House这个名词。字面意思是清算所。初期产生于美国内战之前，在当时的期货市场，为了稳定
9、期货交易、保证交易顺利进行并进行合同的标准化而设立的清算机构。同时，根据维基百科的定义，清算所主要是用来组织和监督结算的机构。Fleet Operator，这个通常的意思是海港中进行船舶调度管理，也指车队调度。l HLC通信ISO15118中涉及到两种不同的通信概念，即：“基础信号通信”和“HLC”通信。在ISO15118-1、ISO15118-2及ISO15118-20中特指HLC通信。HLC包含有身份识别、支付、负载均衡、能源传输控制及增值服务。相对的，“基础信号通信”仅包含有车辆状态交互、能源传输流程启动及安全控制导引相关的基础内容。只有EV及EVSE均配备有HLC设备时，才可以进行基于
10、HLC模式的信息通信。基于此，目前而言EV及EVSE均有如下三种情况：不支持、支持、必须。l 无线通信（2019新增）相较于有限传输，无线通信需要一些额外的要求。例如，在充电过程中在司机接通（plugged-in）前就应该开启HLC通信。尤其是类似电磁波无线充电，这种并没有特别明显的插入（plug-in）操作的充电过程。类比于已知的手机无线通信或者局域网无线设备，无线通信的需要建立在“发现”和“协商”的基础上。SECC的无线接口应该可以发现电动汽车的识别模块。而与手机无线通信不同的是，手机无线通信允许用户使用范围内发现的任意接入点，有时这些接入点可能数量超过20个，那么它会从中任选一个接入点进
11、行无线接入。而对于电动车无线充电来说，很多国家考虑到此种情况，禁止电动车在没泊车的情况下进行无线充电。同时，为了简化司机的充电操作并提供更安全合理的充电服务（避免出现一串可用SECC），在SECC端及EVCC端均需要做一些特定的处理。在SECC端应做到：1），广播其识别信息及必要的发现及协商握手信息。2），每个SECC可以控制一个或者多个充电桩，然而系统整体的数据通信率不应降低。3），每个充电桩只和一个SECC建立链接。EVCC端应做到：不需要司机的参与即可发现并进行协商已建立通信。图1-2 单独SECC无线充电场景为了简化司机的操作体验，EVCC中可供选择的有效范围内SECC列表是有限的。注
12、：无线通信场景由ISO15118-1:2019新增。l RPT和FPT（2019新增）一些电动车或其他一些电助力车可以当成能源供给使用。它们使用内置电池将储存的电能提供给外部负载。对于配备有电池的电动车，正向能量传输（FPT，Forward Power Transfer）是对电池充电的必要要求。而相反，在反向能量传输（RPT，Reverse Power Transfer）中，电动车也可以被看作一个分布式的能源。直流正向反向能源传输的系统如下图所示：图1-3 典型的交流（AC）正向/反向能源传输系统直流的正向/反向能源传输系统与此结构类似。但是有不同点，如图1-3，在交流中双向转换器在EV中，进
13、行电能的双向切换。而在直流的结构中，此部分双向转换器处于中间方形区域中，此区域称作电动车能源系统（EV Power System）。注：反向能量传输相关的场景由ISO15118-1:2019新增。l 回溯（2019新增）回溯的需求为2019的协议中新增的内容，其目的是为了增加多方在能源交换时的可信度及可靠性。注：回溯的相关场景由ISO15118-1:2019新增。第二篇 通信本篇叙述了SECC和EVCC之间的具体通信流程。从标准ISO15118-1:2019中，可以看到其新增了一些内容，这些新增的内容同时体现在ISO15118-8和ISO15118-20中。ISO15118-8中主要是针对无线
14、通信的定义，而ISO15118-20则定义了第二代网络应用协议要求（对应于ISO15118-2，那是第一代）。 目前ISO15118-20这部分官网显示正在准备中，不过后面发布时间标注的2019，最迟也会在今年发布。所以当前先以ISO15118-2做为通信协议基础描述。在ISO15118协议中，按照ISO/OSI七层模型进行了严格分层，保证了各层的独立性。图2-1 ISO15118-2协议OSI分层图如图2-1可见ISO15118-2处于OSI网络分层中的第37层。而数据链路层和物理层由ISO15118-3进行阐述。因测试需要，可能需要对数据链路层和物理层进行测试。这部分测试需要使用特定的硬件
15、环境进行。而37层不属于物理层及数据链路层的内容，故此处可以进行上位机模拟测试。ISO15118-2中定义了两种常用的链接通信模式：半在线和在线。下图2-2及图2-3是半在线和在线模式的交互时序图。这里重点解释一下半在线，半在线的个人理解就是离线模式。不过和纯粹离线模式不同的是，这个在SECC这一端会每隔一端时间在线一下，获取一些即将过期的授权证书等的操作。在确定的情况下，标准强制要求EVCC与SECC之间建立TLS安全通道进行数据通信。而其他一些情况下，TLS是可选的。图2-2展示的是在半在线状态下即插即充（PnC，Plug-and-Charge）的实例。其基于TLC单向验证通道。在半在线状
16、况下，SECC与SA之间的通信是仅为进行一些信息的交互，比如一些交换证书或者计量回执数据。所以这部分并不是实时的，与实际的充电流程无关。而对于在线状况下，SECC会立即将充电首选项发送到智能配电系统（Smart Grid or Demand Clearing House）。（1） 连接通信模式半在线（Semi-online）图2-2 半在线通信模式（2） 连接通信模式在线（online）图2-3 在线通信模式加解密及证书的内容后续会有提另的章节详解。本篇主要详解通信部分，即ISO/OSI七层中第37层的通信交互。在一个对等网络中，对于应用层的数据会进行类似图2-4的处理流程。图2-4 OSI通
17、信架构原型一个数据请求m会自OSI顶层逐级向下传输，可能经过分包，将PDU分成多个数据包之后通过点对点之间的传输，将数据交互到另一端。另一端则将同一PDU的数据组织起来，再按照自底向上逐级向上传输，最后将数据请求指令发送到顶层。顶层接收到指令后，会产生m+1的响应数据，类似于请求数据的传输，响应数据也是经过自顶向下再自底向上发送到另一端。因此，我们以一次数据交互为例，详细研究数据是如何通过这几个逻辑层的。对此，我们不禁要问，都有哪些数据需要传输？传输的具体时机是什么？在ISO15118-2的第八章，定义了完整的数据内容。具体何时传输何种数据内容，暂且放入后面章节讨论。在本篇里，我们仅以一条应用
18、层的数据交互为例，进行完整的说明。TCP连接建立后（TLS及非TLS），就可以开始进行数据交互了。而TCP如何建立链接、证书如何处理这些内容本篇暂不涉及。一次EVCC与SECC的充电交互，总是以SessionSetupReq为起始。那么我们以该条消息为例，进行实际的交互说明。（3） 第七层应用层V2GMessage应用层的处理包含SDP（SECC Discovery Protocol）以及应用消息的处理。以SessionSetupReq为例。该条消息属于一条应用层消息。ISO15118-2第八章的定义如下：图2-5 SessionSetupReq定义SessionSetupReq包含的内容很简
19、单，仅有6个字节长度的EVCCID。其释义如下表：名称类型语义EVCCIDsimpleType:evccIDTypehexBinary(maxLength:6)定义了EVCC可读的标识信息。包括以十六进制表示的六位MAC地址信息。表2-1 SessionSetupReq语义解释（4） 第六层表示层EXI为了描述表示层应用的V2G消息集，采用参照一定XML标记语言规范定义的XML类型数据。该模式支持数据的传输并提供简单的验证功能。根据要求V2G2-097，所有采用XML传输的V2G实体应该参照W3C EXI1.0的定义执行。下面着重整理扩展下EXI（Efficient XML Interchan
20、ge）相关的内容。l EXI（Efficient XML Interchange）EXI格式允许以二进制的形式，使用并传输基于XML的消息。EXI格式提高了处理基于XML数据的速度，并降低了存储空间的占用，它是W3C推荐的格式。它有效提高了用例中的编码效率。相对于同等信息的XML文档，EXI格式可以将其大小压缩100倍。EXI的定义描述需要一个预定义的文件。该预定义文件标识了如何将规范数据转换成EXI语法的过程。相较于同等的XML文档，EXI语法更加简单。目前，除了EXI外还有多种编码机制，而ISO15118需要更少的占用资源，更小的消息大小以及更便于消息扩展，故采用EXI格式。Session
21、SetupReq相关XML规范定义通常，在所有需要编码的消息按照预定义XML语言规范（规范类型语法）编码后，构建一个EXI流数据将会十分有效。下面是对于会话建立请求SessionSetupReq相关的XML规范定义。该定义采用基于字符串的编码方式。如上面XML规范定义中，采用了simpleType类型，名称为evccIDType的规定名称数据。该数据的内容长度最大为6字节。对于解码来说，需要采用和编码相同的XML规范定义。图2-6对ISO15118中EXI的应用进行了总结。图2-6 ISO15118中EXI的应用示意图一条SessionSetupRes数据XML文档格式303132333435
22、3637OKFRA23E45B78C一条V2G消息在EVCC中以数据结构的形式存在，它包含了头部以及内容主体。参考公共文档ISO/IEC15118中XML规范定义，这里定义了EXI的语法。EVCC根据此EXI语法进行结构及内容编码。最后将二进制数据流传输到SECC中。SECC在接收到了数据后，根据相同的语法解码，因为SECC存储空间没有特别严格的限制，故可以以数据结构、DOM树或XML文档的形式表示该接收到的消息。这里以标准的SessionSetupResp为例，说明XML文档与二进制EXI格式。可见占用较多的空间，篇幅很长，及其低效。而转为EXI后，同样的内容表述如下：80 98 02 0C
23、 0C 4C 8C CD 0D 4D 8D D1 E0 00 39 19 49 04 C8 CD 14 D0 D5 08 DC E1 0C 80一共28字节，十分精简高效。l EXI应用层通信设置定义描述如下：【V2G2-098】EXI的XML规范定义中采用命名空间为urn:iso:15118:2:2013。这代表采用ISO15118第二版协议规定的方法EXI数据流的编解码。【V2G2-099】参考W3C EXI 1.0条款定义，在进行ISO15118交互的编解码操作中，EXI Options选项中使用默认的EXI编码选项。【V2G2-100】EXI头部应该根据ISO15118需要进行填充。其
24、中，可选的EXI Cookie（$EXI）不可使用，并且Presence Bit应该总为0（相当于false）。所以，ISO15118的消息中，不需要添加EXI Options的相关内容。不论EVCC或者SECC都应该舍弃不符合EXI头部定义的消息。【V2G2-101】对于命名空间urn:iso:15118:2:2013:MsgDef中没有定义的元素/属性，应该参照W3C EXI 1.0中定义的异常情况Adding Productions when Strict is False进行编解码。【V2G2-600】在EXI解码器进行ISO15118通信编解码时，应该采用EXI首选项设置。【V2G2
25、-102】对于没有在urn:iso:15118:2:2013定义的元素/属性中定义的类型值，应该按照类型发现来编解码。协议定义中，这里描述了EXI的命名空间、可选配置项以及未定义（超出范围）内容的编解码策略。不用太在意，在一般的EXI工具中，这部分都是默认的就可已。l EXI消息安全（仅PnC消息集使用）：摘要签名根据ISO15118定义所述，在EXI表示的XML中，其采用头部加入摘要签名的模式来保证内容的安全性。摘要签名（XML Signature）是W3C推荐的用于满足XML的V2G数据的真实性要求（如：抄表信息）而设计的。扩展：消息的加密方式采用与椭圆曲线数字签名算法（ECDSA，Ell
26、iptic Curve Digital Signature Algorithm）。在ISO15118交互过程中，由次要参与者SA（通常是EMOCH）生成证书的公私钥对。SA需要采用短暂的会话key将加密了的私钥传输给EVCC。这个短暂的私钥key传递交互协议称为短静态迪菲赫尔曼密匙协商协议（ephemeral-static Diffie-Hellman key agremment protoco）。通过采用ESDH协议，SA可以将合同证书（Contract Certificate）传递给EVCC。而XML签名的证书也需要使用这个合同证书。XML签名部分由W3C XML签名语法和处理（版本1.1
27、）定义。在XML中，签名部分采用一个XML元素作为额外信息体现。这个部分的内容先经过哈希处理再进行加密签名。如W3C XML签名语法和处理（版本1.1）一致，签名部分和数据部分可以在分开传输，也可以在同一个XML文档以相邻的元素传输。如下图2-7，描述了V2G消息头部中XML签名元素的定义。图2-7 XML签名规则定义图图2-8 签名信息中的元素引用规则定义根据图2-7、图2-8无法清晰的说明XML签名的构成。下面我们以实际V2G Clarify开源项目中的AuthorizationReq消息说明。AuthorizationReq消息 74A0FE2C511DDFD8 /dzoO7px98cu
28、UdaJ8ljp841TG7qJtNUAYBNMXgUg+9s= kPGg31wlvjVXKHVYh/ZmNQA7Xx09vfsRrosgAPtW3M9U894O+4Fng7Y72Ly9BJRPXvTQuCGuRI/Yj+ld5wlfsA= xJmKUo9jDOSL4xMn5U+FDw= 可见在一条XML形式的V2G消息中，需要加密的签名位于Header中呈现。Header中包含SessionID和Signature。其中Signature元素中又包含SignatureInfo与SignatureValue，SignatureInfo这个元素主要用于描述签名的算法信息。而SignatureVa
29、lue则是签名主体。ISO15118的应用层协议中并不是所有消息的交互都需要进行XML签名操作，签名操作仅针对于涉及PnC支持的方法实现。XML消息保护域签名实体验证实体AuthorizationReq整个消息体/全部域EVCCSECCCertificateUpdateReq整个消息体/全部域EVCCSACertificateUpdateResContractSignatureCertChainContractSignatureEncryptedPrivateKeyDHpublickeyeMAIDSA；证书提供服务EVCC；成功验证后存储CertificateInstallationReq整个
30、消息体/全部域EVCC；由消息体传输，由OEM提供认证SACertificateInstallationResContractSignatureCertChainContractSignatureEncryptedPrivateKeyDHpublickeyContractIDSA:证书提供服务EVCC；成功验证后存储MeteringReceiptReq整个消息体/全部域EVCCSECCChargeParameterDiscoveryResSalesTariff（PnC强制，其余可选）SA：移动运营商Sub-CA2EVCC表2-2 基于XML签名一栏上表2-2说明了需要XML签名字段的消息、保护
31、域、签名及验证实体。普遍的，XML签名的生成需要经过两个步骤：第一，区别收集签名数据体；第二，根据签名数据体根据固定的算法进行签名。下面以AuthorizationReq消息为例，说明XML签名。AuthorizationReq消息具备2个内容：Id（字符串类型）、GenChallenge（Base64二进制类型，16字节）。 生成XML签名的时候可以采用如下签名片段的最简模板：U29tZSBSYW5kb20gRGF0YQ=根据这个模板，在生成签名片段时，仅需要更改Reference部分（URI和DigestValue）以及SignatureValue部分的内容即可，其余的引用都不变。Refe
32、rence的URI部分为AuthorizationReq消息体中Id属性，前加#表示引用至。接下来我们需要计算DigestValue，就是签名的摘要内容。这个摘要内容的原始内容根据表格2-2定义可知，为整个消息。这部分内容做EXI编码。得到的二进制编码结果为：80 04 01 52 51 0C 40 82 9B 7B 6B 29 02 93 0B 73 23 7B 69 02 23 0B A3 09 E8注意：这里XML文档属于一个片段（不是完整的XML内容），针对于XML片段需要启用一个标志schema-informed fragment grammar option选项。如果不启用片段语法
33、，则无法得到正确的EXI内容。然后将这部分EXI数据进行SHA256的哈希，得到如下二进制内容：D1 B5 E0 3D 00 65 BE E5 6B 31 79 84 45 30 51 EB 54 CA 18 FC 0E 09 16 17 4F 8B 3C 77 A9 8F 4A A9然后将哈希后的结果进行Base64编码方便在网络传输，得到如下内容：0bXgPQBlvuVrMXmERTBR61TKGPwOCRYXT4s8d6mPSqk=这部分就是DigestValue的内容。合并后，Reference内容如下：0bXgPQBlvuVrMXmERTBR61TKGPwOCRYXT4s8d6mPS
34、qk=得到这部分内容之后，就可以根据SignedInfo元素的内容生成签名了。生成EXI的方法同样需要启用片段语法，开启schema-informed fragment grammar option选项。具体签名生成的步骤较为麻烦：首先，根据SignedInfo元素体生成EXI流；然后，对该EXI流的二进制数据进行SHA256哈希计算；然后，使用ECDSA算法对哈希的结果进行计算得到签名的二进制流；最后，采用base64编码，将这个二进制流数据进行编码，并填入SignatureValue元素中。至此，我们已将表示层的机制全部阐述完毕。（5） 第五层会话层V2G Transfer Protoco
35、l传输层的协议是V2GTP，即V2G Transfer Protocol。这个协议是标准的EVCC与SECC通信的数据传输协议，但同样适用在任何两个支持V2GTP实体的两端。它定义了头部和有效载荷（Payload），可以高效处理传输的数据。V2GTP基于TLS+TCP。TLS+TCP采用了一对IP地址端口用来构建可标识身份的双向数据流交互链接。根据IETF RFC 6335定义，V2GTP采用的支持的TCP端口为49152-65535。l 协议数据单元框架图2-9 V2GTP PDU根据图2-9，可见V2GTP的数据单元由头部（8字节）与载荷（4T）构成。载荷的内容是上一层EXI数据流的二进制内容。而头部8字节的定义如下：图2-10 V2G头部数据定义如图2-10，V2GTP的头部8字节的数据依次为：协议版本、反向协议版本、载荷类型、载荷长度，共四部分。数据的发送方向是从左至右，或者从1至8。其中载荷类型和载荷长度采用Big-Endian编码格式。协议版本这部分