基于电子电器架构的整车OTA设计方案.docVIP

基于电子电器架构的整车OTA设计方案 （Over-the-Air）是一种无线升级技术，为软件提供了持续迭代更新的能力，已逐渐成为智能网联汽车的标配。整车OTA受限于电子电气架构、升级时间长、控制器多难以控制等限制导致发展进度缓慢，为提高整车OTA的稳定性并缩短升级时间，本文提出一种基于电子电器架构的整车OTA设计方案，实现了对升级对象的统一管理、对升级过程的集中控制，并以此提出了整车OTA的平台化架构方案。本设计方案可应用于其他车型，解决了整车OTA涉及控制器多、升级过程不可控、升级时间长和稳定性差等问题，形成了一套从云端到车端完整的持续迭代更新能力和智能网联汽车价值提升的新动力。 引言 OTA（Over-the-Air）即空中下载技术，是通过移动通信的接口实现对软件进行远程管理。OTA是汽车软件升级的通道，其价值是将新软件远程刷写到汽车中。软件定义汽车逐渐成为业内共识，汽车软件存在两个趋势：第一、整车厂交付的汽车将不再是一个功能固化的产品，而是一个持续更新的智能设备，在整个生命周期内，需要持续支持软件迭代升级；第二、随着软件量的增加，软件bug将成为潜在风险，OTA可以有效解决软件故障，通过软件升级降低开发周期短带来的软件风险问题，完成软件漏洞的修复，减少软件问题导致的召回。OTA远程升级技术已逐渐成为智能网联汽车的基础功能，通过持续迭代的更新软件，不断提升汽车的潜在价值，从而带动智能网联汽车行业全新的商业模式。 需求分析 汽车整车OTA受限于电子电气架构，存在很多困难。随着汽车电子化技术的提高，电子控制单元ECU占领了诸如动力、底盘、车身、座舱以及自动驾驶等领域，ECU的数量多达几十甚至上百个。这些ECU是由不同的供应商提供，运行着各种不同的操作系统和应用软件，整车OTA意味着所有相关的控制器都要在一次升级过程中完成软件版本的更新，因此升级的总时间和成功率是OTA的两大难点。而且为了保持软件升级的稳定性和安全性，车辆部分功能将被禁用，要求车辆处于熄火的状态，长时间的升级会影响用户体验。为了提高整车OTA的稳定性、缩短升级时间，本文提出了一种基于整车电子电器架构的OTA设计方案，实现整车版本管理和整车软件升级。 总体方案设计 整车OTA的功能是控制和执行车上各类控制器的软件升级，因此需要对所有关联控制器提出统一的升级要求和规范，并对升级过程进行集中控制。本方案遵循“集中控制、分而治之”的原则，实现了“两类对象、两个过程、四种角色”：1）两类对象：即升级对象分为2类。第一类是智能控制系统，基于操作系统具备自升级能力，如座舱域的车机、仪表等，驾驶域的自动驾驶控制器等；第二类是传统的控制器即ECU电控单元，没有操作系统而是由刷写上位机来完成软件升级。两类升级对象须遵循各自的技术要求：智能系统要求实现版本信息维护、文件存储、自升级以及升级异常处理等功能；传统的控制器要求满足UDS（汽车通用诊断服务）的刷写规范。 升级对象分类的目的在于将车上众多的控制器按照其软件升级方式的不同进行分类管理，对同类的控制器提出一致的技术要求规范，以便于实现OTA升级对象管理的标准化。2）两个过程：即升级过程分为2个过程。第一个过程是下载部署过程，服务器将升级任务通知到车辆，车端从服务器端下载升级包到本地，这个过程可在车辆行驶中进行不会对用户产生影响；第二个过程是安装过程即“车端各个控制器执行软件升级”，这个过程需要保持车辆处于特定的状态如车速为零、发动机熄火等，所以不能正常用车。下载部署过程和安装过程中的执行对象、执行条件以及控制策略是不同的，将过程分段的目的在于实现OTA不同过程的差异化控制，能够对各种过程进行集中控制，并在一个模块中实现。 3）四种角色：即功能划分为4个角色实现职责分离。第一个角色是OTA服务端（OTAServer）负责web管理平台、升级数据管理和升级文件存储；第二个角色是OTA客户端（OTAClient）完成车上所有控制器的版本收集，与服务端交互获取升级任务和上报升级状态，下载升级包，将升级包和升级信息分发到执行升级的控制器，负责人机交互功能；第三个角色是OTA主控模块（OTAMaster）检查整车的安装条件、保持安装状态、按照升级策略控制安装过程；第四个角色是OTA子控模块（SubMaster）保存升级包、完成所在控制器的升级功能，能够通过车内总线或者USB等其它的物理通道对其他控制器或者固件进行升级。 OTAClient、OTAMaster和SubMaster这三个模块运行在车端，基于整车电子电器架构被部署到不同的控制器中。角色划分的目的在于对功能进行模块化设计，便于在不同车型上实现复用，从而实现该OTA方案的平台化和可移植性。基于上述的设计原则和设计思路，系统设计方案如图1所示：图1