附录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
协议定义：
实际报文：
暂时无法抓到