论文部分内容阅读
摘要：智能汽车对于汽车电子控制单元（ECU）的升级非常频繁，需要从汽车中拆出ECU更新升级软件，该种操作会增加拆装风险和软件升级成本。基于统一诊断服务（UDS）的操作系统启动加载程序升级方法能够解决以上难题，利用UDS的上位机通过控制器局域网络总线连接升级，可以避免从智能汽车上拆卸ECU，为后续软件更新提供方便。该种升级方法也使软件的烧录流程统一规范，可以兼容不同ECU设备，方便不同厂商之间共同调试。
关键词：操作系统启动加载程序;统一诊断服务协议;控制器局域网络总线
中图分类号：TP311 文献标识码：A
文章编号：1009-3044（2021）27-0129-03
Abstract： Smart cars frequently upgrade their electronic control units （ECUs）. The ECU needs to be removed from the car to update the software. This operation increases the risk of disassembly and installation and the cost of software upgrades. The upgrade method of operating system boot loader based on Unified Diagnostic Service （UDS） can solve the above problems. Upgrade the upper computer using the UDS through the controller local area network bus connection. Removing the ECU from the smart car can be avoided. Provide convenience for subsequent software updates. This upgrade method also makes the software burning process a unified standard. It can be compatible with different ECU devices to facilitate joint debugging between different manufacturers
Key words： BootLoader; UDS agreement; CAN
1 背景
随着智能汽车的逐步推广和使用，汽车的各方面功能在不断增加，软件的更新周期开始变得越来越短，软件烧录的成本开始增高。控制器局域网络总线（CAN）作为汽车通信的主要方式，具有完善的通信标准，也为UDS服务和操作系统启动加载程序（BootLoader）提供可靠的保障。智能汽车通过CAN总线来部署实现软件升级，是一项低成本、高效、操作简单且被广泛利用的技术。
UDS统一诊断服务由ISO-14229系列标准定义[1]，是完善的国际标准协议。主机厂商和零部件生产商都会按照这种统一的标准进行生产。采用统一的诊断服务，使软件开发和硬件生产更加高效，能够降低生产开发周期。UDS也具有完善的安全服务流程，CAN具有可靠性的数据完整性机制。基于CAN和UDS服务的BootLoader升级方法使软件升级更新具有快速、可靠、易用、安全等特点。
2 BootLoader相关的UDS服务
2.1 诊断类型
虽然有很多服务，但是一般常用的有15种左右[2]。BootLoader一般涉及的诊断服务有0x10诊断会话控制，切换会话模式，0x11ECU复位操作。0x27解锁，用于解锁ECU安全限制。0x3E保持会话。0x2E数据的写入操作，诊断仪通过这个服务写入数据到ECU。0x22数据读取，主要读取ECU上面的内部数据。0x31例程控制、触发ECU执行操作。0x34请求下载，诊断仪向ECU烧写软件前的确认信息。0x36数据传输，来给ECU烧写数据。0x37请求退出。0x85啟动或者暂停DTC，0x28打开或者关闭CAN报文，0x85和0x28主要用于BootLoader烧写程序过程中减少带宽负载。
2.2 诊断会话
会话模式是汽车诊断很重要的状态机。每种会话形式，对应着差异的SID执行限制。常用的会话模式有三种，默认会话、编程会话、扩展会话[3]。ECU启动位于默认会话。ECU从默认切换到扩展，但是不能从默认跳转到编程。必须通过扩展切换到编程。
在BootLoader加载过程中会话的切换很重要。ECU开机后，启动Boot程序，通过判断软件更新的标志位，决定是否更新操作。不更新的话，会判断App段代码是否有效，然后执行App段代码。App段代码执行进入默认会话。需要一些读写操作时需要进入到扩展会话。刷写软件时，需要进入到编程会话。这时则有App地址段进入到Boot地址段代码，并切换编程状态，然后回复诊断仪（Tester）编程会话正响应，诊断仪本身具备UDS协议，可以扩展软件更新功能。
2.3 UDS服务
1）0x10诊断会话控制
ECU开机会进入到默认方式中，诊断仪需要进行BootLoader的85、28服务操作，需要扩展会话。诊断仪发送10 03使ECU进入到扩展会话。其中子服务 01表示默认、02表示编程、03表示扩展。
0x11ECU复位服务
11服务的主要目的是使ECU的某些操作生效，需要重启ECU。所以通过11服务来重启ECU。重启后ECU会进入到默认会话形式。 2）0x27安全访问
27服务主要用于向ECU写数据时安全解锁。一般写入等操作需要解锁ECU。安全认证需要如下操作：
①诊断仪向ECU传递获取种子的信息。
②ECU产生随机种子Seed向诊断仪传递。
③诊断仪通过获取到的Seed，在本地进行计算，得到一个key，然后发送给ECU。
④ECU拿到诊断仪发送的key与本地Seed计算得到的key进行比对。
⑤成功返回正响应，失败返回错误码。
3）0x28和0x85报文控制
28服务功能是启动/暂停报文传输，85服务功能是开关DTC存储功能，通常28和85都会一起使用[4]。在BootLoader进行烧录软件的时候，当28关闭时，由于收不到消息，ECU会存储大量的DTC，为了避免这种麻烦，通过28关闭报文，85关闭DTC。将通信带宽留给软件烧写，结束升级后恢复系统。
4）0x3E诊断连接
保持ECU与诊断仪处于连接状态，在没有数据传输时，一旦会话超时。会从其他状态进入到默认状态。3E服务就是为了维持状态。
0x22和0x2E数据操作
22服务是读数据操作，2E服务是写数据操作。使用两个字节来标识数据。例如十六进制的F187代表零件号。在BootLoader中通过22服务来读取App段和Boot段的判断标志位。2E服务可以标记写入人身份信息，也可以写VIN码等存储到EEPROM。
5）0x31例程控制
31来调用ECU内置的函数功能。在BootLoader中，我们通过31服务来进行清除Flash、对数据进行CRC校验，保证软件在烧写前的正确性。
6）0x34请求下载
ECU根据诊断仪传递的34消息，做好数据写入Flash的准备。做好地址校验准备。逻辑地址空间是否够用。当ECU返回给诊断仪正响应后，其中包含36传递一次的最大字节数。保证ECU对数据接收的可靠性。
7）0x36数据传输
当诊断仪接收到34服务的正响应后，诊断仪开始执行36服务进行数据传输操作。36服务中会包含表示数据块的计数。保证数据重组时的准确性。
8）0x37传输完成
在34与36没有出错的情况下，那么诊断仪发送37服务，会返回ECU的正响应77。倘若36执行失败，36没有全部发送完成，那么ECU会返回错误码NRC表示诊断序列执行错误。
3 BootLoader下载流程和Flash地址分配
3.1 BootLoader下载流程
BootLoader分为App段程序和Boot段程序，在App段程序更新过程中，如果出现错误，那么可以通过Boot段进行二次更新。可以避免ECU直接变成板砖。ECU上电先进入到Boot段程序，读取标志位，判断是否需要烧写软件。如果否，判断App段程序是否有效。有效则进入到App段程序。无效会切换Boot程序段默认状态。如果需要烧写程序，则进入下列步骤：
步骤1预编程：
在App段程序，默认开启循环发送3E服务。通过诊断仪发送10 03进入到扩展会话。通过85暂停DTC，之后28暂停报文。再切换到编程状态。进入到Boot代码段，ECU向诊断仪正响应。
步骤2主编程：
在Boot段程序中，回复完10 02的正响应后，读取DID标志位，获取软件更新相关的信息[5]。通过27服务解锁安全验证。2E写入身份信息，再通过31执行擦除Flash的App段相关信息。34服务请求下载数据。36服务开始传输数据。36传输完成后，通过37服务请求退出。然后31服务验证App段程序，11服务复位ECU。
步骤3后编程：
重启ECU后，进入到App段程序，10服务切换到03扩展会话，进行先28操作，再85操作打开数据报文和DTC。27服务进行安全校验[6]。然后2E服务写入编程相关信息到ECU。10 01退回到默认会话。
3.2 Flash地址分配表
BootLoader执行的MCU是NXP的MPC5744P一款32位的控制器。擁有约2.5MB的Flash，可以满足App段和Flash段的地址划分，还有EEPROM方便参数长期存储。
MPC5744P的Flash分类方式是EEPROM、Small、Medium、Large Flash，其中Small Flash的起始地址是0x00F9 8000，作为BOOT段的起始地址分配，App段从Large Flash的起始地址0x0100 0000开始分配。Boot段分配352KB后的Medium段的64kb用于参数存储。
4 软件升级测试
测试使用的诊断仪只实现了UDS烧录功能，本烧写上位机是通过QT编写，这里实现了UDS软件升级的一键下载操作，执行UDS下载流程，调试信息打印，刷写数据显示，以及手动重启ECU，整个升级过程可以通过进度条查看。
刷写测试时，STmin设置为0ms，BS为2050kb。通过对BootLoader的刷写不同大小的文件进行软件测试，刷写测试可以顺利完成。通过BootLoader对不同文件大小刷写的稳定性测试，我们可以得到软件的刷写效率。STmin与BS测试时，我们采用同一个文件，进行测试时间。STmin和BS共同影响软件的传输速度。但是随着STmin的降低，BS的增大。系统的稳定性就会下降。STmin越小传输速度越快，BS越大传输速度越快。但是推荐将STmin设置为1ms，BS设置为512kb。在保证稳定性的情况下，达到更快的传输速度。
5 结束语
本设计，实现了通过UDS服务流程的软件烧写方式，统一了汽车ECU软件的更新流程，为汽车后续升级降低了成本，提高了产品更新的效率。UDS作为汽车必要的功能之一，也为汽车故障检测提供了高效的测试方式。实现基于CAN总线和UDS服务BootLoader软件设计后，通过TBox提供的网络服务与CAN总线通信，可以利用空中下载技术实现远程软件更新操作，进一步降低用户更新成本，提高软件更新效率。随着汽车智能化的发展，未来汽车的软件更新周期会越来越短，移动化的远程空中下载技术会越来越受欢迎。
参考文献：
[1] 马学文，朱名日，程小辉.嵌入式系统中Bootloader的设计与实现[J].计算机工程，2005，31（7）：96-97，196.
[2] 余莹莹，王法龙，杨卓，等.基于UDS协议的CAN BootLoader的开发与验证[J].客车技术与研究，2020，42（6）：32-35.
[3] 袁帅，李瑜，苗坤怡，等.基于UDSonCAN的BootLoader上位机开发[J].汽车实用技术，2020（15）：97-99.
[4] 马建辉，于良杰，王勇，等.基于UDS on CAN的Bootloader设计[J].单片机与嵌入式系统应用，2019，19（3）：7-9.
[5] 张成雨，杨朝阳，单志文.基于CAN总线的车载应用Bootloader设计[J].湖北汽车工业学院学报，2017，31（4）：67-70，74.
[6] 王琦.基于CAN总线的Bootloader研究与实现[D].南京：南京邮电大学，2016.
【通联编辑：谢媛媛】
关键词：操作系统启动加载程序;统一诊断服务协议;控制器局域网络总线
中图分类号：TP311 文献标识码：A
文章编号：1009-3044（2021）27-0129-03
Abstract： Smart cars frequently upgrade their electronic control units （ECUs）. The ECU needs to be removed from the car to update the software. This operation increases the risk of disassembly and installation and the cost of software upgrades. The upgrade method of operating system boot loader based on Unified Diagnostic Service （UDS） can solve the above problems. Upgrade the upper computer using the UDS through the controller local area network bus connection. Removing the ECU from the smart car can be avoided. Provide convenience for subsequent software updates. This upgrade method also makes the software burning process a unified standard. It can be compatible with different ECU devices to facilitate joint debugging between different manufacturers
Key words： BootLoader; UDS agreement; CAN
1 背景
随着智能汽车的逐步推广和使用，汽车的各方面功能在不断增加，软件的更新周期开始变得越来越短，软件烧录的成本开始增高。控制器局域网络总线（CAN）作为汽车通信的主要方式，具有完善的通信标准，也为UDS服务和操作系统启动加载程序（BootLoader）提供可靠的保障。智能汽车通过CAN总线来部署实现软件升级，是一项低成本、高效、操作简单且被广泛利用的技术。
UDS统一诊断服务由ISO-14229系列标准定义[1]，是完善的国际标准协议。主机厂商和零部件生产商都会按照这种统一的标准进行生产。采用统一的诊断服务，使软件开发和硬件生产更加高效，能够降低生产开发周期。UDS也具有完善的安全服务流程，CAN具有可靠性的数据完整性机制。基于CAN和UDS服务的BootLoader升级方法使软件升级更新具有快速、可靠、易用、安全等特点。
2 BootLoader相关的UDS服务
2.1 诊断类型
虽然有很多服务，但是一般常用的有15种左右[2]。BootLoader一般涉及的诊断服务有0x10诊断会话控制，切换会话模式，0x11ECU复位操作。0x27解锁，用于解锁ECU安全限制。0x3E保持会话。0x2E数据的写入操作，诊断仪通过这个服务写入数据到ECU。0x22数据读取，主要读取ECU上面的内部数据。0x31例程控制、触发ECU执行操作。0x34请求下载，诊断仪向ECU烧写软件前的确认信息。0x36数据传输，来给ECU烧写数据。0x37请求退出。0x85啟动或者暂停DTC，0x28打开或者关闭CAN报文，0x85和0x28主要用于BootLoader烧写程序过程中减少带宽负载。
2.2 诊断会话
会话模式是汽车诊断很重要的状态机。每种会话形式，对应着差异的SID执行限制。常用的会话模式有三种，默认会话、编程会话、扩展会话[3]。ECU启动位于默认会话。ECU从默认切换到扩展，但是不能从默认跳转到编程。必须通过扩展切换到编程。
在BootLoader加载过程中会话的切换很重要。ECU开机后，启动Boot程序，通过判断软件更新的标志位，决定是否更新操作。不更新的话，会判断App段代码是否有效，然后执行App段代码。App段代码执行进入默认会话。需要一些读写操作时需要进入到扩展会话。刷写软件时，需要进入到编程会话。这时则有App地址段进入到Boot地址段代码，并切换编程状态，然后回复诊断仪（Tester）编程会话正响应，诊断仪本身具备UDS协议，可以扩展软件更新功能。
2.3 UDS服务
1）0x10诊断会话控制
ECU开机会进入到默认方式中，诊断仪需要进行BootLoader的85、28服务操作，需要扩展会话。诊断仪发送10 03使ECU进入到扩展会话。其中子服务 01表示默认、02表示编程、03表示扩展。
0x11ECU复位服务
11服务的主要目的是使ECU的某些操作生效，需要重启ECU。所以通过11服务来重启ECU。重启后ECU会进入到默认会话形式。 2）0x27安全访问
27服务主要用于向ECU写数据时安全解锁。一般写入等操作需要解锁ECU。安全认证需要如下操作：
①诊断仪向ECU传递获取种子的信息。
②ECU产生随机种子Seed向诊断仪传递。
③诊断仪通过获取到的Seed，在本地进行计算，得到一个key，然后发送给ECU。
④ECU拿到诊断仪发送的key与本地Seed计算得到的key进行比对。
⑤成功返回正响应，失败返回错误码。
3）0x28和0x85报文控制
28服务功能是启动/暂停报文传输，85服务功能是开关DTC存储功能，通常28和85都会一起使用[4]。在BootLoader进行烧录软件的时候，当28关闭时，由于收不到消息，ECU会存储大量的DTC，为了避免这种麻烦，通过28关闭报文，85关闭DTC。将通信带宽留给软件烧写，结束升级后恢复系统。
4）0x3E诊断连接
保持ECU与诊断仪处于连接状态，在没有数据传输时，一旦会话超时。会从其他状态进入到默认状态。3E服务就是为了维持状态。
0x22和0x2E数据操作
22服务是读数据操作，2E服务是写数据操作。使用两个字节来标识数据。例如十六进制的F187代表零件号。在BootLoader中通过22服务来读取App段和Boot段的判断标志位。2E服务可以标记写入人身份信息，也可以写VIN码等存储到EEPROM。
5）0x31例程控制
31来调用ECU内置的函数功能。在BootLoader中，我们通过31服务来进行清除Flash、对数据进行CRC校验，保证软件在烧写前的正确性。
6）0x34请求下载
ECU根据诊断仪传递的34消息，做好数据写入Flash的准备。做好地址校验准备。逻辑地址空间是否够用。当ECU返回给诊断仪正响应后，其中包含36传递一次的最大字节数。保证ECU对数据接收的可靠性。
7）0x36数据传输
当诊断仪接收到34服务的正响应后，诊断仪开始执行36服务进行数据传输操作。36服务中会包含表示数据块的计数。保证数据重组时的准确性。
8）0x37传输完成
在34与36没有出错的情况下，那么诊断仪发送37服务，会返回ECU的正响应77。倘若36执行失败，36没有全部发送完成，那么ECU会返回错误码NRC表示诊断序列执行错误。
3 BootLoader下载流程和Flash地址分配
3.1 BootLoader下载流程
BootLoader分为App段程序和Boot段程序，在App段程序更新过程中，如果出现错误，那么可以通过Boot段进行二次更新。可以避免ECU直接变成板砖。ECU上电先进入到Boot段程序，读取标志位，判断是否需要烧写软件。如果否，判断App段程序是否有效。有效则进入到App段程序。无效会切换Boot程序段默认状态。如果需要烧写程序，则进入下列步骤：
步骤1预编程：
在App段程序，默认开启循环发送3E服务。通过诊断仪发送10 03进入到扩展会话。通过85暂停DTC，之后28暂停报文。再切换到编程状态。进入到Boot代码段，ECU向诊断仪正响应。
步骤2主编程：
在Boot段程序中，回复完10 02的正响应后，读取DID标志位，获取软件更新相关的信息[5]。通过27服务解锁安全验证。2E写入身份信息，再通过31执行擦除Flash的App段相关信息。34服务请求下载数据。36服务开始传输数据。36传输完成后，通过37服务请求退出。然后31服务验证App段程序，11服务复位ECU。
步骤3后编程：
重启ECU后，进入到App段程序，10服务切换到03扩展会话，进行先28操作，再85操作打开数据报文和DTC。27服务进行安全校验[6]。然后2E服务写入编程相关信息到ECU。10 01退回到默认会话。
3.2 Flash地址分配表
BootLoader执行的MCU是NXP的MPC5744P一款32位的控制器。擁有约2.5MB的Flash，可以满足App段和Flash段的地址划分，还有EEPROM方便参数长期存储。
MPC5744P的Flash分类方式是EEPROM、Small、Medium、Large Flash，其中Small Flash的起始地址是0x00F9 8000，作为BOOT段的起始地址分配，App段从Large Flash的起始地址0x0100 0000开始分配。Boot段分配352KB后的Medium段的64kb用于参数存储。
4 软件升级测试
测试使用的诊断仪只实现了UDS烧录功能，本烧写上位机是通过QT编写，这里实现了UDS软件升级的一键下载操作，执行UDS下载流程，调试信息打印，刷写数据显示，以及手动重启ECU，整个升级过程可以通过进度条查看。
刷写测试时，STmin设置为0ms，BS为2050kb。通过对BootLoader的刷写不同大小的文件进行软件测试，刷写测试可以顺利完成。通过BootLoader对不同文件大小刷写的稳定性测试，我们可以得到软件的刷写效率。STmin与BS测试时，我们采用同一个文件，进行测试时间。STmin和BS共同影响软件的传输速度。但是随着STmin的降低，BS的增大。系统的稳定性就会下降。STmin越小传输速度越快，BS越大传输速度越快。但是推荐将STmin设置为1ms，BS设置为512kb。在保证稳定性的情况下，达到更快的传输速度。
5 结束语
本设计，实现了通过UDS服务流程的软件烧写方式，统一了汽车ECU软件的更新流程，为汽车后续升级降低了成本，提高了产品更新的效率。UDS作为汽车必要的功能之一，也为汽车故障检测提供了高效的测试方式。实现基于CAN总线和UDS服务BootLoader软件设计后，通过TBox提供的网络服务与CAN总线通信，可以利用空中下载技术实现远程软件更新操作，进一步降低用户更新成本，提高软件更新效率。随着汽车智能化的发展，未来汽车的软件更新周期会越来越短，移动化的远程空中下载技术会越来越受欢迎。
参考文献：
[1] 马学文，朱名日，程小辉.嵌入式系统中Bootloader的设计与实现[J].计算机工程，2005，31（7）：96-97，196.
[2] 余莹莹，王法龙，杨卓，等.基于UDS协议的CAN BootLoader的开发与验证[J].客车技术与研究，2020，42（6）：32-35.
[3] 袁帅，李瑜，苗坤怡，等.基于UDSonCAN的BootLoader上位机开发[J].汽车实用技术，2020（15）：97-99.
[4] 马建辉，于良杰，王勇，等.基于UDS on CAN的Bootloader设计[J].单片机与嵌入式系统应用，2019，19（3）：7-9.
[5] 张成雨，杨朝阳，单志文.基于CAN总线的车载应用Bootloader设计[J].湖北汽车工业学院学报，2017，31（4）：67-70，74.
[6] 王琦.基于CAN总线的Bootloader研究与实现[D].南京：南京邮电大学，2016.
【通联编辑：谢媛媛】