软件也有＂国标＂了!GB/T 48140全解读:汽车软件从＂事后OTA＂到＂事前预防＂,12月1日实施

为什么汽车软件需要国标？

软件定义汽车的时代，一辆智能电动车的代码量已经超过亿行，软件复杂度呈指数级增长。随之而来的是软件缺陷多发、OTA召回逐渐成为常态。不少车型在测试尚不充分的情况下就推向市场，依赖后续OTA推送补功能、修问题，消费者实际上成了"公测用户"。

In the era of software-defined vehicles, the amount of code in a single smart electric vehicle has surpassed 100 million lines, and software complexity is growing exponentially. As a result, software defects have become frequent, and OTA recalls are gradually becoming the norm. Many models are launched onto the market before testing is complete, relying on subsequent OTA updates to add features and fix issues—effectively turning consumers into “beta testers.”

与此同时，供应链软件质量参差不齐，不同供应商的开发流程和质量标准差异较大；缺陷分级和召回标准也不统一，出了问题往往各说各话。行业亟需一套统一的规范，把汽车软件的质量管控从"事后补救"拉回到"事前预防"。

At the same time, the quality of supply chain software varies widely, with significant differences in development processes and quality standards among different suppliers; defect classification and recall standards are also inconsistent, leading to conflicting accounts when problems arise. The industry urgently needs a unified set of standards to shift automotive software quality control from “reactive measures” to “proactive prevention.”

GB/T 48140是什么？

该标准于2026年8月28日发布，2026年12月1日实施。核心方法论是PDCA循环加基于风险的思维，覆盖汽车软件的全生命周期。比亚迪、广汽等企业参与了起草工作，说明标准在制定过程中充分考虑了产业实际。简单来说，这套标准不是给车企增加 “paperwork”，而是要求在软件开发的每个关键阶段都设一道质量关卡，把问题尽量消灭在上市之前。

This standard was published on August 28, 2026, and will take effect on December 1, 2026. The core methodology combines the PDCA cycle with risk-based thinking, covering the entire lifecycle of automotive software. Companies such as BYD and GAC participated in the drafting process, indicating that the standard was developed with full consideration of industry realities. Simply put, this set of standards is not intended to increase “paperwork” for automakers, but rather to require the establishment of a quality checkpoint at every key stage of software development, thereby eliminating issues as much as possible before the product reaches the market.

5个关键评审节点

标准规定了5个关键评审节点，覆盖从立项到交付的完整流程。第一个是项目策划，明确质量目标、资源配置和风险识别。第二个是需求分析，重点审查需求的完整性和可测试性——需求写不清楚，后面一切都免谈。第三个是设计实现，包括架构设计和编码规范。第四个是软件集成，进行集成测试和接口验证。第五个是验证确认，完成系统测试和用户验收。这5个节点允许根据项目实际情况合并评审，但不能跳过。也就是说，车企可以提高效率，但不能省略质量把关。

The standard specifies five key review milestones covering the entire process from project initiation to delivery. The first is project planning, which defines quality objectives, resource allocation, and risk identification. The second is requirements analysis, which focuses on reviewing the completeness and testability of requirements—if requirements are not clearly defined, nothing else matters. The third is design and implementation, which includes architectural design and coding standards. The fourth is software integration, involving integration testing and interface verification. The fifth is verification and validation, which involves completing system testing and user acceptance testing. These five milestones may be combined for review based on the actual circumstances of the project, but they cannot be skipped. In other words, automakers can improve efficiency, but they cannot omit quality control.

软件风险分级管理

不是所有软件都需要同等强度的管控。标准引入了风险分级机制，区分安全相关软件与非安全相关软件，并划分为高、中、低三个风险等级。不同等级对应不同的管控强度——涉及动力、制动、转向等安全相关的高风险软件，评审和测试要求自然更严格；而娱乐系统等低风险软件，则可以适当简化流程。这种基于风险的差异化管理，既守住了安全底线，也避免了"一刀切"带来的效率损失。

Not all software requires the same level of control. The standard introduces a risk classification mechanism that distinguishes between safety-related and non-safety-related software, categorizing them into three risk levels: high, medium, and low. Different levels correspond to varying degrees of regulatory oversight—for high-risk software related to safety functions such as powertrain, braking, and steering, review and testing requirements are naturally more stringent; whereas for low-risk software, such as infotainment systems, procedures can be appropriately streamlined. This risk-based, differentiated management approach not only safeguards safety standards but also avoids the efficiency losses associated with a “one-size-fits-all” approach.

软件缺陷管理流程

标准还规范了软件缺陷的完整管理流程：从信息收集与分析（包括用户反馈和监测数据），到软件问题识别，再到调查分析与评估、召回决定，最后到软件升级（OTA）。每一步都有明确的要求和记录规范。

The standard also specifies a comprehensive management process for software defects: from information collection and analysis (including user feedback and monitoring data) to the identification of software issues, followed by investigation, analysis, and evaluation; the decision to issue a recall; and finally, software updates (OTA). Each step has clear requirements and documentation standards.

这意味着，未来OTA不再是车企想升就升、想怎么升就怎么升，而是需要纳入规范化的缺陷管理流程，升级前有评估、升级中有记录、升级后有验证。

