01 写在最前面

从踏入职业生涯就开始接触所谓的 SOA，一直都在思考什么是 SOA，通信基石又是什么？是以太网？是 someip？是 dds？亦或者其他协议？那我的答案：都不是，是大带宽和 IP。

SOA 在车载真的是一个很新的东西么？在我看来，其实也不算是，在 cp 中，站在高层开发者来说，RTE+SWC 未尝就达不到我们所谓 SOA 需要解决的痛点！那为啥依然 SOA 还会成为主流的“软件定义汽车”的解决方案之一呢？SOA 是解决什么问题？原来的痛点到底是在哪里？SOA 的通信基石为什么是大带宽和 IP 呢？

接下来会从 CP RTE 中理解 SOA，从而体会到 SOA 和 CP 之间并不是颠覆性的新思想。下述 AP 大部分场景都不是准确指的 adaptive autosar，而是 soc 车载中间件的统称。

02 从传统的RTE理解SOA

WHY: 为什么需要 SOA？

从两个不同的视角来描述这个问题：SWC 设计者和 SWC 的开发者。

SWC 设计者：

专注功能划分
专注功能设计
接口标准化（基础功能层面的）
不同车型重用--形成 foundation service

SWC 开发者：

只想关注输入、输出，不关心从哪里来到哪里去
不想关注部署到哪个 ECU

从上述两个视角来看，会发现 CP 就是为了解决这些而生的，站在他们的视角来看，不管 CP 是静态的还是动态，对于他们来说，都只想关注上述的一些点。

WHAT: SOA 是什么？

前面提到了，站在功能设计者和开发者来说，他们并不关心让他们达到灵活的平台是静态还是动态，他们需要的是：

个人理解：所谓的静态和动态，其实需要从不同的维度来理解，现在很多所谓的动态配置，大部分理解的是 soc 上的动态库+动态读取配置文件，这个就是从运行时去理解的。从这个角度来看，cp 或者大部分 mcu 系统来说都是静态，但是站在整个系统开发来说，cp 的动态是体现在使用一整套工具链来达到目的，只不过其每次变更后需要重新构建和刷入的固件而已。因此没有绝对的动态和静态的说法。

在《从“非软件”角度看 AUTOSAR CP》中有过描述，如何从定义功能、实现、部署。摘录如下：

软件工程师经常说需要定义软件边界，所谓的软件边界其实就是不同功能集之间交互的接口，具体来说，对于某个模块来说，就是需要什么输入，输出什么东西，因此如所谓的软件组件描述，其实就是定义软件组件的接口内容，如数据类型、接口。对于在不同的方法论体系下这些都是相同的，对于 SOA 来说，关注的服务+接口，对于传统 autosar 来说，关注的是 swc、数据类型、端口和接口，所以本质上来说，不管是吹的很火的 SOA 还是被“誉为落后”的 CP，在想要达到：功能灵活设计、快速迭代，在顶层设计来看是没有区别的。只不过在实现过程中不一样而已。后续我也会写 SOA 和 autosar cp 的本质区别。

以下面三个图为例，首先我们需要梳理出，我们有哪些功能，最后将功能映射到具体的软件组件（swc）去，但是功能和 swc 并不是一一对应的，因为逻辑上的和真实实现上还是可以有差别，主要是从实现角度是做一个取舍，但是这并不会改变不同功能之间的输入、输出关系。在确定好软件组件以及输入、输出关系后，我们就可以通过虚拟功能总线，将不同的 swc 连接起来。此时，是将整车所有的 ecu 当成一个整体来看的，而所谓的虚拟总线需要有不同的实体来对应，在 autosar cp 世界里就是 RTE 了，而在 SOA 中就是 service framework + communication 了。

回到 soa 本身，想必在汽车行业的都听过，梳理出原子服务，构建出基础功能服务。类似如下（不同公司都会有自己的类似图）：

所谓原子服务和基础功能服务，关键是在于平台么？当然不是，其关键都是划分功能和定义软件边界，而软件边界的实体不就是 API 嘛。从这也可以看出，不管使用任何平台，上面的工作是无法避免的，所以后面会提到“SOA 不是银弹”。

参照 AP 给出的架构：我们可以总结出，SOA 需要提供一个平台，能够让原子服务很轻易的组合，而且该平台能够提供很好的平台部署能力，让应用的设计和开发者可以专注自己的领域。

HOW: cp 是如何做到上述几点的呢？

AUTOSAR CP 解决方案：工具、设计上移和左移、标准

a、工具

