特斯拉EEA跟踪研究者不愿错过的一篇文章
来源:网络:冷酷的冬瓜    作者:商用汽车网    浏览:3704    2020-03-02 08:51:05




今天主要有两个议题,一个是关于特斯拉Model 3的“Communication Architecture”(网络拓扑图),我们有了新的发现;一个是我们一直在‘钻研’的Model 3的总线信号破解阶段性成果的展现。此次也是‘抛砖引玉’,希望更多的人参与进来‘参透’特斯拉的‘设计密码’。



一、Model 3 Communication Architecture的新发现


...这个新的发现其实是相比之前整理的网络拓扑图的补充——抱歉这个‘Communication Architecture’暂时不方便放在文章中,如果有兴趣的可以根据文末的提示进行沟通——我们先附上根据原理图整理而来的拓扑图。


图1 特斯拉Model 3网络拓扑图_20191215


补充了哪些内容呢?


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示意图


(4)破解程度为66.4%(186fr/280fr),另有某个需要‘深度benchmark特斯拉Model 3’客户的信号需求的匹配度分析如下图。总体来说可利用的信息比较丰富。

图7 Tesla Model 3 Vehicle CAN总线破解某客户需求匹配饼图

注:

1.无此信号:没找到相应信号,比如“12V电池SOC”;

2.无此信号但有相关信号:没有唯一对应的信号,但是通过其他信号可以间接得到想要的信号,比如“BMS故障等级”没有,但是有很多的alert(推测为与DTC对应的当前故障状态),可以参考;

3.有此信号但难获取:有信号定义,但不是从方便获取的Vehicle CAN监听,比如轮速信号;

4.有此信号且可提供更多:不仅有对应的信号,还可以提供更多的,比如“档位”不仅有整车逻辑档位,还可以提供换档杆物理状态;

5.有此信号且易获取:有对应信号且就在Vehicle CAN上,比如绝大多数的信号。


2、典型工况


...相信真正搞系统/性能/测试的会设计更多、更专业的use case,去挖掘更多的信息,我们这里只提供典型的工况。其中已知的信号包括但不限于:


    *整车状态(驾驶行为、驻车、踏板、里程...)

    *电机+逆变器(转速、扭矩、温度...)

    *电池(母线电压、电流、SOC、放电能力、电芯状态(电压、温度、一致性等)...)

    *高压附件状态(DCDC/OBC...)

    *空调总成HVAC+热管理...

    *其他(比如车身舒适的BCM Left/Right/Front...)


(1)车辆静置、中控屏操作


图8 车辆静置、操作中控屏数据记录graphic


(2)车辆静置、空调操作

图9 车辆静置、操作空调数据记录graphic


(3)车辆正常行驶(包含调头)

图10 车辆正常行驶(包含调头)数据记录graphic


(4)慢充