「软件定义汽车」时代下的SOA架构设计

「软件定义汽车」时代下的SOA架构设计01Z/nW^四驭从「软件定义汽车」到SOA用「软件定义汽车」，这可能是当今业内智能网联汽车的“风口”下，被“炒”的最火的一个概念了。为什么这么火？我个人觉得无外乎有以下几个原因：首先，在以内燃机为核心的传统汽车被新能源智能汽车颠覆的趋势下，软件在产业价值链和商业模式中的重要性越来越大：以前车厂卖车，商业模式好比是“一锤子买卖”，从机械到硬件到软件，成本和利润全部都“打包”在车价里，一旦车辆被消费者购买以后，整车厂的利润所得就到此为止了。而现在呢？拥有智能网联功能的汽车被卖到最终客户手里以后，整车厂仍然可以通过OTA的形式对车内软件包括固件进行升级，更新，甚至添加新的应用。这样一来，只要汽车没有报废，消费者就可以通过OTA源源不断地获得更多新的“功能体验”，比如ADAS系统从L2升级到L2.5后获得更加成熟的自动驾驶体验，电源管理系统BMS升级后续航里程获得大幅提升等等。但是，天下没有免费的午餐！所有新的驾驶体验，功能体验和性能升级都是需要消费者来额外购买订阅的！这种全新的商业模式最早由特斯拉推出，而现如今已经越来越多的被其他整车厂所效仿和采用。至此，整车厂的盈利模式就由以前的“一锤子买卖”变成了现在的“摇钱树”模式，值此发展下去，传统的4S店都有可能被慢慢取代：以前一些必须送修的故障或者返厂升级的Service工作，现在都可以通过OTA就可以轻松解决了。或许会有朋友不同意以上的这种说法，但是单单依从进化趋势来讲，我认为：未来的智能网联汽车，本质上，或许真的就只是一台装着4个轮子的高性能计算机。其次，随着车联网，信息娱乐系统以及ADAS系统的不断发展壮大，车内控制器的复杂程度也将越来越高，其所属的软件代码的行数也将必然会呈现指数级增长。而相对应的软件研发的费用在整车研发费用中的比例也将会大幅增加。三十年河东，三十年河西，各大车企以及供应商的硬件研发团队或将面临严峻挑战，随之而来的是软件团队的不断发展扩大。所有跟车内软件开发相关职位（嵌入式软件开发，Linux内核开发，功能算法开发等等)的薪资都将水涨船高，人才市场上的竞争不可谓不激烈。在未来高收入程序员的队伍中或将又多出一类新人群一汽车软件工程师！倘若我们从技术层面来分析：智能汽车内的系统复杂程度的提高是“起因”，而「软件定义汽车」就是自然而然会产生的“结果”。这个因果关系明了了，对我们这些开发人员来说，总的“指导思想”就算树立好了！现在新的问题来了：「软件定义汽车」和「SOAJ(ServiceOrientedArchitecture)有何必然联系？对此，AUTOSAR标准给出的解释是这样的：为了支持复杂的应用程序，同时在处理分布和计算资源分配方面提供最大的灵活性和可扩展性，AP(AdaptivePlatform)因遵循面向服务的体系结构(SOA-ServiceOrientedArchitecture)。SOA基于这样一个概念：系统由一组服务组成，其中一个服务可以依次使用另一个服务，以及根据需要使用一个或多个服务的应用程序。SOA通常表现出系统间系统的特性，AP也具有这种特性。例如，一个服务可能驻留在一个应用程序也运行的本地ECU上，或者它可以驻留在一个远程ECU上，该ECU也在运行另一个AP实例。两种情况下的应用程序代码是相同的一一通信基础设施将处理提供透明通信产生的差异。看待这种架构的另一种方式是分布式计算，通过某种形式的消息传递进行通信。总的来说，所有这些都代表相同的概念。这种基于消息传递、基于通信的架构也可以从快速和高带宽通信(例如以太网)的兴起中受益。这段话的重点，强调了SOA架构的灵活性和可扩展性，而这个恰恰与「软件定义汽车」的思路不谋而合。但是，通过采用SOA架构，虽然可以更好的支持车控软件的分布式部署与更新迭代，但是这在基于信号的通讯架构(Signal-orientedCommunicationArchitecture)下是不太可能的，至少是十分困难的。这时候有人可能会有疑问：“特斯拉就没有使用SOA，不照样可以通过OTA进行迭代升级么？”其实，实现OTA，并不需要SOA。别说特斯拉用的是基于Linux的操作系统了，就是在跑CP(ClassicPlatform)的MCU(MicroControllerUnit)上也可以实现OTA，只是具体方法有所不同。在SOA架构下，OTA的实现更加方便灵活，最主要的一个优势是可以实现软硬解耦，服务实体可以部署在任意的域控制器上，而且可以在出厂后进行部署策略的调整。这个优势衍生出了SOA在汽车功能安全方面的另外一个先天优势一一冗余。例如，对于安全性要求比较高的功能可以进行冗余部署，比如刹车控制服务，转向控制服务可以被同时部署在两个域控制器上，如果一个域控制器失效，那么另外一个域控制器上的备用服务实例立刻启动，重新与服务使用者建立连接，以保证正常功能的运转，借此实现冗余机制。当然，怎么在实时运行环境下保证这一套动作的快速完成(两次ServiceDescovery的完成，一次在开机初始化阶段，一次在默认服务实例失效时)，需要在具体实现的过程中做更深入的研究。结合SOA的各种特性回到本段最初的问题「软件定义汽车」的过程和「SOA」(ServiceOrientedArchitecture)有何必然联系？我的答案是：“不一定，但是SOA肯定是可行的解决方案之一”。说了这么多，下面咱们就假设要做一个SOA架构设计，来看看从头至尾都需要完成哪些具体的工作。SOA的设计流程UTOSAR标准中定义了AP的开发流程示范，其中也包含了SOA相关的开发步骤。

