These provisions require manufacturers to contact authorities in territories where features of the ADS can be active in advance of formally applying for approval. The intention is to make receiving authorities aware that an automated vehicle is destined for their territory. An ADS or feature whose ODD includes a geo-fence limiting operation to specific territories is clearly destined for just those territories. A manufacturer is not required to notify authorities in countries where the manufacturer does not intend to sell or operate the ADS or vehicles equipped with the ADS.

Proposal to add a bullet citing Automated Vehicle Safety Consortium (AVSC) Best Practice for ADS Remote Assistance Use Case (Nov. 27, 2023), available at https://avsc.sae-itc.com/publication/avsc-04-2023, which provides detailed explanation of different discrete functions underneath the broader remote operations heading, divided into interactions with vehicles or a fleet of vehicles and interactions with humans, with each then divided into more specific types of functions.

Proposal to remove brackets from the ODD paragraph in section 7.3.1.3. The proposal removes square brackets that were included as a result of the ADS-20-46/Rev.3 discussion. The bracketed text addresses scenarios where a new area falls within existing ODD bounds, where deployment in that area might not require ODD modification, and where modifications to the area of operation would not require ODD modification provided conditions and environment in new areas of operation have been considered, but where operation in an area with different traffic laws or behaviour than those for which the ADS’s ability to comply has been demonstrated would require an amendment to the safety case.

Proposal to remove the placeholder for guidance on expectations concerning mitigation risk condition end states in para. 7.3.1.14. and replace it with text from ADS-20-09 with one paragraph removed based on ADS-20-50. The revised text specifies that while ADS Performance of DDT requirements set out when an MRC is required, they do not specify the process to achieve the MRC or its end state. MRC end states are expected to be fully stopped with parking brake applied and could include activation of hazard lights. The process to reach an MRC is expected to vary depending on the situation and system capabilities, and possible end state examples include stopping in lane, on shoulder, exiting highway, or navigating to nearest parking spot.

Proposal to delete “the examples given below is not the only possible approach,” add clarification that examples are non-comprehensive and represent one possible approach for documenting claims, arguments and evidence, modify example descriptions to point to regulation requirements 5/7.3.3.2 (a) and (b), and incorporate examples from ADS-20-09 by removing the placeholder “Examples to be provided.”

Proposal to delete text from the draft Introduction section of the Guidance and Interpretation Document on ADS Regulation. The formal submission to GRVA produced in June was based on the Workshop information document that contained additional explanations on the status of work. These contents are not appropriate for the final version of the Guidance and Interpretation Document.

Proposal to modify the ADS guidance and interpretation document to replace references to “The ADS” with “An ADS feature,” replace “activates accepts activation” with “activates,” replace “violation” with “failure to meet the ODD conditions,” change “the” to “an” before “ADS feature,” and add “or” between the second and third bullet points under ADS operation outside its ODD. These changes reflect the outcome of OPI subgroup meetings where stakeholders achieved a compromise solution on open items.

Proposal to add a new example and update text based on discussions by the OPI group aimed at finalizing the GID. The revised text adds that the ADS does not transit to a safe state in accordance with the manufacturers defined response as documented in the safety case, and removes provisions regarding the chosen stop location. The group agreed to further work in the next phase on situations where the chosen stop location could have contributed to a collision involving the ADS vehicle before it has moved from that location.

Proposal to add examples to the guidance on reporting noncompliance with DDT performance requirements under para. 6, specifying that failures include systematic or repeated deviations from DDT performance requirements defined under para. 6, non-compliance with respect to DDT performance requirements and requirements on interactions between the ADS and its user or other requirements under para. 6, and deviation from Remote Interaction/Intervention as described in the Safety case, with a note that some examples can reveal unreasonable risk to safety requiring only a single report noting this aspect.

Proposal to modify the explanation on performance issues constituting an unreasonable risk to safety by specifying that this occurrence should be understood as deviations, degradations, or performance limitations shown by an ADS feature that affect its ability to perform the DDT within the declared ODD, triggered by events that present an unreasonable risk to safety and/or are beyond expected variability or acceptable degradation, replace “may” with “might” in references to discrete failures and risk existence, replace “Violation of” with “Non-compliance with respect to the”, delete references to identified reduction in safety margins and exceeding overall hazard exposure thresholds, replace “the rate of hazardous event occurrences” with “hazardous event exposure:”, and replace “suggests” with “could suggest”.

