功能域的由来及域控制器

域和电子电气架构是德尔福发明的。根据欧洲ITEAEAST-EEA项目的术语，域被定义为“一个包含知识、影响范围和活动的球体，其中有一个或多个系统待处理（例如待建立）。”这个术语可以被用来作为一种手段，把机械系统与电子系统组合起来。域在工程师实践过程中的具象化体现在整车不同CAN网络的划分上。功能域与CAN网络是不同概念，但是范围上大致是对齐的。

汽车上安装的ECU较多，但是一个CAN通信网络的带宽有限，因此汽车网络架构工程师在ECU在进行组网时，需要考虑ECU功能的相关性。比如，将动力相关的ECU组成一个网络（动力CAN），因为动力相关ECU搭载的功能，对实时性要求比较高，因此用高速CAN网络；将座椅、车窗、车门等车身机构的相关ECU组网，形成舒适（车身）CAN（也就有了车身域），车身域的ECU对实时性要求不高，所以一般用低速CAN网络搭建。同理，底盘域就是跟汽车行驶相关的一些ECUs，例如ABS（防抱死）、ESC（电子稳定控制）、EPS（电动助力转向），组成了底盘CAN…跨域的通信，就通过网关转发。

域控制器

当汽车智能化成为趋势，消费者越来越认同这种趋势并愿意为这个趋势买单时，“正义”（生产力）就产生了。企业只要愿意往这个方向投入，就会收获更多利润和市场份额。

因此，对于更多更复杂的功能的“正义需求”（发展趋势）就产生了，例如自动驾驶功能、智能座舱功能、车联网功能等。为了迎合这种趋势，对能够“承载”这些复杂功能算力的计算单元就产生了。域控制器就出现了。个人认为，域控制器出现的最初逻辑并不是为了减少车辆ECU数量而存在的，而是为了整合数据、增强计算能力而生（参见博世、大陆、安波福、维宁尔、采埃孚-天合等在L0-L2有量产件的巨头Tier1们对域控制器的定义就知道，域控制器只是做传感器数据融合以及TJP和HWP等高端feature的控制器而已，他们直接定义域控制器为集中式控制器，将感知都拿到域控制器里做，让人家的MPC2、IFV400、LRR、MRR等Smart Sensor还怎么卖？自家推出的产品抢自己的地盘吗？相反，一些没有L0-L2级别分布式smart sensor产品的Tier1，在推域控制器时更加倾向一步到位，直接上域控制器+卫星传感器方案，把计算集中化做的更彻底）。但是一旦实施了这一步，人们马上就会在这个方向上“得寸进尺”，减少ECU数量、分布式向集中式演化也就顺其自然了。

域控制器仍旧是在基于按“域”划分的传统电子电气架构基础上的小迭代。相应的，OEM的组织架构设置上，仍旧是按照发动机（新能源OEM的“三电”部门）、底盘部、电子电器部、智能网联部等“域”的概念划分的。如果想按照中心&区控制（图1）等新型车辆EEA的方式去开发车辆，甚至按照软件的开发思路来开发（从按“域”分割开发任务转向按“层”分割开发任务，应用层、感知层、决策层、网络层、驱动层、硬件层、整车层等），恐怕开发任务丢到OEM组织里，工作也不好分配。

图1 丰田的按中心和区划分的EEA

域控制器之后

域控制器之后，就是EEA（以及EEA的实体-线束）的变革了。相关论述也比较多了，这里就不论述了。很期待Model Y的电子电气架构以及号称100米长度不到的线束。既省了线束，减了整车重量和成本；集中化的E/E也省了ECU，又省了成本；关键是，线束简化了，就减少了人工犄角旮旯的布线，提高了效率，马一龙的强迫症也减轻了（心心念的自动化产线又可以正常运行了），他梦想的智能汽车终于又从笨重的线束时代向半导体时代进了一步。

如果一个设备（机械液压设备）想软件化（软件定义汽车），一般要怎么搞呢？

首先要把机械&液压&结构平台做好（整车）；然后把半导体器件和电源&通信线束装上去（各种控制器和控制网络，软件角度的“硬件”，主要还是指“silicon”-半导体元器件，其实跟一大坨的钢铁机械部件来比，其实不算“硬”...），这个机械设备就有了“空的大脑”和神经系统了；然后再把操作系统、驱动安装进去，最后应用软件刷进去。以上“基础设施”搭建完毕，就可以软件化了。比如做系统设计时，比较少的关心各个功能的通信了，因为很多功能都整合在一个计算平台上了（比如行车电脑），通信也从控制器之间的通信转化为行车电脑中的板级通信和软件模块之间的参数赋值传值了。总线（比如CAN总线）需求最终应该会下降。画系统框图时，把机械液压件和半导体器件在系统框图里打包划到边缘角落，注上“硬件平台&外设”，然后从软件视角把软件分层细化，沾满屏幕，进行开发…软件定义汽车就实现了。哦不，还差一步，这些“硬件平台&外设”必须标准化，只有标准化了的硬件才能脱离封闭的“孤岛”（放弃抵抗），拥抱了“全球化”（为软件定义汽车扫清硬件“割据”的障碍），才有利于跨国公司（软件们）的资本（软件控制）在“全球范围内”（整个机械平台）展开。随着上述进程的推进，OEM的开发部门的组织架构也必须要跟着变化了。举个例子，在“域”的概念下，曾经汽车工程开发这块“蛋糕”是按照块来切的，切成5-6块，动力块、底盘块（如图2）…随着电子电气架构的集中化，以及ECU数量的简化，汽车开发就可以照搬软件开发思路，按层切了（图3）。听闻阿里与上汽的合作，深入到一定程度后，上汽就面临改革组织架构（成立合资公司，组织架构按软件公司来搭）。经济基础变了（客观应用的技术发生变化），上层建筑（生产关系组织方式）也得跟着变啊！

图2 按“域”下刀图3 按“层”下刀

目前“软件定义汽车”有难度，也就是因为以上的各种产品基础设施（车辆）和组织基础设施（开发部门架构）都需要改造，需要一个过程。最近大众在这方面动作就很多，一边喊“软件定义汽车”的口号，一边在组织架构上成立软件开发部门，大力招聘软件人员，并裁员其他类型开发人员；同时整合座舱域（见MEB平台首款ID3车型，如图4搭载大众自己操作系统的ICAS3信息娱乐系统），开发VW.OS操作系统，这是要聚合硬件、进行软硬件分离的节奏啊！操作系统这种东西，就是隔开硬件和软件用的吧？软硬件分离了，不就可以任性“软件定义汽车”了吗？感觉大众以IVI等座舱域开刀，就是为了植入自己的操作系统，随着座舱域整合成功，慢慢力所能及地“吃掉”车里面其他“域”的一些小功能，比如ADAS/AD中基于摄像头视觉的LCA换道辅助和BSD盲区检测这种。个人判断，最终整车要形成一个大的中央控制器（行车电脑）的话，趋势是往座舱域里并。或者像特斯拉那种，分几个独立的板子，有管信息娱乐域的板子，有管ADAS/AD的板子，甚至VCU的板子也可以放进来，搞一个大机箱封装（类似Model3的CCM中央计算模块）。

图4 大众的ICAS3座舱域系统