UN Regulation No 171 – Uniform provisions concerning the approval of vehicles with regard to Driver Control Assistance Systems (DCAS) [2024/2689]

Official Journal EN of the European Union L series 2024/2689 4.11.2024 Only the original UN/ECE texts have legal effect under international public law. The status and date of entry into force of this Regulation should be checked in the latest version of the UN/ECE status document TRANS/WP.29/343, available at:

https://unece.org/status-1958-agreement-and-annexed-regulations UN Regulation No 171 – Uniform provisions concerning the approval of vehicles with regard to Driver Control Assistance Systems (DCAS) [2024/2689]

Date of entry into force: 22 September 2024 This document is meant purely as documentation tool. The authentic and legally binding text is:

ECE/TRANS/WP.29/2024/37 CONTENTS Regulation Introduction

1. Scope

2. Definitions

3. Application for approval

4. Approval

5. General Specifications

6. Additional Specifications for DCAS Features

7. Monitoring of DCAS operation

8. System Validation

9. System Information Data

10. Requirements for Software Identification

11. Modification of vehicle type and extension of approval

12. Conformity of Production

13. Penalties for non-conformity of production

14. Production definitively discontinued

15. Names and addresses of Technical Services responsible for conducting approval tests and of Type Approval Authorities Annexes

1. Communication

2. Arrangements of approval marks

3. Special requirements to be applied to the audit/assessment Appendix 1 – Model assessment form for electronic systems, and/or complex electronic systems Appendix 2 – System design to be assessed during the audit/assessment Appendix 3 – Exemplary Classification of the System Detection Capabilities and Relevant System Boundaries Appendix 4 – Declaration of System Capability

4. Physical Test Specifications for DCAS Validation

5. Principles for Credibility Assessment for using Virtual Toolchain in DCAS Validation

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 1/80EN OJ L, 4.11.2024 Introduction

1. Advanced Driver Assistance Systems (ADAS) have been developed to support drivers and enhance road safety through information support, including warnings in safety-critical situations, and assisting in executing the lateral and/or longitudinal control of the vehicle temporarily or on a sustained basis during normal driving and when avoiding collision and/or mitigating the crash severity in critical situations. ADAS are aimed to assist the drivers, who always remain responsible for vehicle control and shall permanently monitor the environment and vehicle/system performance.

2. This UN Regulation addresses the Driver Control Assistance Systems (DCAS), which are a subset of ADAS.

DCAS are driver-operated vehicle systems assisting a human driver in performing vehicle dynamic control via sustained lateral and longitudinal motion-control support. DCAS, while active, provide support to the driving tasks, and increase comfort and reduce the drivers’ workload by actively stabilising or manoeuvring the vehicle. DCAS assist the driver, when operated within the system boundaries, but do not completely take over the driving task, thus the responsibility remains with the driver. DCAS support shall not adversely impact road safety and driver control over the vehicle behaviour.

3. Reflecting on the expansion to the market of different enhanced DCAS, this UN Regulation intends to establish technologically neutral uniform and general provisions concerning the approval of vehicles equipped with DCAS that may function beyond the limitations imposed by the 03 series of amendments to UN Regulation No 79, and aims to allow the approval of a variety of driver control assistance features, filling an existing regulatory gap. This UN Regulation provides minimum safety requirements for any DCAS.

4. According to the standard SAE J3016 (Taxonomy and Definitions for Terms Related to Driving Automation Systems for On-Road Motor Vehicles), DCAS are treated as ‘SAE level 2 according to SAE J3016’ (partial automation), systems that are only capable of performing parts of the vehicle dynamic control, and thus require a driver to perform the remainder of dynamic control, as well as to supervise the system operation and vehicle environment(1). As such, DCAS, when operated, support – but do not replace – a driver in performing dynamic control. Providing either only longitudinal or only lateral control temporarily degrades DCAS automation level from 2 to 1 (driver assistance).

5. While both DCAS and Automated Driving Systems (ADS) of higher automation levels 3 to 5 according to SAE J3016 provide lateral and longitudinal control on a sustained basis, only ADS may permit the driver to disengage from the driving task, as only ADS, by definition, is capable of managing all driving situations reasonably expected within their Operational Design Domain (ODD) without further input from the driver.

Instead, DCAS only assist the driver but never replace the driver. As a consequence, there is no transfer in the driver’s responsibility for control of the vehicle.

6. The availability of DCAS, and their capability to assist, are constrained by the defined system operational boundaries. While DCAS is able to detect and respond to common scenarios within the use case (DCAS feature), the system may not be capable of recognizing certain environmental conditions, as DCAS are not designed to handle each and every situation, and it is expected that the driver is always in control of the vehicle.

7. This impact of system boundaries on the system’s ability to fulfil certain requirements, and the nature of how requirements can be assessed, is reflected by the language used in this UN Regulation.

(a) Some requirements are expected to be always met, including in all relevant tests. These provisions are phrased as ‘the system shall…’;

(b) Some requirements are such that whilst the system is generally expected to fulfil them, this might not always be appropriate or achievable under the specific circumstances, or external disturbances may still lead to a varying output. These provisions are phrased as ‘the system shall aim to…’; and

(1) The levels of automation described by SAE J3016 are also included in the reference document ECE/TRANS/WP29/1140.

2/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

(c) Some requirements are difficult to verify by assessing system performance directly and are more readily verified by assessing the design of the system, for example by analysing its control strategies. These provisions are phrased as ‘the system shall be designed to…’.

8. Depending on the use case, some DCAS may be able to initiate driving manoeuvres. When manoeuvres are initiated by the system, the system shall be designed to follow the national traffic rules. However, when manoeuvres are initiated by the driver, DCAS only assists the driver in operating the vehicle without ensuring compliance with national traffic rules. In either case, the responsibility remains with the driver.

9. It is recognized that operation in compliance with traffic rules related to driver-confirmed or system- initiated manoeuvres might not be fully achievable due to the complexity and variety of rules across the different countries of operation. The driver’s continued involvement in the driving task is deemed to compensate for this.

10. Overreliance of the driver could pose a potential safety risk. The better the system, the more likely the driver is to trust the system to always function correctly and decrease the driver’s level of supervision over time (even to the point of confusing the system with fully automated driving). Therefore, DCAS shall aim to prevent reasonably foreseeable risks of driver’s misuse or abuse. DCAS shall provide sufficient information to enable the driver to supervise the assistance provided.

11. DCAS shall be designed to avoid drivers undertaking activities other than driving over and above those permitted for manual driving before this UN Regulation enters into force as DCAS require the driver to remain engaged with the driving task. Therefore, DCAS shall have means to evaluate continuous driver involvement in and supervision of the vehicle operation. DCAS will monitor the driver engagement (ensuring hands-on wheel or eyes-on road or even both), evaluate the driver’s involvement and respond to a lack of the driver’s engagement appropriately by giving distinct warnings to the driver. It will further bring the vehicle to a complete stop, if the driver had not responded to the system’s warnings and had not taken necessary control actions. DCAS will monitor for signs of driver disengagement utilizing a driver monitoring system. However, while this system monitors for physical signs of disengagement, it is currently not capable of directly assessing cognitive disengagement.

12. This UN Regulation includes general functional requirements regarding the system safety at normal operation and the failsafe response in the case of the system failure or an inability of the driver to confirm the involvement in the vehicle control. The regulatory provisions cover DCAS interaction with other vehicle assistance systems, description of the system boundary conditions and the system behaviour when the system boundaries have been detected to be reached, controllability and the system dynamic control assistance for different DCAS use cases (features). DCAS and driver interactions are regulated, including Human-Machine Interface (HMI) in two directions: driver operation of the system and the system assurance of the driver’s engagement. This UN Regulation establishes requirements for the specific DCAS features.

13. This UN Regulation establishes more generic compliance assessment methods compared to those in the 03 series of amendments to UN Regulation No 79 (where specific requirements are developed for each use case). The manufacturer is required to declare an outline of the system design, which helps informing the Type Approval Authority of the necessary assessment and verification activities that need to take place. The multi-pillar assessment techniques compensate uncertainties related to DCAS operational cases that are not directly assessed and thus cover the assessment of DCAS multiple operational cases. The validation of DCAS shall ensure that a thorough assessment, considering the functional and operational safety of the features integrated in DCAS and the entire DCAS integrated into a vehicle, has been performed by the manufacturer during the design and development processes. The assessment pillars include the validation of DCAS safety aspects through the enhanced audit of the manufacturer documentation, physical tests on the test track and public roads and in-service monitoring of DCAS operation by the manufacturer.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 3/80EN OJ L, 4.11.2024

14. The safe use of DCAS requires appropriate understanding by the driver of the performance capabilities of DCAS available on the vehicle. The provision of the appropriate information to the driver is required to avoid potential driver’s misinterpretation, overestimation, or difficulty with the DCAS/vehicle control. The development of this UN Regulation showed a necessity to ensure that the driver maintains specific or sufficient knowledge on the appropriate use of DCAS. This issue touches on the broader topic of drivers’ education, which can be divided in two directions: (a) the upgrade of the education and reassessment of drivers to safely operate vehicles equipped with DCAS and (b) the development of a uniform standard (e.g., ISO) setting for DCAS the common HMI, communication techniques, modes of operation, possibilities of overriding, system messages and signals, etc. in addition to this UN Regulation. This will ensure a uniformity of HMI for different DCAS produced by different manufacturers, so that every driver could be prepared to use different DCAS features in a safe way.

15. This UN Regulation is not intended to establish requirements applicable to drivers, however, it stipulates the requirements to the educational materials, messages and signals that the manufacturers of DCAS will need to present to the driver (e.g., for review). However, this UN Regulation nor the Type Approval Authority cannot guarantee, through regulatory provisions, that these materials are appropriately reviewed and understood by the driver.

16. The deployment of DCAS draws attention to the need for a balanced marketing policy so as not to cause overestimation of DCAS capabilities by the driver, who may believe that the system performance is more than an assistant system. Referring to misleading terms in the information materials provided by the manufacturer may lead to driver confusion or overreliance. In order to avoid this, terms which have been deemed misleading by national authorities should not be used in DCAS marketing promotion.

1. Scope

1.1. This UN Regulation applies to the type approval of vehicles of Categories M and N(2)with regard to their Driver Control Assistance Systems (DCAS).

1.2. This UN Regulation does not apply to the approval of vehicles with regard to their Automatically Commanded Steering Functions (ACSF) or Risk Mitigation Function (RMF) which have been approved to UN Regulation No 79, even when a system is exercising longitudinal control at the same time. However, if the manufacturer declares such ACSF or RMF to be part of DCAS, this UN Regulation applies irrespective of whether it has also been approved to UN Regulation No 79.

2. Definitions

For the purposes of this Regulation:

2.1. ‘Driver Control Assistance System (DCAS)’ means the hardware and software collectively capable of assisting a driver in controlling the longitudinal and lateral motion of the vehicle on a sustained basis.

Within this UN Regulation, DCAS is also referred to as ‘the system’.

2.2. ‘Vehicle Type with regard to DCAS’ means a group of vehicles, which do not differ in such essential aspects as:

(a) The system characteristics and design of DCAS;

(b) Vehicle features which significantly influence the performances of DCAS.

If within the manufacturer’s designation of the vehicle type, DCAS consists of multiple features, some of which optionally may not be fitted on some vehicles, DCAS with lesser features is deemed to belong to the same vehicle type with respect to DCAS.

(2) As defined in the Consolidated Resolution on the Construction of Vehicles (R.E.3.), document ECE/TRANS/WP.29/78/Rev.6, para. 2 –

https://unece.org/transport/standards/transport/vehicle-regulations-wp29/resolutions.

4/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

2.3. ‘(DCAS) Feature’ means a specific DCAS capability providing assistance to the driver in defined traffic scenarios, circumstances and system boundaries.

2.4. ‘Dynamic Control’ means the real-time performance of operational and tactical functions required to move the vehicle. This includes controlling the vehicle’s lateral and longitudinal motion, monitoring the road environment, responding to events in the road traffic environment, and planning and signalling for manoeuvres.

For the purpose of this UN Regulation, only a driver is in charge and responsible for vehicle dynamic control whereas DCAS provides assistance to carry out operational and tactical functions without limiting the driver’s ability to intervene at any given time.

2.5. ‘System Boundaries’ are those verifiable or measurable limits or conditions established by a manufacturer up to or within which DCAS or a feature of DCAS is designed to provide assistance to the driver and those conditions which impact the system’s ability to operate as intended.

2.6. ‘Driver disengagement’ means the system’s determination of the driver’s current inability to safely execute perception, planning, or decision-making and to intervene in the operation of DCAS.

2.7. ‘Operational functions’ means the basic control actions of the driver required and taken to move a vehicle and operate its systems, including control of the vehicle’s lateral and longitudinal motion. Realization of operational functions implies the driver’s physical operation of the vehicle.

2.8. ‘Tactical functions’ means the real-time planning and determination of manoeuvres by the driver. Tactical functions imply the implementation of the driver’s skills to operate the vehicle within the continuously changing environment.

2.9. ‘Real-time’ means the actual time during which a process or event occurs.

2.10. ‘Manoeuvre’ means a change in the vehicle’s trajectory that leads the vehicle to at least partially leave its original lane or direction of travel whereby possibly leading to interaction with other road users.

A series of manoeuvres can be considered as an individual manoeuvre providing the manoeuvres follow in succession, without significant separation, and are related to the completion of one tactical goal (e.g., changing lanes in combination with navigating an intersection). Distinct manoeuvres in relation with following a navigation route with significant separation are not considered as an individual manoeuvre.

2.11. ‘Target Lane’ means the lane of the travel to which the system intends to transition the vehicle by performing a manoeuvre.

2.12. ‘Lane Change Procedure (LCP)’ means the sequence of operations aimed at performing a lane change of a vehicle. The sequence comprises the following operations:

(a) Activation of the direction indicator lamps;

(b) Lateral movement of the vehicle towards the lane boundary;

(c) Lane Change Manoeuvre;

(d) Resumption of the stable position of the vehicle in the lane;

(e) Deactivation of direction indicator lamps.

2.13. ‘Lane Change Manoeuvre (LCM)’ is part of the LCP and

(a) Starts when the outside edge of the tyre tread of the vehicle’s front wheel closest to the lane markings crosses the outside edge of the lane marking to which the vehicle is being manoeuvred; and

(b) Ends when the rear wheels of the vehicle have fully crossed the lane marking.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 5/80EN OJ L, 4.11.2024

2.17. ‘Off mode’ means a DCAS operational condition, when the system is prevented from assisting the driver in executing dynamic control of the vehicle.

2.18. ‘On mode’ means a DCAS operational condition, when the system or a DCAS feature has been requested to provide assistance to the driver in executing dynamic control of the vehicle. In this mode, the system is either in ‘stand-by’ or ‘active’ mode.

2.18.1. ‘Active mode’ means a DCAS operational condition, when the system or a DCAS feature considers itself to be within its system boundaries and is providing assistance to the driver in executing dynamic control of the vehicle.

2.18.2. ‘Stand-by mode’ means a DCAS operational condition, where the system or a DCAS feature is in ‘On’ mode, but not generating control output. In this mode, the system can be either in ‘passive’ or ‘inactive’ mode.

2.18.2.1. ‘Passive mode’ means a DCAS operational condition, when the system or DCAS feature is in ‘stand-by’ mode and considers itself to be within its system boundaries with no preconditions preventing switching to ‘active’ mode.

2.18.2.2. ‘Inactive mode’ means a DCAS operational condition, when the system or a DCAS feature is in ‘stand-by’ mode and considers itself to be outside its boundary conditions or any precondition is such that switching to ‘active’ mode is prevented.

2.19. ‘Risk of imminent collision’ describes a situation or an event which leads to a collision of the vehicle with another road user or an obstacle which cannot be avoided by a braking demand lower than 5 m/s2.

2.20. ‘Detection Range’ means the distance at which the system can reliably recognise an object, taking account of the deterioration of components of the sensing system due to time and usage throughout the lifetime of the vehicle, and generate a control signal.

2.21. ‘System/Feature Designed Speed Range’ means the adaptive speed range within which the system or a feature thereof can be in ‘active’ mode based on the system design and capability, taking into account traffic and environmental conditions where relevant.

2.22. ‘Driver-set maximum speed’ means the maximum speed of DCAS operation set by the driver.

2.23. ‘Current maximum speed’ means the maximum speed up to which the system will control the vehicle.

2.24. ‘Rx Software Identification Number (RXSWIN)’ means a dedicated identifier, defined by the vehicle manufacturer, representing information about the type approval relevant software of the Electronic Control System contributing to the UN Regulation No 171 type approval relevant characteristics of the vehicle.

2.25. ‘Electronic Control System’ means a combination of units, designed to cooperate in the production of the stated vehicle control function by electronic data processing. Such systems, often controlled by software, are built from discrete functional components such as sensors, electronic control units and actuators and connected by transmission links. They may include mechanical, electro-pneumatic or electro-hydraulic elements.

2.26. ‘Occurrence’ means, in the context of the provisions in paragraph 7, a safety-related action or instance of an arising event or incident involving a vehicle equipped with DCAS.

2.27. ‘Safety-Critical Occurrence’ means an occurrence when DCAS or its respective feature is in ‘On’ mode at the

time of a collision event which:

(a) Resulted in the injury of at least one person requiring medical assistance; or

(b) Resulted in the deployment of airbags, non-reversable occupant restraints and/or vulnerable road user secondary safety system of the DCAS-equipped vehicle.

6/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

2.28. ‘Controllability’ means a measure of the probability that harm can be avoided when a hazardous condition occurs. This condition might be due to actions by the driver, by the system or by external measures.

2.29. ‘Driver Override’ means any action taken by the driver to temporarily intervene on the assistance provided by DCAS through the application of braking, transmission, accelerator or steering controls.

2.30. ‘Highway’ means a type of road where pedestrians and cyclists are prohibited and which, by design, is equipped with a physical separation that divides the traffic moving in opposite directions.

2.31. ‘Non-Highway’ means a type of road other than a highway as defined in paragraph 2.30.

2.32. ‘Automated Driving System (ADS)’ means the vehicle hardware and software that are collectively capable of performing the entire Dynamic Driving Task (DDT) on a sustained basis.

2.33. ‘Dynamic Driving Task (DDT)’ means the real-time operational and tactical functions required to operate the vehicle in on-road traffic.

3. Application for approval

3.1. The application for approval of a vehicle type with regard to the DCAS shall be submitted by the vehicle manufacturer or by the manufacturer’s authorized representative to the Type Approval Authority of the Contracting Party, according to the provisions of Schedule 3 of the 1958 Agreement.

3.2. It shall be accompanied by the following documentation:

3.2.1. A description of the vehicle type with regard to the items specified in paragraph 2.2 together with a documentation package as required in Annex 1 which gives access to the basic design of the DCAS and the means by which it is linked to other vehicle systems, or by which it directly controls output variables.

3.3. A vehicle representative of the vehicle type to be approved shall be submitted to the Type Approval Authority or its designated technical service responsible for conducting the approval tests.

4. Approval

4.1. If the vehicle type submitted for approval pursuant to this UN Regulation meets the requirements of paragraphs 5 to 10 below, approval of that vehicle type shall be granted.

4.2. An approval number shall be assigned to each type approved. Its first two digits (at present 00 for the UN Regulation in its original form) shall indicate the series of amendments incorporating the technical amendments made to the UN Regulation at the time of issue of the approval. The same Contracting Party shall not assign the same number to another type of vehicle.

4.3. Communication of approval or extension of approval or refusal of approval or withdrawal of approval or of production definitively discontinued of a vehicle type pursuant to this UN Regulation shall be communicated to the Contracting Parties to the Agreement applying this UN Regulation by means of a form conforming to the model in Annex 1 to this UN Regulation and documentation supplied by the applicant being in a format not exceeding A4 (210 × 297 mm), and on an appropriate scale or electronic format.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 7/80EN OJ L, 4.11.2024

4.4. There shall be affixed, conspicuously and in a readily accessible place specified on the approval form, to every vehicle conforming to a vehicle type approved under this UN Regulation, an international approval mark conforming to the model described in Annex 2, consisting of either:

4.4.1. A circle surrounding the letter ‘E’ followed by:

(a) The distinguishing number of the country which has granted approval; and

(b) The number of this Regulation, followed by the letter ‘R’, a dash and the approval number to the right of the circle prescribed in this paragraph.

4.5. The approval mark shall be clearly legible and be indelible.

4.6. The Type Approval Authority shall verify the existence of satisfactory arrangements for ensuring effective checks on conformity of production before type-approval is granted.

5. General Specifications The fulfilment of the provisions of this paragraph shall be demonstrated by the manufacturer to the Type Approval Authority during the inspection of the safety approach as part of the assessment to Annex 3 and according to the relevant tests in Annex 4.

5.1. General Requirements

5.1.1. The system shall be designed to ensure the driver remains engaged with the driving task, in accordance with paragraph 5.5.4.2.