工具是 cp 的绝对核心，如果撇开工具来开发或者使用 cp 的，那绝对是错误的。为什么工具是 cp 的核心呢？首先 cp 是针对 mcu 开发一种解决方案，而 mcu 几乎不会使用类似 soc 上的文件系统和动态库，因此就决定了 mcu 很难存在运行时动态。前面提到了动态是需要从指定维度来看的，而 SOA 需要的动态，并不一定需要在运行时，所以如果对于开发者来说，使用一套平台+工具能够实现千人前面的功能，这何尝不是一种动态的呢？而 cp 正是如此的，不管专注 EE 架构和功能设计的 PREEvison 的工具，还是在嵌入式集成使用的 davinci 工具，都是 cp 的中核心的核心。对于应用开发工具，还有基于 MATLAB 的 simulink 工具（基于 CP 和传统 embed 是两种工具）。

为了解决动态的问题，CP 引入大量的可视化工具以及设计一整套软件配置方案（SWS 文档：Configuration specification + bsw_def.arxml）。

b、设计上移和左移

大家会发现 vector 家的工具是最好用的，除了在 UE 的上体验，更多的是他们家的工具做了很多很多校验，大部分场景下，工具生成出来基本编译不会有问题，很多时候也能正常运行。这其实就是设计上移至工具链，和校验左移至开发阶段。其中设计上移最典型的一个案例就是：资源分配最终在源代码中几乎完全是静态的，但是对于开发者来说，是很轻松在开发阶段灵活分配的。而校验左移，追求的是：工具能够生成，则代码没有问题，这当然是一个很美好的愿景了，但这恰恰是每家 cp 做的是否好的关键，也是难度最高、工作量最大、最需要积累的！

c、标准

前面提到了，需要定义原子服务+基础功能服务，而 cp 已经标准化了一部分基础服务，如：NvM，Com，ComM 和 BswM 等。而其他层面，由其开发流程+软件架构、规范进一步定义了如何开发和集成，所以不同团队都会有趋同的开发流程。

那对于在 soc 来说，如果说为了运行时效率，其实依然需要依赖：工具、设计上移和左移、标准，只不过对于 soc 来说，由于其运行时特性，可以不需要所有的东西都依赖于工具，比如一些配置可以使用配置文件，功能组合可以使用动态库使用动态加载，更新时可以只更新库或者配置文件。剩下无非就是根据上述需求实现一套契合 soc 的中间件，而这些对于不需要构建底层方法论、有各种参考+人才众多的情况下，并不是太大的问题，主要问题反而是解决性能和确定性了。

形态上来说：

•Atomic Component Vs Atomic Service

•Composition Vs Foundation Service

•Port Vs Method

小结

对于 soa 来说，无非就是如下四点：

灵活---软硬件松耦合、标准化接口
自上而下---从需求分析出发，导出服务定义，然后进行服务编排，服务接口的定义，最后是软件到硬件的映射以及对通讯协议的配置。
服务发现---不在乎功能在哪，远离精神内耗
软件灵活更新---修改功能时只需更新、升级部分软件

AUTOSAR 的分层式设计，用于支持完整的软件和硬件模块的独立性（Independence），中间 RTE（Runtime Environment）作为虚拟功能总线 VFB（Virtual Functional Bus）的实现，隔离了上层的应用软件层（Application Layer）与下层的基础软件（Basic Software），摆脱了以往 ECU 软件开发与验证时对硬件系统的依赖。软件组件的交互是基于虚拟功能总线（Virtual Function Bus， VFB ）进行的。在 VFB 上，软件组件之间通过端口（Port）交互，Port 的类型由接口（Interface）定义。接口控制了软件组件间通讯的内容和语义。Port 和 Interface 的组合被称为 AUTOSAR Port Interface。VFB 使得设计者在设计软件组件时不必考虑它们会被分配在哪个 ECU 上，也不必考虑网络拓扑结构和 ECU 在车辆网络中如何通讯。这就意味着，通过 VFB，在车辆 ECU 间的电气架构确定之前，就能够确定系统的整个功能。

AP（代替所有 soc 中间方案）是动态分配资源的，面向服务的，有需要了再分配，这样能节省资源，降低成本，方便使用。SOA 软件构架下的底层软件也就是“服务”，具有接口标准化、相互独立、轻耦合三大特点。

标准化：各个服务间有界定清晰的功能范围，并且有标准化的访问接口，以便上层应用进行功能变动或者升级的时候，底层软件保持不变。

相互独立：每个服务之间相互独立没有相同部分且唯一。

松耦合：底层软件跟硬件、车型、应用、ＯＳ、编程语言不耦合，其他部分可以随便换，底层软件不用动。

整体上把ＳＯＡ软件抽取出来，形成一个中间件，开发完成就不用变动了。然后开发人员可以集中精力编写上层应用去实现功能创新。

