面向智能汽车的SOA架构及服务调度机制研究 *

郝建平，苏炎召，钟志华，黄 晋

（清华大学车辆与运载学院，北京 100086）

前言

在软件定义汽车中，面向服务的架构（serviceoriented architecture， SOA）是搭建软件体系的总体设计理念，其与传统软件体系相比，最明显的特征是能够减少系统软件和信号资源的浪费、提高开发软件的可重用性［1］。SOA 赋予了软件定义汽车丰富的软件开发能力，用SOA 思想设计的SOA 软件架构是软件定义汽车发展的必然趋势之一［2］。

现阶段汽车SOA 主要依附于Adaptive AUTOSAR 标准（即AUTOSAR AP）实现，但由于AUTOSAR AP不能部署传统AUTOSAR CP中逻辑执行时间（logical execution time，LET）等确定性和实时性机制，其不能保证程序运行的确定性和实时性，给安全关键性系统带来相当大的隐患［3］。因此，目前汽车SOA 应用的软件运行集中在智能座舱域内，将车灯、车窗、车辆状态（如温度、车速）传感器等基础硬件的功能作为原子服务，再进行该领域内组合服务的设计，聚焦于提升用户驾驶的舒适性，而不参与安全关键性系统，如制动辅助、运动控制等，一方面由于这样对智能汽车直接驾驶过程的影响较小，另一方面也是因为汽车厂商在SOA 应用初期为了降低测试成本和潜在危险做出的妥协。但这样也难以利用SOA 的优势对直接驾驶过程进行优化。因此，本文希望SOA 的实时性和确定性能满足的前提下，将SOA 在汽车上的应用范围从智能座舱域扩展到其他系统域，在原子服务目录中加入了与自动驾驶等系统级功能关联的软件和算法。

实现一类功能时，可以存在多种可选的子服务，这样的子服务可被分类为一个服务层级。显然服务层级相较于单一的服务而言，存在选择空间多的优势，在不同的环境条件下，能通过选择更合适的子服务来达到更好的运行效果。现有智能汽车通常在自动驾驶的各个环节中采用固定的算法和硬件，虽然保持了运行的稳定性，但同时在某些场景下可能会显著降低效率。如视觉传感器在低光下、超声波雷达在高速下运行效果不佳，因此汽车厂商须采用传感器融合，同时启用多种传感器来保证传感数据的精确性；不同类型的轨迹规划、障碍物检测等算法也会在不同环境下存在更优的选择，但一般只会固定采用一种类型。由此可见，在多个服务层级中选择当前环境下各服务层级中适合的子服务，即服务调度，可以带来汽车SOA系统总体性能和效率的提升。

在计算机领域，服务网格（service grid）［4］作为大规模网络计算系统的一种类型，也采用服务的方式来包装系统机构中的资源，同样也具有调度的需求，并采用服务质量（quality of service， QoS）的评价指标进行调度算法的设计［5］，这与汽车SOA 的调度需求有诸多相似之处，因此可以分析网格计算的服务机制设计思路，进行汽车SOA的设计。

综上所述，为了尽可能发挥SOA 在软件定义汽车上的应用价值，可以在目前的汽车SOA 架构中拓展SOA 的服务层级范围，并引入服务调度算法，进而提升驾驶性能和效率。在不同的服务层级中，服务调度算法可以实时地选取当前环境下更适合的子服务，从而提升汽车在各种复杂环境条件下的自适应性，这也是软件定义汽车应具备的重要特征。

1 汽车SOA架构及分类

1.1 可调度SOA层级分类

汽车SOA 架构一般为多层架构，从下至上分别为硬件层、服务层、应用和算法层［6］，遵循粒度逐渐增大的规律，将需要大量重复使用的服务划分为小粒度，即原子服务；原子服务组合后可以成为粒度更大的组合服务，实现一套稍复杂的完整功能逻辑；而应用和算法层实现了若干完整的用户级功能，可以调用各种原子服务和组合服务，是最完善和复杂的层级，如图1所示。

图1 通用SOA架构图

符合服务调度要求的SOA 服务层级须满足两个条件：其硬件或软件的功能可以被抽象为SOA 中的服务，即符合SOA 应用的硬性条件；其最终实现的功能存在被调度的必要性，即在环境影响下能发生显著性能变化，或能提升用户体验。

