Proposal to clarify that ADS Off means the ADS is prevented from performing any activity, and ADS On means the ADS has been requested to perform activity, either an ADS feature is performing the DDT or the system is in ADS Standby, to distinguish ADS Off from ADS Standby and be consistent with off mode definition in UN R171.

Proposal to amend Figure 1 in para. 4.2.2.2.3 to add an (ADS feature) Available box within the ADS Standby box. The (ADS feature) Available state shows that no ADS feature is performing the DDT, however the ADS may be performing some other activity such as determining whether the vehicle is in the ODD. The figure depicts ADS Off, ADS Standby, ADS Feature (A) Active, ADS Feature (B) Active states with transitions for Activation, Deactivation, Switching On, and Switching Off.

The change request seeks to amend the road-safety agent Instructions explanation to indicate that examples regarding road safety agent instructions to the ADS vehicle are territory-based. The revision adds the phrase “which depending on the country of operation” to both the list of example instructions and the statement regarding communication methods, clarifying that instructions from road safety agents vary from country to country.

This change request proposes to amend the explanatory text for para. 6.1.2.11. (UNR)/4.1.2.11. (GTR) by modifying the phrase “the ADS is always responsible for detecting them” to “the ADS is always responsible for detecting and responding to them” and by deleting two “remote intervention” examples of non-ADS strategies. The rationale states that the ADS is responsible for both detection and response to instructions from road safety agents, and that remote intervention examples should be avoided at the current stage as this topic is already under discussion in Phase Two.

Proposal to amend para. 6.1.2.5 (UNR)/4.1.2.5 (GTR) to clarify that the ADS is always responsible for detecting and responding to priority vehicles, and to delete the examples of non-ADS strategies involving remote intervention.

The revised text adds ISO 21448, GB/T 34590 Road vehicles-Functional safety, and GB/T 43267 Road vehicles – Safety of the intended functionality to the original reference standards ISO 26262-2/8:2028 and ISO 9001 2015. GB/T 34590 is an important reference for functional safety in China and ISO 21448 and GB/T 43267 are important references for SOTIF.

Proposal to correct a paragraph number error in para. 5.3.2.15 of the GTR and para. 7.3.2.15 of the UNR by renumbering them as 5.3.2.14 and 7.3.2.14 respectively. The safety concept shall describe the manufacturer’s approach to scenario selection to cover the reasonably foreseeable situations and conditions that the ADS will encounter including how the following aspects are covered, aligned with WP.29/2026/139 (GTR) and WP.29/2026/137 (UNR).

Proposal to delete example “collision” under “Failure to meet the ADS requirements under paragraph 6 of this Regulation” in Annex 1 (GTR) and 3 (UNR) List of reportable occurrences by reporting type. The rationale states that not all collisions involving ADS vehicles constitute failure to meet ADS requirements, as some collisions are not caused by ADS or the ADS vehicle, and some collisions are not avoidable, such as suddenly appearing obstructing road users.

Contribution for the AI literature review.

Contribution for the AI literature review.

Proposal to add text to para. 3.2.4.6 clarifying that uncertainty-related risks may propagate from upstream to downstream AI modules when uncertainty information is inadequately communicated or used, affecting the resulting action, and to add text to Annex 2, item 1.6 clarifying that inadequate communication or use of uncertainty information across AI modules can propagate or amplify uncertainty-related risks and affect the resulting action, even when the upstream estimate is informative.

Proposal to add text to para. 3.2.4.6 clarifying that uncertainty-related risks may propagate from upstream to downstream AI modules when uncertainty information is inadequately communicated or used, affecting the resulting action, and to add text to Annex 2, item 1.6 clarifying that inadequate communication or use of uncertainty information across AI modules can propagate or amplify uncertainty-related risks and affect the resulting action, even when the upstream estimate is informative.

Proposal to append sentences to paragraph 2 addressing uncertainty-related risks propagated from upstream to downstream AI modules and supporting uncertainty-aware action, and to paragraph 3 considering whether uncertainty information remains meaningful when used by downstream AI modules and how it affects the resulting action.

Proposal to add working definitions for uncertainty quantification, aleatoric uncertainty, epistemic uncertainty, and uncertainty-aware action at the end of section 1.3 of AI-11-03, Annex 5. These definitions do not replace definitions in applicable standards and support general discussion of uncertainty and its effects on action.

Proposal to modify Annex 1, 1.1.2 to replace the clause beginning ‘and such applications fall within the scope’ with language clarifying that applications fall within the first mode of AI use only where AI is part of the regulated product and directly performs or supports a safety-relevant function, and to add that AI tools used solely for development or assessment fall under section 2.3.3.

Proposal to modify the definition of Validation Data to replace ‘a final’ with ‘candidate’ and append clarification that it is used for model selection or tuning while independent test data used for final performance reporting are not used for model selection or tuning, and add a definition of Test Data as data used to evaluate the final selected model and not used for fitting, model selection or tuning, with a note on dataset separation to avoid leakage between sets.

