前言：

SOA（Service Oriented Architecture)在汽车行业目前比较热门，最近有不少写SOA的文章已经解释SOA是什么、有哪些好处、要如何设计等。但其实从技术决策的角度上来看，就关心这几个问题：

搞SOA，有什么好处？能实现什么之前不能实现，或实现成本较高的场景吗？

搞SOA，成本如何？能不能分步搞？

搞SOA，公司的能力是否具备？

1、SOA与软件定义汽车

"软件定义汽车" 已经成为一个不可逆的趋势，其基本的意思是指汽车的功能及性能，之后将更多的由软件来决定。当然，业内也有不同的声音，如"架构定义汽车"等等，其本质差不多。

那么，在"软件定义汽车"的趋势下，”SOA“到底处于什么样的位置呢？

右图是历史上的经典”马拉火车“，当年中国第一条铁路修好后，因慈禧不喜欢火车头的“大呼小叫”，导致很长一段时间列车都是让马与驴拉的。

左图呢，由于受汽车行业的惯性思维影响，整车开发流程都是先定EEA，然后定点各ECU或沿用车型平台的ECU，放在前些年就没有然后了。近年来受”软件定义汽车“的影响，同时还会确定”哪些自研，哪些由Tier1开发“。但这还是不够的，如果不搞SOA，就算EEA升级、控制器升级、软件自研，他们也很难高效的运转与支持迭代。

空口无凭，接下来我们来详细的展开吧。

2、行业现状

这里借用几张出现频率较高的图来说明一下：

大众MEB E3 EEA

大众MEB平台的E3架构，采用千兆Ethernet，规划了3个ICAS（应用服务器），在软件层面上采用了SOA的架构。

现代(Hyundai)的EEA - 引用自《浅谈整车SOA架构系列》

现代的EEA也是将Ethernet纳入主干网，同时在Ethernet连接的结点采用了SOA架构。

国内上，在此领域走的比较靠前的“华人运通”，参考其官方宣传稿，采用了“HOA开放式EEA”，使用了千兆以太网，拥有6个超级域计算平台，并实现了“真正意义的软件与硬件分离”。从技术语言来说，同样采用了SOA架构。

结论就是，从国际和国内上的各种公开信息来看，凡是将Ethernet纳入主干网的车厂，都在其上采用SOA的架构。

3、SOA到底有什么好处？

SOA将跨ECU交互由“基于信号的通信”变为“基于服务的通信”，其意义抽象的讲，有以下方面：

应用服务化，使“全车智能”成为可能

服务的灵活部署

软件更新/升级更快速

服务高内聚，软件易重用

光讲这些太抽象，作为长期战斗在一线的软件架构师，上向领导汇报，下说服工程师，最有效的办法就是讲“场景”。下面一个个展开吧。

3.1 “全车智能”成为可能

服务化，各个域将自己的能力提供出来，在权限允许的情况下，供大家随意使用。这样的话，”智能“就不仅是体现在”智能座舱“、”智能驾驶“领域，也可以是”智能车身“、”智能底盘“等等。举几个具体的例子。

1) 智能交互的开放 —— APA(自动泊车)过程中语音提示

当前基于CAN通信，就是APA控制器提供CAN信号，中控接收到之后，根据APA的状态做用户提示。但是，一般来说搞中控的人对APA一点都不懂，很容易出各种问题。

SOA的做法，中控大屏提供TTS服务，APA控制器自行使用。

2) 车控能力的开放 —— “跳舞”模式 (Tesla Model X)

当前基于CAN通信，”跳舞“这个应用较为复杂，包含音乐、车身、前后运动等，其逻辑会分拆到多个控制器中，且基于各种安全因素的考虑，不一定会将直接的控制能力暴露出来。

基于SOA，各域可抽象出通用的服务出来，如”极低速控制服务“和”车身/灯光控制服务“出来，而”跳舞“相关的应用逻辑，就可以完全放在中控应用当中了。

3) 多域能力的开放与融合 —— 智能车窗

当检测到下雨时，自动将车窗关闭，并通过语音及界面来提示用户。

