奇瑞汽车软件开发过程及发布变更与应用体系建ARTICLE COLUMN

新一代PLM > 技术 > PDM/PLM >

奇瑞汽车软件开发过程及发布变更与应用体系建

敏桥科技 / 阅读
 汽车“新四化”和公司战略对汽车核心竞争力-软件，提出了更高的要求。随着整车电子电气的发展，软件定义汽车成为汽车行业的共识与目标，复杂的软件数据管理成为汽车行业新四化的掣肘。为了提升软件开发管理能力，实现从研发、制造到服务全流程管理势在必行；目前汽车电子开发多采用V字模型，且国际上已有一些通用开发流程（需符合ASPICE、ISO26262等标准）。

       在此背景下，传统车企也在做新四化的转型。软件管理对于相关人员是一个陌生的全新领域，需要从标准、流程和系统等各方面全面对标、全面优化和建立完整的软件数据管理体系（重点包含软件过程开发和发布变更及应用管理两个方面），形成企业级的软件管理标准，助力新四化的企业战略。

       本文将全面阐述本公司在车载嵌入式软件数据管理领域的一些实践和创新。

2 体系建立背景

       新体系建立前，公司的嵌入式软件数据管理体系难以满足业务增长的需要，软件产线升级和售后问题急需解决；难以匹配行业发展趋势和公司战略（软件信息安全、行业标准、国际合作等）要求。

       为解决此问题，通过行业对标和技术、业务可行性分析，需要建立企业级的软件过程开发管理平台，同时对现有PLM系统和相关关键业务信息系统进行改造或集成，实现企业级软件数据的全生命周期管理，提升产品质量和效率，提升未来企业的竞争力。

       2.1 建设前业务现状

       2.1.1 软件开发过程（ALM）缺乏统一完备的企业级过程管理

       当前公司存在两种软件开发模式：一种是软件自主开发，另一种是委托供应商开发软件。

       实现软件自主开发的控制器，当前初步具备部分软件需求定义、建模、代码编写、配置管理、测试验证等能力，已使用部分工具支持软件开发，如Matlab、Rational、SVN等开发管理工具链，但未建立相应的软件过程开发管理平台，集成管理整个软件开发过程，同时缺乏相应的标准和流程规范。

       委托供应商开发软件的控制器，通过手工文档管理设计及验证功能层级需求。网络诊断部分软件有相对完整的设计及相关工具链验证，但未开展软件层级需求定义及测试验证，当前测试验证缺陷通过表格文件等形式线下管理；同样未建立相应的软件过程开发管理平台，集成管理整个软件开发过程，同时缺乏相应的标准和流程规范。

       以上导致如下问题：

       1）技术开发层面需求没有条目化，也无法与测试用例关联。

       2）协同层面在线下角色分散，协同性低；开发进度管控困难。

       3）追溯层面无法精确追溯。

       4）法规层面不符合ASPICE等要求。

       2.1.2 嵌入式软件数据发布、变更(PLM)及应用管理(下游系统)未形成闭环

       1）软件仅在PDM系统中管理了数据包，并无软件BOM。

       2）与硬件BOM无关联。

       3）软件BOM/软件配置字文件/软件包在各自独立的系统中管理，未统一传递至产线。

       4）针对OTA/售后系统需要的软件包还是线下传递，无系统统一源头。

       以上情况导致以下问题：

       1）导致生产/售后软件数据版本出错率较高。

       2）软件数据源不统一，上下游信息不互通，一致性和匹配性无法保障。

       3）软硬件兼容性关系无法管理。

       4）软件随硬件供货，库存多、呆滞件多。

       2.2 建设前信息化系统现状

       1）多头分散管理多种数据，形成烟囱式系统。

       2）系统之间无集成，需要人工处理数据后合成。

       3）响应不及时、不准确。

3 体系建设总体目标

       构建贯穿产品规划、研发设计、生产制造、售后服务的软件数据发布变更及应用，如图1蓝图所示。

体系建设蓝图 