Proposal to modify the definition of concept drift in para. 3.2.9.2 and Annex 2, para. 6.2 to clarify that concept drift arises when changes alter the relationship between inputs and target outputs, and that a change in input distribution alone does not necessarily imply a change in this relationship.

Proposal to insert a sentence in para. 2.2.1 clarifying that decision trees can be learned from data and not all are manually specified rule systems, and to modify para. 2.2.5 to state that Generative AI models can use different architectures, with some being Transformer-based and potentially foundation or general-purpose AI models.

Proposal to add principles and stages of risk-driven lifecycle approach to para. 4.2.1.1, replacing ‘risk informed lifecycle approaches explanation’ with ‘Risk-driven lifecycle approach explanation’ and adding explicit reference to principles of risk-driven lifecycle approach and stages of risk-driven lifecycle approach.

Proposal to conduct safety analysis based on vehicle and system architecture to identify and decompose data and model-related safety requirements, and delete the requirement for maintenance or reassessment of assumptions as the system or environment changes.

Proposal to modify para. 4.2.5.2 to replace ‘management of changes in data and operational distributions’ with ‘management of changes in data and process assurance’. Where a closed-loop data chain is applied to vehicle AI systems safety development activities, evidence of safety assurance capability of the complete closed-loop data chain shall be provided, including safety assurance descriptions for data collection, data processing, and data annotation processes. Where data training is used as an improvement measure for functional insufficiency, relevant analysis shall be conducted and the rationality of the data shall be justified to ensure the improved system meets system-level safety-related requirements.

Add one NB note beneath the “AI Safety” definition in Annex 5, Section 1.1, item 4, clarifying that the definition uses “safety” in the functional-safety sense and that hazards affecting AI-based safety functions may be initiated by malicious actions or arise from personal data processing, and that assurance of AI systems interacts with cybersecurity and data-privacy requirements such as UN R155 and ISO/SAE 21434.

Proposal to insert new sections 2.3.7 and 2.3.8 to clarify the classification criteria and boundaries of the three modes of AI use and provide representative examples illustrating their practical application, establishing that classification should be based on the role and purpose of AI in specific activities rather than assigning a fixed mode to a particular model or process, and that the same AI-related model, system, artefact or process may correspond to different modes at different stages or when used for different purposes.

Proposal to insert an introductory paragraph before para. 4.2.1 to establish that the depth and rigor of applying common AI risk management concepts should be commensurate with the safety risk level of the specific AI application, with risk levels informed by ISO 26262 ASIL classification and ISO 21448 SOTIF risk assessment, as well as the degree of AI system autonomy and adaptability, and to elevate the proportionality principle from a sub-point within para. 4.2.1.1 to a framing principle for the entire Section 4.2.

Proposal to insert new section 4.2.10 defining human oversight and system controllability as complementary dimensions addressing the human-machine interaction layer and engineering design layer. The concept establishes that human oversight refers to the ability of natural persons to monitor, understand, intervene in, and override AI system outputs affecting safety, while system controllability refers to the ability of external agents to influence AI system behavior to prevent harm. For driving automation functions, human oversight and fallback vary with automation level as defined in SAE J3016 / ISO/SAE 22736. For non-driving safety functions, controllability may be achieved through audible or visual warnings, output degradation, or fail-safe behavior. System-level controllability measures include dedicated safety monitors, redundant model architectures, and structured fallback or fail-safe degradation strategies.

Proposal to introduce the nine data-related safety properties defined in ISO/PAS 8800:2024 (Accuracy, Completeness, Correctness, Independence of datasets, Integrity, Representativeness, Temporality, Traceability and Verifiability) as a common verification thread across rows 4.1–4.5 in Annex 3 and Section 4.2.5, add an anchoring practice for row 4.4 (Distribution Shift) requiring periodic monitoring and reassessment of data–model drift with re-evaluation of the safety argument where drift is detected, and list digital watermarking and AI-based automated audit as candidate illustrative practices.

Proposal to add a new risk item addressing compromised or unavailable infrastructure-sourced inputs in para. 3.2.9.5, add a corresponding extended description in Annex 2 (item 6.5), add a new table row in Annex 3, and add the term ‘Roadside Perception’ to Annex 5. AI systems that rely on roadside perception, map data, or remotely-delivered data may encounter communication outages, latency, or maliciously-altered incoming data, resulting in perception gaps or erroneous decisions.

Proposal to add to illustrative practices in para. 4.2.6.3 a reference to scenario coverage assessment based on ISO 34502 and test case generation based on ISO 34505 as sources of evidence for AI system assurance, and to add ISO 34501-34505 to Annex 4 A standards list.

Proposal to add illustrative real-world application examples under Automated Driving Systems in Annex 1, items 1.2.4 and 1.3, covering low-speed unmanned delivery and sanitation vehicles in closed or semi-open areas and urban non-motorized lanes, robotaxi operation on urban roads, and autonomously-operated vehicles deployed within mining sites, ports and industrial parks.

Change request to revise the driving function name from ‘Acceleration Control Pedal Error’ to ‘Acceleration Control for Pedal Error’ in Section 1.2.4, based on UNECE guidance that the original term is not a correct driving function name.

