GB/T 48140—2026《汽车软件质量与缺陷管理规范》解读 | 附全文

1.1 产业阶段变了：从"硬件主导"到"软件定义"

《中华人民共和国国民经济和社会发展第十五个五年规划纲要》明确指出，加快智能网联新能源汽车等战略性新兴产业发展。随着自动驾驶、智能座舱、车用人工智能、车载操作系统等关键技术的广泛应用，汽车质量安全的内涵和外延都发生了深刻改变。智能网联新能源汽车的可靠性与安全性，将高度依赖汽车软件质量水平。

1.2 软件特性决定了管理必须升级

相较于汽车硬件，软件在设计、开发、部署、升级和迭代等全生命周期环节具有显著差异：软件运行过程的不直观性、不透明性，以及人工智能系统的不可解释性，使得传统基于硬件的质量管理方法难以适用。软件问题在整车系统中可能引发高风险等级的安全后果，其影响范围广、隐蔽性强，必须作为重点质量控制和安全验证对象。

1.3 填补国内空白，衔接国际实践

本文件在软件质量管理基础上，集成汽车功能安全（ISO 26262）、预期功能安全（SOTIF）、信息安全、人工智能安全、数据安全等特定要求，引入风险评估与缺陷管理理念，填补了我国汽车软件全生命周期质量与缺陷管理国家标准的空白。

本文件采用过程方法，融合PDCA循环与基于风险的管理思维，通过质量策划（Plan）、过程质量保证（Do）、关键过程评审（Check）、软件风险评估与软件缺陷管理（Act）四大关键活动，实现软件质量安全的过程控制。

核心逻辑解读：

• Plan（质量策划）：覆盖软件安全管理、计划管理、过程指标制定、历史问题规避、状态报告监控、风险管理、配置管理、评审管理、问题管理、变更管理等10项关键质量保证活动。

• Do（过程质量保证）：对策划、需求分析、设计实现、集成、验证确认、发布管理、升级与维护等关键过程实施管理。无论采用瀑布、螺旋、增量、敏捷、双态等何种开发模式，每个子循环均应参照这些关键过程的要求执行。

• Check（关键过程评审）：在软件项目策划、需求分析、设计实现、软件集成、验证确认5个关键过程开展评审，评审结果分为通过、偏差通过、不通过三类。

• Act（风险评估与缺陷管理）：通过持续的风险评估，实现缺陷识别前置和预防控制。

本文件适用于汽车产品生产者、软件提供方、供应链上下游为车辆提供软件产品或服务的组织、召回技术机构等。

适用软件类型包括：

• 车辆嵌入式软件

• 云端软件

• 车用人工智能软件

• 车载操作系统

• 基于人工智能的软件组件

• 移动端实时控制软件

适用活动类型包括：

• 全新开发

• 增量开发

• 现有软件的升级维护

4.1 软件安全管理

组织应结合本文件及适用的国内外软件产品相关标准开展质量策划。若涉及安全相关要求，策划内容应包括但不限于功能安全、预期功能安全、信息安全、人工智能安全、数据安全五大领域，明确安全管理目标、安全管理活动、相应交付成果及评审计划。管理范围应覆盖产品生命周期全过程，包括需求、设计、实现、验证、确认、发布及运维阶段。

4.2 计划管理

软件项目计划应包括：项目目标和交付物特征范围、人员角色职责、子任务分解、资源明细、时间计划、沟通计划、软件验证计划（可实施分级管理）、维护计划、软件发布计划、培训计划等10项内容。若采用迭代开发模式，需按迭代周期逐次制定计划。

4.3 过程指标制定

组织应统筹规划并持续监控软件开发全过程指标，包括：

4.4 历史问题规避

组织应收集相关的监管信息、召回信息、客户反馈及项目过往发生的问题，在新项目开发初期制定问题规避计划（包括设计和验证），针对历史问题的整改优化成果应开展验证确认。这一要求将"经验教训"从口号变成了强制性的管理动作。

4.5 配置管理

组织应在软件开发启动阶段制定并发布配置管理计划，明确配置项及其接口的管理流程、方法与工具。配置管理计划包括职责分工、基线标准、配置项变更控制流程、配置系统工具和存储库、统一命名规范、构建环境、版本构建方法、发布文档生成方法、软件发布传递机制等14项内容。

关键要求：各方应使用指定且一致的构建环境；确保每个版本均由受控配置项构建，保证版本完整性。

4.6 问题管理与变更管理

问题管理：以唯一标识跟踪并推动问题解决，保证问题到根本原因的可追溯性。问题类型包括管理类、技术类、安全类、历史发生的问题、流程不符合问题。所有当前尚未关闭的软件问题信息应在软件交付说明中记录或引用。

变更管理：变更请求的来源包括内部需求变更、相关方或用户需求变更、软件问题引发的变更、硬件变更引发的软件变更等。影响分析应涵盖技术、项目、成本、质量、功能、兼容性、系统资源、安全性、制造、环境、法律法规等13个维度。

5.1 需求分析