Proposal to clarify guidance on reporting uncompleted system-initiated deactivations by deleting “i.e.” and “the user has not properly taken over control of the”, inserting “is left to the user,” after “vehicle control”, inserting “An” before “ADS”, inserting “feature” after “ADS”, inserting “, or” after the clause on driving responsibility, and inserting “The user is not properly re-engaged as defined paragraph 4.2/6.2 of the regulation.” as an additional reporting criterion.

Proposal to amend the guidance on reporting safety-relevant communication issues by deleting “Such an occurrence could be reported in case of” and replacing it with “Examples of communication issues could include”, deleting “The remote interaction is unavailable” and replacing it with “Interruption of remote interaction,”, replacing “Information” with “Communication”, adding “the” before “safety threshold”, and adding “(if indicated in the safety case)” after “safety threshold”, and replacing the period after “unavailable” with “, or”.

This document proposes guidance on reporting cyber security issues affecting autonomous driving systems safety. The proposal modifies the description of reportable cyber security incidents to replace “Safety-relevant ECU compromised” with “Any cybersecurity threat identified to safety relevant ECU, or” and deletes “ADS control channel manipulated.” The text also clarifies that reporting must align with UN R155 where this Regulation is applied, replacing the reference to “CSMS procedure where R155 is applied.”

Proposal to clarify guidance on reporting of system failures that compromise DDT performance by amending the description of reportable system failures, including modifying language regarding loss of redundancy or reduction in capabilities of ADS features to perform the entire DDT, replacing “failure in an actuator used by the ADS” with “hardware failure that compromises the capability of an ADS feature to perform the entire DDT,” and retaining the existing provision regarding degradation in computational capability.

Proposal to clarify guidance on reporting maintenance and repair issues by deleting “Such an occurrence is expected to be reported in case of” and inserting “Examples of maintenance or repair issues could include”, adding “safety-critical” before “software”, adding “potential” before “safety”, deleting “implications” and inserting “consequences, or”, deleting “Fitted hardware not compliant to safety performance specifications” and inserting “Not following the repair instructions given by the manufacturer.”

Proposal to clarify guidance on reporting unauthorized modifications to the ADS by deleting “Such an occurrence is expected to be reported in case of” and replacing it with “Examples of unauthorised modifications to the ADS could include”, deleting “Sensor tampering; obstruction;” and inserting language to specify that ADS-relevant software or hardware tampering, or third-party hardware interfering with ADS, could constitute unauthorized modifications affecting intended functionality.

Proposal to add a note that no guidance is provided on reporting when a feature required remote interaction to navigate a situation. The revised text adds that an active ADS feature required remote interaction to navigate a driving situation and marks guidance as N/A. Proposal was not accepted by the ADS IWG session.

Proposal to delete reference to no response within required time in section 14 on fallback user unavailability, and add reference to para. 4.2.2.1.6 (c) as the requirement for reporting MRC required due to non-response.

Proposal to remove guidance on prevention of unsafe takeovers. The document proposes deletion of the statement “Such an occurrence is expected to be reported when situation is unsuitable or unsafe for the subsequent mode of vehicle operation” from para. 15 of GTR Annex 1/UNR Annex 3, with no replacement text provided. The rationale indicates this removal reflects OPI group discussions aimed at finalizing the GID by resolving remaining open items.

Proposal to clarify reporting of vehicle approval numbers by inserting “(if applicable)” after “national or supra-national regulatory frameworks” in the vehicle approval number section of GTR Annex 2/UNR Annex 4. The insertion indicates that the vehicle approval number does not apply in all jurisdictions.

Proposal to introduce guidance on reporting the average feature engagement time. The average engagement time is a statistical measure of how long an ADS feature stays engaged per activation, computed as cumulative time divided by number of activations. The average is expected to be computed in an aggregated manner over the whole fleet of vehicles having the same ADS feature, representing the average duration between activations and deactivations of a feature.

