发布时间:2026-04-30 13: 28: 13
汽车研发正在从“机械制造主导”转向“软件、电子电气、系统工程共同驱动”。一辆车里,智能座舱、车联网、辅助驾驶、域控制器、网络安全、OTA升级等内容越来越多,研发团队要处理的已经不只是零部件开发,而是一整套复杂系统的协同交付。
IBM Engineering Lifecycle Management,简称IBM ELM,面向汽车OEM和供应商提供系统与软件工程管理工具组合,帮助企业在产品复杂度上升的同时,缩短周期、提升质量,并持续推出新功能。IBM汽车行业页面中也提到,ELM可以把需求、设计模型、测试和工作流程关联起来,形成跨开发团队的生命周期可见性,同时支持ASPICE、ISO 26262、SOTIF、ISO 21434和WP.29等标准要求。
一、汽车研发为什么需要更完整的生命周期管理
汽车行业的变化很明显:功能越来越多,软件占比越来越高,法规和客户要求也越来越细。过去靠文档、表格、会议推动研发,到了智能汽车时代就容易吃力。需求一旦分散,测试很难闭环;变更一旦没有记录,质量问题就可能被带到后期。
在实际研发中,汽车企业经常会遇到三类问题:
1、需求链条越来越长
客户需求需要被拆解到系统、软件、硬件、测试和交付文件中。如果中间缺少追溯关系,团队很难判断每一项需求是否真正被实现、被验证。
2、测试与认证压力更高
汽车软件和电子电气系统需要经过MIL、SIL、HIL等不同层级验证。IBM ELM支持开发和管理相关测试用例,并将需求、测试平台和测试结果关联起来,减少测试结果与研发数据脱节的问题。
3、复用和变体管理更复杂
同一平台可能衍生多个车型,不同产品线之间也会复用设计、功能和架构。如果没有统一管理,复用不一定带来效率,反而可能带来版本混乱和质量风险。
所以,汽车研发管理的重点已经不只是“把项目排好期”,而是要把需求、设计、代码、测试、缺陷、变更和合规证据放到同一条工程链路里管理。
二、诺博科技:从离线流程走向数字化研发平台
诺博科技的案例,体现的是智能汽车供应商在快速发展中遇到的典型问题。作为诺博汽车旗下专注智能汽车软硬件技术和产品的高科技公司,诺博科技面对智能座舱、智能车辆控制、车联网和智能驾驶等业务。随着产品快速量产和全球化进程推进,传统纸质文档、离线表格和人工流程已经很难支撑研发节奏。IBM案例中提到,诺博科技过去仅测试管理方面,就有约95%的信息通过离线文字处理和电子表格管理,原有XRAY插件也无法支持超过80,000个测试用例。
这类问题表面看是工具容量不够,深层其实是研发数据没有连起来。需求、测试、缺陷、变更、代码各自分散,管理层很难实时掌握项目状态,团队也很难支撑平台化和多车型复用。
引入IBM ELM后,诺博科技与IBM共同搭建了适用于多个产品线和多种车型平台的ELM框架。在需求管理和设计管理中,系统、软件、硬件、结构四类需求模块被纳入统一管理,并设计了24种明细化需求工件和约90种字段属性。以智能座舱IN9.0为例,客户需求、系统SRS要求、系统架构设计、软件要求和软件架构设计之间形成了清晰追溯链。
更关键的是,平台真正进入了日常业务。新系统自2023年4月起全面投入使用后,诺博科技已实施项目管理、问题管理、发布管理、变更管理、质量管理等11个在线业务流程,并推出约70个在线流程表单。过去测试进度可能要两周到一个月才能汇总,现在测试结果可以每天上传和刷新,相关人员能够随时查看整体进展。
三、延锋汽车:把质量管理做成可视化过程
延锋汽车子公司延电科技的案例,则更突出质量追溯和客户要求。IBM案例显示,在一个项目中,头部汽车客户要求延电科技获取Automotive SPICE认证,并提供从客户需求到系统、软件、架构设计和测试用例的详细可追溯性。此前延电科技主要采用电子表格,粒度和维护效率都难以满足客户要求。
为此,延电科技与IBM合作共创ELM平台,采用DOORS Next Requirement Management、Rhapsody Design和Engineering Workflow Management等模块,分别支撑需求管理、架构设计、任务管理、变更管理和缺陷管理。通过这些能力,企业可以量化评估需求管理、设计和测试用例质量,并提升软件产品质量状态的实时可见性。
这个变化并不是把Excel换成系统那么简单。过去,团队很难看到质量管理全貌;现在,需求完成情况、设计覆盖率、测试覆盖率等信息可以通过IBM ELM工具链呈现,质量管理也从后期被动检测,逐步转向前向控制和预测。IBM案例还提到,延电科技曾在2019年通过大众汽车Automotive SPICE Level 1评估,并于2020年通过Automotive SPICE Level 3评估。
四、两个案例给汽车行业的启示
诺博科技和延锋汽车的情况并不完全相同,但它们指向同一个问题:汽车企业做数字化研发管理,不能只停留在工具替换层面。真正有价值的是,把研发过程中最容易断开的关系重新接上。
1、让研发状态更透明
项目状态不再只靠会议汇报,而是能从需求、任务、测试、缺陷和质量数据中直接看到。
2、让变更影响更清楚
一次需求调整或代码变更,可以沿着追溯链看到它影响哪些设计、测试、缺陷和交付内容。
3、让合规准备更日常
ASPICE、ISO 26262、SOTIF、ISO 21434、WP.29等要求,最终都离不开过程证据。把证据沉淀在日常研发里,后期审查和客户审核才不会变成临时补课。
结语
汽车行业进入软件定义和系统协同的新阶段后,企业的竞争力不再只体现在单个功能点上,也体现在研发体系是否清楚、质量状态是否可见、合规证据是否完整。IBM Engineering Lifecycle Management在诺博科技和延锋汽车案例中的作用,就是帮助企业把分散的研发活动变成可追溯、可复用、可量化的工程过程。
对汽车OEM和供应商来说,数字化研发管理不是锦上添花,而是复杂产品持续交付的基础能力。研发链路越清楚,问题越容易提前暴露;质量数据越透明,项目越容易稳定推进。
展开阅读全文
︾
读者也喜欢这些内容:
IBM工程生命周期管理金融服务行业成功案例
金融服务行业的数字化,早已不是简单把线下业务搬到线上。银行、保险、资本市场机构每天都要处理大量系统变更、产品迭代、客户体验优化和监管要求。业务部门希望新服务尽快上线,技术团队要保证系统稳定,合规团队又要确认过程证据完整。几股压力同时出现时,软件交付就不只是开发问题,而是研发流程、质量管理和监管准备能力的综合考验。...
阅读全文 >
IBM工程生命周期管理公共基础设施行业成功案例
公共基础设施项目很少只是“把工程建起来”这么简单。以铁路、隧道、城市交通、桥梁等项目为例,背后往往牵涉业主单位、设计团队、施工单位、承包商、供应商、监管机构和公众安全责任。项目周期越长,需求越容易变化;参与方越多,信息越容易分散。也正因为如此,公共基础设施行业越来越需要一套能够贯穿需求、设计、协作、验证和交付全过程的工程管理方式。...
阅读全文 >
IBM Engineering Rhapsody如何进行系统建模 IBM Engineering Rhapsody系统建模能解决什么问题
很多团队一提到系统建模,最先想到的还是把需求、架构、行为和测试分散放在几套文档里维护,结果前期看起来清楚,后期一改需求就很难一路追到设计、仿真和实现。按IBM官方资料,Engineering Rhapsody的定位本来就是一套面向MBSE的系统与软件建模环境,支持SysML和UML建模,也支持仿真、需求管理、代码生成和生命周期追踪。所以它更适合做的,不是单独画几张图,而是把需求、架构、行为和验证放进一套连续模型里。...
阅读全文 >