硬件产品开发中的软件管理（借鉴）

admin

最近在一次专题沟通中，业务人员反馈了目前产品开发中软件版本更新经常导致产线刷写程序版本出错的问题，并且导致过一些事故和损失，询问这块有无更好的管理建议；刚好这点也是我感兴趣的课题，因此就展开了详细的探讨。这是家新能源装备企业，其实现在新能源产品中其实包含了大量的硬件和软件，因此我的定位也是妥妥的高科技企业，当前的管理方式是软件开发归软件开发，软件只要发布后就可以生效，随着产品的发布和生产的使用，也就可以直接抓取BOM中的软件进行刷写，因为软件更新的频次原高于硬件，因此软件发布时可直接更新产品中的版本，生产线就可以获取最新版本使用，不管是对芯片的烧写程序、BMU的程序和参数标定、CMU的程序，或者对PCBA烧写序列号的程序，结果导致两个问题：

• 具体哪一台设备刷新了哪些程序的哪些版本没有记录：设备上使用程序可以输出，但因为生产时获取的最新版本，版本升级时又缺少记录和切换控制，导致后期追溯非常困难；后来不得不开发了设备上获取版本的功能，以及远程云端获取版本的功能，但针对部分无法联网的软件，仍旧是黑盒子；针对部分测试时临时升级的设备，仍旧靠Excel记录，但后续更新人员很难及时准确的获取信息，也导致版本冲突的问题
• 硬件变更切换的滞后性与软件版本的立即生效的冲突：因为变更切换的原因，硬件可能切换在一个月后，但同步发布的软件却立即生效，那么在产线上就会造成改之前的硬件使用最新版本的软件，导致一些版本和兼容性的问题，其实这个时候不能立即更新，或者或需要硬件版本与软件版本的匹配性更新
  

在这么多年的产品开发解决方案输出中，我知道这是共性问题，因此，我没有立即给解决方案，而是建议他们了解一下汽车及配件行业，尤其是新能源是如何管理软件，尤其是了解UN-R156《软件升级与软件升级管理体系》(当然这里也包括R155、R157的法规供参考)；在构思写本篇时，我也想整合我在轨道交通行业的车载软件配置管理、汽车配件行业的软件配置管理、电子及高科技行业的软件配置管理的经理和心得和大家分享，当然我不是代码开发工程师，这里不会分享软件本身的开发经理，更多的是在产品中如何审核、测试、发布、配置软件的经验。UN-R156是2020年6月联合国世界车辆法规协调论坛（简称为UN/WP.29）发布的3项关于智能网联汽车的重要法规R155/R156/R157之一，R156讨论的是软件升级与软件升级管理系统的统一规定；其实以前我在参与轨道交通行业车载软件配置管理解决方案时，更多参考的是航空航天的软件构型、技术状态管理的理念，但后来在汽车工程学会的经历了解到此法规，发现更完整更精准的描述了智能网联汽车针对软件升级的控制要求，目前也获得行业认可，也是整车企业进入欧美市场需要通过的认证法规之一，在这里，针对软件升级管理，为必要的流程提供了一个框架，包括：

• 记录与车辆类型有关的硬件和软件版本

• 识别与型式批准有关的软件

• 验证零部件上的软件

• 识别相互依赖性

• 确定车辆目标，并验证其更新兼容性

• 评估软件升级是否影响型式批准或符合合法定义的参数

• 评估更新是否影响安全或驾驶

• 向车主通报最新情况

• 记录以上所有内容

  
  

上述的大部分内容和前期的管理经验一致，体系也从更大范围的应用提供了一个背书；R156对车载软件的管理和升级合规性认证申请的说明，对认证标识标记的定义，对车型认证(发布时仅对部分车型有要求，并非全部智能网联汽车)的要求，对软件升级管理体系的合规性要求，对认证车型的变更与扩展等要求，这里的软件升级当然也不限于手工或OTA，并且针对OTA也提供了专门的要求，部分逻辑也可以参考图示

通过严谨的软件和升级管理过程，不仅确保软件升级的真实性和完整性应受到保护，以合理的方式防止软件包被破坏并阻止无效的更新(安全层面的要求，车企需要提供相关保护机制的详细说明，以确保在车辆上仅可执行经过认证和完整性检查的软件升级包），而且对软件唯一可识别性、更新、存储与读取要求以及保护防篡改提出了明确管理框架。(大家可以直接到网络上查询下载阅读)。当然针对航空航天的机载软件，以及在后来我们迁移方法论到轨道交通(普铁、标动和高铁)的车载软件管理中，都对软件管理提出了更高的过程质量控制要求，以及升级控制要求(当然不存在汽车的OTA模式)，这里以一个机载FCC飞行控制机柜机载软件标识为例；从软件的策划，交付、测试、地面静态测试，地面动态测试等很多环节对软件和硬件的关联及配置都提出了不同要求(因项目实施资料保密，图片来源于公开资料仅供示意)。

在方案中，行业经验是严格定义软件策划，软件发布，以及发布之后的集成测试场景，并且不同测试场景定义不同的标识，一直沿着不同的标识进行更新，达到不同标识满足不同测试场景要求，其中任一软件更新，基本都会按照影响表逐层级进行测试；发布之后的软件在设备安装、更新时都有详细的记录，这些记录为后续更新维护提供翔实准确的数据(更新时兼容版本对比，识别硬件和软件更新，向指定设备的维护人员发送更新指令，更新后，看板显示更新后的状态)。

这里分享的资料都是在以前项目实施时大量收集和整合资料的一部分，因为这是从更高层级定义了软件管理的框架，并且在对应的行业中得到了很好的应用，因此阅读别的行业最佳实践，及时我们没办法全部迁移应用，也可针对自己的需求和痛点量体裁衣——这是我在做顾问时的经验，例如也在一家电子设备企业分享了汽车行业的《ISO 26262 道路车辆功能安全》的管理要求，帮助企业提升产品的安全策划、风险识别、安全分析和安全实现的管理流程定义，虽然和行业专家相比我差了很多，但也得到企业的认同。所以，他山之石，可以攻玉；他人之事，我事之师；牛顿也说站在伟人的肩膀上看得更远。针对硬件产品开发中的软件管理，的确想和大家分享我的一些浅薄总结，因此计划使用三篇文章进行说明，包括：

• 他山之石：这是开篇，对这些年接触的一些比较总结性的架构性的内容进行说明，广开思路才能游刃有余；
• 常见的管理实践分析：提出多种不同目前常见的管理方案，并分析优势和不足，可供大家结合自己的需求参考；
• 软件开发管理的实践：随着软件越来越多，但软件开发既高度耦合又需要保留各自的专业特性，支撑软件的快速迭代和更新的模式。