硬件产品开发中的软件管理——常见的管理实践分析

admin

随着这些年在企业的管理咨询和PLM实施，在10多年前的项目中第一次接触软件开发交付的管理，一直到目前推荐的软件配置管理的交付，不仅管理流程更深入的融入到软件策划、软件开发、软件测试和软件使用的过程，而且需求的复杂度也在持续不断的增加；以下几种常见的场景。

场景	概要描述	应用场景
场景1：产品中不包含软件	产品定义和软件开发独立，或者软件没有管控	产品中软件比较少，或者几乎稳定不变
场景2：产品中包含软件和版本，但未分离	产品定义的结构中包含软件，但是把软 件版本固化在产品结构中，这样软件变 更就会引起BOM结构变更	企业刚开始关注产品中的软件管理，并且软件变更相对较少
场景3：产品中包含软件和版本，但管理分离	产品结构中包含软件定义，但版本 管理与软件定义分离，这种模式支持 软件变更与产品结构变更的分离	产品中软件相对较多，并且软件更新频次比较多
场景4：模块化、平台化的软件配置管理	按照软件策划、软件开发交付、 软件测试、软件发布、产品软件配置、 集成测试、应用的正向开发场景管理 产品中的软件	产品中的软件比较多，并且对软件的策划、开发、应用、追溯管理要求比较高

以下针对上面说明的4种场景逐一分享在企业实施的实践。

• 产品定义的BOM中不包含软件
  
  

其实在相当长的时间内，很多企业的产品策划和定义时，是不包括软件的，尤其是那些结构和硬件占主要比例，软件又是几乎不变的产品；记得2010年在一起自动化设备企业实施PDM时，我问到为什么不在产品中包含软件时，得到的回答如下：

• 软件又不涉及到采购和领料，放到BOM中没有作用，还容易引起误解
• 软件开发后基本很少改动，尽管每一个项目都有少量修改，但仍旧是几乎不变的，没必要管理
  
  

过去的那些年我在不少企业关注过类似的场景，包括一些产品的应用软件、PLC程序、配置文件等，都采用这种形式；缺失管理必然会对后期的追溯带来很多问题，所以针对这些企业，我都建议采用最简化的软件管理，及场景2的管理模式

• 产品中包含软件和版本，但未分离
  

在进行这种方案描述之前，可以先说明一下企业常见的PCBA和软件的管理模式；随着企业对硬件上使用软件的关注，其实企业开始尝试探索软件管理的模式，如图示的PCBA，为了更完整的定义软件、硬件、结构之间的关系，会搭建一个虚拟/或真实的组件结构，定义数据之间的关系，这样产品开发或者使用人员看到图示结构，就可以很清楚的了解支持PCBA的结构部分，安装的软件，配置的参数/标定，因此这种方案在很多企业得到普及。

针对这种管理模式，企业在产品结构中定义软件时，不仅需要定义软件本身的信息，而且需要记录软件的兼容信息；一般在企业中，常用的信息包括软件的功能，归属系统，以及软件编码、名称、版本等，此外，需要记录软件安装硬件及版本，对于部分Kernel类软件，甚至需要记录对应的芯片型号，对于有多个芯片的，需要进一步记录位置信息和烧写方式，当然，更多的信息就不限制了，其实这里所有的信息，都有可能在后续业务中使用（原本计划找一个汽车企业的，但发现电脑上只有图片，没有征得客户同意，不能对外展示）

但是这种方式也存在很多弊端，可以从以下两个方面分析：

• 硬件上使用的软件，在很多企业并非随着PCBA的制作完成就烧录，至少目前我在企业就遇到过不同的场景，其实要考虑工艺应用时，就会发现这种结构其实并没有完整的考虑软件的使用，仅按照软件烧录在硬件上定义产品结构
  
  
  • 完成PCBA制造后，同步烧录软件：很多企业的PCBA是委外制造，所以这种模式还包含PCBA入库时就包含软件，或者PCBA领域时先烧录软件，这种对企业比较大的挑战时，烧录软件前后，从PCBA上看不到差异，因此在企业中建议尽量采用统一的模式，避免有些来料包含软件，有些不包含，那就需要有清晰的标识区分
  • 完成PCBA安装后，同步烧录软件：PCBA安装并没有包含软件，而是在线安装后，再进行软件安装，一般这种场景是软件可能同时需要不同的有影响的PCBA硬件支持，否则不建议在总装线上进行烧录，减少对生产节拍的影响
  • 在整机组装的测试环节，烧录软件：在生产线上有专门的工位进行软件的烧录灌装，然后进行测试，这种一般属于应用软件
    
    
