依然如同之前我们的实验方式，使用的软件和工具都是自己研发的。 这个实验要用到的工具包括：总线采集软件，ECU模块扫描软件，云端log service分析平台，外加ECU测试bench和连接工具。
实验目的
收集ECU测试bench数据，判断有几个ECU？ 每个ECU的CAN包ID列表。
实验方法
实际上这个实验非常简单：用我们的ECU模块扫描工具, 不需要做任何硬件上的拆解，直接进行扫描，几分钟就可以得出结果。
很明显结果包括两组，即两个ECU，每组ID跃然纸上。然而，细看一下，有一个非常有趣的地方，导致我们花更多的时间来进行验证排查。为什么0x440和0x442这两个ID分在不同的组中？于是又进行了第2次扫描，扫描结果依然是一样的。
结果验证排查
为了确认模块扫描结果的正确性，我们用VT-CANBusLogger软件对该ECU bench进行了流量采集，并进行了 统计分析。
对统计结果进行标注后（绿色和红色各自代表不同的分组），0x440和0x442两个ID无论是从发包间隔还是频率都极其相似，再加上他们的ID数值只相差2。简直就是一对双胞胎！为什么他们却天各一方，分在两个不同的家庭（组），难道是我们的结果出错了吗！？
上粗暴但最有效的方法：接卸ECU bench，只留一个ECU！我们只收集剩下这个ECU的流量。流量数据里所有的ID都只和这个ECU相关。流量数据如下：
这些CAN ID和上面标注的分组ID完全一致，说明我们的ECU模块扫描软件的结果是正确的：0x440和0x442这个两个ID就是属于两个不同ECU的！
更上一层楼
再进一步，把ECU bench流量上传到云端汽车数据分析平台。画出这两个ID的时间分布图。可以看到这两个ID的包前后错落有致，报文里面的一个字节分别有0x42和0x40，难道是巧合？
对数据进行放大，明显看到这两个ID发包的间隔是一样。这就是很好地解释为什么它们的统计特征也是完全一致的，但却不属于一个ECU。基于它们的频率是流量里最高的，个人认为，是按照周期发布的广播包来通知自身的存在感。
结论
这个实验一方面验证了我们的模块扫描软件的正确性；另外一个方面是告诉我们：基于统计特性的ID分类有时不靠谱。统计特征的完美性往往会欺骗我们。应该采取多种不同维度的工具叠加验证，提高准确性。
