欢迎关注下方公众号阿宝1990，本公众号专注于自动驾驶和智能座舱，每天给你一篇汽车干货，我们始于车，但不止于车。
本文约6,200字，建议收藏阅读
作者 | jinbao
从踏入职业生涯就开始接触所谓的SOA，一直都在思考什么是SOA，通信基石又是什么？是以太网？是someip？是dds？亦或者其他协议？那我的答案：都不是，是大带宽和IP。SOA在车载真的是一个很新的东西么？在我看来，其实也不算是，在cp中，站在高层开发者来说，RTE+SWC未尝就达不到我们所谓SOA需要解决的痛点！那为啥依然SOA还会成为主流的“软件定义汽车”的解决方案之一呢？SOA是解决什么问题？原来的痛点到底是在哪里？SOA的通信基石为什么是大带宽和IP呢？接下来会从CP RTE中理解SOA，从而体会到SOA和CP之间并不是颠覆性的新思想。下述AP大部分场景都不是准确指的adaptive autosar，而是soc车载中间件的统称。
从两个不同的视角来描述这个问题：SWC设计者和SWC的开发者。- 不同车型重用--形成foundation service
从上述两个视角来看，会发现CP就是为了解决这些而生的，站在他们的视角来看，不管CP是静态的还是动态，对于他们来说，都只想关注上述的一些点。
前面提到了，站在功能设计者和开发者来说，他们并不关心让他们达到灵活的平台是静态还是动态，他们需要的是：个人理解：所谓的静态和动态，其实需要从不同的维度来理解，现在很多所谓的动态配置，大部分理解的是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需要提供一个平台，能够让原子服务很轻易的组合，而且该平台能够提供很好的平台部署能力，让应用的设计和开发者可以专注自己的领域。
AUTOSAR CP解决方案：工具、设计上移和左移、标准工具是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）。大家会发现vector家的工具是最好用的，除了在UE的上体验，更多的是他们家的工具做了很多很多校验，大部分场景下，工具生成出来基本编译不会有问题，很多时候也能正常运行。这其实就是设计上移至工具链，和校验左移至开发阶段。其中设计上移最典型的一个案例就是：资源分配最终在源代码中几乎完全是静态的，但是对于开发者来说，是很轻松在开发阶段灵活分配的。而校验左移，追求的是：工具能够生成，则代码没有问题，这当然是一个很美好的愿景了，但这恰恰是每家cp做的是否好的关键，也是难度最高、工作量最大、最需要积累的！前面提到了，需要定义原子服务+基础功能服务，而cp已经标准化了一部分基础服务，如：NvM，Com，ComM和BswM等。而其他层面，由其开发流程+软件架构、规范进一步定义了如何开发和集成，所以不同团队都会有趋同的开发流程。那对于在soc来说，如果说为了运行时效率，其实依然需要依赖：工具、设计上移和左移、标准，只不过对于soc来说，由于其运行时特性，可以不需要所有的东西都依赖于工具，比如一些配置可以使用配置文件，功能组合可以使用动态库使用动态加载，更新时可以只更新库或者配置文件。剩下无非就是根据上述需求实现一套契合soc的中间件，而这些对于不需要构建底层方法论、有各种参考+人才众多的情况下，并不是太大的问题，主要问题反而是解决性能和确定性了。 •Atomic Component Vs Atomic Service •Composition Vs Foundation Service- 自上而下---从需求分析出发，导出服务定义，然后进行服务编排，服务接口的定义，最后是软件到硬件的映射以及对通讯协议的配置。
- 软件灵活更新---修改功能时只需更新、升级部分软件
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软件构架下的底层软件也就是“服务”，具有接口标准化、相互独立、轻耦合三大特点。标准化：各个服务间有界定清晰的功能范围，并且有标准化的访问接口，以便上层应用进行功能变动或者升级的时候，底层软件保持不变。相互独立：每个服务之间相互独立没有相同部分且唯一。松耦合：底层软件跟硬件、车型、应用、ＯＳ、编程语言不耦合，其他部分可以随便换，底层软件不用动。整体上把ＳＯＡ软件抽取出来，形成一个中间件，开发完成就不用变动了。然后开发人员可以集中精力编写上层应用去实现功能创新。
在汽车行业说，说到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的全部，即使基于以太网也可以在面向信号的架构完成服务通信。
在引入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文档进行详细规范定义，所以仍旧需要各供应商或者软件团队自己进行实现。- 部署在网关，所有的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，就能解决传统开发过程中的所有问题么？在各种场景和架构中，我们往往都会发现，新的设计很多时候并不是解决问题，而是转移问题，问题转移并不是变得简单了，而是变得合作起来更加方便了，以此达到提效的目的。
前老板曾经说过：不管车如何变化，其主体永远是机械，或者即使软件扮演的角色越来越重要，但是它依然是机械。当然结合当时情景，他想表达并不仅仅是技术层面的问题，同时这句话并不是反对软件的重要性。之前有架构大佬提过，软件能定义汽车么？其实我的答案跟他类似，软件并不能定义汽车，定义汽车的依然是产品经理，无非产品经理需要比之前懂得更多，需要集合新的整车电子电器架构来思考如何更好的落地。为什么说没有银弹？在《人月神话》中，佛瑞德·布鲁克斯预言：没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。因为：“软件的根本困难（Essence，包括复杂度、一致性、可变性、不可见性）在软件问题中占据的份额超过了10%”。前面分析来看，CP和SOA在顶层设计来看，并没有什么本质的区别，所以对于功能定义者和开发者来说，原有的工作和困难（软件的根本困难）并没有发生变化；而soa带来的灵活性也没能解决所有的问题，并且又带来很多新的问题，比如：确定性和可靠性。而车是一个高度集中又同时是一个分布式系统，其分布式节点的变少才是导致开发变简单的关键。但是原有分布式系统的兼容性、一致性，依然是存在的，并不会因为引入了SOA就没有了。ps：想起前段时间跟前同事吃饭，据描述，他们的软件发版经常出现基础软件和应用软件接口不兼容的问题，并为此特地预留2周做接口的兼容集成。所以问题的本身又转移到了在高度集中的单一系统内如何保证高效开发、集成，而原有的高可靠性的系统在以太网+soc下又是如何保证？所以有了自研、有了全新的组织架构，有了tsn，有了确定性通信和确定性调度。SOA的出现与EEA架构是相辅相成的，SOA也仅仅是一种技术方法论，就像面向对象一样，都有其适用的场景和应用的问题。
SOA的确带来了很多开发模式的变化，但是细细琢磨，好像所有的变化都是来源更加底层的变化，即使没有SOA会有XOA的出现。当然每个人所处的位置、背景以及所经历的项目，都不一样，都会有自己的看法和偏见，甚至误解，我自己本身肯定也是如此。