刚发布的《GB/T 48140-2026 汽车软件质量与缺陷管理规范》存在一系列问题- 大数跨境

首页

刚发布的《GB/T 48140-2026 汽车软件质量与缺陷管理规范》存在一系列问题

软件工程3.0时代

2026-09-24

导读：它更像一份"过程条款清单 + 召回导向的风险评估手册

（声明：本文代表AI和分析者个人的观点，不代表本公众号的观点）

2026年8月28日发布的 GB/T 48140—2026《汽车软件质量与缺陷管理规范》（12月1日实施），是我国首个面向"软件定义汽车"的软件质量与缺陷管理国家标准。它由缺陷产品召回技术中心牵头、主流车企与高校共同起草，把功能安全、预期功能安全、信息安全、AI安全、数据安全"五合一"地并入软件质量框架，并引入风险评估与召回处置——站位对、方向对、覆盖面广，作为"填补空白"的第一步值得肯定。

但通读全文（第4章质量策划、第5章过程质量保证、第6章关键过程评审、第7章软件风险评估、第8章软件缺陷管理），一个突出的感受是：它更像一份"过程条款清单 + 召回导向的风险评估手册"，而不是一套能真正驱动组织把软件质量做好的管理体系。具体问题如下。

一、框架问题：PDCA只是"贴标签"，没有形成闭环

标准引言自称"融合PDCA循环"，并做了如下映射：

质量策划（Plan）→ 过程质量保证（Do）→ 关键过程评审（Check）→ 软件风险评估与软件缺陷管理（Act）

（来自标准：GB/T 48140—2026）

这个映射本身就经不起推敲：

"过程质量保证（Do）"当了Do，但"质量保证"在国际惯例（ISO 9000、CMMI、ASPICE）里本就是监督与评价职能，属于Check范畴；标准把"保证"直接等同于"开发执行"，概念错位。
把"风险评估与缺陷管理"整章塞进Act，让Act变成了"事后处置+召回"，而不是"基于评估结果更新过程、更新规则、再进入下一轮Plan"的闭环动作。标准没有规定"上一轮问题资产如何反哺下一轮质量策划"，PDCA少了最关键的回流线。
没有"闭环证据"的要求：谁在什么条件下判定"纠偏有效"，纠偏结果如何进入过程资产（模板、规则集、门禁准则、回归基线），标准基本不涉及。

结论：PDCA是"画上去的"，不是"跑起来的"。

二、概念问题："策划"与"管理"混为一谈，真正的"质量计划"缺失

这是该标准最硬伤的地方。

1. 第4章"质量策划"名不副实。第4章标题是"质量策划"，但4.1开宗明义，讲的是建立"软件质量安全管理体系"，随后4.2~4.11罗列的是：软件安全管理、计划管理、过程指标制定、历史问题规避、状态报告监控、风险管理、配置管理、评审管理、问题管理、变更管理——这十项里绝大多数是"管理"职能，被整体装进了"策划"章。"策划"是个动作、是一次性的方案设计；"管理"是持续的运行职能。两者被强行合并，导致"策划"名存实亡。著名的朱兰质量三部曲是：质量策划、质量控制和质量改进。

2. 术语3.12对"质量策划（quality planning）"的定义本身就是项目管理。其定义为"划定目标和交付物范围，定义和管理项目或迭代目标和计划……"，这实质上就是项目策划，而非质量策划，成了笑话。质量策划的核心——质量目标、质量策略、质量指标阈值、质量活动与责任的匹配、质量门禁设置——要么缺席，要么散落。

3. 真正的"质量计划（Quality Plan）"缺失。全文只在6.2的“关键过程交付物清单”里出现过一次"软件质量管理计划"，却没有任何条款规定它由谁编制、包含什么、如何被门禁校验。而4.3"计划管理"列出的十项（a~j）是开发计划、资源计划、验证计划、发布计划、培训计划——全是"项目计划"，没有一份贯穿全局、可被门禁审计的"质量计划/质量控制计划"。

结果就是用户所说："搜'质量计划'搜不到，质量计划缺失，却留着一堆管理——牛头不对马嘴。"

三、内容缺失：质量文化与组织几乎空白，度量有"目"无"标"，改进无方法

1. 质量文化与质量组织缺失。标准没有一章、也没有一条谈"质量文化"、"质量方针"、"组织职责与权限"、"SQA/质量管理委员会"等。第5章虽出现"软件质量经理"（作为评审组成员），但其权力边界、独立性、否决权完全没有规定。没有独立的 SQA 组织与授权机制，所谓"质量保证"必然落空。这是全文最致命的缺口。

