柳州免费做网站的公司wordpress3.6

附录C SLAC匹配过程命令定义与实际抓包

ISO15118-3 附录A中规定了SLAC匹配过程中的请求命令及应答， 本文将会对比协议中的定义和实际抓包内容，以便读者获得直观的认识。

1 CM_SET_KEY.REQ

定义内容：

实际数据：

注意报文中的 08 60字节，这个就是mme_type, 大小端整理后实际是0x6008。

2 CM_SET_KEY.CNF

15118-3协议中无定义。在代码中的定义如下：这是在 everest项目中找到的定义。

这是在pyslac中的定义：

/home/vboxuser/checkout/everest-workspace/libslac/include/slac/slac.hpptypedef struct {uint8_t result; // 0x00 = success, 0x01 = failure, 0x02 - 0xFF = reserveduint32_t my_nonce;uint32_t your_nonce;uint8_t pid;uint16_t prn;uint8_t pmn;uint8_t cco_capability;
} __attribute__((packed)) cm_set_key_cnf;

实际报文数据如下：

注意报文中的 09 60字节，这个就是mme_type, 大小端整理后实际是0x6009。

这个报文中的result是0x01， 但是定义中01表示失败，为什么应答报文不是01呢？

【联芯通解答】协议中0x01表示设置失败，但是高通的SLAC程序写错了，成功应答却返回了0x01。这个错误一直没有更改。没办法，为了能跟高通芯片正确通信，其他厂家（联芯通、君正)也跟着故意做错了。

3 EV 广播  CM_SLAC_PARM.REQ

定义内容： Table A.2 

实际数据：

注意报文中的 64 60字节，这个就是mme_type, 大小端整理后实际是0x6064（24276）。

4 EVSE应答 CM_SLAC_PARM.CNF

实际抓包:

注意报文中的 65 60字节，这个就是mme_type, 大小端整理后实际是0x6065。

5 EV请求 CM_START_ATTEN_CHAR.IND

定义Table A.4

实际抓包：

注意报文中的 6a 60字节，这个就是mme_type, 大小端整理后实际是0x606a。

6 EV请求 CM_MNBC_SOUND.IND  

协议中的定义：

实际抓包： 注意中间的次数9，后续的几个包该值递减到0。刚好是10个包。

注意报文中的 76 60字节，这个就是mme_type, 大小端整理后实际是0x6076。

7 EVSE收到 CM_ATTEN_PROFILE.IND

这是ese端PLC芯片发给slac程序的内部消息。

协议定义：Table A.4

实际抓包数据：

注意报文中的 86 60字节，这个就是mme_type, 大小端整理后实际是0x6086。

8 EVSE请求 CM_ATTEN_CHAR.IND

协议定义：Table A.4

实际抓包数据： 

注意报文中的 6e 60字节，这个就是mme_type, 大小端整理后实际是0x606e。

9 EV应答 CM_ATTEN_CHAR.RSP

协议定义： Table A.4

实际抓包数据：

注意报文中的 6f 60字节，这个就是mme_type, 大小端整理后实际是0x606F。

注意最后一个字节0x00， 表示EV端认为信号强度符合要求，这个evse的信号强度是合格的，应答结果是Success。

10 CM_SLAC_MATCH.REQ    EV发送消息

协议定义：

实际抓包数据：

注意报文中的 7c 60字节，这个就是mme_type, 大小端整理后实际是0x607C。

11 CM_SLAC_MATCH.CNF   EVSE应答

协议定义：

实际抓包数据：

注意报文中的 7d 60字节，这个就是mme_type, 大小端整理后实际是0x607D。

12   CM_VALIDATE.REQ

这是ev端发出的验证命令， 属于可选项目。

协议定义分为Step1、和Step2， 命令字相同，但是内容有所不同。

实际报文： 我改造了联芯通代码，新增加了此命令，这样才抓到实际命令包：

13 CM_VALIDATE.CNF

  

14 CM_AMP_MAP.REQ

协议定义：

实际报文：

  暂时无法抓到