项目应设计和构建适用于软件需求管理的体系，管理所有软件需求（包括相关方需求和组织内部需求），建立外部需求与软件需求的追溯性。针对人工智能需求，应建立人工智能需求和软件需求之间的追溯性，识别和说明人工智能需求相关的数据特征及其预期分布。

交付物包括：软件需求、人工智能业务需求、人工智能数据需求、软件需求追溯矩阵、软件实现计划。

注：对于实施敏捷的组织，产品待办列表等同于软件需求，待办列表应定义DoR（就绪定义）和DoD（完成定义）。

5.2 设计实现

软件设计实现的关键要求：

• 基于明确的软件需求设计软件架构，通过结构化方法逐层分解，直至不宜再分的软件项

• 对复用软件（包括库文件、软件模块、软件组件、源代码含开源代码和商用现成产品）的合理性和应用限制进行分析，获得所有相关方认可

• 使用开源代码时，要评估许可证风险、安全风险、知识产权风险、法律风险

• 开发硬件/软件接口规范，明确软件配置规则

• 开展软件性能分析，针对系统各类潜在极端运行工况编制最坏情况分析报告，充分论证软件在最严苛的极限运行条件下，各项性能指标仍能满足规定的软件需求

最坏情况分析报告包含的内容：

人工智能设计实现的特殊要求：

• 构建含AI要素的专用架构，包含数据预处理、后处理及模型超参数

• 明确人工智能模型训练数据集，在人工智能实现环节增加价值观管控关键节点

• 涉及安全的人工智能相关软件，架构设计要兼顾鲁棒性、可靠性、可控性、可解释性和可预测性等基本特征

• 数据集构建过程中要保障数据准确性、完整性、独立性、代表性和时效性等基本特征

5.3 集成

软件集成采用分层、分步的方式有序开展，将独立或已完成集成的软件项逐级整合，最终形成符合软件架构设计要求的完整软件系统。

• 制定集成验证措施，对集成后的软件组件开展验证工作

• 硬件/软件接口规格是集成验证措施的输入

• 系统集成验证采用环境模拟方式开展，包括硬件在环模拟、车辆网络模拟、数字样机等技术手段

• 采用敏捷开发模式的组织，软件集成需实现自动化集成，并按需配套自动化集成测试

5.4 验证确认

项目应针对每一次软件交付编制验证计划。验证方式包括模拟验证、台架验证、泛化验证、实车验证等。应保证软件需求与对应验证措施唯一标识保持一致，建立双向可追溯关系。

软件安全验证范围包含但不限于：

5.5 发布管理

项目应制定软件发布计划，针对每次软件发布确定发布目的、发布标准，并识别所需配套的文档和发布对象范围。所有交付软件应配套完整交付文档，至少包括：

• 软件交付说明（含构建环境、软件版本号、硬件部件号、资源包信息、需求实现情况和验证状态、现存问题、硬件/软件依赖项、对相关方的影响）

• 软件验证报告

• 各项需求的开发完成状态和验证状态说明

5.6 升级与维护

项目应编制软件维护计划，明确全生命周期软件维护的人员、设备保障要求，规范全周期软件维护活动的实施方式。明确软件升级与维护的职责分工，界定维护主体为软件开发单位或第三方服务机构，必要时应签订正式服务协议。

为对软件质量和缺陷进行有效的过程管理，应在汽车软件实现过程中的5个关键过程开展评审活动：软件项目策划、需求分析、设计实现、软件集成、验证确认。

评审组人员构成包括：软件项目经理、软件项目管理经理、软件集成经理、软件架构师、功能安全专家、预期功能安全专家、信息安全专家、人工智能安全专家、数据安全专家、产品安全专家等。

关键过程评审根据软件迭代周期适当合并：

评审结果分为三类：

• 通过：整体按计划交付无风险，直接进入下一个阶段

• 偏差通过：整体存在一定的延期或质量问题，无高风险，允许存在中低风险，但中风险有影响分析和改进措施，评估组成员经过充分评估后达成一致意见，带风险进入下一个阶段

• 不通过：整体存在重大延误或高风险，会影响整车交付或整车质量，应立即采取改善措施并重新评估通过后才能进入下一个阶段

7.1 风险评估对象

软件风险评估对象包括但不限于以下环节发现的软件问题：

• 设计开发环节：方案策划、需求评审、技术选型、架构设计、设计实现、代码生成等过程评审活动及关键节点评审中识别到的软件质量问题

• 测试验证环节：软件单元静/动态测试、集成测试、系统测试、验收测试等活动及关键节点评审中暴露的软件质量问题

• 接收交付物时：对交付物进行验证过程中检查出来的软件质量问题

• 生产制造环节：软件封装、测试、产线下线检测（EOL检测）、整车测试等活动中暴露的软件质量问题

• 产品使用环节：市场索赔信息、用户反馈、网络舆情、用户投诉、市场质量信息报告、政府监管部门以及第三方机构反馈信息等

7.2 风险评估流程

软件风险评估应基于以下流程：

• 软件对系统影响的评估：确定软件问题对系统或整车可能产生的系统风险

• 系统风险评估：根据系统风险的严重性和可能性进行综合评估，确定风险等级

