上一期《FOTA技术专栏—UDS刷写》，笔者主要介绍了UDS刷写的基础知识，并阐释了刷写的业务流程。对于沿袭分布式电子电气架构的汽车，车内绝大多数控制器仅由MCU构成，网络通信方式也主要以CAN总线为主。对于此种配置，UDS刷写便足以支撑FOTA绝大部分的车端升级业务。
然而，在智能化、网联化的浪潮下，汽车俨然变成了一头庞大的、移动的数据猛兽，随时随地都在产生、发送、接收、存储和处理海量的数据。而拥有高算力芯片，大容量存储空间，并支持车载以太网等多种网络通信方式的智能控制器，逐渐在这种氛围中找到感觉，开始在车端崭露头角。
智能控制器基本采用Linux、Android等遵循POSIX标准的操作系统，其FOTA业务流程中的升级包下载和更新过程可由自身完成。基于此，在手机行业成熟应用并具有悠久历史的A/B升级开始在车端智能控制器的升级中得到了极大的关注和应用。
A/B升级首先在智能手机的Android系统上得到大量应用。
使用过Android系统手机，有刷机经历的同学对Android Recovery模式不会太陌生。进入该模式后，用户可对Android系统进行数据修改，数据备份、系统升级，以及恢复出厂设置等。
Android系统7.0之前，由于升级过程没有备份或冗余功能，如果在Recovery模式下搞小动作失败，同时还损坏了Recovery程序，那么你的手机不仅丧失升级的能力，而且无法再正常进入原来版本的系统。
所以在上个十年智能手机热潮之初，刷系统需要小心翼翼如履薄冰，刷机变砖喜闻乐见。路边不少专营越狱刷机的苍蝇小店根本无法保证刷机的可靠性，成功与否全靠运气。
在谷歌后续发布的Android系统版本中，开始采用A/B升级的方式取代Recovery刷写方式，官网中也称之为无缝升级（Seamless update）。
所谓A/B升级，是指在设备上开辟两个存储空间（A/B存储空间），每个存储空间上均安装有一个系统，其中一个系统处于激活使用状态，另外一个系统处于备用待命状态。在进行系统升级时候，可在激活的系统中对备用系统进行升级，升级完成重启后切换成新升级的系统。
随着谷歌在Android 11版本中要求设备采用强制A/B分区，A/B升级开始在广泛地被应用。A/B升级与传统Recovery升级相比拥有如下的优点：
（1）升级过程中可以保证有一个可以正常运行的系统，降低设备变砖的率几率。即使设备掉电或其他异常中断了升级过程，也能保证设备再次上电后系统可以正常运行。
（2）升级过程可以在系统运行时进行而不会中断用户正常使用。升级完成后用户仅需重启，且重启所用的时间不会超过常规重新启动所用的时间。
（3）如若升级失败导致刷写程序被损坏，用户可使用系统旧版本，并再次尝试升级。
（4）如果升级完成但无法启动，系统将回滚到旧分区，用户仍然可以正常使用系统，并继续尝试升级。
（5）升级包可以流式传输到A/B设备，意味设备无需在缓存分区上预留空间以存储升级包。
传统Recovery升级方式下的系统分区如下图所示：
以Linux操作系统为例对各分区含义进行说明，其他操作系统类似：
-
bootloader：存放用于引导Linux的bootloader，传统方式bootloader通过读取misc分区信息来决定是进入Linux主系统还是Recovery系统。A/B方式的bootloader通过特定的分区信息来决定是从slot A还是slot B启动。
-
boot：存放主系统的Linux kernel文件和用于挂载system和其他分区的ramdisk。
-
system：主系统分区，包括系统应用程序和库文件。
-
vendor：主系统分区，主要是包含开发厂商定制的一些应用和库文件，很多时候开发厂商也直接将这个分区的内容直接放入system分区。
-
userdata：用户数据分区，存放用户数据，包括用户安装的应用程序和使用时生成的数据。
-
cache：临时存放数据的分区，通常用于存放OTA的升级包。
-
recovery：存放传统Recovery系统的linux kernel文件和ramdisk。
-
misc：存放主系统和Recovery系统跟bootloader通信的数据。
对于A/B升级的系统而言，boot，system和vendor系统分区变为两套，使用了称为slot的分区，分别是slot A和slot B。同时不再需要cache和recovery分区，misc分区也是可选的。任何情况都有一个slot是活跃slot。bootloader下次启动时使用的slot，被标记为active属性。
每个slot都有一个可启动属性(bootable)，该属性用于表明设备可从相应slot启动。此外，每个slot还都有一个由用户空间设置的成功属性(successful)，仅当相应slot处于可启动状态时，该属性才具有相关性。被标记为成功的slot应该能够自行启动、运行和更新。
（1）正常情况。最常见的情形，例如设备下线时，A分区和B分区都可以成功启动并正确运行，所以两个分区都设置为bootable和successful，但由于是从B分区启动，所以只有B分区设置为active。
（2）升级中。系统正在从B分区运行，因此，B分区是可启动(bootable)且被标记为成功(successful)的活动分区。由于正在更新A分区，因此A分区被标记为不可启动(unbootable)。在此状态下，重启仍从slot B运行。
（3）升级完成。正在等待重新启动：系统正在从B分区运行，B分区可启动(bootable)且被标记为成功(successful)，A分区升级完成后，重启后需要从A分区启动被标记为active和bootable，但尚未验证成功，所以不能被标记为successful，bootloader应尝试从A分区启动。
（4）系统重启。设备重启后，bootloader检测到A分区为active，完成校验之后，A分区如能正确运行，应将slot A 标记为成功(successful)。对比第1个普通场景，A和B分区都设置为bootable和successful，但active从B分区切换到A分区。至此，B分区成功更新并切换到A分区，设备重新进入正常场景。
随着整车电子电气架构中出现越来越多的智能控制器，A/B升级在车辆的FOTA升级中愈发重要。而智能控制器升级后宕机导致整车功能不可使用是灾难性的，因此汽车FOTA升级相比于手机更注重升级的稳定性和鲁棒性。
例如某一智能控制器A分区激活，B分区升级成功后，B分区启动，A分区则变为B分区的备用分区，是否对当前的备用分区A进行分区同步，则是主机厂需要去根据实际情况考虑的。
（2） A分区为旧版本，已被验证是一个相对稳定的版本。如将A分区同步升级，A/B分区皆为新版本系统，如果新版本系统不稳定，则控制器无法切换至稳定系统运行。
如果选择将A分区保持在旧版本，例如本次升级任务后，A分区维持在V1.0的旧版本，B分区升级至V2.0的新版本，则会面临：
（1）下次有V3.0的升级任务时，需要指定待升级的分区（A或者B）；或者同时验证V1.0->V3.0和V2.0->V3.0，给升级任务和策略的制定带来一定的难度。
（2） 如果不指定升级的分区，则可能会导致分区版本的混乱，给FOTA的运营带来麻烦。
虽然A/B升级能够提高升级的健壮性和鲁棒性，增强用户体验。但是对设备的存储容量要求会比传统升级方式要大得多。随着智能控制器芯片和存储成本的日益高涨，成本问题同样需要主机厂仔细斟酌平衡。
下期，专栏会来到FOTA云端，讨论云端的服务架构。
初心 | 记录生而为人的证据，分享工农阶层原创作品，聚焦智能网联与人情冷暖。
声明 | 本文部分文字及图片资料取自网络，如有侵权，请联系平台进行修改或删除；文章属于作者本人，仅代表个人观点，不代表平台立场，如有不妥，也请联系平台修改或删除；本文不作任何商业用途。
原文始发于微信公众号（十一号组织）：FOTA技术专栏—A/B升级