03 为什么是 IP？

在汽车行业说，说到 SOA，很多人都会想到以太网、SOME/IP 或者 DDS，为什么总是会有这种错误？以太网先暂且不说，无非就是贷款高，而 SOME/IP 和 DDS 都是可以基于 IP 体系下的，TCP/IP 定义了严格分层，让通信变得及其灵活。

如上图所示：OSI 七层模型，对于同一层次的通信，其实是建立了逻辑链路，通信的双方就是对等实体，所以每一层都专注在自己的功能上，比网络层有一个很重要的功能就是路由，基于软件层面的灵活路由。

基于这种严格分层体系来说，是有一个很大的问题的，就是浪费了很大一部分带宽，这恰恰是传统基于 CAN/LIN 允许的，所以会发现在 cp 体系下的 can/lin 协议栈都是分层极少，如果把 canid/linid 当做头部的话，那么基本可以理解为 can/lin stack 数据是平铺的（cantp/lintp 头部也极其的短）。而对于 tcp/ip 体系来说，每一层都是有自己的 header，作为对比 can/lin 几乎可以看做只有一层 header，所以其能够带来的灵活性就可想而知了。

车载在选择大带宽通信时，选择的是以太网+tcp/ip 体系，也是因为其在很多领域都是极其成熟的。

对于 can 来说，虽然其总线是无主节点+广播型的，但是由于其带宽有限，通常都会有很多条总线，这样就造成如果需要跨总线通信时，不得不做很多基于规则的路由，并且其只有一层 id，所以其路由规则会相对来说较多，这就导致了通信的不够灵活。

对于以太网来说，虽然其硬件拓扑是点对点的，但是由于每一层都可以数据路由+转发（大部分是软件），所以即使其点对点，数据想穿过不同总线到达不同的节点，在 tcp/ip 体系是特别简单的，尤其是 ip 路由这一层，不管动态路由还是静态路由。而且由于上层还可以有多层，其路由规则也不会特别多，仅仅是有限的几个！

总结来说：对于 can，由于 Payload 短，所以有一堆 CANID，复杂且易变的路由逻辑；而以太网+tcpip 则是 Payload 长，高度抽象、灵活组合。

使用 tcp/ip 当然还有很多其他各种各样的好处，这个暂且不聊了。

我们可以看出，SOA 所谓的动态发现，其实都是依赖于 ip 体系的功能，而传统的 can/lin 由于带宽有限，只能让有效负载高的一种方式，因此就丧失了部分灵活性，而其 cp 的面向信号也是跟着有关（前面提到过，cp 的以太网通信也是其架构下转成了面向信号）。

拓展：

随着 tsn 的引入，对于通信的可靠性和确定性也可以慢慢接近 can 总线。

在最新的 CANXL 中，由于其带宽变高+payload 变大，也可以运行 tcp/ip 协议栈，这更可以看出 ip 才是 soa 通信的基石之一，甚至说是最重要的。至于 CANXL vs 10BASE-T1S 孰优孰劣，就交给更加底层去评判吧。

但是不管如何，can 由于其特点：确定性+可靠性+便宜，依然在承担着很重要的角色，为了上层的统一性以及用上 ip 的灵活性，就不得不引入 signal 2 service（S2S）了。ps: 这里本身 cp 很灵活并不冲突的，cp 的灵活在于整体架构，并且 can/lin 也不是 cp 的全部，即使基于以太网也可以在面向信号的架构完成服务通信。

04 S2S--承新既古

在引入 SOA 架构之后，汽车软件工程师不得不面临的一个问题是，基于以太网的服务（service）的域控制器，区域控制器等，如何能和只有基于信号（signal）工作的 ECU 相互兼容并工作。

这个问题之前并没有被 AUTOSAR 规范所定义，所以也没有类似于其他 BSW 模块的基础模块，或者参考解决方案可以使用，基本上 OEM 或者 Tier1 需要新建一个 SWC/APP 来做这个转换，至于是部署在 CP 端还是 AP 端，这个不同的团队都会根据实际硬件性能或者软件架构进行思考。

在 AUTOSAR 组织发布 20-11 版本规范之后，我们可以在 AUTOSAR_TPS_System Template 文档的 6.16 章节阅读到对于 Signal to Service（下称 S2S）的实现参考。当然，这里也只是一个参考，并没有相应的 SWS 文档进行详细规范定义，所以仍旧需要各供应商或者软件团队自己进行实现。

S2S 的功能模块有以下几种部署方式：