• 若软件版本与结构的组成绑定在一起，软件版本的更新换代会远远高于硬件，因此每一次软件的升级，都需要考虑更新产品结构信息，但实际开发软件时，会考虑对硬件的兼容性，企业也认同版本更新前后的一致性，因此这种频繁的变更不仅对产品配置带来很多的复杂工作，而且考虑生产中不同产品、批次的断点切换，就会发现这种模式就很难实现了，因此就衍生了对第三种方案的需求。
  
  

例如，汽车行业的软件配置管理是一个复杂的过程，它涉及到对车辆软件组件的版本控制、变更管理、兼容性测试以及更新部署等多个方面，那么这种方式就无法满足要求了，或者说，至少最近接触的一些新能源汽车部件厂商，都不这么管理软件了。

• 产品中包含软件和版本，但管理分离
  
  

因为软件更新相对比较频繁，尤其是在测试阶段，甚至量产发布阶段，目前还有可能通过OTA进行升级，那么第二种管理方案是不满足这种管理诉求的，所以就出现新的，衍化出更多适应不同版本软件的管理方式；在场景二中，一个软件组成部件仅包含一个安装包或相关文件，但考虑多版本的兼容，这种方式就不合适，因此上述的管理方式，就出现了变形，如图示。

上述管理中，与第二种场景最大的区别在于将软件物料与实际发布可用的软件进行了分离，只要是针对当前功能软件的发布，统一按照图示逻辑构建关系，一个逻辑软件包含多个安装包的发布，并且针对发布的软件提供了状态管理，用于支撑发布软件在产品上的集成测试；但这种模式也带来一个新的问题，随着发布版本3的集成测试完成，有3个发布的软件可使用，那是否针对产品使用最新版本，还是如何处置？其实并非如此，这里涉及到一个集成产品的软件配置和测试，以及多软件的配置管理(生效管理)。

• 集成软件的配置管理：大部分产品的软件都并非一个，软件在应用过程中存在兼容性的问题，因此开发交付的软件，除了软件的功能测试外，还需要集成硬件测试和集成产品测试，尤其是集成产品测试时，就需要针对测试样机建立软件配置版本的基线；例如产品上有10种软件，就需要记录当前产品的配置，以及软件的版本配置清单，这样测试出的问题记录采用更精确的针对性，才能更精准的识别兼容性的问题，规避软件冲突的风险。我在企业也专门沟通过，在集成测试阶段，会遇到大量单产品测试无法识别的问题；也仅仅测试通过后，识别软件最新的配置清单随产品版本一起发布下游系统，下游系统按照配置清单的版本要求进行获取，并非最新版本；
  
  

• 软件配置的生效管理：当测试或者应用过程中，发现配置清单中某一软件有问题，可以单独进行开发修复并发布，但是发布的软件并非立即用于生产环境，必须重新升级图示配置清单的版本，例如从V4.1-II进行升级到V4.2版本，在此将软件更新到最新版本测试，测试过程中不影响历史产品按照历史的配置单获取对应的软件版本，也仅仅最新版本的软件测试通过后，才允许将软件的配置清单从V4.1-II切换到V4.2版本
  
  

按最新的配置进行生产使用；这种控制逻辑相对复杂，但其实也最符合集成硬件的软件的发布管理，最大化的控制软件频繁更改带来的风险问题，并且这种方案在记录产品的软件装机版本配置时也非常容易，仅记录装机的配置清单版本即可；获取的产品软件装机版本配置对后期软件升级时的更新维护非常重要，例如在以前的咨询项目中，我们就是依靠这个记录，针对轨道交通的列车，针对风力发电机识别并定义产品的软件更新计划，并生成测试、正式的升级任务等。汽车行业当然也面临着复杂的，高质量要求的软件开发过程管理和集成产品的软件配置管理，以下是汽车行业进行软件配置管理的一些关键步骤和实践：