图1 体系建设蓝图

       1）实现软件开发技术能力的拓展，搭建软件开发过程管理平台，实现软件全生命周期管理。

       2）通过研发-生产-售后等关键业务系统的改造/集成，统一数据源，实现软件数据发布、变更和应用的一体化管理。 

       3）建立软件全

       周期的数据管理的系统、方法、标准、流程。 

       4）实现业务和系统的平稳上线。

4 业务体系与流程规范

       4.1 软件开发过程体系

       确定以项目管理为单位来管理整个ECU软件开发过程。从项目启动开始，结合软件工程的行业最佳实践，将整个软件生命周期划分为需求分析、架构设计、详细设计、开发、集成与测试、软件产品验证、版本发布和产品发布阶段。将公司当前的软件研发业务分为自主研发和外协两个板块：自主研发涉及上述阶段的每一个活动；外协业务是DRE负责向供应商提需求，由供应商完成软件开发，交付最终软件产品和刷写完成的控制器零件。两个板块最终的软件产品验证需要通过测试，然后将可刷写的软件介质发布到PDM系统，与PDM软件数据管理模块对接，为后续控制器软件的生产线刷写和售后刷写提供数据来源。

       在整个软件的生命周期当中，引入缺陷和变更管理，以确保所有缺陷得到修复，所有变更相关的受影响对象版本一致，变更过程可控。

软件开发过程总体业务流程 

图2 软件开发过程总体业务流程

       由图2的业务流程可知，完成了以下相关内容：

       1）定义了开发过程相关过程域的范围和活动要素。

       2）明确了软件开发过程中的关键角色和职责定义。

       3）理顺了业务流程中的各个业务阶段的活动和输入输出关系。

       4）定义了各业务活动的详细子流程和工作内容（本文略）。

       5）明确了自主开发软件过程版本发布（ALM）和产品最终版本发布（PDM）之间的关系、过程。

       4.2 软件发布变更及应用体系

       公司规划了软件研发过程管理、整车软件实体数据管理、发布/变更管理、软件应用，通过构建涵盖上下游各部门的业务流程和标准，支撑软件相关数据从研发到生产及售后的全生命周期管理与应用。

       该流程主体由公司研发部门对软件实体数据和BOM关系数据进行统一的管理，生产工艺部门、制造负责对电检设备参数的维护与应用，售后服务包括（OTA和DMS）负责对售后相关数据的维护与应用，具体见图3。

软件数据发布变更及应用刷写一体化管理解决方案业务流程 

图3 软件数据发布变更及应用刷写一体化管理解决方案业务流程

       由图3的业务流程可知，完成了以下相关内容：

       1）定义了软件主数据模型（编码规则、名称定义、层级结构、属性定义等）。

       2）构建了与公司EBOM匹配的全配置软件BOM方式和业务模型。

       3）完成了软件配置选项纳入整车工程配置表管理的业务定义。

       4）完成了从全配置BOM到单车解算的方式和业务传递方式。

       5）统一发布源头，全过程由发布变更体系管控。

       6）整合了上下游的业务资源，明确了职责定义，实现了业务上的无缝衔接。

       7）定义了各业务活动的详细子流程和工作内容（本文略）。

5 信息系统及集成建设

       5.1 软件开发过程管理系统

       构建了以ALM为核心系统的管理平台，通过对业务体系的适配，管理了软件过程的相关数据和流程控制，做到数据源的统一。详细的系统框图见图4。

       在ALM系统中通过标准项目模板，裁剪成适合自主研发/外协业务场景的单个ECU项目来管理各自软件开发过程，包含需求、设计、测试及变更的过程，测试通过后对ECU进行产品发布，通过接口将软件数据集成至PDM系统。同时通过与SVN的集成，将软件的源代码进行了双向追溯管理。

软件开发过程系统框图 

图4 软件开发过程系统框图

       5.2 软件发布变更及应用系统群及集成

       软件开发过程的数据在ALM系统中管理，在达到特定的成熟度通过变更系统的发布流程，驱动软件数据到PDM系统，PDM系统中软实体数据与软件BOM、配置字文件数据按单车集成后，通过整车软件BOM发布流程发布到软件仓库。软件仓库作为企业软件数据中台与下游系统进行集成，实现数据在研发、生产、售后领域的交互集成。详细系统框图见图5。