当前基于CAN通信，车身控制域提供“雨量传感器”的状态、“车窗控制”的信号，一切由中控大屏来实现。但说实话，这功能跟“中控大屏”有什么关系？因为是否与用户交互是可选项，并非此功能的核心。

基于SOA，中控将“通知”与“语音播报”的能力提供出来，车身控制域在发现“下雨”时，调用“车窗控制”，基于用户的习惯，选择合适的方式与用户交互，甚至于说不交互。

由于笔者为智能座舱背景，举的例子多半与智能座舱相关。相信其他领域的小伙伴，会有更多的用户场景可讲。

3.2 服务的灵活部署

SOA的一个基础，就是“服务发现”机制，即给每个服务分配一个“全局名称”，通过这个名称就可以直接找到对应的服务。比如我们上网时的“网址”就是起的这种作用。这样的好处是：

可以在ECU运行时获取服务的位置。继续以“网址”为例，"ele.me"的服务器到底部署在哪，我们是不知道的，当我们输入"ele.me"，DNS服务器会解释其IP地址，并通过动态路由的方式找到拥有这个IP地址的服务器。大白话的说："不管你在哪里，只要不改名，我都能找到你"所以，基于这个特性，在整车生命周期内，不同的车型配置可做不同的服务部署，对代码几乎可以不用改动。以笔者较为熟悉的OTA，来说明吧：

基于SOA的OTA逻辑架构

上图中，带SOC的ECU都连接了Ethernet，需要基于SOA Middleware来提供标准的OTA Service，如版本号查询、自升级控制、升级状态反馈等；不带SOC的ECU，通过CAN连接网关，则通过UDS直接刷新。其中所有的Service的部署都与位置无关。

举个例子，拿OTA中最最最要命的”升级主控“的选择来说吧。”升级主控 (OTA Master)“是OTA的核心，其功能一般包含：版本检测、升级状态控制、回滚、状态上报、合法校验等。升级主控放在哪个ECU上，是整个OTA方案争议最大，最重要的决策之一。但问题是，同一个项目，因为不同配置的关系，它还要放在不同的ECU上。比如说，

放中控大屏上，低配车没有大屏怎么办？

放Tbox上，高配是5G，低配是4G，供应商还不一样怎么办？

放网关上，高配带SOC，低配只是个CAN网关怎么办？

采用SOA架构的OTA方案就没有这个问题。

升级主控由网关换成Tbox

如上图中，升级主控由网关换为Tbox，也只需要重新部署OTA Master Service和OTA UDS Service即可。其他的不变。

而传统架构的OTA方案，改动升级主控？大工程啊。除了服务要重新部署，相关的通信协议也需要改动，代码也要做一定的修改，麻烦。

3.3 软件更新更灵活

SOA的松藕合特性，可以将功能更新与变更限制在更小的范围内。

1) 硬件架构需要调整，减少复杂功能涉及的ECU数量

车控域发生域融合

如上图，基于SOA的架构，车控域发生域融合时，应用可以直接做重新部署，而无需重新开发，改动限制在服务的实现上。

若不基于SOA实现，发生域融合时，所有功能几乎都要重头开始。

2) 软件架构需要更新，一个功能改变只需要更新/升级部分软件

增加"空调滤芯寿命显示"功能时传统方式与SOA方式的对比

如上图，“增加PM2.5滤芯寿命显示”这一功能，传统方式有4处的改动，而SOA方式仅有2处。

4、实现SOA的成本如何？

4.1 内部成本

SOA在很多年前，某些Tier 1就已经在搞了，但由于设计过于理想，开发成本过高，且运行效率较低，放弃了。

在理想架构下，不同的控制器的应用与服务可以任意的通信，它们全都使用跨ECU IPC。但是，这样实现：

成本极高，比如Android源生支持binder，要把所有应用都改为使用新的IPC。Linux也一样，源生都是使用dbus，其对跨ECU通信支持较差，也要改为使用新的IPC，代价非常大。

运行效率低，跨ECU的IPC，其一定比ECU内IPC更重，资源消耗大、时延大。