5.1.2. The manufacturer shall implement strategies to ensure mode awareness and avoid driver overreliance. This shall be demonstrated by fulfilment of provisions of paragraphs 5.5.4.

5.1.3. The manufacturer shall take effective measures to guard against reasonably foreseeable misuse by the driver and unauthorized modification of the system’s software and hardware components.

5.1.4. The system shall provide the driver a means to safely override or deactivate the system at any time in accordance with paragraphs 5.5.3.4.

5.1.5. The DCAS-equipped vehicle shall at least be equipped with an Advanced Emergency Braking System. In addition, it shall be equipped with either a Lane Departure Prevention System or Lane Departure Warning System. These systems shall comply with the technical requirements and transitional provisions of UN Regulations Nos 131, 152, 79 (Corrective Steering Function) and 130, as appropriate for the DCAS- equipped vehicle category.

5.2. DCAS interaction with other vehicle assistance systems

5.2.1. While the system is in ‘active’ mode, its operation shall not deactivate or suppress the longitudinal functionality of activated emergency assistance systems (i.e., AEBS). In the case of lateral functionality, the system may deactivate or suppress emergency assistance systems in accordance with the respective regulations covering this functionality.

5.2.2. Transitions between DCAS and other assistance or automation systems, prioritization of one over the other, and any suppression or deactivation of other assistance systems which are intended to ensure the safe and nominal operation of the vehicle shall be described in detail in the documentation presented to the Type Approval Authority.

5.3. Functional requirements 8/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.3.1. The manufacturer shall describe in detail in the documentation the detection capabilities of the system relevant to the individual features, especially for those system boundaries listed in Annex 3, Appendix 3.

5.3.2. The system shall be able to assess and respond to its surroundings as required to implement the system’s intended functionality, within the system boundaries and to the extent possible if operating beyond system boundaries.

5.3.2.1. The system shall aim to avoid disruption to the flow of traffic by adapting its behaviour to the surrounding traffic in an appropriate safety-oriented way.

5.3.2.2. If the system detects a risk of collision, it shall aim to avoid or mitigate the severity of a collision.

5.3.2.3. Without prejudice to other requirements in this UN Regulation, the system shall control the longitudinal and lateral motion of the vehicle aiming to maintain appropriate distances from other road users.

5.3.3. The system may activate relevant vehicle systems when necessary and applicable as appropriate for the system’s operational design (e.g. direction indicators, activate wipers in case of rain, heating systems, etc.).

5.3.4. The system’s control strategy shall be designed to reduce the risk of collisions whilst remaining controllable, accounting for the reaction time of the driver, as per paragraph 5.3.6.

5.3.5. Response to System boundaries

5.3.5.1. The system shall aim to detect the applicable system boundaries when DCAS or a feature of DCAS is in ‘on’ mode. If the system identifies that the system or feature boundary is exceeded, it shall transition into ‘stand-by’ mode and immediately notify the driver in accordance to the strategies described by the manufacturer as outlined in paragraph 5.3.5.2. and according to the HMI requirements defined in paragraph 5.5.4.1.

The system shall terminate assistance to the driver provided by the affected feature or the system in a controllable way. The assistance termination strategy shall be described by the vehicle manufacturer and assessed according to Annex 3.

5.3.5.1.1. The manufacturer shall implement strategies to avoid rapid system fluctuations between ‘stand-by’ and ‘active’ modes.

5.3.5.2. The manufacturer shall describe in detail, as part of the documentation required for Section 9, the system boundary conditions for the system and its features, and the strategies to notify the driver in the event a boundary condition is detected to be exceeded, being met or being approached (as per paragraph 5.3.5.5).

5.3.5.2.1. The description shall at least take into account potentially relevant boundary conditions as listed in Annex 3, Appendix 3.

5.3.5.2.2. The manufacturer shall describe and where reasonable demonstrate the behaviour of the system, the impact on system performance and how safety is ensured in case the system or its features remain in ‘active’ mode beyond these boundaries.

5.3.5.3. The manufacturer shall identify those system boundaries that the system is able to detect and shall describe the means by which the system is capable of identifying system boundaries.

5.3.5.4. Any declared system boundary that the system is unable to detect shall be documented and it shall be justified, to the satisfaction of the Type Approval Authority, how the inability to detect does not affect the safe operation of the system or its features.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 9/80EN OJ L, 4.11.2024

5.3.5.5. When the system identifies that the vehicle is approaching a system boundary of a feature in ‘active mode’, it shall inform the driver of this with appropriate lead time.

5.3.6. Controllability

5.3.6.1. The system shall be designed to ensure that control actions by the system including, but not limited to, those resulting from system failures, reaching system boundaries or when the system is being switched to ‘off’ mode remain controllable for the driver. This shall take into account the driver’s potential reaction time, as relevant to the situation, so that the driver intervention can be safely performed at any time (e.g., during a given manoeuvre).

5.3.6.2. To ensure controllability, the system shall implement strategies as relevant to the system’s capabilities, within the defined system boundaries.

Controllability strategies may include, but are not limited to:

(a) Limiting the system’s steering output;

(b) Adjusting the vehicle’s position in the lane of travel;

(c) Determining road type and attributes;

(d) Determining other road user behaviour;

(e) Driver monitoring used.

The manufacturer’s controllability design shall be described in detail to the Type Approval Authority and shall be assessed according to Annex 3.

5.3.6.3. Deceleration and Acceleration

5.3.6.3.1. When controlled by the system, the vehicle deceleration and acceleration shall remain manageable for the driver and surrounding traffic, unless increased levels of deceleration are required to ensure the safety of the vehicle or surrounding road users.

5.3.6.3.2. (Reserved)

5.3.7. System Dynamic Control

5.3.7.1. Positioning of the vehicle in the lane of travel

5.3.7.1.1. The DCAS feature while being in ‘active’ mode shall assist in keeping the vehicle in a stable position within its lane of travel.

While being in ‘active’ mode, the system shall ensure that the vehicle does not leave its lane of travel for lateral acceleration values specified by the manufacturer.

5.3.7.1.1.1. The system shall have the capability to adapt the vehicle speed in response to road curvature in order to achieve this.

5.3.7.1.2. The activated feature shall at any time, within the boundary conditions, ensure that the vehicle does not unintentionally cross a lane marking for lateral accelerations values to be specified by the manufacturer which shall not exceed 3 m/s2 for M and N category vehicles and 2,5 m/s2 for M , M , N and N category 1 1 2 3 2 3 vehicles.

It is recognised that the maximum lateral acceleration values specified by the vehicle manufacturer may not be achievable under all conditions (e.g., inclement weather, different tyres fitted to the vehicle, laterally sloped roads). The feature shall not deactivate or unreasonably switch the control strategy in these other conditions.

10/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.3.7.1.2.1. The moving average over half a second of the lateral jerk generated by the system shall not exceed 5 m/s3.

5.3.7.1.3. The strategy by which the system determines the appropriate speed and resulting lateral acceleration shall be documented and assessed by the Type Approval Authority.

5.3.7.1.4. When the system reaches its boundary conditions set out in paragraph 9.1.3, and both in the absence of any driver input to the steering control and when any the front tyre of the vehicle starts to unintentionally cross a lane marking, the system shall avoid sudden loss of steering support by providing continued assistance to the extent possible as outlined in the safety concept of the vehicle manufacturer. The system shall clearly inform the driver about this system status by means of an optical warning signal and additionally by an acoustic or haptic warning signal.

For vehicles of categories M , M , N and N , the warning requirement above is deemed to be fulfilled if the 2 3 2 3 vehicle is equipped with a Lane Departure Warning System (LDWS) fulfilling the technical requirements of UN Regulation No 130.

5.3.7.2. Manoeuvre

5.3.7.2.1. General Requirements

5.3.7.2.1.1. A manoeuvre shall only be initiated if the driver is not detected to be disengaged, and

(a) has commanded the system to perform the manoeuvre for a driver-initiated manoeuvre; or

(b) has acknowledged the system’s intention as needed for a driver-confirmed manoeuvre; or

(c) is given sufficient notice to react for a system-initiated manoeuvre.

5.3.7.2.1.2. The system shall only be permitted to perform a manoeuvre if the vehicle is equipped with detection capabilities with sufficient range to the front, side and rear with respect to the manoeuvre.

5.3.7.2.1.3. A manoeuvre shall not be initiated if a driver disengagement warning is being given to the driver.

5.3.7.2.1.4. A manoeuvre shall not be initiated if a risk of collision with another vehicle or road user is detected in the predicted path of the DCAS vehicle during the manoeuvre.

5.3.7.2.1.5. A manoeuvre shall be predictable and manageable for other road users.

5.3.7.2.1.6. A manoeuvre shall aim to be one continuous movement.

5.3.7.2.1.7. A manoeuvre shall be completed without undue delay.

5.3.7.2.1.8. Once a manoeuvre has been completed, the system shall resume assisting in maintaining a stable position in the lane of travel.

5.3.7.2.1.9. In case the vehicle is unexpectedly forced to become stationary during a planned manoeuvre, the system shall provide at least a visual warning signal to the driver, and may request the driver to resume control.

5.3.7.2.1.10. The system shall indicate driving manoeuvres assisted by the system (e.g., a lane change or turn) to other road users as per the required convention or as specifically defined in this Regulation. This shall include the use of the direction indicator to notify road users of an upcoming lateral manoeuvre.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 11/80EN OJ L, 4.11.2024

5.3.7.2.1.11. The system shall ensure the manoeuvre remains controllable for the driver, as per paragraph 5.3.6, by adapting its longitudinal speed before and during the manoeuvre when necessary.

5.3.7.2.1.12. The manoeuvre shall aim to not cause a collision with another detected vehicle or road user in the predicted path of the vehicle during the manoeuvre.

5.3.7.2.2. General requirements for driver-initiated manoeuvres The requirements of this paragraph and its subparagraphs apply to systems capable of performing driver- initiated manoeuvres.

5.3.7.2.2.1. The system shall only initiate the manoeuvre when explicitly commanded by the driver without prior request by the system, and when it is safe to do so.

5.3.7.2.2.2. The system shall not start the manoeuvre when a driver disengagement warning is currently being given.

5.3.7.2.3. General requirements for driver-confirmed manoeuvres The requirements of this paragraph and its subparagraphs apply to the system capable of performing a driver-confirmed manoeuvres.

5.3.7.2.3.1. The requirements outlined in paragraph 5.5.4.1.8 and subparagraphs shall apply. In addition, the system shall be designed to ensure that the driver has sufficient time to confirm that the system may proceed with the manoeuvre, as appropriate.

5.3.7.2.3.2. A request by the system for the driver to confirm a manoeuvre shall at least be indicated through a specific visual signal.

5.3.7.2.3.3. In the event that the driver does not confirm a request by the system or a driver disengagement warning is currently being given, the system shall not initiate the manoeuvre.

5.3.7.2.3.4. A manoeuvre manoeuvres shall only be proposed if there is a justifiable reason for said manoeuvre.

5.3.7.2.3.5. The system shall not initiate the proposed manoeuvre, even if already confirmed by the driver, unless the

following conditions are met:

(a) The target area, lane or path of the manoeuvre is not obstructed;

(b) The reason for the manoeuvre still exists;

(c) The target area or lane allows the system to resume stable control after completing the manoeuvre;

(d) The manoeuvre is anticipated to be completed before the vehicle comes to standstill, unless this is necessary for safe navigation or to give way to other road users;

(e) The target area or lane is assessed not to be outside of the system’s boundaries.

5.3.7.2.3.6. The system shall not propose a manoeuvre if it would knowingly cause other road users to unreasonably decelerate or evade the vehicle as a consequence of the manoeuvre.

5.3.7.2.3.7. The system shall aim to not propose a manoeuvre if it would violate applicable instruction by relevant signage or by other traffic rules as specified in paragraph 6.

5.3.7.2.3.8. The system shall not propose a manoeuvre if it would lead the vehicle to cross lane markings which are not permitted to be crossed.

12/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.3.7.2.4. General requirements for system-initiated manoeuvres The requirements of this paragraph and its subparagraphs apply to the system capable of performing a system-initiated manoeuvres.

5.3.7.2.4.1. (Reserved)

5.3.7.3. Driver Unavailability Response

5.3.7.3.1. The system shall comply with the technical requirements and transitional provisions of the 04 or later series of amendments to UN Regulation No 79 with respect to the Risk Mitigation Function (RMF). In the event that the driver has been determined to be unavailable following a driver disengagement warning escalation sequence as defined in paragraph 5.5.4.2.6, the system shall appropriately activate the Risk Mitigation Function in order to come to a safe stop.

5.3.7.3.2. Where the system is equipped with a driver-confirmed or system-initiated lane change feature, the RMF shall be capable of performing lane changes during an intervention on a highway. The system shall be designed to perform lane changes towards a slower or emergency lane where it is possible and safe to do so, taking into account surrounding traffic and road infrastructure in order to come to a safe stop.

5.3.7.4. Speed Limit Compliance Assistance

5.3.7.4.1. The system shall aim to determine the permitted road speed limit relevant to the current lane of travel.

5.3.7.4.2. The system shall continuously display the system-determined road speed limit to the driver.

5.3.7.4.3. The system and any of its features shall only provide assistance within their designed speed range.

5.3.7.4.4. The maximum speed up to which the system and any of its features provides assistance shall not exceed the maximum speed limit in the country where the vehicle is currently operating.

5.3.7.4.5. The current maximum speed the system may assist up to shall be determined either from:

(a) Driver-set maximum speed;

(b) System-determined road speed limit.

5.3.7.4.6. The system shall automatically control the vehicle speed to not exceed the current maximum speed.

5.3.7.4.7. The system shall provide a means for the driver to set a driver-set maximum speed within the system’s designed speed range.

5.3.7.4.7.1. When the vehicle speed exceeds the system-determined road speed limit, the system shall provide at least an optical signal to the driver for an appropriate duration.

5.3.7.4.7.2. The system may incorporate a feature allowing the driver to confirm or reject any change in current maximum speed before it is implemented by the system.

5.3.7.4.7.3. In the case where there is a change in the system-determined road speed limit the following shall apply:

5.3.7.4.7.3.1. The driver shall be given at least an acoustic or haptic signal, which may be suppressed permanently by the driver.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 13/80EN OJ L, 4.11.2024

5.3.7.4.7.3.2. If the current maximum speed before the change was a driver set maximum speed, then the current maximum speed shall not automatically change to the new system-determined road speed limit if the driver set maximum speed is lower than both previous system-determined road speed limit and the new system- determined road speed limit.

5.3.7.4.7.3.3. If the new system-determined road speed limit is lower than the current maximum speed, the current maximum speed shall automatically change to the new system-determined road speed limit.

5.3.7.4.7.3.4. For those cases not specifically addressed by the provisions above, the manufacturer shall document the system behaviour in response to a change in system-determined road speed limit and demonstrate this to the Type Approval Authority.

5.3.7.4.8. Any system-initiated change in vehicle speed due to a changed system-determined road speed limit shall be controllable to the driver.

5.3.7.4.9. The system shall not enable the driver to set a default offset by which the current maximum speed is supposed to exceed the system-determined road speed limit.

5.3.7.4.10. Technically reasonable tolerances (e.g., related to speedometer inaccuracy) may be applied to the warning thresholds and operational limits and shall be declared by the manufacturer to the Type Approval Authority.

5.3.7.4.11. The provisions of paragraph 5.3.7.4 shall not be in prejudice to any national or regional legislations which regulate the speed limit control system.

5.3.7.5. Safe Headway Assistance

5.3.7.5.1. The system shall support the driver in complying with regulatorily defined headway according to national traffic rules.

5.3.7.5.1.1. For M and N vehicles, the requirement in paragraph 5.3.7.5.1 shall be deemed to be fulfilled if either of the 1 1

following requirements are met:

5.3.7.5.1.1.1. The system shall permanently indicate to the driver the current headway setting while the system is in ‘active’ mode.

5.3.7.5.1.1.2. Upon first activation of the system during a run cycle, the system shall provide information to the driver that the headway configuration is set to a value lower than 2 seconds, if that is the case.

5.4. System safety response to detected failures

5.4.1. The activated system shall be capable of detecting and responding to electrical and non-electrical (e.g., sensor blockage, misalignment) failure conditions affecting the safe operation of the system or its features.

5.4.2. Upon detection of a failure affecting the safe operation of a given feature(s) or the system as a whole, the control assistance of the affected feature(s) or the system altogether shall be terminated in a safe manner in accordance with the manufacturer’s safety concept.

The system shall gradually reduce its control assistance provided by the affected features(s) or system if it is safe to do so, and inform the driver according to paragraph 5.5.4.1.

5.4.2.1. If a failure affects the entire system, the system shall switch to ‘off’ mode upon termination of assistance and provide at least an optical failure warning signal to the driver for an appropriate duration.

14/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.4.2.2. The failure affecting the system shall be indicated to the driver with at least an optical signal unless the system is in ‘off’ mode.

5.4.3. The manufacturer shall take appropriate measures (according to paragraph 5.3.6) to ensure that failures in the system remain controllable by the driver.

5.4.4. If a failure only affects some features, the system operation is permitted to continue provided that the remaining features are capable of operating in accordance to this Regulation.

5.4.4.1. The remaining available features or the absence of those features as a result of the failure shall be visually indicated to the driver in an easily understandable manner.

5.4.4.2. If the system is able to provide continued assistance in the case of a failure disabling a given feature, the manufacturer shall describe which features are able to operate independently from one another. This shall be assessed according to Annex 3.

5.4.5. When the driver attempts to switch to ‘on’ mode the system or a feature that is unavailable due to a failure, the system shall provide a notice to the driver about the failure and the unavailability of the system or given feature.

5.5. Human-Machine Interface (HMI)

5.5.1. Modes of operation

Diagram of DCAS Modes of Operation as defined under this Regulation:

5.5.2. General Requirements

5.5.2.1. When the system is switched into ‘on’ mode, specific system features shall be either in ‘active’ mode (generating control outputs) or in ‘stand-by’ mode (currently not generating control outputs), while some other system features may remain in ‘off’ mode and be commanded by a different means.

5.5.2.2. When the system is switched to ‘off’ mode by the driver, there shall not be an automatic transition to any system which provides continuous longitudinal and/or lateral movement of the vehicle.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 15/80EN OJ L, 4.11.2024

5.5.2.3. When the system is in ‘active’ mode, sustained longitudinal and lateral control assistance shall not be

provided by any other system other than DCAS, unless an intervention of an emergency safety system is deemed necessary as specified in paragraph 5.2.

5.5.2.4. The HMI shall be designed not to cause mode confusion with other systems equipped on the vehicle.

5.5.2.4.1. Without prejudice to the provisions of UN Regulation No 121, the vehicle controls dedicated to the DCAS shall be clearly identified and distinguishable (e.g., through size, form, colour, type, action, spacing and/or control shape) to accommodate only the appropriate interactions. This provision aims to promote correct use and is not intended to prohibit multifunction controls.

5.5.3. Activation, Deactivation and Driver Override

5.5.3.1. The system shall be in ‘off’ mode at the initiation of each new engine start (or run cycle, as relevant), regardless of what mode the driver had previously selected.

This requirement does not apply when a new engine start (or run cycle, as relevant) is performed automatically, e.g., the operation of a stop/start system.

5.5.3.2. Activation

5.5.3.2.1. The system shall change its mode from ‘off’ to ‘on’ only upon a deliberate action of the driver.

5.5.3.2.2. The system or its features shall only enter ‘active’ mode if all of the following conditions are met:

(a) The driver is in the driver seat and the driver’s safety belt is fastened;

(b) The system is able to monitor the driver’s potential disengagement with the driving task;

(c) No failure affecting the safe operation of the system has been detected;

(d) The system or feature has not detected to be outside of its system boundaries;

(e) Other safety systems according to paragraph 5.2 are functional.

The manufacturer shall specify in the documentation additional types of preconditions enabling the system or its features to enter ‘active’ mode, if applicable.

5.5.3.3. Deactivation

5.5.3.3.1. It shall be possible for the driver to switch the system to ‘off’ mode at any time.

5.5.3.3.2. When the driver switches the system or one of its features off, the system or feature respectively shall go to ‘off’ mode.

5.5.3.3.3. When the system or a feature thereof has assessed that the preconditions for remaining in ‘active’ mode are no longer met, the system or features shall terminate the control output in a safe and timely manner by either transitioning to ‘stand-by’ mode, or by switching the system or feature to ‘off’ mode, unless specifically defined otherwise by this Regulation.

5.5.3.3.4. The system shall not resume longitudinal control without driver input if the vehicle comes to a standstill following an intervention by an emergency safety system (e.g., AEBS).

5.5.3.4. Driver Override

5.5.3.4.1. The system may remain in ‘active’ mode, provided that priority is given to the driver input during the overriding period.

16/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.5.3.4.1.1. A driver input to the braking control resulting in a higher deceleration than that induced by the system, shall override any feature associated with the longitudinal control performed by the system and shall not resume assistance following such override without a separate action by the driver.

