域架构的前世今生

如大家所知，“远古时期”的汽车电子电气架构起源于分离式架构，也就是德美日韩四大车企巨头横行七大洲八大洋的时候，为了更高效地产出质量稳定的产品，巨头们更多选择将相关的“结构模块”和“电子模块”绑定给同一供应商开发，也就是我们通常所说的“机电一体化”，或者汽车行业中的"系统总成供应商"，而其中的原因，仅仅是因为这个供应商对此功能的集成方式较为精通。然而，为了能用最小成本服务不同的车型，总成供应商会将他们系统打包成“平台”，提供给他们的甲方。当各个厂商的平台凑在一块的时候，自然而然地就形成了下图中的分离式架构。

■  无法打破的供应商开发体系壁垒

很难有单个供应商有能力做到“整车级功能完美集成”，例如擅长三电体系开发的公司，在自动驾驶算法面前捉襟见肘；而精通算法的公司，往往又没有汽车行业的开发资质。正所谓术业有专攻，成熟的系统研发体系下，本身就不太可能会存在技术垄断。

■ 整车需求定义中无法避免的矛盾命题

当一个系统的复杂度较高的时候，需求定义势必会发生自然冲突。举一个最简单的例子，我们既要实现纯粹集中式，又要实现高等级的功能安全时，一定会出现矛盾。比如，我们现在假定，某车只有一个中央控制大脑VC，那么，当VC在驾驶过程中出现严重系统宕机问题时，有没有其他控制器能取代大脑做整车级的功能调度？如果可以，那么这个控制器能替代VC多久？此外，VC和执行器之间的通路线束如果发生故障如何处理？本地控制器要做多少备份逻辑？重要的传感器单元又需要多少算力？

■  软件开发过程中的生态问题

汽车行业中的软件体系在数十年的闭环开发模式中，软硬件强相关，形成了一个过于封闭的环境。甚至有人戏称，汽车里面一个小小的车窗控制算法对操作系统的要求，比航天航空的自动巡航功能要求还高。大家知道，车窗控制算法当然不可能比自动巡航更复杂，其根本原因，还是因为整车软件的可移植性较差，软硬件无法做到解耦，每次更换一个小小的芯片都会伤筋动骨、大动干戈，动辄就会涉及到数百万甚至上千万的研发费用。所以，纯粹集中式这种要拆臂断腿的操作，自然不适合目前的整车电子电气架构了。

在发现“分离式”和“纯粹集中式”都走不通的时候，“功能域”和“区域”的概念就诞生了。

那么，域架构下，

我们的开发模式会发生什么样的变化呢？

｜基于服务架构(SOA)的功能开发｜

■  上文在集中式方案介绍的时候有提到，很多人认为某一些功能在没有统一的集成环境下，是无法实现的。这个观点并不完全正确。其实我们缺的并不是统一的集成环境，而是一个统一的生态。

就拿现在风头浪尖的“IOS”和“安卓”之争来做例子，两边是拳头撞拳头，完全没办法握手的两个操作系统，甚至连编程语言都无法做到一致（JAVA、Kotlin和Swift）。但是，我们在用手机产品的时候，很少会发生华为手机上的微信无法给苹果手机发消息，或者某个APP在华为手机上能安装，但是在苹果应用商城里却找不到的现象（某些冷门APP除外）。

你可能会说，那是因为APP开发的供应商做了妥协，两边都做了同步开发。那么，咱们再想想，现在互联网行业更新迭代的惊人速度，几乎每个月都会在“双端”推出日新月异的更新，这种效率，真的是靠妥协和努力能在做到的么？

■  其实，答案就在这一章的标题里，虽然两者的操作系统不同，但是，当他们的底层模块能打包成统一的“服务接口”，即使“语言不通”，他们依然在同一个生态里。比如蓝牙的协议一旦固定，在任何操作系统和环境下，我们都能用统一的查询方式，去操作蓝牙的扫描、广播、连接、配对，进行一些基础的功能执行，例如电量查询、设备信息、故障模式。

我们在开发过程中，看到的不再是一张张接口表，告诉你这个信号代表电量，如何解析，另一个信号代表故障，参考故障手册可以知道其含义。相反，我们看到的是一个个服务，今天，这个服务来自安卓或IOS的蓝牙模块，叫做“电量查询”，调用这个服务，返回的百分比可以直接显示在智能屏幕上，不需要做任何处理。

｜区域控制器的优势｜

■  正如我们上一期提到的，区域控制器给整车带来的潜在效益非常惊人，例如Tesla的区域控制架构为其平均线束重量减少了接近40%之多。同时，相比传统分布架构，区域架构的线束不会出现因为“又长又软”而导致必须需要人工组装的情况，换而言之，线束的减少使整车总装线上更多的自动化工艺能付诸实现。

■ 同时，由于功能和硬件的解耦，所以我们可以在Function Allocation上提供更多的自由。例如，未来的外灯、雨刮、锁、钥匙、车窗、电动尾门可以不再是车身控制器BCM的独有标签，而扭矩控制、能耗管理、挡位切换、驾驶诊断也不再是动力控制器EMS/VCU的专属功能。

