从控制器的管脚定义看特斯拉Model 3的功能分配 - LBCM篇
从控制器的管脚定义看特斯拉Model 3的功能分配 - BCM RH篇
从控制器的管脚定义看特斯拉Model 3的功能分配 - FBCM篇
从控制器的管脚定义看特斯拉Model 3的功能分配 -Autopilot+MCU篇
从控制器的管脚定义看特斯拉Model 3的功能分配 - 电机控制器DI篇
从控制器的管脚定义看特斯拉Model 3的功能分配 - HV Battery篇
上述系列文章可以说是从整车硬件接口层面对主要控制器进行了梳理，而“软件接口”根据我们所获取的Vehicle CAN的报文、信号设计也在之前的一篇文章里面有提及，详情可参考，
干货！
特斯拉EEA跟踪研究者不愿错过的一篇文章
注：“软件接口”的概念是与硬件接口对应，便于理解；实际指矩阵设计。
后面陆续有朋友交流特斯拉电子控制器的软件架构？说实话有点惶恐...一是因为确实还在学习中，尤其是娱乐等带操作系统的——传统ECU的开发模式倒还容易理解，毕竟有点传统ECU的软件开发经验；一是特斯拉此类信息极少对外（无论官方还是非官方渠道）...所以今天主要会以我目前了解到的信息跟大家做个分享，一方面是尽可能展示源头信息、一方面根据个人的理解做的‘推测’，仅供参考。
首先最直接的一个信息，是网友Chiphead4u于2018年8月19日发表在m.blog.naver.com上的一篇文章，
根据根据公开的资料信息，包括GitHub（Buildroot，Linux Kernel）、Blackhat等，推论并重构了特斯拉的娱乐系统及Autopilot的软件架构。
作者还提到
汽车电子更注重安全性。因为它是基于Ubuntu系统，因此LSM（Linux Security Modules，Linux安全模块）似乎采用的是Ubuntu的AppArmor而不使用最强大的SELinux。此外，它似乎通过删减Ubuntu中的coreutils、并采用busybox来进行瘦身。
特意找朋友根据Nvidia Tegra的信息确认了下，
仪表 Tgera 2/中控 Tegra 3/AP Drive PX 2
18 年 3 月前的 S/X
HW 2.0
虽然时间久远、有部分是黑匣子，但还是有些帮助了解特斯拉内部的软件架构。
其次，是一次关于动力系统的研发人员构成的电话采访（来源记不清了），
动力系统的硬件和软件是两个不同的团队，但彼此非常接近。
在动力系统硬件团队中，有负责BMS，充电口以及电机的。充电机和充电口结合相当紧密。硬件团队有自己的硬件测试、集成和发布回归。早期的工程师完成了所有的工作。动力系统的硬件研发团队不超过100人。
软件团队则分为充电机，BMS和电机。每个团队都有一个首席工程师、软件工程师和测试工程师，然后集成测试下面有动力系统集成团队。
系统架构团队则完全独立于上述人员，他们进行动力系统架构设计，也有自己的测试团队；每个团队有5个软件开发工程师和3个软件测试工程师。
可以看出，团队里面有硬件、软件、系统和测试，最与众不同的可能是为数众多的软件、测试工程师吧。
最后跟大家同步下绿神关于特斯拉采用的Linux系统的一些看法。
很高兴特斯拉在没人提醒情况下将20.4.10（内核）源码上传到GitHub
特斯拉是否大幅更改了Linux？
更改的不太多，我们可以看到他们试图最小化和本地化他们的更改，以更容易地跟踪供应商的内核，并减少他们自己的努力，以保持一切都是最新的和安全的。
特斯拉选择Linux作为娱乐系统的操作系统，那很明显意味着他们必须共享他们针对GPL部件（包括Linux内核）做的更改。
参考资料：
1.https://github.com/teslamotors
2.https://www.blackhat.com/us-17/briefings/schedule/#free-fall-hacking-tesla-from-wireless-to-can-bus-6415
3.https://twitter.com/greentheonly
相关精彩推荐：
汽车架构框架：沃尔沃汽车的经验
干货！
特斯拉EEA跟踪研究者不愿错过的一篇文章大众“MEB平台”与“软件驱动的企业”：缓慢拉开的巨幕？