5.5.3.4.1.2. A driver input to the braking control by any braking system (e.g. parking brake) in order to maintaining the vehicle in standstill, shall override any feature associated with the longitudinal control performed by the system.

5.5.3.4.1.3. An accelerator input by the driver with a higher acceleration than that induced by the system shall override longitudinal control assistance provided by the system. The system shall resume longitudinal control assistance on the basis of the current maximum speed.

5.5.3.4.1.4. A steering input by the driver shall override any feature associated with the lateral control assistance performed by the system. The steering control effort necessary to override shall not exceed 50 N. The system may allow for the driver to perform minor lateral corrections (e.g. to avoid a pothole).

5.5.3.4.1.5. If according to paragraph 5.3.7.4.4 the system is no longer permitted to provide longitudinal or lateral assistance in response to driver override, the manufacturer shall implement strategies to ensure controllability of these phases of operation (e.g. not terminating lateral control while the driver is detected to be motorically disengaged).

5.5.4. Driver Information, Driver Disengagement and Warning Strategies

5.5.4.1. Driver Information

5.5.4.1.1. The system shall inform or warn the driver about:

(a) The status of the system or feature: ‘stand-by’ mode (if applicable), ‘active’ mode;

(b) An ongoing manoeuvre;

(c) The need for the driver to perform a specific action (e.g. apply control, check indirect vision devices);

(d) If while in ‘active’ mode the system has detected to have reached a currently relevant system boundary, unless already indicated by (a);

(e) A detected upcoming system boundary;

(f) Detected failures affecting the system or its features, unless the system is in ‘off’ mode;

(g) Intended driver-confirmed or system-initiated manoeuvres.

5.5.4.1.2. The system messages and signals shall be unambiguous, timely and shall not lead to confusion.

5.5.4.1.3. The system’s messages and signals shall use individual or an appropriate combination of visual, audio and/or haptic feedback for the given circumstances.

5.5.4.1.4. In the case of multiple messages or signals being offered in parallel, they shall be subject to prioritization by urgency. Safety-relevant messages and signals shall be given the greatest urgency. The manufacturer shall list and explain all system messages and signals in the documentation.

5.5.4.1.5. The system’s messages and signals shall be designed to actively encourage driver understanding of the state of the system, its capabilities and the driver’s tasks and responsibilities.

5.5.4.1.6. The system’s messages and signals shall encourage driver understanding of system’s intended control outputs.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 17/80EN OJ L, 4.11.2024

5.5.4.1.7. The system’s overall status indication shall be unambiguously distinguishable from the status indication of any automated driving system equipped on the vehicle.

5.5.4.1.8. System Messages and Signals for Driver-Confirmed Manoeuvres

5.5.4.1.8.1. The system shall visually inform the driver about a proposed manoeuvre. If informing about a series of manoeuvres, then it shall be a combination that is comprehensible to the driver and of a connected series.

The manufacturer shall explain to the Type Approval Authority the timing at which this information is

provided to ensure appropriate driver response.

5.5.4.1.8.2. The system’s signals and messages shall be designed to avoid driver overreliance or misuse.

5.5.4.1.9. System Messages and Signals for System-Initiated Manoeuvres

5.5.4.1.9.1. The provisions 5.5.4.1.8 shall equally apply. Where possible, information shall be provided at least 3 seconds ahead of a relevant intended manoeuvre.

5.5.4.1.9.2. (Reserved)

5.5.4.2. Driver State Monitoring and Warning Strategies The driver state monitoring system and its warning strategy shall be documented and demonstrated by the manufacturer to the Type Approval Authority during the inspection of the safety concept as part of the assessment to Annex 3 and according to the relevant tests of Annex 4.

5.5.4.2.1. Driver Disengagement Monitoring The system shall be equipped with means to appropriately detect driver disengagement as specified in the following paragraphs.

5.5.4.2.1.1. The system shall monitor if the driver is motorically (i.e., hand(s) on the steering control) and visually (e.g. eye gaze direction and/or head posture) disengaged.

5.5.4.2.1.2. If visual disengagement determination is detected to be temporarily unavailable, the system shall not lead the vehicle to leave its current lane of travel.

5.5.4.2.2. General Requirements for Driver Disengagement Warnings

5.5.4.2.2.1. The warning shall guide the driver on the required actions in order to support appropriate engagement in the driving task.

5.5.4.2.2.3. The system’s warning and escalation strategy shall consider for and prioritize warning strategies of simultaneously activated emergency assistance systems (e.g. AEBS).

5.5.4.2.3. Types of Warnings

5.5.4.2.3.1. Hands On Request (HOR) 18/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.5.4.2.3.1.1. An HOR shall contain at least a continual (continuous or intermittent) visual information similar to the presented in the example below.

5.5.4.2.3.1.2. An HOR, as a minimum, shall be considered confirmed when the driver has placed the hand(s) on the steering control.

5.5.4.2.3.2. Eyes On Request (EOR)

5.5.4.2.3.2.1. An EOR shall be a continual visual information in combination with at least one other modality which are clear and easily perceptible, unless it can be ensured that the driver has observed the visual information.

5.5.4.2.3.2.2. An EOR shall, as a minimum, be considered confirmed when the driver is no longer visually disengaged as per paragraph 5.5.4.2.5.

5.5.4.2.3.3. Direct Control Alert (DCA)

5.5.4.2.3.3.1. A DCA shall clearly and prominently instruct the driver to immediately resume either lateral, or lateral and longitudinal unassisted control of the vehicle. It shall comprise of a visual warning combined with at least one other modality which are clear and easily perceptible.

5.5.4.2.3.3.2. A DCA shall, as a minimum, be considered confirmed when the driver has taken unassisted lateral, or lateral and longitudinal control of the vehicle as requested by the DCA.

5.5.4.2.4. Assessment of Motoric Disengagement

5.5.4.2.4.1. The driver shall be deemed to be motorically disengaged when the driver has removed their hands from the steering control.

5.5.4.2.5. Assessment of Visual Disengagement

5.5.4.2.5.1. The driver state monitoring system shall detect the driver’s visual disengagement at a minimum based on the detection of the driver’s eye gaze. Head posture may also be used if the driver’s eye gaze cannot be determined, or where the head posture can determine the disengagement more quickly.

5.5.4.2.5.2. The driver shall be deemed to be visually disengaged when the driver’s eye gaze and/or head posture, as relevant, is directed away from any currently driving task relevant area.

An outline of the driving task relevant areas, and when they are relevant, shall be specified by the manufacturer in the documentation provided to the Type Approval Authority. For the purpose of the assessment of visual disengagement, the dashboard and instrument panel shall not be considered as a driving task relevant area.

5.5.4.2.5.2.1. The driver shall be deemed be visually engaged or reengaged following an aversion of eye gaze or head posture if either are re-directed towards any currently driving task relevant area for a sufficient duration depending on the situation. The duration shall be at least 200 milliseconds.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 19/80EN OJ L, 4.11.2024

5.5.4.2.5.3. The manufacturer shall implement strategies to address the detection and response to multiple subsequent short aversions of eye gaze or head posture by the driver (e.g. increased reengagement time and/or immediate issuing of an EOR).

5.5.4.2.6. Warning Escalation Sequence Depending on the safety concept of the system, the warning escalation sequence described below may start directly at any of the warning stages, skip any of the warning stages, provide simultaneous warnings, or supress or delay individual warnings in case another warning is already active.

5.5.4.2.6.1. Hands On Requests

5.5.4.2.6.1.1. At speeds above 10 km/h a HOR shall be given latest when driver is deemed motorically disengaged for more than 5 seconds.However, the HOR may be delayed for a period of up to 5 seconds as long as the system can confirm that the driver is not visually disengaged.

5.5.4.2.6.1.2. In the event of continued disengagement, the HOR request shall be escalated latest 10 seconds after the initial HOR. The escalated HOR shall contain an additional acoustic and/or haptic information.

5.5.4.2.6.1.3. (Reserved for hands-off requirements)

5.5.4.2.6.2. Eyes On Requests

5.5.4.2.6.2.1. At speeds above 10 km/h an EOR shall be given latest when the driver is deemed visually disengaged for 5 seconds.

5.5.4.2.6.2.2. In the event of continued visual disengagement, the system shall escalate the EOR latest 3 seconds after the initial EOR according to the warning strategy with increased intensity. This escalation shall always include acoustic and/or haptic information.

5.5.4.2.6.3. Direct Control Alerts

5.5.4.2.6.3.1. At the latest 5 seconds following an escalation of the EOR, a DCA shall be presented to the driver.

5.5.4.2.6.4. Transition to Driver Unavailability Response

5.5.4.2.6.4.1. If the system determines the driver to continue to be disengaged following a warning escalation, the system shall initiate a driver unavailability response at the latest 10 seconds after the first escalated request or alert.

5.5.4.2.6.5. (Reserved for hands-off requirements)

5.5.4.2.7. Additional Strategies for Disengagement Detection and Re-Engagement Support The driver state monitoring system shall be equipped with strategies to assess whether the driver is disengaged in the event that no driver input has been determined over prolonged periods (e.g. through a negative determination of driver drowsiness), and implement appropriate countermeasures.

5.5.4.2.8. Repeated or Prolonged Driver Disengagement

5.5.4.2.8.1. The manufacturer shall implement strategies to disable activation of the system for the duration of the start/ run cycle when the driver is detected to demonstrate prolonged insufficient engagement at least when this leads to more than one driver unavailability response initiations.

20/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

5.6. Driver Information Materials In addition to the user manual the manufacturer shall provide clear and easily accessible information (e.g. documentation, video, website materials) free of charge regarding system operation on the specific vehicle type. The information shall cover at least the following aspects using terminology that is understandable by a non-technical audience:

(a) Reminder of the driver’s responsibilities and appropriate use of the system;

(b) Explanation on how and to which extent the system and its features assist the driver;

(c) System capabilities and limitations;

(d) System Boundaries;

(e) Modes of operation and transition between modes;

(f) Mode transition to other assistance or automated systems, if applicable;

(g) Driver Disengagement Detection;

(h) Privacy Management when using the system;

(i) Explanation on how to override the system or its features;

(j) Human-machine interface (HMI):

(i) Activation and deactivation;

(ii) Status indication;

(iii) Messages and signals to the driver and their interpretation;

(iv) Vehicle behaviour when reaching system boundaries;

(v) Vehicle behaviour when exceeding system boundaries;

(vi) Information on system failures;

(vii) Information on system mode transition to other assistance or automated systems, if applicable.

In the manufacturer’s documentation, including the educational materials (e.g. documentation, video, website materials) addressed to consumers, the manufacturer shall not describe the system in a manner that would mislead the customer about the capabilities and limits of the system or about its level of automation.

6. Additional Specifications for DCAS features The fulfilment of the provisions of this paragraph shall be demonstrated by the manufacturer to the Type Approval Authority during the inspection of the safety approach as part of the assessment to Annex 3 and according to the relevant tests in Annex 4.

The system shall fulfil the requirements of paragraph 6 where applicable to the design of the system and relevant to the safety concept, when operated within its boundary conditions according to paragraphs

5.3.5.2.

6.1. Specific requirements for positioning in the lane of travel

6.1.1. Increased lateral dynamics

6.1.1.1. Notwithstanding the requirements in paragraph 5.3.7.1.2, for M and N category vehicles, the feature may 1 1 be permitted to induce higher lateral acceleration values than 3 m/s2 (e.g., in order to not disturb traffic flow), provided the following conditions are met:

(a) The system provides visual information to the driver on the upcoming or ongoing driving situation which may potentially induce higher lateral acceleration than 3 m/s2; and

(b) There is no disengagement warning being given to the driver; and

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 21/80EN OJ L, 4.11.2024

(c) The system operation remains predictable and controllable according to paragraph 5.3.6; and

(d) The vehicle is travelling at the system-determined road speed limit or below.

When any of the conditions are no longer met, the system shall implement strategies to ensure controllability.

6.1.1.2. The manufacturer shall demonstrate how the provisions of paragraph 6.1.1.1 are implemented in the system design to the Type Approval Authority.

6.1.2. Merging roads and slip roads on highways

6.1.2.1. The system shall aim to detect situations where the current lane of travel merges into another lane of travel (including slip roads), and shall be designed to ensure safe control in these situations accounting for road users in the neighbouring lane. If the system is designed to handle such a situation by performing a manoeuvre, this shall be in accordance with the provisions of this regulation.

6.1.3. Leaving the lane to form an access corridor for emergency and enforcement vehicles.

6.1.3.1. If the system is capable of forming an access corridor for emergency and enforcement vehicles, the system shall only leave its current lane of travel to (pre-emptively) form an access corridor where this is required and allowed according to national traffic rules.

6.1.3.2. While forming an access corridor, the system shall ensure sufficient lateral and longitudinal distance to road boundaries, vehicles and other road users.

6.1.3.3. The vehicle shall return completely to its original lane of travel once the situation that required this access corridor to be formed has passed.

6.1.4. Lane positioning on roads without lane marking

6.1.4.1. If the system is designed to perform lane positioning on roads without lane markings, it shall utilize other sources of information in order to robustly determine and pursue the appropriate trajectory in respect of other road users.

6.2. Specific Requirements for lane changes

6.2.1. A lane change shall only be performed if the system has sufficient information about its surrounding to the front, side and rear in order to assess the criticality of that lane change.

6.2.2. A lane change shall not be performed towards a lane intended for traffic moving in the opposite direction.

6.2.3. During the lane change manoeuvre, the system shall be designed to avoid a lateral acceleration of more than 1,5 m/s2 in addition to the lateral acceleration generated by the lane curvature and avoid a total lateral acceleration in excess of 3,5 m/s2.

The moving average over half a second of the lateral jerk generated by the system shall not exceed 5 m/s3.

6.2.4. A lane change manoeuvre shall only be started if a vehicle in the target lane is not forced to unmanageably decelerate due to the lane change of the vehicle.

22/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

6.2.4.1. When there is an approaching vehicle.

The system shall be designed to not make an approaching vehicle decelerate at a higher level than 3 m/s2, A seconds after the system starts the lane change manoeuvre, to ensure the distance between the two vehicles is never less than that which the DCAS vehicle travels in 1 second.

With:

(a) A equal to:

(i) 0,4 seconds after the start of the lane change manoeuvre, provided that the full width of the approaching vehicle was detected by the DCAS vehicle during its lateral movement for at least 1,0 second before the lane change manoeuvre starts; or

(ii) 1,4 seconds after the start of the lane change manoeuvre.

6.2.4.2. When there is no vehicle detected If no approaching vehicle is detected by the system in the target lane, the assessment shall be calculated as per paragraph 6.2.4.1 with the assumption that:

(a) The approaching vehicle in the target lane is at a distance from the DCAS vehicle equal to the actual rearward detection range;

(b) The approaching vehicle in the target lane is travelling with the allowed maximum speed or 130 km/h, whichever is lower; and

(c) The full width of the approaching vehicle is detected by the system during its lateral movement for at least 1 second.

When the target lane has just commenced, this requirement is deemed fulfilled if there is no vehicle detected along the length of the target lane to the rear.

6.2.4.3. In case the system intends to decelerate the vehicle during a lane change procedure, this deceleration shall be factored in when assessing the distance to a vehicle approaching from the rear, and the deceleration shall not exceed 2 m/s2 except for the purpose of avoiding or mitigating the risk of an imminent collision.

6.2.4.4. Where there is not sufficient headway time for the vehicle behind at the end of the lane change procedure, the system shall not increase the rate of deceleration for a least 2 seconds after the completion of the lane change procedure except in case this is necessary for nominal operation of the system (e.g., when responding to road infrastructure or other road users), or avoiding or mitigating the risk of an imminent collision.

6.2.5. The manufacturer shall demonstrate how the provisions of paragraph 6.2.4 are implemented in the system design to the Type Approval Authority.

6.2.6. The system shall generate a signal to activate and deactivate the direction indicator. The direction indicator signal shall remain active throughout the whole period of the lane change procedure and shall be deactivated by the system in a timely manner once the positioning in the lane of travel feature is resumed, unless the direction indicator control remains fully engaged (latched position).

6.2.7. A lane change procedure shall be indicated to other road users for at least 3 seconds prior to the start of the lane change manoeuvre. A shorter indication time is permitted where this is not in violation of national traffic rules in the country of operation, and sufficient notice of the manoeuvre is nevertheless given to other road users.

6.2.8. When the lane change procedure is suppressed by the system, it shall clearly inform the driver by means of an optical signal in combination with either an acoustic or haptic signal.

6.2.9. Additional requirements for lane changes

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 23/80EN OJ L, 4.11.2024

6.2.9.1. Additional requirements for driver-confirmed lane changes

6.2.9.1.1. In addition to the requirements of paragraph 6.2.4.1, the system shall aim not to make an approaching vehicle in the target lane decelerate unless necessary due to the traffic situation.

6.2.9.1.2. Notwithstanding the requirements in paragraph 6.2.4.2 (b), the approaching vehicle in the target lane is assumed to be travelling with the allowed maximum speed + 10 % or 130 km/h, whichever is lower.

6.2.9.2. Additional requirements for system-initiated lane changes

6.2.9.2.1. (Reserved)

6.2.9.3. Assisting lane changes on roads where there is no physical separation of traffic moving in opposite directions If the system is designed to assist lane changes on roads where there is no physical separation of traffic moving in the opposite direction, the system shall implement strategies to ensure that the lane change procedure is only performed into or via a lane where the target lane is not designated for oncoming traffic.

These strategies shall be demonstrated to and assessed by the Technical Service according to the corresponding tests in Annex 4 during Type Approval.

6.2.9.4. Assisting lane changes on roads where pedestrians and/or bicycles are not prohibited The system shall only be permitted to perform a lane change on roads with pedestrians and cyclists if the system is able to avoid causing risk of a collision with any vulnerable road user (such as pedestrians and cyclists).

6.2.9.5. Assisting lane changes in situations where the lane change manoeuvre cannot be started within 7 seconds of the initiation of the lane change procedure The time between initiation of the lane change procedure and start of the lane change manoeuvre is only permitted to be extended beyond 7 seconds where this is not in violation of national traffic rules.

6.3. Specific requirements for other manoeuvres other than a lane change

6.3.1. The provisions of this paragraph apply for manoeuvres which lead the vehicle to:

(a) select a lane where this manoeuvre is neither following the current lane of travel, nor a lane change; or

(b) navigate a roundabout by entering, navigating and exiting the roundabout; or

(c) navigate around an obstruction in the lane of travel; or

(d) take a turn (e.g. taking a turn at an intersection); or

(e) depart or arrive at a parked position.

6.3.2. The system shall be designed to respond to vehicles, road users, infrastructure or a blocked path ahead which are already within or may enter the planned trajectory or the corresponding driving environment in

order to ensure safe operation.

6.3.3. The system shall be designed to respond to traffic lights, stop signs, right-of-way infrastructure (such as zebra crossings or bus stops) and restricted lanes appropriate to the system’s given lane of travel, or the lane of travel the system would find itself in as a result of the manoeuvre where this is deemed relevant for the given manoeuvre and operating domain (e.g., highway or non-highway).

6.3.4. The system shall be designed to safely and cautiously navigate hillcrests where this is deemed relevant for the controllability the given manoeuvre.

24/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

6.3.5. If the manoeuvre would potentially lead the system to cross paths with vulnerable road users crossing the lane of travel (e.g., bike path, crosswalk), the system shall be designed to respond appropriately to the road users and infrastructure.

6.3.6. If the manoeuvre would lead the system to cross paths with crossing traffic (e.g., when taking a turn) or lead the system to merge with traffic approaching from a different direction, the system shall be designed to appropriately respond to these road users (e.g., by giving way).

6.3.7. Where relevant to the manoeuvre, the system shall be designed to detect restricted lanes of travel (e.g., bus, bike or taxi lanes) and shall aim to refrain from navigating on such lanes. In the event the system detects that it has entered into a restricted lane of travel, it shall propose or perform a lane change procedure to an appropriate lane of travel as appropriate to the system design, or request the driver to resume manual control.

6.3.8. The system shall aim to respect appropriate right-of-way rules.

6.3.9. Additional Requirements for navigating around an obstruction in the lane of travel

6.3.9.1. Navigating around an obstruction in the lane of travel can be performed under the following circumstances:

(a) Driving around a stationary obstacle (e.g., parked vehicle, debris, etc.) in the lane;

(b) Passing a very slow moving vehicle or road user in or near to the lane (such as a cyclist in a cycle lane) with sufficient lateral distance;

(c) The manoeuvre is instructed by legitimate external sources (e.g., static and dynamic road signs, road works, emergency or enforcement instruction, etc.), if applicable to the system’s design.

Other reasons to cross into another lane may be accepted if the manufacturer presents sufficient information to the Type Approval Authority and it is determined that it is appropriate and the system would be able to safely operate.

6.3.9.2. Navigating around an object obstructing the lane of travel shall only be permitted if the system is able to determine the position and movement of other road users to the front, side and rear where relevant to the specific manoeuvre, and that there is adequate distance to them to perform the manoeuvre.