This means that, going forward, OTAs will no longer be something automakers can deploy whenever and however they please; instead, they must be incorporated into a standardized defect management process, with assessments before deployment, documentation during deployment, and verification after deployment.

覆盖哪些软件？

标准的覆盖范围相当广泛，不仅包括车辆嵌入式软件，还涵盖云端软件、车用AI软件、车载操作系统、基于机器学习的软件组件，以及移动端实时控制软件。

The scope of the standard is quite broad, covering not only in-vehicle embedded software but also cloud-based software, automotive AI software, in-vehicle operating systems, machine learning-based software components, and real-time control software for mobile devices.

值得注意的是，AI软件和机器学习组件被明确纳入覆盖范围——这在汽车软件标准中是一个重要信号，说明监管层已经关注到智能驾驶等AI系统的质量管控问题。

It is worth noting that AI software and machine learning components have been explicitly included in the scope of coverage—a significant signal in automotive software standards, indicating that regulators have taken notice of quality control issues related to AI systems such as autonomous driving.

对车企和供应链的影响

标准实施后，车企需要建立健全软件质量安全管理体系，增加开发评审和测试投入，OTA升级将纳入规范化管理。同时，要求不会只停留在整车厂层面——供应商也需要遵循统一标准，这将推动整个供应链的软件质量提升。

Once the standard is implemented, automakers will need to establish and improve their software quality and safety management systems, increase investment in development reviews and testing, and bring OTA updates under standardized management. At the same time, these requirements will not be limited to automakers alone—suppliers will also be required to comply with the unified standards, which will drive improvements in software quality across the entire supply chain.

短期来看，部分车型的上市节奏可能因此放缓；但长期来看，统一的质量标准将减少后续缺陷和召回，整体提升行业的软件成熟度。

In the short term, this may slow down the launch schedule for some models; however, in the long term, uniform quality standards will reduce subsequent defects and recalls, thereby improving the industry’s overall software maturity.

AI软件的特殊挑战

标准明确覆盖AI软件，但AI软件的质量管理确实存在特殊挑战。机器学习模型的"缺陷"如何定义？端到端大模型如何进行充分的测试验证？模型迭代后的回归测试怎么做？这些问题在标准中给出了框架性要求，但具体落地仍需要行业在实践中不断探索。

The standard explicitly covers AI software, but quality management for AI software does indeed present unique challenges. How should “defects” in machine learning models be defined? How can end-to-end large models be thoroughly tested and validated? How should regression testing be conducted after model iterations? While the standard provides a framework for addressing these issues, their practical implementation still requires ongoing exploration by the industry.

可以确定的是，AI软件不会成为质量管控的法外之地。12月1日，汽车软件国标正式实施。这不是限制创新，而是让创新在质量的轨道上运行。从"事后OTA"到"事前预防"，汽车软件正在走向成熟。

One thing is certain: AI software will not become a “lawless zone” when it comes to quality control. On December 1, the national standard for automotive software officially took effect. This is not meant to restrict innovation, but rather to ensure that innovation stays on track with quality standards. From “post-event OTA” to “preemptive prevention,” automotive software is maturing.

对于汽车安全研发和测试工程师而言，理解低速碰撞法规、车身前部能量管理、保险分类测试（RCAR/AZT）以及集成安全系统设计，是把握行业趋势的基础。carhs 将于 2026 年 10 月 19 日至 21 日 举办线上研讨会 《低速碰撞中的乘用车》，由来自奥斯特法利亚应用科学大学哈拉尔德·巴赫姆教授主讲，系统覆盖低速碰撞法规要求、结构设计、碰撞传感与被动系统等内容，英文授课。

For automotive safety R&D and testing engineers, understanding low-speed crash regulations, front-end energy management, insurance classification testing (RCAR/AZT), and integrated safety system design is essential for keeping pace with industry trends. carhs will host an online seminar titled “Passenger Cars in Low-Speed Crashes” from October 19 to 21, 2026. Led by Professor Harald Bachmann from Ostfalia University of Applied Sciences, the seminar will systematically cover low-speed crash regulations, structural design, crash sensing, and passive safety systems. The seminar will be conducted in English.

低速碰撞的要求和测试程序

· 低速碰撞试验要求简介

· 法律测试

· 消费者保护测试

· 其他要求

Requirements and test procedures for low-speed crash  Introduction to the requirements for low-speed crash tests  Legal tests  Consumer protection tests  Other requirements

车辆前部的能量管理和结构力

· 荷载路径和结构荷载

· 连接到高速测试

· 影响碰撞传感和结构设计变更的因素

· 结构设计变更

· 碰撞传感和约束系统的影响

Energy management and structural forces in the vehicle front  Load paths and structure loading  Connections to high-speed test  Influencing factors on crash sensing and structural design changes  Changes of structural design  Influence of crash sensing and restraint systems

被动系统设计

· 市场上现有的解决方案

· 概念解决方案方法

· 目标冲突

· 技术可行性和局限性

Design of passive systems  Existing solutions on the market  Conceptual solution approaches  Conflicts of objectives  Technological feasibility and limits

对整体安全系统的讨论

· 集成解决方案的潜力

· 技术可行性和局限性

Discussion of integral safety systems   Potential of integrated solutions   Technological feasibility and limits