2. 度量只给"指标清单"，不给"用法"。4.4列出13类过程指标（覆盖率、缺陷密度、测试通过率、OTA成功率、ASIL达标情况等），但没有目标值、没有阈值、没有"触发什么动作、由谁负责、什么时限"。指标如果不与门禁和纠偏动作绑定，就退化成"报表数字"。

3. 质量改进缺少方法体系。标准多处提到"改进"、"避免重复发生"（4.9.6、4.10.6、6.9），但没有规定任何根因分析与改进的标准方法——8D、5Why、5A、鱼骨图、CAPA、有效性验证一概不提；也没有"改进资产化"要求（把结论沉淀为规范、规则集、测试用例库）。改进只能停留在个案修复层面。

4. 培训只出现在"计划清单"里。4.3 j) 提到"特定项目人员的培训计划"，除此之外没有能力（competence）要求、没有资质与授权规定。软件质量最终靠人，标准对此几乎不管。

四、汽车行业特性强调不足：有ASIL之"名"，无ASIL之"实"

引言反复强调"车规级"、"集成功能安全、预期功能安全、信息安全、AI安全、数据安全"，但这些安全维度在正文里大多只是"点到了"，没有转化为差异化的质量管理策略。

最典型的是ASIL（汽车安全完整性等级）：

全文仅在 4.4 过程指标里出现过一次——"功能安全指标：含安全目标ASIL达标情况……"。
没有任何一条要求"按ASIL等级差异化设计质量策略/流程/门禁强度/验证深度/证据要求"。

也就是说，无论QM等级还是ASIL D，标准给出的流程与证据要求几乎是同一条。而汽车行业质量管理最核心的方法论恰恰是风险分层、分级管控：高风险模块要更严格的门禁、更深的验证、更严的变更控制、更频繁的回归。"用一套流程跑所有风险等级"是这份标准与工程现实的脱节。

同样，信息安全（CAL）、SOTIF、AI安全的"特有能力要求"（如未知场景、数据集质量、可解释性）虽在正文有零星条款（5.3.2 人工智能设计实现一节相对较好），但未与质量门禁、质量策划、质量度量打通，安全与质量仍是"两张皮"。

五、风险管理："质量风险"没有站起来，进度与质量门禁的联动太弱

1. "风险管理"讲的是项目风险，不是质量风险。4.7 风险管理仅要求编制"风险管理清单"（风险描述、评估结果、优先级、处置措施、实施状态），通篇没有区分"质量风险"——如过程能力不足、验证不充分、追溯断链、配置失效、工具链不一致、供应链证据不可审计（这才是质量管理要关注的）。第7章的风险评估则是"软件问题→系统安全风险→召回决策"，是"缺陷风险/安全风险"，不是"质量风险"。用户所指"风险管理没有强调质量风险"，正在于此。

2. 进度管理有"监控"无"约束"。4.6 状态报告监控要求报告进度、滞后原因与追赶方案，但没有建立"进度与质量门禁的硬联动"：当回归时间被压缩、验证资源被削减时，门禁是否应加严？是否应判定"证据不足不予放行"？标准没有给出规则，等于把最现实的"交付挤压质量"问题留给现场自行想象。

3. 缺陷管理偏"事后召回"，前段预防机制弱。第8章从信息收集到召回效果评估，链条完整、执法属性强，但本质是"问题已经发生→评估→召回→修复"，与第4章的预防机制（历史问题规避等）之间的链路不清晰。缺陷管理的重心，应是一半在预防、一半在处置，而本标准的重心明显偏向后端。

六、其他值得追问的问题

"质量门禁"名不副实。第6章"关键过程评审"把门禁做成了"评审活动+通过/偏差通过/不通过"，但缺少门禁的准入/准出证据包、裁决权限、偏差接受条件与补救计划的硬规定，更像"会议"而非"准入控制系统"。
供应链质量只点到、不落地。范围适用于供应链上下游，但未规定供应商质量能力评估、证据交付接口、联合评审与审计机制。
评审人员构成"拼盘化"。 6.1 要求评审组包括质量经理、项目经理、集成经理、架构师及各类安全专家，但未规定独立性与能力资质，"自己审自己"的风险无解。
方法论偏"文档符合性"。对静态分析豁免机制（5.3.1.15）、最坏情况分析（5.3.1.9）等有较好要求，但对测试分层充分性、回归准则、自动化证据、可复现构建的证据深度要求仍偏泛。