Proposal to clarify para. 6.1.3.3.2. to specify that the requirement provides an exception for instances where there is a need to move the ADS vehicle before the operational state of its ADS can be verified, remove reference to fallback user since the requirement explicitly refers to ADSF-2, replace “Hand-over to fallback user” with “Allow an appropriate ADS user to take over control”, and clarify that the road safety agent may be permitted to drive the ADS vehicle manually.

Proposal to clarify that an appropriate ADSF-1 response to road-safety agent instructions could be a transfer of control to the fallback user while appropriately managing the response during system-initiated deactivation, add that deactivation of the ADS to enable non-ADS strategies to comply with road safety agent instructions is an appropriate response, label examples of non-ADS strategies and road safety agent instructions, and amend punctuation and references to jurisdiction in the final sentence.

Proposal for explanation that where confirmatory testing reveals apparent non-conformities, the assessor provides results to the manufacturer for review as foreseen by 6/8.3.3.1.2, the manufacturer conducts the same tests, and where results are consistent with the assessor’s, the manufacturer develops remedies and provides evidence to the assessor, or where manufacturer test results differ, the two parties discuss discrepancies and agree on next steps.

Proposal to clarify that non-ADS-related warnings refers to warnings from other vehicle systems generally managed by the ADS according to paragraph 6.3.6, that this requirement does not negate the need to give a certain warning to users where giving such a warning while an ADS feature is active is specifically required by other regulations, that this paragraph does not require such warnings to be suppressed, and that consideration should be given to how a warning is presented in the case that DDT-related warnings are not suppressed while an ADS feature is active.

Proposal to add an interpretation of the term “other road user” in para. 2.21. of Definitions. The proposal defines “other road user” (ORU) as any entity making use of publicly accessible road infrastructure, covering users making intentional use of roadways with knowledge of traffic rules and other sentient entities that might be found in vehicle paths but cannot be expected to respond predictably based on vehicle signals or traffic rules, such as children and animals. The safety case would address both classes of ORU with appropriate adaptation to account for lower predictability of child and animal behaviours where relevant to the ODD of an ADS feature. The proposal was withdrawn for reconsideration during the further development of GTR 26 and UN Regulation 185.

Proposal to add animals and other road users as examples of entities an ADS may encounter in driving situations and test scenarios. The revised text adds “animals, or other road users” to the illustrative example in para. 2.33 and para. 2.34, and replaces “pedestrians” with “these entities” in the corresponding sentence about scenario design. This ensures scenario design used to demonstrate ADS competency explicitly accounts for animal encounters alongside pedestrians and other road users.

Proposal to add animals and children to examples of safety-relevant objects in para. 6.1.2.8. The revision inserts “Animals and children (in or adjacent to the roadway, under the vehicle carriage, etc)” into the illustrative and non-exhaustive list of safety-relevant objects. The proposal removes ambiguity for manufacturers developing safety cases and ensures consistent treatment across ADS requirements, making explicit that animals and children are safety-relevant objects even though they cannot be expected to respond predictably based on vehicle signals, traffic rules, or common conventions.

Proposal for guidance on operational states, including remote termination and a diagram illustrating ADS and feature operational states, update guidance on terms “on”, “off”, “available,” “active,” “unavailable,” and “disabled” as canonical operational state terms for ADS descriptions and clarify that “active” applies only to features.

Proposal to delete and amend the draft guidance on para. 8.1.7.1. to replace “The intention of this requirement is to ensure that organizations have robust mechanisms to verify, monitor, and continuously improve safety performance. The regulatory text emphasizes” with “The Regulation implies,” delete “evidence-based” from the description of safety assurance as a continuous process, replace “aimed at ensuring that” with “to monitor the effectiveness of,” delete “remain effective” after “safety measures,” replace “whether” with “insofar that” and delete “risk control measures remain effective and whether” in the definition of safety assurance, delete “systematic” before “processes,” replace “that” with “on” after “confidence,” delete “and” before “products,” replace “established” with deletion, replace “employee reporting” with “internal feedback,” add “to maintain the demonstrated performance” after “safety improvements,” add “of KPI for the organization” in the evaluation clause, and replace “improvement of” with deletion and restructure the final clause to read “of the products.”

