In-Depth Interpretation of GB/T 48140-2026 Automotive Software Quality and Defect Management Specification

The standard was comprehensively coordinated, managed and reviewed by the Recall Technology Center of the State Administration for Market Regulation, with the International Automotive Quality Standardization Association (IAQSA) of Jiading District, Shanghai responsible for overall framework design and content drafting coordination. A total of 21 organizations participated in researching and drafting the standard content [4]:

The drafting lineup covers the entire chain of "regulators - testing and certification bodies - vehicle manufacturers - Tier 1 suppliers - software suppliers - universities". Mainstream domestic brands and new-energy vehicle startups are all represented, reflecting the consensus nature of the standard based on China's intelligent connected vehicle industry practice [4].

"Software-defined vehicle" has become a core trend in the development of the automotive industry. While software gives vehicles intelligent experiences, it also brings new safety risks. In its release statement, the State Administration for Market Regulation clearly identified three challenges currently facing automotive software [1]:

1. Frequent software defects: software problems in vehicle systems can easily trigger high-severity safety risks, and are characterized by wide impact and strong concealment;
2. Normalized iterative upgrades: OTA remote upgrades have made rapid software version evolution the norm, increasing the channels through which defects are introduced;
3. Absence of systematic requirements: the industry lacks unified automotive software quality and defect management specifications, and management levels vary widely between organizations.

The drafting notes point out that, constrained by the complexity of vehicle system architectures and the particularity of operating conditions, software problems should be a key focus of quality control and safety validation. Building on the software quality management framework, this standard integrates the special requirements of automotive functional safety, safety of the intended functionality (SOTIF), information security, artificial intelligence safety and data security, and incorporates risk assessment and defect handling mechanisms to establish a vehicle-grade software quality and defect management specification covering the entire lifecycle from requirements, design and implementation to validation and operations [4].

The drafting notes also state that this is the world's first vehicle-grade software quality and safety integration standard. For the first time it unifies the common requirements of automotive software quality management, functional safety, safety of the intended functionality and information security, and, combined with best practices in China's intelligent connected vehicle field, provides a systematic architecture and implementation guide for the full lifecycle management of automotive software [4].

The main body of the standard consists of 8 parts [4]:

GB/T 48140-2026 Automotive Software Quality and Defect Management Specification

• Scope and references
  • Applicable objects and software types
  • References to GB/T 34402, 39603, 45496
• Terms and definitions (30)
  • Software defect
  • Quality planning
  • Requirements analysis
  • Design and implementation
  • Release management
  • Configuration management
  • Risk assessment
• Quality planning P
  • Software quality and safety management system
  • 10 key quality assurance activities
• Process quality assurance D
  • 7 key processes
  • Adaptation to multiple development models
• Key process review C
  • 5 review points
  • May be combined in implementation
• Software risk assessment C
  • Graded assessment
  • Risk elimination measures
• Software defect management A
  • Information collection and analysis
  • Investigation, analysis and assessment
  • Recall decision and implementation
  • OTA recall provisions

The standard adopts a process approach, combining the PDCA cycle (plan - do - check - act) with risk-based thinking; the five core activities map onto the PDCA stages as follows [2]:

The closed-loop logic of this framework is: continuous risk assessment advances software defect risks to the front end and enables preventive control; handling specifications for quality and safety risks and defects raise automotive software quality and the quality assurance level of organizations, ensuring that automotive software quality and safety objectives are met [2].

The standard applies to all organizations along the chain that provide software products or services for vehicles [4]:

The standard applies to automotive software and software that directly interacts with vehicles [4]:

• Vehicle embedded software
• Cloud software
• Automotive artificial intelligence software
• In-vehicle operating systems
• Machine learning-based software components
• Mobile-side real-time control software

Notably, the standard explicitly brings automotive artificial intelligence software and machine learning-based software components into its scope of control, reflecting a regulatory response to the emerging risk of AI being deployed in vehicles at scale [1][4].

The standard covers three types of automotive software development activities [4]:

1. New development
2. Incremental development
3. Upgrades and maintenance of existing software

The standard requires vehicle product manufacturers, software and related component suppliers, system suppliers, and other organizations in the supply chain that provide software products or services for vehicles to establish and operate a software quality and safety management system, and to carry out quality planning for the implementation processes of software requirements, design and implementation, integration, verification and validation, release management, and software upgrades and maintenance [1][4].

The standard specifies 10 key quality assurance activities [1][4]:

Among them, historical issue avoidance and status reporting and monitoring were specifically highlighted in the administration's release statement as the two landmark activities driving the shift toward "defect prevention" [1].

Organizations should carry out quality planning based on analysis of applicable domestic and international standards for software products; where safety is involved, planning should include but not be limited to functional safety, safety of the intended functionality, information security, artificial intelligence safety and data security (such as safety management objectives, safety management activities, corresponding deliverables and review plans) [4].

