汽车软件重构趋势：面向“同构多核”与“异构多核”“GGAI布道”

几十年来，汽车软件开发人员一直受益于能够在使用越来越强大的硬件的同时使用相同的软件代码。

由于硬件制造商经常通过提高晶体管密度和时钟频率来提高芯片的性能，软件开发享受着“搭便车”——他们能够轻松地在这些新处理器上开发，而无需改变软件架构。

然而，由于时钟频率增长的限制，芯片处理能力遇到了瓶颈。因此，芯片制造商一直在寻求大幅提高性能的新方法。

首先是超线程和同构多核架构，然后是异构多核架构。为了从这些硬件变化中获益，必须对现有软件进行并行化和修改，以处理异构性。

最新一代的微控制器(MCUs)和SoC片上系统，如英飞凌的AURIX 2G或英伟达的Drive Xavier，都指向了高度同构多核、甚至异构的多核硬件架构的趋势。

为了从这些芯片的进步中获益，汽车软件也需要改变。

平均而言，现在一辆新的乘用车拥有大约80个集成和网络化系统。虽然动力系统、ABS(防抱死制动系统)、安全气囊控制和车身电子控制等系统的控制传统上是独立的，但通过系统间的数据交换可以增加大量的价值。

然而，随着不同系统之间互连和网关数量的增加，接口数量的增加和可能出现的瓶颈增加了整个车辆电子网络可能变得过于复杂的可能性。此外，它们需要更多的测试和验证，复杂性增加了系统故障的可能性，并且总的系统成本不是最优的。

从过去的分散架构到具有全局和一致控制的集中架构的转变，已经是不可逆的行业趋势。

开发这类系统的关键将是转向支持软件的功能，专用硬件将被运行在微控制器(MCU)上的软件算法所取代。信号处理和通信将从模拟转向数字，通过线控驱动的功能，将实现换挡、混合控制、转向和刹车的机电一体化解决方案。

为了支持增强的软件功能，业界将转向功能更强大的MCU架构，提供实时和故障安全功能、广泛的外围设备集和eFlash，以支持必要的高性能和网络连接功能。

本文主要讨论标准化的软件体系结构，特别是AUTOSAR的分层软件体系结构，如何使用功能强大的mcu进行更新，以显著提高性能。

一、汽车芯片的变革

ARM在两年前发布了下一代处理器技术的第一步。基于ARMv8指令集的改变，将使用更灵活的处理器内核集群，将人工智能和机器学习的性能提高至多50倍。

ARM V8是ARM公司的第一款64位处理器架构，而专为嵌入式系统处理器所设计的ARMv8-R架构，则强调实时运算的效能，主要锁定汽车及工业控制运用。

而DynamIQ集群技术的发布，将允许多达8个完全不同的核，目的是广覆盖应用，包括ADAS、自动驾驶及企业服务器。

集群技术是ARM战略的核心。DynamIQ集群是继ARM11 4核集群、big.LITTLE之后的第三代，集群中的每个核都可以是不同的实现和不同的核，这将带来更高的性能和灵活性。

DynamIQ允许几个小内核和几个大内核独立运行，并根据处理需求在不同的内核之间切换代码。例如，1+3或1+7 DynamIQ+big.LITTLE组合。

这推动了SoCs的创新，可以采用合适大小的计算和异构处理，从而在设备本身提供有意义的人工智能性能。同时，每个核还可以有自己紧密耦合的加速器，这为人工智能和视觉机器学习提供更多的响应能力，这些外部加速器通过现有的CoreLink端口进行接口。

DynamIQ的定位是异构和可伸缩性。这两个词隐藏了许多生态系统术语，但ARM预测，未来ARM芯片的销量增长将主要依靠汽车、人工智能和机器学习等关键领域。

因此，性能、效率、可伸缩性和延迟都将是DynamIQ旨在促进的关键指标。DynamIQ的第一阶段每个集群最多有8个完全不同的核，来自不同的ARM Cortex-A家族，具有不同的配置，基础设计还允许每个核独立控制电压和频率，以及睡眠状态。

另一个重点就是冗余。新架构将允许使用数量似乎无限的集群，这样，如果一个集群失败了，其他集群可能会取而代之。

后续，ARM对DynamIQ是否扩展到SoC级别的冗余级别，或者是否将由ARM的合作伙伴在DynamIQ之上开发，这将是一件有趣的事情。