SOA 服务层级可以由硬件或软件组成。对于硬件而言，SOA 应用条件的主要限制为通信协议。汽车SOA 的通信协议通常使用SOME/IP，是一种适用SOA 大数据和标准化传输的先进协议［7］，属于车载以太网的范畴，而与传统汽车大量使用的CAN 通信协议存在很大的不同［8］。主要区别可以概括为：CAN协议的实时性高，为微秒级的硬实时协议，数据量小，在须保证可靠和实时性的汽车硬件上仍无法取代；SOME/IP 一类的以太网协议传输带宽大、但实时性没有CAN 协议高，能实现毫秒级的软实时要求，适合用于传输多媒体数据，以及实时性要求相对较低硬件。

因此，对于仍须使用CAN 协议的动力与控制功能域的执行器硬件，如电动机、转向控制等硬件，属于具有硬实时要求的硬件服务［9］，由于无法接入SOA 服务，也无法用于服务调度。根据不同的功能区间，可以将可调度的硬件层级分为如表1 所示的几种类型，并分别对每种类别进行了若干举例。

自动驾驶域的硬件以激光雷达等感知传感器为代表，其性能会受到环境变化的显著影响，具有服务调度的必要性；车身与座舱域、动力与控制域的传感器可以为智能软件算法提供汽车运动或环境的信息，车身与座舱域的执行器作为软件的输出，都与后者具有直接相关性，因此也可以随软件一起进行服务调度。而动力控制功能域的执行器一般采用CAN协议，现阶段一般无法被直接抽象为SOA 服务，但可以采用“服务代理”的方式，将整个旧的软件模块包装为软件黑盒，成为一个类似软件服务的整体功能，保留在旧架构下的既有成熟代码［10］。但这种方式作为额外的转接层，会降低效率和可被用户察觉的性能，影响实时性，因此对于实时性要求高的模块，只应该在服务代理的黑盒预留出实时性要求不高的状态发布类信息接口，也就被归类到动力与控制域的传感器范畴，因此执行器由于硬实时的需求，在严格意义上仍然暂时不能接入SOA。

对于软件服务层级而言，理论上现阶段智能网联汽车的各类软件都可以被抽象为SOA 服务，如表2 所示，但应用最广泛、最多讨论的功能域为智能座舱相关的对人智能类型软件。此类软件投入成本相对较小，对汽车运行的影响小，试错成本较低，适合作为SOA 车用探索阶段的软件类别。其他可被调度的类型还有自动驾驶相关软件算法、对车和路智能的智能座舱软件，及控制通信的车联网软件等，这些功能对汽车的行驶性能有直接影响，测试成本较大，适宜在SOA 应用更成熟广泛后再纳入体系；或因车路云系统本身不够成熟，相关基础设施也没有普及应用，不适宜在现阶段就考虑SOA 的部署。但这些技术的相关成本和成熟应用问题得到改善后，将其纳入SOA 的可调度层级中，能将汽车SOA 的服务范围拓展到更通用的范围。

表2 可调度SOA软件服务层级分类

1.2 影响调度的关键环境因素分类

对于不同的SOA 服务层级，不同环境因素的影响也不相同。对其性能或功能有显著影响的环境变化，称之为关键环境因素，否则为非关键因素。能对服务造成影响的环境因素，可以大致按表3分为4种类型：天气条件、路面条件、交通条件和车辆状况。一般天气条件中的关键环境因素为负面影响，对汽车的硬件造成功能阻碍，如雨雪或能见度降低的天气；路面条件即为影响汽车动力经济性、操稳性、平顺性等性能的路面因素，与汽车驾驶息息相关；交通条件主要影响自动驾驶相关软硬件，对其算法的运行效率有影响；车辆状况可能影响座舱内的环境舒适程度，以及与驾驶性能的参数相关。

表3 影响调度的关键环境因素分类及示例

2 SOA设计与建模

2.1 SOA服务层级建模

一组功能目标相近，且服务粒度大小相近的子服务可以构成一个服务层级。其中，硬件服务层级与硬件直接关联，提供最基础的功能，位于SOA 架构底层；而软件服务层级中的子服务一般为实现一类功能的算法或其他软件，不与硬件直接关联。为了实现一个系统功能，需要对SOA 架构发起相应的服务请求。

应用和算法层的一个功能往往需要多个存在上下调用关系的服务层级共同实现，在纵向上可以分类为不同的服务层级束。

