Model3的网络拓扑图和总线信号破解.docVIP

Model3的网络拓扑图和总线信号破解 一、Model 3?Communication Architecture的新发现 ...这个新的发现其实是相比之前整理的网络拓扑图的补充——抱歉这个‘Communication Architecture’暂时不方便放在文章中，如果有兴趣的可以根据文末的提示进行沟通——我们先附上根据原理图整理而来的拓扑图。 图1?特斯拉Model 3网络拓扑图补充了哪些内容呢： 1、几大核心控制器的‘Enclosure’（封装）内部原理 包括BCM Left/Right、Autopilot+MCU（Media）、HVC（High Voltage Controller）、EPS等，最典型的莫过于连接超声波雷达的BCM Right了——强行‘Single Enclosure’——根据这些原理、可以很清晰地了解到特斯拉的设计思路； 2、明确了同一网段、同一控制器占用不同管脚的“事实” 这么说可能有人不理解，大家可以先看下面的示意图： 图2?特斯拉Model 3右车身控制器网络连接示意图 这种连接方式，如果只根据整车原理是看不出来差别的——因为它们是占用了不同的管脚但同时它们也是同一个网段。这点可以在第二章节中的报文记录中得到佐证。特斯拉对这种设计‘乐此不疲’，本质是将线束钉点放到了ECU板端，出于线束分区的考虑； 3、定义了不同节点的唤醒行为并区分了‘Powered during vehicle sleep’ ...这就是系统工程师应该做的、而且很方便在拓扑图里面体现的内容。 特斯拉没去扯什么网络管理，就告诉你：这个节点的这个网段需要网络唤醒、那个节点需要在整车休闲状态下仍然供电，直击问题本源； 4、标明了控制器的供应商 我这里做了简单的汇总， 图3 Tesla Model 3控制器供应商分布饼图 据上图的不完全统计，特斯拉自研的控制器占据了大半壁‘江山’！ ...当初还只是自研核心的三电、中控以及AP，现在连车身控制器这种‘低门槛’的也不放过（当然还有其他比较重要的，像是Security Controller），简直丧心病狂！ 除非真有两板斧（掌握核心技术），控制器供应商的日子不好过啊。 5、当然还有余下细枝末节的，比如终端节点的设计、选装节点的设计等等。 二、Model 3总线信号破解 ...其实Model S/Model X我们也有破解，只不过一个‘年代’久远（两年？）、一个Model 3才是当红炸子‘车’呀，这是她应得的荣耀... 在开始之前，我们先来看下以前文章中的铺垫： Private CAN（即PARTY CAN），连接驱动模块、AP，底盘的转向、制动，推测承载车辆最基本、也是最主要的驱动、底盘控制等功能模块信息交互——再多说一点，这一路在不拆车的情况很难接入；? Vehicle CAN，连接三大车身控制器、高压管理模块以及VSC（Security Controller），推测主要实现传统车身域功能（负载控制、空调、进入退出）以及高压管理——这一路也是最容易accessible的，用不着拆车；? Chassis CAN，相比来说这一路是最传统的，连接了制动、转向、气囊等。 我们此次介绍的是Vehicle CAN的内容——以下数据整理均基于Model 3进口版LR RWD v10.2(2019.40.50.7）。 之前也没有“介绍总线设计”这类的经验，我想了下，从两个方面展开吧。一个是总体情况说明、一个是典型工况数据展示，其他的如果有更专业的解读或是需求，可以根据文末的提示进行沟通。 1、Model?3 Vehicle CAN总体情况说明 ????（1）ID分布从0x0C~0x7FF（未发送诊断请求）、总计280帧报文 图4 Tesla Model 3 Vehicle CAN CANoe Trace窗口概览 感觉报文帧数还是多（我没太多的概念，搞网络设计的可以来说一说），信号更是多如牛毛，稍后我们会看破解获取的信号情况。 ????（2）该网段负载率最小38%、最大55%、平均能达49%！ 图5?Tesla Model 3 Vehicle CAN负载率状态（冬季夜晚正常行驶工况） 物尽其用、物还没尽其用！ ????（3）根据破解的信息可知，Model 3中大量使用了multiplexing类型，比如实时性要求不高的状态量；各节点与DTC对应的‘当前’故障状态——我个人推测后台使用的是这个数据实时获取车辆状态而非诊断请求；以及结构化的节点报文帧结构，详见下图。其中alertMatrix即当前故障位、info则包含版本/生产等track信息、status及ECU节点的系统状态信息。 图6?Tesla Model 3 Vehicle?CAN中EPB Left发送报文matrix示意图 ?