• 风险控制：根据风险等级制定相应的对策方案

• 效果评估：跟踪措施实施情况和验证措施的有效性

7.3 五级风险矩阵

系统风险严重性分为五级（高、较高、中、较低、低），可能性分为五级（高-必现、较高-频发、中-偶发、较低-发生概率较低、低-极少发生）。根据严重性等级和可能性等级，通过风险评估矩阵确定综合风险水平等级，分为5级：

7.4 差异化风险控制策略

对于已应用于在售汽车产品的软件版本：

对于未应用于在售汽车产品或处于软件开发过程中的软件版本：

汽车产品生产者应根据多个渠道收集和分析市场信息、顾客反馈、产品技术信息、政府产品安全监管信息等，按照第7章所述风险评估方法开展软件缺陷调查分析与评估，并根据评估结果制定解决措施与对策，进行软件缺陷认定与召回决策。

软件缺陷管理全流程：

8.1 信息收集与分析

汽车产品生产者应建立信息收集与分析工作程序，明确主要信息来源及内容，并对信息进行分类和综合性分析。信息来源包括但不限于：

• 法律法规要求

• 最终产品市场信息

• 服务热线和投诉信息

• 舆情监测信息

• 重大事故类信息

• 国内外同类车型召回信息

• 生产者内部信息

• 供应商报告信息

• 政府监管信息

8.2 软件问题识别与调查分析

汽车产品生产者召回管理部门应基于信息分析提取的共性问题，识别软件问题，从风险严重性、可能性等维度进行初步判断。软件提供方发现软件问题的，应主动向汽车产品生产者报告软件问题。

调查分析责任部门应基于软件问题表象，通过对开发过程包括需求分析、设计开发、集成、验证等活动的追溯，明确问题发生的根因和影响范围。

8.3 召回决定

汽车产品生产者召回管理部门应审议调查分析结果，作出召回决定并形成记录：

• 认定产品存在缺陷的：按相应的法律法规要求开展召回活动，消除车辆安全隐患

• 认定产品不存在缺陷的：应采取服务公告、自愿性在线升级等方式开展软件修复活动，向用户告知问题及解决方案，并根据相应的法律法规要求进行备案

• 尚不能判断是否存在缺陷的：应进一步开展信息收集与分析、调查分析与评估，必要时协调第三方机构开展测试与风险评估

8.4 召回实施的关键时限要求

8.5 召回过程管理与效果评估

• 汽车产品生产者应保持与召回相关方的沟通，发出明确要求与信息，并在召回备案的实施日开始针对特定范围的产品进行软件发布，采用在线升级、返厂刷写或更换零件等措施

• 基于在线升级方式开展召回活动，应按照GB/T 45493—2025《基于远程升级技术的汽车产品召回实施要求》执行

• 召回完成后，汽车产品生产者应对召回效果进行评估，评估方法按照GB/T 39603—2020《缺陷汽车产品召回效果评估指南》执行

9.1 对不同市场主体的影响

整车企业：需要建立覆盖软件全生命周期的质量安全管理体系，将软件缺陷管理纳入召回管理体系。头部车企凭借完善的软件研发体系和缺陷管理经验，将更快适应新要求；而软件能力较弱的车企，需要加快补齐短板。

软件提供方：标准明确了软件提供方在缺陷管理中的配合义务，包括主动报告软件问题、配合调查分析、准备修复软件等。软件供应商与整车厂之间的质量责任界面需要重新界定。

供应链上下游：配置管理、变更管理等要求将向上游延伸，芯片、操作系统、中间件等供应商需要提供更完善的软件交付文档和配置管理支持。

召回技术机构：需要具备软件缺陷的技术评估能力，包括代码分析、风险评估、修复验证等能力。

9.2 企业合规行动建议

2026年9月—11月（标准实施前）：体系建设冲刺期

• 对照标准要求，全面梳理现有软件质量管理体系的差距

• 建立软件缺陷管理专项流程，明确召回管理部门职责

• 完善软件交付说明模板，确保包含标准要求的全部要素

• 建立软件风险评估机制，培训相关人员掌握五级风险矩阵评估方法

2026年12月起（标准实施后）：持续运行优化期

• 将软件缺陷管理纳入企业召回管理信息系统

• 建立与软件提供方的协同工作机制，明确问题报告和配合调查的流程

• 定期开展软件风险评估演练，提升风险识别和处置能力

• 持续跟踪国内外软件召回案例，完善历史问题规避机制

GB/T 48140—2026《汽车软件质量与缺陷管理规范》的发布实施，是我国汽车软件治理体系建设的重要里程碑。这份标准不仅规定了技术要求，更重要的是建立了一套从预防到处置、从开发到召回的全生命周期软件质量与缺陷管理框架。

对于企业而言，合规不再是简单的"通过检测"，而是需要建立覆盖产品全生命周期的软件质量治理能力。在软件定义汽车的时代，软件质量管理能力将成为继制造能力、供应链能力之后的第三核心竞争力。

2026年12月1日，标准将正式实施。留给企业准备的时间已经不多了。

公众号后台回复"AES53"，自动获取GB/T 48140—2026 PDF完整版。