6.3.9.3. If the manoeuvre would cause the vehicle to cross partially or fully into another lane, the system shall only do so if it is able to confirm that sufficient space and time is available. Such that there are no oncoming road users which would impede the system from completing the manoeuvre by reverting to the appropriate lane of travel. It shall not cross into another lane, where the direction of travel is in the opposite direction, to pass general traffic moving at an appropriate speed.

6.3.9.4. The system shall not suggest a manoeuvre to the driver, which intends to cross a solid lane marking that is not permitted to be crossed, unless permitted by the situation as described in 6.3.9.1 (c).

7. Monitoring of DCAS operation

7.1. Monitoring of DCAS Operation

7.1.1. The manufacturer shall maintain processes to monitor safety-critical occurrences caused by the operation of the system.

7.1.2. To fulfil this provision, the manufacturer shall set up a monitoring program aimed at collecting and analysing data in order to provide, to the extent feasible, evidence of the in-service safety performance of the DCAS and confirmatory evidence of the audit results of the Safety Management System requirements established in Annex 3 to this Regulation.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 25/80EN OJ L, 4.11.2024

7.2. Reporting of DCAS operation

7.2.1. Initial notification of Safety-Critical Occurrences

7.2.1.1. The manufacturer shall notify the Type Approval Authority as soon as practical about any safety-critical occurrence the manufacturer becomes aware of, where the system or its features were switched to ‘on’ mode, or had been switched to ‘on’ mode within the last 5 seconds before the safety-critical occurrence.

7.2.1.2. The initial notification may be limited to high-level data (e.g., location, time, type of accident).

7.2.2. Short-term Reporting of Safety-Critical Occurrences

7.2.2.1. Following the initial notification, the manufacturer shall investigate whether the incident was related to DCAS operation and inform the Type Approval Authority of the results of this investigation as soon as possible. If the operation of the system was likely one of the causes of the incident, in addition, the manufacturer shall inform the Type Approval Authority of intended remedial action(s) addressing DCAS design, if applicable.

7.2.2.2. If remedial action is required, the Type Approval Authority shall communicate this information to all Type Approval Authorities.

7.2.2.3. If the Type Approval Authority is informed of a safety critical occurrence with a vehicle equipped with DCAS through sources other than a vehicle manufacturer, such as by other Type Approval Authorities, that Type Approval Authority may request the manufacturer to provide available information of the incident in a comprehensive and accessible way as stipulated in 7.2.1 and 7.2.2.

7.2.3. Periodic Reporting

7.2.3.1. The manufacturer shall report at least once a year to the Type Approval Authority on the information deemed to be proper evidence of the intended operation and safety of the system in the field. The manufacturer shall report at least the information listed in the table below. Additional information is subject to agreement between the Type Approval Authority and the manufacturer.

In the event that the system was subject to significant changes relevant to the reported information during the reporting period, the report shall differentiate the changes of the system.

Table 1 Information for Periodic Reporting Frequency of Occurrence (Total and related hours of operation or distance travelled unless specified)

1. Safety-critical occurrences known to the manufacturer

2. Number of vehicles equipped with the system, and aggregated distance driven with the system in ‘passive’ and ‘active’ mode

3. Number of events resulting in a driver unavailability response

4. Number of system-initiated deactivations of the system or its features due to:

4.a. Detected System failures

4.b. Exceeding system boundaries

4.c. Other (if applicable)

5. Percentage of total distance travelled with a driver-set speed limit above the system-determined speed limit while the system is in ‘active’ mode 26/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

8. System Validation

8.1. The validation of the system shall ensure that an acceptable thorough consideration of functional and operational safety of the features integrated in the system and the entire system integrated into a vehicle has been performed by the manufacturer assessed according to Annex 3.

8.2. The validation of the system shall demonstrate that the features integrated in the system and the entire system meet the performance requirements specified in paragraphs 5. and 6. of this Regulation

The validation of the system shall include:

(a) Validation of the system safety aspects in accordance with the requirements of Annex 3;

(b) Physical tests on the test track and public roads in accordance with the requirements of Annex 4;

(c) Monitoring of the system or its features in accordance with the requirements of paragraph 7.

8.2.1. The validation of the system may include the use of virtual testing and reporting of metrics produced by virtual testing, such as coverage measurement and safety metrics. If virtual testing is performed, a credibility assessment as described in Annex 5 shall be provided to the Type Approval Authority.

9. System Information Data

9.1. The following data shall be provided by the manufacturer, together with the documentation package required in Annex 3 of this UN Regulation, to the Type Approval Authority at the time of type-approval.

9.1.1. Specific features according to the classification of paragraph 6 that the system possesses.

The manufacturer is to confirm with an ‘x’ or ‘Not Applicable’ what domain the feature can operate in, and

complete the table as necessary:

Other relevant preconditions System Minimum for activation (e.g., lane Feature System Maximum Speed Speed width, type of road, time of day, weather conditions) Positioning in the lane of travel Driver-initiated lane change (Please specify variants if any) Driver-confirmed lane change (Please specify variants if any) Other manoeuvres (Please specify variants if any) System-initiated lane change (To be completed by the manufacturer)

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 27/80EN OJ L, 4.11.2024

9.1.2. Domains (highway or non-highway), in which the system provides certain types of assistance as classified under paragraph 9.1.1.

The manufacturer is to confirm with an ‘x’ or ‘Not Applicable’ what domain the feature can operate in, and

complete the table as necessary:

Feature Non-Highway Highway Positioning in the lane of travel Driver-initiated lane change (Please specify variants if any) Driver-confirmed lane change (Please specify variants if any) Other manoeuvres (Please specify variants if any) System-initiated lane change (To be completed by the manufacturer)

9.1.3. The conditions under which the system and its features can be activated and the boundaries for operation (boundary conditions).

9.1.4. DCAS interactions with other vehicle systems.

9.1.5. Means to activate, deactivate and override the system.

9.1.6. Criteria monitored and the means by which driver disengagement is monitored.

9.1.7. Dynamic control assistance provided by each feature of the system.

9.1.8. Input other than lane markings the system uses to reliably determine the course of the lane and continues to provide lateral control assistance in the absence of a fully marked lane.

Will the system continue to provide Situation lateral control assistance in those Operating domain requirement situations? (yes/no) Lane marking(s) listed in UN Highway Regulation No 130 Lane marked with only a single Non-Highway marking Road edges Non-Highway Lane demarked by something Non-Highway other than a lane marking (parked cars, curb, construction infrastructure) (To be completed by the manufacturer) 28/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

10. Requirements for Software Identification

10.1. For the purpose of ensuring the software of the System can be identified, an R SWIN shall be implemented 171 by the vehicle manufacturer. The R SWIN may be held on the vehicle or, if R SWIN is not held on the 171 171 vehicle, the manufacturer shall declare the software version(s) of the vehicle or single ECUs with the connection to the relevant type approvals to the Type Approval Authority.

10.2. The vehicle manufacturer shall demonstrate compliance with UN Regulation No 156 (Software Update and Software Update Management System) by fulfilling the requirements and respecting the transitional provisions of the original version of UN Regulation No 156 or later series of amendments.

10.3. The vehicle manufacturer shall provide the following information in the communication form of this UN

Regulation:

(a) The R SWIN;

171

(b) How to read the R SWIN or software version(s) in case the R SWIN is not held on the vehicle.

171 171

10.4. The vehicle manufacturer may provide in the communication form of the related Regulation a list of the relevant parameters that will allow the identification of those vehicles that can be updated with the software represented by the R SWIN. The information provided shall be declared by the vehicle 171 manufacturer and may not be verified by a Type Approval Authority.

10.5. The vehicle manufacturer may obtain a new vehicle approval for the purpose of differentiating software versions intended to be used on vehicles already registered in the market from the software versions that are used on new vehicles. This may cover the situations where type approval regulations are updated or hardware changes are made to vehicles in series production. In agreement with the Type Approval Authority duplication of tests shall be avoided where possible.

11. Modification of vehicle type and extension of approval

11.1. Every modification of the vehicle type as defined in paragraph 2.2 of this Regulation shall be notified to the Type Approval Authority which approved the vehicle type. The Type Approval Authority shall then either:

(a) Consider that the modifications made do not have an adverse effect on the conditions of the granting of the approval and grant an extension of approval;

(b) Consider that the modifications made affect the conditions of the granting of the approval and require further tests or additional checks before granting an extension of approval;

(c) Decide, in consultation with the manufacturer, that a new type-approval is to be granted; or

(d) Apply the procedure contained in paragraph 11.1.1 (Revision) and, if applicable, the procedure contained in paragraph 11.1.2 (Extension).

11.1.1. Revision When particulars recorded in the information documents have changed and the Type Approval Authority considers that the modifications made are unlikely to have appreciable adverse effects, the modification shall be designated a ‘revision’.

In such a case, the Type Approval Authority shall issue the revised pages of the information documents as necessary, marking each revised page to show clearly the nature of the modification and the date of re-issue.

A consolidated, updated version of the information documents, accompanied by a detailed description of the modification, shall be deemed to meet this requirement.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 29/80EN OJ L, 4.11.2024

11.1.2. Extension The modification shall be designated an ‘extension’ if, in addition to the change of the particulars recorded in

the information documents:

(a) Further inspections or tests are required; or

(b) Any information on the communication document (with the exception of its attachments) has changed; or

(c) Approval to a later series of amendments is requested after its entry into force.

11.2. Confirmation or refusal of approval, specifying the alterations, shall be communicated by the procedure specified in paragraph 4.3 above to the Contracting Parties to the Agreement applying this UN Regulation.

In addition, the index to the information documents and to the test reports, attached to the communication document of Annex 1, shall be amended accordingly to show the date of the most recent revision or extension.

11.3. The Type Approval Authority shall inform the other Contracting Parties of the extension by means of the communication form which appears in Annex 1 to this UN Regulation. It shall assign a serial number to each extension, to be known as the extension number.

12. Conformity of production

12.1. Procedures for the conformity of production shall conform to the general provisions defined in Article 2 and Schedule 1 to the Agreement (E/ECE/TRANS/505/Rev.3) and meet the following requirements:

12.2. A vehicle approved pursuant to this UN Regulation shall be so manufactured as to conform to the type approved by meeting the requirements of paragraph 5. above;

12.3. The Type Approval Authority which has granted the approval may at any time verify the conformity of control methods applicable to each production unit. The normal frequency of such inspections shall be once every two years.

12.4. The approval granted in respect of a vehicle type pursuant to this UN Regulation may be withdrawn if the requirements laid down in paragraph 8, above are not complied with.

12.5. If a Contracting Party withdraws an approval, it had previously granted, it shall forthwith so notify the other Contracting Parties applying this Regulation by sending them a communication form conforming to the model in Annex 1 to this UN Regulation.

13. Penalties for non-conformity of production

13.1. The approval granted in respect of a vehicle type pursuant to this UN Regulation may be withdrawn, if the requirements laid down in paragraph 12 above are not complied with.

13.2. If a Contracting Party withdraws an approval it had previously granted, it shall forthwith so notify the other Contracting Parties applying this UN Regulation by sending them a communication form conforming to the model in Annex 1 to this UN Regulation.

14. Production definitively discontinued 30/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

14.1. If the holder of the approval completely ceases to manufacture a type of vehicle approved in accordance with this UN Regulation, he shall so inform the Approval Authority which granted the approval, which in turn shall forthwith inform the other Contracting Parties to the Agreement applying this Regulation by means of a communication form conforming to the model in Annex 1 to this UN Regulation.

14.2. The production is not considered definitely discontinued if the vehicle manufacturer intends to obtain further approvals for software updates for vehicles already registered in the market.

15. Names and Addresses of Technical Services Responsible for Conducting Approval Tests and of Type Approval Authorities

15.1. The Contracting Parties to the Agreement applying this UN Regulation shall communicate to the United Nations Secretariat(3) the names and addresses of the Technical Services responsible for conducting approval tests and of the Type Approval Authorities which grant approval and to which forms certifying approval or extension or refusal or withdrawal of approval are to be sent.

(3) Through the online platform (‘/343 Application’) provided by UNECE and dedicated to the exchange of such information https://apps. unece.org/WP29_application/

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 31/80EN OJ L, 4.11.2024 ANNEX 1 Communication(1) (Maximum format: A4 (210 × 297 mm))

issued by: Name of administration: ........................... ........................... ........................... () Concerning(3): Approval granted Approval extended Approval refused Approval withdrawn Production definitively discontinued of a vehicle type with regard to DCAS pursuant to UN Regulation No 171

Approval No: .................................................................................................................

Reason for extension or revision: .............................................................................................

1. Trade name or mark of vehicle: ........................................................................................

2. Vehicle type: ...........................................................................................................

3. Manufacturer’s name and address: .....................................................................................

4. If applicable, name and address of manufacturer’s representative: .....................................................

5. General construction characteristics of the vehicle:

5.1. Photographs and/or drawings of a representative vehicle: .............................................................

6. Description and/or drawing of the DCAS: see Section 9.

7. Cyber Security and Software updates

7.1. Cyber Security Type Approval Number (if applicable): .................................................................

7.2. Software Update Type approval number (if applicable): ...............................................................

8. Special requirements to be applied to the safety aspects of electronic control systems (Annex 3)

8.1. Manufacturers document reference for Annex 3 (including version number): .........................................

(1) Distinguishing number of the country which has granted/extended/refused/withdrawn approval (see approval provisions in UN Regulation No 171).

(2) Distinguishing number of the country which has granted/extended/refused/withdrawn approval (see approval provisions in UN Regulation No 171).

(3) Strike out what does not apply.

32/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

8.2. Information document form (Appendix 1 to Annex 3): ...............................................................

9. Technical Service responsible for conducting approval tests: ..........................................................

9.1. Date of report issued by that service: ..................................................................................

9.2. (Reference) Number of the report issued by that service: ..............................................................

10. Approval granted/extended/revised/refused/withdrawn (2)

11. Position of approval mark on vehicle: ..................................................................................

12. Place: ...................................................................................................................

13. Date: ...................................................................................................................

14. Signature: ..............................................................................................................

15. Annexed to this communication is a list of documents in the approval file deposited at the administration services having delivered the approval and which can be obtained upon request.

Additional information

16. R SWIN: .............................................................................................................

171

16.1. Information on how to read the R SWIN or software version(s) in case the R SWIN is not held on the 171 171

vehicle: .................................................................................................................

16.2. If applicable, list the relevant parameters that will allow the identification of those vehicles that can be updated with

the software represented by the R SWIN under the item above: .....................................................

171

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 33/80EN OJ L, 4.11.2024 ANNEX 2 Arrangements of approval marks MODEL A (See paragraph 4.4 of this Regulation) a = 8 mm min The above approval mark affixed to a vehicle shows that the vehicle type concerned has, with regard to DCAS, been approved in the Netherlands (E 4) pursuant to UN Regulation No 171 under approval No 002439. The approval number indicates that the approval was granted in accordance with the requirements of UN Regulation No 171 in its original version.

MODEL B (See paragraph 4.5 of this Regulation) a = 8 mm min The above approval mark affixed to a vehicle shows that the vehicle type concerned has been approved in the Netherlands (E 4) pursuant to UN Regulations Nos 171 and 31(1). The approval numbers indicate that, at the dates when the respective approvals were given, UN Regulation No 171 was in its original version and UN Regulation No 31 included the 02 series of amendments.

(1) The second number is given merely as an example.

34/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 ANNEX 3 Special requirements to be applied to the audit/assessment

1. General This Annex defines the special requirements for documentation, safety by design and verification with respect to the safety aspects of Electronic System(s) (paragraph 2.3) and Complex Electronic Control System(s) (paragraph

2.4 below) as far as this UN Regulation is concerned.

This Annex does not specify the performance criteria for ‘The System’ but covers the methodology applied to the design process and the information which must be disclosed to the Type Approval Authority or the Technical Service acting on its behalf (hereafter referred to as Type Approval Authority), for type approval purposes.

This information shall show that ‘The System’ respects, under non-fault and fault conditions, all the appropriate performance requirements specified elsewhere in this UN Regulation and that it is designed to operate in such a way that it is free of unreasonable safety risks to the driver, passengers and other road users.

Provisions in this UN Regulation of the form ‘the system shall…’ must always be complied with. Failure to meet such a requirement during assessment constitutes a non-compliance with the requirements established by this UN Regulation.

Provisions in this UN Regulation of the form ‘the system shall aim to…’ acknowledge that the requirement may not always be achieved (e.g., due to external disturbances or because it is not appropriate to do so under the specific circumstances).

Provisions in this UN Regulation of the form ‘the system shall be designed to…’ acknowledge that testing of system performance is not a comprehensive way to verify that the requirement is, or is not, complied-with, and that verification of the requirement will require an assessment of the system design (e.g. its control strategies).

If during assessment a requirement of the form ‘shall aim to...’ or ‘shall be designed to…’ is not fulfilled, the manufacturer shall demonstrate to the satisfaction of the Type Approval Authority why this was the case, and how the system nevertheless remains free from unreasonable risk.

2. Definitions For the purposes of this annex,

2.1. ‘The system’ means the hardware and software collectively capable of assisting a driver in controlling the longitudinal and lateral motion of the vehicle on a sustained basis. In the context of this Annex, this also includes any other system covered in the scope of this UN Regulation, as well as transmission links to or from other systems that are outside the scope of this UN Regulation, that acts on a function to which this UN Regulation applies.

Within this UN Regulation, the system is also referred to as ‘Driver Control Assistance System (DCAS)’.

2.2. ‘Safety Concept’ means a description of the measures designed into the System, for example within the electronic units, as to address system integrity and thereby ensure safe operation under fault (functional safety) and non- fault conditions (operational safety) in such a way that it is free of unreasonable safety risks to the vehicle occupants and other road users. The possibility of a fallback to partial operation or even to a backup system for vital vehicle functions may be a part of the safety concept.

2.3. ‘Electronic Control System’ means a combination of units, designed to cooperate in the production of the stated vehicle control function by electronic data processing. Such systems, commonly controlled by software, are built from discrete functional components such as sensors, electronic control units and actuators and connected by transmission links. They may include mechanical, electro-mechanical, electro-pneumatic or electro-hydraulic elements.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 35/80EN OJ L, 4.11.2024

2.4. ‘Complex Electronic Control Systems’ are those electronic control systems in which a function controlled by an electronic system may be over-ridden by a higher-level electronic control system/function. A function which is over-ridden becomes part of the complex electronic control system, as well as any overriding system/function within the scope of this UN Regulation. The transmission links to and from overriding systems/function outside of the scope of this UN Regulation shall also be included.

2.5. ‘Higher-Level Electronic Control’ systems/functions are those which employ additional processing and/or sensing provisions to modify vehicle behaviour by commanding variations in the function(s) of the vehicle control system. This allows complex systems to automatically change their objectives with a priority which depends on the sensed circumstances.

2.6. ‘Units’ are the smallest divisions of system components which will be considered in this annex, since these combinations of components will be treated as single entities for purposes of identification, analysis or replacement.

2.7. ‘Transmission links’ are the means used for inter-connecting distributed units for the purpose of conveying signals, operating data or an energy supply. This equipment is generally electrical but may, in some part, be mechanical, pneumatic or hydraulic.

2.8. ‘Range of control’ refers to an output variable and defines the range over which the system is likely to exercise control.

2.9. ‘Boundary of functional operation’ defines the boundaries of verifiable or measurable limits within which the system is designed to maintain control, as defined in paragraph 2.5 of this UN Regulation.

Within this UN Regulation, Boundaries of functional operation are also referred to as ‘System Boundaries’.

2.10. ‘Safety Related Function’ means a function of ‘the system’ that is capable of changing the dynamic behaviour of the vehicle. The system may be capable of performing more than one safety related function.

2.11. ‘Control Strategy’ means a strategy to ensure robust and safe operation of the function(s) of the system in response to a specific set of ambient and/or operating conditions (such as road surface condition, traffic intensity and other road users, adverse weather conditions, etc.). This may include the automatic deactivation of a function or temporary performance restrictions (e.g., a reduction in the maximum operating speed, etc.).

2.12. ‘Fault’ means an abnormal condition that can cause a failure. This can concern hardware or software.

2.13. ‘Failure’ means the termination of an intended behaviour of a component or a system of the System due to a fault manifestation.

2.14. ‘Unreasonable risk’ means the overall level of risk for the vehicle occupants and other road users which is increased compared to a manually driven vehicle in comparable transportation services and situations within the system boundaries.

2.15. ‘Highway’ means a road where pedestrians and cyclists are prohibited and which, by design, is equipped with a physical separation that divides the traffic moving in opposite directions.

2.16. ‘Non-Highway’ means a road other than a highway as defined in paragraph 2.15.

36/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

3. Documentation

3.1. Requirements The manufacturer shall provide a documentation package which gives access to the basic design of the system and the means by which it is linked to other vehicle systems or by which it directly controls output variables. The function(s) of the system and the safety concept, as laid down by the manufacturer, shall be explained.