换句话说，未来的区域控制器不会以功能命名。一方面，区域控制器会更关注整车级或架构级的应用设计，例如上一期提到的，整车供电中心、信息中心和驱动中心，另一方面，由于功能上移和SoA的实现，区域控制器可以集成BCM、VCU、Gateway、DCM甚至部分高功能安全模块，例如EPB和iBooster的输出逻辑，这就意味着，ASIL C/D中要求的控制单元级的冗余设计不再遥不可及， Zone和Zone之间可以做互补备份，当某一个区域控制器或iBooster发生故障时，另一个区域控制器可以直接做故障监控以及紧急接管。

■ 除此之外，Zone在整车架构中能起到“承上启下”的作用，上接Vehicle Computer，下接各个单元控制模块，可以将算法和输出完全解耦，就像RTE层在AUTOSAR架构中的作用一样，对平台的拓展性、可移植性、灵活开发性有着极大的提升。

那么，区域架构对软件开发而言，

又能有什么样的好处呢？

其实这个问题很好理解，软件和功能开发的未来趋势一定会趋向于集中化。而区域架构这一步，正是Vehicle Fusion的神来一笔。

■ 首先，正如上文提到，由于区域架构可以将功能域淡化，意味着电子电气架构级的ECU可以实现如AUTOSAR软件架构中的“抽象化”的概念。在整车的茫茫软件海洋中，我们不需要通过功能、信号、驱动去定义功能部署，所有的软件功能可以原子化，成为一个个独立的服务，不同的Zone之间的调度通过Vehicle Computer来实现，而VC和Zone又能按需组成集群，和传统的架构相比，存在着无限升级的可能性。

举一个稍微简单的例子来看一下，原来我们的经典开发模式是通过V模型形成开发矩阵，从架构和系统到硬件和软件，最后再回到测试和验证，再佐以ASPICE、Fusa以及Cyber Security的开发，形成一个坚不可摧的闭环。而这种开发模式比较依赖于串行合作，下游对上游需求的依赖性较强，同时也对相关件的要求较高。例如，如果没有整车级的系统需求，比如dbc缺失和故障，会导致整个软件开发进度的延迟。

■ 而全新的基于Zone和SoA开发模式，并不是要打破原有流程，而是在串行合作的同时增加了平行合作的可能性。在开发初期，软件可以根据平台需求先行进行服务和集群的开发验证，按软件需求定义服务接口，再反向传递给架构开发。同时，架构在接到Service Provider方的接口描述后，再进行跨控制器、跨Zone级的功能分配和调整。也就是说，在服务开发的流程中，架构、系统、软件、硬件的V字模型是同时在运行的，同时相互影响和验证。这种开发模式非常灵活，而且极其敏捷，相对于传统模式，平行开发不会畏惧任何新的变更需求，因为服务的抽象化能够将关联影响压到最小，变更和验证周期也可以大幅度减少。

■ 同时，在开发过程中，如果出现设计溢出（软硬件的设计无法满足系统需求，例如I/O口资源不够，CAN通路数量不足，通讯速率，存储空间溢出等问题）。在原有架构开发中，设计溢出常常会给功能开发划上句号，因为硬件变更成本过高，所以需求只能做妥协或降级，并且将溢出部分的设计延迟至下一代的平台开发。而在Zone开发过程中，由于软硬件解耦的实现，即使出现了设计溢出，也可以通过Zone Duplicate的形式，将设计延伸以满足溢出的需求。换句通俗易懂的话来说，如果三个Zone无法解决问题，那么就再来第四个Zone。

当然，Zone Duplicate并不是简单的硬件相加，增加部分的软件和服务的验证还是需要的，而在Zone开发的平行合作模式里，只需要新开一个小小的任务包即可，并不需要做伤筋动骨的大回归。

｜小结｜

纵观历史，其实大家对开发的认知和定义一直在进化，区域架构和功能域一样，是开启下一代跑道的重要里程碑。定义汽车的不仅仅只有软件，架构、服务、硬件、流程、质量，只有当这些融合在一起才能真正定义汽车。未来的某一天，如果我们的服务能够组成切面，打破天机，迈向云端，那时候，相信每辆车都可以成为一个移动的服务站，实现真正的车路协同，成为我们值得信赖的第二起居室。

很显然，我们离这个目标还有很长一段路需要走，但毋容置疑的是，未来的车会更像移动的智能手机，而我们的电子电气架构也逐步会向互联网趋势发展。然而，即使是5G时代和自动驾驶竞争全面到来的今天，仍有这样几个问题值得深思：车云互联下，算力和功能如何分配？新的架构如何定义？云计算是否真的能深入嵌入进整车电子电气架构，而非现在简单的软件刷新和远程开关门？SoA的服务提供方Service Provider能否部署云端？没有网络的地方如何保障功能实现？因人工智能和机械学习的训练盲区而导致的意外事故，是车主需要负责，还是开发者需要承担责任？

这些问题，我会在下一期的架构设计里继续和大家探讨。。。