[.小白一枚.]Autosar_Bootloader学习笔记_1

1、术语和定义

1.1 BootLoader 

        在 ECU 非易失性存储器中独立存在的软件，用于应用程序代码的更新。当上电或复位时，ECU从该功能中启动。

1.2 Flashdriver

        用于对控制器的 FLASH 存储空间进行擦除和写入。

在应用程序正常运行时，需防止应用程序被擦除或者重新，因此，ECU需要采用软件互锁机制， 即用于编程的内存驱动并不是存储在ECU的永久性存储器中，而是在下载过程中下载到ECU的RAM中。下载完成后，驱动代码将从ECU RAM缓冲区彻底移除。

1.3 PBL

        Primary BootLoader：主引导加载程序，其中包含ECU启动软件，并因存储在受保护的永久存储器中，以消除意外擦除的可能性

1.4 SBL

        Secondary BootLoader：二级引导加载程序，是一个可下载的软件模块，其中包括擦除和写入闪存的例程。它与flash序列一起下载，以确保正常操作期间ECU不存在擦除和写入例程。

1.5 Logical Block 

        逻辑块用于将物理内存划分为单独的可写区域，例如application and calibration block；这些块可以单独下载和验证。逻辑块不能相互重叠，但允许在一个逻辑块中有间隙。

2、Uds（ISO 14229）

2.1 0x34 RequestDownload

2.1.1 请求格式

        客户端使用requestDownload服务启动从客户端到服务器的数据传输(下载)。在服务器接收到requestDownload请求消息后，服务器应在发送积极响应消息之前采取所有必要的操作来接收数据。

2.1.1.1 dataFormatIdentifier

• 高位表示 “ compressionMethod ” 压缩方式
• 低位表示“ encryptingMethod ” 加密

0x00表示不使用 CompressionMethod 或 cryptoningMethod，非0x00值由主车厂定义

2.1.1.2 addressAndLengthFormatIdentifier

• bit 7-4：memorySize 的参数字节数 ；
• bit 3-0：memoryAddress 的参数字节数

memorySize ：使用此参数来比较memorySize 和 TransferData 服务期间传输的数据总量 

memoryAddress ：写入数据的服务器内存的起始地址 

2.1.2 正响应

 2.2 0x35 RequestUpload

        客户端请求从服务器到客户端的数据传输。服务器收到requestUpload请求消息后，服务器应采取所有必要的措施在发送肯定响应消息之前发送数据。

（请求格式和响应同0x34）

2.2.1 请求格式

 2.2.2 正响应

2.3 0x36  TransferData

        客户端使用TransferData服务将数据从客户端传输到服务器(下载)或从服务器传输到客户端(上传)。 数据传输方向由前面的RequestDownload或RequestUpload服务定义。

        如果客户端发起了RequestDownload，则要下载的数据包含在TransferData请求消息中的参数transferRequestParameter中。如果客户端发起了RequestUpload，则要上传的数据包含在TransferData响应消息中的参数transferResponseParameter中。TransferData服务请求包括一个blockSequenceCounter，以便在多个TransferData请求的序列中，如果TransferData服务失败，可以改进错误处理。当接收到RequestDownload (Ox34)或RequestUpload (Ox35)请求消息时，服务器的blockSequenceCounter应该初始化为1。这意味着在RequestDownload (Ox34)或RequestUpload (Ox35)请求消息之后的第一个TransferData (Ox36)请求消息以1的blockSequenceCounter开始。

2.3.1 请求格式

        blockSequenceCounter 参数值从 0x01开始，第一个 TransferData 请求位于RequestDownload 服务或 RequestUpload 服务之后。对于每个后续的 TransferData 请求，其值将增加 1。当值增加到 0xFF 时，blockSequenceCounter 值滚动并从 0x00 开始并带有下一个TransferData 请求消息。
规范中有以下四种情况：

