欢迎关注下方公众号阿宝1990，本公众号专注于自动驾驶和智能座舱，每天给你一篇汽车干货，我们始于车，但不止于车。
【摘 要】 针对异构SOC实时内核部署SOA服务的性能瓶颈，文章设计一种基于车载异构计算平台的SOA服务部署方法。实时内核从总线获取和提供原始数据，通过核间通信协议传输至性能内核，性能内核基于SOME/IP协议将原始数据封装为服务进行发布。与传统的直接在实时内核上发布SOME/IP服务的方式相比，该方法能显著降低实时内核系统的开销，有效解决实时内核运算力不足、无法支撑大量SOME/IP报文发送的问题。同时，由于性能内核具有强大的运算能力，后续服务可以灵活迭代与扩展，用户可以获得更加便捷的车控交互体验。
1 研究背景
随着汽车硬件配置趋同，整车厂很难在硬件上打造差异化，软件定义汽车 （Software Defined Vehicles，SDV）趋势愈发明显。SDV可以帮助汽车实现功能的创新，满足新生代用户千人千面、千车千面的个性化需求。软件高速迭代升级，能不断为用户带来全新的驾乘体验，提高产品的竞争力，增加用户对品牌的黏性。面向服务的软件架构（Service-Oriented Architecture，SOA）在计算机领域已经被证明是一种高效、灵活的系统软件架构，为汽车软件践行 “软硬分离，软软解耦”的SDV理念提供了重要的理论支撑[1-2]。SOA在汽车应用场景中，将车端不同软件的功能及硬件抽象为具有标准接口的服务，服务的客户端和消费端通过既定协议相互访问、扩展组合[3]。服务调用通过系统内部IPC或者以太网SOME/IP协议实现[4]。当前，汽车电子电气架构 （Electrical/Electronic Architecture，EEA）已经发展到集中式架构 （EEA3.0）阶段，EEA3.0可以满足汽车业务需求与硬件资源解耦，具备实现SOA的能力。其中，中央车载计算平台是汽车应用场景中SOA服务部署的主要载体。中央计算平台主要采用高性能的集成多个处理器的异构SOC芯片，其软件架构是异构体分布式操作系统协同合作的软件架构，不同的操作系统运行满足具有不同功能安全等级、信息安全等级及实时性要求的应用软件[5]。中央计算平台的性能内核和实时内核分别基于Adaptive AUTOSAR和Classic AUTOSAR标准，可以分别实现功能的服务化，对外发布服务或者请求服务。但限于实时内核的处理能力和系统CPU、RAM及网络资源，在实时操作系统上的服务直接通过SOME/IP方式提供的开销过大，当服务数量达到一定量级时，该方式会产生明显的性能瓶颈，甚至导致无法部署的情况，无法满足当前车辆功能全面服务化的需求。而当前的车载计算平台通常是基于异构的SOC芯片开发，实时内核上大量的车辆基础控制能力需要以SOA服务的形式提供给性能内核上POSIX操作系统、车上其他计算平台或云端的服务消费方使用。所以克服实时操作系统的性能瓶颈，解决实时操作系统提供服务的方式和能力，是实现整车功能全面服务化，充分发挥整车SOA优势的关键。
针对车载计算平台实时内核部署SOA服务的瓶颈，本文将设计一种基于异构SOC计算平台的SOA服务部署方案，即一种将实时内核的服务通过核间通信协议传输至性能内核，再通过服务代理在性能内核进行部署的方式，能显著降低实时内核端的资源开销，提升相关SOC上可部署服务的数量。
2 方案设计
2.1 中央计算平台架构方案设计
本文采用异构双核SOC作为车载中央计算平台的主控芯片，主要包括性能内核和实时内核。中央计算平台根据不同业务的实时性、功能安全及信息安全等要求划分为3个分区：VM1、RT1和RT2。VM1分区为性能内核，搭载Linux操作系统和Adaptive AUTOSAR中间件，用于部署对算力要求较高的应用；RT1、RT2分区为实时内核，采用Classic AUTOSAR的实时操作系统，用于部署实时性和可靠性要求高的应用。根据AUTOSAR设计原则，需要进行软件分层设计，分层的目的是实现软硬解耦，软软分离，实现服务的灵活部署。本文软件架构划分为5层，如图1所示。其中，L1层为硬件相关的基础软件；L2层为操作系统相关的基础软件；L3层为具备跨域通用性，为上层提供基础功能或服务的基础中间件；L4层为专属于特定域，为上层提供基础功能或服务，并做服务封装的专用中间件；L5层为用于实现具体逻辑的应用软件。结合了高性能和高实时性的计算平台，可以承载整车基础性功能和智能舒适功能。
图1 异构中央计算平台的软件架构示意图
2.2 SOA服务的部署方案设计
SOME/IP是一种面向服务的可伸缩的中间件协议，是实现SOA接口契约化的重要的支撑协议之一[6]。在SOME/IP通信过程中，通常把提供服务的一端称为服务端 （Server），请求服务的一端称为客户端 （Client）。SOME/IP传输的主体是Client和Server，传输内容为服务Service。服务是一个自包含的、无状态的实体，一项服务实体由事件Event、方 法Methods 和 字 段Fields 等 组 成[7]。SOME/IP 服 务 发 现（SOME/IP Service Discovery）是SOME/IP中的服务发现机制，Client可以通过SOME/IP SD来查找服务的位置，判断服务的可用性，或者订阅事件组等，基于SD可以实现车内节点的即插即用[8]。Client可以用Request-Response、Fire&Forget模型访问Server所提供的服务；Server利用Notification推送给Client已经订阅的服务内容。
计算平台性能内核通过部署Adaptive AUTOSAR[9]、实时内核通过部署Classic AUTOSAR[10]提供实现SOME/IP服务通信的方式分别如图2和图3所示。在Adaptive AUTOSAR中，SOA服务主要通过标准组件Communication Management（CM）以及VSOMEIP协议栈实现。Classic AUTOSAR中服务主要通过RTE、COM、PDUR以及SOAD等AUTOSAR标准模块实现。
图2 SOC的性能内核SOA服务架构示意图
图3 SOC实时内核的SOA服务架构示意图
由于提供整车控制能力的基础服务绝大部分来自于实时核上部署的Classic AUTOSAR 的应用或者依赖传统的CAN总线信号，考虑到实时内核的算力和核资源，为了尽可能部署更多的服务，对外提供更多的整车车控的能力，本文设计了一种性能内核代理实时内核发布SOA服务的部署方案。如图4所示，为了实现服务代理，在性能内核和实时内核的L4层分别部署SOA服务代理专用中间件和SOA API分发专用中间件。实时内核的SOA API分发中间件从RTE接口获取服务Server SWC的功能，通过L3层核间通信转换模块Inter core Comm将实时内核的功能信息传至性能内核的SOA服务代理中间件；然后性能内核的L3层Adaptive AUTOSAR 通 信 管 理 中 间 件（Communication Management，CM）通过API接口获取SOA服务代理的信息，将实时内核的功能进行服务化；最后，协议栈以IPC或SOME/IP的方式提供服务。
图4 异构SOC的SOA服务架构示意图
实时内核上的SOA API Convertor组件将AUTOSAR标准接口进行语义转换，其中RTE C/S接口转换为服务接口Method，RTE S/R接口转换为服务接口Event或Field。转换后的服务接口参数、服务提供方ID、服务ID等信息序列化后，通过异构计算平台内部总线Inter core Comm提供至性能内核端。性能内核代理实时内核实现SOA服务的接口映射如表1所示。部署于性能内核上的SOA服务代理组件通过内部总线收发接口获取SOA API Convertor所提供的服务信息，对其进行反序列化解析后，将其转换为标准的服务调用接口暴露至中央计算平台内部IPC通信或外部SOME/IP通信上。中央计算平台内部Client通过系统内IPC通信，根据标准的服务接口 （Method、Property/Field、Event）调用服务。外部Client通过以太网SOME/IP协议，根据标准的服务接口 （Method、Field、Event）调用服务。
表1 性能内核代理实时内核实现SOA服务的接口映射表
2.3 基于异构计算平台的音乐律动氛围灯SOA服务设计
基于性能内核代理实时内核实现SOA服务的部署方法，本节以车载音乐律动氛围灯服务为例，介绍异构车载计算平台实施SOA服务代理的具体方案。
2.3.1 音乐律动氛围灯功能需求分析
音乐律动氛围灯的功能主要为灯光颜色或亮度跟随音乐节奏和响度改变。音乐律动氛围灯功能交互如图5所示，发出激活或退出该功能指令、提供音乐信息的控制器为信息娱乐域控制器 （Infotainment Domain Controller，IDC），IDC 上的软开关控制指令使能该功能，IDC可以提供5种特定的音源类型 （USB、BT Music、Car Play Music、Car Life Music、Online Music），中 央 计 算平台收到音乐信号后对音源类型进行判断，当音源信号为非指定的音源类型时，音乐律动氛围灯功能自动退出。当出现音乐暂停或停止、音源信号插播导航、电话等其他效果时，IDC主动将音乐信号切换为OFF，退出音乐律动氛围灯功能。
图5 音乐律动氛围灯系统交互图
氛围灯随音乐律动的功能需求为：IDC播放音乐时，向中央计算平台发送每25ms时间内的最大音乐振幅、最大分贝值和最大分贝值对应的频率值等音乐特征。中央计算平台根据接收到的音乐特征控制氛围灯的颜色和亮度跟随音乐节奏进行律动。
2.3.2 音乐律动氛围灯服务设计
基于EEA3.0电子电气架构，实现音乐律动氛围灯应用功能的物理架构如图6所示，IDC是音乐律动氛围灯服务的Client，中央计算单元是服务Server，区域控制器是灯光颜色和亮度变化的执行单元。中央计算平台与IDC之间的通信采用车载以太网，氛围灯的区域控制器与中央计算平台之间的通信采用CANFD总线，计算平台实时内核与性能内核之间通过核间通信协议交互。
图6 音乐律动氛围灯应用功能的物理架构
IDC提供播放音乐和音量调节等功能。作为音乐灯光秀功能的消费方，IDC可直接请求中央处理单元的服务接口来判断进入音乐灯光秀功能条件，并控制音乐律动氛围灯功能的开启或退出。中央计算单元作为服务的提供方，提供服务调用的接口，中央计算平台的实时内核根据接收到的音乐特征按照相应算法计算后，向区域控制器发出控制灯光颜色和亮度的指令。区域控制器驱动灯光呈现氛围灯的效果。
根据功能需求结合SOA的设计思想，对音乐律动应用涉及到的基础服务设计如表2所示。IDC提供氛围灯音乐律动管理服务包含音源类型、所播放音乐的特征信息设置功能。中央运算平台的实时内核的SWC提供氛围的控制服务，性能内核的SOA代理模块通过核间通信代理该服务，SOA代理对外提供氛围灯控制服务。音乐律动氛围灯应用通过消费音乐播放和氛围灯控制基础服务，来实现控制车上的氛围灯的颜色和亮度随着音乐播放的声音和节奏变化而变化的功能。
表2 音乐氛围灯服务矩阵
3 试验验证
3.1 测试方案及测试环境
基于SOME/IP的SOA服务测试主要包括ECU级的协议一致性测试、系统级与实车级的通信测试。本文侧重验证氛围灯音乐律动服务的信息交互行为和响应实时性。音乐氛围灯服务发布和调用的过程如图7所示，为了测试服务链路中的数据传输情况，需要获取IDC与中央计算单元之间的SOME/IP报文，以及中央计算单元的SOA日志。
图7 服务发布和调用过程
台架测试环境如图8所示，测试平台包括VN5650和配套软件CANoe16.0，被测件为中央运算单元，性能内核作为服务端 （Server）提供氛围灯音乐律动服务，上位机作为客户端 （Client）模拟主机调用服务。VN5650作为以太网接口收发中央计算平台的以太网报文，通过CANoe的报文Trace观察中央计算平台与模拟客户端的SOME/IP信息交互情况，通过SOA日志、核间通信日志分析服务发布和调用过程。
图8 测试环境
3.2 结果与分析
3.2.1 服务代理方案有效性分析
SOA进程及核间通信启动后，服务发布过程的SOME/IP SD报文及SOA日志信息如图9所示。性能内核的SOA服代理模块通过核间通信主动连接实时内核的SOA API分发模块，连接成功后，SOA服务代理调用CM以SOME/IP的方式发布服务，即广播SOME/IP SD Offer Service报文，告知氛围灯律动服务 （Service ID：0x10D3）已经启动，有需求的Client方可根据SOME/IP SD报文中0x10D3服务所在的IP地址和端口号等信息与Server方创建连接。
图9 音乐氛围灯服务发布过程日志信息
确认氛围灯服务为可用状态后，如图10所示，上位机模拟IDC （Client）发送SOME/IP Setter报文，通过CurAudioSource 接 口 将 音 源USAGE 类 型 设 置 为BTMUSICE 型（Method ID：6001，Payload：0x4），通过CurToneFolloInfo接口将音乐的振幅、频率和分贝设置为00 00 00 00 00 00 （Method ID：6002，Payload：0x00 00 00 00 00 00）。SOME/IP Setter 报 文 上 报 给CM 后，CM 进 行Service ID：0x10D3，Method ID=6001或6002的调用，性能内核的SOA代理收到SOME/IP Setter报文的Payload等参数信息。接着，SOA代理通过核间通信向实时内核的SOA API分发发送Setter报文，实时内核的氛围灯控制SWC通过RTE接口获取Setter信息，执行相应逻辑后，SOA API分发通过RTE接口获取SWC的执行结果，并通过核间通信发送回性能内核，CM收到后，回复Setter应答，最后由SOME/IP协议栈回复IDC的Setter请求。
图10 音乐氛围灯服务调用过程日志信息
3.2.2 服务代理方案响应实时性分析
为了保证音乐节奏和氛围灯律动的匹配，获得良好的用户体验，要求中央运算单元收到第1帧音乐数据的时间要比人耳听到音乐的时间早，并且中央运算单元对音乐节奏变化的响应时间小于或等于人耳对音乐节奏变化的响应时间。因此，需要分析音乐氛围灯服务响应的实时性。如图11所示，以性能内核接收Setter请求报文和发出应答报文 为 起 止 时 间，调 用 一 次Service ID：0x10D3，Method ID=6002的时间为25ms，符合人体对音视频同步的感知要求 （音频相对视频超前20ms到延后90ms的范围内，人体对音视频同步不敏感）[11]。
图11 调用一次音乐氛围灯服务所需时间
为了验证IDC以短周期频繁调用氛围灯服务时的响应实 时 性，模 拟IDC 在10min 内 以50ms 为 周 期 调 用 服 务，10min内实际调用周期及音乐氛围灯服务响应时间如图12所示。实际调用服务的平均周期为51ms，服务响应的平均时间为23ms，符合响应实时性要求[11]。
图12 10min内模拟IDC调用服务周期和10min内音乐氛围灯服务响应时间
4 总结
面向服务架构 （SOA）被认为是能够支持未来汽车软件发展的核心技术之一，汽车制造商OEM向SOA架构转型，期望汽车行业的商业模式从一次性购车逐步转变为对智能驾驶体验、智能服务体验、座舱娱乐体验的持续升级迭代消费，智能汽车成为持续创造价值的平台。本文提出的基于异构SOC的中央计算平台服务部署的方法，突破了异构SOC实施内核提供服务的性能和资源的限制，大大提升了整车功能服务化的水平。试验结果表明按照异构SOC服务部署的方案可实现音乐律动应用的功能，满足其功能对代理服务实时性的要求。
参考文献：