Renault Zoe 在 SLAC 匹配过程后未发送 SDP 请求
Renault Zoe doesn't send SDP Request After SLAC Matching Process
我们正在尝试根据 DIN SPEC 70121 与 Renault Zoe 进行通信。
我们正在与 Hyundai Kona 和 BMW i3 成功通信,但未能收到 SPD 请求 和 雷诺 Zoe。我们正在通过 Renault Zoe 的 SLAC 流程,但之后我们没有收到任何 UDP 消息。根据 DIN 规范 70121:2014-12、8.3.3.3.2、Table 2,我们将 CM_SLAC_MATCH_CNF 消息作为以太网单播消息发送(在设计指南组合充电系统 V5 - 故障中注明)在 SLAC 期间 - SLAC 比赛序列中断)。
为什么我们用Kona和i3能收到SDP Request,而用Zoe却收不到?以前有人经历过这种行为吗?
使用 scapy 嗅探 SLAC 消息:
(= ''表示该字段用零填充)
从 Zoe 收到:
###[ CM_SLAC_MATCH_REQ ]###
ApplicationType= 0
SecurityType= 0
MatchVariableFieldLen= 15872
\VariableField\
|###[ SLAC_varfield ]###
| EVID = ''
| EVMAC = 7c:bc:84:41:03:3b
| EVSEID = ''
| EVSEMAC = 3e:7e:f1:10:ab:3e
| RunID = '\xd3\xac;\x0f\x17-\xb7+'
| RSVD = ''
发送给佐伊:
###[ CM_SLAC_MATCH_CNF ]###
ApplicationType= 0
SecurityType= 0
MatchVariableFieldLen= 86
\VariableField\
|###[ SLAC_varfield ]###
| EVID = ''
| EVMAC = 7c:bc:84:41:03:3b
| EVSEID = ''
| EVSEMAC = 3e:7e:f1:10:ab:3e
| RunID = '\xd3\xac;\x0f\x17-\xb7+'
| RSVD = ''
| NetworkID = '$\x94\xc1\x0c\xbcO\xb5'
| Reserved = 0
| NMK = ''
解决方案是在 CM_SLAC_MATCH_CNF
消息中以 little-endian 字节顺序发送 2 字节字段 MatchVariableFieldLen
。
从雷诺 Zoe 发送的消息中,我们可以看到 Zoe 发送 CM_SLAC_MATCH_REQ
,其中 MatchVariableFieldLen
作为 0x3e 0x00
(15872 == 0x3e00
)。由于根据DIN SPEC 2014-12这个字段应该是0x3e
,我们可以看到这个字段的字节顺序是little-endian。所以一个合理的猜测是它期望响应消息中的little-endian中的这个字段。
结果:我们收到了 SDP 请求和之后的消息。
HomePlug GP 规范 未在条款 11.5.58 中指定此字段的字节顺序。但是看看 Table 11-316 中的例子,人们会说它是 big-endian.
很明显 Zoe 将此字段解释为 little-endian 并且不接受 0x00 0x56
但接受 0x56 0x00
.
Kona 和 i3 要么不抱怨这个字段并接受消息,要么 Zoe 的解释是错误的。无论哪种方式,问题的原因都已确定。
我们正在尝试根据 DIN SPEC 70121 与 Renault Zoe 进行通信。
我们正在与 Hyundai Kona 和 BMW i3 成功通信,但未能收到 SPD 请求 和 雷诺 Zoe。我们正在通过 Renault Zoe 的 SLAC 流程,但之后我们没有收到任何 UDP 消息。根据 DIN 规范 70121:2014-12、8.3.3.3.2、Table 2,我们将 CM_SLAC_MATCH_CNF 消息作为以太网单播消息发送(在设计指南组合充电系统 V5 - 故障中注明)在 SLAC 期间 - SLAC 比赛序列中断)。
为什么我们用Kona和i3能收到SDP Request,而用Zoe却收不到?以前有人经历过这种行为吗?
使用 scapy 嗅探 SLAC 消息:
(= ''表示该字段用零填充)
从 Zoe 收到:
###[ CM_SLAC_MATCH_REQ ]###
ApplicationType= 0
SecurityType= 0
MatchVariableFieldLen= 15872
\VariableField\
|###[ SLAC_varfield ]###
| EVID = ''
| EVMAC = 7c:bc:84:41:03:3b
| EVSEID = ''
| EVSEMAC = 3e:7e:f1:10:ab:3e
| RunID = '\xd3\xac;\x0f\x17-\xb7+'
| RSVD = ''
发送给佐伊:
###[ CM_SLAC_MATCH_CNF ]###
ApplicationType= 0
SecurityType= 0
MatchVariableFieldLen= 86
\VariableField\
|###[ SLAC_varfield ]###
| EVID = ''
| EVMAC = 7c:bc:84:41:03:3b
| EVSEID = ''
| EVSEMAC = 3e:7e:f1:10:ab:3e
| RunID = '\xd3\xac;\x0f\x17-\xb7+'
| RSVD = ''
| NetworkID = '$\x94\xc1\x0c\xbcO\xb5'
| Reserved = 0
| NMK = ''
解决方案是在 CM_SLAC_MATCH_CNF
消息中以 little-endian 字节顺序发送 2 字节字段 MatchVariableFieldLen
。
从雷诺 Zoe 发送的消息中,我们可以看到 Zoe 发送 CM_SLAC_MATCH_REQ
,其中 MatchVariableFieldLen
作为 0x3e 0x00
(15872 == 0x3e00
)。由于根据DIN SPEC 2014-12这个字段应该是0x3e
,我们可以看到这个字段的字节顺序是little-endian。所以一个合理的猜测是它期望响应消息中的little-endian中的这个字段。
结果:我们收到了 SDP 请求和之后的消息。
HomePlug GP 规范 未在条款 11.5.58 中指定此字段的字节顺序。但是看看 Table 11-316 中的例子,人们会说它是 big-endian.
很明显 Zoe 将此字段解释为 little-endian 并且不接受 0x00 0x56
但接受 0x56 0x00
.
Kona 和 i3 要么不抱怨这个字段并接受消息,要么 Zoe 的解释是错误的。无论哪种方式,问题的原因都已确定。