前言 01
近两年牵头参与了多个，基于SOA的全新架构项目。在和客户一起开展项目的过程中，也遇到了很多共性的问题。所以想借这个机会，和大家分享一下，希望对大家有所启发。有错误，不恰当的地方，欢迎大家指正。
开发过程中的痛点 02
近年来，由于汽车电子电气架构的快速迭代，很多主机厂都处于新老架构交替的重要时期，搭建一个全新的架构，对于任何团队都将是一个不小的挑战。任何新生事物的出现，都是对传统的革命，我们需要抱着积极的心态，至少在一定程度上打破原有的思维和框架，从而建立新的秩序。
在SOA架构设计项目中，无论是和主机厂，或是我们团队内部，都对项目开展了多次复盘总结，大概得出了下图中的这些共性问题。包括：“职责边界”，“传统和变革共存”，“服务是什么”......
这些问题需要从宏观上，或者从思维意识上，给予特别的重视。今天我们就——“职责边界”，来重点聊一聊。
我们知道，汽车电子电气是个异常复杂的系统，不可能由一个人，一个组织来完成。所以站在主机厂角度，梳理出正确的事情，然后把他们交给正确的组织来做，就显得异常重要。
当然这也涉及到公司的业务策略，对未来的定位，比如公司是否致力于主导打造完整的生态链，还是掌握核心的软件，还是仅仅专注于市场需求的理解及实现，等等。
无论如何，宏观的职责分工在一开始就需要规划清楚，否则所有的工作是没法有效开展的，就算开展了，也会逐步偏离初衷，变得难以控制。
职责定义 03
在我们讨论职责边界之前，应该先清晰一个问题，“职责由何而来？”，只有清楚了职责的由来，才能梳理出职责的准确定义，并进一步明确职责的边界。
为了得到答案，先让我们回到最初的起点，看看我们对车辆的定义是怎样的。车辆是仅仅作为交通工具，还是发展成为所谓的第三生活空间？无论是哪种发展方向，有一点是肯定的：车辆都是为人来服务的。
从下图中，我们可以看到车辆使用时的三个要素：环境，车辆和用户。车辆需要感知环境，来满足用户的需求。从这点来看，也能说明为什么把整个车辆作为系统的边界来定义用户需求。（环境和用户在这里都是广义的，我们就不展开了。）
接下来我们拨开车辆的外壳，进到车辆的内部，来看下车辆是如何感知环境来满足用户需求的。这个层级已经属于解决方案了，核心元素是传感器，ECU和执行器。
从上图中，我们可以看到，环境中的一切物理表象，通过传感器转化为对应的电信号，然后这些模拟电信号，传输到在ECU内部，转化为数字信号。然后在软件世界进行沟通，计算和分析，之后将控制指令转化为模拟信号。模拟信号传递到执行器，执行器遵照这些指令，结合自身的物理特性，执行器完成功能在物理世界的最终实现。这个层级看得见摸得着，传统的零部件供应商基本也是按照这个职责来划分。
对于传感器和执行器，目前的现状和趋势是各家的技术和方案逐渐趋同，以后应该是向标准化的方向发展了。当然这些不是我们今天讨论的范围，ECU才是我们今天讨论的重点。我们可以看到ECU在感知环境和满足用户的过程中起到了关键的分析与控制的角色，所以ECU才是满足车辆定义的核心元素。由此，也回答了我们之前的问题，当我们讨论架构开发中的职责，其实本质是溯源到ECU所承担的职责。
接下来我们再拨开ECU的外壳，到ECU内部来看看。这里我们提到的ECU是个泛化概念，对于用户，不太在乎是1个ECU还是100个ECU实现了他们所期望的功能。但是从架构的角度，我们需要评估需要有哪些ECU，这些ECU分别承担什么职责是最优化的。
我们详细来看看ECU可能承担的职责，这里将忽略ECU的中间件，应用层，操作系统......这些是用以 “实现” ECU职责的部件，但我们今天单讲 “职责”，不讲 “实现”。
在下图中，我们根据不同的职责，将ECU分成多个软件层级。
最底层的是Device (S&A) abstraction，这里是指传感器，执行器这些物理部件的抽象。
当我们和其他人进行沟通，或者协作时，首先要保证有同样的语言。如果都不能理解对方说了什么，好的沟通结果根本无从保证。
这里的Device (S&A) Abstraction其实就是这个作用，他们是在软件世界里对实际物理设备的抽象，或者说翻译。
除了Device (S&A) abstraction以外，其他的每一层都发挥着独有的作用，为了更好的理解ECU每一层所承担的职责，我们可以将他与人体机能进行类比，如下图所示：
- Device (S&A) abstraction：
这个最底层的作用就相当于人的双手，双脚，是最终接触这个世界的对象。 - Device (S&A) control：
这层就是对Device的控制，比如对天窗电机的控制，开还是关等等，类似于人手部的肌肉，控制手的活动。 - Gateway of communication：
这层主要是通讯的枢纽，类似于人的关节，连接身体的各个部位。 - Domain/zone level control：
这层是功能域控制，是对控制之间的协调。比如为了保证车身的稳定，需要考虑如何协调制动控制和转向控制。类似于神经系统，如何协调手脚，来保持身体平衡。 - Cross-domain/vehicle scope control：
这层就是整车范围内的规划。比如所谓的场景定义汽车，基于场景来进行整车范围内的规划。这类似于人的大脑，处理一个项目，考虑要做哪些事情，前后次序是什么等等。
这个层级架构，从下往上，层级越高，处理的事务就越复杂，就越需要规划和计算，层级越低，越简单，只需要条件反射。这和人，也是一样的。
在了解了ECU可能承担的职责以后，接下来我们来看看，架构在演变过程中ECU的职责是怎么变化的。
分布式架构
首先是最传统的分布式架构，ECU承担了设备抽象和设备控制的职责，每个ECU基本上是各司其职，尽可能不打扰对方。这个架构里，人承担了总体规划，思考分析，及车辆行为的协调的职责。
域（Domain）控架构
接下来是功能域架构，在原来的基础上增加了功能域控制器，来承担域内的协调及域间的沟通。
区域控制+中央计算架构
最后，就升级为区域控制+中央计算的架构，在这个架构中，人大脑的职责也要被取代了。到这一步，车辆将真正发展成为数据世界中的一环。
因为每个公司或多或少都有遗留的资产或者负担，包括基于原有架构的打造的，车型，组织架构，流程和工具，原有的零部件和供应链体系等等。另外，支持新架构的产品体系还没有完全打通，尤其是在性能，功能安全等方面，所以这个架构还处于，传统控制器和新架构控制器同时存在的中间状态，各自的职责还在不断的发生演进，这背后会有不同的力量在推动。
接下来，我们聊下为什么要分层？
这和我们对架构的理解，以及供应商合作方式都有很大的关系。
我们暂且以ECU这个颗粒度来举例。在上图中，如果把一个ECU和另一个ECU的交互定义为一个复杂度，那么左边这平级架构中的每个ECU因为自身功能，需要沟通的话，都将有3个可能的复杂度。最终，这4个ECU组成的架构，一共将存在3*4，12个复杂度。
而如果把其中一个ECU提高一个层级，通过这个ECU来协调底层的ECU。这个ECU将依然保持3个复杂度，但是底层的每个ECU，复杂度都将变成1。那这4个ECU组成的架构，就变为6个复杂度。
大家可以看下这个差异。同样是4个ECU的总数，但最终的复杂度数量却减少了一半。ECU数量越大，两种架构的复杂度差异也将越大。
另外，因为不同层级复杂度的明确，对于如何宏观分配资源，规划平台，我们就心中有数了。
需要注意的是，这个例子，只是以ECU为单位，对功能实现来讲，颗粒度必须下沉到软件单元才有意义。这种情况下，因为架构分层引起的数量差就更加可怕了。
从这点上，也能理解，为什么在传统的架构和供应商体系中，有任何小的改动都如此缓慢和昂贵了。我们如果不从根本上解决复杂度，其他的措施都是扬汤止沸，治标不治本。
职责边界04
从车辆定义再到ECU层级的拆解，我们对开发过程中ECU所承担的职责已经较为清晰了。最后，根据ECU所承担的职责，我也对实际开发过程中的职责边界给出自己的看法。
在上图中，我们先将整个开发分为两个大的阶段，需求开发和产品开发，然后根据之前提到的ECU层级，将产品开发划分为3级，每一级又拆分为软件产品和硬件产品。然后基于这个分类，应当由主机厂，还是合作商来承担某一分类的职责，在图中给出了推荐程度。
因为传统OEM的开发设计人员，不太懂软件，而传统的软件商只关注单个ECU，没有整车视野，所以在这个变革的历史阶段，市场上需要有能结合两种能力和视野的方案供应商，来弥补缺失的地方。（在实际的情况中，方案商也可能是软件供应商。）
最后，重点说明两点：
在新的架构体系下，主机厂除了负责需求开发，还应该掌控域控制器及中央控制器的软件开发，只有这样，才真正培养迭代能力，保证产品质量，拥有真正的话语权。
注：掌控不一定代表需要事必躬亲，什么都是自己来做。
- 最底层的ECU，建议软硬件同一供应商，因为在这一层软硬件耦合性较大。再往上，域和中央控制器的ECU，建议软硬分离，由不同的供应商负责，而且因为领域的不同，可能存在多个软件供应商，如此一来，主机厂的协调沟通就尤其重要。
作者：贾承前
来源：汽车电子与软件
推荐阅读：
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