• 软件物料清单（Software BOM）管理：车企或者关键部件企业在产品开发中会创建一个详细的软件物料清单，其中包含了车辆中所有软件组件的详细信息，包括它们的版本、依赖关系以及与硬件的关联，这也是产品定义和管理的核心，确保软硬件版本数据的配套性，为生产、售后刷写提供准确的数据支持
• 版本控制和变更管理：通过版本控制系统（如Git），可追踪软件的每一次变更，包括新增功能、修复的漏洞以及性能改进，当软件发生变更时，需要进行版本管理，确保每次更新都能够被追踪和审计；所有发布的软件版本，都会进入到发布库中等待测试验证和正式发布
• 兼容性测试：在软件更新或新功能部署之前，必须进行详尽的兼容性测试，以确保新软件与现有系统和硬件的兼容性，这包括对不同硬件配置、操作系统版本以及第三方应用的兼容性测试；充分的测试非常重要，企业需要建立自己的自动化测试平台，尽量减少人工测试，但这代替不了大量的人工仿真和测试
• 软件更新和部署：新能源汽车越来越多地采用OTA技术进行软件更新，这允许远程无线更新车辆软件，通过OTA更新，企业可以推送新的功能、性能改进或安全补丁到车辆，而无需车主前往经销商；这种技术也越来越多的被用到其他产品上，例如我们公司的产品也大量采用OTA技术，但本身OTA对软件的架构，版本及兼容性，测试要求会更高，毕竟工业设备若是OTA出现问题，影响是很大的；以前参与的轨道交通设备，都是不允许OTA的，优先考虑的就是安全性
• 安全性和隐私保护：随着汽车软件的增加，安全性和隐私保护变得尤为重要。汽车制造商需要确保软件更新不会引入新的安全漏洞，并且要保护用户的个人数据不被未经授权的访问，当然这是新的话题，目前国内外也有很多法规在说明这个事情，这个红线不能碰，例如上篇说明的UNR156和UNR155等，都有部分要求说明
• 组织流程变革：最后，为了适应软件定义产品的趋势，为了适应快速迭代的软件开发和部署，例如OTA技术的引进，开发流水线的引进，可以给企业带来很多持续更新的能力，这就要求制造企业调整其组织架构，建立与软件定义产品开发模式相匹配的组织流程，这可能包括建立跨部门的协作团队，专注于软件开发、测试和部署(当然硬件产品上的软件开发目前很难做到纯软件开发的敏捷，这块也咨询过一些专业人士)
  

• 模块化、平台化的软件配置管理
  
  

当然这个段落也并非说明软件本身的模块化，而是说明企业如何进行模块化，平台化的实施，在产品开发前期对软件需求进行策划，然后在产品开发中持续的完善，直至最后的发布。尤其随着软件定义XX的扩展和蔓延，大量产品都可以结合硬件+软件的“硬件软件化”的思路去考虑功能，越来越多的企业将分散的软件进行整合形成兼容性更强的软件、可建立更多链接的软件，甚至面向SOA对软件底层进行重新架构，我在和公司的软件研发负责人沟通时，他也给反馈目前也在执行这项工作，这里面也就带入了一个新的挑战，若将软件更多的模块化、平台化，那么软件如何适应不同产品、定制化需求的差异管理？我对软件本身的架构了解的比较少，但是参与的一些讨论，以及看到不少这方面的资料，目前这是一种方向，若是后期有更专业的人员可以帮忙提供资料，我也会陆续与大家分享。但是在一家轨道交通企业，还是参考MBSE针对产品开发管理的要求，协助企业定义了配置化，平台化的软件管理机制(已经交付，但感觉还有很多课持续提升的空间可优化，涉密，不能继续展开说明)

ASPICE提供了一种很好的模式，从软件的需求、架构到功能到编码、测试和应用的完整管理过程和能力评估的模型(目前还在学习，持续不断的研读，体会中间的管理要领，学会如何根据企业的情况，在保证核心的同时进行适应化的裁剪)

个人精力和能力有限，虽然在日常的咨询和实施中也在持续不断的沉淀这方面的管理经历，但写到这里仍旧感觉意犹未尽，仍感觉在管理实践上有很大的可改善空间进行探索和尝试，不过我没有放弃探索，希望后续可以进一步展开分享，也希望更多专业的朋友指正。