软件定义汽车时代电子电气架构的思考

过去汽车行业对软件没有那么的重视，原因之一是认知的问题。普遍存在观点是，汽车是1个轮子加4个沙发，靠硬件卖钱的。随着软件和整个ICT技术的发展，让汽车行业有了新的利润增长点。虽然软件在汽车上的比重越来越多，但大多数的汽车工程师并没有真正开发过软件。

最近两年国内兴起的电子电气架构，传统的架构非常简单，一个网关加几个控制器，并没有真正的架构设计概念。我做架构也是最近这几年，参与过一些项目，直到和瑞典人合作的时候，才见识到了架构的复杂性。

架构到底是什么？车是采集各种各样的输入信息，然后控制输出，做一些执行操作。小的如钥匙、开关，都是整车的输入，车上的发动机、各种电机都是整车输出。从整车的角度来看，中间处理的部分，可以由一个控制器完成，也可以由好几个控制器完成。从单独的一个控制器或一个功能来说，也可以使用IPO模型，其本质都是采集一些输入，控制一些输出，中间做一些逻辑的处理。从这个角度来看，我们现在变化的更多的是处理的部分，输入、输出变化的并不多。可能网联技术的应用，会增加输入的部分，比如一些移动数据。对自动驾驶来说，多的输入就是各种传感器的信息。在输入和输出在变化的时候，中间处理的部分也要做相应的变化。这些变化正是设计电子电气架构应该考虑的部分。

过去通常采用以中央网关为主的架构，在中央网关下面，带着一些控制器，底层还是输入、输出。现在很多车已经上了域控制器，域这个概念，在中文容易混淆，是按功能还是区域划分？目前通常是以功能划分的域。比如ADAS，信息娱乐，车身。我觉得这是由于目前的供应商体系和主机厂能力所决定的，只能这么分。因为跨域的功能整合，是需要大量的能耗和经验的。目前还很少有主机厂能做到把功能跨域整合。整合的前提是要把原来的控制器里的功能都抽取出来打散，然后进行软硬件解耦，最后再重新组装。这样操作起来的难度非常大，汽车行业过去几十年做的特别成功的东西，如果要一下子推到、重塑，是不现实的。

下一代是中央计算机的阶段，中央计算机往往要几个区域控制器。因为在中央有一个特别大的计算机，车上还有上百个传感器，执行器，这些不可能直接通过线束连接到中央计算机，这就相当有了一个中央政府，还得有很多区、县，把小的信号进行采集、处理，包括供电。处理完之后，通过高速总线输送到中央计算机。这也是目前车载以太网很火的原因，大家都在研究以太网延时和可靠性的问题。

最后可能是中央计算机，输出很多总线，每个区域有区域网关，区域网关和区域控制器不太一样。因为区域控制器还需要一些处理运算的功能。而区域网关只需要做信号的传输，这样车上绝大多数的线束就仅剩下电源线和总线了。然而这种方式目前还是有些距离，只有当芯片，尤其是大功率驱动芯片的成本足够低的时候，直接将芯片贴到每个电机或传感器上，这个理想才有可能实现。

对于架构的讨论，可能最多的就是网络拓扑图，觉得网络拓扑图就是架构。其实网络拓扑图仅是一个表象，就像一栋楼盖地好不好，不能只从外表去看，其实里面看不到的东西才是决定好与坏、先进与否的关键。还有一个是所谓的电气架构，指的是车上电器分布。一个电气架构需要考虑的不仅是控制器，还要考虑线速、电源分配，包括这些控制器在车上分布位置，还有如保险丝盒是什么样子的，这些都是电气架构需要整体考虑的。至于控制器里面的细节，如使用什么样的处理器，反倒不是电气架构优先考虑的。电气架构更像一张设计图纸，是顶层设计的工作。

而真正影响电气架构本质的东西，也就是冰山以下的东西，首先是功能架构。也就是这个电气架构要承载多少功能，比如所谓的L3/L4，不仅仅是等级的区别，更是它的功能和安全角度上不一样。还如一个普通的机械式的汽车仪表和一个12.3寸的全液晶的仪表，它们也不仅是表面上的不一样，更是本质上的功能不一样，12.3寸可以显示各种各样的信息，这是普通仪表不具备的。把这些功能搞清楚了，你想要做什么样子的功能，然后这些功能在整个架构下如何分配，他们之间如何关联，这些才是架构设计要优先考虑和解决的问题。随着功能的不断增加，电气架构也需要与之匹配地不断演讲。

最下层是软件架构，无论软件是使用C写的还是C++写的，只要实现上面的功能都是可以的。选择什么样的编程语言，工具链是要基于整个行业的生态、技术的发展等综合因素考虑的。

以上四个分法是我的个人总结，不同的人可能有不同的分法。架构是一个复杂的系统，可以有很多的维度，从不同的角度看，有不同的关注点。

