当前位置: 首页 > 科技观察

本文讲述智能驾驶系统及软件升级的相关设计方案

时间:2023-03-18 11:37:23 科技观察

由于智能汽车集中化趋势,网络连接的升级过程已经从传统的低带宽Can网络转换为高带宽以太网络。为了提高车辆升级能力,在为车主提供持续、优质的体验和服务的基础上,需要在现有的系统基础上(从原来对车上传统ECU的升级到实现的过程)增量以太网升级)开发新的OTA服务系统,兼容现有OTA系统,实现整车软件、固件、服务的OTA升级能力,最终提升用户体验和服务体验。软件升级涵盖的两大领域——FOTA/SOTA整车软件升级是通过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)升级前条件判断:通过Ethernet、CAN等车载网络??获取车辆当前状态,并根据项目实际需求,包括但不限于电池电量、发动机转速、车速、车辆档位、手刹状态、座椅传感器状态、车门状态、锁状态等。升级开始前,座舱域控制器需要检查升级车辆的状态,并继续跟进。其当前状态的检查项目包括:模块内部存储空间剩余、模块硬件版本、模块固件版本、模块软件版本。通常在升级过程中,需要判断车辆是否静止,档位是否在P档,域控制器的SOC功率是否大于一定阈值。如果合适,会在中控界面/电检电脑的显示屏上弹出预约升级或立即升级的提示。触发升级有两种情况:开机自检和用户主动触发。触发升级条件,如果触发成功则进入下一步,否则退出升级流程。2)下载升级包:在云端升级策略和升级包分发过程中,云端需要检测版本号是否更新,OTA升级服务器将升级策略包下发给驾驶舱域控制器,用户不会意识到这个过程。座舱域控制器支持常规刷机和升级方式,DoIP和CAN刷机。基于CAN协议的软件烧写CAN编程过程实际上就是按照规范(规范主要基于ISO14229)进行编程的过程。在编程过程中,需要指定以下几种不同的步骤来进行有效的寻址和服务访问:标准步骤是强制性步骤,要求客户端和服务器在任何情况下都按照规定进行操作。建议的步骤是可选的,需要特定的诊断服务标识符,并包含有关如何进行的建议。此可选方案仅要求客户端和服务器在使用指定功能时按指定方式运行。OEM实施步骤:其用途和内容(例如,使用的诊断服务标识符)由车辆制造商自行决定,但当然也可以作为另一个可选步骤。CAN软件刷写主要分为三个阶段:预编程阶段、编程阶段、结束阶段。每个阶段需要进行的业务流程如下图所示:基于DoIP协议刷机详解DoIP(DiagnosticcommunicationoverInternetProtocol)是一种基于车载以太网的诊断,主要存在于交通领域OSI七层模型的层。DoIP是一种传输协议,用于通过以太网传输UDS诊断数据。DoIP带宽高,适用于传输大量数据的场景,非常适合作为车载更新的OTA软件升级。与CAN相比,DoIP主要在物理层和传输层优化数据传输,提高速度。在应用层和诊断服务环节,CAN和DoIP的实现基于14229协议。对于ODX数据库部分,除了增加DoIP协议通讯参数和相关控制器外,一般不需要额外调整,大大节省了诊断数据开发的时间和成本。DoIP文件刷写主要包括无文件系统控制器的DoIP刷写和有文件系统控制器的DoIP刷写。对于没有文件系统的控制器的刷写,整体方案与CAN节点刷写方案类似。多媒体主机根据地址传输,控制器根据地址写入。对于带文件系统的控制器,多媒体主机只需要将升级包传给控制器即可(当然过程中需要能够支持断点续传),其他没有要求。目前常用的DoIP诊断连接方式有两种:一种是网线直连形式:在整车情况下,采用OBD-Ethernet网线直连;另一种是兼容CAN/CANFD通信,并且为满足生产和售后需要,通过使用诊断VCI集成以太网激活功能,可以实现DoIP通信。创建数据库后,可以使用相关诊断工具实现车辆刷写过程。座舱域控收到服务器下发的整车工厂模式自动升级指令后,如果满足升级条件,请求服务器自动下载升级包,自动升级车辆,支持断点续传和完整性检查.存储空间管理等功能。3)智能驾驶域控制器升级状态反馈:智能驾驶域控制器向座舱域控制器上报域控制器信息,完成升级前条件判断。只有满足条件才能进入OTA升级。升级信息需要上传到OTA服务器。此类信息包括域控制器各模块的软件/硬件版本号、序列号(SN)和位置信息(GPS)。4)执行升级任务:座舱域控制器根据服务器下发的升级包、升级策略等信息进行OTA升级。如果需要同时进行多ECU联合升级刷写,则需要根据下发的升级任务序列,按照升级顺序,与对应的控制器发送点对点的升级交互信息,对应的升级可以完成任务。5)断点续传升级:断点续传升级是指基于状态机的管理。在升级过程中,备份并存储当前升级的文件或块设备。如果在升级过程中出现中断、掉电或其他干扰,导致正在升级的文件损坏,那么控制器会记录当前的升级状态,然后在程序重启时控制器会执行一定的校验算法下次(如哈希验证)评估文件是否损坏,如果程序完好,则直接按照未标记为已升级程序的顺序进行升级。如果文件损坏,备份存储将用于恢复升级。整个升级过程,一般需要有几次刷机失败后的重试机会。并且当存在关联模块依赖时,需要回滚所有升级的关联模块。6)联动升级管理:对于功能相关的ECU(比如之前的毫米波雷达的升级可以看作是同性质的联动升级),后台可以设置联动升级,也可以设置相关ECU的升级顺序。升级过程是座舱域控制器从后台获取升级任务时,会检测升级命令中是否有联动升级请求,如果有则依次升级并关联ECU.驾驶舱域控制器会在整个升级过程中持续管理和分发升级包,监控整个升级过程,直到所有ECU升级完成,然后统一上报后台升级结果。当检测到任何ECU升级失败需要回滚时,控制器会联动所有关联的ECU同步进行版本回滚。同时,座舱域控制器会有效报告是哪个ECU升级失败导致回滚。对应的软件升级时序图如下:基于以上描述,车辆各模块的升级可归纳为:OTA服务器发送升级策略文件确定升级顺序,服务器生成策略配置升级时的文件,驾驶舱域控制根据策略文件制定各ECU升级计划和顺序。智能驾驶相关模块的升级顺序按照以下优先顺序进行控制:CAN模块—>DoIP无文件系统模块—>DoIP有文件系统。与CAN相比,DoIP主要在物理层和传输层优化数据传输,提高速度。在应用层和诊断服务环节,CAN和DoIP的实现基于14229协议。对于智能驾驶系统来说,软件升级已经成为不可或缺的一环。域控制器在为客户提供实时在线升级功能的同时,需要满足云安全通信需求,包括协议通信链路管理、升级命令接收和升级状态发送、升级包下载、升级包解密、差分包重构、升级包针对合法性验证,还包括密钥证书管理服务、数据加密服务、数字签名服务等功能。可以说,智能驾驶级别的软件升级是引领其不断发展的动力源泉。