为了准备下周和ISO/IEC JWG1上海会议交流的材料，讨论了一下未来充电通信协议标准修订可能涉及的一些问题。

啥是即插即充？其实说这个有点浪费大家精力，呵呵，说白了就是懒人的梦想。。。应该还不是终极梦想吧。。。拎起枪插上就可以走人了，省掉了常规的开APP、扫码、刷卡支付等一系列动作。要做到这点其实最关键的一点就是如何安全地完成身份凭证的传递和充电授权。

常规的即插即充是怎么实现的捏？请看下图：

这个我们把他叫模式一，也可以叫15118模式，虽然有点不准确，其实就是现在欧洲在推的即插即充授权过程。可以看出，这个过程很简单，就三步。车辆把自己的凭证（可以是VIN码或者任何一个唯一的ID）通过PLC加密传给充电桩，充电桩再送往后台完成认证。看上去十分简洁、完美、易懂。木啥问题，谁都能在5秒内想明白。于是想当然地，咱们可以把这个模式移植到GB来，看下图：

这个是模式二，看上去和模式一唯一区别是吧PLC改成了CAN，也是十分简洁、完美、易懂？其实仔细一琢磨有问题，问题就出在传送凭证和其他一些敏感信息时用的是CAN，而CAN是一个很久很久以前发明的用以汽车内部的工业控制网络，由于其本身的特性几乎无法像PLC一样去承载IP的网络层，它是OSI模型的阉割版，说白了也就是用CAN实现基于IP的所有加密机制是几乎不可能滴。因此那些敏感信息如果直接套用这个模式很可能会有安全问题。如何解决这个问题？比较直接的想法是采用某种CAN的增强式安全模式，在应用层做加密，但是这种方法和很多通信安全专家讨论后，都表示比较难。。。还有一种办法，就是。。。干脆咱们也用PLC？。。。好像看见了高高扬起的巴掌正在朝你脸上呼来，嘿嘿嘿。。。

怎么办呢，换一个思路也许是一种办法，请看下图：

既然CAN很难保证强力加密的强度，那我们在CAN上不走敏感信息或者降低敏感度不就可以了？于是整个过程可以分成六步。首先（第零步），插枪，此时车辆认证机构被激活。第一步，车辆将自己的身份信息通过3G/4G/5G等等办法直接将请求发给车辆运营商，车辆运营商在认证车辆的身份后。。。注意，此时的认证完全是基于强壮的基于IP的加密机制完成的。。。临时生成一个全球唯一的一次性使用凭证并通过第二步发给车辆。第三步，车辆通过CAN 将这个一次性凭证传给充电机。第四步，充电桩将这个临时凭证发送到一朵云里。。。恩，说不明白的东西都可以叫云。。。这朵云具体啥样，整个过程如何实现，不是今天的重点，就不说了，反正是所有参与的充电运营商车辆运营商都在里面，过程好像失物招领一下，充电运营商通过这朵万能的云，知道了是否可以为这辆车充电，通过第五步把授权发给充电机。于是完成了整个授权的过程，而所有的敏感信息的传递都是在基于IP的WIFI/3G/4G等等网络中传递，弱弱的CAN只传了一个一次性使用的临时凭证，而这个凭证即使被截获，仿冒，串改的意义也不大了。

好了上面说的是基于CAN的直流充电的方案，如果是交流充电怎么办呢？

首先，个人认为未来交流充电是否有存在的必要还值得商榷。。。这又是一个话题，以后有空再聊。。。第二即使存在是否有必要加一个通信也是要仔细探讨的。好吧，即使上面两点都不成立，一定要在交流中实现通信，是不是在无法增加信号针的交流方案里一定要再去采用PLC？。。。PLC的问题，是一个持续了十年的问题，又是一个要割袍断义的话题，下回说。。。答案是不需要的，还是看下图：

交流可以套用模式三的方式，区别就是把插枪变成车辆接近侦测。。。或者叫靠近充电桩侦测更准确一点。。。然后采用无线通信的方式解决通信问题，具体流程和直流类似，这里就不扯了。当然也可以采用类似模式一的方式，只是将PLC换成无线就好了。

简单总结一下：

1. 这篇东西只是从即插即充这个概念入手谈谈凭证传输、加密强度等几个小概念。

2. 解决CAN加密的问题可以有不同的思路，正面强攻不行，咱们可以悄悄滴进村。。。换个思路。

3. 交流是否一定需要通信支持，需要好好议一下。

返回第一电动网首页 >