摘要
现代交通面临着日益严峻的挑战，例如无碳交通需求以及对灵活交通解决方案的迫切需求。U-Shift II项目通过模块化电动汽车架构、驱动单元（驱动板，Driveboard）和车身（舱体，Capsule）的设计来应对这些问题。这种分离式设计使其在不同使用场景中具备高度灵活性。当前的架构范式（如 AUTOSAR）在成本和开发速度方面存在局限性。为解决这些问题，本文提出一种混合软件架构，将面向信号的架构（如 CAN 总线）与面向服务的架构相融合，以提升灵活性。该混合架构的核心组件是动态链接系统（Dynamic Link System），其通过在运行时将舱体专用组件动态集成到驱动板软件栈中，实现两种架构的衔接。研究人员基于集成到驱动板原型中的硬件装置，对所开发系统的性能及功能进行了评估，包括动态链接系统的延迟测量和功能测试。此外，基于云的重构流程通过支持空中软件更新和资源分配，进一步增强了驱动板的通用性。结果表明，这种混合可重构电气 / 电子（E/E）架构具有良好的应用前景，有望推动向未来电动自动驾驶汽车所需的纯面向服务架构平稳过渡。
1. 引言
在快速城市化与技术创新并行的时代，全球交通格局正经历深刻变革。共享经济、电动化和自动驾驶汽车的兴起这三大关键趋势，正在重塑城市交通，从根本上改变人与货物在城市内部及城市间的流动方式。随着城市中心面临拥堵、环境可持续性和公平可达性等多重挑战，传统的个人车辆拥有模式和常规公共交通模式遭遇严峻考验。在此背景下，共享模块化交通概念应运而生，成为一种可行且具创新性的解决方案，为满足现代社会的动态需求提供了灵活自适应的框架。共享交通模式与先进电气 / 电子（E/E）架构的相互作用，将车辆重新定义为智能互联系统，而非单纯的交通工具。通过优先采用基于信号的通信方式，车辆能够与其组件实现无缝交互，并动态响应周边环境，构建安全、高效且敏捷的交通网络。此外，基于服务的软件集成进一步提升了模块化程度，使车辆能够根据当前配置提供定制化功能。
随着这一趋势的推进，主流汽车制造商正积极调整以满足模块化和可扩展性需求。例如，戴姆勒（Daimler）宣布计划批量生产模块化、可扩展的 "货车电动架构"，该架构在制造过程中将车辆分解为三个可互换单元；起亚（Kia）也于 2024 年国际消费电子展（CES 2024）上推出 "超越车辆平台"（Platform Beyond Vehicle），采用了类似的设计思路。这些创新使得具备可互换组件的模块化车辆成为可能，进而支持多样化的硬件配置。然而，传统软件架构通常为固定硬件设置设计，在适应模块化组件带来的变异性方面面临巨大挑战。面向信号的软件架构本质上难以高效适配模块化车辆的动态需求，尤其是当不同配置需要独特的软件适配时。
面向服务架构（Service-Oriented Architecture, SOA）为解决这些挑战提供了可行路径。通过将软件功能与特定硬件配置解耦，SOA 能够在管理模块化、可扩展车辆架构的复杂性方面实现更高的灵活性、可扩展性和适应性，为更高效、更具创新性的汽车解决方案奠定基础。SOA 方法已在消费级网络和云服务领域得到充分验证，通常基于超文本传输协议（HTTP）的应用程序接口（API）进行信息交换。但由于消费级云应用与汽车应用存在本质差异，HTTP 无法在汽车行业中直接应用。为此，当前的标准架构解决方案（如 AUTOSAR Adaptive）已开始聚焦于汽车领域的基于服务架构，并采用基于 IP 的可扩展面向服务中间件（SOME/IP）。
通过网关电子控制单元（ECU）与 AUTOSAR Classic 结合，已能够实现总线系统与 SOA 的融合。然而，该系统仍存在两个主要缺陷：首先，受经济因素驱动，供应商使用 AUTOSAR 基础软件栈的年费高达 10,000 欧元以上，具体金额取决于公司规模和产量；其次，AUTOSAR 的文档亟待完善。因此，机器人操作系统 2（ROS2）等框架有望成为 AUTOSAR 等当前主流软件架构解决方案的替代方案，目前已有相关研究致力于开发适用于汽车领域的 ROS2 版本。此外，互联技术已在汽车行业迅速兴起。大多数现代车辆均具备云连接功能，部分车辆（如大众 ID.3）通过车辆对车辆（V2V）通信，利用欧洲电信标准协会（ETSI）定义的协同感知消息（CAM）和分布式环境通知消息（DENM），提升整体环境感知能力。在原有研究基础上，本文修订并扩展了第 3 节，新增第 3.2 节对云重构流程进行详细描述，同时在第 5 节补充了相关评估内容以适配新增章节。
1.1 问题
U-Shift II 平台是针对模块化电动自动驾驶汽车设计的解决方案，旨在应对现代交通挑战，其车辆概念与首个 U-Shift 项目一脉相承（见图 1）。在 U-Shift II 项目中，需开发一款道路模块化车辆，该车辆需无缝整合多种功能和依赖关系，并配备当前的舱体拓扑结构。这种灵活性使得设计适用的电气 / 电子（E/E）架构成为一项重大挑战。除供电需求外，舱体还可能配备驱动板在现有系统配置中未预设的传感器和执行器组，这就要求驱动板能够兼容这些组件。考虑到这一点，模块化车辆的典型汽车 E/E 架构很快会达到其性能上限，进而影响其在整体交通领域的潜在价值（优势）。
图 1、U-Shift 车辆概念。（a）驱动板与舱体分离状态 （b）驱动板与舱体连接状态
1.2 目标
向原生汽车级面向服务架构（SOA）的转型需要从混合软件架构入手。混合软件架构作为一种新兴系统，能够弥合当前技术标准与未来软件定义汽车之间的鸿沟 ------ 它既充分利用了 SOA 系统带来的灵活性和快速开发周期，又能在设定的时间约束内以安全可靠、经济高效的方式实现信息分发。U-Shift 项目实现了完全自动驾驶功能与基于不同舱体的高度模块化的结合，为实施和评估混合模块化软件架构提供了独特的验证平台。
1.3 贡献
本文详细阐述了为自动化模块化车辆开发的 E/E 架构，该架构通过 U-Shift II 项目中的驱动板原型开发与构建得以实现。在该原型中，本文提出的融合面向服务和面向信号架构的混合软件架构概念已完成实施与测试。通过动态软件耦合机制（即动态链接），面向信号和面向服务的架构能够实现舱体拓扑结构及其使用场景的无缝切换，这对整体 E/E 架构提出了新的要求。借助 5G 互联技术，驱动板能够利用云计算能力和空中更新（over-the-air updates）功能，提升整体性能、可靠性以及对新型舱体技术的适应性。第 5 节通过测试验证了所提出的动态链接概念的可行性，并提供了性能基准数据，以评估基于云的重构机制的必要性和适用性。
2. 相关研究现状
汽车行业正经历从传统面向信号架构向更灵活的面向服务架构的重大转型。面向信号的架构历来是汽车 E/E 系统的核心，其依赖于预定义的通信协议（如控制器局域网（CAN））。这种方法在模块化车辆中存在局限性，尤其是在可扩展性和灵活性方面，因为它需要静态配置，这会减缓新功能的快速开发和适配。近期研究围绕汽车系统中 SOA 实施的多个方面展开，重点包括资源分配、网络架构、时序可预测性和通信协议。
文献提出了一种基于优化的 SOA 资源分配方法，该方法利用数学优化对服务参数进行调度，同时考虑数据流与服务内计算之间的依赖关系，研究聚焦于车辆 ECU 内部及跨多个服务和 ECU 的本地资源优化。文献通过仿真环境研究了软件定义网络（SDNs）与面向服务架构的融合，旨在支持车辆中的动态网络配置，验证了利用 SOME/IP 协议通过 SDN 实现动态面向服务网络架构的可行性。此外，文献对 SOME/IP 中的发现阶段进行了形式化时序分析，强调了 SOA 发现阶段在确定车辆子系统就绪状态中的重要性，因为该阶段的完成时间是影响整体系统性能的关键参数。文献通过案例研究探讨了基于 SOME/IP 和可编程数据平面的 SOA 分布式反馈控制回路汽车应用的实施，验证了将 SOME/IP 感知融入汽车 SOA 应用和网络设备的潜在优势。同时，研究人员也在持续努力提升 SOA 实施的性能和平台独立性。文献提出的 Bitroute SOME/IP 是 SOME/IP 通信协议的一种新实现，侧重于执行性能和部署平台独立性，满足了现代汽车系统对可扩展、高效通信中间件的需求。这些汽车领域 SOA 应用的进展，标志着车辆软件架构在灵活性、可扩展性和效率方面取得了显著进步。
UNICARagil 研究项目与 U-Shift 项目类似，基于可扩展驱动平台和多种使用单元，但与 U-Shift 不同的是，该项目的作者为其自动驾驶车辆解决方案采用了原生 SOA 方法。正如文献所指出的，目前结合以太网、CAN 和 FlexRay 的混合面向信号与面向服务架构在实际应用中更为可行。文献首次通过实际案例研究展示了混合面向服务架构的相关成果；文献则在基于信号的传统 CAN 和 ECU 驱动的 AUTOSAR Classic 与通过以太网构建 SOA 的 Adaptive 平台的背景下，探讨了混合软件架构的应用。相关研究现状表明，为充分发挥模块化自动驾驶电动汽车所需的纯 SOA 优势，基于当前面向信号的行业现状，通过混合架构实现可控过渡是一种合适的中间解决方案。在汽车应用的 SOA 与云技术交叉领域，系统正朝着更动态、灵活和互联的方向发展。文献提出了一种编排器（Orchestrator），用于将汽车 E/E 架构动态扩展至云端，为非安全关键功能提供空中控制（COTA）能力。这种方法与边缘和云环境中的服务编排趋势相一致，例如工业车辆目标检测研究所展示的应用。文献提出了一种多层 SOA，该架构为异构计算硬件提供抽象，并促进云计算和大数据分析与高级自动驾驶技术的融合。为确保云计算中的高可用性并提升服务质量（QoS），文献提出了多种复制策略，并将其分为面向数据和面向服务的方法。此外，文献展示了车辆更新管理系统，该系统将车内通信网络与车外服务（包括云车辆服务）相连。
云计算技术在汽车领域的应用正逐步扩展至汽车软件架构的在线重构。通过云计算扩展车载计算和存储能力催生了云基车辆功能的概念 ------ 利用云能力增强车辆控制策略，并实现仅依靠车载资源难以达成的新功能。文献强调了车辆云连接的潜力，能够在云端运行计算密集型机器学习模型，例如降低城市公交车空调系统的能源消耗。借助云的可扩展性和计算能力，可采用专家混合（mixture-of-experts）方法，通过门控机制（gating mechanism）基于特定上下文数据动态选择专用模型，以优化车辆功能并适应不同场景。文献提出了一种用于汽车系统中以太网 TSN（时间敏感网络）的重构协议，该协议通过云实现动态空中网络操作，具备流量隔离、失效恢复和性能调整等功能，通过重构提升安全性和用户体验。此外，文献提出了一种成本感知的多维度重构方法，用于动态路由应用，利用基础设施即代码（infrastructure-as-code）模块实现高效资源分配和闲置组件的重新调度。最后，文献提出了一种智能云管理系统，该系统利用知识库对云资源进行建模、管理服务级别协议（SLA），并通过 RESTful 服务优化资源分配。
3. 混合E/E架构概念
3.1 动态链接系统架构
针对驱动板的应用场景，动态链接系统架构成为应对舱体技术不断发展所带来挑战的可行解决方案。由于 CAN 总线等基于信号的系统本质上具有静态特性，需要一个定义明确的信息流接口来衔接混合软件架构中的面向服务和面向信号组件。此外，面向信号的 ECU 更新频率较低，通常在车间大修期间进行。为确保驱动板的通用性，通用动态链接系统消息至关重要。动态链接系统（DLS）消息包含两个核心部分：通用信息字段（UIF）和对应的规则标识符（RID）。UIF 作为唯一标识符，规定了如何解析 DLS 消息中的数据；RID 本质上是编排器（Orchestrator）动态链接 X 服务的接口定义，为驱动板和舱体之间建立标准化通信协议。这种设计确保了向后兼容性和向前兼容性，即驱动板能够理解采用不同技术和功能的舱体发送的消息。基于 RID 的设计使 DLS 架构能够支持模块化和可扩展的交互：当开发出新的舱体功能时，可以引入相应的 RID 对这些新功能进行定义，而无需修改区域控制器 ECU 的软件。这种模块化特性确保驱动板保持通用性，能够支持多种舱体，而无需进行根本性的重新设计或软件更新。
DLS 消息中的 UIF 用作传输各类数据的容器，包括传感器读数、控制指令和状态更新。舱体服务通过 DLS 消息与驱动板的面向信号组件（如 CAN 总线和其他通信总线）进行交互。UIF 中封装的信息经过转换和双向路由，实现驱动板与舱体之间高效、标准化的通信。该架构为不同舱体技术之间的无缝交互提供了稳健且具适应性的平台。DLS 的一个关键特性是舱体在运行时的动态集成，因此需要即插即用（Plug-and-Play）兼容性以支持舱体的连接和断开流程。图 2 展示了完整的 DLS 架构。如图左侧所示，多个舱体中的一个（舱体 X）通过 DLS 与驱动板连接，首先向驱动板编排器共享其舱体类型（见图 3）。随后，编排器与舱体服务后端（Capsule Service Backend）通信，下载对应的动态链接 X 服务，并将其集成到已运行的 SOA 中。当新的舱体与驱动板连接时，会通过其舱体类型进行自我声明；经过握手流程后，驱动板首先下载新服务并启动舱体专用的动态链接 X 服务。一旦该动态链接 X 准备就绪，会发送声明消息；在收到舱体 X 的最终确认标志后，动态链接 X 服务开始运行。该动态链接 X 可支持多种应用场景：例如，根据舱体类型，舱体可能配备自身的电池存储系统，该系统既可以为驱动板的电池存储提供支持，也可以反过来平衡两者的荷电状态（SoC）。
通过交换以特定 RID 编码的 SoC 信息，驱动板能够动态调整功率分配，平衡舱体和驱动板之间的 SoC，确保能源资源的优化利用、延长续航里程，并防止电池深度放电，进而延长电池寿命。另一个应用场景是基于舱体重量的电机控制器调整：通过舱体内的传感器将重量信息传输至驱动板，DLS 能够根据舱体重量自适应调整电机控制器参数。例如，对于承载可变负载的舱体，电机控制器可以动态调整扭矩输出或再生制动设置，以根据当前负载优化性能和效率。从安全角度考虑，DLS 能够实现舱体和驱动板安全关键元件的耦合（例如，人员运输舱体的门锁与驱动板的电机使能信号）。其他应用还包括同步舱体和驱动板的同类执行器（如灯光控制），实现整体系统的实时监控等。为确保 CAN 总线在保持 SOA 灵活性的同时实现消息的及时传输，系统会保留两个域之间最近一次成功的传输数据。
图 2、基于文献的动态链接系统架构
图 3、新 DLS X 软件组件（SWC）的启动流程及舱体与驱动板之间的示例性交互
3.2 云赋能软件重构
在云端运行软件组件（SWC）具有多项优势。云集成的核心优势在于能够在 SWC 中动态融入实时数据和外部信息，例如当前天气数据或交通预测，这些数据可被实时处理并适配单个车辆的个性化需求。此外，云能够支持构建综合车队数据库，集中存储和汇总车队中所有车辆的信息。云外包的另一个优势是突破车辆硬件的资源限制：云系统提供近乎无限的计算和存储能力，使得计算密集型和数据密集型应用能够在不占用车载系统资源的情况下运行。最后，云架构确保外包功能和数据的全球可用性 ------ 无论车辆位于何处，相关信息都可以被提供、更新和使用，这对于全球运营的车队尤为有利。在云端运行 SWC 之前，必须首先评估其卸载可行性（见图 4）。
文献已开展相关前期研究，其成果可纳入该评估流程。评估过程分为两个步骤：第一步基于实时性要求或汽车安全完整性等级（ASIL）等标准，确定功能的运行相关性；如果某功能被判定为非运行相关，则进一步评估其云卸载适用性。这种适用性由定量和定性标准共同决定：定量标准包括硬件计算层面的潜在节能效果，以及由于云端处理速度更快而可能实现的响应时间缩短；定性评估则关注外包功能的潜在附加值（如车队学习的收益），并将其纳入评估流程。评估流程最终会为每个功能分配一个标准化的适用性评分（范围在 0 至 1 之间），评分越高表明该功能越适合云卸载。在云端运行 SWC 的主要优势在于，不仅可以为某一功能提供一个通用模型，还可以提供多个专家模型（expert model）。专家模型是一种专用机器学习模型，基于特定上下文或数据集训练而成，因此在其应用领域具有极高的性能。然而，仍需要一个通用基础模型作为备用方案，以应对没有合适专家模型可用的情况。使用通用基础模型作为备用方案至关重要，确保即使在没有合适或可用的专家模型时，系统仍能正常运行。该基础模型可作为一种通用解决方案，在广泛的上下文范围内提供可接受的结果，但相较于专用专家模型，其性能可能较低。专家模型与基础模型的结合使系统兼具灵活性和效率，能够动态适应各种需求和数据上下文。
图4、使用门控机制和选择专家网络的上下文对云中的软件组件进行重新配置
以一个覆盖所有可能上下文领域的通用机器学习模型为起点，同时需要多个专家模型，每个专家模型针对特定上下文进行训练。这些专家模型应具有明确的应用场景，并可根据上下文进行调整。此外，这些专家模型可以在系统运行过程中逐步学习和整合：随着新上下文的出现或现有上下文的演变，系统可以通过训练和集成新的专用模型不断完善其专业能力。这种动态方法使系统能够随着时间的推移持续提升性能。当向云端发送请求时，需要通过门控机制（见图 4）选择合适的专家模型。门控机制可以是简单的查找表，也可以是可训练的机制（如神经网络或决策树）。基于输入数据，系统会决定哪个专家模型与当前任务相关；如果没有合适或可用的专家模型，则选择通用模型或覆盖范围最广的模型。根据所选专家模型，软件会进行相应重构并在云端运行（见图 4）。重构过程包括动态加载所需模型、调整处理流程，并确保与输入数据格式的兼容性；随后通过分配必要的计算资源编排软件执行，最终将结果通过通信通道反馈给车辆。
4. 原型搭建
可持续交通的目标可以通过模块化电动汽车架构实现 ------ 使用数量更少但日均使用时间更长的车辆完成必要的出行任务。为实现最高程度的模块化，U-Shift II 车辆概念打破了传统结构，将车辆分为驱动单元（驱动板）和车身（舱体）（见图 1a、b），图中展示了一个驱动板原型与前序项目中的人员运输舱体。驱动板集成了全自动电动汽车运行所需的所有组件，包括电驱动系统、电池系统、控制单元和环境传感器。自动驾驶功能通过舒曼等人（Schumann et al.）提出的新型混合 A* 路径规划算法实现，该算法融合了驱动板的独特驾驶特性。车辆的具体应用场景由所选舱体决定：根据舱体类型的不同，车辆可支持乘客运输、食品配送、自行车回收或货物物流等多种用途。底盘中嵌入的升降机构使车辆能够在无需外部协助的情况下自主拾取和对接舱体。
驱动板的核心设计要求是能够适配不同舱体的多样化架构，以应对现代交通的挑战。这种适应性确保其能够兼容舱体技术的持续进步和动态发展。由于驱动板生产后可能会出现新的舱体设计、功能和配置，因此必须具备适应这些变化的能力，以在各种车辆应用中保持有效性和通用性。这种适应性对于驱动板在快速发展的技术环境中保持相关性至关重要。图 5 展示了 U-Shift II 系统中用于动态链接的硬件搭建。该搭建分为两个主要部分：第一部分位于驱动板前部，包含支持面向服务和面向信号架构集成的组件（以蓝色突出显示），还包括与驱动板关键组件（如编排器）对接的舱体耦合机制。编排器负责管理通信并运行面向服务架构；dSpace 微自动箱（MAB）用作区域控制器，作为具备实时能力的快速原型系统，负责管理驱动板上大多数传感器和执行器的控制与通信。该系统通过面向信号的方式进行通信，利用多种 CAN 总线组件满足硬实时要求。
图5、U-Shift II原型硬件设置
搭建MAB 和编排器运行的软件组件旨在促进面向信号和面向服务架构之间的动态集成。为满足驱动板的实时性能要求，并确保安全关键功能在指定时间约束内执行，MAB 以 1 kHz 的时钟频率运行，该配置确保所有控制驱动板的关键任务都能可靠执行。MAB 与网络中其他控制单元之间通过以太网接口使用 UDP 协议建立通信，这种方式实现了面向服务架构元素与驱动板面向信号框架的无缝集成。
交换机用作编排器、MAB 和可能连接的舱体之间的物理接口。正常运行时，MAB、编排器和舱体之间通过高精度精密时间协议（PTP）主时钟实现时间同步。硬件搭建的第二部分以绿色标识，代表舱体及其与驱动板之间的耦合机制，提供机械、电力和网络耦合，确保 U-Shift II 的完全模块化。舱体内至少包含一个小型 ECU，作为编排器与舱体之间的接口。作为云服务提供商，我们利用内部服务器基础设施为 U-Shift II 创建专用虚拟机（VM），作为舱体服务后端（CSB）。该 VM 支持垂直和水平扩展，以满足驱动板更新部署和其他 SWC 执行的需求。驱动板在需要时通过基于高级加密标准（AES）的 IPSec 安全 VPN 连接与 CSB 建立通信，确保驱动板与 CSB 之间通信的真实性和安全性。
5. 测试与评估
实验中，基于上述两个场景对 DLS 架构的实现进行了评估：首先是共享所连接舱体的重量信息，该信息可用于优化 MAB 内的控制参数；其次，为测量从动态链接 X 服务到面向信号 CAN 总线的信号同步传输延迟，对驱动板的灯光执行器（CAN 总线系统的组件）进行控制。在包含延迟信息的测试中，首先通过 PTP 直接同步编排器 PC 和 MAB，其中 MAB 作为主时钟。通过约 9000 个测试点对 PTP 同步性能进行观测（见图 6），结果显示 MAB 与编排器的中位时间偏差为 56 µs，最大异常值峰值为 246 µs。因此，在测试的硬件搭建中，同步的最坏情况可近似为 250 µs。
图 6 所示结果反映了 U-Shift II 验证平台所用特定硬件搭建的性能，但相关原理和性能可扩展至该解决方案。从编排器到 MAB 的平均传输时间为 1.23 ms，低于 2.5 ms（可视为车辆中两个控制单元之间的最坏情况传输时间）。这意味着即使是前文提到的电池关闭或紧急制动等安全关键功能，也有望通过动态链接接口进行控制（尽管本研究未明确涉及这些功能）。传输时间的方向性差异源于 MAB 的固定时钟 ------ 为保持实时能力，该时钟频率被严格设定，且由于其他任务的计算时间需求，无法进一步降低。为在 CAN 总线上进一步处理和发送相应消息，消息到达 CAN 总线并激活灯光平均需要额外 1.25 ms。当重量信息成功从编排器传输至 MAB 后，MAB 会根据重量设置各种模型变量（如轨迹跟踪控制参数）。
图6、MAB和编排器的PTP同步
结果图7展示了 MAB 和编排器执行的消息帧序列及相应信息提取过程。上方测试图显示了未分离的原始 UIF 消息帧（为清晰起见已进行颜色标注），注意图中包含两个坐标轴（否则刻度差异过大）；第二个测试图为对应的 RID（正确解析信息所需的关键）。接收 DLS 消息的 MAB 可将 RID 用作上下文标记，以确定如何解析 UIF 中包含的信息。这种上下文解析确保每个组件根据其特定需求和功能处理数据，该过程可在下方两个测试图中看到（信息被分离并相应处理）：当 RID 值为 11 时，驱动板共享 CAN 总线的左转向灯同步信息至编排器（进而传输至舱体的动态链接 X 服务）；而当 RID 等于 10 时，舱体共享其当前重量信息，该重量信息可用于进一步调整控制器参数以提升性能。
图 7、接收的原始UIF消息及基于RID的分离信息
图8展示了 CPU 利用率与消息频率随时间变化的关系。测试中通过基准测试（benchmark）以更好地理解高 CPU 负载的影响：红线标记基准测试开始，CPU 负载从约 5% 的基础负载在 30 s 内线性上升至 100%。随着利用率的提升，服务频率从远高于 90 Hz 骤降至 40 Hz，且在 CPU 利用率恢复至基础负载前，服务频率始终远低于 100 Hz 的目标频率。服务频率的下降和上升均发生在 CPU 利用率约为 60% 时，这表明 CPU 利用率与服务频率之间存在明显相关性 ------ 更精确地说，两者的相关系数为 -0.39，提示存在中等程度的负相关。因此，运行过程中应避免高 CPU 负载。如图 8 所示，额外软件组件（如舱体专用 SWC）不断增长的计算需求可能会对传感器数据处理性能产生负面影响，进而可能影响自动驾驶功能的有效性，最坏情况下可能导致这些功能无法正常执行。为避免这种情况，应尽可能将资源密集型非安全关键任务卸载至云端；通过仅重新分配非时间关键型 SWC，可有效缓解这一限制。
图 8、CPU利用率对SWC频率的影响
6. 结论
总之，新型 DLS 架构在解决模块化道路车辆概念开发中的关键挑战方面展现出巨大潜力。通过实现不同舱体和驱动板组件之间的无缝通信、适应性和集成，DLS 支持多种高级功能（包括安全关键特性），例如将电机控制与舱体安全机制耦合，或动态平衡驱动板与舱体（如配备）电池存储之间的荷电状态（SoC）。研究团队与合作伙伴共同开发了全尺寸驱动板原型，该原型采用了所提出的混合 E/E 架构。初步测试证实，DLS 实现了面向信号架构与 SOA 之间的低延迟连接。测试涵盖多种双向消息，结果令人鼓舞 ------ 特别是动态链接消息满足了硬实时要求。DLS 具备适应新舱体技术的灵活性，即使在驱动板已投入使用后仍可适配。通过编排器和 MAB，可利用所提出的 RID（定义通用信息字段）动态调整交互。此外，云赋能软件重构支持将 SWC 卸载至云端，带来增强计算能力、实时数据处理和全球可用性等优势。这种重构过程通过专家模型和门控机制实现，能够为特定上下文动态选择最合适的模型，优化性能和资源利用。
在混合软件架构的背景下，本研究聚焦于面向信号架构中的单一总线协议，这与本研究的原型驱动特性相一致。尽管原型基于单一总线协议构建，但所用方法仍具有灵活性，为未来研究探索其他协议在汽车应用中的更广泛可行性奠定了基础。为将基于云的重构方法推广至其他 E/E 架构，需开展单独研究以确定系统能力 ------ 因为不同的总线协议、物理传输层和处理单元可能导致不同的行为（例如延迟特性）。未来研究需要解决连接故障、安全挑战、新舱体拓扑结构集成以及不同 E/E 架构的比较等问题。为提高对连接故障的鲁棒性，当前系统会保留面向服务和面向信号架构之间最近一次成功的传输数据；可通过增加内部冗余或传输错误时的备用功能进一步增强所提出系统的可靠性。在网络安全方面，尽管基于 AES 加密的 IPSec 提供了坚实基础，但仍可通过添加网络攻击检测和缓解措施进一步提升安全运行水平。
此外，需要通过不同舱体拓扑结构对系统进行评估，以验证 DLS 的可行性和可扩展性。为此，研究团队正在积极收集大量数据，为进一步分析和与替代技术的直接比较提供支持。关于不同 E/E 架构的比较，未来研究将重点考察多个 CAN 域和其他车载网络与 DLS 架构的交互方式。同时，研究团队正积极收集原型数据以评估系统性能，并将探索舱体中安全关键通信的集成策略。