GB/T 48140-2026 Specification of automotive software quality and defect management
1 Scope
This document specifies the requirements for quality planning, process quality assurance, critical process review, software risk assessment, and software defect management throughout the full lifecycle of software products. It describes the overall implementation framework and methods for automotive software quality and defect management.
This document applies to automotive product manufacturers, software providers, upstream and downstream supply chain organizations that provide software products or services for vehicles, recall technical institutions, etc. It applies to automotive software and software that directly interacts with automotive, including vehicle embedded software, cloud software, automotive artificial intelligence software, on-board operating systems, AI-based software components, and mobile real-time control software. It applies to activities such as new development, incremental development, and upgrade and maintenance of existing software for automotive software.
2 Normative references
The following documents contain requirements which, through reference in this text, constitute provisions of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
GB/T 34402-2017 Safety of motor vehicle product - Guidelines for risk assessment and risk control
GB/T 39603-2020 Guidelines for the recall effectiveness evaluation of defective motor vehicle products
GB 44496-2024 General technical requirements for software update of vehicles
GB/T 45493-2025 Requirements of implementation of motor vehicle products recall based on over-the-air update technology
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply.
3.1
artificial intelligence system
engineering system that generates outputs such as content, predictions, recommendations, or decisions for a given set of human-defined objectives
Note 1: This engineering system uses various AI-related techniques and methods to develop models that represent data, knowledge, processes, etc., for performing tasks.
Note 2: Artificial intelligence systems have different levels of automation.
[Source: GB/T 41867-2022, 3.1.8]
3.2
AI safety
absence of unreasonable risk due to hazards caused by errors, faults, or functional insufficiencies of artificial intelligence systems
3.3
functional safety
absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems
[Source: GB/T 34590.1-2022, 3.67]
3.4
safety of the intended functionality; SOTIF
absence of unreasonable risk due to hazards caused by functional insufficiencies of the intended functionality or its implementation
[Source: GB/T 43267-2023, 3.25]
3.5
vehicle cyber security
state in which the electrical and electronic systems, components, and functions of a vehicle are protected so that their assets are free from threats
[Source: GB 44495-2024, 3.1]
3.6
data security
ability to ensure that data is effectively protected and lawfully used by taking necessary measures, as well as to ensure a continuous security
[Source: GB/T 41479-2022, 3.4]
3.7
over-the-air update; OTA update
software update in which the update package is transmitted to the vehicle in a wireless way rather than by using cables or other local connection methods
Note 1: "Over-the-air update" is also called a "remote update".
Note 2: "Local connection method" generally refers to physical connection methods such as those made through the on-board diagnostics (OBD) interface or the universal serial bus (USB) interface.
[Source: GB 44496-2024, 3.3]
3.8
software item
elements of a software program that are integrated into the software as a whole
Note: Typical software items include:
a) Software subprogram;
b) Software module;
c) Software library;
d) Configuration file.
3.9
deliverables
work products generated at different stages of the software life cycle that must be submitted
Note: Such as documents, computer models, source code, scripts, etc.
3.10
software issue
operational behavior of a software program that does not conform to its definition or basic usage expectations
3.11
software defects
software issues in software programs that affect or impair normal operation and can pose safety risks to the entire vehicle
3.12
quality planning
act of defining software development objectives and the scope of characteristics of deliverables, defining and managing project or iteration objectives and plans, and specifying the necessary operating processes and related resources to achieve software quality objectives
3.13
prevent recurrence of historical nonconformities
act of summarizing issues that have occurred in a product, improving the stability of software products through technical and management methods, and preventing recurrence of same or similar issues
3.14
documentation
process by which a system or software product generates and maintains documents
Note: Includes the following elements:
a) A documentation set, including written or graphical information such as descriptions, definitions, reports, plans, certification activities, requirements, procedures, and results;
b) The process of generating or modifying documents;
c) The process of managing documents, including identification, acquisition, processing, storage and dissemination.
3.15
configuration management
process of establishing and maintaining the integrity and consistency of configuration items through configuration item identification, storage control, version control, baseline control, and audit activities, so as to uniquely identify and obtain product status and trace the relationships and differences between versions
3.16
configuration item
item managed under configuration control
Note 1: Configuration items include software items, code library, test cases, compilers, data, documents, physical media, external interfaces, etc.
Note 2: The description of a configuration item includes:
a) Item type;
b) Associated configuration management system;
c) Responsible owner;
d) Date placed under configuration control;
e) Status information (e.g., development, baseline, released, etc.);
f) Relationships to lower-level configuration items;
g) Change control records;
h) Change history, etc.
3.17
review management
act of reviewing deliverables to identify and resolve issues early, thereby reducing additional costs caused by issues/failures
3.18
structured walk-through
act of systematically reviewing a system or part of its requirements, design, or implementation by competent personnel against standard requirements or specifications
3.19
software delivery documentation
description of the technical status information of a version during the release management phase of software development
Note 1: Software delivery documentation includes documents containing internal technical information such as build environment, requirement implementation status and existing issues.
Note 2: The software delivery documentation in this document differs from the software version release notes intended for end users.
3.20
change management
systematic process that involves identifying change requests, analyzing and assessing the impact on technology, quality, business, and security, formulating and approving change implementation plans, tracking the execution process, verifying change results, documenting changes, and finally closing the change
3.21
requirement analysis
entire process of eliciting and clearly describing the services to be implemented by the system and the system's operational constraints, as well as analyzing, documenting, reviewing, and confirming those services and constraints
Note: software requirements are divided into functional software requirements and non-functional software requirements, including safety requirements related to functional safety, safety of the intended functionality, information security, artificial intelligence safety, etc.
Contents
Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Quality planning
4.1 General
4.2 Software safety management
4.3 Plan management
4.4 Formulation of process metrics
4.5 Prevent recurrence of historical nonconformities
4.6 Status report monitoring
4.7 Risk management
4.8 Configuration management
4.9 Review management
4.10 Issue management
4.11 Change management
5 Process quality assurance
5.1 General
5.2 Requirements analysis
5.3 Design and implementation
5.4 Integration
5.5 Verification and validation
5.6 Release management
5.7 Upgrade and maintenance
6 Critical process review
6.1 General
6.2 Objects of critical process review
6.3 Software project planning process review
6.4 Requirements analysis process review
6.5 Design and implementation process review
6.6 Software integration process review
6.7 Verification and validation process review
6.8 Review results
6.9 Measures and verification
7 Software risk assessment
7.1 General
7.2 Risk assessment object
7.3 Software risk assessment process
7.4 Assessment of software impact on the system
7.5 System risk assessment
7.6 Risk control
7.7 Evaluation of measure effectiveness
8 Software defect management
8.1 General
8.2 Information collection and analysis
8.3 Software issue identification
8.4 Investigation, analysis and evaluation
8.5 Recall decision
8.6 Preparation of remedial software
8.7 Recall plan development
8.8 Recall plan report
8.9 Recall information notification
8.10 Recall process management
8.11 Recall effectiveness evaluation
Bibliography
GB/T 48140-2026 Specification of automotive software quality and defect management
1 Scope
This document specifies the requirements for quality planning, process quality assurance, critical process review, software risk assessment, and software defect management throughout the full lifecycle of software products. It describes the overall implementation framework and methods for automotive software quality and defect management.
This document applies to automotive product manufacturers, software providers, upstream and downstream supply chain organizations that provide software products or services for vehicles, recall technical institutions, etc. It applies to automotive software and software that directly interacts with automotive, including vehicle embedded software, cloud software, automotive artificial intelligence software, on-board operating systems, AI-based software components, and mobile real-time control software. It applies to activities such as new development, incremental development, and upgrade and maintenance of existing software for automotive software.
2 Normative references
The following documents contain requirements which, through reference in this text, constitute provisions of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
GB/T 34402-2017 Safety of motor vehicle product - Guidelines for risk assessment and risk control
GB/T 39603-2020 Guidelines for the recall effectiveness evaluation of defective motor vehicle products
GB 44496-2024 General technical requirements for software update of vehicles
GB/T 45493-2025 Requirements of implementation of motor vehicle products recall based on over-the-air update technology
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply.
3.1
artificial intelligence system
engineering system that generates outputs such as content, predictions, recommendations, or decisions for a given set of human-defined objectives
Note 1: This engineering system uses various AI-related techniques and methods to develop models that represent data, knowledge, processes, etc., for performing tasks.
Note 2: Artificial intelligence systems have different levels of automation.
[Source: GB/T 41867-2022, 3.1.8]
3.2
AI safety
absence of unreasonable risk due to hazards caused by errors, faults, or functional insufficiencies of artificial intelligence systems
3.3
functional safety
absence of unreasonable risk due to hazards caused by malfunctioning behavior of electrical/electronic systems
[Source: GB/T 34590.1-2022, 3.67]
3.4
safety of the intended functionality; SOTIF
absence of unreasonable risk due to hazards caused by functional insufficiencies of the intended functionality or its implementation
[Source: GB/T 43267-2023, 3.25]
3.5
vehicle cyber security
state in which the electrical and electronic systems, components, and functions of a vehicle are protected so that their assets are free from threats
[Source: GB 44495-2024, 3.1]
3.6
data security
ability to ensure that data is effectively protected and lawfully used by taking necessary measures, as well as to ensure a continuous security
[Source: GB/T 41479-2022, 3.4]
3.7
over-the-air update; OTA update
software update in which the update package is transmitted to the vehicle in a wireless way rather than by using cables or other local connection methods
Note 1: "Over-the-air update" is also called a "remote update".
Note 2: "Local connection method" generally refers to physical connection methods such as those made through the on-board diagnostics (OBD) interface or the universal serial bus (USB) interface.
[Source: GB 44496-2024, 3.3]
3.8
software item
elements of a software program that are integrated into the software as a whole
Note: Typical software items include:
a) Software subprogram;
b) Software module;
c) Software library;
d) Configuration file.
3.9
deliverables
work products generated at different stages of the software life cycle that must be submitted
Note: Such as documents, computer models, source code, scripts, etc.
3.10
software issue
operational behavior of a software program that does not conform to its definition or basic usage expectations
3.11
software defects
software issues in software programs that affect or impair normal operation and can pose safety risks to the entire vehicle
3.12
quality planning
act of defining software development objectives and the scope of characteristics of deliverables, defining and managing project or iteration objectives and plans, and specifying the necessary operating processes and related resources to achieve software quality objectives
3.13
prevent recurrence of historical nonconformities
act of summarizing issues that have occurred in a product, improving the stability of software products through technical and management methods, and preventing recurrence of same or similar issues
3.14
documentation
process by which a system or software product generates and maintains documents
Note: Includes the following elements:
a) A documentation set, including written or graphical information such as descriptions, definitions, reports, plans, certification activities, requirements, procedures, and results;
b) The process of generating or modifying documents;
c) The process of managing documents, including identification, acquisition, processing, storage and dissemination.
3.15
configuration management
process of establishing and maintaining the integrity and consistency of configuration items through configuration item identification, storage control, version control, baseline control, and audit activities, so as to uniquely identify and obtain product status and trace the relationships and differences between versions
3.16
configuration item
item managed under configuration control
Note 1: Configuration items include software items, code library, test cases, compilers, data, documents, physical media, external interfaces, etc.
Note 2: The description of a configuration item includes:
a) Item type;
b) Associated configuration management system;
c) Responsible owner;
d) Date placed under configuration control;
e) Status information (e.g., development, baseline, released, etc.);
f) Relationships to lower-level configuration items;
g) Change control records;
h) Change history, etc.
3.17
review management
act of reviewing deliverables to identify and resolve issues early, thereby reducing additional costs caused by issues/failures
3.18
structured walk-through
act of systematically reviewing a system or part of its requirements, design, or implementation by competent personnel against standard requirements or specifications
3.19
software delivery documentation
description of the technical status information of a version during the release management phase of software development
Note 1: Software delivery documentation includes documents containing internal technical information such as build environment, requirement implementation status and existing issues.
Note 2: The software delivery documentation in this document differs from the software version release notes intended for end users.
3.20
change management
systematic process that involves identifying change requests, analyzing and assessing the impact on technology, quality, business, and security, formulating and approving change implementation plans, tracking the execution process, verifying change results, documenting changes, and finally closing the change
3.21
requirement analysis
entire process of eliciting and clearly describing the services to be implemented by the system and the system's operational constraints, as well as analyzing, documenting, reviewing, and confirming those services and constraints
Note: software requirements are divided into functional software requirements and non-functional software requirements, including safety requirements related to functional safety, safety of the intended functionality, information security, artificial intelligence safety, etc.
Contents of GB/T 48140-2026
Contents
Foreword
Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Quality planning
4.1 General
4.2 Software safety management
4.3 Plan management
4.4 Formulation of process metrics
4.5 Prevent recurrence of historical nonconformities
4.6 Status report monitoring
4.7 Risk management
4.8 Configuration management
4.9 Review management
4.10 Issue management
4.11 Change management
5 Process quality assurance
5.1 General
5.2 Requirements analysis
5.3 Design and implementation
5.4 Integration
5.5 Verification and validation
5.6 Release management
5.7 Upgrade and maintenance
6 Critical process review
6.1 General
6.2 Objects of critical process review
6.3 Software project planning process review
6.4 Requirements analysis process review
6.5 Design and implementation process review
6.6 Software integration process review
6.7 Verification and validation process review
6.8 Review results
6.9 Measures and verification
7 Software risk assessment
7.1 General
7.2 Risk assessment object
7.3 Software risk assessment process
7.4 Assessment of software impact on the system
7.5 System risk assessment
7.6 Risk control
7.7 Evaluation of measure effectiveness
8 Software defect management
8.1 General
8.2 Information collection and analysis
8.3 Software issue identification
8.4 Investigation, analysis and evaluation
8.5 Recall decision
8.6 Preparation of remedial software
8.7 Recall plan development
8.8 Recall plan report
8.9 Recall information notification
8.10 Recall process management
8.11 Recall effectiveness evaluation
Bibliography