为了体现这种横纵向服务层级关系，表现功能域拓展后的SOA 架构，文中给出了如图2 所示的问题模型：某汽车SOA架构中包含m个硬件服务层级，n个软件服务层级，其中硬件子服务由Lij表示，软件子服务由Mij表示。 其中，i为服务层级序号，j为每个服务层级中的子服务序号。

图2 功能域扩展的汽车SOA模型

在每个服务层级中，子服务都具有可选性，可启用其中若干个以满足系统的功能需求；同时，满足上下调用关系的不同服务层级中，也可能存在关联的子服务，即上层子服务需要固定启用下层的子服务，存在依赖性。

2.2 服务响应参数建模

2.2.1 硬件服务层级

定 义 2 维 向 量Lij∈R3，i= 1，2， …，m，j=1， 2， …，k来描述第i个硬件的参数：

式中：Cost为服务资源负载；S为服务能力。服务资源负载包括计算资源和能耗两个部分。

计算资源负载又可包括CPU、内存、存储容量、网络以及GPU 等关键元器件的资源消耗情况，根据计算资源负载的各组成部分及能耗在车辆上的影响程度大小，可以采用不同的影响系数，并添加或减少关键元器件的种类。例如，对于CPU、内存、网络和能耗4 种因素影响最大的车辆而言，服务资源负载可以用式（2）表示：

式中：P为实际消耗的资源数量，单位为相应资源的单位，MB、kJ 等；C为对应的资源系数，用于进行去单位化和设定每种资源的加权量，单位为MB-1、kJ-1等。

服务能力表示该服务硬件在当前环境下的运行效果，对于不同的硬件种类，选取最关键的几种评价指标。对于可调度SOA 硬件，最典型的即为环境感知传感器，其服务能力可用分辨率表示，单位为PPI（pixels per inch，PPI）。

2.2.2 软件服务层级

定 义 2 维 向 量Mij∈R3，i= 1，2， …，n，j=1，2， …，k来描述第i个传感器的参数：

式中：Te为服务预计完成时间。服务资源负载的计算与硬件服务层级相同，而服务预计完成时间可根据车机操作系统给出预估时间，用于评价同类功能软件服务在执行某个任务时的难易程度。

2.2.3 调度方案变量

对于一个服务层级Li或Mi，定义调度方案变量Xi∈Rk，维度与该层级子服务的数量相同；Xi第j个元素的值，Xi[j]= 0 or 1，代表服务层级自上而下总计第j个备选子服务是否启用，0 表示不被调用，1 表示被调用。例如，对于具有4 个子服务的M3服务层级，调度方案X3∈R4。对所有服务层级的调度方案进行总和，可得系统的整体调度方案。

2.2.4 约束条件

服务调度的约束条件较为宽泛，主要目的是避免极端情况下出现系统宕机，（C1～C6）以及保证系统能对需要调用的服务具有优先操控权，因此还需引入系统需求功能覆盖约束（C7）。

服务最大完成时间约束（C1）：

式中：n表示该层级具有的子服务数量；Tmax则为设定的最大服务完成时间。

系统服务资源约束（C2～C5）：

式中Costmax表示对应资源的设定最大值上限。

硬件服务能力下限约束（C6）：

式中Smin表示对应硬件服务能力的设定最小值下限。

系统需求功能覆盖约束（C7）：

式中Psyst表示系统功能需求开启的子服务集合，需要优先确保系统开启需求的子服务。

3 SOA调度算法

3.1 服务置信度

每个服务层级中，在当前环境条件下每个子服务的运行可靠性和响应效果的综合效果为服务置信度。在网格计算的服务调度机制中，通常会采用基于信任的QoS［11-12］和性能的QoS［13］，以分别提升服务提供者和接受者的可信程度，并进一步采用基于如启发式的方法实现机制，如经典的Min-Min 算法［14］。在网格计算中，性能QoS 包括最终服务期限等与时间相关的参数和精度等与准确性相关的参数，而信任QoS 是用来评价服务信息的真正可信程度。服务置信度结合了类似于网格计算中QoS 的信任和性能两个维度的理念，用于综合表征汽车SOA 上的服务运行效果。其中信任的理念体现在加入的运行稳定性的评价指标，数据越稳定，表明其服务失效的可能性相对而言更低，也就具备更高的可信度；性能的理念体现在服务参数中的负载、服务能力和预计完成时间，更优秀的指标也就表征了更强的性能。

服务置信度Conf由服务参数L和M估计得出。LiT和MiT为短时间段T内由每隔T/n时间采集的一系列服务参数Li和Mi构成的二维离散数列，为其标准差的模。

