Document identifies open questions regarding MRC definition, risk assessment, feature deactivation, and post-MRC obligations. Discusses reasons for MRC including collisions, faults, remote termination, ODD exits, and fallback user transition failures. Addresses post-MRC reporting and data recording under DSSAD and ISMR. Examines feature deactivation following MRC and ODD exit scenarios, with three possible solutions for ADSF-2 post-ODD exit recording.

Proposal to clarify that the ADS must respond to user requests to deactivate, require multimodal signals at the start of and during deactivation procedures that continue until completion or termination, require escalation of warnings for system-initiated deactivations if the user is not re-engaging as expected, require gradual reduction of ADS control action during deactivation while maintaining safe vehicle control, allow the ADS to retake full control if the vehicle is not being controlled safely, terminate the deactivation procedure if the user is not suitably engaged and the time available to transition has expired, replace the requirement for contact with the steering wheel with being in a physical position to operate the driving controls, suspend non-driving related activities at the start of the deactivation procedure, and modify the DDT section to require fallback to an MRC instead of a deactivation procedure if there is insufficient time for transition.

Proposal to modify para. 4.2.2.3.8.1 to add a requirement that a user be in a physical position to operate the driving controls, to allow gaze to be directed to multiple driving task-relevant areas rather than a single area, and to add a requirement that the user have demonstrated an appropriate response to transition of control.

Analysis of terminology related to remote support for automated driving systems, grouping terms into four categories: remote termination, remote fleet management, remote assistance, and remote driving. Remote termination disables ADS features until rescinded. Remote fleet management involves observation without performing the dynamic driving task. Remote assistance provides information while ADS continues the dynamic driving task. Remote driving involves a remote user performing the dynamic driving task. Document proposes agreeing on categories, determining definitions, developing a supplement without new requirements, and potentially developing proposals for new requirements covering ADS performance when expected remote support is not provided and further consideration of remote assistance.

Document presents initial considerations for approving Automated Driving Systems as Separate Technical Units under UN R185. It explains how component and STU approvals divide responsibility between suppliers and vehicle manufacturers, provides examples from other regulations such as lighting, tyres, glazing, and fuel systems, and discusses potential benefits and challenges specific to UN R185 application. Benefits include independent audits and avoiding repeated assessments for different vehicle types. Challenges include difficulty splitting requirements, potential information withholding, and unclear legal responsibility. Proposes flexible approaches with shared Safety Management System requirements and validation in vehicles.

Document presents research on Safety Performance Indicators (SPIs) for continuous monitoring and evaluation of Automated Driving Systems safety. Leading indicators anticipate outcomes through metrics including time-based, distance-based, probability-based and deceleration-based measures; lagging indicators confirm outcomes after occurrence such as crashes and injuries. Analysis of 21 datasets identified SHRP2 as primary source with 1402 crashes and 5262 near-crashes. Performance evaluation using Distance Headway and Time-to-Collision achieved Area Under the Curve close to 0.9 distinguishing crashes and near-crashes from normal driving. Main bottleneck identified is data quality and scarcity of reliable safety event labels.

Agenda for the 22nd session of the ADS informal working group and the 20th GRVA Workshop on ADS, to be held 6-9 October 2026 in Sydney. The session will address adoption of the agenda and previous session report, status of work on GTR 26, UN R185, and the GID, highlights from the 26th GRVA session, Interpretation H4 on electromagnetic compatibility, ADS Phase 2 context and programme, refinement and allocation of Phase 2 work items, integration into 2026-2029 strategy, ADS2 schedule and coordination with other groups, and various change requests to GTR, UNR, and GID.

Japan presents a proposed approach to address regulatory provisions for end-to-end (E2E) automated driving systems. E2E technology uses a single AI model to perform the entire driving task from perception to decision-making. While E2E systems offer benefits including flexible responses to traffic situations and reduced deployment costs through lower dependence on high-definition maps, concerns exist regarding their black-box nature, including limited visibility into decision-making processes, challenges with reproducibility, and difficulties with root cause analysis in accident investigations. The proposed approach involves three steps: identifying key issues related to E2E automated driving, discussing and organizing identified issues including possible E2E-specific requirements, and considering concrete amendment of provisions based on conclusions reached.

Document presents candidate amendments for ADS Regulation Phase 2 addressing Safety Management System and in-service monitoring and reporting. Proposes:

• An emergency recovery plan for fleet-level failures,
• Harmonization of SMS audit provisions and certificate mutual recognition,
• Split of operational and design responsibilities between operators and manufacturers,
• Refinement of occurrence classes with objective measurable criteria,
• Delta-V thresholds for all vehicle categories in scope,
• Extended reporting templates,
• Leading safety performance indicators,
• Confidentiality rules for ISMR data sharing,
• Explicit feedback loops from findings to corrective action and approval review.

