由于智能汽车集中化趋势，导致在网络连接上已经由传统的低带宽Can网络升级转换到高带宽以太网网络为主的升级过程。为了提升车辆升级能力，基于为车主提供持续且优质的体验和服务，需要在现有系统基础（由原始只对车机上传统的 ECU 进行升级，转换到实现以太网增量升级的过程）之上开发一套可兼容现有 OTA 系统的全新 OTA 服务系统，实现对整车软件、固件、服务的 OTA 升级能力，从而最终提升用户的使用体验和服务体验。
整车软件升级是通过OTA技术，是对车载娱乐、导航、人机互动等应用软件及转向、制动、车身控制等固件进行升级。整车OTA升级包是由升级对象中可升级ECU的升级包组合而成。对于整车OTA类型，主要分为两类，FOTA（Firmware-over-the-air）和SOTA（Software-over-the-air），两者均为主机厂重点关注及逐步落地的领域，可适应不同场景的OTA需求。
FOTA（又称为移动终端空中下载软件升级技术），通过给车辆控制器下载安装完整的固件镜像，来实现系统功能完整的升级更新。FOTA涉及控制器相关策略核心功能的一个完整的系统性更新，对整车性能影响较大，升级过程对时序、稳定性、安全性要求极高，同时升级前置条件包括挡位、电量、车速等要求，升级过程一般不支持点火用车。
FOTA通过给车辆控制器下载安装完整的固件镜像，来实现系统功能完整的升级更新。例如升级车辆的智驾系统，让驾驶员享受越来越多的辅助驾驶功能；升级车辆的座舱系统，提高驾驶员疲劳检测的准确率；升级车辆的制动系统，提升车辆的制动性能。
SOTA实际可看成一种软件可售策略的核心需求，他是通过给车辆控制器安装“增量包”，来实现控制器功能的一个“增量”更新，一般应用于娱乐系统和智驾系统。例如更换多媒体系统操作界面，优化仪表盘显示风格，更新娱乐主机里的地图程序时，用到的都是SOTA升级方式。SOTA涉及控制器应用层一个小范围的功能局部更新，对整车性能影响较小，升级前置条件要求较低。SOTA的增量更新策略，可以大幅减小升级包文件大小、从而节约网络流量和存储空间。
这里我们举例说明FOTA和SOTA分别如何在智能驾驶升级中进行有效定义。
例如升级智能驾驶汽车系统，为了让驾驶员享受越来越多的辅助驾驶功能；通常根据功能开发难度、时间长度来确定对阶段性功能的不断更新迭代（包含从低级别功能向高级别功能进阶的软件更迭）。同时，过程中需要升级车辆的座舱系统，提高驾驶员疲劳检测的准确率；升级智能驾驶车辆的关联子系统（如制动、转向系统等模块），提升车辆的制动性能。
对于整个OTA升级而言，从下至上主要包括如下三方面：升级对象、OTA管理器、OTA云服务平台。自动驾驶域控制器与座舱域控制器通过以太网连接，升级协议一般为常用的DoIP，除开域控本身外，升级过程还包括高精定位模块升级，传感器升级。对于由以太网连接的摄像头而言，其升级过程主要是通过主域控端所搭载的整个集成程序进行升级。也就是说对于纯摄像头传感器而言，没有单独的程序升级过程。对于由CANFD搭载的毫米波/超声波雷达而言，由于是自带控制器的，其升级过程主要是通过CANFD连接控制器，域控通过CANFD接入公CAN，由座舱域负责刷写CANFD域控制器转发报文到各雷达控制器上。
如上图所示，OTA云服务平台主要对OTA升级包进行管理与下发，并完成升级任务的配置、调度及跟踪。OTA管理器主要完成升级包的下载、解密、验签、差分包重构等功能，最终将升级包发送至对应的升级对象。升级对象是由一个或多个ECU构成，升级对象接收到升级包后，将对应的ECU升级包发送至对应的ECU，ECU完成升级包的刷写。
目前的升级方式主要是静默升级。即包含常态化模式下的有感升级和非常态模式下的无感升级。常态模式实际就是在工厂模式下，多媒体接收升级命令后，在满足升级条件的情况下下载升级包，进行车辆的自动化升级。升级过程中，如收到解闭锁/开车门/按下启动按钮/云服务解锁信号后，车辆显示屏不显示 OTA 升级，常规升级过程中车辆处于静默状态。
非工厂模式下做无感升级，在用户不感知的情况下进行升级作为一保留方案。由于受国家相关法律的限制，这种方案的实现需要智能驾驶所有模块满足两面分区升级策略。这里的两面区分指的是A/B双面升级过程。即针对域控中的SOC开辟A/B两个存储空间，每个存储空间上均安装有一个系统，其中一个系统处于激活使用状态时，另一个系统就会处于待命备用状态。在进行系统升级时，可在激活的系统中对备用系统进行升级，升级完成后重启切换成新升级的系统。由此，在智驾域控的SOC中的升级过程可描述为当运行区为 A 区，则升级 B 区，升级完成后，从 B 区重启，启动后，择时将 B 区同步到 A 区。且当 SOC 升级失败的时候，不允许使用使能驾驶。
此外，对于域控中的MCU刷写而言，最好采用双APP机制。即MCU采用bootloader单区+app双区部署方式，bootloader一般没有升级需求。因此，对MCU的升级过程只需要对双区部署的APP进行即可。
整个升级过程中，需要完成如下升级过程中的任务：
1）升级前置条件判断：
通过以太网、CAN 等车内网络获取车辆当前状态检查，根据项目实际需求定制包含但不限于蓄电池电量、发动机转速、车辆速度、车辆档位、手刹状态、座椅传感器状态、门状态、锁状态等。座舱域控制器在升级开始前，需要针对升级车辆进行状态检查后继续后续动作。其当前状态的检查项目包括：模块剩余内部存储空间、模块硬件版本、模块固件版本、模块软件版本。通常情况下，升级过程中需要判断是否满足车辆是否静止，档位是否为P档，域控制器的SOC电量是否大于一定阈值条件。在适当的情况下，由中控界面/电检电脑显示屏上弹出预约升级或立即升级指示。有两种情况会触发升级：上下电自检与用户主动触发。升级条件触发，触发成功进入下一步，否则退出本次升级流程。
2）下载升级包：
在云端升级策略和升级包下发过程中，云端需要检测版本号是否更新，OTA升级服务器下发升级策略包到座舱域控制器，此过程中用户不会感知。座舱域控制器支持常规的刷写升级方式，DoIP 和 CAN烧写。
基于CAN协议的软件刷写
CAN 烧写过程实际是一种根据规范（规范主要是根据 ISO 14229 ）进行编程的过程。编程过程中需要指定参照如下几种类型的不同步骤进行有效的寻址及服务访问：
标准步骤作为一种强制性的步骤，要求无论任何情况下客户端和服务器都应按照规定行事。推荐步骤是可选的，他需要使用特定的诊断服务标识符，并包含有关如何执行操作的建议。这种可选的方案仅要求在使用指定的功能的情况下，客户端和服务器应按照规定行事。OEM实施步骤：其使用和内容（例如，使用的诊断服务标识符）由车辆制造商自行决定，当然也可作为另一种可选的步骤。
CAN软件刷写主要分三个阶段：预编程阶段，编程阶段，结束阶段。相应的各阶段需要进行的业务流程如下图所示：
基于DoIP协议的软件刷写详解
DoIP（Diagnostic communication over Internet Protocol）作为基于车载以太网的诊断，主要存在于OSI 七层模型中的传输层，DoIP是在以太网网络上传输UDS诊断数据的传输协议。DoIP具有高带宽，适合传输大量数据的场景，这就非常适合作为车上更新的OTA软件升级。相较于CAN，DoIP主要是在物理层和传输层对数据的传输进行了优化并提升了速度。在应用层和诊断服务环节，CAN与DoIP的实现均基于14229协议。ODX数据库部分，除需增加DoIP协议通讯参数和相关控制器外，一般情况下，不需要进行额外调整，这大大节省了诊断数据开发时间与成本。
对于DoIP的文件刷写主要包括无文件系统控制器的DoIP刷写和有文件系统控制器的DoIP刷写。针对无文件系统控制器的刷写，其总方案类似于 CAN 节点刷写方案。多媒体主机按地址传输，控制器按地址写入方式。对于有文件系统的控制器，多媒体主机只需要将升级包传到控制器（当然过程中需要能支持断点续传），并没有其他的要求。
目前常用的DoIP诊断连接方式分为两种：其一，是以太网线缆直连形式：在整车情况下，制作OBD-Ethernet线缆直连；其二，是兼容CAN/CAN FD通讯，并满足生产和售后需求，通过使用诊断VCI集成以太网激活功能，实现DoIP通讯。数据库创建完成后，使用相关诊断工具，即可实现车辆刷写过程。
座舱域控收到服务器下发的整车工厂模式自动化升级指令后，在满足升级条件的情况下请求服务器自动下载升级包，并对车辆进行自动化升级，支持断点续传，完整性校验，存储空间管理等功能。
3）智驾域控制器升级状态反馈：
智驾域控制器上报域控制器信息到座舱域控制器完成升级前置条件判断，条件满足时方可进入 OTA 升级，升级这类信息需要上传到OTA服务器。这类信息包括域控制器各个模块的软/硬件版本号、序列号(SN) 、定位信息(GPS)等。
4）执行升级任务：
座舱域控制器将根据服务器下发的升级包，升级策略等信息，进行 OTA 升级。如果同时需要进行多 ECU 联合升级刷写时，需要根据下发的升级任务序列，按照升级顺序与对应控制器发送点对点升级交互信息，即可完成对应的升级任务。
5）断点接续升级：
断点接续升级是指基于状态机的管理，在升级过程中，对当前升级的文件或块设备进行备份存储。如果在升级过程中出现中断，断电，或其它干扰，导致正在升级的文件被破坏，那么，控制器会记录当前升级状态，后续在下次重启程序时，控制器会执行一定的校验算法（如hash 校验）评估该文件是否已经遭到破坏，如果程序完好，则会直接按照未被标记升级过的程序进行顺序升级。如果文件已损坏，则会用备份的存储来恢复升级。
对于整个升级过程一般要求刷写失败后有数次重试机会。且有关联模块依赖时，对于已升级的关联模块需要全部回滚。
6）联动升级管理：
针对功能相关联的 ECU（比如前毫米波雷达升级可看成同性质下的联动升级），后台可以设定联动升级，也可以针对关联 ECU 设置升级顺序。升级过程为当座舱域控制器自后台取得升级任务后，会检测升级指令中是否有联动升级要求，如果有便会依照顺序进行逐一升级并关联 ECU。
座舱域控制器在整个升级过程中会管理并不间断派发升级包，监控整个升级过程直到所有 ECU完成升级，再统一上报后台升级结果。当检测到有任一ECU升级失败需要进行回滚时，控制器会联动所有关联 ECU 同步进行版本回滚。同时，座舱域控制器会有效上报因为哪一个 ECU 升级失败导致回滚。
相应的软件升级时序图如下：
基于如上说明，整车各模块升级可概括为：由 OTA 服务器下发升级策略文件决定升级顺序，在服务器上配置升级时生成策略文件，座舱域控根据策略文件制定各 ECU 升级方案和顺序。智能驾驶相关模块的升级顺序则按照如下优先级顺序进行先后升级控制：CAN 模块—>DoIP 无文件系统模块—>DoIP 有文件系统。
相较于CAN，DoIP主要是在物理层和传输层对数据的传输进行了优化并提升了速度。在应用层和诊断服务环节，CAN与DoIP的实现均基于14229协议。
对于智能驾驶系统而言，软件升级已作为不可或缺的一部分。在为客户提供实时在线升级功能的同时，域控制器需要满足云端安全通信，包括协议通信链接管理，升级指令接收和升级状态发送，升级包下载、升级包解密、差分包重构、对升级包进行合法性验证,还包括密钥证书管理服务，数据加密服务，数字签名服务等功能。可以说，智驾级别的软件升级是引领起其不断发展的源源动力。
以上是一文聊聊智能驾驶系统与软件升级的关联设计方案的详细内容。更多信息请关注PHP中文网其他相关文章！