SWPackageexfitLlableOSExecution[Vanagemenc审¥APIMachin*NanifestExecutionManrfestdefllcymcnt.ai；thentrar™,n^tdllalucrotherfunctionalclusters5ff\lcelnt«rf«eDEScriptionstartup,configureOSshuldffwn,„rDevitopSoftwareD&visilopPlatformsndConfigureMachineoffbaand'imschineA；SWPackageexfitLlableOSExecution[Vanagemenc审¥APIMachin*NanifestExecutionManrfestdefllcymcnt.ai；thentrar™,n^tdllalucrotherfunctionalclusters5ff\lcelnt«rf«eDEScriptionstartup,configureOSshuldffwn,„rDevitopSoftwareD&visilopPlatformsndConfigureMachineoffbaand'imschineA；Adaptive

ApplicationIntegrateSoFt^aiaDetinaandConfigure

SeruceInslauesService

instance

Manifistprocess1-1(loaded!execulaNenstance)iii曲liedexecuEable1*Lr^=F=F.41AP\SWConfigurathn|ManagementW0

APIprocessed:■mcriiksts'-乞几何四驱J图2-1：AP开发流程示范大体上，AP(AdaptivePlatform)的开发是一个“从上至下”的流程,其中跟SOA设计相关的有以下几个重要步骤：服务定义(DefineServices)从整车层面按照功能需求定义并划分服务。那么到底什么是服务(Service)呢？IEEE对Service的定义如下：服务是一个独立的功能单元，可以远程访问和独立更改或更新。服务(Service)一般应具有如下特性：•代表功能单元(Representsfunctionalunit)•是自我包含的(self-contained)•是无状态的(stateless)•使用标准接口进行通讯(usesstandardizedinterfacestocommunicate)•对外是一个黑盒子(blackboxforconsumers)•可重用性(reusability)•可以由下层服务组成(canconsistofunderlyingservices)此步骤实际上就是搭建了一个系统功能架构。服务接口描述(ServiceInterfaceDescription)本质上就是想办法从功能架构过渡到软件技术架构并对服务接口进行定义。如果是同时包含CP和AP的架构，则还需要定义从CPSWC(CPSoftwareComponent)接口到服务接口的映射。

CdmmoniSahwar^Archileclur^CdmmoniSahwar^Archileclur^如上图2-2所示：不论是从哪种视角，软件模块之间的相互关系都需要被表示出来。对于SOA来说，需要定义清楚服务之间的相互关系，也称为服务编排(ServiceOrchestration)。下面我们来具体举例说明。!s«ra'ti-crthcstrzHan图2-3!s«ra'ti-crthcstrzHan图2-3:服务编排图2-3为我们展示了一个简单的关于获取天气信息的例子：Test作为服务消费者(ServiceConsumer)想获取当前位置的天气，只需要申请使用服务提供者(ServiceProvider)WheatherControlService提供的服务。而它本身又是依存于另外两个基础的服务，一个是MapService，另一个是WeatherService。它只需要通过服务接口申请使用这两个服务即可。有了上面的软件架构，接下来我们需要来定义具体的服务接口(ServiceInterface)，具体定义见图2-4

ServiceInterfaceAmethodrepr已s已nt5afuniztianthati5executedbyaprovideronrequestofoneormorewn&umeir(5)ServiceInterfaceAproperty(fieldra^triDute)n&presentsapieceofdatahostedbyaproviderthatexposestooneormoreconsumer(s^agetond/or住setmethod.Consumers匚anoptionallyreceivenotificationsofchangesofthefieldsvalue.Anevent-epresentsanupdatetoapieceofdata.Theproviderdecideswhentosendthisupdat己andtheoccurnenc$ofitis';nfppj-tte^ifromatooneormoreconsurnfir(^).'」—lo-图2-4服务接口定义服务接口可分为以下三种类型：•方法（Method）:在服务消费者要求下一个由服务提供者执行的函数•属性（Property）:由服务提供者管理的数据，对消费者可见，可以通过get/set方法操作，并且可以在有变动的情况下收到通知•事件（Event）:表示一块数据的更新。服务提供者决定何时发送此更新给一个或多个服务消费者可以看出，这里对服务接口的定义是完全抽象的，跟通信协议无关的，任何两个服务之间都可以使用此接口进行通信。而使用合适的工具链可以由此生成基于特定协议的接口，比如webservice,AA(AdaptiveApplication)接口或者CPSWC接口。有了服务及其接口的定义，接下来就可以交给软件开发人员进行开发了。通过软件集成生成软件包(SoftwarePackage)，它包含可执行文件(executable)，执行清单(ExecutionManifest)和服务实例清单(ServiceInstanceManifest)。最后这个服务实例清单是通过定义与配置服务实例生成，也是我们下面要重点说明的一个步骤。定义与配置服务实例(DefineandConfigureServiceInstances)对服务进行部署，也就是建立服务实例到机器(AP)或者ECU(CP)的映射(软件/硬件之间的映射)，此步骤会生成服务实例清单。Technolo肿mapping图2-5Technolo肿mapping图2-5服务实例的映射图2-5中为我们展示了映射服务接口的两种类型映射到Machine上的APSWC映射到ECU上的CPSWC其中，一个SWC对应服务编排中的一个服务提供者或者服务消费者。需要注意的是，AP和CP支持的软件接口是不一样：AP支持服务接口，所以之前定义的服务接口可以1比1的拿过来用。而CP不支持服务接口，所以这里需要一个接口之间的映射。

Softwaresynthesis；ALfFOSARClass:C,rAUTOSARAdaptiveSoftwaresynthesis；ALfFOSARClass:CI图2-6软件接口之间的映射图2-6中所展示的是从抽象的接口定义到具体的软件层面接口的映射。左边是1比1的到APSWC接口的映射（或者说实例化），因为APSWC本来就支持服务接口。而右边则是到CPSWC接口的映射，因为CPSWC不提供服务接口。为此需要使用CP中现有的接口对服务接口的三种类型（图2-4）分别进行描述：

■Method:•对于带参数的Method可以使用Client-Server接口•对于带自变量的Fire&ForgetMethod可以使用Sender-Receiver接口•对于无参数的Fire&ForgetMethod可以使用Trigger接口Property:•对于Get/Set操作（对property的读写）可以使用Client-Server接口•对于notifier（由于property改变而触发的事件）可以使用SenderReceiver接口Event:•触发事件，可以使用Sender-Receiver接口至此我们完成了从抽象的服务定义到软件层面的推导。接下来是通讯协议层面的设计。Bito-iM1CL°!■+【£:dLBito-iM1CL°!■+【£:dL内‘片毎牙订此1kSariixvScriicDiiHtapt-w3护HardwmcL:I!」WasfUHr:1UCU图2-7通讯设计图2-7中展示了AP下SOA架构的整个设计流程。从服务定义到服务实例化，我们在前面都解释过了。最后一步就是红框标出的部分，以太网通讯设计。以太网通讯设计主要是对服务实例进行相关的通讯协议层面的配置，包括VLAN，Switch，Socket，SOME/IP，SD等。配置完成之后可以生成Arxml文件。这一步的输出是服务实例清单，也是前面提到的软件包的一部分。混合系统的S0A设计前面的部分，我们着重向大家讲解了纯AP以及纯CP系统的SOA设计流程，但是实际工作中，还有一种更常见的，是AP与CP共存的混合系统，这里我觉得有必要为大家简单说明一下在此类情况下的SOA设计要点。AUTj?：SAR口・hIcFLitl'iira•:€0_tni2—CO_C*H1'AUTj?：SAR口・hIcFLitl'iira•:€0_tni2—CO_C*H1'如匪CU•^；CO_CAH1AUT^SAR■CIibk:HiifM-mAxIb*UviFkvtlcrin昱UT(oy耳FlClbMkPWfWraandroid*图3-1混合系统示例在上图3-1中我们可以看到：在这个拓扑结构中，有两个APMachine（绿色）和三个CPECU（淡蓝色）节点。而在ServerMachine上又同时存在AP，CP还有android系统。整个网络拓扑又可以分成上下两个Cluster:上面的Cluster使用基于信号的传输协议，下面的Cluster使用面向服务的传输协议。

这导致我们需要在中间这个ServerMachine上实现一个从信号到服务的转换(signaltoservicetranslation)。图3-2：SignaltoservicetranslationonAPmachine在图3-2中，AP上的黑色模块就是用来实现此转换的。转换完成以后得到的服务实例就可以被AA(AdaptiveApplication)通过ara::comAPI直接使用了。

D«*gr>/pp!iC37i«1LH2£f炖£■-&TWVtaraiiU^iBlr4m3ah.¥Hin>Hard-niUAKaocihgLl$«・伽trutarkirtL^Bi旳耳EburkMHfrIM氏加*kCK询i*KU1ECUSum.D«*gr>/pp!iC37i«1LH2£f炖£■-&TWVtaraiiU^iBlr4m3ah.¥Hin>Hard-niUAKaocihgLl$«・伽trutarkirtL^Bi旳耳EburkMHfrIM氏加*kCK询i*KU1ECUSum.EeUExifdCi:图3-3：混合系统的设计流程上图3-3描述的混合系统的设计流程与前面的AP的设计流程大同小异。除了需要同时完成AP和CP的几个类似的步骤之