BootLoader升级知识点001:OTA在线升级技术之-AUTOSAR FOTA升级流程与关注点解析。

目录

1、概述

1.1、动机

1.2、范围

1.3、通用用例

1.4、本文件的限制

2、假定和约束

2.1、内存栈的必备条件

2.2、FOTA Master实例的实现

2.2.1、进一步阅读

3、术语

3.1、缩略语

3.1.1、未在TR_Glossary中列出的缩略词

3.2、系统组件术语

3.2.1、FOTA 目标(FOTA Target)

3.2.2、FOTA主机(FOTA Master)

3.2.3、FOTA镜像(FOTA Image)

3.2.4、后端

3.2.5、数据块

3.3、流程术语

3.3.1、更新

3.3.2、下载

3.3.3、安装

3.3.4、校验

3.3.5、激活

3.3.6、回滚

4、需求

5、详细技术方案

5.1、功能与架构对象

5.1.1、FOTA Target ECU

5.1.1.1、FOTA 处理器模块的功能说明

5.1.1.12、DCM

5.1.1.3、Nv Data

5.1.1.4、OTA镜像类型

5.1.2、FOTA Master (UCM-Master)

5.1.3、后端

5.2、FOTA步骤

5.2.1、FOTA处理程序模块

5.2.1.1、内部FOTA状态

5.2.1.2、安装

5.2.1.3、激活(切换分区)

5.2.1.4、回滚

5.2.1.5、取消

5.2.1.6、使“旧”运行时分区无效

5.2.2、FOTA Master

5.2.3、DCM交互

5.2.3.1、接口FOTA通过诊断服务(Dcm)的目标实例

5.2.3.2、FOTA使用的诊断服务

5.2.3.3、FOTA诊断会话

5.2.3.4、FOTA上下文中的缓冲区处理

5.2.3.5、FOTA上下文中的缓冲区处理

5.2.3.6、抢占FOTA协议

5.2.3.7、恢复被抢先的 FOTA 程序

5.2.3.8、期望的 FOTA 特定诊断服务

5.3、迁移场景

5.4、接口附加功能

5.4.1、安全特性

5.4.2、安全功能

5.5、错误处理

5.6、序列图

5.6.1、(重新)初始化FOTA过程

5.6.2、FOTA数据块的处理

5.6.3、恢复被中断/抢占的FOTA程序

5.6.4、激活成功flash的fota镜像

5.6.5、FOTA程序回滚

6、参考资料


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

  • 10
    点赞
  • 16
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

剑从东方起

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值