The management scope covers every stage of the product lifecycle: requirements, design, implementation, verification, validation, production and operations. The main content includes the definition of safety objectives, safety requirements management, hazard analysis and risk assessment, safety-oriented design and implementation, safety verification and validation, safety planning for production, operations and support processes, and toolchain and supply chain safety [4].

To ensure automotive software quality and safety and to avoid software defects and recall risks, quality assurance activities should be implemented across the entire software lifecycle, managing the following key processes [4]:

1. Planning
2. Requirements analysis
3. Design and implementation
4. Integration
5. Verification and validation
6. Release management
7. Upgrade and maintenance

A notable feature of the standard is that it adapts to multiple development models. When software uses waterfall, spiral, incremental, agile or bi-modal development models, each sub-cycle within the development model can still refer to the requirements for key processes such as planning, requirements analysis, design and implementation, integration, verification and validation, release management, and software upgrades [4].

This design responds to the reality of automotive software development: traditional vehicle control software mostly uses the V-model/waterfall approach, while internet-style software such as intelligent cockpits and OTA services generally uses agile iteration, and "bi-modal development" has become the norm among vehicle manufacturers. The standard does not mandate a unified development model, but maps the key process requirements onto the sub-cycles of any model.

The standard requires manufacturers to conduct review activities at 5 key processes in the automotive software implementation process [4]:

The standard also stipulates that review points may be combined in implementation according to the actual project situation [1][4], providing flexibility for high-frequency iteration scenarios such as agile development and preventing reviews from becoming a process burden.

Software problems have different impacts on the quality and safety of a system depending on the system and operating environment. Chapter 7 of the standard specifies the risk assessment method for the impact of automotive software product problems on the quality and safety of the system or the complete vehicle, as well as the corresponding relationship for risk grading, so that critical software problems or defects receive adequate risk assessment and corresponding risk elimination measures are taken promptly [4].

At the terminology level, the standard establishes a complete risk management vocabulary (citing terms defined in GB/T 43387-2023 Road Vehicles - Functional Safety and other standards) [5]:

The standard requires establishing a software risk assessment mechanism that brings software problems from every stage into graded assessment, moving quality control from "post-incident handling" toward "defect prevention" [1]. Through continuous risk assessment, software defect risks are front-loaded and preventively controlled, improving automotive software quality, reducing delivery risks and lowering the probability of various safety incidents [4].

Chapter 8 of the standard sets out the full-process closed-loop requirements for software defect management [1]:

Vehicle product manufacturers should collect and analyze information from multiple channels and carry out software quality investigation, analysis and assessment [4]:

• Market information
• Customer feedback
• Product technical information
• Government product safety regulatory information

Software providers should cooperate with vehicle product manufacturers in the above processes, clarifying supply chain collaboration responsibilities [4].

The standard sets out provisions for implementing recalls by means of over-the-air (OTA) upgrades, achieving closed-loop handling of software defects and continuous improvement [1]. This directly aligns with GB/T 45493-2025 Implementation Requirements for Vehicle Product Recalls Based on Remote Upgrade Technology - GB/T 45493 specifies the technical implementation requirements for OTA recalls, while this standard embeds OTA recalls into the overall process framework of software defect management [4].

The standard was drafted under the leadership of the Recall Technology Center of the State Administration for Market Regulation, and aligns with the mandatory national standards GB 44495-2024 Technical Requirements for Vehicle Information Security and GB 44496-2024 General Technical Requirements for Vehicle Software Upgrades [1]:

The standard takes the Product Quality Law of the People's Republic of China, the Regulations on the Administration of Recalls of Defective Vehicle Products, the Implementation Measures for the Regulations on the Administration of Recalls of Defective Vehicle Products, GB 44496-2024 and GB/T 45493-2025 as overall guidance [4], forming a four-tier governance architecture of "laws and regulations - mandatory technical standards - integrated management standards - specialized supporting standards".

According to the release statement of the State Administration for Market Regulation, the release and implementation of the standard have threefold significance [1]:

1. Moving the checkpoint forward: the identification and prevention of automotive software defects move upstream, reducing from the source the risk of defective software entering the market;
2. Improving the governance system: further improving the software safety governance system for intelligent connected vehicles, together with GB 44495 and GB 44496 forming a standards portfolio for software safety governance;
3. Transforming the management paradigm: moving automotive software quality control from "post-incident handling" toward "defect prevention", and from passive recall response to proactive full-lifecycle prevention.

From a global perspective, this standard is the world's first vehicle-grade software quality and safety integration standard. It is the first to unify the common requirements of quality management, functional safety, safety of the intended functionality and information security, providing a systematic architecture and implementation guide for the full lifecycle management of automotive software and contributing a Chinese approach to international automotive software governance [4].