Proposal to modify the interpretation text for para. 8.1.7.1.(a) to replace “ensures” with “focuses on” in the statement describing the element for periodic independent internal audits and external audits.

Proposal to revise the explanation of para; 8.1.7.1.(b) to explain that safety assurance includes the organization and also other involved parties.

Proposal to delete "This provision ensures that " and insert “This element focuses on” before “changes”, delete “systematically”, and insert "that " after “changes” in para. 8.1.7.1.(c) to improve and streamline the text so that the description reads “This element focuses on changes that are assessed and managed, recognizing that modifications can introduce new risks.”

Proposal to delete “The intention is to ensure that”, delete “organizations have”, insert “This element focuses on”, insert “the”, and insert “organization’s” in para. 8.1.7.1.(d) to improve and streamline the text, changing “The intention is to ensure that organizations have processes to identify, implement, and track corrective actions to maintain safety at an acceptable level” to “This element focuses on the organization’s processes to identify, implement, and track corrective actions to maintain safety at an acceptable level.”

Proposal to delete “This clarifies that corrective” and replace with “Corrective”, and delete “/systemic” in para. 8.1.7.1.(e). The revised text states: Corrective actions may address both technical aspects (ADS) and organizational aspects (SMS).

Proposal to amend para. 8.1.7.1.(f) to replace “ensures” with “focuses on” in the element text describing performance monitoring practices to track safety outcomes over time.

Proposal to revise para. 8.1.7.1.(g) to delete “Monitoring is expected to cover both the ADS and the SMS, ensuring a comprehensive view of safety performance.” and insert “Monitoring practices include the monitoring of the ADS product (i.e., using SPIs) and evaluation of the Safety Management System so that it remains effective (i.e., using KPIs).”

Proposal to modify para. 8.1.7.1.(h) to replace “aims to ensure that” with “focuses on”, replace “Assessment of how organizations coordinate” with “Assessment that organizations coordinate”, delete “and product reviews” from the list of change management triggers, and delete “the approach and output from various” before “monitoring procedures” and delete “including operational data, safety reports and performance indicator” from the examples of monitoring procedures.

Proposal to modify the safety risk management definition by replacing “the core” with “an”, changing “that supports” to “described in”, deleting “and the intended results of the Organization, as well as the effectiveness of other organizational processes”, capitalizing “Organization” to “organization”, and removing the comma after “Organization”. The term safety risk management restricts itself to the management of safety risks without consideration of factors such as financial, legal, economic, or reputational risks.

Proposal to improve the interpretation of para. 8.1.6.1.(a) concerning verification that reactive and proactive practices for risk management are in place.

Proposal to improve the interpretation of para. 8.1.6.1.(b) concerning verification that the risk-management activity is not limited to the ADS itself but includes risk arising from organisation/people which can affect the SMS effectiveness or the safety of the ADS.

Proposal to improve the interpretation of para. 8.1.6.1.© concerning verification that the risk management activity includes risks from third parties.

Proposal to improve the interpretation of para. 8.1.6.1.(d) concerning verification that the risk management activity covers and is performed over the entire lifecycle.

Proposal to improve the list of examples of risk-management practices to support para. 8.1.6.1.

Proposal to improve the interpretation of para. 8.1.5.1. concerning the scope and contents of the manufacturer’s SMS safety policy.

Proposal to improve the interpretation of para. 8.1.5.1.(a) concerning the definition of the principles and objectives upon which the SMS is built, operated, and maintained.

Proposal to improve the interpretation of para. 8.1.5.1.(b) concerning the general recognition of the inherent risks of ADS-related activities throughout their life cycle, including the risks of the parties involved.

Proposal to improve the interpretation of para. 8.1.5.1.(c) concerning the organizational structure and the safety governance elements and their appropriateness for the needs of the organisation.

Proposal to amend the interpretation of para. 8.1.5.1.(d) to replace “a key” with “an”, delete “effective”, and insert “processes” before “of the SMS”. The proposal streamlines guidance text on SMS safety policy to improve clarity in describing how safety policy demonstrates management commitment to safety through approval by the accountable executive and supports promotion of safety and continuous improvement of the SMS.

Proposal to improve the interpretation of para. 8.1.5.1.(e) the description of the means/approaches to engage people within the organisation in the culture of safety.