去年9月，Arm就发布了Cortex-A76AE(汽车增强)处理器，旨在确保自动驾驶汽车运行系统的安全和效率，支持DynamIQ技术，并优化为7nm工艺制造。

随后，Arm通过Cortex-A65AE扩展了其增强处理器系列，这是一种多线程CPU，设计用于在传感器级别处理数据需求，同样基于DynamIQ技术，并得益于其弹性和灵活的多核特性。

过去，每个传感器流都需要一个单独的处理器，以满足严格的吞吐量和延迟需求。但是，由于A65是一个多核处理器，具有多线程功能，可以做到每个核处理最多两个传感器信息流，从而提高了整体效率和延迟。

与A76一样，A65配备了Arm的分锁技术，可以灵活处理同一处理器上不同传感器的输入。使用split - lock，内核可以被“分割”，这样内核就可以按照优化的速度和性能来处理指令；使用“锁定”，这样两个内核就可以运行相同的指令，并检查每个操作，或者这两个操作的某些组合。

根据Arm的说法，锁定功能提供了额外的安全性，而不增加软件的复杂性，并符合ISO26262 ASIL D安全标准。

而结合A65和A76的设计是为了给汽车制造商一个最佳的解决方案，处理自动驾驶车辆的传感、感知和决策功能。

A65位于硬件端，处理传感器吞吐量。A65和A76的组合可以处理感知阶段，A65处理更多的吞吐量，A76承担更多的计算能力任务。最后，A76处理更高级的决策系统。

A65AE只是Arm自主增强处理器路线图中最新的一款。从2019年开始，Arm预计将宣布另外两款用于汽车的处理器：一款是未来的Cortex-R处理器，另一款是代号为“大力神”(Hercules)的AE处理器。

有消息称，大力神系列可能会在某些能力上专注于电力管理（功耗，另一个对自动驾驶汽车日益关注的问题）。Arm预计将在2020年发布第一批A56AE芯片。

二、为多核架构优化AUTOSAR

AUTOSAR软件体系结构的一个重要增强是在不同的核心上分布AUTOSAR通信堆栈，这对于实现多核体系结构的性能优势是必需的。

在AUTOSAR 4.0.1中，首先是对多核mcu的支持。在这次更新中，AUTOSAR提供了将应用程序软件组件(SWCs)分配给专用内核的方法，并通过运行时环境(RTE)促进了这些SWCs之间的跨内核通信。

然而，AUTOSAR basic software (BSW)仍然分配给一个单一的核。

在AUTOSAR 4.2.1中，AUTOSAR基本软件被划分为所谓的功能集群，这些功能集群可以使用BSW schedule manager (SchM)分配给不同的内核进行内核间通信。

由于通信堆栈作为一个整体是一个功能集群，因此不支持在多个核心上分布通信堆栈。而且，尽管AUTOSAR 4.4引入了分发最底层(微控制器抽象层)的BSW模块的可能性，但AUTOSAR通信栈的其余部分仍然必须放在单个核上。

在AUTOSAR的发展过程中，很明显，分配给单个内核的单片通信堆栈最终将成为性能瓶颈。这是因为软件的连续部分将继续对多核单片机的速度施加理论限制。

因此，它带来了将通信堆栈分布到不同内核的新方法，这对于获得多内核的性能好处是必要的。

在进行通信栈软件分发时，为了有效利用多核资源，需要考虑以下几点：

1、应该尽可能减少内核间的通信和同步，因为它们通常涉及内核间中断，而内核间中断又会导致MCU的操作模式(从用户模式转换到监控模式)、管道阻塞和缓存丢失。

2、如果需要内核间调用并且无法避免，则应该优先使用异步调用而不是同步调用。后者阻塞调用者，直到被调用者完成，从而降低并行度，从而潜在的加速。

不幸的是，这并不总是可能的，因为由于遗留的原因，AUTOSAR的通信堆栈大量使用同步api，而更改同步api将是一个主要的向后不兼容的重新设计。

3、此外，如果可能的话，应该避免使用锁实现内核间互斥，因为这将阻塞所有其他涉及的内核，而一个内核位于独占区域。由于典型的内核间互斥原语(如自旋锁)涉及繁忙的等待，这也会浪费阻塞内核上的CPU周期。