Proposal to define CLIV System as the ability to derive the potential presence of a subject or object inside the car based on logic using sensing information such as pressure or capacitive sensing. CLIV System encompasses indirect sensing methods using door logic alone or door logic combined with additional sensors, indirect sensing without door logic using pressure, capacitive, temperature, motion sensors or CO₂ concentration sensor, and direct sensing using camera, millimeter wave radar, UWB radar, or WiFi sensing to detect the absolute presence of a human inside the vehicle.

Responses to EPPR questionnaire on legislative gaps in the transposition of GTR 2 into UN R40.

Proposal to revise the weight threshold of M₃ vehicle category from 7.5 tonnes to 12 tonnes, split N-type trucks into three categories with light-duty trucks below 5 tonnes, medium-duty trucks above 5 tonnes and N₃ below 18 tonnes, and heavy-duty trucks above 18 tonnes, adjust year and mileage limits for N₂, N₃ medium-duty trucks to 8 years or 500,000 km, and establish energy throughput requirements: M₂ 120,000 kWh, M₃≤12t 300,000 kWh, M₃>12t 500,000 kWh, N₂≤5t 200,000 kWh, N₂>5t, N₃≤18t 400,000 kWh, N₃>18t 1,200,000 kWh.

China introduces an assessment of low State of Charge Energy requirements for M-type vehicles using data from city buses and coaches. At low SOCE levels, available energy is reduced, requiring increased initial battery energy capacity to meet customer driving range expectations, leading to higher purchase costs and vehicle weight. China provides reasons supporting SOCE performance targets at an 8-year timeframe, including significant differences in vehicle types, operating conditions, business models, and battery specifications that vary by vehicle type, making uniform standards inefficient.

GTR 25 establishes alternative test and verification methods for heavy-duty vehicle energy consumption. China released test method GB/T 18386.2-2022 based on chassis dynamometers using continuous cycle and shortened methods. Test conditions include temperature of 25°C ± 5°C, initial battery SOC of 20%, and pre-conditioning soak and charge for minimum 6 hours and maximum 36 hours. The torque meter method measures road load without disabling regenerative braking, achieving resistance matching within 5% error. Test verification includes vehicle selection across mileage groups 0, 200,000, 400,000, and 600,000 km, with on-board data collection and sensor accuracy consistency analysis post-durability.

Under GTR 25, a feasibility assessment proposes introducing a 5-year mid-term performance requirement threshold together with corresponding mileage and energy-throughput limits as an intermediate verification checkpoint for battery degradation. Based on analysis of State-of-Health data from vehicles with 5-year life and mileage ranging from 250,000 km to 350,000 km, the MPR value is set at 75%, which can cover 98% battery-durability performance. Specific mileage and energy-throughput limits are established for vehicle categories M₂, M₃, N₂, and N₃.

This document proposes establishing a unified global testing method for determining system power and torque of heavy-duty hybrid electric vehicles (HD-HEV) and heavy-duty plug-in electric vehicles (HD-PEV). The proposal addresses the lack of standardized test methods by recommending hub-coupled dynamometer testing for vehicles with central drive systems and chassis dynamometer testing for other configurations. Testing should measure 30-minute continuous maximum power and torque under thermal equilibrium conditions. The document includes technical data from battery energy distribution analysis and recommends China lead formulation of this standard using chassis dynamometer verification.

Proposal to:

• Amend para. 2.1.(a) to include fuel cell electric vehicles that have more than one propulsion energy converter,
• Add fuel cell electric vehicle preparation requirements to para. 6.3. requiring run-in in accordance with manufacturers recommendations and at least 300 km of fuel cell run-in with hydrogen refueled in accordance with manufacturers recommendations,
• Amend para. 6.5. to include FCEVs in initial REESS charge requirements,
• Amend para. 6.8.1. to include fuel cell temperature in operational metrics to be monitored and recorded throughout the test,
• Retitle para. 2.6. as Fuel cell architectures, and add paras. 2.6.1., 2.6.2., and 2.6.3. specifying power determination reference points and test procedures for fuel cell architectures.

Proposal to add VRU warning pattern requirements. Document presents data from accident databases showing pedestrian crossing conflicts represent the highest proportion of nighttime road accidents at approximately 32% with obstructions and 19% without. Limited visibility and restricted communication between drivers and VRUs necessitates an assistance function. A spotlight feature with a bright narrow beam pattern directed at hazardous VRUs, moving with the target and flashing to remind drivers while warning VRUs, received positive feedback from customer experience surveys

Proposal to replace “multiple separate light sources” with “multiple light sources” in the provision governing rear position lamps reciprocally incorporated with stop lamps.

Door-opening collision accidents between motor vehicles and vulnerable road users occur frequently and pose serious risks to road traffic safety. No mandatory UN Regulation or Global Technical Regulation for Door Opening Warning Systems exists internationally, resulting in regional inconsistencies. A virtual kick-off workshop was held on 1 April with participation from contracting parties and stakeholders. The workshop reviewed accident data from Germany and China, discussed potential technical parameters for DOWS, and identified the need for broader international data collection. Further workshops are envisaged pending availability of substantive new input.