运行效果参数α1、α2，运行稳定性参数β1、β2，满足：

对于硬件服务层级：

对于软件服务层级：

3.2 基于服务置信度的子服务更新算法

该算法的目的是更新某个具体层级的服务调度方案，需要在整体算法中被多次复用。为了便于表述，后文将该算法称为算法1。该算法的具体流程如下，流程图如图3所示。

图3 算法1流程图

（1）输入需要更新子服务调度方案的服务层级，根据服务层级为硬件层级或软件层级，获取所有子服 务 的Cost、S或Cost、Te，得 到 所 有 子 服 务 的Li或Mi。

（2）考虑系统功能覆盖约束C7，选择系统功能需求开启的子服务集合Psyst中包含的子服务。由于约束条件C1～C6主要为了避免极端情况下的宕机，在这里认为系统提出需求的服务本身满足约束条件C1～C6。

（3）考虑最大完成时间约束条件C1，系统服务资源约束C2～C5，硬件服务能力下限约束C6，当其中的子服务不满足约束条件时，不选择这些子服务。

（4）其他没有被约束条件限制的子服务，计算所有的服务置信度Confi，构成集合{Conf}，其中步骤（2）中指定开启的系统需求子服务单独列出，构成的服务置信度集合为{Confsyst}，此时，{Conf}不包含{Confsyst}的元素。

（5）比较{Conf}中所有元素和{Confsyst}的平均将其从{Conf}去除。

（6）若{Conf}中仍有剩余元素，选择{Conf}中最大的元素对应的子服务，并加上步骤（2）中优先级更高的{Confsyst}构成输出的调度方案。

通过步骤（4）～步骤（6），能在满足系统功能需求的条件下，通过其他可能服务置信度更高的子服务进一步提升最终调度方案的平均服务置信度。

3.3 服务调度选择算法

该算法为整体算法，控制汽车整体的调度过程运行。为了减少计算资源的消耗，在某一服务层级的服务置信度下降不超过10%时，不对该服务的选择方案更新；同时，为了避免出现服务置信度稳步下滑，影响整体运行效率，系统每隔一个初始化周期后会进行重置，重新选择各服务层级的调度方案。后文将该算法称为算法2，具体流程如下所示，流程图如图4所示。

图4 算法2流程图

（1）对所有服务层级运行算法1，获得初始的子服务调度方案X。

（2）每隔时间δt，获取每个层级正运行的服务参数Li或Mi，计算服务置信度，并计算服务置信度相较Nδt内最大值的变化幅度p，其中N为记录当前检测点之前的时间间隔数目， 该服务层级的变化幅度p记为

（3）当p≤-10%时，对该服务层级重新运行算法1，更新子服务的选择，转步骤（2）。

（4）当p＞-10%时，不改变该服务层级的调度情况，转步骤（2）。

（5）每隔一个初始化周期Tinit后，转步骤（1）。

4 模拟实验设计

4.1 简化系统模型

为了更具体地展示服务调度机制的运行过程，以及验证服务调度的优势，文中设计了简化的软件和硬件双层模型，在参数模拟下进行服务调度过程的仿真，并设计几种典型的环境场景，将其与不进行服务调度的效果进行对比，验证其在能耗和服务能力上的优势。

如图5 所示，SOA 模型选为双层架构，每个服务层级分别由3 个子服务组成。汽车上布置3 组自动驾驶汽车常用的传感器类型：摄像头组、激光雷达组和超声波雷达组［15-16］。每个传感器组的布置方案都能覆盖车身周围的足够范围，使自动驾驶功能正常工作。3 种传感器类型不仅应用广泛，并且在不同环境中的工作特性差异明显，能够更典型地表现出应对不同环境的服务运行差异性；而常用的毫米波雷达的工作特性与激光雷达相似，故而仅选取了其中的一种。

图5 简化SOA双层模型

汽车SOA 除传感器服务层级外，拥有一层具有3 个子服务的上层算法层级，代表运动物体追踪（moving object tracking， MOT）层级，分别为：立体视觉MOT、传感器融合MOT、深度学习MOT［15］，同样，假定这3 种的软件层级在不同环境下工作特性同样差异较大，更为典型。

