作者 | 孤月狼
来源 | 汽车电子软件
导读:
车辆下线时,使用工具或者是触发相应的软件,对车辆的软件版本信息进行回收,以VIN为关键字段,将相关信息回传到云端。云端对信息进行整理后做相应的存储。如果车辆的软件版本与初始设定的软件版本不一致,需要形成相应的升级任务,在车辆入库前通过OTA完成车辆软件版本的更新。
交付客户前的PDI检查。在PDI检查中加入手工出发升级程序的操作,升级程序会查看车辆的软件版本信息,并上报给云端,如有新的版本会下发给车端进行升级。确保交付给客户的车辆满足客户要求。
使用过程中的定期任务,按照一定的时间点上报车辆软件版本信息。在车端设置定期任务,车端执行版本检查动作并将车辆版本回传给云端。如发现车辆软件版本异常,需要做出相应的提醒,然后判断后执行相应的处理操作。
常规保养时对车辆软件版本进行检查。客户车辆在进行保养时,操作人员手动执行车端的软件版本检查程序,让车辆上报车辆软件版本,并检测是否有新版本,如软件版本有异常,可直接执行升级程序,让车辆软件版本符合OEM的要求。
软件信息的关系梳理:
在软件信息的对应关系上,要符合实际情况。软件搭载在零部件上,零部件又安装在具体的车辆上,不同的车辆可能会在相同的硬件基础上搭载不同的软件版本。因此,依据这种物理关系,软件信息→零部件是多对一的关系,但每个零部件只有一种版本状态。零部件→车辆VIN,这种关系在OEM内部已经有相应的系统做对应。如此存储,就可以对软件信息做相对规范的管理。
软件版本使用情况统计:
为了明确现在市场上软件版本的使用情况,需要以零部件为分类,统计市场上在行的软件版本数量,这个数据有助于企业判断市场上在行软件的风险程度。同时可以通过版本数量数据,大致的了解企业在软件版本开发上付出的工作量。
车辆软件版本是否与公司要求保持一致:
在软件版本信息回收后,云端会依据VIN码调用的公司该车型标准的软件版本信息,然后对比车端软件是否符合公司标准。如不符合应该给出相应的提醒。OEM可调用该车辆的相关信息,检查软件版本信息不一致产生的原因。
车辆软件版本的地理分布情况:
对于新能源车辆来说,不同的地域在地形、温度等条件上不尽相同,软件版本可能会出现区域不适应的问题,特别是与电池电控相关的零部件,对软件版本做地域上的分析有助于我们发现潜在的问题。
车辆软件版本与软件BUG间的关系分析:
不同的软件版本在质量表现上肯定是不同的,对软件版本和问题出现次数做统计有利于我们把控车辆整体表现。同时,也给营销领域推荐产品跟好的指导作用,尽可能在质量表现好的软件版本上不做太多的定制。
软件包的全流程安全防控
OEM的工程师们在探讨OTA系统安全的时候,往往最关注的是车端软件的安全性,云端软件的安全性,对升级包在系统外的传输过程并没有给予足够的关注。主机厂从供应商处获取软件包的过程中,也是存在安全风险的。如何安全的将软件包从生产单位转移到内部平台上,是软件包管理的首要任务。
软件包的测试与验证
在获取新的软件包之后,OEM要对软件包的质量进行必要的试验验证。随着软件版本的逐渐增多,OEM的试验部门要有相应的管理流程对软件包进行必要的测试。至少要进行台架测试,试验部门要把好入口关。如在验证上没有足够的经验,可以采取业务外包的模式开展,同时在关键核心零部件的软件测试上进行能力建设。
软件包的存储与关系管理
软件包在经过验证后,需要按照一定的规则进行存储。一般情况下以车型为单位,对ECU上使用的软件包、刷写策略、配置字、关联关系等相关内容进行保存。在企业内部做到软件包调用的统一管理,确保企业内部相关系统的软件包均源自同一出口,确保软件包的统一性。对软件包上传和调动的权限进行管理,做好使用记录,防止软件包不被外泄,确保软件包的安全。
软件包质量监控
依据车辆故障信息对软件包的质量进行监控,对故障数据的统计,有利于我们集中力量对重大问题进行整改,同时可以对整改工作的效果进行准确的监督和管控。软件包质量监控工作,是汽车产品质量的重要维度。
开发过程的管理
在开发过程中,软件工程师需要随着工作进度的推进,在内部系统上传软件编写源文件。在编码工作中需要遵循公司的相关编码规则和注释规则,在确保软件源码可读性的情况下,将源码存储在云端。云端要对源码的版本进行管理,确保程序员可追溯其历史版本。
软件源码的存储与调用
对于已经交付的源码,要有按照内部的命名规则对软件进行命名,做好相应的标注工作,统一存储在企业内部服务器上。对源码的调用权限进行设置,确保与该项目无关的人员不能获取软件源码。同时,对于源码的调用要有详细的记录,为后期追溯做好基础信息的收集。
已完成
数据加载中