用自适应Autosar重新编程经典ecu

文章︰BernhardWagner，KPIT Technologies

自适应Autosar在实现车辆中更复杂的软件架构方面提供了高度的灵活性。这种灵活性可归因于执行用于维护目的的空中软件更新（OTA）的能力。随着即将到来的EU7法规，OTA用于车载监测（OBM）甚至可能成为强制性的。

自2019-11版本以来，Adaptive Autosar已经有了一个用于软件集群(SWC)更新的车载解决方案，包括更新和配置管理(UCM)。然而，车辆中仍有许多ecu继续运行经典Autosar或非Autosar软件。

随着新的2020-11版本的发布，UCM规范已经扩展到包括经典ecu的编程。一个基于ISO 22900-2“诊断协议数据单元API”标准(也称为D-PDU API)的简单解决方案实现了这一功能。自2009年起，D-PDU API已在船外测试中建立。

“经典”软件与D-PDU API的软件如何通过自适应自动启动进入车辆？

更新过程的起点是称为“OTA客户端”的自适应应用程序。此车辆和OEM特定应用程序的任务是与云中的OEM后端进行通信，或者使用传统的车间测试仪并在车辆内传输闪存数据。通过AutoSAR架构更精确地指定通信通道和物理。然而，通过以太网或可以通过以太网或可以使用无线电网络或通过以太网或可以使用本地车间测试仪的密码安全连接。

OTA客户端申请负责外部通信并完全摘要此通信。UCM主站是一个单独的自适应服务实例。它不仅提供了有关ECU，车辆本身，已安装的软件以及OTA客户端的ARA :: COM接口的信息，而且还提供了“车辆驱动程序应用程序”和“车辆状态管理器”的信息。最后两个应用程序确保驱动程序同意更新，另一方面，在更新活动期间无法运行车辆。

UCM主机接收整个车辆的闪存数据，称为车辆包。车辆包装通常由OEM用于整个车辆。除了单个车辆包装清单外，它还包含各种（虚拟）硬件平台，ECU和软件集群的软件包集合。此外，它包含每个软件包的独特方式将其分配给其UCM客户端。

一旦UCM主人正确接收到图2的车辆包，就可以开始车辆更新过程。更新包括一个或多个平台，ECU和（root）软件集群。UCM使用来自车辆包的数据来确保在正确的时间执行更新。此过程还可以包括多次重新启动ECU，自适应平台和UCM本身。为此目的，在必要的序列中调用各种UCM客户端，也称为UCM代理。

然后，UCM主人通过在OTA客户端上调用RequestPackage来开始编程软件包（SWP），如图3所示。

UCM主机对所有UCM客户端执行以下三个阶段。在这样做时，它必须考虑各种软件包和ECU之间的所有依赖项。

1）软件包的数据传输

这个过程从通过UCM主服务器将实际的flash数据从OTA客户端传输到UCM客户端开始。这些数据以类似于UDS的顺序传输到各种UCM客户端:TransferStart，几个TransferData，然后是最终的TransferExit。对于不同的UCM客户端，这个顺序也可以并行执行，以实现速度优化。因此，闪烁适配器将首先缓冲数据。一旦获得了驾驶员的同意，并确保了其他前提条件(如车辆停止)，经典ECU的实际重新编程现在可以使用指定的闪烁适配器进行。

2)软件包编辑

在整个过程中，当软件包的处理可能发生时，UCM主根据Vehicle Package数据来决定。它会在预定义的时间通过带有ProcessSw包的闪烁适配器触发ECU的更新。

然后，闪光适配器执行ISO 14229-1:2020中描述的正常UDS闪光序列，第17.2.1.1章“阶段#1的预编程步骤”和17.2.1.2章“阶段#1的编程步骤-应用软件和数据的下载”。一个闪光适配器知道并观察特定于ECU的序列，并提供所有必要的数据，例如，安全访问和擦除内存。flash Adapter建立在D-PDU API“C”接口上，用于传输UDS业务。UDS数据通过CAN总线或以太网总线传输到经典ECU进行重新编程。为了达到这个目的，闪烁适配器只提供实际的二进制数据(PDU)，独立于任何协议或D-PDU API的实现。因此，它可以在不同的自适应环境或不同的硬件平台上使用，而无需修改。在TransferExit之后，这个过程结束了对Classic-ECU新编程应用的校验和的计算和验证。这个flash进程的结果最终被报告回UCM主服务器，并在此步骤中使用CurrentStatus=READY。

3)激活

将数据传输到Classic-ECU后，UCM主机再次检查所涉及的软件集群的依赖关系和车辆的安全要求。如果这是正的，UCM主然后调用闪烁适配器再次与Activate。此触发器启动ISO 14229-1:2020中第17.2.1.3和17.2.1.4点中描述的编程结束后步骤。特别是，这也通过“硬复位”重新启动连接的经典ECU。闪烁适配器结束其活动，并向OTA客户端反馈新软件包为CurrentStatus=ACTIVATED。

重编程过程结束后，UCM主端报告状态为TransferState=IDLE的数据包成功传输到OTA客户端，此过程结束。

这种架构提供了许多优点:

• 当提供车辆包时，它对软件包无差异是自适应或经典的ECU。因此，车辆中OEM的自适应OTA客户端可以更新该车辆的所有网络ECU。
• 作为UCM客户端的闪光适配器向上是Autosar UCM接口(第7层)，向下是标准化的D-PDU API接口(第5层)。因此，它既不依赖于硬件，也不依赖于Autosar堆栈的供应商。它只依赖于相关的经典ECU本身，它作为一个诊断应用程序执行flash运行。因此，ecu供应商可以将参数化的闪烁适配器作为Autosar应用程序交付给OEM，以便在现场重新编程他们的ecu。
• 自2008年以来，ISO 22900-2 (D-PDU API)已经在该领域的许多船外诊断系统中得到了证明。它是将各种车载通信接口(VCIs)连接到诊断系统的基础。得益于异步和队列，它提供了比PassThru (SAE J2534)或RP 1210等类似标准更高的性能。在D-PDU API中，所有协议参数及其行为都是完全标准化的，这对应用程序的交换至关重要。
• 机载闪光适配器的相关部分与符合ISO 22900-3的机载诊断应用程序相同。这意味着，在最终将闪光序列作为闪光适配器集成到自适应自动sar环境中之前，可以很容易地开发和测试闪光序列。这有助于特殊情况下的船外测试覆盖，提高质量，并节省时间和成本。

KPIT已经与几家大型oem合作，实现了一个概念验证(PoC)解决方案，其中包括OTA客户端和一个闪烁适配器。事实证明，在动态开发环境中使用标准化协议参数非常有利，可以使车辆更新平稳、不引人注目且易于测试。

相关的Autosar规范“更新和配置管理”刚刚在Adaptive Release 11-2020中重新发布。由于使用了经过良好验证的规范，已经实现了高度的成熟度。因此，允许在未来的项目和项目中广泛和有效地使用这一概念。

关于作者

该企业。Inf. Bernhard Wagner, MBA，是KPIT Technologies的Autosar和诊断主题专家。他是自适应Autosar联盟的活跃成员。