原创 汪阳 2025-03-20 19:02 陕西
软件定义汽车新挑战：软件能力已成为车企核心竞争力的关键要素，本文将探讨汽车软件研发面临的挑战及其应对之法。
随着软件定义汽车（SDV: Software-Defined Vehicles）技术的快速发展，汽车产业正经历从传统机械时代向电动化、智能化时代的深刻变革。软件在汽车中的比重显著提升，软件能力已成为车企核心竞争力的关键要素。
相较于汽车机械和硬件领域业已成熟的研发体系，汽车电子软件的研发流程尚存在明显差距。现阶段，汽车软件研发还未构建起严谨的质量管理体系以及标准化的开发流程，其开发模式常常具有临时性与分散化的特点，这种模式也被形容为“草台班子”，“小作坊”式。这种"小作坊"式的开发模式直接导致了软件质量的波动性和不可预测性，给汽车软件带来了潜在风险。
本文将探讨汽车软件研发面临的主要问题与挑战，以及行之有效的应对之法。
汽车软件研发面临的主要问题
众所周知, 在机械燃油时代，汽车功能的复杂度相对较低，各个控制器都是独立开发，软硬一体，软件功能很有限，因此这种软件开发方式并没有明显的问题。
但在智能化时代，汽车功能呈现爆发式增长，汽车电子电气架构也从分布式独立控制逐步走向了集中式中央控制器模式。
汽车软件的复杂度也指数级增长，据统计，当前一辆具备 L2++ 智能辅助驾驶的汽车, 纯软件代码量就超过了 1 亿行，远超传统燃油车时代的规模。
汽车电子电气架构演进 | 软件代码规模对比 |
Example of E/E Architecture Evolution. Source: Bosch | Source：https://informationisbeautiful.net/visualizations/million-lines-of-code/ |
随着市场竞争加剧，车企整车项目研发周期从48个月缩至18个月。在巨大时间压力下，汽车软件研发面临严峻挑战，许多软件未经全面测试就匆忙上车，期望通过OTA升级解决质量问题。但这种做法过于理想化，既无法确保软件可靠性，还可能引发潜在安全风险。
据相关数据显示，近些年由于软件问题引发的召回事件，占车企所有召回事件的 30% 以上。
数据来源：市场监督总局官网和相关网上报道
|
和电子消费品不同，汽车软件质量直接关乎驾驶员及道路参与者的人身安全，必须引起足够重视！
只有了解汽车软件质量问题频发的根源，才能更好地进行针对性的解决。软件质量问题往往不容易量化和度量，管理者缺乏有效手段来洞察系统中潜在的质量隐患，因而难以做出客观的决策，常常陷入“头痛医头，脚痛医脚”的被动局面。
汽车软件质量问题的根源主要体现在以下几个方面：
1. 汽车软件代码规模与复杂度激增
随着汽车智能化的发展，软件代码量呈指数级增长，复杂度也随之大幅提升。代码规模越大、逻辑越复杂，出现漏洞和缺陷的可能性就越高，这对软件质量提出了严峻挑战。
2. 软件开发缺乏统一标准
尽管软件行业中存在 CMMI（能力成熟度模型集成）和 ASPICE（汽车软件过程改进与能力评定）等过程能力模型，但这些标准在实际应用中缺乏具体指导。传统的 V 模型灵活性不足，难以应对快速迭代的需求；而 Agile 模型虽然灵活，却无法完全满足汽车行业对合规性、质量与安全的严格要求。
V-Model |
3. OEM与供应商合作中的质量管控问题
主机厂对供应商的质量管控能力不足，导致在系统集成阶段容易出现兼容性和完整性问题。此外，供应商通常采用黑盒交付模式，使得软件系统的可追溯性较差，问题定位耗时且效率低下。
4. 质量保证未贯穿软件开发全生命周期
主机厂仍沿用传统的测试思维，将质量保证集中在开发后期的测试阶段，依赖人力堆砌来解决问题，而非基于“预防大于发现”的原则。这种模式难以应对复杂软件系统的质量要求。
5. 软件开发过程不透明且缺乏数据驱动
软件开发过程的有效性缺乏科学的评价手段和度量方法，主要依赖经验主义，而非数据驱动的决策思维。这种不透明性导致问题难以及时发现和解决，进一步加剧了质量风险。
应对质量问题的策略与实践
要解决这些问题，必须从根源入手，通过透明化开发过程、强化标准执行和指导方法、优化合作模式以及引入数据驱动的质量管理方法，构建贯穿全生命周期的汽车软件质量保证体系，才能真正提升汽车软件的质量与可靠性。
序号 | 问题 | 解决策略关键要点 |
1 | 软件复杂度激增 | 解耦，模块化设计，减少代码耦合。建立组件复用策略和代码复用库。 |
2 | 软件开发缺乏统一标准 | 推广和实施行业标准，如 ISO 26262 和 ISO 21324；结合敏捷开发方法与传统的V模型，如 Agile + ASPICE，构建多态研发体系，以提高灵活性并满足合规性要求。 |
3 | OEM 与供应商协作问题 | 建立明确的合作伙伴关系和沟通机制；实施供应商质量管理, 将供应商纳入整体开发节奏中；要求供应商提供源代码或至少是足够的文档，以提高可追溯性和问题定位的效率。同时将供应商纳入持续集成体系中。 |
4 | 质量保证未贯穿整个软件开发过程 | 质量内建（Built-in Quality），测试左移，端到端质量保障，在开发早期阶段引入质量保证措施，如设计审查和代码静态分析。 |
5 | 软件开发过程不透明，缺乏数据驱动 | 使用敏捷方法和 DevOps 实践来提高透明度和响应性，构建汽车研发度量体系，建立质量 KPI 体系；采用度量和分析工具来监控软件开发过程，如使用度量数据来指导决策。 |
基于上述的解决策略要点进行归类后，我们可以围绕 PPT (Process, Methods, Tools) 三个维度来构建端到端汽车软件研发质量保障体系，系统性解决汽车软件质量问题。
流程改进
流程/过程质量决定产出质量，高效的研发流程是保障软件质量的基石。
汽车电子软件研发涉及到软硬件集成，大规模协作，供应商管理等方方面面，一个ADAS系统开发动辄数百上千人的研发人员，也使得软件研发管理的复杂度剧增。
但是随着软件复杂度的增加，软件研发效率却无法及时跟上节奏，复杂度与效率矛盾日益突出。
汽车行业软件开发主要有以下三种主流的开发模型：
对比维度 | 瀑布开发模型 | 敏捷开发模型 | 双态开发模型 |
关键特点 | 用户需求明确，项目开发周期内需求极少发生变化 | 用户需求复杂且具有不确定性，需求变化快，重点是快速创新以快速获得市场反馈 | 整体需求即有相对明确的部分，也有一些需要在迭代中逐步明确的，需求变更相对可控 |
质量要求 | 有严格的质量要求，对文档和标准化有高要求 | 对质量有一定的容忍度，允许持续改进 | 对质量有一定的要求，需要产品保持较高的稳定性 |
应用场景 | 该产品有严格的汽车行业开发规范要求，如 ISO-26262功能安全要求，ASPICE 要求等。 | 该产品一般不涉及汽车核心控制系统，主要是偏用户体验，如座舱娱乐 APP，车主 APP ，车云系统，IT 支撑系统等 | 该产品一般是汽车中间件，操作系统等底层软件，一般底层与硬件结合的部分采用瀑布式 V 模型，而偏向应用层 ASW 则采用敏捷开发模式，形成的 Agile-V模型。 |
车企需要基于不同的业务类型和复杂度，选择合适的开发模式。深刻理解康威定律和复杂性理论，调整组织结构和角色职责以适应开发模式。
以双态开发（Agile+V Model）为例，将 ASPICE 等合规性要求融入到具体的敏捷活动中去，既满足流程合规又能发挥敏捷开发的作用。
|
方法实践
仅仅有流程规范是远远不够的，因为在实际操作过程中，动作很容易会发生变形，只有有效且可落地的方法才能够更好地满足流程要求。CMMI 或者 V 模型之所以在车企软件研发中越来越难提升质量和效率，其根源就在于缺乏有效的质量保障方法来进行指导。
1.需求工程优化
有好的需求产出，项目就已经成功了一半。
然而需求质量低，是大部分车企面临的主要痛点。需求阶段主要的问题有：需求不清晰，需求描述不规范，需求结构混乱，需求的跟踪管理失控等等。
需求阶段我们通过需求的分层与结构化，需求开发与需求实施解耦等方式，来提升需求管理和需求传递的质量。
需求分层 | 需求结构化 |
| |
通过合理的需求分层结构设计，将问题域逐步细化到解决方案域。 | 通过需求结构化有助于需求的传递，避免出现需求描述不清晰，验收标准不明确。 |
需求实施与任务管理 | |
| |
通过需求条目拆分到实施任务，将需求与实施解耦，来支持特定车型需求和平台性需求复用等场景的开发管理。 | |
2.架构设计改进
设计阶段，车企面临的主要挑战在于，如何确保设计的一致性，如何平衡设计与变更的工作量，以及如何进行高效的设计。
因此，我们建议首先在架构信息层面对齐认知，优化架构设计方法与工具，引入高效的架构治理实践。
·架构信息模型
在复杂的项目中，统一架构信息元素的概念非常重要，比如 Component 的定义，在不同的领域是不一样的。保持所有人的认知对齐，能够更好地帮助管理架构实施活动。
|
·软件架构设计
架构设计在软件开发的整个生命周期中占据着举足轻重的地位。它不仅关乎技术的实现，更直接影响到软件的可维护性、可扩展性和性能。一个精心设计的架构能够确保软件在未来的迭代中保持灵活性和高效性。
通过 Document as Code. Arch as Code的设计理念，构建轻量化的架构设计解决方案，并且引入持续架构设计，演进式架构设计方法，C4 模型，架构决策记录 ADR，架构评估委员会 TAB等实践，帮助组织高效管理架构活动，最大化架构价值。
·软件详细设计
在当前敏捷开发模式下，很难先完成详细设计文档基线后，然后再写代码。但是也不能没有详细设计文档，只有代码。详细设计不仅仅是车载软件合规性的要求，也是后续软件维护的重要保障。因此我们建议构建持续增量式软件详细设计，同时详细设计与编码活动交叉进行，而不是瀑布模式下的前后线性关系。
增量式详细设计关键特点：
1.迭代式设计：
a.将详细设计分解为多个迭代周期，每个周期都聚焦于一部分功能或模块的设计。
b.在每个迭代周期结束时，确保设计文档得到更新，并与代码实现保持同步。
2.最小化可行设计：
a.在设计初期，只关注最关键的设计决策和架构元素，确保系统的基础稳定性。
b.随着开发的深入，逐步细化设计细节，添加必要的功能和优化，满足合规性要求。
3.增量更新：
a.不试图一次性编写完整的详细设计文档，而是随着开发的进展逐步更新文档。
b.使用版本控制系统来管理设计文档的变更历史，确保可追溯性。
3.编码实践规范
基于大量的项目统计，编码阶段是引入缺陷最多的过程，其原因是多样的，比如企业对于代码内部质量的忽视，缺乏有效的编码规范和度量工具，一次性代码，没有考虑后续的扩展性，缺乏代码审查机制等等。
基于此，车企需要加强对于编码规范，代码重构与技术债管理，同行评审，质量门禁等活动的实践。
·编码规范定义
车企需要基于业界通用的一些编码标准（如 MISRA C/C++, AUTOSAR, CERT 等）和自身业务场景相结合，构建自身的软件编码规范，并将规则固化到一些自动化的代码检查工具中，对于无法自动化检测的规则，则需要纳入代码评审检查表中，进行人工的检查和确认，确保代码规范被完全遵守。
·代码提交规范
汽车软件开发是大规模协作的过程，因此制定和遵守开发纪律是一个合格开发人员的基本素养。企业需要制定完善的代码提交规范，确保代码提交的规范化和可溯源性。同时我们可以通过工具来自动检测每一笔代码提交是否满足规范要求，做到自动化审查。
如：某车企非常重视代码的回溯性，需要将需求和问题单与代码变更关联起来。为此，该企业实施了一项措施，即对代码提交信息（commit message）进行标准化配置。当开发人员尝试提交代码时，系统会自动验证提交信息中是否包含了需求或问题单的唯一标识ID。若提交信息中缺少ID，或者ID的格式不符合预设规范，系统将阻止代码提交，从而确保每一次代码变更都能准确地追溯到相应的需求或问题单。
·代码门禁
借助MR（合并请求）、门禁自动检查以及 Code Review（代码审核）来对研发流程予以一定的规范。所有的变更都必须经由MR来提交，并且要通过流水线上的门禁代码检查，这其中涵盖了静态代码检查和单元检查。只有当至少两位审核人员审核通过之后，变更后的代码才被允许合并到代码主干分支之中。
4.分层验证体系
车企在验证环节面临的主要痛点是测试活动覆盖不全，测试周期太长，问题反馈太慢，测试资源不足等。
·分层测试体系
我们建议车企构建清晰明确的分层测试体系，明确每一层级测试的目标和方法。
基于开源软件工具创建持续测试体系，在每一次软件版本发版后自动触发。分别通过单元验证，组件集成测试，软件测试、软硬件集成测试、真实外设环境下的系统测试、整车测试。其中单元和组件测试是分钟级别完成，硬件、系统与整车层面的测试能够在天级别内完成，从而加快各层级测试反馈。
| |
·测试有效性提升
在实践中，我们常常收到一线开发人员的反馈，单元测试和集成测试没有效果，反而耗费了大量的时间和精力等。这从侧面反映了我们测试设计有效性不足以及对于测试认知不足的问题。
因此加强测试活动，测试用例设计方法的培训与赋能，提升开发人员测试用例编写能力，是车企需要重点建设的地方。
工具支撑
根据麦肯锡的研究，引入标准化工具链可以提升30-40%的组织生产力。
流程也需要工具支撑才能保证有效执行，减少规则宣贯和人员跟进的工时损耗，同时减少信息孤岛。
·工具链搭建
好的需求、设计工具能够帮助高效地管理需求与设计活动，同时满足流程合规性要求。
如基于 Arc42 模板和Structurizr、Asciidoctor 等工具链构建的 document as code方式，能够提高架构师编写架构文档的效率，同时比传统的Microsoft Word离线文档方式，更便于架构的版本管理，协作开发等。
代码建模工具能够确保详细设计与实现的一致性，自动化测试工具的引入也能够极大提高回归测试的效率。
·构建软件工厂平台
如何将分散的工具链有机结合起来，需要从全局端到端的角度进行系统性的汽车软件研发DevOps 平台设计，打通工具链，构造研发组织级统一的 Software Factory。
同时基于安全内建（Built-in Security）与性能内建 (Built-in Performance)的理念，将安全与性能要求和活动融入到汽车研发 DevOps 端到端全流程中。
·数据驱动质量改进
改进才是目标，度量只是手段。基于数据建模方法构建度量指标体系，结构化研发过程数据和产品质量数据。通过不断沉淀研发活动数据，建立统一的数据看板 Quality KPI Dashboard, 将研发质量透明化, 可视化。
构建质量数据运营机制，如指标趋势分析，TOPN 问题根因与改进等等，可以帮助组织更好地利用数据，诊断问题，度量成效，指导改进。
以下表评估代码质量为例，基于 GQM 的度量方法，设计相应的度量指标。
目标 (Goals) | 问题 (Questions) | 数据指标 (Metrics) |
代码质量 | 1.代码是否100%基于详细设计文档中描述进行实现？ 2.代码是否100%满足编码规范，并且满足安全要求？ 3.代码是否具备可维护性，可测试性？ | 1.C0, C1覆盖率 2.代码静态扫描 Violation 数，Deviation 数 3.HIS-Metrics违规数 4.代码圈复杂度，注释密度 |
除了代码质量指标以外，还有过程性能指标，架构指标等其他维度，这里不做列举。
持续改进与以人为本
策略与方法是基础，但仅有策略和方法，是不够的，只有行动起来，从实践中持续获取反馈并调整改进，才是解决问题的根本之道。
软件定义汽车所引发的挑战涵盖了各个方面：包括思想观念、技术水平、工作流程、方法策略以及工具应用等。车企只有不断的迭代和创新，充分利用新技术，新范式，如 AI4SE, LLM 大模型等手段不断进行工程实践（如辅助需求编写，业务代码和测试用例生成等），才能从容应对当下的不确定性和复杂性。
最后，也是最重要的一点，软件研发仍然是人的创造性活动过程，因此所有的流程，方法设计均要以人为本，提升人的主观能动性，这是确保组织目标达成的关键。
