作者: 下午9:03 特斯拉, 资讯

干货!特斯拉 EEA 跟踪研究者不愿错过的一篇文章


*本文转载自微信公众号《冷酷的冬瓜》,转载请联系作者。

上篇文章的最后预告了这篇文章的存在。


一晃眼十来天过去了,期间陆续有朋友找上我咨询一些事情,为几个做行业调研的朋友准备了一些材料,也为文章需要的数据做了一些分析准备。感觉在老家的日子过得又快又慢?对了插播一则消息:这个月过完,我就正式失业了…想一想还有那么点小激动呢。

好了,言归正传。

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

我们依次展开描述。

Model 3 Communication Architecture 的新发现

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

特斯拉 Model 3 网络拓扑图_20191215

补充了哪些内容呢?

1、几大核心控制器的「Enclosure」(封装)内部原理


包括 BCM Left/Right、Autopilot+MCU(Media)、HVC(High Voltage Controller)、EPS 等,最典型的莫过于连接超声波雷达的 BCM Right 了——强行「Single Enclosure」——根据这些原理、可以很清晰地了解到特斯拉的设计思路。

2、明确了同一网段、同一控制器占用不同管脚的「事实」


这么说可能有人不理解,大家可以先看下面的示意图:

特斯拉 Model 3 右车身控制器网络连接示意图

这种连接方式,如果只根据整车原理是看不出来差别的——因为它们是占用了不同的管脚但同时它们也是同一个网段。这点可以在第二章节中的报文记录中得到佐证。特斯拉对这种设计「乐此不疲」,本质是将线束钉点放到了 ECU 板端,出于线束分区的考虑。

3、定义了不同节点的唤醒行为并区分了「Powered during vehicle sleep」


这就是系统工程师应该做的,而且很方便在拓扑图里面体现的内容。

特斯拉没去扯什么网络管理,就告诉你:这个节点的这个网段需要网络唤醒,那个节点需要在整车休闲状态下仍然供电,直击问题本源。

4、标明了控制器的供应商


我这里做了简单的汇总。

Tesla Model 3 控制器供应商分布饼图

据上图的不完全统计,特斯拉自研的控制器占据了大半壁江山!

当初还只是自研核心的三电、中控以及 AP,现在连车身控制器这种低门槛的也不放过(当然还有其他比较重要的,像是 Security Controller),简直丧心病狂!

除非真有两板斧(掌握核心技术),控制器供应商的日子不好过啊。

5、当然还有余下细枝末节的,比如终端节点的设计、选装节点的设计等等。


Model 3 总线信号破解

其实 Model S/X 我们也有破解,只不过一个年代久远(两年?),一个 Model 3 才是当红炸子车呀,这是她应得的荣耀.。

在开始之前,我们先来看下以前文章中的铺垫:

Private CAN(即 PARTY CAN),连接驱动模块、AP、底盘的转向、制动,推测承载车辆最基本、也是最主要的驱动、底盘控制等功能模块信息交互——再多说一点,这一路在不拆车的情况很难接入; 

Vehicle CAN,连接三大车身控制器、高压管理模块以及 VSC(Security Controller),推测主要实现传统车身域功能(负载控制、空调、进入退出)以及高压管理——这一路也是最容易 accessible 的,用不着拆车; 

Chassis CAN,相比来说这一路是最传统的,连接了制动、转向、气囊等。
冷酷的冬瓜,公众号:冷酷的冬瓜从控制器的管脚定义看特斯拉Model 3的功能分配 -Autopilot+MCU篇

我们此次介绍的是 Vehicle CAN 的内容——以下数据整理均基于 Model 3 进口版 LR RWD V10.2(2019.40.50.7)。

之前也没有「介绍总线设计」这类的经验,我想了下,从两个方面展开吧。一个是总体情况说明,一个是典型工况数据展示,其他的如果有更专业的解读或是需求,可以根据文末的提示进行沟通。

1、Model 3 Vehicle CAN 总体情况说明


(1)ID 分布从 0x0C~0x7FF(未发送诊断请求),总计 280 帧报文。

Tesla Model 3 Vehicle CAN CANoe Trace 窗口概览

感觉报文帧数还是多(我没太多的概念,搞网络设计的可以来说一说),信号更是多如牛毛,稍后我们会看破解获取的信号情况。

(2)该网段负载率最小 38%,最大 55%,平均能达 49%!

Tesla Model 3 Vehicle CAN 负载率状态(冬季夜晚正常行驶工况)

物尽其用,物还没尽其用!

(3)根据破解的信息可知,Model 3 中大量使用了 multiplexing 类型,比如实时性要求不高的状态量。各节点与 DTC 对应的「当前」故障状态——我个人推测后台使用的是这个数据实时获取车辆状态而非诊断请求,以及结构化的节点报文帧结构,详见下图。

其中 alertMatrix 即当前故障位,info 则包含版本/生产等 track 信息,status 及 ECU 节点的系统状态信息。

Tesla Model 3 Vehicle CAN 中 EPB Left 发送报文 matrix 示意图

(4)破解程度为 66.4%(186 fr / 280 fr),另有某个需要「深度 benchmark 特斯拉 Model 3」客户的信号需求的匹配度分析如下图。

总体来说可利用的信息比较丰富。

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

注:

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

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

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

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

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

2、典型工况


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

1.整车状态(驾驶行为、驻车、踏板、里程…);
2.电机+逆变器(转速、扭矩、温度…);
3.电池(母线电压、电流、SOC、放电能力、电芯状态(电压、温度、一致性等)…);
4.高压附件状态(DCDC/OBC…);
5.空调总成 HVAC+ 热管理…;
6.其他(比如车身舒适的 BCM Left/Right/Front…)。

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

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

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

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

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

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

(4)慢充

车辆静置、慢充数据记录 graphic

最后,为了更好地搜集各位的需求、更精准、更高效地沟通,我们建立了自己的「知识星球」:冷酷的冬瓜,后续高质量、高价值的信息可能会唯一渠道或是优先在「知识星球」发布。

惯例,对「Tesla Model 3 Communication Architecture」以及「特斯拉Model S/X/3 的总线信号破解」感兴趣的,欢迎来「知识星球」找我。



(Visited 55 times, 1 visits today)
标签: Last modified: 2020年2月25日