Documentation shall be brief, yet provide evidence that the design and development has had the benefit of expertise from all the system fields which are involved. For periodic technical inspections, the documentation shall describe how the current operational status of the system can be checked.

The Type Approval Authority shall assess the documentation package to show that ‘The System’:

(a) Is designed to operate, under non-fault and fault conditions, in such a way that it is free from unreasonable risk; and

(b) Respects, under non-fault and fault conditions, all the appropriate performance requirements specified elsewhere in this UN Regulation; and

(c) Was developed according to the development process/method chosen by the manufacturer according to paragraph 3.4.4.

3.1.1. Documentation shall be made available in two parts:

(a) The formal documentation package for the approval, containing the material listed in paragraph 3. (with the exception of that of paragraph 3.4.4) which shall be supplied to the Type Approval Authority at the time of submission of the type approval application. This documentation package shall be used by the Type Approval Authority as the basic reference for the verification process set out in paragraph 4. of this Annex.

The Type Approval Authority shall ensure that this documentation package remains available for a period determined in agreement with the Type Approval Authority. This period shall be at least 10 years counted from the time when production of the vehicle is definitely discontinued.

(b) Additional confidential material and analysis data (intellectual property) of paragraph 3.4.4 which shall be retained by the manufacturer, but made open for inspection (e.g., on-site in the engineering facilities of the manufacturer) at the time of type approval. The manufacturer shall ensure that this material and analysis data remains available for a period of 10 years counted from the time when production of the vehicle is definitely discontinued.

3.2. Description of the functions of the system A description shall be provided which gives a simple explanation of all the functions, including control strategies, of the system and the methods employed to achieve the objectives, including a statement of the mechanism(s) by which control is exercised.

Any described function shall be identified and a further description of the changed rationale of the function’s operation provided.

Any enabled or disabled safety related functions providing assistance to the driver as defined in paragraph 2.1 of this UN Regulation, when the hardware and software are present in the vehicle at the time of production, shall be declared and are subject to the requirements of this Annex, prior to their use in the vehicle.

3.2.1. A list of all input and sensed variables shall be provided and the working range of these defined, along with a description of how each variable affects system behaviour.

3.2.2. A list of all output variables which are controlled by the system shall be provided and an explanation given, in each case, of whether the control is direct or via another vehicle system. The range of control exercised on each such variable shall be defined.

3.2.3. Limits defining the boundaries of functional operation shall be stated where appropriate to system performance.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 37/80EN OJ L, 4.11.2024

3.2.4. A declaration of the capability of the system and its features according to the model in Appendix 4 to this Annex shall be provided.

3.3. System layout and schematics

3.3.1. Inventory of components.

A list shall be provided, collating all the units of the system and mentioning the other vehicle systems which are needed to achieve the control function in question.

An outline schematic showing these units in combination, shall be provided with both the equipment distribution and the interconnections made clear.

3.3.2. Functions of the units The function of each unit of the system shall be outlined and the signals linking it with other units or with other vehicle systems shall be shown. This may be provided by a labelled block diagram or other schematic, or by a description aided by such a diagram.

3.3.3. Interconnections Interconnections within the system shall be shown by a circuit diagram for the electric transmission links, by a piping diagram for pneumatic or hydraulic transmission equipment and by a simplified diagrammatic layout for mechanical linkages. The transmission links both to and from other systems shall also be shown.

3.3.4. Signal flow, operating data and priorities There shall be a clear correspondence between transmission links and the signals carried between units. Priorities of signals on multiplexed data paths shall be stated wherever priority may be an issue affecting performance or safety.

3.3.5. Identification of units Each unit shall be clearly and unambiguously identifiable (e.g. by marking for hardware and marking or software output for software content) to provide corresponding hardware and documentation association.

Where functions are combined within a single unit or indeed within a single computer, but shown in multiple blocks in the block diagram for clarity and ease of explanation, only a single hardware identification marking shall be used. The manufacturer shall, by the use of this identification, affirm that the equipment supplied conforms to the corresponding document.

3.3.5.1. The identification defines the hardware and software version and, where the latter changes such as to alter the function of the Unit as far as this Regulation is concerned, this identification shall also be changed.

3.4. Safety concept of the manufacturer

3.4.1. The manufacturer shall provide a statement which affirms that the strategy chosen to achieve the system objectives will not, under non-fault conditions, prejudice the safe operation of the vehicle.

The manufacturer shall supplement this statement by an explanation showing in overall terms how the chosen strategy ensures that the system objectives does not prejudice the safe operation of the systems referred above, and by a description of the part of the validation plan supporting the statement.

The Type Approval Authority shall perform an assessment to establish that the manufacturer’s explanation of the chosen strategy is understandable, logical and that the validation plan is suitable and have been completed.

38/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 The Type Approval Authority may perform tests, or may require tests to be performed, as specified in paragraph 4. below, to verify that ‘the system’ operates as per the chosen strategy.

3.4.2. In respect of software employed in the system, the outline architecture shall be explained and the design methods and tools used shall be identified. The manufacturer shall show evidence of the means by which they determined the realisation of the system logic, during the design and development process.

3.4.3. The manufacturer shall provide the Type Approval Authority with an explanation of the design provisions built into the system so as to generate safe operation under fault conditions. Possible design provisions for failure in

the system are for example:

(a) Fall-back to operation using a partial system;

(b) Change-over to a separate back-up system;

(c) Removal of the high level function.

3.4.3.1. If the chosen provision selects a partial performance mode of operation under certain fault conditions, then these conditions shall be stated and the resulting limits of effectiveness defined.

3.4.3.2. If the chosen provision selects a second (back-up) means to realise the vehicle control system objective, the principles of the change-over mechanism, the logic and level of redundancy and any built in back-up checking features shall be explained and the resulting limits of back-up effectiveness defined.

3.4.3.3. If the chosen provision selects the removal of the higher-level function, all the corresponding output control signals associated with this function shall be inhibited, and in such a manner as to limit the transition disturbance.

3.4.4. The documentation shall be supported, by an analysis which shows, in overall terms, how the system will behave on the occurrence of any individual hazard or fault which will have a bearing on vehicle control performance or safety.

The chosen analytical approach(es) shall be established and maintained by the manufacturer and shall be made open for inspection by the Type Approval Authority at the time of the type approval.

The Type Approval Authority shall perform an assessment of the application of the analytical approach(es). The

assessment shall include:

(a) Inspection of the safety approach at the concept (vehicle) level with confirmation that it includes

consideration of:

(i) Interactions with other vehicle systems;

(ii) Malfunctions of the system, within the scope of this UN Regulation;

(iii) For functions defined in paragraph 3.2 of this UN Regulation: — Situations when a system free from faults may create safety critical risks (e.g. due to a lack of or wrong comprehension of the vehicle environment);

— Operational and system limitations; — Reasonably foreseeable misuse by the driver; — Intentional modification of the system.

(iv) Cyber-attacks having an impact on the safety of the vehicle.

This approach may be based on a Hazard/Risk analysis appropriate to system safety.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 39/80EN OJ L, 4.11.2024

(b) Inspection of the safety approach at the system level. This approach includes top down and bottom-up approach. The safety approach may be based on Failure Mode and Effect Analysis (FMEA), a Fault Tree Analysis (FTA) and a System-Theoretic Process Analysis (STPA) or any similar process appropriate to system functional and operational safety;

(c) Inspection of the validation plans and results. This validation shall/may include validation testing appropriate for validation, for example, Hardware in the Loop (HIL) testing, vehicle on-road operational testing, or any other testing appropriate for validation.

The assessment shall consist of checks of hazards, faults and failure conditions chosen by the Type Approval Authority to establish that the manufacturer’s explanation of the safety concept is understandable, logical and that the validation plans are suitable and have been completed.

The Type Approval Authority may perform tests or may require tests to be performed as specified in paragraph 4. to verify the safety concept.

3.4.4.1. This documentation shall itemize the parameters being monitored and shall set out, for each failure condition of the type defined in paragraph 3.4.4 of this Annex, the warning signal to be given to the driver and/or to service/ technical inspection personnel.

3.4.4.2. This documentation shall describe the measures in place to ensure the system does not prejudice the safe operation of the vehicle when the performance of the system is affected by environmental conditions e.g.

climatic, temperature, dust ingress, water ingress, ice packing.

Where this UN Regulation contains particular requirements for the operation of the system under different environmental conditions, this documentation shall describe the measures in place to ensure compliance with those requirements.

3.5. Safety Management System (Process Audit)

3.5.1. In respect of software and hardware employed in the system, the manufacturer shall demonstrate to the Type Approval Authority in terms of a safety management system that effective processes, methodologies and tools are in place, up to date and being followed within the organization to manage the safety and continued compliance throughout the product lifecycle (design, development, production and operation).

3.5.2. The safety management system shall comprise of the following key components:

(a) Safety policy and objectives, which establish safety practices with a clear safety policy, safety roles and responsibilities, and organizational safety objectives;

(b) Safety risk management which aims at managing the risk in a proactive way;

(c) Safety assurance to monitor, analyse, and measure overall safety performance;

(d) Safety promotion to ensure adequate information, education, and heighten the safety awareness of employees.

3.5.3. The design and development process shall be established including safety-by-design, requirements management, requirements’ implementation, testing, failure tracking, remedy and release.

3.5.4. The manufacturer shall institute and maintain effective communication channels between manufacturer departments responsible for functional/operational safety, cybersecurity and any other relevant disciplines related to the achievement of vehicle safety.

3.5.5. The manufacturer shall demonstrate that periodic independent internal process audits are carried out to ensure that the processes established in accordance with paragraphs 3.5.1 to 3.5.4 are implemented consistently.

40/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

3.5.6. The manufacturer shall put in place suitable arrangements (e.g. contractual arrangements, clear interfaces, quality management system) with suppliers to ensure that the supplier safety management system comply with the requirements of paragraphs 3.5.1 (except for vehicle related aspects like ‘operation’), 3.5.2, 3.5.3 and 3.5.5.

3.5.7. The documentation shall outline a system information strategy which aims to encourage the driver to review information on system operation when the driver operates the system (e.g. a regular notification at the start of the drive cycle when the system is switched to ‘on’ mode inviting the driver to review relevant materials).

4. Verification and test

4.1. The functional operation of the system, as laid out in the documents required in paragraph 3., shall be tested as

follows:

4.1.1. Verification of the function of the system The Type Approval Authority shall verify the system under non-fault conditions by testing a number of selected functions from those declared by the manufacturer in paragraph 3.2 above.

The verification of the performance of those selected functions shall be conducted following the manufacturer’s test procedures unless a test procedure is specified in this UN Regulation.

For cases where the system is subject to input signal(s) from systems outside the scope of this UN Regulation, the test shall be conducted using the test procedure of the relevant UN Regulation, or by another means that generates the relevant input signal(s), (e.g. simulation).

For complex electronic systems, these tests shall include scenarios whereby a declared function is overridden.

4.1.1.1. The verification results shall correspond with the description, including the control strategies, provided by the manufacturer in paragraph 3.2.

4.1.2. Verification of the safety concept of paragraph 3.4.

The reaction of the system shall be checked under the influence of a failure in any individual unit by applying corresponding output signals to electrical units or mechanical elements in order to simulate the effects of internal faults within the unit. The Type Approval Authority shall conduct this check for at least one individual unit, but shall not check the reaction of ‘The System’ to multiple simultaneous failures of individual units.

The Type Approval Authority shall verify that these tests include aspects that may have an impact on vehicle controllability and user information/interaction (HMI aspects).

4.1.2.1. The verification results shall correspond with the documented summary of the failure analysis, to a level of overall effect such that the safety concept and execution are confirmed as being adequate.

4.2. Simulation tools and mathematical models for verification of the safety concept may be used, in particular for scenarios that are difficult on a test track or in real driving conditions. Where used for this purpose, such methods shall be in accordance of Annex 5 of this UN Regulation. The manufacturer shall demonstrate the scope of the simulation tool, its validity for the scenario concerned as well as the validation performed for the simulation tool chain (correlation of the outcome with physical tests).

4.2.1. If virtual testing is performed by the manufacturer, the Type Approval Authority shall evaluate the declared results

provided by the manufacturer, in particular pertaining to safety metrics and the coverage of the system boundaries.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 41/80EN OJ L, 4.11.2024

4.3. The Type Approval Authority shall check a number of scenarios that are critical for the characterization of HMI functions of the system, as well as to verify the effective performance of the driver disengagement monitoring and warning system.

4.4. The Type Approval Authority shall also check a number of scenarios that are critical for controllability of system boundaries by the driver (e.g. object difficult to detect, when the system reaches its system boundaries, risk of collision with another road user) as defined in the regulation.

5. Reporting by Type Approval Authority The reporting of the assessment by the Type Approval Authority shall be performed in such a manner that it allows traceability, e.g. versions of documents inspected are coded and listed in the assessment records.

An example of a possible layout for the assessment form is given in Appendix 1 to this Annex.

42/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 Appendix 1 Model assessment form for electronic systems, and/or complex electronic systems

Test report No: ................................................................................................................

1. Identification

1.1. Make:

1.2. Vehicle Type:

1.3. Means of system identification on the vehicle:

1.4. Location of that marking:

1.5. Manufacturer’s name and address:

1.6. If applicable, name and address of manufacturer’s representative:

1.7. Manufacturer’s formal documentation package:

Documentation reference No: .......................................................................................

Date of original issue: ................................................................................................

Date of latest update: ................................................................................................

2. Test vehicle(s)/system(s) description

2.1. General description:

2.2. Description of all the control functions of the system, including control strategies (Paragraph 3.2 of this Annex):

2.2.1. List of input and sensed variables and their working range including a description the effect of the variable on system behaviour (Paragraph 3.2.1 of this Annex):

2.2.2. List of output variables and their range of control (Paragraph 3.2.2 of this Annex):

2.2.2.1. Directly controlled:

2.2.2.2. Controlled via another vehicle system:

2.3. Description System layout and schematics (Paragraph 3.3 of this Annex):

2.3.1. Inventory of components (Paragraph 3.3.1 of this Annex):

2.3.2. Functions of the units (Paragraph 3.3.2 of this Annex):

2.3.3. Interconnections (Paragraph 3.3.3 of this Annex):

2.3.4. Signal flow, operating data and priorities (Paragraph 3.3.4 of this Annex):

2.3.5. Identification of units (hardware & software) (Paragraph 3.3.5 of this Annex): ......................................

3. Manufacturer’s safety concept

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 43/80EN OJ L, 4.11.2024

3.1. Manufacturer’s declaration (Paragraph 3.4.1 of this Annex):

The manufacturer(s) ............. affirm(s) that the system objectives will not, under non-fault conditions, prejudice the safe operation of the vehicle.

3.2. Software (Outline architecture, software design methods and tools used) (Paragraph 3.4.2 of this Annex):

3.3. Explanation of design provisions built into the system under fault conditions (Paragraph 3.4.3 of this Annex):

3.4. Documented analyses of the behaviour of the system under individual fault conditions:

3.4.1. Parameters monitored:

3.4.2. Warning signals generated:

3.5. Description of the measures in place for environmental conditions (Paragraph 3.4.4.2 of this Annex):

3.6. Provisions for the periodic technical inspection of the system (Paragraph 3.1 of this Annex):

3.7. Description of the method by which the operational status of the system can be checked:

4. Verification and Test

4.1. Verification of the function of the system (Paragraph 4.1.1 of this Annex): .........................................

4.1.1. List of the selected functions and a description of the test procedures used:

4.1.2. Test results verified according to this Annex, paragraph 4.1.1.1: Yes/No

4.2. Verification of the system safety concept (Paragraph 4.1.2 of this Annex):

4.2.1. Unit(s) tested and their function:

4.2.2. Simulated fault(s):

4.2.3. Test results verified according to this Annex, paragraph 4.1.2: Yes/No

4.3. Date of test(s):

4.4. This test(s) has been carried out and the results reported in accordance with … to UN Regulation No 171 as last amended by the ... series of amendments.

Type Approval Authority carrying out the test

Signed: .................................................... Date: ......................................................

4.5. Comments:

44/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 Appendix 2 System design to be assessed during the audit/assessment

1. Introduction The following information shall be provided by the manufacturer for assessment by the Type Approval Authority.

2. Information related to DCAS in general

2.1. Driver Interaction and HMI

2.1.1. How the system is designed to ensure the driver remains engaged with the driving task, which includes an outline of the driver monitoring system and its warning strategy (paragraph 5.5.4.2)

2.1.1.1. Additional strategies for driver disengagement detection and re-engagement support (paragraph 5.5.4.2.7)

2.1.1.2. Evidence of effectiveness of driver disengagement monitoring and warning strategy

2.1.1.3. An outline of the driving task relevant areas, and their limits, and applicable values in the context of determining the driver’s visual disengagement in relation to the system and its features (paragraph 5.5.4.2.5.2)

2.1.1.4. Strategies to disable activation of the system in the context of repeated driver disengagement leading to more than one driver unavailability response (paragraph 5.5.4.2.8.1)

2.1.2. Measures taken to guard against reasonably foreseeable misuse by the driver and tampering of the system (paragraph 5.1.3)

2.1.3. Measures taken to encourage the driver’s understanding of the system’s limitations and their continued role in the driving task. (paragraph 5.1.2)

2.1.5. Model of the information provided to users (paragraph 5.6)