软件数据发布变更及应用系统框图 

图5 软件数据发布变更及应用系统框图

       5.2.1 PDM系统与ALM系统集成

       ALM系统中的软件数据在达到EX的成熟度时，由ALM系统将代码编译后的软件实体数据推送至PDM系统中。

       5.2.2 PDM系统与BOM系统集成

       由于采用全配置BOM的方式管理软件BOM，同时业务上定义了软件配置项纳入整车工程配置表管理，软件的配置项会统一在BOM系统的配置模块管理，且单车的定义采用与硬件相同，需要从BOM系统中同步单车节点和配置项至PDM系统。

       5.2.3 PDM系统与配置字系统集成

       配置字是用于定义单车功能开关量的文件，此文件需要随同单车软件BOM同时下发，需传递至PDM系统中。

       5.2.4 PDM&变更系统

       1）管理软件主数据（软件编码、名称、结构、属性等）。

       2）将从BOM系统传递过来的单车节点作为整车数据源头，在其下按照配置用法搭建的形式搭建全配置软件BOM。

       3）将软件主数据、配置字文件与软件BOM关联。

       4）通过变更系统驱动数据发布和上下游传递过程。

       5.2.5 PDM与数据仓库集成

       整车软件数据发布后，PDM系统将相关配置车型的软件BOM、实体数据、配置字通过接口解算出单车的数据并存放于数据仓库中。

       5.2.6 数据仓库与MES/ECOS集成

       数据仓库定时将单车软件数据传递给MES，MES将需要生产车型的数据发送给ECOS设备，设备在整合数据后同时通过数据仓库接口拿到所需软件实体文件，进而在制造车辆上完成点检、刷写等一系列动作。

       5.2.7 数据仓库与OTA/DMS系统集成

       数据仓库将所需的软件实体推送给OTA/DMS系统，满足后续升级需要。

6 结论

       本次的体系和系统建设是一次创新，在业务基础薄弱、涉及的上下游部门/系统众多、部门业务没有行业先例的情况下，将整个软件开发从过程管理到发布应用整体梳理和设计了一番，通过整个团队的不懈努力，基本达成了既定目标，成果可总结如下：

       1）整体引入了业内先进的ALM系统平台，当前软件自主开发业务已有序在系统中开展。

       2）软件开发过程的能力和水平稳步提升。

       3）将原本线下业务零散模式整体搬到线上，实现了数据同源、同质、同标。

       4）发布了数十项企业级技术标准和管理流程，在内部首次对相关业务“有法可依”。

       5）明确了软件BOM相关定义和边界，当前所有新电子电器平台车型已全部定义相关主数据和BOM。

       6）实现了自动化的软件传递，当前软件数据的传递均由系统自动/驱动完成，减少了大量的人工传递级核对时间。

       7）打通了软件开发过程（ALM）与最终发布(PDM)及应用（下游各系统）之间的系统集成，初步做到了全生命周期管理。

       在车企软件管理作为新生事物，通过一次的体系建设必然有所不足，当前仅仅是将基础的相关内容建设完成，展望未来，后续体系还会向支持敏捷开发模式、海外KD、备件、机电软协同设计等各个业务领域延伸。

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

相关文章

  • 敏桥PCP端到端PLM方案面向汽车零部件上下游研发全流

    敏桥 PCP 端到端 PLM 方案，专门面向汽车零部件企业，打通上下游研发全流程。 当前国内汽配企业，不管是内外饰、底盘还是传动系统，市场压力都很大：一方面要满足 IATF16949、APQP 这...

    敏桥

  • 敏桥PLM：汽车行业的全方位得力助手?

    敏桥PLM：汽车行业的全方位得力助手? 敏桥PLM在汽车行业的应用广泛且深入，为汽车企业带来诸多变革。 在长城汽车中，敏桥科技助力其BOM数据一元化平台建设新一代PLM，二者共创平台...

    敏桥