点击“蓝字”关注我们
导读/软件管理的管理对象&＃xff0c;说的更直白点就是软件管理我们到底管理什么&＃xff0c;管理主体的明确是我们做软件管理思考的出发点。就如同初级管理者的教程中所说&＃xff0c;管理者管什么&＃xff1a;管事、管人、管心。当然我们这里不研讨管理者的管理技术问题&＃xff0c;而是要看汽车软件管理的问题。
来源&＃xff1a;知乎
软件管理的目标
ENTER TITLE
做任何事情前都需要考虑清楚目标。我们对汽车上的软件进行管理&＃xff0c;做这个事情的目的是什么。绝不仅仅只是为了看哪辆车上用了什么版本的软件。
目的一&＃xff1a;减少软件被错用的风险。
在定制化非常高的客车领域&＃xff0c;每个批次都是交付给不同的用户&＃xff0c;在某些零部件上为了满足用户需求会有相应的软件更改。为了确保软件版本没有被用错&＃xff0c;就需要对下线车辆上的软件版本进行检查和管理。
目的二&＃xff1a;及时发现软件盗刷。
给车辆的软件版本进行刷写在后装市场上是一个服务&＃xff0c;用户可以找到相应的服务人员对软件进行版本上的刷写&＃xff0c;以达到提升车辆性能或者是实现某些功能的目的。私自刷写后如果车辆因为软件出了问题&＃xff0c;OEM想要做举证是很困难的&＃xff0c;对市场上车辆的软件是否做更改进行监管也是非常必要的。
目的三&＃xff1a;促进软件质量提升。
软件定义汽车是未来的发展趋势&＃xff0c;软件质量将会是车辆产品质量的重要体现。软件可便捷迭代后&＃xff0c;市场上反馈的软件质量问题可以快速解决&＃xff0c;软件质量会逐步提升。没有规范的软件版本管理&＃xff0c;软件质量的提升也无从下手。
目的四&＃xff1a;符合国家未来的管控政策。
国六排放标准的执行细则中已经要求OEM对国六控制器的软件版本进行公示&＃xff0c;确保市场上的在行版本与公示版本相同。国家质检总局也已经明确规定&＃xff0c;软件OTA是汽车召回的途径之一。不排除未来&＃xff0c;国家会对汽车上的软件进行管理&＃xff0c;企业内部的软件管理肯定要先行执行&＃xff0c;才能符合国家的相关要求。明确了汽车软件管理的目标&＃xff0c;也就可以清楚的明确OEM在软件管理过程中的关键举措。在出现一些策略上的模糊时&＃xff0c;我们可以回归目标来思考到底哪一种方案对目标是对有效的。正所谓&＃xff0c;菩萨畏因&＃xff0c;凡人畏果&＃xff0c;做一件事情的初始目的是很关键的
软件管理的管理对象
ENTER TITLE
软件管理的管理对象&＃xff0c;说的更直白点就是软件管理我们到底管理什么&＃xff0c;管理主体的明确是我们做软件管理思考的出发点。就如同初级管理者的教程中所说&＃xff0c;管理者管什么&＃xff1a;管事、管人、管心。当然我们这里不研讨管理者的管理技术问题&＃xff0c;而是要看汽车软件管理的问题。
第一&＃xff1a;管软件信息
软件信息的管理绝对是软件管理的核心对象。哪辆车上使用是哪一个版本的软件&＃xff1f;车辆上的软件更改历史如何&＃xff1f;市场上现在某个版本的软件还存在多少&＃xff1f;它们大致的分布是怎样的。软件信息的获取&＃xff0c;分析和应用&＃xff0c;是软件管理发挥价值的关键。
第二&＃xff1a;管软件包
软件包是软件的存在形态。我们需要对软件包的新增、版本、关系、存储、使用和删除进行管理。对软件包的管理要充分考虑软件的生命周期&＃xff0c;针对生命周期中不同的使用场景对软件包管理作出相应的定义。
第三&＃xff1a;管源码
主机厂的部分软件项目需要供应商交付软件源码的&＃xff0c;这些源码首先要与软件版本进行对应&＃xff0c;同时对于软件源码的上传&＃xff0c;存储和调用都应该有相应的管理举措。管理过程要在调用便利的基础上确保软件源码的安全。
第四&＃xff1a;管缺陷
软件在使用过程中肯定会遇到相应的问题&＃xff0c;这些问题原因的查找&＃xff0c;修复情况都需要进行管理&＃xff0c;以确保软件在市场上遇到问题后有渠道可以进行反馈并有团队负责进行修复。在软件问题修复后同时要有后续的软件升级相关操作&＃xff0c;以减少后期质量问题的出现。其实软件管理还需要管理软件开发过程&＃xff0c;但考虑到大部分的控制器软件的开发过程都是供应商完成的&＃xff0c;所以在这里就不多做赘述。同时&＃xff0c;软件开发过程的管理与项目管理是很类似的&＃xff0c;我们也就不多说了。
软件管理的举措
ENTER TITLE
为了达成管理目标&＃xff0c;结合OEM的实际情况&＃xff0c;应该设置怎样的管理举措是软件管理的核心所在。以下内容是我与某OEM的同仁一起电话聊了一个多小时的成果&＃xff0c;可能不是很成熟&＃xff0c;但值得参考。
软件信息管理举措
软件信息管理的基础是车辆软件信息的回收。在软件信息获取完整且准确的情况下&＃xff0c;依据实际工作需要&＃xff0c;对软件信息进行统计和分析才会更有价值。第一、车辆软件基础信息回收的时间点车辆软件基础信息的回收是软件信息管理的前提。从车辆的生命周期中来看&＃xff0c;有以下机会可以实施软件信息的回收。
- 车辆下线时&＃xff0c;使用工具或者是触发相应的软件&＃xff0c;对车辆的软件版本信息进行回收&＃xff0c;以VIN为关键字段&＃xff0c;将相关信息回传到云端。云端对信息进行整理后做相应的存储。如果车辆的软件版本与初始设定的软件版本不一致&＃xff0c;需要形成相应的升级任务&＃xff0c;在车辆入库前通过OTA完成车辆软件版本的更新。
- 交付客户前的PDI检查。在PDI检查中加入手工出发升级程序的操作&＃xff0c;升级程序会查看车辆的软件版本信息&＃xff0c;并上报给云端&＃xff0c;如有新的版本会下发给车端进行升级。确保交付给客户的车辆满足客户要求。
- 使用过程中的定期任务&＃xff0c;按照一定的时间点上报车辆软件版本信息。在车端设置定期任务&＃xff0c;车端执行版本检查动作并将车辆版本回传给云端。如发现车辆软件版本异常&＃xff0c;需要做出相应的提醒&＃xff0c;然后判断后执行相应的处理操作。
- 常规保养时对车辆软件版本进行检查。客户车辆在进行保养时&＃xff0c;操作人员手动执行车端的软件版本检查程序&＃xff0c;让车辆上报车辆软件版本&＃xff0c;并检测是否有新版本&＃xff0c;如软件版本有异常&＃xff0c;可直接执行升级程序&＃xff0c;让车辆软件版本符合OEM的要求。
第二、软件基础信息的统计分析方式。软件信息的统计和分析要基于实际工作需求开展&＃xff0c;反观软件管理的目标&＃xff0c;结合能够回收的信息类型&＃xff0c;大致有以下几种软件信息统计分析的方式。
- 软件信息的关系梳理&＃xff1a;
在软件信息的对应关系上&＃xff0c;要符合实际情况。软件搭载在零部件上&＃xff0c;零部件又安装在具体的车辆上&＃xff0c;不同的车辆可能会在相同的硬件基础上搭载不同的软件版本。因此&＃xff0c;依据这种物理关系&＃xff0c;软件信息→零部件是多对一的关系&＃xff0c;但每个零部件只有一种版本状态。零部件→车辆VIN&＃xff0c;这种关系在OEM内部已经有相应的系统做对应。如此存储&＃xff0c;就可以对软件信息做相对规范的管理。 - 软件版本使用情况统计&＃xff1a;
为了明确现在市场上软件版本的使用情况&＃xff0c;需要以零部件为分类&＃xff0c;统计市场上在行的软件版本数量&＃xff0c;这个数据有助于企业判断市场上在行软件的风险程度。同时可以通过版本数量数据&＃xff0c;大致的了解企业在软件版本开发上付出的工作量。 - 车辆软件版本是否与公司要求保持一致&＃xff1a;
在软件版本信息回收后&＃xff0c;云端会依据VIN码调用的公司该车型标准的软件版本信息&＃xff0c;然后对比车端软件是否符合公司标准。如不符合应该给出相应的提醒。OEM可调用该车辆的相关信息&＃xff0c;检查软件版本信息不一致产生的原因。 - 车辆软件版本的地理分布情况&＃xff1a;
对于新能源车辆来说&＃xff0c;不同的地域在地形、温度等条件上不尽相同&＃xff0c;软件版本可能会出现区域不适应的问题&＃xff0c;特别是与电池电控相关的零部件&＃xff0c;对软件版本做地域上的分析有助于我们发现潜在的问题。 - 车辆软件版本与软件BUG间的关系分析&＃xff1a;
不同的软件版本在质量表现上肯定是不同的&＃xff0c;对软件版本和问题出现次数做统计有利于我们把控车辆整体表现。同时&＃xff0c;也给营销领域推荐产品跟好的指导作用&＃xff0c;尽可能在质量表现好的软件版本上不做太多的定制。
软件信息的分析角度非常多&＃xff0c;在一篇文章中可能不足以描述清楚。但数据分析的目的是为我们的工作带来便捷&＃xff0c;让工作有更多的数据支撑进而做出更加正确的决策&＃xff0c;从这个角度出发&＃xff0c;软件信息的统计分析会创造更多的价值。
软件包的管理举措
ENTER TITLE
软件包是软件版本的载体&＃xff0c;OME对软件包的管理&＃xff0c;主要是解决软件包从哪来、质量如何、怎么存、怎么用的问题。同时&＃xff0c;还需要重点关注软件包的安全问题。
- 软件包的全流程安全防控
OEM的工程师们在探讨OTA系统安全的时候&＃xff0c;往往最关注的是车端软件的安全性&＃xff0c;云端软件的安全性&＃xff0c;对升级包在系统外的传输过程并没有给予足够的关注。主机厂从供应商处获取软件包的过程中&＃xff0c;也是存在安全风险的。如何安全的将软件包从生产单位转移到内部平台上&＃xff0c;是软件包管理的首要任务。 - 软件包的测试与验证
在获取新的软件包之后&＃xff0c;OEM要对软件包的质量进行必要的试验验证。随着软件版本的逐渐增多&＃xff0c;OEM的试验部门要有相应的管理流程对软件包进行必要的测试。至少要进行台架测试&＃xff0c;试验部门要把好入口关。如在验证上没有足够的经验&＃xff0c;可以采取业务外包的模式开展&＃xff0c;同时在关键核心零部件的软件测试上进行能力建设。 - 软件包的存储与关系管理
软件包在经过验证后&＃xff0c;需要按照一定的规则进行存储。一般情况下以车型为单位&＃xff0c;对ECU上使用的软件包、刷写策略、配置字、关联关系等相关内容进行保存。在企业内部做到软件包调用的统一管理&＃xff0c;确保企业内部相关系统的软件包均源自同一出口&＃xff0c;确保软件包的统一性。对软件包上传和调动的权限进行管理&＃xff0c;做好使用记录&＃xff0c;防止软件包不被外泄&＃xff0c;确保软件包的安全。 - 软件包质量监控
依据车辆故障信息对软件包的质量进行监控&＃xff0c;对故障数据的统计&＃xff0c;有利于我们集中力量对重大问题进行整改&＃xff0c;同时可以对整改工作的效果进行准确的监督和管控。软件包质量监控工作&＃xff0c;是汽车产品质量的重要维度。
当前&＃xff0c;受限于部分供应商在软件层面的技术封闭&＃xff0c;在车型故障排查上可能会遇到很多的困难。OEM在定义汽车零部件质量的考察维度时&＃xff0c;软件质量也需要考虑到&＃xff0c;同时要对市场上软件质量的表现情况做详细的统计分析。
软件源代码管理举措
ENTER TITLE
OEM在采购的过程中会要求供应商对零部件的上层源码进行交付。随着OEM对车载软件的重视程度逐渐提升&＃xff0c;对零部件内部软件源码的要求也会越来越多。OEM也需要对车辆软件的源代码进行规范的管理&＃xff0c;在高效利用源码的情况下&＃xff0c;也需要保证源码的安全。软件源码的管理在互联网公司已经有非常成熟的管理模式。OEM内部也有相应的软件编程工作&＃xff0c;在这个领域可以参照互联网公司的管理模式。
- 开发过程的管理
在开发过程中&＃xff0c;软件工程师需要随着工作进度的推进&＃xff0c;在内部系统上传软件编写源文件。在编码工作中需要遵循公司的相关编码规则和注释规则&＃xff0c;在确保软件源码可读性的情况下&＃xff0c;将源码存储在云端。云端要对源码的版本进行管理&＃xff0c;确保程序员可追溯其历史版本。 - 软件源码的存储与调用
对于已经交付的源码&＃xff0c;要有按照内部的命名规则对软件进行命名&＃xff0c;做好相应的标注工作&＃xff0c;统一存储在企业内部服务器上。对源码的调用权限进行设置&＃xff0c;确保与该项目无关的人员不能获取软件源码。同时&＃xff0c;对于源码的调用要有详细的记录&＃xff0c;为后期追溯做好基础信息的收集。
软件源码是企业的核心资产&＃xff0c;随着软件在汽车上发挥的作用越来越大&＃xff0c;关键的技术内容都会被抽象为软件功能&＃xff0c;源码对于OEM来说会越来越重要。汽车软件将会是汽车关键核心技术的主要载体&＃xff0c;OEM不但要在软件源码管理上下功夫&＃xff0c;还需要在软件定义和开发上下功夫。搭建OTA系统只是万里长征的第一步&＃xff0c;升级什么&＃xff0c;如何定义汽车软件&＃xff0c;才是真正的万里长征。
结语
ENTER TITLE
本位作为一个专注于OTA产品从业人士&＃xff0c;我们十分希望主机厂在软件管理上能够做的规范。正如一开始所说&＃xff0c;规范的软件管理是OTA系统产生价值的基础之一。在我交流过的企业中&＃xff0c;软件管理的水平和现状都不尽相同&＃xff0c;希望大家能够在评论区对汽车软件管理发表自己的看法&＃xff0c;分享各自做的好的部分。交流是创新产生的前提&＃xff0c;只有行业不断的进步&＃xff0c;才会创造出更多的机会。欢迎各位不吝赐教。
来源&＃xff1a;知乎
推荐合集资料&＃xff1a;
自 动 驾 驶 | 智 能 座 舱
资讯|技术|干货|深度
长 按 关 注
旺材自动驾驶与智能座舱
【免责声明】文章为作者独立观点&＃xff0c;不代表旺材自动驾驶与智能座舱立场。如因作品内容、版权等存在问题&＃xff0c;请于本文刊发30日内联系旺材自动驾驶与智能座舱进行删除或洽谈版权使用事宜。
京公网安备 11010802041100号