随着车载MCU性能和资源的提升，“A/B分区（Partition）”、“回滚策略”、“无感刷写”、“静默刷写”...这些概念已不再虚无缥缈，而是逐步走向落地，实现量产化。首先，得益于MCU级车载芯片资源的提升，不然，A/B分区也就无从谈起。有了A/B分区，静默刷写也就水到渠成了。虽然概念和目标是好的，但是，并不意味着开发会一帆风顺。本文，就A/B分区和回滚策略，聊一些实现需要思考的点。
1、A/B分区简述
什么是A/B分区系统呢？答：A分区或者B分区系统独立，两者之间可以相互切换的系统。那么，为什么需要这样的系统呢？答：在没有A/B功能之前，车辆控制器的刷写需要车辆停车，满足一定的安全刷写条件后，使用诊断仪或者其他上位机刷写。这一系列的操作，费时费力。为了最大程度的节省刷写时间，给用户更好的升级体验，静默刷写来了。而静默刷写建立的基础就是A/B功能，即：激活的分区，可以在车辆运行的过程中更新非激活分区。A/B分区示意如下：
相对单一系统的MCU，具有A/B分区系统的MCU，工作稳定性会更高，因为A/B系统有两套独立的系统，均可以独立运行，如果一套系统失效，可以回滚到另一个系统运行。示意如下：
虽然A/B系统可以降低控制器的失效率，但是，其缺点也很明显：需要两倍的资源。eg：传统系统，3M的Flash即可，如果具有A/B功能，则需要6M的Flash。当然，车规级MCU资源在不断的提高，资源已不再是瓶颈。
2、A/B实现过程中的问题思考
Q1：非激活分区完成更新以后，何时切换分区？
A1：非激活分区（A分区或者B分区）完成软件更新以后，需要在下次系统启动（一般需要MCU进行系统级复位）时，进行分区切换。
Q2：静默升级可以在车辆运行过程中完成吗？
A2：可以。为了实现无感升级，支持A/B功能的控制器应支持车辆行驶过程中的软件升级活动，即：支持升级非激活分区。而这一点，在软件实现中，应在空闲任务中进行升级，避免干扰激活分区内的正常软件运行行为。
Q3：回滚次数需要做限制吗？
A3：需要。思考这样一种工况：MCU上电或者复位，进入默认的A分区，但是，启动过程中发现A分区失效（比如：完整性检查失败）。为了安全，程序需要回滚到B分区启动，回滚进入B分区以后，程序再次启动，不巧的是：B分区的启动也失败了。如果不做回滚次数限制，A分区和B分区会无限循环的切换，所以，从启动失败的B分区再次回滚到启动失败的A分区是没有意义的。示意如下：
Q4：A/B分区均启动失败以后，应该如何处理？
A4：如果A/B分区均启动失败，程序应该进入诊断的编程会话（Programming Session），以便于程序可以被更新，避免控制器成为"板砖"，示意如下：
Q5：信息安全Core回滚失败，Host如果不知道曾经回滚过，会带来什么问题？
A5：解释一下这个问题。在具有信息安全的软件中，信息安全一般由一个独立的Core处理（eg：Security Core），信息安全有对应的软件程序。如果程序是级联校验启动，即：信息安全校验用户的Bootloader程序失败，进行程序回滚，由Partition A进入Partition B，在Partition B启动过程中，Security Core校验用户Bootloader程序成功，但是用户Bootloader程序（Host Core）校验用户Application程序失败，需要回滚吗？自然也没有回滚的必要。需要进入Programming Session，等待程序更新即可，如下所示：
但是，如上有一个点需要解决：用户的Bootloader程序怎么知道Security Core曾经回滚过？所以，在软件设计时，需要Security Core将自身回滚过的信息存储在Host Core也可访问的位置，以便于Host知道Security Core曾经回滚过，让Host Core不要再次回滚，否则，将会无限循环回滚。
Q6：信息安全Core校验用户Bootloader均失败，如何处理？
A6：Security Core在A分区校验用户Bootloader失败以后，回滚到B分区，在B分区再次校验用户的Bootloader程序，再次失败，此时，出于安全考虑，程序应该进入编程会话，等待升级，示意如下：
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
