域架构的演进
域架构的前世今生
如大家所知，“远古时期”的汽车电子电气架构起源于分离式架构，也就是德美日韩四大车企巨头横行七大洲八大洋的时候，为了更高效地产出质量稳定的产品，巨头们更多选择将相关的“结构模块”和“电子模块”绑定给同一供应商开发，也就是我们通常所说的“机电一体化”，或者汽车行业中的'系统总成供应商'，而其中的原因，仅仅是因为这个供应商对此功能的集成方式较为精通。然而，为了能用最小成本服务不同的车型，总成供应商会将他们系统打包成“平台”，提供给他们的甲方。当各个厂商的平台凑在一块的时候，自然而然地就形成了下图中的分离式架构。
分离式架构发展了近数十年，其中不但诞生了大名鼎鼎的大众MQB平台、通用Global系列平台，也孵化了一系列出色的供应商体系，如博世、大陆、德尔福，都是在这个大环境下成功地巩固了自己牢不可摧的行业竞争力。然而，随着行业技术水平的不断发展，集中式架构的方案更多地开始呈现在OEM和Tier1的会议桌之上，起初是为了优化整车研发成本和效率，而后是因为大家越来越意识到，某一些功能，在没有统一的集成环境下，是无法实现的。
上面两张图，就是近十年来集中式架构方案里最常见的讨论缩影，大家想要的是左图里展示的那种纯粹集中式(Pure Centralization)，即一个中央电脑Vehicle Computer实现所有的功能，其余部分是执行端和采集端，也就是大家熟知的“功能上移”。而到了落地阶段，却往往只能做到右图的多端集中式(Multiple Centralization)，其根本原因有以下三点：
■ 无法打破的供应商开发体系壁垒
很难有单个供应商有能力做到“整车级功能完美集成”，例如擅长三电体系开发的公司，在自动驾驶算法面前捉襟见肘；而精通算法的公司，往往又没有汽车行业的开发资质。正所谓术业有专攻，成熟的系统研发体系下，本身就不太可能会存在技术垄断。
■ 整车需求定义中无法避免的矛盾命题
当一个系统的复杂度较高的时候，需求定义势必会发生自然冲突。举一个最简单的例子，我们既要实现纯粹集中式，又要实现高等级的功能安全时，一定会出现矛盾。比如，我们现在假定，某车只有一个中央控制大脑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能否部署云端？没有网络的地方如何保障功能实现？因人工智能和机械学习的训练盲区而导致的意外事故，是车主需要负责，还是开发者需要承担责任？
这些问题，我会在下一期的架构设计里继续和大家探讨。。。
文章来源：联合电子微信公众号