在简化模型中，设置运行效果参数α1= 0.8，α2= 0.9，运行稳定性参数β1= 0.2 ，β2= 0.1。由于信任QoS 的理念不是直接对应在运行稳定性一个因素上，因此根据性能QoS 理念的运行效果应该作为更加重要的因素；硬件层级的运行稳定性受环境影响和安装位置等影响更大，因此提高了硬件层级相较于软件层级的运行稳定性参数。

4.2 设计场景验证

4.2.1 高速路场景

Case1 设置为高速路场景。硬件传感服务层级L1、L2、L3分别为：摄像头组、激光雷达组、超声波雷达组。此场景只影响硬件传感服务层级。在高速路场景下，速度会对超声波雷达的感知能力产生不利影响［17］，因此设定归一化后的服务能力平均值=0.4；对于服务资源负载，以各传感器静止且工况条件最适宜时的负载作为标定。在传感器的运行工况变差时，更难获取传感数据，且运算模块进行处理时会消耗更多的资源，因此选取服务资源负载，如表4 所示。同时，运行工况变差时，服务能力和资源负载的数据浮动值会提高，由此如表4 可以设定标准差的数值。

由设定的参数计算当前场景下的Conf(Li)，并应用算法1 和算法2 进行排序。对于某些自动驾驶汽车而言，不需要处理激光雷达的数据就可以实现满足自动驾驶功能。此时，摄像头的服务置信度最高，考虑约束条件后可以得出调度方案变量为

对于其他自动驾驶车辆，需要进行传感器融合算法［17］，如补充激光雷达数据进行融合等才能获取足够感知数据，此时系统需求开启的服务集合Psyst=[0，1，0]。又因为摄像头的服务置信度大于激光雷达，根据算法1，摄像头服务也需要开启，考虑约束条件后调度方案变量为

则此时求解结果：同时启用摄像头组和激光雷达组。

4.2.2 交通参与者较多场景

软件服务层级M1、M2、M3在Case 2 中代表运动物体追踪（MOT）层级，分别为：立体视觉MOT、传感器融合MOT、深度学习MOT。此场景只影响软件算法服务层级。立体视觉算法相对来说计算资源消耗较低，但依赖于环境中存在足够的纹理和深度信息；传感器融合算法对计算资源要求较高，但适合跟踪各种类型的物体，包括没有明显纹理的物体；深度学习的方法便于处理复杂场景和多目标跟踪，但需要更多的训练数据和计算资源［18］。根据这些特征，对于服务响应时间，深度学习方法具有最高的效率，处理速度更快，用时应最短，其次是传感器融合和立体视觉方法。对于服务资源负载，标定值1 时取为适中处理数据下的负载情况，在环境场景变化时，既需要考虑各子服务本身的负载变化幅度，也需要考虑不同子服务间本身的负载差距，可以按一定的参数选取。由于立体视觉方法计算复杂度最小，其次为传感器融合方法和深度学习方法。三者的数据波动性一般都不大，传感器融合分析数据量较大，相对而言稳定性稍高。由以上分析，进行归一化后得到表5的设定数据。

表5 拥堵道路场景软件层级服务置信度

计算当前场景下的Conf(Mi)，可得此场景下深度学习的服务置信度最高，为0.61，并应用算法1和算法2，考虑约束条件后得出该软件服务层级的服务方案变量：

则此时求解结果：启用深度学习MOT。需要注意的是，不同复杂程度的交通参与者复杂程度、不同的算法在响应时可能有不同的调度结果。

4.2.3 隧道低光照场景

此场景同时影响软件算法服务层级和硬件传感服务层级。低光下摄像头组的传感能力受到影响，一并影响立体视觉MOT 的运行效果；同时隧道无行人和非机动车，交通参与者复杂性和数量相比适中处理数据的标定场景降低。可以设定摄像头和立体视觉MOT 的各项参数受到影响，传感器融合由于也具有摄像头数据，也受到较小的影响。对于超声波雷达，隧道中行车速度较低，但距离其最适宜的低速行驶工况仍有部分降低；深度学习方法受到的影响较小，且其负载更高，但受环境影响的变化幅度较低。综合以上分析，进行归一化后可以得到表6 和表7的设定数据。

表6 隧道低光照场景硬件层级服务置信度

表7 隧道低光照场景软件层级服务置信度

计算当前场景下的Conf(Mi)和Conf(Li) ，并应用算法1 和算法2，可得两个层级中，分别为激光雷达和传感器融合子服务的服务置信度最高，考虑约束条件后，可得出该双层服务层级的服务变量方案为

则此时求解结果：在硬件服务层级启用激光雷达，在软件服务层级启用传感器融合MOT。

