导读：随着智能车辆在网联化、智能化及架构技术的发展，汽车无论是在固件还是软件上都已经不可逆转的需要进行软件迭代升级。要求在汽车生命周期内会不断的基于汽车 OTA 能力为整车提供软件升级、固件升级、售后服务等服务能力，可以说，汽车的智能化更迭对于 OTA 升级能力已经成为不可或缺的主流趋势。
本文将针对自动驾驶汽车的软件升级现状需求及监管要求等进行详细的描述。意在帮助读者整体了解自动驾驶中的软件升级过程原理、准入要求及其应对策略。
一、整车软件升级技术优势
首先，软件定义汽车推动了整车软件升级技术的发展与应用，通过整车软件升级解锁新技能，堵上小漏洞，甚至对不同使用场景进行特性化的配置推送或更改。由于软件定义汽车已经形成共识，软件有bug风险也成为一大趋势。整车软件升级可有效解决软件故障，通过应急响应降低开发周期短带来的软件风险问题，以及完成对信息安全漏洞的修复。
以智驾系统和智能座舱系统的升级为例可以很好的说明OTA（汽车OTA技术原理是什么？如何正确看待OTA技术？）升级过程原理及数据流走向。整个 OTA 软件框架包括三部分：OTA 云端，多媒体服务，智能驾驶模块。
OTA 云端的软件框架结构主要包括以下部分：OTA 管理平台、任务调度系统、升级监控、版本监控、打包工具打包升级包、加密计算、签名、版本管理、升级日志报告、升级通知等。
智能驾驶域（包含域控制器以及各个传感器零部件）通过软件开发完成迭代，其相应的软件会被打包为升级包，进行加密、签名后传送给到 OTA 云端，同时本地端进行版本管理、记录升级日志报告、给相关联系统发送升级通知。软件包包括要更新的内容，全量还是分量，一个车型，一个批次，还是一个特定群体等，这些包被放在 OTA 云端服务器上开始交互。对于摄像头这类部件如果是纯挂接到域控制器上，升级前需要明确其与域控制器的兼容性来明确他们之间的关联关系。考虑域控制器模块的功率，如果有液冷散热需求，整车升级流程中不能在域控制器工作的情况下升级TMS模块。
智能座舱域通过 4G/5G 网络建立车辆与服务器之间的安全连接，确保全新的、待更新的固件安全地传输到车辆的各个ECU。主要软件框架如下：获取版本信息、升级条件判断与检测、升级日志上传服务器、DoIP client、从服务去下载升级包、制定升级策略、解密计算、验签、HMI 解密显示、升级日志上传等。
智能驾驶模块需要满足车端的安全通信，包括协议通信链接管理以及安全认证。其主要的软件框架如下：升级包验签、升级包进度和结果反馈、升级包解密、差点还原、DoIP server、5R1V 升级、高精定位升级、域控制器升级、环视摄像头升级等。
整个升级要素包括如下：
1）软件升级包配置：通过打包工具生成相应的配置文件 .Config。然后，对配置好的软件包进行签名、拆包、加密传输。
2）软件升级包组包：智能座舱控制器解析接收到的数据，并进行解密、组包、验签；获得软件升级包与 Config 文件的压缩包。
3）软件升级包传输：读取 Config 文件中的相关信息用于通信控制交互，将软件升级包传输至智能驾驶各模块。
4）软件升级包交付：智能驾驶控制器对软件升级包进行解密、差分还原，解密后得到软件安装包；最后，使用应用证书进行验签，开启自升级任务。
其次，若出现因软件故障导致的召回，可以节省大量的时间和金钱成本。快速迭代、提升产品和使用体验。
随着软件在汽车上的应用越来越广泛，涉及软件相关的召回越来越多，在这个发展过程当中，软件带来的性能改变会给企业带来很多的潜在质量问题。新能源汽车出去之后投诉率百分之百，百分之百里面90%都是软件bug。
通常情况下，软件升级可以把原先不够好的功能变得更好，而车辆召回则是把有缺陷的东西换成或修复为符合标准和要求的东西。因此升级和召回都是一种消除缺陷的活动，返点返厂并不是必要条件。而通过合理的手段对OTA技术的应用，可以是省事省力又省钱的解决问题，预计通过这种方式召回的汽车将越来越多。
二、整车软件升级安全管理与测试挑战
汽车作为成熟的工业产品，上市之前需完成产品的公告认证及生产企业的许可认证。整车、零部件都是固化的，整车软件升级使这一切成为可变的。
从软件升级的整体把控上看，软件OTA的过程涉及云端安全管理，OTA连接安全管理，车端OTA安全管理几个大项。其中，云端安全主要是包括服务器访问保护、服务器攻击抵御、服务器-客户端鉴权、升级包安全存储、OTA业务渗透测试、OTA管理平台漏洞扫描、OTA业务安全日志这几大块。其次，OTA连接安全则是涉及Https的安全连接、传输内容加密、APN等业务领域。最后，车端OTA安全则是涉及汽车服务器鉴权、升级包完整性及安全性验证、OTA应用漏洞扫描、升级包存储安全管理、升级可靠性等多方面。
从某种程度上讲，软件升级过程需要通过对整个安全体系的设计与认证：其中包含云端OTA安全设计，管理端的连接安全保护，车端的OTA安全加固，并辅以严苛的性能测试，才能确保产品的可靠性和安全性。
三、软件升级管理要求应对策略
高级智能驾驶汽车为了从实践层面实现智能驾驶汽车准入，从当前准入指南规定的角度出发需要重点考虑软件升级在实际应用过程中的具体要求和实施措施。这是因为已经有不少新势力在设计之初，往往对于软件升级真正的规则和需求理解不够透彻，在软件版本发布中做毫无安全管控的升级滥用。当前出现的各类软件升级法规及准入指南关于软件升级的部分规范则是对于软件升级指导所下的及时雨。将从如下几方面为软件升级带来更多的应对优势。
1）软件升级的国家监管
中国市场，截止到2019年涉及程序或软件问题的召回就达到213次，涉及车辆683.02万辆，约占总召回数量的9%→因软件造成的召回增涨趋势明显。
当前市场上部分车企为快速推出产品，将还没有完善的汽车产品推出市场→通过OTA忽悠消费者，用升级之类的借口，对自身产品存在的问题进行搪塞、混淆甚至掩盖召回的事实。
基于以上现状描述，国家市场监督总局2020年11月25日国家市场监督管理总局出台了《关于进一步加强汽车远程升级（OTA）技术召回监管的通知》，着力实现对OTA的监管重点：在于通过有效的手段出台政策方法辨识召回与升级的差别。以避免OEM通过OTA方式消除缺陷，掩盖召回事实的行为。
采用OTA方式对已售车辆开展技术服务活动的汽车厂家，应按照《缺陷汽车产品召回管理条例》和 《缺陷汽车产品召回管理条例实施办法》要求，向市场监管总局质量发展局备案。2020年1月1日已实施OTA技术服务活动，生产者应于2020年12月31日已完成了相应的补充备案。
此外，2022年4月15日，工业和信息化部装备工业发展中心发布了《关于开展汽车软件在线升级备案的通知》中就明确指出，软件升级的申请主体应是汽车整车生产企业。且升级过程应按要求依次完成企业管理能力备案、车型及功能备案和具体升级活动备案等一系列要求。解读下来，那就是国家对软件升级的监管将更加严苛，后续主机厂想学特斯拉那一套，先上后优化的策略可能会存在较大的阻碍了。
2）软件升级法规-UN/WP29
对于软件升级法规而言，欧洲标准中UN/WP29可以完全适用于有软件升级功能的M类（乘用车）、N类（载货车）、O类（挂车）、R类（拖车）、S类(牵引车）、T类（农用车）等车辆的国际法规。对于智能驾驶市场布局而言，其软件升级的法规适用范围总结如下：• 2020年6月24日，WP.29第181次全体会议以网络会议形式通过软件升级法规，并于2020年6月25日正式发布 ；• 法规发布后，已于2021年1月22日正式生效，并由日本正式实施到研发车型中。• 韩国在法规正式发布之前已经将其融入了国家指南。• 2022-2024年，欧盟已陆续将所有新车型到全部车型都纳入该软件升级所需遵守的范畴中。
对于软件升级而言，其法规所规定的部分涉及利益相关者（汽车制造商、技术服务部门、主管部门）的责任。软件升级涵盖的内容涉及信息安全方面、认证合规方面、功能安全方面的要求。软件升级的具体流程、步骤、主要包括车辆类型批准申请、SUMS合格证书、RX软件标识号（RXSWIN）等几大方面。如上这些内容都意在满足软件升级的安全性和可靠性要求。
3）《智能网联汽车准入指南》对软件升级的要求
智能网联汽车准入指南是一部针对当前各家主机厂期待所研发的自动驾驶功能被认可所办法的准则、规范。它涉及包含如功能安全、信息安全安全、软件升级、数据记录、仿真/实车测试等方方面面。而软件升级上又主要包括对管理制度、标准规范、升级影响、测试和验证、适配性、可追溯性、告知义务和安全性等内容进行了相应的开发内容规范。综合总结相应的管理要求和测试要求如下图。
对于各家车企而言，需要各企业需尽快建立OTA管理运营体系、组织，积极配合国家进行监督管理。构建完善的OTA安全保障体系，流程体系先行。严控软件开发交付体系，做好全流程和全生命周期管理的验证、发布、备案、过程监管及应急处理，确保软件开发的安全可靠和系统效率。形成完善的OTA整车集成测试能力，同步发展功能安全、信息安全测试能力，形成OTA功能安全与信息安全的测试与验收方案。
四、总结
本文是概述性的讲解了软件升级在自动驾驶汽车设计开发中的优势、难点及规范要求几大方面。对于智能驾驶开发来讲，了解软件升级的重要技术优势，才能倾注更多的精力去发展软件升级技术开发及安全管理所带来的挑战，才能明确如何较好利用软件升级所涉及的规范、标准、法规等内容更好的开发出适合智能汽车的软件包。因此，这一过程的了解将使得整体把控软件升级过程将显得不那么棘手。
来源：焉知智能汽车
相关阅读：