Overview of activities under the testing sub-group for ADS regulations, covering approval, manufacturer requirements, and compliance assessment. Documents Level 1 and Level 2 requirements across virtual testing, track testing, and real-world testing environments. Identifies items not addressed in original versions, existing items requiring further consideration including safety case suitability testing and evidence generation, improvements identified during drafting GID discussions, and other items not included in previous lists.

Proposal to insert provisions requiring the ADS to terminate the deactivation procedure and execute a fallback to an MRC if the user is not suitably engaged after the time available for transition has expired, to permit the ADS to terminate the deactivation procedure and resume its previous operating state in the case of user-initiated deactivation instead of a fallback to an MRC, and to require the user be promptly informed that the deactivation process has been terminated and the reason for termination.

Change request to clarify ADS response to user-initiated deactivations. Proposes to amend para. 4.2.2.3.3 to specify that for ADSF-2 systems, deactivation procedures shall only be initiated if the ADS can assess the user to be available to assume the role of the driver according to fallback user provisions in para. 4/6.2.2.1.6 a), and to renumber para. 4.2.2.3.4 as para. 4.2.2.3.3.1. The original text could be misinterpreted as requiring the ADS to initiate deactivation whenever requested by the user.

Change request to add new paragraph clarifying that an advance notification that the fallback user should prepare for a system-initiated deactivation shall not be considered as the start of the deactivation procedure. The existing text does not clearly define when a system-initiated deactivation procedure begins. Advance notification is a necessary tool to prepare the fallback user for re-engagement without prematurely starting the deactivation procedure.

Change request to establish a method to transfer vehicle control between the ADS and the user during the deactivation procedure. The ADS shall maintain safe control of the vehicle until the deactivation procedure is completed, gradually reduce its vehicle control action in response to the user assuming vehicle control, and may increase its control action if the reduction is leading to an unsafe vehicle response.

The document identifies inconsistencies between requirements in sections 6 and 7 and assessment provisions in section 8 of UN R185, including requirements without specific assessment provisions, assessment provisions without corresponding requirements, and cases with no direct mapping between requirements and assessment. The document presents examples of problematic wording differences and asks whether section 8 should be retained as-is, aligned, simplified, removed, or consolidated into other sections.

Document identifies technical and drafting issues in UN R157 and its Global Technical Regulation equivalent requiring clarification or correction. Issues include:

• Definition of ‘Critical Occurrence’ using logically inconsistent language,
• Undefined terms like ‘area of operation’,
• Absence of provisions for reactivation after fault clearance,
• Incorrect cross-references between paragraphs,
• Non-standard citations such as ‘ISO 9001 Automotive’,
• Terminology inconsistencies between ‘alternative format’ and ‘alternative data’,
• Unclear assessment pathways for user information requirements,
• Inappropriate use of ‘demonstrate’ by approval authorities,
• Limited confidentiality scope,
• Misaligned section headings,
• Omission of 7.3.3 from safety case references,
• Interaction issues between reportable occurrence thresholds and systemic categories,
• Conflicting damage-area taxonomies between templates,
• Missing template rows,
• Undefined units and computations,
• Delta-V criterion applicability to L-category vehicles,
• Definition inconsistencies regarding vulnerable road user secondary safety systems,
• Out-of-scope self-certification references,
• Unspecified regulatory references for data retrievability,
• Missing remote termination recording,
• Inconsistent British versus American English spelling variants.

Proposal to insert a requirement that at the start of the deactivation procedure, any non-driving related activities provided or enabled by the ADS vehicle that were permitted because an ADS feature is active shall be automatically suspended. The requirement applies only to activities provided or enabled by the ADS vehicle and only to NDRA permitted because an ADS feature is active, not to activities such as listening to music or navigation permitted while an ADS feature is not active.

Table to facilitate consideration of ADS Phase 2 work items and their integration into an ADS2 IWG plan for 2026-2028.

Proposal to clarify para. 5.3.1.14 by replacing ‘end states’ with ‘possible vehicle resting positions’, adding examples of stopped in lane, stopped on shoulder, and stopped in parking spot, removing ‘feature’ from references to the ADS to provide flexibility, and adding requirement for the ADS to select a mitigated risk condition in addition to attempting to reach it.

Document lists work items for phase 2 of the IWG on Automated Driving Systems, organized by categories: ADS requirements covering Dynamic Driving Task (remote assistance, connectivity, MRC, priority vehicles and road safety agents); interactions between ADS and its user(s) (external HMI, feature activation and deactivation, ADS to ADAS transitions, HMI commonality, resuming control by fallback user); other ADS requirements (software parameter adaptation, DSSAD, non-DDT related tasks); manufacturer requirements (ISMR, safety case, ODD description, leading metric considerations); items affecting UN Regulation or GTR only (separate technical units, communication document, mutual recognition of SMS); and other items (drafting and text improvements, system updates and thresholds, end-to-end AI ADS, items remaining from FRAV/VMAD integration document). Each item identifies lead parties, priority levels, and status.