2019-2020年间，在分析中央&区EEA时（尤其在看待车载中央计算机时），默认该零部件总成实现的是L2+级智能驾驶，没有考虑冗余控制器（或者相关的eBOM）；而智能座舱+智能网联方面，我们是参考特斯拉CCM的思路，还是把独立的IVI控制器板子和LTE控制器板子，与Autopilot控制器（智能驾驶域控）板子一起，通过叠板的方式，封装在同一个外壳里而已。从部件总成上，是一个零部件，但是其实还可以认为是三个独立的控制器，如链接ADAS/AD专题-1万字讲透面向量产的整车电子电气架构演进。
但是，两年过后，我们没有预想到SOC能发展这么快，连Thor这种整合智驾&座舱的巨型SOC都规划出来了，更别说某通甚至会把基带芯片（智能网联功能）也给塞进去，那可真的是“智能驾驶”+“智能网联”+“智能座舱”的三位一体的智能化了。今日之《车载中央计算机》，可比两年前说的《车载中央计算机》，内涵更丰富了，集成度更高了。因此，是时候做新的假设了。
那么，面向L3-L4的高阶智能驾驶、并集成了智能座舱域控制器的车载中央计算机该长什么样呢？
按照之前文章的一些结论（ADAS/AD系统方案05-L3高阶智驾系统怎么设计），在不考虑中央&区架构（没有融合了智驾&座舱的中央计算机）前提下，要实现较高性价比的智能驾驶系统，采用两个子系统（比如一个camera-only子系统，和一个Lidar/radar子系统），可能是个不错的方式。在任意一个子系统失效后，都能支撑路边停车MRM（为什么做到路边停车就足够了，分析详见ADAS/AD系统方案05-L3高阶智驾系统怎么设计）；两个子系统都正常工作时，又能撑起全传感器的感知运行（默认这样就能搞定脱手/脱眼），有个完整的性能表现。
但是，以上分析都是在控制器层面进行讨论的。在PCB板层面，考虑到外壳和液冷系统的配套，大概率是两个单独的控制器板子封装在同一个外壳中（类似特斯拉CCM总成），每个板子都有对应的主SOC分别承担camera-only系统及lidar/radar子系统的计算。
在芯片层面，应该是没必要区分出两个型号的SOC，用两颗同一类SOC就行。但是接口上，和后续的数据量处理上，既需要SerDes-MIPI-ISP-CV-NPU等视觉处理IP核，可能也需要DSP等能做Lidar/Radar的原始数据或点云数据FFT的处理单元，保持通用性。
但是，如果是以终局思维来思考，比如，已经可以用上类似Thor这样的芯片（甚至把基带芯片也集成进去的SOC？），该怎么做智能驾驶系统的Fail-Operational呢？
首先，类似Thor这种芯片，是完全没必要进行双份冗余的。座舱+网联都不需要。成本不划算。但是，毕竟是个超豪华的中央计算机芯片，所以单颗SOC所形成的主控制器（board A）将目前主流的11*Camera + 1or3*Lidar + 5*Imager Radar + 12*USS + 1*DMS都处理了，应该完全没问题。只要这颗SOC正常工作，做到脱手/脱眼/脱脑都完全没问题了（其实是假设，我也不清楚最终能不能搞定）。
那么就需要另外一颗只支持智驾的SOC，来构建冗余备份系统（board B）就够了。而且，由于我们只需要做到靠边停车（原因见上文的文章链接），考虑到需要做变道操作，需要360°感知能力。那么就打比方，选一颗能够驱动6V（Front Main + Corners + Wings + Rear，且这些摄像头都与主系统共用）的SOC就够了。当然也可以选一个Lidar/Radar处理的SOC做备份系统，不过由于道路几何信息检测可能差一些，所以还是建议构建一个camera-only系统做备份。
以上，将单独供电的board A 和 board B，封装在同一个外壳里（叠板形式），形成一个真正的支持高阶智能驾驶的《车载中央计算机》，配合ZCU（或者叫VIU），形成面向终局的中央&区EEA。
稍等，上面的这个《车载中央计算机》，其实是面向智能化方面的范围，比如智能驾驶+智能网联+智能座舱三方面，而且更多是AI加速相关能力的集中。但是，两年前我们讨论《车载中央计算机》时，还把中央网关+车身域控制器（有点像VW的ICAS1？）也纳入到《车载中央计算机》的范围里来了。但是，这个承担“中央网关+车身域控制器”功能的组件，是以芯片的方式（比如S32G这种？），整合到有类似Thor芯片的Board A（主控制器板子）上，还是以一个单独的板子（我们就叫他Board C）存在，现在说不清楚。也有可能“中央网关+车身域控制器”功能会被分散到ZCU中。
但是，搞《车载中央计算机》，总会有个缺点，就是这个计算节点太重要了（而且承载的功能也太多），一旦失效会造成车辆系统出巨大的问题。因此，乍看起来，都会觉得太强调中央集中，也不太好。比如，假如采用了“中央网关+车身域控制器”功能的组件，整合到有Thor芯片的Board A中的方案，一旦Board A出问题（比如供电），那可就不是智驾功能要降级的问题了；车机也要挂，车身域也要挂，网关也要挂。
但是再进一步分析和澄清的话，会发现，只有智驾有Fail-Operational（冗余）的说法。其他一些系统，比如车机、车身控制器、网关这种，只要满足对应的功能安全等级就可以了，没有Fail-Operational的说法。从这个角度看，只要Board A（咱们在这就假设是Thor + S32G3 + MCU这种配置吧）的功能安全等级足够（比如整个板级系统能到ASIL-D），那就算很安全了，没必要再搞个Board C，这样也能够进一步减少PCB板子的使用，提高集成度。
有了新的、集成化程度更高的SOC前提下，总结下可能的车载中央计算机形态吧！
两个子板（也可以说就是两个域控制器），A板为主板，B板为备份板；都封装在同一个外壳里，复用同一套液冷系统；
A板集成类似Thor主芯片+智能网关芯片+MCU，形成智能驾驶+智能网联+智能座舱+中央网关+车身控制等真正意义上的车载中央计算机；当然，如果有一颗比Thor更疯狂的SOC，直接就能把网关功能也做进去，那更完美，单颗SOC，加个小小的MCU，搞定；
B板集成一个类似特斯拉FSD芯片的SOC，处理好camera-only智能驾驶系统的冗余备份计算，实现适当的MRM（我这里的一系列文章，都假设实现的是靠边停车MRM）；
由于集成度非常高，而且用了叠板，车载中央计算机与目前有些多SOC的、长得像个游戏笔记本一样的DCU，长宽可能会缩小，厚度可能会更厚一些（叠板），安装在副驾驶手套箱后面。
问题是，这种超大型SOC设计实现起来，很复杂，挑战很大。
即便是问世，对使用方（OEM和Tier1等供应商）也是个能力上的挑战。因为集成了太多的功能，原来这些功能都是又不同部门的人来分别搞的，现在为使用好这颗芯片，需要对组织架构进行整合调整，也不会太容易。原来都有自己的对应代码，现在都要统一集成到一个大系统软件中，导致系统架构设计、软件架构设计和集成很复杂。
联系客服