整车的定义是从属性开始的，比如动力性、经济性、成本、重量等，将车辆定义出来，然后再决定搭载什么功能。比如设计一辆轿车的话，是不是要考虑四驱，是否要搭载辅助驾驶功能，这些都是功能层面的东西。硬件并不会为了装一个摄像头而去装一个摄像头，是为了实现某些功能而去装一个摄像头或者一个雷达的。汽车的功能定义，不仅要通过整车的配置表，还要做一件非常复杂的事情是这些功能之间的关联。比如门锁的功能要跟车速、自动上锁、碰撞之后的解锁，还有跟其他很多功能的耦合。然后再去考虑如何系统设计，包括软件设计、硬件设计等，最终才跑到了零部件层。

如上图，红线为主机厂的架构能力指标线，越往上，表明主机厂的架构能力越低，很多主机厂只能提出一张功能配置表，我想要什么功能，但是这些功能之间怎样关联，很多时候其实都是Tier1帮着做的。有像大众、宝马这样的OEM，在系统层面的设计能力是非常强的，我们现在看到的很多各种各样的方案，是由他们和一些Tier1 联合研发出来的。这些Tier1再跑到国内来，把方案变个样，卖给国内的主机厂。从这个角度讲，我们有了看起来与世界同步的技术应用，但是当你在使用的时候，人家的下一代早就已经设计出来了。所以，我们一直都在比人家落后不少。我们要想把架构设计好，要把这条线尽量往下走一走，把系统能力建设起来。

(模型化设计 + 数据链协同) 流程Ⅹ 数据化循环迭代+知识沉淀 = 高效协同研发体系

MBSE这个词，最近在汽车行业也特别火。简单说就是通过一些软件工具，把原来使用Word、Excel这种文本的表达方式，以模型化的方式呈现出来。文本最大的问题是每个人输出的东西，别人理解不一样。而通过标准化的模型呈现出来，可以减少歧义。无论是中国人还是日本人，画出来都是一样的，也不用翻译。不过这一块建设花钱比较多，花时间也比较多。但如果想把架构做好的话，还是有必要把基础能力通过MBSE这种方式构建起来。这样才能在将来通过模型随时修改一个功能，并快速进行迭代，甚至通过软件工具直接把模型转换成Code，直接刷到控制器里面。这样就实现了像智能手机这样，可以每天把程序升级一下。如果像现在这种模式，通过文本写出来，告诉供应商应该这么做，再去做个DVPV验证，迭代速度就不可能上来。

只有工具升级了，方法升级了，效率才能升级。这绝不是靠加班加点能实现的。

搞架构设计一定要把三个方面做好，PMT（流程、方法、工具）。

效能 = 效率（体系、流程）× 效果 （能力、时机）

体系和流程直接决定了你的效率，包括做事的快与慢，流畅程度。而如果仅是做得快快，但效果不一定好，效果是由能力和时机决定的。架构设计涉及到几百甚至几千人，一定要把体系、流程、工具方法建好。如果在工具上不舍得投入，只让工程师用一个Word、Office去做设计的话，如何能PK过使用先进工具的企业呢？

SDV现在有些像军备竞赛了，大家经常看到，这个公司在招了多少人做软件，那个公司成立了软件中心，又有哪个公司成立全球数字化中心。大家都在努力的往里头砸钱，圈人。但是，军备竞赛最后一定会有输家，而且一旦输了，损失会比较大，大量的财力物力付诸东流。

现在大家拼的就是人和财，你得有既懂汽车，又懂软件的人才。但钱也是不可或缺的，随便设计一个架构，要把车上这么多控制器重新做一遍，成本还是相当高的，原来仅是开发一个BCM，真实的投入可能就是大几百万甚至几千万。这样要根据是使用什么工具链，投入多少人，做的标不标准。假如一个控制器重新设计成本是1000万，车上几十个控制器，没个十亿八亿，是做不出来的，这还是在极其理想的情况下。想做好一个全新的架构，把所有的控制器都开发到量产的状态，车能够BUG比较少的上市，至少得几十个亿的投入。再加上软件中心的投入，现在养一个软件开发人员的综合成本至少100万/年。如果养1000人的软件中心，一年仅人员投入就10个亿。如果再加上工具链等其他的，一年得20个亿。五年、十年下来，可以想象这个投入是多少。

我一直特别反对996，整天推行996的公司，逼得要死要活的公司，肯定是架构没有设计好。这里不是说电气架构没有做好，而是组织架构、管理架构、工具架构没有做好。如果做的好的话，生活不应该是这个样子。

就像这条马路似的，一个车道是一个人，一辆车就是老板派的一个活，在车辆比较少的时候，整个车道的输出量还是不错的。在一定范围内是呈线性增长的。但是当车流量达到一定程度的时候，马路的通行能力就大幅下降。人的大脑也是一样，领导交代的人任务太多时，他就得不停地切换，效率就提升不上来。最后人崩溃了，公司效率也低下。

如果你要是觉得一件事不对劲的话，要么是你做事的方法错了，要么是这件事本身就是错的。生活本应该是流畅的，欧洲人每天喝着咖啡，每周工作35个小时，老板也不逼着996，做的东西质量仍然比我们好，说明他们长时间积累出来的PMT，也是有一定道理的。

要做好电子电气架构，先得做好组织架构，管理架构！