所以，考虑实际，可落地架构是指

大部分的ECU中，内部通信使用源生的IPC，保证效率、降低开发成本。跨ECU通信，通过专门的proxy / adaptor来做中继。这种proxy / adaptor依据情况在同一ECU内可以有多个。

在某些业务逻辑较为简单的ECU内，可以采用跨ECU的IPC，方便后续移植。

所以，只有采用上图中的可落地架构，才能做到内部成本可控。

4.2 外部成本

要实现SOA，有不少的工具、组件需要向外部购买，其成本如何呢？是否可以分步走呢？

1) 基础版本：仅支持所有带SOC的ECU之间的服务调用。

成本：最低可以为0。

对于SOC上运行的操作系统，如Linux, Android, QNX而言，SOA是十分自然的过程，其源生的就支持IPC（跨进程通信），如binder, dbus等。在这种情况下，可选用的跨ECU的IPC就不少，如SOME/IP，DDS-RPC（DDS支持RPC的版本），fdbus (Jeremy大神写的）等等。

但由于免费的DDS-RPC及fdbus等方式，不被Classic AutoSAR支持，所以后续扩展会有一定的问题。

2) 进阶版本：支持所有ECU之间的服务调用，但不支持实时业务

成本最低为单件百万级别

目前可选的跨ECU通信中间件，只有SOME/IP，且最好选择商业版的。因为虽然Genivi有开源的vSOMEIP，但是是否量产还是个问题。

3) 专业版本：支持SOC内的应用升级(Software OTA)

成本为单件几百万至千万级别。

先解释一下SOTA。业界叫的OTA，通常指的是FOTA (Firmware OTA)，而严格意义上的OTA分别3个级别：

Firmware OTA：固件升级。升级的对象为整个系统，通常不包含bootloader。风险最高，对可靠性要求也最高，升级频率1~3个月。

Software OTA：应用升级。升级的对象为单个或多个应用。风险中等，最严重的就是某个功能用不了，对可靠性要求中等，升级频率可以高至每个星期。

Data OTA：数据升级。升级的对象为应用内部的数据。风险低，最严重的就是某个子功能出问题，对可靠性要求低，升级频率随意。

目前来看，除了Android系统，其他系统最直接的方式就是上AutoSAR AP。但是个人比较质疑其效果，就拿源生支持SOTA的Android而言，对于深度定制的中控大屏系统，目前有哪一家支持SOTA？原因是，SOTA听起来简单，但对组织的能力要求很高，每次升级某个应用，都需要清楚的知道其依赖关系，而实行SOA架构的系统，其依赖关系往往错综复杂，很容易出错。

因此，AP平台需要慎重考虑。

4) 极致版本：支持跨ECU的实时通信

成本：上亿？

方式是选择TSN，使Ethernet上的部分业务达到CAN同样的实时性。当初Ethernet为了高吞吐量，采用了CSMA/CD，而CAN为了实时性，采用了CSMA/CR。采用TSN的Ethernet集齐了两者的共同优点，可谓完美。但现实是，目前其标准仍在修改中，且尚无车厂量产。

5、SOA带来的挑战

最后，简单总结一下，SOA的本质是让汽车变成一个真正的分布式系统，就像阿里的“飞天”一样。各自为战的ECU功能设计将被打破，取而代之的是分层式的架构设计与实施。

SOA分层式的架构也不是一蹴而就的，就跟软件行业的操作系统的发展一样，也是增加功能 -> 抽象的不断循环往复。

其将给我们带来变革与挑战：

人才的挑战：整车的功能分解与交互时序定义将由ECU级别（只管ECU的输入输出），下降至模块级别（要管ECU的各个模块的输入输出）。同时需要软件架构与EEA领域的知识。

功能的集成：跨多个ECU功能交互成为常态，在零部件仍大部分由Tier1提供的情况下，OEM功能的集成是个大问题

主导权的争夺：SOA需要OEM来主导各个ECU的对外提供的服务，以达到平台化的目的，可强势Tier1们愿意吗？