4、另一个重要的考虑是大多数多核mcu使用的非统一内存体系结构所需要的代码和数据的适当位置。

内存分为core-local内存(缓存、flash和RAM)致力于单一核心，可以快速访问和无冲突的核心，和全局内存(flash和RAM)，不同核之间共享和访问该内存慢和冲突。

在这种非统一的内存体系结构中，正确的代码和数据位置是至关重要的。频繁访问的代码和数据需要尽可能靠近访问核心。

使用静态AUTOSAR内存映射机制，应该根据在实际负载场景下导出的访问统计信息来执行这种布局。

三、堆栈分配策略

考虑到这些因素，我们可以为AUTOSAR通信堆栈开发通用分发策略。我们根据特定的网络类型(即、CAN、LIN、FlexRay和Ethernet)，并允许将这些子堆栈分配给一个专用的内核。

因此，任何潜在的并发访问通信硬件外设(即， CAN, LIN, FlexRay和以太网控制器)可以排除来自不同核心的。此外，不同子堆栈的完全独立和并行执行不需要它们之间的交互。

为了进一步推动这种分离和独立性，我们将通信栈(比如IpduM和Com)分成不同的部分。每个部分都配备了专用的处理功能，用于处理来自或针对特定网络类型的通信子集。然后，在专用核上为各自的网络类型分配这些专用处理函数。

通过这样做，我们可以有效地将特定网络类型的所有通信保持在一个单独的核心上，并排除对任何其他网络类型通信的干扰。

因此，我们避免了内核间的通信和同步，最大化了不同通信子堆栈的独立执行，并且能够将AUTOSAR通信堆栈的大部分同步API调用保持在各自核心的本地。

通信路径通常起源于一种网络类型并针对另一种网络类型（比如，网关路由路径），针对多种网络类型（比如，组播路由路径）由具有多核能力的PDU路由器(PduR)处理。

PduR使用SchM的内核间通信功能来处理路由路径中所需的核心转换。PduR中的缓冲或排队促进了异步(而不是同步)内核间调用的使用。这将导致调用者和被调用者的解耦，从而使不同网络类型的子堆栈的执行保持独立，即使对于这些通信路径也是如此。

AUTOSAR通信栈的这种核心分配导致了多核通信栈体系结构。

四、成功的OEM部署案例

本文描述的方法已成功地实现并部署在德国一家主要汽车制造商的两个实际量产车型项目中。

第一个项目涉及一辆高端车型的中央网关电子控制单元(ECU)，该单元需要在不同网络之间路由大量数据，并且显示出非常复杂的路由路径。

在这个设置中，使用了一个ST的Chorus 6M MCU，其中CAN、FlexRay和以太网子堆栈分别分配给专用的核。

第二个项目涉及一个动力系统域主ECU，该主ECU显示了涉及多个ECU的时间关键事件链，并且需要在多个CAN网络上严格确定时间。

在这个架构中，使用英飞凌AURIX 2G单片机，其中CAN和LIN子栈分配在一个内核上，FlexRay和Ethernet子栈分配在另一个内核上。

由于在这个项目中跨越核心边界的通信路径减少了，因此几乎没有核心间通信和同步的开销(少于1%的额外CPU负载)。

在内存映射方面，我们收集了实际负载场景下的访问统计数据，并针对频繁访问的代码和数据优化了内存映射。与未优化的内存映射相比，优化的内存映射减少了15%的CPU负载。

五、总结

要有效地使用多核mcu，通常需要分发AUTOSAR基本软件，特别是通信栈。

我们建议根据不同的网络类型划分通信栈，以防止对通信硬件外围设备的并发访问，允许完全独立和并行地执行不同的子栈，并减少内核间通信和同步的需要。

我们建议使用AUTOSAR的静态内存映射功能在内存中定位代码和数据，这些代码和数据与各自的内核具有很强的关联性，从而正确地使用快速内核本地内存，并在访问较慢的全局内存时防止/减少冲突。

实现该方法并将其部署到德国某大型OEM的两个系列项目中表明，通过分发通信堆栈和正确分配应用软件组件，可以有效地使用AURIX 2G单片机的多核，而且几乎没有内核间通信和同步的开销。

本文部分内容来自作者：Dr. Thomas Galla，Elektrobit公司首席专家