1. 服务器正确接收并处理了传输数据下载数据的请求，但是肯定消息未到达客户端，则客户端重新发送相同的请求，服务器接收到重复的请求，立即发送肯定响应
2. 服务器没有正确接收下载数据请求，客户端重复发送，服务器处理此请求并发送肯定响应
3. 服务器正确接收并处理了传输数据的上传数据请求，但是肯定消息未到达客户端，服务器将收到重复的 TransferData 请求，并可以根据包含的 blockSequenceCounter 确定重复此TransferData 请求。服务器将立即发送肯定响应消息，再次访问其内存中先前提供的数据。
4. 服务器中未正确接收上传数据的 TransferData 请求，则服务器将不会发送肯定响应消息。服务器将接收到重复的 TransferData 请求，并可以基于所包含的blockSequenceCounter 确定这是新的 TransferData。服务器将处理该服务并发送肯定响应消息。

2.3.2 正响应

2.4 0x37  RequestTransferExit

        客户端请求终止数据传输（上传和下载）。

2.4.1 请求格式

参数 transferRequestParameterRecord 记录包含服务器支持数据传输所需的参数。

2.4.2 正响应

3、重编程ECU通用需求

1、概述

1）所有支持应用程序刷写的ECU，应当包含Bootloader软件。在正常运行过程中，执行的是应用软件和应用数据。仅当应用软件无效，或者要求对此ECU进行升级的时候，Bootloader软件才被激活。

2）应用软件、标定数据、网络配置数据及资源数据可以一起下载，也可以相互独立下载。

3）在ECU应用程序刷写过程中，因故障导致刷写失败，当故障消失后，ECU应能按本规范定义的刷 写流程重新刷写。

4） 数据传输过程中（36服务） ，如果某组传输数据的请求在规定时间内未得到ECU的响应，诊断 设备需在S3server超时前补发一次这组数据， ECU应按照ISO 14229-1中36服务的要求，正确处理相关 数据。

2、电压要求

        当ECU进行刷写时，ECU供电电压应保证稳定，一般是在9-16V之间能保证刷写正常进行。

3、安全访问

        ECU应该支持种子和密钥的安全特性，并且可以通过安全访问服务（27h）进入访问， 从而保护ECU免遭未授权的编程动作影响。

4、预编程条件

        ECU应该确保重编程的执行是处于安全状态。如果编程预条件不满足（如车辆或发动机正在运行等）， 那么重编程请求将被拒绝。具体的实现是通过一个“检查预编程条件“的例程控制激活检验。

5、完整性验证

        ECU 需要检查下载到存储器中的数据的完整性。当一个逻辑块下载后，将使用 “CRC32 ”算法验证当前逻辑块的所有数据字节是否被正确传输和写入。具体的实现是通过一个“检查完整性验证“的例程控制激活验证。

        当 ECU 接收到此服务请求时，Bootloader 将计算下载数据字节的 CRC32 值，并将计算结果 与诊断仪请求报文中发送的校验值进行比较。

        规范中会提供：多项式、初始值、异或值等支持验证算法

6、依赖性检查

a）所有逻辑块下载完成后，ECU应检查应用程序与引导加载程序是否兼容、应用软件与标定数据、 网络配置数据、资源数据等是否兼容。

b）ECU验证通过后，才能表明此次刷写成功，可以从BootLoader跳转到应用程序运行，否则不能跳转。验证方法由ECU供应商决定。

c) 对于有更高安全需求的ECU，必须在所有逻辑块下载后，下载数字签名文件，并在依赖性检测过程中完成数字签名认证。当文件下载后，ECU需要解密数字签名，对文件来源的可靠性进行认证。当ECU收到例程控制  “检查编程依赖性”  诊断服务的请求时，ECU将执行依赖性检查。

7、软件有效性验证

        ECU内部定义一个标志位，用于标识应用软件是否有效。

当 “完整性验证” 和 “依赖性检查” 都正确，ECU才设置标志位为有效。只有标志位为有效时，应用软件才可以运行。