来源：以下文章来源于十一号组织 ，作者黄百万 侵删
前一段时间，SOA在汽车媒体上的频繁发声差点让我耳朵起了茧，正如现在做核酸做的即将起茧的喉咙一样。面对这种行业内突然蹿红的概念，我一贯保持灵魂和肉体的无感，喜欢让子弹飞一会。行业的变革，需要一些动听的故事，需要一些资本的加持，需要一些陪跑的选手。
时间到了2022年的5月，亲眼见证越来越多的车企投入到SOA的躬身实践中，亲耳听到宇宙第一车企基于SOA新车量产落地的巨响。在行业交流没有个SOA的议题可能都上不了台面背景下，作者再不妄议SOA可能就要做一个上不了台面的小编了。
01
背景
在当前分布式电子电气架构阶段，大家有没有思考过主机厂负责哪个控制器的团队最窝火、最痛苦、最失意吗？毫无疑问，是位于架构中心（不是核心）位置的网关控制器，是负责不同总线间（Ethernet/CAN FD/CAN/LIN等）信号路由和转发功能的网关控制器。
BCM和中控大屏可能略有不服，但请你们扪心自问：你们有为某一控制器漏提另一控制器的一个信号更新软件的经历吗；你们有为整车新增与自身不相关功能而更新软件的经历吗？这是分布式电子电气架构基于信号的点对点通讯方式痛苦的缩影。任何微小功能的改动、BUG的修复都可能涉及通信矩阵的改动，也都影响着每次都躺枪的网关控制器的软件更新。
特斯拉Autopilot功能的迭代速度和变更范围已经刷新了传统汽车行业的认知，在未来高级别自动驾驶技术成熟和落地后，功能迭代速度和变更范围必将同时提升好几个量级。而那时的车又不再是一个简单的交通工具，而是一个拥有办公、休闲、娱乐属性的移动个人空间。
针对不同乘车人提供千人千面的个性化、人性化、差异化的功能与服务，不可或缺。而这一切，基于点对点通讯方式的分布式电子电气架构无法实现。而解决上述痛点与需求的答案就藏在互联网的财富密码中，一种叫做SOA的软件架构和软件设计方法，一种可能是世纪大忽悠“软件定义汽车”的软件技术基础。
02
SOA定义
SOA（Service-Oriented Architecture，面向服务的架构），虽然在互联网领域已经摸爬滚打了20年，但异常玄乎的是，至今尚未有公认的定义，足见其深奥且晦涩。下面我们摘选三个有代表性的定义，供读者朋友参考。
《SOA权威指南》一书的定义：SOA不是一种具体的技术，而是一种架构策略层面的指导思想。
IBM的定义：SOA是一种可通过服务接口复用软件组件的方法。
百度百科的定义：SOA是一个组件模型，它将应用程序的不同功能单元（服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，独立于实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA的所有定义都形而上学，难以理解。但每种定义里都有一个汽车行业少见的属于：服务。而这个服务又可分为三类：原子服务、组合服务和流程服务。
（1）原子服务是业务上最小颗粒度的一系列操作，比如氛围灯的颜色控制指令、升降车窗指令等。原子服务一般和硬件功能有关，硬件功能决定了原子服务的范围；
（2）组合服务通过利用多个原子服务，实现部分判断逻辑。比如通过结合光照条件、开关状态等条件实现氛围灯的自动控制功能；
（3）流程服务通过调用多个组合服务，去实现特定场景下的产品功能，比如实现一种新的氛围灯模式。
所以当SOA应用于汽车后，整车各个控制器把自己的硬件能力以原子服务的方式提供出来，整车实质上变成了一个完备的原子服务集合。每个原子服务相对独立、互不影响，具有唯一的身份标识及标准化的服务接口，并通过服务中间件完成服务的发布。在实现新的产品功能时，工程师通过定义新的组合服务与流程服务即可。而通过硬件升级，工程师又可以去拓展原子服务的功能范围。
同时SOA还规定了一套服务管理的框架，来管理这些服务。包括服务发布、查找和定位的方法。在这套框架下，服务之间人人平等，且可以动态的建立订阅/发布的关系。服务之间通过中立的服务描述语言为契约，是一种松耦合的关系。
总结一下，SOA通过标准化的服务接口、松耦合的服务机制以及可组合扩展的服务特性，能以最小的软件变更应对迭代多变的需求。如果再辅以吹上天的域架构或中央集中式架构硬件基础，“软件定义汽车”的故事就圆满了。
03
SOA示例
看完上一章节SOA枯燥的定义，部分朋友可能更加迷惑。这一章节，笔者通过一个简单的例子，介绍SOA在整车上的应用，以便辅助对SOA定义的理解。
有劲没处使的产品经理基于不同的用车场景，将整车氛围灯设计有静谧、柔和、热情、狂热几种氛围模式。按照SOA的设计理念，工程师首先需要把车内一个个氛围灯的颜色控制定义为一种种原子服务，每个原子服务中的不同参数决定这个氛围灯的不同颜色。
将不同氛围灯的原子服务按照静谧、柔和、热情、狂热的场景需求组合成不同的流程服务。车上其它控制器通过调用相应的服务接口，实现对车内氛围灯的模式控制，从而实现一种特定的灯光效果。
对于ECU1来说，它可以学习、预测车内用户的使用习惯，包括对氛围灯的使用习惯。那么当用户在车内玩手机或看电影时，ECU1就可以根据预测算法得出的结果，向ECU3请求调用不同的流程服务接口，来实现对氛围灯模式的切换。
对于ECU2来说，它在检测到车辆解锁或用户关门离开后也需要对氛围灯的模式进行控制。包括车辆解锁时控制氛围灯开启某一种模式，在用户离开车辆关闭车门后，控制氛围灯模式关闭。那么此时ECU2在判断条件满足时，也可以向ECU3请求调用不同的流程服务接口，来实现对氛围灯模式的开闭。
当同时出现两个以上的ECU（ECU1/2）调用同一服务时，此时需要服务提供方（上图中的ECU3）进行仲裁，对每个服务请求进行优先级比较。同时，如果出现第三个ECU4也需要对氛围灯模式进行控制，那么它只需发送服务调用请求即可，再也不需要网关背锅了。
此处可能有人会说，当前的分布式电子电气架构也可以实现我上面提到的功能需求。只要把氛围灯的服务接口分别定义为两个不同信号，ECU3收到ECU1和ECU2的信号后，驱动氛围灯亮对应的颜色，从而实现氛围模式的控制。
事实确是如此，这两者本质不同是SOA把自身车辆最底层的硬件能力展现出来，这些能力被抽象为SOA原子服务。业务部门可以根据自身的需求，调用这些原子服务，在不同的用车场景中构建个性化、智能化的应用，提升用户的用车体验。这也是SOA设计的最终目的，也是整车厂需要掌握的核心能力。而当前的分布式架构，并没有把功能进行开放，往往是ECU3被动的接受ECU1和ECU2提的需求。
把原子服务与车型平台进行解耦，从而提升原子服务的复用性。对于每个原子服务要进行清晰的定义，一旦进行了定义，就不要进行更改，否则调用该服务的软件也要进行变更，原子服务原则上需要向下兼容，所以原子服务的定义很考验工程师的能力。
由于不同车型平台的硬件设备不一样，相对应的驱动程序也会有不同，然而每个原子服务表现出来的功能在不同的车型平台中需要保持一致，否则需要定义不同的原子服务接口，以此来屏蔽硬件设备与驱动的差异。
04
SOA交际圈
汽车领域提到SOA的地方，我们无一例外地总能找到架构升级、车载以太网，SOME/IP，AUTOSAR等的身影。他们是同一个屋檐下的家人，还是时常聚在一起打麻将的牌友，下文我们试图厘清这剪不断的关系。
（1）架构升级
在分布式电子电气架构阶段，一辆车上几十个ECU是有的，每个ECU均承担相应的逻辑控制和驱动执行的功能，这导致一个大的系统功能往往需要多个ECU齐心协力去实现。功能的迭代和单个ECU的功能升级、变更往往需要多个ECU共同配合修改。而各个ECU采购于不同的供应商，最终导致商务复杂性增加，技术难度加大，变更成本升高以及软件交付周期加长。
而随着架构朝着域架构和中央集中式架构演进，ECU的数量将极大减少，或者说负责功能逻辑的ECU将极大减少。按照经典六域理论，整车功能逻辑将全部部署在六个域控制器中，其它ECU变成纯粹的执行和传感单元。基于个位数的域控制器设计面向服务的架构与基于好几十个ECU设计面向服务的架构，难易不辩自明。架构升级是SOA得以发挥最大潜力的硬件基础。
（2）车载以太网
在分布式电子电气架构阶段，车上主要采CAN(FD)总线进行通讯。CAN(FD)总线速度低、无效载荷开销大（甚至>50%）、有效数据长度太小（CAN 8字节，CAN FD 64字节）。伴随着智能驾驶、智能座舱等功能的引入，整车数据吞吐量极具增加，CAN(FD)总线显得有心无力。
在这样的需求背景下，诞生了适用汽车领域的车载以太网。车载以太网提供100Mbp~10bps的带宽能力，可以说一步到位解决汽车当前及以后的数据吞吐量不断增加的难题。为SOA提供了可行的通讯通道。
（3）SOME/IP
基于车载以太网的上层通讯协议SOME/IP（Scalable service-Oriented MiddlewarE over IP，运行于IP之上的可伸缩的面向服务的中间件），定义了两个核心协议。一个用于服务之间数据交互（称作SOME/IP协议），一个用于服务发现（称作SOME/IP-SD协议）。这两个协议的设计细节十分精巧，这也是它能够支持所谓的面向服务架构的基础。可见，并不是SOA必须和SOME/IP绑定，而是SOME/IP天生就是为了SOA而生。
当然SOA并未指定底下的通讯方式必须是基于车载以太网的SOME/IP协议，SOA对底层通讯方式的需求是可以实现不同服务之间的数据交互。而实现此需求还是可以是共享内存， DDS（既支持车载以太网、也支持共享内存）等方式。各主机厂可根据架构要求及自身实力自行开发其他的通讯通道和通讯协议。但是伴随着SOME/IP被纳入AUTOSAR标准，SOME/IP俨然成为SOA服务间通讯协议的代名词。
（图片来源："域"见SOA_联合电子微信公众号）
而对于SOME/IP定义的两个核心协议，下面我们简单进行介绍。
（a）SOME/IP协议
SOME/IP协议定义了三种主要服务通讯方式，包括Method、Event和Field。
- Method
Method分为R&R（Request&Response，请求和响应通信）和F&F（Fire＆Forget，焚烧和忘记通信）。R&R通常由Client发起请求（Request），并由Server答复（Response）。F&F只是Client向Server发起请求（Request），无需Server对该请求进行回复。
- Event
Event属于事件通知类的服务，首先由client向server订阅服务内容，然后server向client自动发布服务内容。
- Field
Field也属于事件通知类的服务，除了具有和上文Event一样的服务通知功能Notifier，还具有Getter和Setter的功能，即对信息进行读写的操作。
Notifier：Notifier与Event类似，Field中的事件报文在Field值更新时会发送出来。
Getter：由Client向Server请求Field中的数据，Getter是一个请求/响应调用，请求报文的payload为空，Field的值置于响应报文的payload中。
Setter：由Client修改Server Field中的数据，Setter是一个请求/响应调用，将要设置的Field的值置于请求报文的payload中，响应报文的payload也要放置Field设置的值。
上述氛围灯的原子服务就可通过车载以太网SOME/IP协议中Method的通讯方式进行定义，每个氛围灯的颜色可定义为一个独立的原子服务接口，具体的服务例子可由下表进行简单描述。
（b）SOME/IP-SD
SOME/IP-SD有两个功能：应用程序之间传达自己的服务或获取对方的服务是否可用；向其他应用程序订阅服务（通过SOME/IP-SD对服务进行订阅，然后再通过SOME/IP里面的Notification类型信息发布订阅内容）。
（4）Adaptive AUTOSAR
Adaptive AUTOSAR（AP）是一种遵循SOA架构设计思想的操作系统中间件，提供了汽车面向服务软件架构的具体实现方案，是车载SOA实现的标准。AP可以统一管理下属OS以及周边资源，使得系统运行时的一切调度、状态和资源消耗都处在一个可控的范围内，以满足车载安全性、确定性的要求。
而除了AP外，ROS也是遵循SOA架构设计思想的操作系统中间件，最早应用于移动机器人领域。是一个分布式的进程（也就是“节点”）框架，这些进程被封装在易于被分享和发布的程序包和功能包中。无数自动驾驶公司的第一套代码都是跑在ROS上，ROS何时可以进化到满足汽车自动驾驶领域的需求，值得万众期待。
05
SOA现状
大力宣传并践行SOA的厂商非零束和威马莫属。零束SOA主要面对的是开发者，并于2022年4月上市了其基于SOA的首款量产车型-智己L7（宇宙第一车企市场部请速与我联系，支付广告费）。威马SOA主要面对的是用户，早在2021年4月的时候便上市了其基于SOA的首款量产车型-威马W6。其他主机厂也在同步跟进，只是并没有做大力的宣传。
回到上述两个技术路线，零束的SOA主要面对开发者。作为开发者而言，我入住你的平台，平台方需要给我回报，而且回报至少是处于软件行业平均水平时，我才愿意坚持干这事，也才会吸引更多的开发者进驻该平台。
但是对于开发者来说，在电脑上开发出来的程序，如果自身没买这台车或者所在的公司没有相应车辆进行验证，那这个程序是谁负责验证呢？正如信心满满热情洋溢炒出一盘菜，结果找不到人品尝菜的美味。
另一方面，整车可定义的服务取决于底层硬件可提供的能力，在当前架构、当前硬件条件下，可预见的是，整车开放出来的服务也就在三位数级别。基于少的可怜的服务，无论怎么排列组合，也都玩不出花来，更无法也满足广大开发者的开发需求。
威马的SOA主要面对用户，作为用户，更期望的是车辆可以提供不断进化的能力以及更加愉悦的体验。把那么多服务开放给用户，犹如抛给用户一本几百页的产品手册。刚拆箱时，可能还有兴趣看一下产品手册。但在使用一段时间后，可能再也没人愿意去看产品手册了。
将场景编辑作为卖点，有考虑过打工人的宝贵拧螺丝时间吗是？用户花了那么多时间去编辑用车场景，对用户的实质收益在哪里？这个卖点用户是否买单，W6的销量已经告诉了我们答案。
站在笔者的角度，以上两条技术路线都走得都不会太顺畅。SOA的道路，需要所有主机厂齐心协力把SOA的服务接口统一化、标准化。从而可以剥离开硬件，使得软件的开发不受硬件的影响，增加软件的复用性。然而现在犹如先秦时期，百家争鸣，各家主机厂各自为战，没有形成统一战线。等到哪天西方国家开发出类似Android的SOA平台，国内主机厂又得屁颠屁颠的去买软件、买工具、买培训。
中国电动汽车百人会理事长陈清泰在一次论坛中曾提到：“在软件定义汽车的时代，厂商和用户将由一次性的买卖关系转化为全生命周期的合作关系，形成“用户不断提供数据、厂商不断扩展服务”的良性循环。也就是说，厂家的商业模式正在由“制造”转变为“制造 服务”，而服务的收益占比会逐步增长。”
06
SOA思考
SOA对于“软件定义汽车”而言，是否是决定性的因素，是否只有这一条路可走？当人人都在做SOA的时候，是否有人真正静下来思考实质收益是什么，远方在哪里？目前行业对SOA理解尚未能达成一致，很多车企为了SOA而SOA。继AUTOSAR的生与死之后，我们是否需要考虑一下SOA的生与死。
参考资料：
"域"见SOA
mp.weixin.qq/s/nnfq-Iv_CPE47Rn1zgyxgA
自动驾驶软件架构之：中间件与SOA（一）
mp.weixin.qq/s/IzMTl4wRUcGXNYkPKtx88w
软件究竟如何定义汽车【二】？
mp.weixin.qq/s/5_Ke33DSEB12FdGQPrAseQ
,
