AUTOSAR多核资源分配优化

摘要在桌面计算兴起数年后，汽车行业正面临着向多核架构的软件转型挑战。这一转变要求软件进行重大变革，以充分发挥新型先进芯片技术的优势，即采用同构或异构多核系统的微控制器（MCU）和片上系统（SoC）。越来越多汽车开发者面临此类系统的配置与优化问题，需依赖经验丰富的合作伙伴的最佳实践。ETAS早在2009年就率先开发出全球首个用于量产车辆的多核AUTOSAR软件栈，并基于多年单核系统ECU性能优化经验持续迭代。截至目前，全球超过40亿个ECU依赖ETAS RTA-CAR（RTA-Classic AUTOSAR）运行应用软件，且多核应用呈增长趋势。本白皮书简要介绍多核技术普及的动因与历程，随后通过三个真实案例（包含现有系统优化与新建多核系统两类典型场景）阐述ETAS如何助力客户优化核间分配，并附理论示例。文末展望了将进一步增强多核应用的新功能。 superior 目录1.引言2.并行化面临的挑战3.深度嵌入式系统的特殊需求4.实践方案4.1负载分布优化4.2 减少运行时峰值4.3BSW模块分布的主/从与多主架构方案4.4 创新型多核项目的从零搭建5.展望6.我们的AUTOSAR多核解决方案：RTA-CAR 4566789121314 1.引言数十年来，硬件速度的提升直接带来了软件性能的增长，而无需大量适配工作。然而在2010年代初，开发者们遭遇了"功耗墙"——由于电流密度和功耗上升导致性能提升受限的临界点。2004年，英特尔通过推出首款面向台式机的多核芯片为此提供了解决方案¹。尽管当时多数软件仍为单线程，这项新技术仍在全行业快速普及。但要从多核设计中获益需要大幅重构软件，因此其实际应用速度未能与多核硬件的推出保持同步。随着功耗墙问题稍晚波及汽车行业，单核ECU的性能增长同样陷入停滞。转向多核架构成为必然选择，尤其是当更集中的整车架构需要在更少ECU中集成更多功能——从而降低单车硬件总成本。2010年代首批汽车多核微控制器面世时，开发者面临将历史遗留ECU软件迁移至多核环境的挑战。ETAS通过其基础软件（BSW）栈推出了首个支持多核进程并行化的AUTOSAR解决方案，使得在保留关键传统系统的同时，能充分发挥新硬件的优势。 AUTOSAR多核资源分配优化 -同步和通信开销：程序的某些部分可能需要来自另一个核心的数据，或者需要进行同步，从而导致处理器等待状态。-上下文切换开销：CPU执行上下文切换时总会产生开销——从某些微控制器上的短短两个周期，到桌面处理器或嵌入式微处理器上可能需要刷新缓存、执行页表遍历和从磁盘重新加载RAM内容的数百万个周期。限制加速效果的实际因素（不包括进程并行化限制）：2.并行化的挑战充分发挥多核技术优势的关键在于将应用软件和基础软件合理分配到各个核心。然而，两个核心并不能自动带来双倍速度提升，其根本原因在于某些任务必须顺序执行，因此核心数量翻倍带来的性能增益永远无法达到100%。虽然阿姆达尔定律可以预测多核使用时的理论加速比，但实际性能还受其他（现实）因素限制。右侧方框中列举了部分示例。这一挑战的核心在于通过尽可能实现并行操作来获得最大效率提升，即尽可能减少顺序操作，并优化内存使用以避免等待时间。理论上，增加更多核心似乎是个好方案，但这也会增加并发问题的可能性，并带来主要与内存访问相关的额外问题。 AUTOSAR多核资源分配优化-资源争用：如果核心共享硬件资源且一个核心正在使用该资源，其他核心必须等待其可用。-干扰效应：即使两个核心访问两个独立外设，这些外设也可能连接到公共总线，从而形成瓶颈。-内存分配：芯片具有多个物理内存区域，其访问时间差异很大。高效分配应将数据移至运行代码附近。两种通用架构类型——具有多个相同核心的同构架构和具有多个不同核心的异构架构——通常混合存在于单个设备中。典型芯片可能包含多个相同的"主"核心，外加一些专用核心来加速特定功能，例如提供高性能高级加密标准（AES）的内置硬件安全模块（HSM）。在内存拓扑方面，当前大多数微控制器都采用混合设计，既包含共享内存资源，也包含每个核心的私有内存。不同内存区域具有不同的访问时间，因此内存布局对系统性能有很大影响。通过优化内存访问模式，通常可获得约10%的运行时间提升。 3.深度嵌入式系统的特殊要求尽管向多核发展势在必行，车辆中的深度嵌入式系统目前仍主要依赖单核系统。安全性、可靠性和实时行为这些在单核系统上发展起来的关键特性，现在需要为多核系统进行调整或重新建模。主要挑战在于：使用多线程的单核系统可能已经呈现出多任务并行的表象，但直接将代码移植到多核系统可能导致错误²。虽然理想情况下应从零开始一个多核项目，进行周密的前期分析和规划，而非尝试"转换"现有单核项目，但这种情况实属例外。在汽车行业，遗留系统占据重要地位且难以简单替换。因此，将创新解决方案集成到现有架构中往往是更可行的途径。对于深度嵌入式系统，AUTOSAR是当前开发者可用的行业标准。ETAS专家在2009年通过AUTOSAR 4.01版本推动了多核技术的引入，同时开发了ETAS RTA-CAR BSW软件栈来实现相关功能³。该版本最初包含对操作系统(OS)、运行时环境4.实践方案开发者转向多核的初始条件各不相同，很大程度上取决于现有遗留系统和工作流程。基本上可以分为三种情况：支持开发全新多核系统、将功能迁移到多核系统（从现有单核或多核系统）、或优化现有分配方案。ETAS拥有数十年支持OEM和供应商开发各种汽车用例ECU软件的经验。 AUTOSAR多核资源分配优化6(RTE)和ECU管理器(EcuM)的扩展，为深度嵌入式功能从单核迁移到多核提供了理论可能。遗憾的是，AUTOSAR最初实现多核支持的方式存在性能问题，因为完整的基础软件运行在一个核心上，而其他核心通过远程过程调用进行访问。4.11版本引入了"分区系统中增强的BSW分配"概念（也称为主/从模式）来解决这些问题。尽管AUTOSAR提供了功能文档和BSW分配指南，但实际实现仍极具挑战性。因此ETAS持续完善其解决方案，将最初的软件栈逐步扩展为全面的RTA-CAR产品组合，以全面支持各种客户用例。以下段落将通过三个真实客户项目案例展示配置和分配方案。前两个案例中，客户已具备多核分配方案，但面临配置问题。在简短的理论说明后，我们将以第三个案例作结——在该项目中我们从初始阶段就支持客户进行全新开发。所有案例描述均为总结性内容，着重于成果展示。RTA-CAR 概览久经验证紧凑高效功能多样符合安全标准 图1：将负载从core0迁移至core1实现了更好的运行时分布，代价是总负载有所增加。4.1 负载分布优化某整车厂就一个双核ECU项目联系ETAS寻求支持，该项目在现有双核分布方案下出现运行时问题，特别是core0的性能问题。项目首先对现状进行全面分析：运行时测量显示core0负载接近饱和，而core1仍有大量空闲资源（如图1所示）。通过将占15%运行时的完整通信协议栈从core0迁移至core1，core0的过载问题被降至合理水平。这一新分布方案导致系统总负载增加了4%，部分原因是新增了跨核调用（例如core0的诊断协议栈与core1的通信协议栈之间的交互），这些模块原先位于同一核心。仅迁移通信协议栈意味着原本的核心内调用现在需要跨越100%80%60%40%20%0% AUTOSAR多核资源分配优化7核心边界。总运行时增加的另一个原因是：测量时尚未根据新分布调整内存布局，通信协议栈数据仍驻留在core0的内存中，导致core1访问时间延长从而增加运行时。由于仅core0的运行时是关键指标，总运行时的增加对该项目并不构成问题。不过后续仍进行了诊断协议栈迁移和内存分配优化等改进，在项目推进过程中降低了运行时增幅。此案例展示了多核系统配置中需要权衡的典型场景：并非分布越分散越好，关键在于明确优化目标（单核负载、总运行时、中断延迟等）。core 1原始方案分布式方案+19% core 0-15% 4.2 减少运行时峰值在第二个案例中，某一级供应商的制动系统多核ECU遇到了另一种性能问题。虽然平均负载正常且各核心均有运行时余量，但系统在某些运行时峰值期间表现未达预期。运行时测量显示，通信协议栈中Com_MainFunctionRx的最大运行时间非常关键：该函数每5毫秒被周期性调用来处理新接收的协议数据单元（Pdu），而部分应用层软件（ASW）函数仅每40毫秒运行一次。最坏情况下，Com_MainFunction处理数据的频率达到实际需求的8倍。图2：根据消息时序拆分Com_MainFunction。要深入理解这一新分配方案的逻辑，需要仔细分析通信协议栈的架构。该协议栈包含多个层级：底层负责帧的打包和解包、协议特定头部的添加和移除、帧的分片和重组等任务，这些经过速度优化的层级计算量较小。因此PDU路由器（PduR）以下层级的运行时需求较低。图3：主要负载位于高层。ETAS建议将底层（总线协议栈）运行在单一核心，并在PduR层级进行分配以匹配ASW分布。名称Com_MainFunctionRxCanIfPduRComSignal layer 最大值[μs]Pdu数量Pdu数360.651203214 AUTOSAR多核资源分配优化8解决方案是将Com_MainFunction拆分为多个具有不同周期的主函数（见图2），并将Pdu分配给与最终读取数据的ASW函数周期相匹配的函数。作为额外优化，通常由Rx中断触发的Rx指示被拆分，大部分处理流程移出了中断上下文。这些措施共同解决了项目的运行时问题。.大部分运行时集中在高层级（PduR及以上）。为此，ETAS建议在较低层级处理触发事件，而让高层级采用轮询方式（图3）。如后续章节和图5所示，信号到核心的分配是在PduR层级执行的。名称Com_MainFunctionRx_5ms最大值[μs]Pdu数量24.0433338Com_MainFunctionRx_10ms36.06524Com_MainFunctionRx_20ms33.81093845Com_MainFunctionRx_40ms16.1541154310μs675RxIndication()Com_MainFuncRx()ComScl_RxCpy()Scl_Rx()Scl_Tx()Com_MainFuncTx()TxRequest in Ctrl3672514 core0NvM 服务(主)NvM 服务(从)存储栈SW-C4.3 BSW模块分布的主/从与多主架构方案前文案例展示了实际多核项目中出现的不同优化场景。现在让我们看看AUTOSAR对多核基础软件(BSW)的规范要求，以及ETAS RTA-CAR BSW栈的具体实现方式。ECU的核心任务是执行应用层软件(ASW)实现的功能，而基础软件(BSW)需要为此提供支持。在多核系统中，ASW运行于多个核心上。调用其他核心的函数会产生切换开销（同一核心不同分区间调用也存在开销，但代价较小）。部分BSW模块（如Dem、Fim、NvM或WdgM等具有服务型软件组件的模块）需要被ASW频繁访问。图4：需要通过主/从模式实现的跨BSW分区访问模块。 AUTOSAR多核资源分配优化9RTEμC跨分区队列(BSW内部)NvM 服务(从)NvM 服务(从)SW-C应用层软件(ASW)中的切换开销可能导致运行时或延迟问题。这类情况通常出现在具有服务型软件组件(ServiceSwComponents)的基础软件(BSW)模块中，例如诊断事件管理(Dem)、功能禁止管理(Fim)、非易失性存储管理(NvM)或看门狗管理(WdgM)。针对这些需要跨分区访问的模块，AUTOSAR定义了主/从架构方案：将软件栈拆分为控制底层的主模块，以及为其他核心或分区中的ASW提供访问接口的从模块。图4展示了NvM模块的典型实现案例。core1 core 0OsAppA (ASIL)OS IOCSW-CRTEAdderAdapterSW-COther BSWComPduRBus stackCan