2.1.6. Extract of the relevant part of the owner`s manual

2.1.7. A list of system messages and signals (paragraph 5.5.4.1.4)

2.1.8. Timings and strategy to inform the driver about a (series of) driver-confirmed manoeuvre(s) (5.5.4.1.8.1)

2.1.9. Timings and strategy to inform the driver about a (series of) system-initiated manoeuvre(s) (5.5.4.1.9.1)

2.2. System Boundaries

2.2.1. The system’s ability to assess and respond to its surroundings as required to implement the intended functionality (paragraphs 5.3.2 and 5.3.5)

2.2.1.1. The boundary conditions of the system and its features, and strategy to notify the driver when those boundaries are exceeded, being met or approached(paragraph 5.3.2)

2.2.1.2. The system’s ability to maintain appropriate distances from other road users (paragraph 5.3.2.3)

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 45/80EN OJ L, 4.11.2024

2.2.1.3. The system’s ability to ensure safety, its behaviour and the impact on system performance when a feature remains in ‘active’ mode beyond the system boundaries (paragraph 5.3.5.2.2)

2.2.2. The boundaries for detection capabilities for the system and individual features (paragraph 5.3.1)

2.2.3. Evidence of continued safe operation of the system or its features when the system is unable to detect a declared system boundary (paragraph 5.3.5.4)

2.3. System operation

2.3.1. If/how the system adapts its behaviour to respond to identified safety risk of a collision (paragraph 5.3.2.2)

2.3.2. Additional preconditions for DCAS activation (paragraph 5.5.3.2.2)

2.3.3. The system’s controllability design (paragraphs 5.3.4 and 5.3.6)

2.3.3.1. Strategies ensuring controllability when the system no longer provides longitudinal or lateral assistance in response to driver override (paragraph 5.5.3.4.1.5)

2.3.4. Description of any transitions between DCAS and other assistance or automation systems, their prioritization of one over the other, and any suppression or deactivation of other assistance systems to ensure safe and nominal operation (paragraph 5.2.2)

2.3.5. System behaviour in response to changes in system-determined road speed limits in cases other than addressed in 5.3.7.4 (paragraph 5.3.7.4.7.3.4)

2.3.6. Technically reasonable tolerances to warning thresholds and operational limits (paragraph 5.3.7.4.10)

2.3.7. An outline of the system’s ability to provide continued assistance in the case of a failure disabling a given feature (paragraph 5.4.4)

3. Information related to System Dynamic Control

3.1. The strategy by which the system determines appropriate speed and resulting lateral acceleration in the context of lane of travel positioning (paragraph 5.3.7.1.3)

4. Information related to DCAS features (Where applicable)

4.1. Strategies to ensure controllability if the system induces higher lateral acceleration values and the conditions are no longer met (paragraph 6.1.1.2)

4.2. Other sources of information to determine lane positioning without lane markings (paragraph 6.1.4.1)

4.3. Evidence that a lane change manoeuvre is only started if a vehicle in the target lane is not forced to unmanageable decelerate due to the lane change (paragraph 6.2.5)

4.4. An outline of the strategies to ensure that the lane change procedure is only performed into or via a lane where the target lane is not designated for oncoming traffic (paragraph 6.2.9.3)

4.5. If the system can navigate around an obstruction in the lane of travel, sufficient evidence for other reasons to perform this manoeuvre (paragraph 6.3.9.1) 46/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 Appendix 3 Exemplary Classification of the System Detection Capabilities and Relevant System Boundaries The manufacturer shall explain the detection capabilities of DCAS, differentiated by features, if applicable, and the system boundaries for these detection capabilities. The following list shall be taken as guidance on possibly relevant objects and

events in different operating scenarios: — Road: type (highway, rural, etc.), surface (type, adhesion), geometry, lane characteristics, availability of lane markings, edge of road, road crossings; — Road facilities (traffic control facilities, special facilities (road construction markings), other facilities);

— Road events (e.g. road accidents, traffic congestion, road works); — Environmental conditions, such as: — Inclement weather, fog and mist; — Temperature; — Precipitation; — Time of day and light conditions;

— Other road users (e.g. motor vehicles, motorcycles, bicycles, pedestrians).

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 47/80EN OJ L, 4.11.2024 Appendix 4 Declaration of system capability The manufacturer shall declare the capability of the system and its features according to the classification of paragraph 6 based on the following criteria. This declaration serves as reference to the base tests to be performed according to Annex 4.

The system shall be considered to possess a capability as declared below if it is able to demonstrate the required behaviour in at least 90 % of the corresponding tests. Evidence of this capability shall be provided to the Type Approval Authority via appropriate documentation.

When conditions deviate from those specified for the corresponding test, the system shall not unreasonably switch its control strategy. This shall be demonstrated by the manufacturer to the Type Approval Authority in accordance to Annex 4.

1. System’s capability to respond to other road users A detailed description of scenarios can be found in Annex 4.

The manufacturer shall declare the maximum operational speed up to which the system is able to handle (i.e., to avoid a collision without driver intervention) the following scenarios as relevant for the system’s design:

Max. operational speed up to Max. operational speed up to which the system is able to which the system/vehicle is Operating domain Scenario avoid a collision with a able to avoid a collision requirement deceleration demand not requiring a deceleration exceeding 5 m/s2 demand exceeding 5 m/s2 Stationary vehicle ahead on a Highway straight section of road (Annex 4, par. 4.2.5.2.1.1) Stationary vehicle ahead on a Highway curved section of road (Annex 4, par. 4.2.5.2.2.1) Slower moving vehicle ahead Highway on straight section of road (Annex 4, par. 4.2.5.2.3.1) Cut-out of lead vehicle (Annex Highway 4, par. 4.2.5.2.5.1) Cut-in vehicle from adjacent Yes/No Yes/No Highway lane – Type 1 (Annex 4, par.

4.2.5.2.6.1)(1) Cut-in vehicle from adjacent Yes/No Yes/No Highway lane – Type 2 (Annex 4, par.

4.2.5.2.6.1)(1) Stationary pedestrian target Non-Highway ahead in lane (Annex 4, par.

4.2.5.2.8.1) 48/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 Max. operational speed up to Max. operational speed up to which the system is able to which the system/vehicle is Operating domain Scenario avoid a collision with a able to avoid a collision requirement deceleration demand not requiring a deceleration exceeding 5 m/s2 demand exceeding 5 m/s2 Stationary bicycle ahead in Non-Highway lane Annex 4, par. 4.2.5.2.9.1) Pedestrian target crossing into Non-Highway the path of the VUT (Annex 4, par. 4.2.5.2.10.1) Bicycle target crossing into the Non-Highway path of the VUT (Annex 4, par.

4.2.5.2.11.1) (To be completed by the manufacturer)

(1) The manufacturer is expected to declare whether a system response can be expected.

2. System’s capability to follow the course of the lane Minimum Lateral Specific conditions (e.g., Speed range(s) Maximum lateral acceleration Acceleration paragraph 6.1.1) (To be completed by the manufacturer)

2.1. Road events which the system may recognize relevant to the given declared system boundaries and system design, to be completed and possibly extended by the manufacturer, alternatively indicated as ‘Not Applicable’:

Considered a system System will not be System will be able System will be able boundary for the Operating Road event able to respond to to respond upon to provide an early system/specific domain this road event detection warning features? (yes/no) Toll station Highway End of highway Highway Permanent lane Highway ending Temporary lane Highway ending (e.g. due to broken down car) Long-Term Highway Construction zone Railway crossings Non-Highway

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 49/80EN OJ L, 4.11.2024 Considered a system System will not be System will be able System will be able boundary for the Operating Road event able to respond to to respond upon to provide an early system/specific domain this road event detection warning features? (yes/no) Intersections Non-Highway Pedestrian Non-Highway crossing Traffic lights Non-Highway

3. System’s ability to ensure safe operation when assisting lane changes (applicable to both driver- and system-initiated lane changes) The manufacturer shall declare the range at which the system is able to respond to other unobstructed targets if equipped with lane change feature. The manufacturer shall declare the conditions under which the maximum range

is reduced:

Rear (m) Front (m) Side (m) Conditions Range at which the system is able to respond to a motorcycle Range at which the Not applicable Not applicable system is able to respond to a blocked target lane Types of obstacles the Not applicable Not applicable vehicle is able to respond to (To be completed by the manufacturer)

4. The system’s ability to safely perform other driver-initiated or system-initiated manoeuvres in non-highway environments without driver intervention, alternatively indicated as ‘Not Applicable’:

Will the system be able to avoid a Preconditions under which the system will be collision in this scenario? able to avoid a collision Pedestrian target crossing into the path of the VUT in an intersection (Annex 4, par. 4.2.5.2.12.1) Bicycle target crossing into the path of the VUT in an intersection (Annex 4, par. 4.2.5.2.13.1) VUT turns across a path of an oncoming vehicle (Annex 4, par.

4.2.5.2.14.1) 50/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 Will the system be able to avoid a Preconditions under which the system will be collision in this scenario? able to avoid a collision VUT crosses the straight path of a vehicle target in an intersection (Annex 4, par. 4.2.5.2.15.1)

5. System’s ability to operate in accordance with traffic rules related to a certain driver-initiated manoeuvre The manufacturer shall declare traffic rule compliance related to a certain manoeuvre, if relevant to the given signal.

In case the system’s performance is specific to a country of operation, this may be additionally specified by the

manufacturer:

Potentially relevant traffic rule Will the system be designed to obey this rule? Duration of indication of the Lane Change Procedure (To be completed by the manufacturer)

6. System’s ability to operate in accordance with traffic rules related to a certain system-initiated manoeuvre The manufacturer shall declare traffic rule compliance related to a certain manoeuvre, if relevant to the given signal.

In case the system’s performance is specific to a country of operation, this may be additionally specified by the

manufacturer:

Potentially relevant traffic rule Will the system be designed to obey this rule? Not to unintentionally cross a solid lane marking during a system-initiated manoeuvre Not to change lanes when prohibited by a dedicated sign Yielding to other road users when turning left/right at an intersection as part of a system-initiated manoeuvre Yielding to other road users when exiting a roundabout as part of a system-initiated manoeuvre (To be completed by the manufacturer)

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 51/80EN OJ L, 4.11.2024 ANNEX 4 Physical Test Specifications for DCAS Validation

1. Introduction This Annex defines physical tests with the purpose to verify the technical requirements applicable to the system and the declaration made by the manufacturer according to Appendix 4 to Annex 3. All the tests in this annex shall be performed or witnessed by the Type Approval Authority or the Technical Service acting on its behalf (hereafter referred as ‘Type-Approval Authority’) during the approval process.

The specific test parameters for track tests shall be selected by the Type-Approval Authority based on the declaration made by the manufacturer and shall be recorded in the test report in such a manner that allows traceability and repeatability of the test setup.

Pass- and Fail-Criteria for tests are derived solely from the technical requirements in paragraphs 5. and 6. of this UN Regulation and correspondence with the declarations made according to Appendix 4 to Annex 3.

The tests specified in this document shall be intended as a minimum set of tests. The Type-Approval Authority may perform additional tests and compare the measured results against the requirements in paragraphs 5 and 6, or the contents of the Audit according to Annex 3.

2. Definitions For the purposes of this Annex,

2.1. ‘Time to Collision’ (TTC) means the time obtained by dividing the longitudinal distance (in the direction of travel of the VUT) between the VUT and the target by the longitudinal relative speed of the VUT and the target.

2.2. ‘Offset’ means the distance between the vehicle’s and the respective target’s longitudinal median plane in driving direction, measured on the ground.

2.3. ‘Pedestrian Target’ means a target that represents a pedestrian.

2.4. ‘Passenger Car Target’ means a target that represents a passenger car vehicle.

2.5. ‘Powered Two-Wheeler Target’ means a target that represents a combination of a motorcycle and motorcyclist.

2.6. ‘Bicycle Target’ means a target that represents a combination of a bicycle and a cyclist.

2.7. ‘Vehicle Under Test’ (VUT) means the vehicle equipped with the system to be tested.

2.8. ‘Base Test’ means a test scenario where the manufacturer shall declare a threshold for the missing boundary conditions (e.g. VUT speed) up to which the system is able to safely control the vehicle.

2.9. ‘Extended Testing’ means a set of test scenarios with a combination of test design variations to verify that the system does not unreasonably change the control strategy compared to the declared value and strategy in the base test, within the declared system boundaries.

3. General principles 52/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

3.1. Test conditions

3.1.1. The tests shall be performed under conditions (e.g. environmental, road geometry) that allow the activation of the system or specific features thereof. For conditions not tested that may occur within the defined system boundaries of the vehicle, the manufacturer shall demonstrate as part of the audit described in Annex 3 to the satisfaction of the Type-Approval Authority that the vehicle is safely controlled.

3.1.2. If system modifications are required in order to allow testing (e.g. road type assessment criteria), it shall be ensured that these modifications do not have an effect on the test results. These modifications shall be documented and annexed to the test report. The description and the evidence of influence (if any) of these modifications shall be documented and annexed to the test report.

3.1.3. In order to test the requirements for failure of functions, self-testing and initialisation of the system, errors may be artificially induced and the vehicle may be artificially brought into situations where it reaches the limits of the defined operating range (e.g., environmental conditions).

It shall be verified, that the condition of the system is according to the intended testing purpose (e.g. in a fault-free condition or with the specific faults to be tested).

3.1.4. The test surface shall afford at least the adhesion required by the scenario in order to achieve the expected test result.

3.1.5. Test Targets

3.1.5.1. The target used for the vehicle detection tests shall be a regular high-volume series production vehicle of Category M or N or alternatively a ‘soft target’ representative of a vehicle in terms of its identification characteristics applicable to the sensor equipment of the system under test according to ISO 19206-3.

The reference point for the location of the vehicle shall be the most rearward point on the centreline of the vehicle.

3.1.5.2. The target used for the Powered-Two-wheeler tests shall be a test device according to ISO 19206-5 or a type approved high volume series production motorcycle of Category L . The reference point for the 3 location of the motorcycle shall be the most backward point on the centreline of the motorcycle.

3.1.5.3. The target used for the pedestrian detection tests shall be an ‘articulated soft target’ and be representative of the human attributes applicable to the sensor equipment of the system under test according to ISO 19206-2.

3.1.5.4. The target used for bicycle detection tests shall be a device according to ISO 19206-4. The reference point for the location of the bicycle shall be the most forward point on the centreline of the bicycle.

3.1.5.5. As an alternative to reference targets, driverless robotised vehicles or state-of-the-art test tools (e.g., soft targets, mobile platforms, etc.) may be used to carry out the tests, replacing real vehicles and other road users that could reasonably be encountered within the system boundaries. It shall be ensured that the test tools replacing the reference targets have comparable characteristics to the vehicle or road user they are intended to represent, and are in agreement between the Type Approval Authority and the manufacturer.

3.1.5.6. Details that enable the target(s) to be specifically identified and reproduced shall be recorded in the vehicle type approval documentation.

3.1.6. Test parameter variation

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 53/80EN OJ L, 4.11.2024

3.1.6.1. The manufacturer shall declare the system boundaries to the Type Approval Authority. The Type Approval Authority shall define different combinations of test parameters (e.g., present speed of the vehicle under test, type and offset of the target, curvature of lane).

3.1.6.2. In order to confirm consistency of the system, base tests shall be carried out at least 2 times. If one of the two test runs fails to meet the required performance, the test shall be repeated once. A test shall be accounted as passed if the required performance is met in two test runs and the manufacturer has

provided sufficient evidence according to Annex 3 Appendix 4. The Type Approval Authority may choose to require additional test runs to confirm the declaration thresholds outlined in Annex 3 Appendix 4.

3.1.6.3. When conditions deviate from those specified for the base test, the system shall not unreasonably switch its control strategy. This shall be verified by the extended testing. Each parameter as outlined in the extended tests shall be varied, where variations can be grouped into a single test design. In addition, the Type Approval Authority may request additional documentation evidencing the system’s performance under parameter variations not tested.

3.1.7. Public road verification

3.1.7.1. Where applicable to the type of feature of the system, the Type Approval Authority shall conduct, or shall witness, an assessment of the system, in a fault-free condition, in the presence of traffic in at least in one country of operation. The purpose of this verification is to assess the behaviour of the system in a fault- free condition, in its operating environment.

4. Test procedures

4.1. Test scenarios to confirm general compliance with requirements of this UN Regulation Compliance with the requirements of this UN Regulation shall be demonstrated by physical test for the following paragraphs. Variations of the same test (e.g. reaching different boundary conditions) may be demonstrated by other means (e.g. part of the audit described in Annex 3 or virtual testing) in agreement with the Type Approval Authority.

4.1.1. Requirements and system aspects that shall be tested during the physical tests are described in table 1. The relevant requirements or system aspects shall be chosen based on the system boundaries.

Scenarios with the aim of testing the given requirement or aspect shall be created and described in agreement with the Type Approval Authority. Each requirement or aspect shall be assessed at least through track testing or public road verification. A given scenario may be used to assess different requirements/aspects of the system.

Test scenarios shall be created depending on the system preconditions for activation and system boundaries.

Table A4/1 Requirements and system aspects to be tested Requirements or system aspect to be assessed Physical test scenario or Reference in main text audit Driver Information, Driver Disengagement and Annex 3 Paras. 5.1.1 and 5.5.4 Warnings to the Driver 4.1.1 System Assurance of Absence of Driver Annex 3 Paras. 5.1.2 and 5.5.4.2 Disengagement 4.1.1 Reasonably foreseeable misuse Annex 3 Para. 5.1.3

4.1.1 54/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 Requirements or system aspect to be assessed Physical test scenario or Reference in main text audit System override Annex 3 Paras. 5.1.4 and 5.5.3.4

4.1.1 Equivalent performance of other safety systems (UN 4.2.5.2.1.1 Para. 5.1.5 Regulations No 131, No 152, No 79 and No 130) 4.2.5.2.2.1

4.2.5.2.3.1

4.2.5.2.4.1

4.2.5.2.8.1

4.2.5.2.9.1

4.2.5.2.10.1

4.2.5.2.11.1 Functional requirements (*) Para. 5.3 Assessment and response to surroundings as 4.2.5.2.5.1 Para. 5.3.2, 5.3.7.1.2 required for the functionality 4.2.5.2.6.1 Vehicle behaviour in traffic (Avoid disruption of 4.3.1 Paras. 5.3.4, traffic flow, maintain appropriate distance from 4.3.2 5.3.7.2, other road users, reduce risk of collision, 5.3.7.5, deceleration/acceleration, traffic rules, headway 5.4.2, distance) Activating relevant vehicle systems Annex 3 Para. 5.3.3

4.1.1 Detecting and Reaching DCAS boundaries Annex 3 Paras. 5.3.5, 5.3.7.1.4

4.1.1 Controllability Annex 3 Para. 5.3.6

4.1.1 Positioning in the lane of travel 4.2.4 Paras. 5.3.7.1,

4.2.5.1.1 6.1 Driver-initiated manoeuvres 4.2.5.1.2 Para. 5.3.7.2.2 Driver-confirmed manoeuvres 4.2.5.1.2 Para. 5.3.7.2.3,

5.5.4.1.8 System-initiated manoeuvres 4.2.4 Para. 5.3.7.2.4,

4.2.5.1.1 5.5.4.1.9 Driver unavailability response (*) Para. 5.3.7.3 Speed limit assistance 4.3 Para. 5.3.7.4 Failure response (*) Para. 5.4 DCAS operation, driver interaction and driver (*) Para. 5.5 information Lane change (*) Para. 6.2 Driver-confirmed lane changes (*) Para. 6.2.9.1 System-initiated Lane Change 4.2.4 Para. 6.2.9.2

4.2.5.1.1 Other manoeuvres 4.3.3 Para. 6.3 (*) Scenarios and test procedures for these items shall be agreed between the manufacturer and the Type Approval Authority.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 55/80EN OJ L, 4.11.2024

4.2. Test scenarios to assess system behaviour

4.2.1. Test scenarios shall be selected depending on the system’s preconditions for activation and system boundaries.

4.2.2. The tests can be performed either on a test track, or, where possible and without any safety risk to the vehicle occupants and other road users, on public roads.

Test scenarios that may cause danger to other road users and the test personnel (e.g. AEB equivalent performance, driver unavailability response, high lateral accelerations, etc.) shall be aimed to be tested on a test track.

4.2.2.1. The tests shall be performed in a way that the outcome of the test is not affected by driver settings or driver input and any other influences not related to the manoeuvre under test. Therefore, the following

conditions shall apply:

(a) The system’s longitudinal control following distance shall be set to:

(i) the default distance, if the distance is reset to a specific value upon first activation of the system in the run cycle; or

(ii) the closest driver adjustable following distance, if the distance is not reset to a default value;

(b) The system’s longitudinal control set speed shall be set to the speed indicated in the test or the speed declared by the manufacturer according to Annex 3 Appendix 4;

(c) The system must be in ‘active’ mode before the lower of 10 s TTC or 250 m relative longitudinal distance;

(d) There shall be no corrective driver input to the steering control.

The manufacturer shall declare any other relevant conditions to be met for correct execution of each test.

4.2.3. Tests must not be carried out in such a way as to endanger the personnel involved and significant damage of the vehicle under test must be avoided where other means of validation are available.

4.2.4. Lane Markings and Lane Geometry

4.2.4.1. Where base tests are required to be performed on a curved section of road, the geometry shall fulfil the following criteria (S-bend means both turns in the listed order, curved section of the road means the 2nd turn):

Clothoid parameter Radius (m) Length (m) First turn (Any direction) 153,7 - 30,0 - 787 57,1 105,0 - 14,0 Second turn (Opposite 98,6 - 26 direction to the 1st turn) - 374 5,1 120,8 - 39 At the request of the manufacturer and with the agreement of the Type Approval Authority, tests may be conducted on a road of different curvature, provided this does not change the intention or lower the severity of the test.

4.2.5. At the time of type approval, the Type Approval Authority shall conduct or shall witness at least the

following tests to assess the behaviour of the system based on the declared operating domains:

56/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

4.2.5.1. Test scenarios for different DCAS Features

4.2.5.1.1. Positioning in the lane of travel

4.2.5.1.1.1. Base Test: The test shall confirm positioning in the lane of travel capabilities declared by the manufacturer.

4.2.5.1.1.1.1. Functional part I: The VUT speed shall remain in the range declared by the manufacturer in paragraphs

9.1.1 and 9.1.2 of this UN Regulation.

The test shall be carried out for each speed range declared by the manufacturer in paragraphs 9.1.1 and 9.1.2 of this UN Regulation separately or within contiguous speed ranges where the declared maximum lateral acceleration is identical.

The VUT shall be driven without any force applied by the driver on the steering control (e.g. by removing the hands from the steering control) with a constant speed on a curved track with lane markings at each side.

The necessary lateral acceleration to follow the curve shall be between 80 and 90 per cent of the maximum lateral acceleration declared by the manufacturer in Annex 3 Appendix 4 of this UN Regulation.

4.2.5.1.1.1.2. The VUT speed shall remain in the range declared by the manufacturer in paragraphs 9.1.1 and 9.1.2 of this UN Regulation.

The test shall be carried out for each speed range declared by the manufacturer in paragraphs 9.1.1 and 9.1.2 of this UN Regulation separately or within contiguous speed ranges where the declared maximum lateral acceleration is identical.

The VUT shall be driven without any force applied by the driver on the steering control (e.g. by removing the hands from the steering control) with a constant speed on a curved track with lane markings at each side.

The Type Approval Authority shall define a test speed and a radius which would provoke a higher acceleration than the declared maximum lateral acceleration + 0,3 m/s2 (e.g. by travelling with a higher speed through a curve with a given radius).

4.2.5.1.1.2. Extended Testing:

The test shall demonstrate that the system does not leave its lane and maintains a stable motion inside its ego lane across the speed range and different curvatures within its system boundaries up to the maximum lateral acceleration declared by the manufacturer.

4.2.5.1.1.2.1. The test shall be executed at least:

(a) With sufficient length to allow for an assessment of positioning in the lane of travel behaviour;

(b) For different road curvatures, including an S-bend with the parameters according to paragraph 4.2.4.1 or equivalent, and different initial speeds, at least one exceeding the maximum lateral acceleration declared by the manufacturer;

(c) With different types of lane boundaries (e.g. markings, road edges, only one lane marking) as applicable to the system.

4.2.5.1.2. Driver-initiated lane changes

4.2.5.1.2.1. Base Test: The test shall confirm the driver-initiated lane changing capabilities of the system declared by the manufacturer.

4.2.5.1.2.1.1. The VUT shall perform a full lane change (3,5 m lateral displacement) into the adjacent lane after the driver initiated the LCP.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 57/80EN OJ L, 4.11.2024

4.2.5.1.2.1.2. The VUT and the lead vehicle shall travel in a straight line, in the same direction, for at least two seconds prior to the functional part of the test with a VUT to lead vehicle centreline offset of not more than 1 m.

4.2.5.1.2.1.3. Tests shall be conducted with a lead vehicle travelling at least 20 km/h slower than the set speed limit of the VUT.

4.2.5.1.2.2. Extended Testing:

The test shall assess the system’s ability to assist the driver within its boundary conditions/manufacturer’s

declared system features in changing lanes safely:

(a) With other speed differences between the lead vehicle and VUT;

(b) On roads without physical separation;

(c) On roads where pedestrians and cyclists are not prohibited;

(d) Where the lane change cannot be executed immediately after its initiation by the driver.

4.2.5.1.2.2.1. The test shall be executed at least:

(a) On a road with oncoming or overtaking traffic in the target lane;

(b) With different road users approaching from the rear;

(c) With a vehicle driving beside in the adjacent lane preventing a lane change;

(d) In a scenario where the system reacts to another vehicle that starts changing into the same space within the target lane, to avoid a potential risk of collision.

4.2.5.1.4. System-initiated lane changes

4.2.5.1.4.1. Base Test: The test shall confirm system-initiated lane changing capabilities declared by the manufacturer.

4.2.5.1.4.1.1. The VUT shall perform a full lane change (3,5 m lateral displacement) into the adjacent lane after the system has initiated the LCP.

4.2.5.1.4.1.2. The VUT and the lead vehicle shall travel in a straight line, in the same direction, for at least two seconds prior to the functional part of the test with a VUT to lead vehicle centreline offset of not more than 1 m.

58/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

4.2.5.1.4.2. Extended Testing: The test shall demonstrate that the system is able to assist the driver in changing lanes

safely:

(a) With other speed differences between the lead vehicle and VUT;

(b) On roads without physical separation; and/or

(c) On roads where pedestrians and cyclists are not prohibited.

4.2.5.1.4.2.1. The test shall be executed at least:

(a) On a road with oncoming or overtaking traffic in the target lane;

(b) With different road users approaching from the rear;

(c) With a vehicle driving beside in the adjacent lane preventing a lane change;

(d) In a scenario where the system reacts to another vehicle that starts changing into the same space within the target lane, to avoid a potential risk of collision.

4.2.5.2. Ability to respond to another road user corresponding to the declared operating domains

4.2.5.2.1. Stationary vehicle ahead on a straight section of road

4.2.5.2.1.1. Base Test: The test shall confirm the declared response capability of the system for a stationary vehicle ahead on straight section of road.

4.2.5.2.1.1.1. The VUT shall approach the stationary target in a straight line for at least 2 seconds prior to the functional part of the test with a VUT to target centreline offset of not more than 0,5 m.

4.2.5.2.1.1.2. The functional part of the test shall begin with:

(a) The VUT travelling at the required test speed within the tolerances and within the lateral offset prescribed in this paragraph; and

(b) A distance corresponding to a time of at least 4 seconds before the DCAS vehicle begins to react to the target.

4.2.5.2.1.2. The tolerances shall be respected between the start of the functional part of the test and the system intervention.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 59/80EN OJ L, 4.11.2024

4.2.5.2.1.3. Extended Testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a stationary vehicle ahead on straight section of road.

4.2.5.2.1.3.1. The test shall be executed at least with:

(a) A stationary vehicle of a different type or category;

(b) A stationary vehicle positioned at a larger offset to the VUT’s centreline;

(c) A stationary vehicle facing towards the VUT for systems that are able to operate in non-highway conditions.

4.2.5.2.2. Stationary vehicle ahead on a curved section of road

4.2.5.2.2.1. Base Test: The test shall confirm the declared response capability of the system for a stationary vehicle ahead on curved section of road.

4.2.5.2.2.1.1. The target shall be positioned within a 0,5 m offset between the centreline of the target vehicle and the centreline of the lane around the bend (1st turn defined in 4.2.4.1 of this Annex) so that the rear corner is touching the extrapolated lane line if the straight were to continue.

4.2.5.2.2.1.2. The VUT vehicle shall be driven along the straight section of the fully marked lane at a constant speed with the system on for enough time for the lateral control to take up a constant position within the lane, prior to the start of the curved section of road.

4.2.5.2.2.2. Extended Testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a stationary vehicle ahead on curved section of road.

4.2.5.2.2.2.1. The test shall be executed at least with:

(a) A stationary vehicle of a different type or category;

(b) A stationary vehicle positioned with a larger offset from the centre position of the lane;

(c) An angle of a stationary vehicle to the centreline of the lane;

(d) A stationary vehicle facing towards the VUT depending for systems capable of operating in non- highway conditions.

4.2.5.2.3. Slower moving vehicle ahead on a straight section of road 60/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

4.2.5.2.3.1. Base Test: The test shall confirm the declared response capability of the system for a slower moving vehicle ahead on a straight section of road.

4.2.5.2.3.1.1. The VUT and the target shall travel in a straight line, in the same direction, for at least two seconds prior to the functional part of the test with a VUT to target centreline offset of not more than 0,5 m.

4.2.5.2.3.1.2. The tests shall be conducted with a slower moving vehicle target travelling 50 km/h slower than the VUT.

4.2.5.2.3.2. Extended Testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a slower moving vehicle ahead on straight section of road.

4.2.5.2.3.2.1. The test shall be executed at least:

(a) A slower moving vehicle of a different type or category;

(b) A slower moving vehicle positioned at a larger offset to the VUT’s centreline;

(c) A slower moving vehicle with a larger speed difference to the VUT’s speed.

4.2.5.2.4. (Reserved)

4.2.5.2.5. Cut-out of lead vehicle

4.2.5.2.5.1. Base Test: The test shall confirm the declared response capability of the system for a cut-out of the lead M 1 category vehicle.

4.2.5.2.5.1.1. The vehicle cutting out shall perform a full lane change (3,5 m lateral displacement) into the adjacent lane to avoid the stationary vehicle target, with the measurement behind the stationary vehicle target indicating that start of the lane change, and the measurement in front of the stationary vehicle target indicating the end of the lane change.

4.2.5.2.5.1.2. The indicated TTC is defined as the TTC of the lead vehicle to the target when the lead vehicle will start the lane change. Indicators are not to be used by the lead vehicle during the manoeuvre.

4.2.5.2.5.1.3. The cutting out vehicle shall not deviate from its defined path by more than ± 0,2 m.

Lane change manoeuvre of SOV Lead vehicle Cut-out test VUT (M Category) Lane change Radius of turning 1 Lateral acceleration length segment Cut-out at TTC = 3 s 70km/h 50km/h 1,5m/s2 44m 130m

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 61/80EN OJ L, 4.11.2024

4.2.5.2.5.2. Extended Testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a cut-out of the lead vehicle.

4.2.5.2.5.2.1. The test shall be executed at least with:

(a) A stationary vehicle target of a different type or category;

(b) The cut-out occurring at less than 3 s TTC of the lead vehicle;

(c) Different speeds of the VUT and lead vehicle;

(d) Different lateral acceleration of the lead vehicle.

4.2.5.2.6. Cut-in of vehicle from adjacent lane

4.2.5.2.6.1. Base Test: The test shall confirm the declared response capability of the system for a cut-in of the vehicle from adjacent lane.

4.2.5.2.6.1.1. The vehicle target on the adjacent lane shall perform a full lane change (3,5 m lateral displacement) into the lane of the VUT.

4.2.5.2.6.1.2. The indicated TTC is defined as the TTC at the point in time that the target has finished the lane change manoeuvre, where the rear centre of the vehicle target is in the middle of the VUT’s driving lane.

4.2.5.2.6.1.3. The cutting in vehicle shall not deviate from its defined path by more than ± 0,2 m.

Lane change manoeuvre of the GVT Cut-in test Global (Paragraph VUT Vehicle Lateral Lane change Radius of turning

4.2.5.2.6.1.2) Target (GVT) acceleration length segment Type 1– Cut-in at 50km/h 10km/h 0,5m/s2 14m 15m TTC = 0 s Type 2 – Cut-in at 120km/h 70km/h 1,5m/s2 60m 250m TTC = 1,5 s 62/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

4.2.5.2.6.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a cut-in of vehicle from adjacent lane.

4.2.5.2.6.2.1. The test shall be executed at least with:

(a) A cutting g-in vehicle of a different type or category;

(b) The cut-in occurring at a different TTC value;

(c) Different speeds of the VUT and target;

(d) Different lateral acceleration of the target.

4.2.5.2.8. Stationary pedestrian ahead in lane

4.2.5.2.8.1. Base Test: The test shall confirm the declared response capability of the system for a stationary pedestrian.

4.2.5.2.8.1.1. The pedestrian target shall be positioned within the driving path of the VUT facing away from the VUT.

4.2.5.2.8.1.2. The VUT shall approach the impact point with the pedestrian target in a straight line for at least two seconds prior to the functional part of the test.

4.2.5.2.8.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a stationary pedestrian.

4.2.5.2.8.2.1. The test shall be executed at least with:

(a) A pedestrian target positioned within the lane, but outside of the driving path of the VUT;

(b) A pedestrian target positioned facing in a different direction;

(c) A pedestrian target of a different size;

(d) A different speed of the VUT.

4.2.5.2.9. Stationary bicycle target ahead in lane

4.2.5.2.9.1. Base Test: The test shall confirm the declared response capability of the system for a stationary target and any lateral movement navigating around the target, if applicable.

4.2.5.2.9.1.1. The bicycle target shall be positioned within the driving path of the VUT facing away from the subject vehicle.

4.2.5.2.9.1.2. The VUT shall approach the impact point with the bicycle target in a straight line for at least two seconds prior to the functional part of the test.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 63/80EN OJ L, 4.11.2024

4.2.5.2.9.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a stationary bicycle.

4.2.5.2.9.2.1. The test shall be executed at least with:

(a) A bicycle target positioned with different offsets up to the target being outside of the driving path of the VUT;

(b) A bicycle target positioned facing in a different direction;

(c) A different speed of the VUT;

(d) A bicycle target facing towards the subject vehicle.

4.2.5.2.10. Pedestrian target crossing into the path of the VUT

4.2.5.2.10.1. Base Test: The test shall confirm the declared response capability of the system for a crossing pedestrian target.

4.2.5.2.10.1.1. The functional part of the test shall start with:

(a) The VUT travelling at the required test speed within the tolerances and within the lateral offset prescribed in this paragraph, and

(b) A distance corresponding to a TTC of at least 4 seconds from the target.

4.2.5.2.10.1.2. The tolerances shall be respected between the start of the functional part of the test and the system intervention.

4.2.5.2.10.1.3. The pedestrian target shall travel in a straight line perpendicular to the VUT’s direction of travel at a constant speed of 5 km/h + 0/– 0,4 km/h, starting not before the functional part of the test has started.

The pedestrian target’s positioning shall be coordinated with the VUT in such a way that the impact point of the pedestrian target on the front of the VUT is on the longitudinal centreline of the VUT with a tolerance of not more than 0,2 m, if the VUT would remain at the prescribed test speed throughout the functional part of the test and does not brake.

4.2.5.2.10.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a crossing pedestrian target.

4.2.5.2.10.2.1. The test shall be executed at least:

(a) A pedestrian target of a different size;

64/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

(b) A pedestrian target moving at a different, but constant speed;

(c) A different angle of the pedestrian target path to the VUT path.

4.2.5.2.11. Bicycle crossing into the path of the VUT

4.2.5.2.11.1. Base Test: The test shall confirm the declared response capability of the system for a crossing bicycle target.

4.2.5.2.11.1.1. The bicycle target shall travel in a straight line perpendicular to the VUT’s direction of travel at a constant speed of 15 km/h + 0/– 1 km/h, starting not before the functional part of the test has started. During the acceleration phase of the bicycle target prior to the functional part of the test the bicycle target shall be obstructed. The bicycle target’s positioning shall be coordinated with the VUT in such a way that the impact point of the bicycle target on the front of the VUT is on the longitudinal centreline of the VUT with a tolerance of not more than 0,2 m, if the VUT would remain at the prescribed test speed throughout the functional part of the test and does not brake.

4.2.5.2.11.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a crossing bicycle target.

4.2.5.2.11.2.1. The test shall be executed at least with:

(a) A bicycle target moving at a different but constant speed;

(b) A different angle of the bicycle path to the subject vehicle path;

(c) A different offset.

4.2.5.2.12. Pedestrian target crossing into the path of the VUT in an intersection

4.2.5.2.12.1. Base Test: The test shall confirm the declared response capability of the system for a crossing pedestrian target in an intersection.

4.2.5.2.12.1.1. The functional part of the test shall start with:

(a) The VUT travelling at the required test speed and within the lateral offset prescribed in this paragraph, and

(b) A distance corresponding to a TTC of at least 4 seconds from the target.

4.2.5.2.12.1.3. The tolerances shall be respected between the start of the functional part of the test and the system intervention.

4.2.5.2.12.1.4. The pedestrian target shall travel in a straight line at a constant speed of 5 km/h + 0/– 0,4 km/h, starting not before the functional part of the test has started. The pedestrian target’s positioning shall be coordinated with the VUT in such a way that the impact point of the pedestrian target on the front of the VUT is on the longitudinal centreline of the VUT with a tolerance of not more than 0,2 m, if the VUT would remain at the prescribed test speed throughout the functional part of the test and does not brake.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 65/80EN OJ L, 4.11.2024

4.2.5.2.12.1.5. The test run shall be executed with the pedestrian target moving parallel to the near side from the VUT according to the diagram below.

4.2.5.2.12.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a crossing pedestrian target in an intersection. Up to four different scenarios shall be executed far and near side with the pedestrian target moving at both sides of the road.

4.2.5.2.12.2.1. The test shall be executed at least with:

(a) A pedestrian target of a different size;

(b) A pedestrian target moving at a different but constant speed;

(c) A pedestrian target colliding with the vehicle at a different impact point or avoiding the vehicle;

(d) A variation of the visibility conditions (e.g., night time), as appropriate to the declared system boundaries.

4.2.5.2.13. Bicycle target crossing into the path of the VUT in an intersection

4.2.5.2.13.1. Base Test: The test shall confirm the declared response capability of the system for a crossing bicycle target in an intersection.

4.2.5.2.13.1.1. The bicycle target shall travel in a straight line perpendicular to the VUT’s direction of travel at a constant speed of 15 km/h + 0/– 1 km/h, starting not before the functional part of the test has started. During the acceleration phase of the bicycle target prior to the functional part of the test the bicycle target shall be obstructed. The bicycle target’s positioning shall be coordinated with the VUT in such a way that the impact point of the bicycle target on the front of the VUT is on the longitudinal centreline offset of not more than 0,2 m, if the VUT would remain at the prescribed test speed throughout the functional part of the test and does not brake.

66/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

4.2.5.2.13.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a crossing bicycle target in an intersection.

4.2.5.2.13.2.1. The test shall be executed at least with:

(a) A bicycle target moving at a different but constant speed;

(b) A bicycle target colliding with the vehicle at a different impact position or avoiding the vehicle.

4.2.5.2.14. VUT turns across a path of an oncoming vehicle

4.2.5.2.14.1. Base Test: The test shall confirm the declared response capability of the system for an oncoming vehicle target while the VUT is turning in an intersection.

4.2.5.2.14.1.1. The VUT shall approach the impact point with another vehicle (passenger car or motorcycle) target in an initial straight line followed by a turn in an intersection to cross front edges of a target vehicle with a lateral position that gives a 50 % overlap of the width of the VUT.

4.2.5.2.14.1.2. The target shall approach at a speed of up to 60 km/h, depending on the declared system boundaries.

4.2.5.2.14.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for an oncoming vehicle target while the VUT is turning in an intersection.

4.2.5.2.14.2.1. The test shall be executed at least with:

(a) Different target vehicle types or categories;

(b) Different overlaps;

(c) Different lane position of both vehicles;

(d) Target lane is (partially) blocked.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 67/80EN OJ L, 4.11.2024

4.2.5.2.15. VUT crosses the straight path of the vehicle target in an intersection

4.2.5.2.15.1. Base Test: The test shall confirm the declared response capability of the system to recognize and offer right of way for a crossing vehicle target driving straight in an intersection.

4.2.5.2.15.1.1. The VUT shall approach the impact point with another vehicle (passenger car or motorcycle) target in an initial straight line in an intersection from either the near side or far side direction to collide the side of the target vehicle at 25 % along the length of the target with the centre front of the VUT.

4.2.5.2.15.1.2. The target shall approach at a speed of up to 60 km/h, depending on the declared system boundaries. The VUT is expected to give right of way.

4.2.5.2.15.2. Extended testing: The test shall demonstrate that the system is not unreasonably changing the control strategy for a crossing vehicle target driving straight in an intersection.

4.2.5.2.15.2.1. The test shall be executed at least with:

(a) Different target vehicles types or categories;

68/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

(b) Different overlaps;

(c) Different lane positions of the VUT and target vehicles.

4.3. Public Road Verification

4.3.1. The location and selection of the test route, time-of-day and environmental conditions shall be determined by the Type Approval Authority. Public road verification shall cover different time-of-day and light intensity according to the system boundaries. They shall include scenarios in which the system is expected to experience challenging scenarios (e.g. tight curvatures, speed changes caused by variable infrastructural and traffic conditions, variable lead vehicle behaviour, variable road speed limits) and to approach the limits of its declared system boundaries (e.g. changes in visibility or road conditions, planned or sudden end of system boundaries).

4.3.2. The duration of public road tests shall be such that allows the recording and assessment of the system operation according to all relevant parts of the specification described in paragraphs 5. and 6., excluding safety critical and failure related scenarios.

4.3.3. Test scenarios to assess the behaviour of the system in other driver- or system-initiated manoeuvres

4.3.3.1. Public road verification shall include the test scenarios in the table below to assess the behaviour of the system under normal real-world operating conditions.

The routing shall be planned such that it incorporates the test scenarios, which are relevant according to the declaration of the manufacturer in Annex 3 of this UN regulation.

The test plan created by the Type Approval Authority shall cover the scenarios to assess the specific capability in a variety of circumstances.

4.3.3.2. Evidence of the system’s behaviour in any type of scenario which are relevant according to the declaration of the manufacturer in Annex 3 of this UN Regulation shall be additionally provided by the manufacturer (e.g., based on virtual testing).

Specific reference requirements (non- Category Type of scenario exhaustive list) Other manoeuvres Lead the vehicle to select a lane Paras. 6.3.1. – 6.3.9.4.

Enter into a roundabout or take an exit when navigating through a roundabout Lead the vehicle to leave its lane of travel when this manoeuvre is not a lane change Lead the vehicle to take a turn Lead the vehicle to depart or arrive at a parked position Other system-initiated Lead the vehicle to select a lane (Reserved) manoeuvres Enter into a roundabout or take a specific exit when navigating through a roundabout Lead the vehicle to leave its lane of travel when this manoeuvre is not a lane change Lead the vehicle to take a turn Lead the vehicle to depart or arrive at a parked position

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 69/80EN OJ L, 4.11.2024

4.3.4. For any other relevant types of scenarios according to the system capability and system boundaries declared by the manufacturer according to Annex 3 that could not be encountered during the public road tests, the manufacturer shall provide appropriate evidence from the manufacturer’s internal system validation to the satisfaction of the Type Approval Authority.

4.3.5. The verification drive shall be recorded and, if necessary, the test vehicle instrumented with additional non- perturbing equipment. The Type Approval Authority may log, or request logs of any data channels used or generated by the system as deemed necessary for post-test evaluation.

4.3.6. It is recommended that the public road verification is undertaken once the system has passed all of the track tests outlined in this Annex and upon completion of Annex 3.

70/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024 ANNEX 5 Principles for Credibility Assessment for using Virtual Toolchain in DCAS Validation

1. General

1.1. It is recommended that the Modelling and Simulation (M&S) toolchain could be used for virtual testing if its credibility is established by evaluating its fitness for the intended purpose. It is recommended that credibility is achieved by investigating and assessing five M&S properties:

(a) Capability – what the M&S can do, and what are the associated risks;

(b) Accuracy how well M&S does reproduce the target data;

(c) Correctness – how sound & robust is the M&S data and the algorithms in the tools;

(d) Usability – what training and experience is needed and what is the quality of the process that manage its use;

(e) Fit for Purpose – how suitable is the M&S toolchain for the assessment of the DCAS within its system boundaries.

Figure A5/1 Graphical representation of the relationships between the components of the credibility assessment framework

1.2. Therefore, credibility requires a unified method to investigate these properties and get confidence in the M&S results. The Credibility Assessment framework introduces a way to assess and report the credibility of M&S based on quality assurance criteria that allow an indication of the levels of confidence in results.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 71/80EN OJ L, 4.11.2024 In other words, the credibility is established by evaluating the key influencing factors that are the main contributors to the behaviour of the models and simulation tools and therefore affect the overall M&S toolchain credibility. The following all have an influence on the overall M&S credibility: organizational management of the M&S activity, team’s experience and expertise, the analysis and description of the chosen M&S toolset, the pedigree of the data and inputs, verification, validation, uncertainty characterization.

How well each of these factors is addressed indicates the level of quality achieved by M&S toolchain, and the comparison between the obtained levels and the required levels provides a qualitative measure of the M&S credibility and fitness for its use in virtual testing. A graphical representation of the relationship among the components of the credibility assessment framework is reported in Figure 1.

2. Definitions

For the purposes of this annex:

2.1. (reserved)

2.2. (reserved)

2.3. ‘Abstraction’ is the process of selecting the essential aspects of a source system or referent system to be represented in a model or simulation, while ignoring those aspects not relevant. Any modelling abstraction carries with it the assumption that it should not significantly affect the intended uses of the simulation tool.

2.4. ‘Closed Loop Testing’ means a virtual environment that does take the actions of the element-in-the loop into account. Simulated objects respond to the actions of the system (e.g. system interacting with a traffic model).

2.5. ‘Deterministic’ is a term describing a system whose time evolution can be predicted exactly and a given set of input stimuli will always produce the same output.

2.6. ‘Driver-In-the-Loop’ (DIL) is typically conducted in a driving simulator used for testing the human–automation interaction design. DIL has components for the driver to operate and communicate with the virtual environment.

2.7. ‘Hardware-In-the-Loop’ (HIL) involves the final hardware of a specific vehicle sub-system running the final software with input and output connected to a simulation environment to perform virtual testing. HIL testing provides a way of replicating sensors, actuators and mechanical components in a way that connects all the I/O of the Electronic Control Units (ECU) being tested, long before the final system is integrated.

2.8. ‘Model’ is a description or representation of a system, entity, phenomenon, or process.

2.9. ‘Model calibration’ is the process of adjusting numerical or modelling parameters in the model to improve agreement with a referent.

2.10. ‘Model Parameter’ are numerical values used to support characterizing a system functionality. A model parameter has a value that cannot be observed directly in the real world but that must be inferred from data collected in the real world (in the model calibration phase).

2.11. ‘Model-In-the-Loop’ (MIL) is an approach which allows quick algorithmic development without involving dedicated hardware. Usually, this level of development involves high-level abstraction software frameworks running on general-purpose computing systems.

72/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

2.12. ‘Open Loop Testing’ is a virtual testing approach where a data provision unit provides input stimuli to a DCAS.

There is no feedback between the DCAS and the environment provided via the input stimuli, hence the loop is ‘open’. The data provision unit can play back a recorded traffic situation, e.g., from a real-world drive.

Environment data can also be generated (simulator approach) or measured (shadow mode) while testing.

2.13. ‘Probabilistic’ is a term pertaining to non-deterministic events, the outcomes of which are described by a measure of likelihood.

2.14. ‘Proving Ground or test-track’ is a physical testing facility closed to the traffic where the performance of a DCAS can be investigated on the real vehicle. Traffic agents can be introduced via sensor stimulation or via dummy devices positioned on the track.

2.15. ‘Sensor Stimulation’ is a technique whereby artificially generated signals are provided to the element under testing in order to trigger it to produce the result required for verification of the real world, training, maintenance, or for research and development.

2.16. ‘Simulation’ is the imitation of the operation of a real-world process or system over time.

2.17. ‘Simulation toolchain’ is a combination of simulation tools that are used to support the validation of a DCAS.

2.18. ‘Software-In-the-Loop’ (SIL) is where the implementation of the developed model will be evaluated on general- purpose computing systems. This step can use a complete software implementation very close to the final one.

SIL testing is used to describe a test methodology, where executable code such as algorithms (or even an entire controller strategy), is tested within a modelling environment that can help prove or test the software.

2.19. ‘Stochastic’ means a process involving or containing a random variable or variables. Pertaining to chance or probability.

2.20. ‘Validation of the simulation model’ is the process of determining the degree to which a simulation model is an accurate representation of the real world from the perspective of the intended uses of the tool.

2.21. ‘Vehicle -In-the-Loop’ (VIL) is a fusion environment of a real testing vehicle in the real-world and a virtual environment. It can reflect vehicle dynamics at the same level as the real-world and it can be operated on a vehicle test bed or on a test track.

2.22. ‘Verification of the simulation model’ is the process of determining the extent to which a simulation model or a virtual testing tool is compliant with its requirements and specifications as detailed in its conceptual models, mathematical models, or other constructs.

2.23. ‘Virtual testing’ is the process of testing a system using one or more simulation models.

3. Models and Simulation Management

3.1. The Models and Simulation (M&S) lifecycle is a dynamic process with frequent releases that should be monitored and documented. As a result, it is recommended that management activities should be established to support the M&S through typical product management processes. Relevant information on the following aspects should be included in this section.

3.2. It is recommended that this part should:

(a) Describe the modifications within the M&S toolchain releases;

(b) Designate the corresponding software (e.g., specific software product and version) and hardware arrangement e.g., X-In the Loop (XiL configuration);

(c) Record the internal review processes that accepted the new releases;

(d) Be supported throughout the full duration of the virtual testing utilization.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 73/80EN OJ L, 4.11.2024

3.3. Releases management

3.3.1. It is recommended that any toolchain’s version used to release data for certification purposes should be stored.

The virtual models constituting the testing tool should be documented in terms of the corresponding validation methods and acceptance thresholds to support the overall credibility of the toolchain. The developer should establish and enforce a method to trace generated data to the corresponding toolchain version.

3.3.2. Quality check of virtual data. Data completeness, accuracy, and consistency are ensured throughout the releases and lifetime of a tool or toolchain to support the verification and validation procedures.

3.4. Team’s Experience and Expertise

3.4.1. Even though Experience and Expertise (E&E) are already covered in a general sense within an organization, it is important to establish the basis for confidence on the specific experience and expertise for M&S activities.

3.4.2. In fact, the credibility of M&S depends not only on the quality of the simulation models but also on the E&E of the personnel involved in the validation and usage of the M&S. For instance, a proper understanding of the limitations and validation domain will prevent possible misuse of the M&S or misinterpretation of its results.

3.4.3. It is important to establish the basis for the manufacturer confidence in the experience and expertise of:

(a) The teams that will internally assess and validate the M&S toolchain; and

(b) The teams that will use the validated simulation for the execution of virtual testing with the purpose of validating the DCAS.

3.4.4. Thus, if a team’s E&E is good it increases the level of confidence and hence the credibility of M&S and its results by ensuring that the human elements underpinning the M&S activity are taken into consideration and risks from the human aspect of the activity can be controlled, through its Management System.

3.4.5. If the manufacturer toolchain incorporates or relies upon inputs from organizations or products outside of the manufacturer’s own team, it is recommended that the manufacturer includes an explanation of measures it has taken to manage and develop confidence in the quality and integrity of those inputs.

3.4.6. The team’s Experience and Expertise include two aspects:

3.4.6.1. Organizational level:

The credibility is established by setting up processes and procedures to identify and maintain the skills, knowledge, and experience to perform M&S activities. The following processes should be established,

maintained and documented:

(a) Process to identify and evaluate the individual’s competence and skills;

(b) Process for training personnel to be competent to perform M&S-related duties.

3.4.6.2. Team level:

Once a toolchain has been finalized, its credibility is mainly dictated by the skills and knowledge of the teams that will first validate the M&S and then use it for the validation of DCAS. The credibility is established by documenting that these teams have received adequate training to fulfil their duties.

The manufacturer should:

(a) Provide the basis for the manufacturer’s confidence in the Experience and Expertise of the individual/team that validates the M&S toolchain;

74/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

(b) Provide the basis for the manufacturer’s confidence in the Experience and Expertise of the individual/team that uses the simulation to execute virtual testing with the purpose of validating the DCAS.

3.4.6.3. The manufacturer should demonstrate of how it applies the principles of its Management Systems, e.g. ISO 9001 or a similar best practice or standard, with regard to the competence of its M&S organization and the individuals in that organization and the basis for this determination. It is recommended that the assessor not substitute its judgment for that of the manufacturer regarding the experience and expertise of the organization or its members.

3.4.7. Data/Input pedigree

3.4.7.1. The pedigree and traceability of the data and inputs used in the validation of the M&S is important. The manufacturer should have a record of these that allows the assessor to verify their quality and appropriateness.

3.4.7.2. Description of the data used for the M&S validation

(a) The manufacturer should document the data used to validate the models included in the tool or toolchain and note important quality characteristics;

(b) The manufacturer should provide documentation showing that the data used to validate the models covers the intended functionalities that the toolchain aims at virtualizing;

(c) The manufacturer should document the calibration procedures employed to fit the virtual models’ parameters to the collected input data.

3.4.7.3. Effect of the data quality (e.g. data coverage, signal to noise ratio, and sensors’ uncertainty/bias/sampling rate) on model parameters uncertainty The quality of the data used to develop the model will have an impact on model parameters’ estimation and calibration. Uncertainty in model parameters will be another important aspect in the final uncertainty analysis.

3.4.8. Data/Output pedigree

3.4.8.1. The pedigree of the output data is important. The manufacturer should keep a record of the outputs of the M&S toolchain and ensure that it is traceable to the inputs and the M&S toolchain that produced it. This will form part of the evidence trail for the DCAS validation.

3.4.8.2. Description of the data generated by the M&S

(a) The manufacturer should provide information on any data and scenarios used for virtual testing toolchain validation.

(b) The manufacturer should document the exported data and note important quality characteristics e.g. using the correlation methodologies.

(c) The manufacturer should trace M&S outputs to the corresponding M&S setup:

3.4.8.2.1. Effect of the data quality on M&S credibility

(a) The M&S output data should be sufficient to ensure the correct execution of the validation exercise. The data should sufficiently reflect the system boundaries relevant to the virtual assessment of the DCAS.

(b) The output data should allow consistency/sanity check of the virtual models, possibly by exploiting redundant information

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 75/80EN OJ L, 4.11.2024

3.4.8.2.2. Managing stochastic models

(a) Stochastic models should be characterized in terms of their variance.

(b) The use of a stochastic models should not prohibit the possibility of deterministic re-execution.

3.5. M&S Analysis and Description

3.5.1. The M&S analysis and description aim to define the whole toolchain and identify the parameter space that can be assessed via virtual testing. It defines the scope and limitations of the models and simulation tools and the uncertainty sources that can affect its results.

3.5.2. General description:

(a) The manufacturer should provide a description of the complete toolchain along with how the M&S data will be used to support the DCAS validation strategy;

(b) The manufacturer should provide a clear description of the test objective.

3.5.3. Assumptions, known limitations and uncertainty sources:

(a) The manufacturer should motivate the modelling assumptions which guided the design of the M&S toolchain;

(b) The manufacturer should provide evidence on:

(i) How the manufacturer-defined assumptions play a role in defining the limitations of the toolchain;

(ii) The level of fidelity required for the simulation models;

(c) The manufacturer should provide justification that the tolerance for M&S versus real-world correlation is acceptable for the test objective;

(d) Finally, this section should include information about the sources of uncertainty in the model. This will represent an important input to final uncertainty analysis, which will define how the M&S toolchain outputs can be affected by the different sources of uncertainty of the M&S toolchain used.

3.5.4. Scope (what is the model for?). It defines how the M&S is used in the DCAS validation.

(a) The credibility of virtual tool should be enforced by a clearly defined scope for the utilization of the developed M&S toolchains.

(b) The mature M&S should allow a virtualization of the physical phenomena to a degree of accuracy which matches the fidelity level required for certification. Thus, the M&S environment will act as a ‘virtual proving ground’ for DCAS testing.

(c) M&S toolchains need dedicated scenarios and metrics for validation. The scenario selection used for validation should be sufficient such that there is confidence that the toolchain will perform in the same manner in scenarios that were not included in the validation scope.

(d) The manufacturer should provide a list of validation scenarios together with the corresponding parameter description limitations.

(e) System boundary analysis is a crucial input to derive requirements, scope and the effects that the M&S toolchain must consider supporting DCAS validation.

(f) Parameters generated for the scenarios will define extrinsic and intrinsic data for the toolchain and the simulation models.

3.5.5. Criticality assessment 76/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

3.5.5.1. The simulation models and the simulation tools used in the overall toolchain should be investigated in terms of their impact in case of a safety error in the final product. The proposed approach for criticality analysis is derived from ISO 26262, which requires qualification for some of the tools used in the development process.

In order to derive how critical the simulated data is, the criticality assessment considers the following

parameters:

(a) The consequences on human safety e.g. severity classes in ISO 26262;

(b) The degree in which the M&S toolchain results influence’s the DCAS.

3.5.5.2. The table below provides an example criticality assessment matrix to demonstrate this analysis. The manufacturer may adjust this matrix to their particular use case.

Table A5/1 Criticality assessment matrix Influence on Significant N/A DCAS Moderate Minor Negligible N/A Negligible Minor Moderate Significant Decision consequence

3.5.5.3. From the perspective of the criticality assessment, the three possible cases for assessment are:

(a) Those models or tools that are clear candidates for following a full credibility assessment;

(b) Those models or tools that may or may not be candidates for following the full credibility assessment at the discretion of the assessor;

(c) Those models or tools that are not required to follow the credibility assessment.

3.6. Verification

3.6.1. The verification of M&S deals with the analysis of the correct implementation of the conceptual/mathematical models that create and build up the overall toolchain. Verification contributes to the M&S’s credibility via providing assurance that the individual tools will not exhibit unrealistic behaviour for a set of inputs which cannot be tested. The procedure is grounded in a multi-step approach described below, which includes code verification, calculation verification and sensitivity analysis.

3.6.2. Code verification

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 77/80EN OJ L, 4.11.2024

3.6.2.1. Code verification is concerned with the execution of testing that demonstrates that no numerical/logical flaws affect the virtual models.

(a) The manufacturer should document the execution of proper code verification techniques, e.g. static/ dynamic code verification, convergence analysis and comparison with exact solutions if applicable(1).

(b) The manufacturer should provide documentation showing that the exploration in the domain of the input parameters was sufficiently wide to identify parameter combinations for which the M&S tools show unstable or unrealistic behaviour. Coverage metrics of parameters combinations may be used to demonstrate the required exploration of the model’s behaviours.

(c) The manufacturer should adopt sanity/consistency checking procedures whenever data allows

3.6.3. Calculation verification

3.6.3.1. Calculation verification deals with the estimation of numerical errors affecting the M&S.

(a) The manufacturer should document numerical error estimates (e.g. discretization error, rounding error, iterative procedures convergence).

(b) The numerical errors should be kept sufficiently bounded to not affect validation.

3.6.4. Sensitivity analysis

3.6.4.1. Sensitivity analysis aims at quantifying how model output values are affected by changes in the model input values and thus identifying the parameters having the greatest impact on the simulation model results. The sensitivity study also provides the opportunity to determine the extent to which the simulation model satisfies the validation thresholds when it is subjected to small variations of the parameters, thus it plays a fundamental role to support the credibility of the simulation results.

(a) The manufacturer should provide supporting documentation demonstrating that the most critical parameters influencing the simulation output have been identified by means of sensitivity analysis techniques such as by perturbing the model’s parameters.

(b) The manufacturer should demonstrate that robust calibration procedures have been adopted and that this has identified and calibrated the most critical parameters leading to an increase in the credibility of the developed toolchain.

(c) Ultimately, the sensitivity analysis results will also help to define the inputs and parameters whose uncertainty characterization needs particular attention to characterize the uncertainty of the simulation results.

3.6.5. Validation

3.6.5.1. The quantitative process of determining the degree to which a model or a simulation is an accurate representation of the real world from the perspective of the intended uses of the M&S. It is recommended that

the following items be considered when assessing the validity of a model or simulation:

3.6.5.2. Measures of Performance (metrics)

(a) The Measures of Performance are metrics that are used to compare the DCAS’s performance within a virtual test with its performance in the real world. The Measures of Performance are defined during the M&S analysis.

(b) Metrics for validation may include:

(i) Discrete value analysis e.g. detection rate, firing rate;

(ii) Time evolution e.g. positions, speeds, acceleration;

(1) Roy, C. J. (2005). Review of code and solution verification procedures for computational simulation. Journal of Computational Physics, 205(1), 131-156.

78/80 ELI: http://data.europa.eu/eli/reg/2024/2689/ojEN OJ L, 4.11.2024

(iii) Analysis of state changes e.g. distance/speed calculations, TTC calculation, brake initiation.

3.6.5.3. Goodness of Fit measures

(a) The analytical frameworks used to compare real world and simulation metrics are generally derived as Key Performance Indicators (KPIs) indicating the statistical comparability between two sets of data.

(b) The validation should show that these KPIs are met.

3.6.5.4. Validation methodology

(a) The manufacturer should define the logical scenarios used for virtual testing toolchain validation. They should be able to cover, to the maximum possible extent, the system boundaries of virtual testing for DCAS validation.

(b) The exact methodology depends on the structure and purpose of the toolchain. The validation may consist

of one or more of the following:

(i) Validate subsystem models e.g. environment model (road network, weather conditions, road user interaction), sensor models (Radio Detection And Ranging (RADAR), Light Detection And Ranging

(LiDARs), Camera), vehicle model (steering, braking, powertrain);

(ii) Validate vehicle system (vehicle dynamics model together with the environment model);

(iii) Validate sensor system (sensor model together with the environment model);

(iv) Validate integrated system (sensor model + environment model with influences form vehicle model).

3.6.5.5. Accuracy requirement

3.6.5.5.1. Requirement for the correlation threshold is defined during the M&S analysis. The validation should show that these KPIs are met using the correlation methodologies.

3.6.5.6. Validation scope (what part of the toolchain to be validated)

3.6.5.6.1. A toolchain consists of multiple tools, and each tool will use several models. The validation scope includes all tools and their relevant models.

3.6.5.7. Internal validation results

(a) The documentation should not only provide evidence of the M&S validation but also should provide sufficient information related to the processes and products that demonstrate the overall credibility of the toolchain used.

(b) Documentation/results may be carried over from previous credibility assessments.

3.6.5.8. Independent Validation of Results

3.6.5.8.1. The assessor should audit the documentation provided by the manufacturer and may carry out tests of the complete integrated tool. If the output of the virtual tests does not sufficiently replicate the output of physical tests, the assessor may request that the virtual and/or physical tests to be repeated. The outcome of the tests will be reviewed and any deviation in the results should be reviewed with the manufacturer. Sufficient

explanation is required to justify why the test configuration caused deviation in results.

ELI: http://data.europa.eu/eli/reg/2024/2689/oj 79/80EN OJ L, 4.11.2024

3.6.5.9. Uncertainty characterisation

3.6.5.9.1. This section is concerned with characterizing the expected variability of the virtual toolchain results. The assessment should be made up of two phases. In a first phase the information collected from the ‘M&S Analysis and Description’ section and the ‘Data/Input Pedigree’ are used to characterise the uncertainty in the input data, in the model parameters and in the modelling structure. Then, by propagating all of the uncertainties through the virtual toolchain, the uncertainty of the model results is quantified. Depending on the uncertainty of the model results, proper safety margins will need to be introduced by the DCAS manufacturer in the use of virtual testing as part of the DCAS validation.

3.6.5.9.2. Characterization of the uncertainty in the input data The DCAS manufacturer should demonstrate they have estimated the model’s critical inputs by means of robust techniques such as providing multiple repetitions for their assessment.

3.6.5.9.3. Characterization of the uncertainty in the model parameters (following calibration).

The manufacturer should demonstrate that when a model’s critical parameters cannot be fully determined they are characterized by means of a distribution and/or confidence intervals.

3.6.5.9.4. Characterization of the uncertainty in the M&S structure The manufacturer should provide evidence that the modelling assumptions are given a quantitative characterization by assessing the generated uncertainty (e.g. comparing the output of different modelling approaches whenever possible).

3.6.5.9.5. Characterization of aleatory vs. epistemic uncertainty The manufacturer should aim to distinguish between the aleatory component of the uncertainty (which can only be estimated but not reduced) and the epistemic uncertainty deriving from the lack of knowledge in the virtualization of the process.

4. Documentation structure

4.1. This section will define how the aforementioned information will be collected and organized in the documentation provided by the manufacturer to the relevant authority.

(a) The manufacturer should produce a document (a ‘simulation handbook’) structured using this outline to provide evidence for the topics presented;

(b) The documentation should be delivered together with the corresponding release of the toolchain and appropriate supporting data;

(c) The manufacturer should provide clear reference that allows tracing the documentation to the corresponding parts of the toolchain and the data;

(d) The documentation should be maintained throughout the whole lifecycle of the toolchain utilization. The assessor may audit the manufacturer through assessment of their documentation and/or by conducting physical tests.

80/80 ELI: http://data.europa.eu/eli/reg/2024/2689/oj