1、概述
FOTA方法应引入一种在运行时更新ECU软件的通用机制，当前ECU软件被执行并且从功能角度（例如在驾驶过程中）完全可用时，应在后台（安装阶段）对新的ECU软件进行编程。在安装过程中(安装过程可能会中断并持续几个驾驶周期)，应验证新软件的真实性和完整性。如果验证结果是肯定的，ECU应能够激活新的SW，SW的激活总是需要一个特殊的ECU模式(例如boot)，因此新SW的激活不能在驾驶时启动甚至执行。激活应在车辆安全状态下进行，例如静止，发动机关闭和应用驻车制动。如果在新SW激活后或激活过程中检测到异常或错误，ECU应能够实现ECU内部回滚到以前的SW，ECU内部回滚意味着以前的SW仍然存在于ECU上，并且可以重新激活。
重要提示:FOTA功能的整个实现方法在很大程度上取决于AUTOSAR目前正在开发或讨论的概念和变更请求。
这些讨论点预计将在下一个发布阶段得到解决:
1.1、动机
由于不断发展的安全需求、分布式和连接功能所驱动的软件复杂性不断增长，使车辆系统保持最新的需求不断增加。
为了避免由于即将到来的软件更新而导致的耗时和反复的服务车库访问，应该通过空中编排软件部署到车队。
不同的无线技术(UMTS、LTE、蓝牙、WiFi、5G)可用于将车辆连接到后端/云系统，以提供将软件下载到车辆上的能力。
新软件通过CAN、CAN- fd、Flexray或汽车以太网等车载总线分发到受更新影响的目标ECU。
如今，大多数ECU都具有车载重新编程功能，用于服务车库基础设施，以部署错误修复或在现场进行功能改进。
该接口通常是一个flashbootloader，也可以通过无线(OTA)升级主ECU来解决，以便在车辆不在维修车库时安装新的SW。
换句话说，您可以通过将编程功能从外部诊断测试仪转移到连接的车载ecu (OTA-Master)来实现无线软件更新。
从目标ECU的角度来看，无论目标ECU是通过诊断测试仪还是OTA Master进行的，它都可以更加透明。
这一办法带来了需要考虑的几个方面:
在整个软件更新过程中，从功能的角度来看，目标ECU是不可操作的。这通常会导致整个车辆在软件更新期间停机。
在分布式功能的情况下，在一个活动中必须更新多个ECU，与单个ECU更新相比，车辆停机时间更长。
如果在安装新软件期间或之后出现错误，可以启动并通过OTA-Master重新安装以前的软件。然而，这额外增加了车辆的停机时间，并可能最终导致ecu功能砖化的情况。
如果需要回滚，则必须回滚与更新相关的所有依赖ecu。
电源的概念和电池的剩余容量也应注意遵循这种方法。
为了达到更高的成熟度，需要分析其他OTA更新方式的可靠性和舒适度，并确定它们对现有BSW架构的影响。
为减少OTA更新运行导致的车辆停机时间，部分OTA更新过程应在ecu正常运行时执行，例如在驾驶时。
当前软件正常运行时，新的软件将在后台安装。这不会对当前运行的软件的性能和可用性产生任何负面影响。新软件的安装应是可中断的，即在一个驾驶周期结束时不应完全放弃安装过程，而应在下一个驾驶周期中继续安装。《断点续传》。
在后台安装过程结束时，新软件应该准备好激活。由于µC和所用flash设备的硬件功能不同，新软件的激活可以通过从µC以前不活动的分区启动来实现（取决于硬件功能），也可以启动ECU内部激活过程，包括将新软件从纯存储复制到执行分区的ECU内部复制。纯存储分区可以分配在µC内部或µC外部闪存上，例如通过SPI连接（有关详细信息，请参阅第5.2.1.3章）。
在根据给定产品的硬件能力激活新软件的过程中，以前的软件应保留在ECU内。如果在激活期间或之后检测到错误，则应启动ECU内部回滚到先前的SW。这应通过定义的内部标准来完成，例如检测新软件的破坏真实性，或通过OTA Master进行外部触发。(例如CRC校验失败)
这种方法将解决或从本质上改进上面列出的OTA更新方法的缺点，其中安装和激活是在功能非操作模式下实现的。这将大大减少车辆的停机时间，并且新的软件可以并行安装在多个ecu上。一旦在所有受影响的ecu上安装了新的SW，就可以集中触发激活。如果激活过程中出现意外异常，将触发回滚，并在所有受上次OTA更新影响的ecu上执行回滚。
思考点：回滚应该有次数限制，例如新SW有问题，回滚到旧SW也出现了问题了，这个时候记录回滚次数，例如达到三次就停在BootLoader的扩展会话下等待人工升级。
1.2、范围
本文档的目的是提供新的软件更新概念，它支持在ecu上安装新的软件，同时正常执行当前的软件。这包括这样一种情况，即车辆在行驶过程中，新软件安装在受影响的ecu上，而这些ecu的功能没有下降。
本文将评估避免运行时系统干扰和阻塞的策略。这意味着所有正在运行的应用程序以及系统服务(例如诊断，NvMemory)在更新过程中应该是完全可用的，并且可能以最小的方式从功能的角度影响任何请求处理的延迟。
本文还将详细介绍ECU内部备份和回滚功能的不同方法。
1.3、通用用例
新的ECU软件应使用诊断通信服务(Dcm使用UDS)传输，并通过FOTA Target模块传输到底层内存驱动程序。内存堆栈应该将新软件编程到一个非活动内存分区中。要使用缓冲机制来分段地将SW映像传输到内存堆栈。安装过程成功并验证新软件的完整性后，将触发激活机制，最终启动新软件。如果在新软件激活期间或之后出现故障，则可以回滚到以前的软件，该软件在ecu内部仍然可用。
可以在这里找到实现FOTA过程所需的详细要求的完整列表:[3]
《AUTOSAR_CP_RS_FirmwareOverTheAir》
1.4、本文件的限制
本文档未涵盖的用例和主题:
·更新不支持UDS的ecu
·新内存 SW 的验证策略
·ECU软件版本处理和检查(特定供应商)
·ECU软件兼容性/完整性检查(特定于供应商)
·关于内存堆栈的SW架构的任何细节
2、假定和约束
2.1、内存栈的必备条件
在本文档中，术语内存堆栈将取代内存驱动程序(例如FlashDriver)和内存管理模块(例如Fee)，无论它们是作为内部驱动程序还是外部驱动程序实现的，因为在AUTOSAR中尚未做出关于架构解决方案的决定。
只要这些先决条件还在讨论中，而且还不是规范文档的一部分，为了实现本文档中描述的FOTA方法，必须考虑并在内存堆栈中实现以下假设。
访问程序闪存
到目前为止，AUTOSAR仅在运行时预测对数据闪存部分的访问，对程序flash部分的访问还没有在AUTOSAR中解决，需要以专有的方式实现(例如在引导加载程序模式下)。为了实现FOTA方法，有必要在运行时获得对程序闪存部分的读写访问权限。因此，为了获得对程序内存的写访问，AUTOSAR内存堆栈的扩展目前正在开发中。
Read-while-write特性
假设在具有A/B交换能力(内存抽象)的硬件解决方案上实现FOTA，则需要将新软件写入非活动内存段，而在正常并行执行期间访问活动内存段进行读取。
这主要影响程序flash访问的计划实现，其中一个分区被执行(活动)并进行读取访问，而另一个非运行时相关的分区(非活动)需要具有写访问，以便在后台应用新软件。
为了实现读写方法，硬件供应商需要在他们的MCAL实现中提供所需的功能。
使用不同的内存解决方案
FOTA过程适用于所有不同类型的内存架构和技术。
然而，硬件和驱动程序供应商负责提供所需的接口，由AUTOSAR MCAL层定义，以便以这里描述的方式检测FOTA功能
现有和未来的硬件解决方案以及底层驱动程序之间的差异，预计将在所有提供的内存堆栈api接口中不可见。
换句话说，应该支持所有现有的内存架构，而不会以任何方式影响任何上层。
处理Nv(用户)数据
虽然用户数据（Nv-Data，见第 5.1.1.3 节）的更新是由 NvM 模块利用其提供的功能和接口来处理的，但必须定义一种适当的机制来迁移数据模型等，同时这些数据模型仍可由活动分区访问。
从架构的角度来看，这将产生如图2.1所示的概述:
2.2、FOTA Master实例的实现
由于FOTA方法既适用于AUTOSAR的经典平台，也适用于自适应平台，因此决定将FOTA- master实现置于自适应平台中，因为自适应ecu的功能有望比经典ecu强大得多。
这个FOTA-Master实现是由WG-UCM团队在自适应平台上下文中完成的，并将被称为UCM-Master。
UCM-Master将处理、处理和引导对经典平台的更新，预计将在R19-11中与本文档一起发布第一个版本。
然而，由于本文档关注的是FOTA特性，因此它将始终将主实例称为FOTA- master，其中在自适应平台中实现的不同实现称为UCM-Master。
2.2.1、进一步阅读
有关UCM-Master实现的更多信息，请参见规范文档[1]。
《AUTOSAR_AP_SWS_UpdateAndConfigurationManagement》
有关此处引用的FOTA-Master角色的更多信息，请参阅第3.2.2和5.1.2章，了解其预期行为的详细信息。
有关潜在的非易失性数据处理和迁移的更多信息，请参阅规范文档[4]。
《AUTOSAR_CP_SWS_BulkNvDataManager》
3、术语
在本章中列出了FOTA过程中使用的所有先决条件、假设、过程和系统术语。
3.1、缩略语
3.1.1、未在TR_Glossary中列出的缩略词
3.2、系统组件术语
3.2.1、FOTA 目标（FOTA Target）
本术语一般适用于所有能够通过FOTA程序进行更新的ecu。
3.2.2、FOTA主机（FOTA Master）
FOTA Master指定处理所有软件更新的实例，以及将相应更新应用于FOTA更新过程所处理的FOTA目标ECU所需的所有相关信息。
注意：请记住，FOTA Master是在UCM Master概念的背景下实现的，该概念目前正在开发中，未来可能会发生变化。UCM和FOTA小组之间的合作已被考虑并计划在未来发布。
3.2.3、FOTA镜像（FOTA Image）
Image这个术语描述了一个完整的可下载ECU软件集合。无论是否下载并安装了部分、增量或全功能ECU软件(见图3.1)。将新映像应用于ECU将至少更新以下ECU软件部分之一:
·ASW
·BSW
·标定数据
在将新映像应用到ECU之后，它必须处于完全功能状态并与系统的其余部分兼容。
3.2.4、后端
这将识别提供FOTA映像的远程实例，以便下载到FOTA目标ECU中(例如通过Wifi, 3G, 4G, 5G等)。
3.2.5、数据块
数据块是数据包，从FOTA主ECU传输到FOTA目标ECU，包含原始图像数据(UDS TransferData服务负载)。之所以使用这个术语，是因为每个数据块的长度可能不同。
3.3、流程术语
整个FOTA更新过程可以分为几个阶段，在本章中进行了展示。总体概况如下图所示:
3.3.1、更新
术语“（FOTA）更新”用于表示ECU的整个更新过程（或在其他相关ECU更新的情况下的多个ECU）。它包含以下所有描述的任务，如下载、安装、验证、激活等。如果有必要，可以将回滚功能视为更新过程的一部分。
3.3.2、下载
下载映像是指将FOTA目标ECU的完整更新所需的所有相关和必要的ECU软件、数据和配置从后端服务器传输到FOTA主实例。
3.3.3、安装
术语“安装”是指将新的ECU软件从FOTA主ECU转移到FOTA目标ECU。由于一次将整个ECU软件完全转移到FOTA目标ECU并不方便，因此该过程是使用数据块实现的（详见第3.2.5章）。这意味着安装过程甚至可以在几个行驶循环中处于活动状态。当没有更多的块可以传输到FOTA目标ECU并且所有块都已成功写入内存堆栈时，安装过程就完成了。
此外，安装过程还包括FOTA目标ECU内的程序flash驱动器将软件实际写入非活动目标分区。
3.3.4、校验
验证过程是具体实施的，应确保新flash的ECU软件的正确性。这只会影响闪存到相应FOTA目标ECU中的普通ECU软件（例如图像或甚至差分更新）。
注：作为软件更新包，与FOTA映像的完整性和真实性相关的初始验证、身份验证和条件检查由FOTA Master完成。从FOTA目标的角度来看，FOTA程序中的验证检查应侧重于语义和功能的完整性，因此是具体实施的。如果需要，可以对FOTA目标再次进行完整性和真实性验证
注：如果使用外部闪存，在激活过程中需要将其复制到内部存储器，则应考虑复制后的第二个验证步骤。这应确保SPI从外部到内部存储器的传输不会发生意外修改。
3.3.5、激活
激活过程描述了ECU引导分区的实际开关。在不可切换存储器架构ECU（例如，外部闪存、固定多分区存储器）的情况下，这也涵盖了从临时（例如外部）闪存到内部闪存的复制过程。当确认先前ECU软件（n-1）的备份时，激活程序完成。
注意：新安装的软件的最终激活必须在车辆安全状态下进行。由集成商来确保车辆的安全状态。
3.3.6、回滚
在回滚过程中，必须恢复以前运行的软件中的所有ECU和用户数据。回滚完成后，与整个更新过程开始前相比，ECU软件和用户数据不得有任何差异。
4、需求
到目前为止，为FOTA定义的所有要求都可以在AUTOSAR RS文件中找到
《AUTOSAR_CP_RS_FirmwareOverTheAir》
5、详细技术方案
本章提供了为固件空中传送程序设置FOTA目标功能所需的所有信息。受影响的体系结构组件，FOTA目标ECU之外，也在这里列出了系统完整性。
下图显示了整个FOTA过程中所有相关组件和模块的体系结构概述。
5.1、功能与架构对象
FOTA整体架构设计(如上图所示)包括:
·FOTA目标ECU
它从 FOTA 主站接收要刷新的 ECU 软件，并将软件转发到低级存储器堆栈实例（实际的 ECU 软件刷新过程）。
·FOTA主ECU
缓存所有新的ECU软件工件，以下载到FOTA目标ECU
·后端服务器
它为FOTA主ECU提供要安装到FOTA目标ECU的映像。
5.1.1、FOTA Target ECU
由于 FOTA 处理器规范目前还在不断发展中，并非所有功能都已指定和定义，因此 FOTA 处理器模块目前被视为 CDD。之所以做出这样的决定，是因为到目前为止，还没有定义足够的功能来发布一个完整的新 AUTOSAR 基本软件模块。如果将来功能集发展到 BSW 模块的复杂程度，将考虑定义 FOTA BSW 模块。但是，由于 “边读边写 ”闪存方式和程序闪存访问方式的架构决策（将由相关的 AUTOSAR MCAL 小组实现）尚未确定，因此 CDD 方式保留了通过所有 BSW 层进行连接的选项。
5.1.1.1、FOTA 处理器模块的功能说明
FOTA Handler模块旨在处理FOTA块缓冲区(位于DCM模块中，作为协议行配置的一部分)处理，并在新的块数据到达时最终触发内存堆栈，并且内存驱动程序可用于写入。
在FOTA Handler模块中，需要实现为Dcm模块接收到的请求提供服务的相应调出函数(Dcm模块提供FOTA数据块)。在这个callout函数中，需要处理FOTA块的接收。
本文档中描述的解决方案方法在FOTA Handler模块中实现了两个功能:
·FOTA_ProcessTransferDataWrite(…) (Dcm callout)
每次 Dcm 模块接收到镜像数据块时，都会调用该函数。该函数的主要任务是通知 FOTAHandlerMain(…)函数将处理接收到的新数据块。此外，OpStatus 调用参数应设置为 DCM_PENDING，直到数据块处理完毕。在数据块处理过程中，调用函数应始终以 Dcm_ReturnWriteMemoryType = DCM_WRITE_PENDING 返回。这将告知 Dcm 当前的服务处理情况，并转发给 FOTA 主站，以防止超时。一旦收到 FOTAHandlerMain(…)函数完成块处理的指示，FOTA_ProcessTransferDataWrite(…)应返回 Dcm_ReturnWriteMemoryType = DCM_WRITE_OK，以通知 Dcm 和 FOTA Master 处理成功。之后，FOTA 主控 ECU 可以发送新的数据块。
·FOTAHandlerMain(…)
该函数对 FOTA_ProcessTransferDataWrite(…)函数指示的新数据块进行实际处理，并将其转发到内存栈进行编程。FOTAHandlerMain(…) 函数应由 AUTOSAR 操作系统周期性调度，独立于诊断和通信栈。一旦接收到的数据块处理完毕，FOTAHandlerMain(…)函数应通过使用 InterRunnableVariable 等方式向 FOTA_ProcessTransferDataWrite(…) 表明这一点。
5.1.1.12、DCM
由于 AUTOSAR Dcm 模块实现了 UDS（参见 [6]）诊断协议，因此可 “免费 ”提供大量有用的功能来实现 FOTA 功能：
·会话控制
·安全访问
·身份验证
·服务处理(0x22\0x2E\0x31\0x34\0x36\0x37)
·错误处理
·检查编程条件
·复位ECU
目标是尽可能多地使用DCM模块已经提供的特性。由于缺乏FOTA程序所需的功能而进行的任何额外扩展应在不扩展DCM模块的任何核心功能的情况下实现。
为实现FOTA要求而需要的额外扩展应由FOTA Handler模块实例或FOTA Master模块实例(UCM-Master，详见5.1.2章)实现。
5.1.1.3、Nv Data
AUTOSAR 中的 NvM 模块通常会处理数据闪存（用户数据、校准数据、错误和快照、ECU SW 的附加运行时数据），并将它们排列到所谓的 NvDataBlock 中。NvM 模块提供了读取、写入或删除这些数据块的功能和接口。为了迁移或修改 NvData，应使用 NvM 模块提供的功能，无论是 FOTA 主设备还是 FOTA 目标设备，都不得与数据闪存直接交互，以避免干扰、阻塞或数据损坏。这意味着，例如，影响 NvData 或用户数据迁移的数据模型变更必须由实施者处理。详情请参见第 5.3 章。
但是，为了安全地存储与 FOTA 进程相关的信息（如当前 FOTA 进程状态、FOTA 处理程序最后一次成功写入的内存地址等），以便在中断期间持续存在，应使用 NvM 模块来处理（FOTA 特定的）用户数据。应使用相关规范文件中定义的机制（详见 [7]）。
《AUTOSAR_CP_SWS_NVRAMManager
5.1.1.4、OTA镜像类型
一般来说，有几种方法可以更新ECU，例如安装完整的系统映像或仅安装部分软件。甚至可以进行部分和增量更新。但是，由于本文档没有详细说明如何将新软件安装到FOTA Target ECU上，因此只要使用的安装机制允许，所有类型的更新都是可能的。
根据所使用的硬件的能力，可以选择几种放置新图像的方法:
·从固定地址运行时执行
在这种配置下，由于硬件限制，无法交换分区。在这种情况下，映像数据需要放在临时存储位置（无论内部或外部内存），并在激活阶段复制到可执行运行分区。在回滚情况下，需要备份之前的软件版本。
·从灵活地址运行时执行
硬件支持交换分区，因此新的 SW 可以放在任何可用的分区中，并在激活后从该位置执行。映像中地址和偏移量的调整或转换必须由执行者来确保。
下表列出了两种分区类型的几个属性:
目标 | 固定地址 | 灵活地址 |
安装 | 存储在临时存储器内（内部或外部存储器） | 直接写入芯片内存 |
激活 |
| 切换分区 |
激活时间 | 慢（需要将镜像数据复制到目标分区） | 快速（引导程序直接切换） |
镜像类型 | 可定位与不可定位的镜像 | 重定向镜像 |
寻址方式 | 固定寻址 | 逻辑地址 |
最小分区 | 3 | 2 |
典型应用 |
| ECU内存需要大于两倍镜像 |
5.1.2、FOTA Master (UCM-Master)
FOTA 目标 ECU 需要与相应的主控实例通信，以接收 FOTA 图像数据。该主实例必须存储车辆网络内所有相关 ECU 的图像数据，这些数据量可能相当大。
通常，经典平台针对的嵌入式ecu在内存、存储和计算能力方面的资源有限。因此，将主实例的责任转移到ecu是有意义的，ecu提供了更强大的自适应平台。
主实例与FOTA目标ECU通信的实现目前由工作组更新和配置管理(WG-UCM)完成。这将导致以下逻辑架构:
注意:请记住，UCM-Master概念目前正在开发中，可能会发生变化。WG-UCM和FOTA概念组之间的潜在合作被考虑用于未来的版本。
5.1.3、后端
Backend实例表示要更新的车辆的初始图像提供程序和通知接口。关于可用新软件的通知可以从后端实例触发到汽车，或者车辆自行决定何时询问新软件是否可用(轮询方法)。但是，如果车辆网络中有一个或多个ecu的新软件可用，则会启动提取过程，并将图像存储在车辆内的适当位置(例如FOTA Master)。关于与其他软件包的依赖关系的信息也必须由后端提供。关于FOTA流程的状态和更新进度信息可以与后端共享，用于分析和诊断目的。
5.2、FOTA步骤
注:请记住，本章的所有说明主要是最佳实践，仅作为实现FOTA程序的指导方针。
5.2.1、FOTA处理程序模块
在FOTA更新过程中，FOTA Handler模块需要关注某些操作，以便创建一个可靠的更新过程:
·从FOTA Master接收数据块
·处理数据块
·将数据块转发到内存堆栈
·FOTA Master交换状态信息
5.2.1.1、内部FOTA状态
FOTA Handler模块需要处理和指示FOTA图像处理过程中的所有不同状态。为了向启动和触发 FOTA 程序的 FOTA Master 提供此信息，应实现诊断服务，以便从 FOTA Target 的角度提供和更新安装程序的当前状态。一些不同的状态应通过以下列举来反映:
·IDLE
ECU启动后FOTA处理器的初始状态
·INIT
初始化FOTA Handler，并将Dcm设置为正确的状态(在Dcm中，FOTA会话和安全访问已被授予)。
·READY
所有FOTA数据块已经安装，激活程序可以被触发。
·PROCESSING
FOTA Handler由Dcm调出触发，因为已经接收到一个新的块并在调出上下文中进行处理。
·WAIT
FOTA Handler已经成功处理了最后一个接收到的数据块，返回了Dcm callout函数，正在等待下一个数据块。
·VERIFY
可选的和特定于实现者的步骤，因为FOTA目标没有指定任何关于验证过程的细节。
·ACTIVATE
FOTA安装已经完成，并从FOTA Master接收到一个相应的服务作业，该作业指示下一个引导过程中的分区切换。
·ERROR
可选的和特定于实现的。保留状态，例如用于特定于实现者的错误处理，FOTA目标(尚未)涵盖此状态。
所有上述列出的状态将有助于保持FOTA目标状态，因此整个FOTA更新过程是确定的、可靠的和可恢复的。这将产生一个处理FOTA更新的状态机，如下图5.3所示:
注意:转换到IDLE或READY可以通过RequestTransferExit()调用中的OpCode参数来区分，详见SWS_DiagnosticCommunicationManager[8]。
注意:FOTA Master触发的回滚将是从任何状态转换到ACTIVATE状态
FOTA内部状态枚举应作为Read/WriteDataByIdentifier或由FOTA目标ECU Dcm模块提供的RoutineControl UDS服务提供给FOTA主ECU。
FOTA Handler模块的状态转换在正常(不间断)处理中由FOTA Master实例控制。在中断的情况下，内部FOTA状态指示恢复策略。为了恢复任何中断的FOTA程序，所有附加信息应由FOTA Target ecu Dcm模块作为用户作业提供(更多信息请参见5.2.3.8节)。
5.2.1.2、安装
安装过程在WAIT状态下启动，等待来自FOTA Master的TransferData服务请求。一旦接收到此消息，FOTA处理程序将其状态切换到PROCESSING。在这种状态下，在DCM RAM缓冲区中接收FOTA块(参见5.2.3.4章，也参考规范文档[8])。一旦接收到数据块的所有数据，Dcm模块将执行FOTA callout函数对数据块进行处理(见5.2.3.5)。callout函数以Dcm RAM缓冲区中的块的地址作为输入参数，并使用内存堆栈接口将该数据编程到闪存中。目的地址(分区中的偏移量)和块大小也是该函数的输入参数。可选地(特定于实现)，callout函数可以在编程后验证数据。可选地(特定于实现)，callout函数可以在编程后验证数据。一旦编程完成，callout函数将最终响应(OK/NOK)返回给DCM，因此它可以传输到FOTA Master。在此之后，FOTA处理程序切换回WAIT状态。callout函数必须异步实现，即在FOTA主函数中，由操作系统循环调用。
5.2.1.3、激活（切换分区）
为了使新flash的ECU软件生效，需要一个切换机制。这适用于所有可用的flash解决方案(例如A/B可交换或临时存储)。切换机制需要处理成功切换引导/运行时分区所需的所有活动(例如，将新的ECU软件从外部移动到内部闪存)。有关当前活动分区的状态信息和非活动分区的更新状态必须在所有运行模式下可用(例如，引导加载程序，应用程序)。
注意:从系统的角度来看，这种切换机制也是HW的先决条件。
由于当前更新是否依赖于其他 ECU 更新及其状态对 FOTA 目标 ECU 来说并不透明，因此 FOTA 主控器需要处理依赖关系以及激活新 SW 的时间点。需要配置相应的 Dcm 服务任务来触发 FOTA 状态机从 “准备 ”到 “激活 ”的转换，例如使用例程控制（ARApi:RC_TriggerActivation）服务。该 RoutineControl 服务的执行是 FOTA 处理器模块的一部分，必须执行所有必要步骤，为下一次 ECU 重启时的实际激活步骤做好准备。执行激活所需的所有步骤(例如验证，通知其他ecu或FOTA-Master)都是特定于项目的，因此此处没有详细说明。
注意:记住，控制激活指示的标志/数据字段必须位于引导加载程序和应用程序都可以访问的内存区域中。
5.2.1.4、回滚
回滚场景的主要用例是主触发的回滚。这意味着，FOTA Master检测到一个或多个新安装的软件映像上的错误，并主动触发回滚，例如，当来自后端请求或检测到版本不兼容时。
这必须由FOTA Master以适当的方式使用Dcm模块提供的UDS服务(例如ReadDataByIdentifier/WriteDataByIdentifier, RoutineControl)进行指示，详细信息请参见5.2.3.1节。
或者，各自的FOTA目标ECU，不能成功启动，将自动启动回滚过程(例如，切换回分区)，以再次达到运行和通信状态
回滚分为自动回滚与通过FOTA Master触发两种，自动回滚软件版本号怎么进行处理呢？。
在自动回滚和FOTA目标ECU再次响应之后，FOTA主ECU可以请求相应的SW版本。
根据要求 [RS_FOTA_00035]，要将某个 FOTA 目标 ECU 当前运行的 SW 版本读回给 FOTA 主 ECU，必须提供适当的 UDS 服务（例如 ReadDataByIdentifier/WriteDataByIdentifier、RoutineControl），详见第 5.2.3.1 节。
具体的实现方式在很大程度上取决于系统设计和结构，以及特定的原始设备制造商和供应商。下面解释了一种可能的实现方法
为了在 FOTA 主 ECU 启动后显示正在运行的 FOTA 目标 ECU，应在每个 FOTA 目标 ECU 的相应 Dcm 配置元素 DcmDspEcuReset 中将参数 DcmResponseToEcuReset 设置为 AFTER_RESET。这将向 FOTA 主 ECU 发送最后的肯定响应，以宣布每个 FOTA 目标 ECU 在单独复位后的可用性。然后，FOTA 主 ECU 可以询问系统中每个 FOTA 目标 ECU 当前运行的 SW 版本。
不同 FOTA 目标 ECU 之间的依赖关系，以及是否应用潜在回滚，必须由 FOTA 主 ECU 评估和触发。
注意：考虑将配置参数 DcmSendRespPendOnRestart 设置为 “true”，以便通知 FOTA 主 ECU 重新启动以进行激活。
5.2.1.5、取消
取消是指正在进行的 FOTA 软件更新过程的丢失。FOTA主ECU可在FOTA更新启动和安装程序完成后的激活触发之间的任何时间触发取消过程。
详细地说，取消只是通过在FOTA主ECU端执行RequestTransferExit服务来停止从FOTA主ECU到FOTA目标ECU的FOTA数据块传输。
此外，刚刚取消的软件应应用到的目标分区也应失效，以便向 FOTA 目标 ECU 表明，在 ECU 因新的驾驶周期而重置/重启后，无需恢复中断的更新。有关失效程序，请参见第 5.2.1.6 章。
5.2.1.6、使“旧”运行时分区无效
在成功切换到新软件并确认整个启动过程和运行时可用性后，可将先前（现在为非活动）的分区作废，以避免意外或强制的未授权回滚。这样可以确保以前的活动软件及其潜在漏洞无法再被激活。实施者可自行决定是否使 “旧 ”软件失效。
注意:使前一个分区无效的触发器预计将由FOTA Master发送，因为如果另一个ECU在多ECU更新活动中更新失败，则可能仍然需要回滚。
注意:如何实现这个功能还没有在FOTA上下文中定义，因此是特定于实现的(例如，通过设置标志，删除“旧”分区，使分区校验和无效，等等)。
5.2.2、FOTA Master
该 FOTA 主站实例连接到在 Dcm 模块中配置的专门定义的用户任务（详见 5.2.3 章）。Dcm 模块和 FOTA 处理器模块之间的数据传输应使用 FOTA 数据块，以便使 FOTA 下载和闪存程序具有可中断（可抢占）的能力。这是必要的，因为在闪存过程中，FOTA 目标 ECU 的所有功能都应可用（如应用程序-SWC、BSWS 服务等）。
一般来说，在从远程端点接收 FOTA 镜像的过程中，由于服务问题，空中传输程序可能会随时中断。在这种情况下，无法保证所有数据包都能按顺序连续接收，甚至无法保证所有数据包都能在一个连接和/或驱动周期内接收。
5.2.3、DCM交互
Dcm模块具有许多FOTA程序可以使用的功能，例如识别，认证，安全机制，甚至流量控制和一致性功能。由于这些特性是开箱即用的，因此不需要重新实现其中的任何一个。
5.2.3.1、接口FOTA通过诊断服务(Dcm)的目标实例
Dcm模块在FOTA更新过程中需要完成的步骤列表如下:
·回读FOTA状态信息
·预装软件版本检查(由FOTA Master提供)
·切换到FOTA会话(用户会话)
·验证FOTA会话的访问控制
·安装阶段(数据从主服务器传输到客户端并进行刷新)
·验证阶段(特定于实现者，此处没有详细信息)
·预激活条件(如用户数据迁移，详见5.3章)
·激活阶段(车辆安全状态;ECU重置)
·软件激活后的版本检查(由FOTA Master负责)
5.2.3.2、FOTA使用的诊断服务
具体而言，完成FOTA程序所需的上述步骤将由以下Dcm服务涵盖:
·传输镜像数据：将从FOTA主机接收到的数据传输到FOTA目标。提出服务:请求下载/传输数据/传输出口(0x34/0x36/0x37)
·交换状态信息：读出当前的更新状态或FOTA目标ECU条件，并在主机需要时设置它们。提出服务:常规控制(0x31)，通过标识符读取/写入数据(0x22/0x2E)。
·额外的控制功能(例如激活、验证或回滚)：为了设置特定的状态，标志或执行额外需要的功能(例如设置激活标志或使“旧”分区无效):提出服务:常规控制(0x31)，通过标识符读取/写入数据(0x22/0x2E)。
5.2.3.3、FOTA诊断会话
由于 FOTA 程序可能不会影响 BSW 和应用程序级别的任何运行时执行和服务可用性，因此它应定义自己的诊断会话，在此背景下进行 FOTA 处理。这允许 Dcm 使用诊断协议抢占功能，该功能是 Dcm 规范的一部分（参见规范文档 [8]，第 7.3.4.16.3 章和本文档第 5.2.3.6 章）。
此外，应该使用Dcm模块指定的安全访问机制来保护对FOTA诊断会话的更改(参见[8])。
5.2.3.4、FOTA上下文中的缓冲区处理
一般情况下，FOTA 数据块由 FOTA 主控 ECU 使用 UDS（0x36 TransferData）进行传输。从 FOTA 目标的角度来看，DCM 模块将从通信栈接收数据块。根据 DCM 模块规范，内部缓冲区可按诊断协议（如 UDS、OBD…）进行配置。
由于 FOTA 进程应在 Dcm 内其自身的低优先级上下文中运行，因此应使用 DcmDslProtocolRow 配置容器定义使用 FOTA 的自身协议条目。这意味着需要引入第二个仅处理 FOTA 请求的 UDS 协议（使用 DcmDslProtocolPriority 定义的最低优先级），该协议应在 Dcm 模块内引用自己的数据缓冲区。
从 FOTA-Master ECU 接收的最大数据量取决于 FOTA 相关诊断协议处理专用的 DCM 配置参数 DcmDslBufferSize（详见 DCM 模块规范 [8]）。由于 DCM 服务 TransferData(0x36) 是作为回调函数实现的，因此 FOTA 处理器模块必须实现这样一个函数，以处理接收到的包含 FOTA 数据块的 DCM 数据缓冲区指针。
该函数调用由 Dcm 主函数循环触发，直至 FOTA 处理程序提供最终响应（OK/NOK）。在处理数据块期间，FOTA 处理程序应返回 “待处理 ”状态。
注意:确定FOTA数据块缓冲区的适当大小是高度特定于硬件和实现的。但最好不要超过Dcm模块中其他UDS协议配置的最大值。
5.2.3.5、FOTA上下文中的缓冲区处理
TransferData 调用仅作为操作系统异步调用的附加 FOTA 主函数的指示器。在该 FOTA 主函数中，将 FOTA 块传输到内存栈的实际处理过程已经完成。TransferData 服务调用也应等到 FOTA 主函数的 FOTA 块处理完成后才返回，并触发 Dcm 模块对 FOTA 主站的积极响应。这将由服务返回值 (Dcm_OpStatus) 显示，并由 FOTA 处理程序模块控制。
但是，在任何情况下，最后一次成功写入内存栈的数据都应反映在特定的 Dcm 服务任务中（如使用 DID）。
5.2.3.6、抢占FOTA协议
如果 Dcm 模块收到更高的协议请求而发生抢占，则会立即停止当前的 FOTA 处理，并首先处理新的请求。可以使用配置容器 DcmDslCallbackDCMRequestService 在 Dcm 中为每个协议配置抢占时的回调函数。一旦收到协议抢占，就会创建对此处定义的函数的调用。在执行此调用时，应进行额外调整，以确保 FOTA 程序的状态一致且可恢复。
一旦 FOTA 会话因抢占而中断，将不会有任何信息传输到 FOTA 主 ECU。用户在FOTA目标ECU的Dcm模块中定义的通知工作，以通知FOTA主控单元任何进程中断/抢占，不在本文件的范围内，因此完全由实施者决定。
不过，在本文件中，预计在发生抢占时，FOTA 主控 ECU 不会收到任何通知。这意味着 FOTA 主控 ECU 检测这种抢占的唯一方法是超时。超时时间一般取决于 ECU 的需要。超时后，FOTA 主控 ECU 需要重新建立并重新启动 FOTA 进程。
5.2.3.7、恢复被抢先的 FOTA 程序
假设 FOTA 目标 ECU 方面的协议抢占已经完成，而 FOTA 主 ECU 在处理最后提供的 FOTA 块时发生超时。从 FOTA 主控 ECU 的角度来看，超时仅发生在 UDS 协议层面，但由于协议限制，FOTA 目标 ECU 不会提供有关数据块处理状态的进一步信息。因此，无法确定 FOTA 目标 ECU 是否已完全接收到最后一个数据块并仍可在后台处理，或者是否需要在重新初始化后重新发送整个数据块。
FOTA 主ECU可使用FOTA专用Dcm服务作业与FOTA目标ECU交换所需信息，以恢复被抢占的FOTA程序，例如：“FOTA目标ECU”：
·当前处理状态(详见5.2.1.1章节)
·最后一个数据块的编程状态
·最后一次成功编程的地址
·最后一个块id
恢复策略由执行者决定，是始终在最后一次成功传输数据块后恢复（FOTA 主设备专用），还是与 FOTA 目标 ECU 交换最后一次成功写入的位置。一旦交换了这些信息和所有其他必要信息，FOTA 流程将在指定位置继续进行。
虽然 FOTA 流程的启动由 FOTA 主 ECU 触发，但镜像数据的一般流程（安装步骤，另见第 3.3.3 章）由 FOTA 目标 ECU 控制。由于 FOTA 主控 ECU 只能通过 UDS 提供 FOTA 图像数据，因此 Dcm 从 FOTA 目标 ECU 发送的返回代码表示可以接收数据块。如果通信终止（例如，由于协议抢占），FOTA 主站侧的超时表示通信中断。FOTA 主站和目标 ECU 重新同步后，根据 FOTA 目标 ECU 提供的状态信息（如 DID 或 RID 结果），FOTA 程序可以继续进行。
5.2.3.8、期望的 FOTA 特定诊断服务
与 FOTA 相关的信息交换和特征触发的拟议方法：
RID:校验、激活、取消、回滚、预编程检查、安装后检查、激活后检查，使用0x31服务。
DID：最后以此写入FOTA镜像的内存地址、获取安装版本信息、其他特定于实现的信息交换
5.3、迁移场景
这一章涵盖了迁移场景的各个方面，它处理了在运行时使用和可能修改的特定于用户或应用程序的数据的移植。有关过程和受影响组件的更多细节将在第2.1章和5.1.1.3章中描述。在AUTOSAR中，NvM BSW模块负责所有可修改的用户和应用程序数据(参见规范文档[7])。
一般的前提条件是不要扩展NvM模块已经提供的任何特性或功能。除了NvM模块(或任何其他BSW模块)之外，所需的所有功能都应由FOTA Handler模块实例或FOTA主ECU实现(详见5.1.2章)。
迁移场景涉及的主要任务是处理随FOTA-Image附带的更改的数据模型(参见第3.2.3章)。这意味着必须定义一种机制，在通过FOTA更新过程将分区切换到更新后的分区之前，将“旧”数据模型迁移到“新”数据模型。
由于NvM模块提供了创建、删除和移动NV数据块的功能，因此应该使用这些功能。
5.4、接口附加功能
在实现FOTA期间，应考虑AUTOSAR提供的其他功能。但是，本文档不描述如何使用、实现或实现这些特性。有关详细信息，请参阅相关的AUTOSAR规范文档。
5.4.1、安全特性
在实现FOTA时应考虑AUTOSAR提供和支持的安全特性。这些可以是:
·从FOTA主站到FOTA目标站的加密传输
·解密加密的fota镜像
·加密flash中的新数据
·从Dcm到内存堆栈的加密传输
·支持HSM(硬件安全模块)特性
5.4.2、安全功能
为了避免FOTA主ecu和FOTA目标ecu之间的通信错误，应该始终考虑使用AUTOSAR提供的端到端保护机制。
5.5、错误处理
一般来说，所有与FOTA相关的错误和恢复操作都应由FOTA主ECU完成或至少控制。FOTA 主控 ECU、通信栈或诊断栈未涉及的所有错误处理都是针对具体实施的。本文件不涉及这些具体实施错误。
5.6、序列图
本章将介绍相关的序列图。它们从 FOTA 目标的角度展示了所有必要模块和实例之间的互动。这些受影响的实例（至少）包括
·FOTA Master (ECU)
·Diagnostics stack (Dcm)
·FOTA Handler module (CDD)
·Program memory stack (Low-level Memory Driver)
注意：请记住，本章列出的序列图只是建议，尚未固定。功能的更改或扩展由实施者决定。
有关 FOTA 主设备和 FOTA 目标设备之间交换的状态信息和其他数据的详情，请参阅第 5.2.3.8 章。
5.6.1、(重新)初始化FOTA过程
FOTA 目标的初始化（以及因 FOTA 程序中断或被抢占而重新初始化）序列涉及以下组件：
·FOTA Master (ECU)
·Dcm (FOTA Target ECU)
FOTA 程序的初始化过程始终保持不变，无论更新是首次触发还是因中断（如驾驶周期改变）或抢占（更高优先级的诊断协议请求）而恢复。使用 FOTA 特定诊断服务工作进行的信息交换应指出在哪个位置应在哪个位置恢复安装程序。
5.6.2、FOTA数据块的处理
FOTA更新过程中的安装顺序会影响以下组件:
·FOTA Master (ECU)
·Dcm (FOTA Target ECU)
·FOTA Handler module (CDD)
FOTA数据块的数据传输由FOTA Master中心实例触发和控制。Dcm模块接收Dcm RAM缓冲区中的数据块。这个RAM缓冲区然后被转发到FOTA处理器模块实现，在那里它将被处理。
在UCM主ECU和FOTA目标ECU之间传输单个FOTA块的安装序列。对每个必要的FOTA块执行此序列。
本文档中描述的解决方案应在由回调签名提供的Dcm缓冲区上工作。由于包含FOTA数据块的Dcm缓冲区由FOTA Handler模块独占访问，因此即使在多次诊断协议更改中，缓冲区有效载荷也可以保持一致。因此，FOTA数据块的Dcm缓冲区被FOTA处理程序阻塞，直到它被完全处理。在处理FOTA数据块期间，Dcm模块返回一个待处理状态，该状态向FOTA主ECU指示处理活动，一旦FOTA数据块被完全处理，由Dcm模块触发的TransferData服务调出函数将返回一个积极的响应。
5.6.3、恢复被中断/抢占的FOTA程序
为了恢复被中断或抢占的FOTA程序，需要重新初始化FOTA诊断会话和安全访问（如5.6.1所述）。使用FOTA特定诊断服务作业（详情请参见第5.2.3.8节）应返回在给定位置恢复FOTA程序所需的所有信息。重新初始化后，FOTA 程序将按照 5.6.2 中所述的相同顺序进行。
5.6.4、激活成功flash的fota镜像
由于新安装的SW映像的激活序列主要在引导加载程序上下文中完成，这超出了AUTOSAR的范围，因此没有列出序列图。
激活过程请参见5.2.1.3。
5.6.5、FOTA程序回滚
由于回滚到先前活动的SW映像(n-1)的序列主要是在引导加载程序上下文中完成的，这超出了AUTOSAR的范围，因此没有列出序列图。回退过程请参见5.2.1.4。
6、参考资料
[1] Specification of Update and Configuration Management
AUTOSAR_AP_SWS_UpdateAndConfigurationManagement
[2] Requirements on Update and Configuration Management
AUTOSAR_AP_RS_UpdateAndConfigurationManagement
[3] Requirements on Firmware Over-The-Air
AUTOSAR_CP_RS_FirmwareOverTheAir
[4] Specification of Bulk NvData Manager
AUTOSAR_CP_SWS_BulkNvDataManager
[5] Glossary
AUTOSAR_FO_TR_Glossary
[6] Unified diagnostic services (UDS) – Part 1:Application layer (Release 2013-03)https://www.iso.org
[7] Specification of NVRAM Manager
AUTOSAR_CP_SWS_NVRAMManager
[8] Specification of Diagnostic Communication Manager
AUTOSAR_CP_SWS_DiagnosticCommunicationManager