4.3 调度优势分析

不进行服务调度时，在本文的简化双层SOA 服务层级中，硬件服务层级的全部子服务开启，在所有场景中都始终采集数据进行处理；软件服务层级在所有场景下只选择一种固定的子服务运行。而进行服务调度时，按照上面设计的3 种服务场景通过系统进行多次场景服务的切换，进行服务能耗的对比分析，并同时比对整体服务能力的变化，进而可以分析服务调度的优势。开启更多的子服务会产生更多的能耗，而整体的服务能力可以近似认为和服务能力最高的子服务相近。在场景的环境没有影响到该服务层级时，负载设置为1。

由于实际场景的数据采集和定量难度较大，在本文的初步研究中将采用虚拟的随机数组作为服务参数指标中的负载、服务能力及服务预计完成时间数据输入。为了在简化条件下更好地模拟实际驾驶场景中数据的自然波动，这些服务参数的随机数组服 从 正 态 分 布X～N(μ，σ2)，式 中，μ= 1，σ=即本节中设定的各场景下标准差，见表4～表7。

自动驾驶汽车运行时，由于不断计算消耗的能源相比传统汽车而言更不可忽视。因此，采用考虑了系统计算资源消耗等计算机负载的服务资源负载Cost来表示汽车整体能耗情况是可行的。

如图6 设置一组场景循环，每隔一个时间间隔切换一组场景。时间间隔为单位时间的虚拟量，表示一次更换场景的单位时间，包含一组正态分布随机数组的所有数据。随后，将上述生成的各场景下正态分布随机数组经过调度与否的叠加计算后，按场景的轮换，在MATLAB 中绘制为图7～图9，分别展示调度与否的能耗、软件层级服务预计完成时间和硬件层级服务能力3个维度的模拟情况对比。

图6 调度场景对比设置

图7 调度与否的能耗对比分析

由图7 可见，进行服务调度的组别在能耗负载上明显更低。通过计算，在模拟场景下，进行调度与不调度的能耗平均比值为64.33%，在本文所列场景循环中可能降低能耗3至4成。

根据图8，对于软件层级的预计服务时间，在某些场景下，如Case2 中，由于软件服务层级中不同子服务性能差距较大，进行调度能够显著降低服务预期完成时间。整体而言，进行调度也能维持小于等于不进行调度的Te。对于本文的场景循环，Te的平均比值约为70.19%，进行服务调度可降低3 成左右的服务预计完成时间。

图8 调度与否的预计服务时间对比分析

对于硬件层级的服务能力，由图9 可得，进行服务调度的平均服务能力与不进行调度的比值约96.61%，与不进行调度的子服务全部开启情况相近。这说明服务调度在该场景循环下可以保持绝大部分的服务能力，维持性能。

图9 调度与否的服务能力对比分析

综合以上分析可以得出，开启服务调度后，能在一定的环境场景下显著降低由于计算资源等消耗产生的能耗，一定程度上降低软件服务的预计完成时间，并能和不进行调度的服务能力表现相近。

5 结论

在通用SOA 架构的基础上，本文归类并分析了可被调度的SOA 服务层级，以及会影响服务调度的环境因素。在此基础上，提出了面向智能汽车功能域可拓展的SOA 架构，可以适配更广泛的SOA 服务层级，便于跨域服务调度。基于此，本文设计了一个相对完整的SOA 服务调度机制，以服务置信度为调度核心，实现子服务调度方案的最优选择。综合考虑服务能力、负载和数据稳定性等因素，通过测定服务响应参数计算获得服务置信度，并通过基于服务置信度的子服务更新算法和服务调度选择算法实现服务调度流程，提高智能汽车应对环境变化的自适应能力。

在简化的SOA 双层模型中，本文设计了3 种典型场景以演示服务调度的过程，模拟实验结果表明：所提方法显著降低了计算资源负载等原因引起的服务能耗与预计服务时间，分别为36%和30%；且该方法能保持服务能力与不调度的情况相近，为原有的96.61%。由此可见，调度算法能够在维持服务能力的同时，降低汽车在环境场景切换时的能耗，在一定程度上提升自适应性。

为了使数据的设定更符合实际情况，未来还需要在实车上进行数据测定和验证，以对调度算法进行优化和改进。同时，还可以采用更先进的数据通信方式，来将汽车动力系统容纳到可被调度的SOA服务层级中，以更大程度地拓展SOA的优势。