部署在网关，所有的 Signal to Service 转换都在网关执行，
如果有多层网关（中央网关、区域网关等），最终都可以通过 udp 或者 tcp 送至其中一个或者多个
部署在（例如）分布在汽车前后左右的四个区域控制器中，区域控制器会连接 CAN， LIN 节点
部署在使用了服务的 ECU 中，各自转换各自需要的 Signal/Service

部署 S2S 的时候，团队可以根据实际需求决定是部署在 CP 或者 AP 上，同时，也要考虑是否加上 E2E 或者 SecOC 的功能，对 cp 来说，如果了解以太网的，基本都会做在 swc 层，无非该 swc 仅仅是收发和转换数据。其实我自己是不喜欢这种方式的，我觉得如果 oem 自研的话，这部分是可以重构的，将 s2s 和传统的 com 进行融合，在 rte 以下就把 s2s 完成掉（保密，不展开）。

上述文字也是东拼西凑的，当然这章描述的重点也不是 S2S 的科普。所以从中看出，所谓的 s2s 就是连接旧世界和新世界的纽带。自己在很多场合都给 s2s 下了一个定义：实现信号和接口的相互转换，而成为一个服务，但是信号本身是执行器或者传感器产生的，所以本质上 s2s 就是若干执行器或者传感器的代理。但是，但是，其实并没有这么简单，其中还是有很多需要解决的。

想一下 can/lin signal 的通信特点：单次数据少，周期；而以太网：header 字节长，最好是 request/response 这种 ping-pong 模型的。

所以你会发现，其天然是对立的，如果将 signal 承载在以太网上来单次发布数据，导致其有效负载极其的低下，而其高频必然会导致资源的超级浪费；并且由于 soc 系统+以太网的不确定性导致，周期也往往无法满足。而事实恰恰就是如此，在我所了解的几家 oem 中，都遇到了类似的问题，服务化的高频接口调用中占掉了很多的 cpu 资源；对于一些时间敏感的功能，往往由于其不确定性导致问题发生。

所以全部服务化--SOA，就能解决传统开发过程中的所有问题么？在各种场景和架构中，我们往往都会发现，新的设计很多时候并不是解决问题，而是转移问题，问题转移并不是变得简单了，而是变得合作起来更加方便了，以此达到提效的目的。

05 SOA 不是银弹

前老板曾经说过：不管车如何变化，其主体永远是机械，或者即使软件扮演的角色越来越重要，但是它依然是机械。当然结合当时情景，他想表达并不仅仅是技术层面的问题，同时这句话并不是反对软件的重要性。之前有架构大佬提过，软件能定义汽车么？其实我的答案跟他类似，软件并不能定义汽车，定义汽车的依然是产品经理，无非产品经理需要比之前懂得更多，需要集合新的整车电子电器架构来思考如何更好的落地。

为什么说没有银弹？在《人月神话》中，佛瑞德·布鲁克斯预言：没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。因为：“软件的根本困难（Essence，包括复杂度、一致性、可变性、不可见性）在软件问题中占据的份额超过了 10%”。

前面分析来看，CP 和 SOA 在顶层设计来看，并没有什么本质的区别，所以对于功能定义者和开发者来说，原有的工作和困难（软件的根本困难）并没有发生变化；而 soa 带来的灵活性也没能解决所有的问题，并且又带来很多新的问题，比如：确定性和可靠性。而车是一个高度集中又同时是一个分布式系统，其分布式节点的变少才是导致开发变简单的关键。但是原有分布式系统的兼容性、一致性，依然是存在的，并不会因为引入了 SOA 就没有了。ps：想起前段时间跟前同事吃饭，据描述，他们的软件发版经常出现基础软件和应用软件接口不兼容的问题，并为此特地预留 2 周做接口的兼容集成。

所以问题的本身又转移到了在高度集中的单一系统内如何保证高效开发、集成，而原有的高可靠性的系统在以太网+soc 下又是如何保证？所以有了自研、有了全新的组织架构，有了 tsn，有了确定性通信和确定性调度。

SOA 的出现与 EEA 架构是相辅相成的，SOA 也仅仅是一种技术方法论，就像面向对象一样，都有其适用的场景和应用的问题。

06 写在最后

SOA 的确带来了很多开发模式的变化，但是细细琢磨，好像所有的变化都是来源更加底层的变化，即使没有 SOA 会有 XOA 的出现。当然每个人所处的位置、背景以及所经历的项目，都不一样，都会有自己的看法和偏见，甚至误解，我自己本身肯定也是如此。

转载自公众号：焉知汽车

原作者：jinbao

原文链接：https://mp.weixin.qq.com/s/R_uJGNtmlICM9IM2dMAIJg

SOA 的通信基石为什么是大带宽和 IP？