R171法规对L2+级自动驾驶(DCAS)的要求

1.背景

在2024年3月5日至3月8日，联合国世界车辆法规协调论坛（UN WP.29）第192次全体会议在瑞士日内瓦召开，会议审议通过了关于驾驶员控制辅助系统（DCAS）的新法规建议案。这一法规的出台旨在规范L2+级自动驾驶中的DCAS，包括高速NOA（Navigate On Autopilot）和城市NOA。DCAS作为先进驾驶员辅助系统（ADAS）的一个子集，通过持续的横向和纵向运动控制来帮助驾驶员执行车辆动态控制。尽管DCAS能够提供显著的辅助功能，但其责任始终在驾驶员手中，驾驶员需要持续监控驾驶环境和车辆及ADAS系统性能。这一法规的制定填补了现有监管空白，确保DCAS在市场推广中的安全性和可靠性。

2.范围和定义

2.1 范围

本法规适用于M类和N2类车辆的驾驶员控制辅助系统（DCAS）的型式认证。M类车辆指主要用于载运乘客及其行李的车辆，N2类车辆指主要用于载运货物且最大设计总质量不超过3.5吨的车辆。本法规不适用于已取得R79认证的ACSF（自动紧急制动系统）和RMF（风险缓解功能）。如果主机厂宣称ACSF或RMF是DCAS的一部分，则本法规适用，无论其是否已被R79批准。

DCAS系统的整体架构，包括车辆动态控制和驾驶员辅助两个主要部分。车辆动态控制进一步分为纵向控制和横向控制，驾驶员辅助包括警告系统和信息提供。

2.2 定义

驾驶员控制辅助系统（DCAS）：指能够帮助驾驶员持续控制车辆纵向和横向运动的硬件和软件。DCAS在激活时为驾驶任务提供支持，并通过主动操纵车辆来增加舒适性和减少驾驶员的工作量。

车辆类型：指在DCAS的系统特点及设计、显著影响DCAS性能的车辆特征等方面没有区别的车辆。

功能：指在定义的交通场景、环境和系统边界内为驾驶员提供帮助的特定DCAS能力。

动态控制：指实时执行移动车辆所需的操作和功能，包括控制车辆的横向和纵向运动、监测道路环境、响应道路交通环境中的事件以及为机动进行规划和信号。

系统边界：指制造商制定的可验证、可测量的限制或条件，以及影响系统按预期运行能力的条件。

驾驶员脱离：指DCAS系统判断驾驶员当前无法安全执行感知、规划、决策以及干预DCAS操作。

操作功能：指驾驶员移动车辆和操作其系统所需和采取的基本控制动作，包括对车辆横向和纵向运动的控制。

战术功能：指驾驶员对机动的实时规划和确定。

实时：指过程或事件发生的实际时间。

机动：指车辆轨迹的变化，导致车辆至少部分离开其原始车道或行驶方向，从而可能导致与其他道路使用者的互动。

目标车道：指系统打算通过执行机动将车辆转移到的车道。

变道程序（LCP）：指执行车辆变道的操作序列。

变道机动（LCM）：指LCP的一部分，涉及车辆从一个车道移动到另一个车道的过程。

关闭模式：指DCAS运行状态，当系统被阻止协助驾驶员执行车辆的动态控制时的状态。

开启模式：指DCAS运行状态，当系统或DCAS功能被请求为驾驶员执行车辆动态控制提供帮助时的状态。

激活模式：指DCAS运行状态，当DCAS系统或DCAS功能认为自己在其系统边界内并为驾驶员执行车辆的动态控制提供帮助时的状态。

待机模式：指DCAS运行状态，DCAS系统或DCAS功能处于“开启”模式，但不产生控制输出。

抑制模式：指DCAS运行状态，当DCAS系统或DCAS功能处于“待机”模式并认为自己在其系统边界内，没有任何先决条件阻止切换到“激活”模式时。

非激活模式：指DCAS运行状态，当DCAS系统或DCAS功能处于“待机”模式并认为自己在其边界条件之外或任何先决条件（如驾驶员脱离、车辆故障）是防止切换到“激活”模式时。

紧急碰撞风险：描述了一种情况或事件，即低于5m/s²的减速度不能避免车辆与另一个道路使用者或障碍物发生碰撞。

检测范围：指系统能够可靠识别物体的距离，并产生控制信号，需充分考虑感知系统组件的性能在车辆整个生命周期内由于时间和使用而恶化。

系统/功能设计速度范围：指考虑到相关的交通和环境条件，DCAS系统或其功能可以根据系统设计和能力处于“激活”模式的自适应速度范围。

驾驶员设定的最大速度：指驾驶员设定的DCAS运行的最大速度。

当前最高速度：指系统将控制车辆的最大速度。

R171软件识别号（RXSWIN）：指由车辆制造商定义的专用标识符，代表电子控制系统（DCAS）的型式认证相关软件的信息。

电子控制系统：指旨在通过电子数据处理，产生所述车辆控制功能的单元组合。

事件：在第7章的规定中，涉及DCAS车辆的与安全有关的行动、事件或即将发生的事件。

安全-关键事件：指在碰撞事件发生时，DCAS或其相应功能处于“开启”模式时发生的事件。

可控性：指在危险情况发生时可以避免伤害的概率。

驾驶员超控：指驾驶员通过应用制动、变速器、油门或转向控制来暂时干预DCAS提供的辅助的任何行动。

高速公路：指一种禁止行人和骑自行车的道路，其设计配备了物理隔离，将相反方向的交通分开。

非高速公路：指上文定义的高速公路以外的道路类型。

自动驾驶系统（ADS）：指能够持续执行整个动态驾驶任务（DDT）的车辆硬件和软件。

动态驾驶任务（DDT）：指在道路交通中操作车辆所需的实时操作和战术功能。

3.申请

车辆制造商或制造商授权代表应向缔约方的型式批准机构提交与DCAS有关的车辆型式批准申请。型式批准申请应附有以下留档：

• 关于DCAS的车辆类型的描述，以及本法规中要求的留档包，该包可以访问DCAS的基本设计、DCAS与其他车辆系统连接的方式，以及DCAS直接控制输出变量的方式。

代表待批准车辆类型的车辆应提交给型式批准机构或其指定的负责进行批准测试的技术服务部门（送测）。

下图为申请的流程，从提交申请到型式批准机构，经过技术评估和车辆测试，最终决定是否批准。

4.批准

根据UN法规提交审批的车辆类型符合下文第5至10段的要求，则应批准该车辆类型。应为每种批准的类型分配一个批准编号。其前两位数字（UN法规的原始形式为00）应表示包含批准发布时对UN法规所做技术修改的一系列修改。同一缔约方不得为另一种类型的车辆分配相同的编号。

应通过符合本联合国法规中格式的表格以及申请人提供的格式不超过A4（210×297mm）、适当比例尺或电子格式的文件，向使用本联合国法规的协议缔约方传达包括批准、扩项、拒绝、撤销认证或最终停产车型在内的信息。

每辆符合根据本UN法规获批准的车辆类型的车辆，须显眼地并在批准表格上指明的易于到达的地方，贴上符合所述型号的国际批准标记，该标记包括：

• 围绕字母“E”的圆圈，后跟：
  • 已批准的国家的编号；
  • 本法规的编号，后跟字母“R”、破折号和本段规定圆圈右侧的批准编号。

或

• 围绕字母“UI”的椭圆形，后跟唯一标识符。

批准标志应清晰易读且不可磨灭。在型式批准之前，型式批准机构应核实制造商是否存在令人满意的安排，以确保对车辆生产的符合性进行有效检查。

下图为批准的流程，从提交申请到型式批准机构，经过技术评估和车辆测试，最终决定是否批准，并将结果传达给相关方。

5.一般要求

5.1 一般要求

下图为系统设计的要求，包括确保驾驶员持续参与、提高安全驾驶意识、防止滥用、提供安全超控手段和配备安全系统。

作为评估（11.系统安全要求）的一部分并根据（12.物理测试要求）中的相关测试，制造商应在安全方法检查期间向批准机构证明本段规定的履行情况。

5.1.1 系统设计：系统的设计应确保驾驶员按照第5.5.4.2段继续从事驾驶任务。

5.1.2 安全驾驶意识：制造商应实施策略以确保驾驶员安全驾驶意识并避免驾驶员过度依赖DCAS系统。这应通过履行第5.5.4段的规定来证明。

5.1.3 防止滥用：制造商应采取有效措施，防止驾驶员合理可预见的滥用和未经授权修改系统的软硬件组件。

5.1.4 安全超控：系统应按照第5.5.3.4段的规定，随时为驾驶员提供安全超控或停用DCAS系统的手段。

5.1.5 配备安全系统：配备DCAS的车辆至少应配备先进的紧急制动系统（AEB）。此外，它还应配备车道偏离预防系统（CSF）或车道偏离警告系统（LDW）。这些系统应符合R131、R152、R79（纠正转向功能）和R130号法规的技术要求和过渡规定，视配备DCAS的车辆类型而定。

5.2 DCAS与其他车辆辅助系统的交互

下图为DCAS系统与其他辅助系统的交互，包括纵向紧急辅助系统、横向紧急辅助系统和其他辅助系统。

5.2.1 紧急辅助系统：当DCAS系统处于“激活”模式时，其操作不得停用或抑制已激活的纵向紧急辅助系统（即AEBS）的功能。对于横向紧急辅助功能，DCAS系统可以根据涵盖此功能的相应法规停用或抑制紧急辅助系统。

5.2.2 系统转换：DCAS与其他辅助系统或自动化系统之间的转换、系统之间的优先顺序以及任何旨在确保车辆安全和正常运行的其他辅助系统的抑制或停用，应在提交给型式认证机构的留档中详细描述。

5.3 功能要求

下图为功能要求的各个方面，包括系统检测能力、环境响应、系统激活、控制策略、系统边界响应和可控性。

5.3.1 系统检测能力：制造商应在留档中详细描述与单个特征相关的系统检测能力，特别是中列出的系统边界。

5.3.2 环境响应：DCAS系统应能够根据实现系统预期功能的要求，在系统边界内并在超出系统边界的情况下尽可能评估和响应其周围环境。

  5.3.2.1 交通适应：DCAS系统应以适当的方式调整其行为以适应周围交通，以避免对交通流的干扰。

  5.3.2.2 碰撞避免：如果DCAS系统检测到碰撞风险，则应旨在避免或减轻碰撞的严重程度。

  5.3.2.3 保持距离：在不损害本UN法规其他规定的原则下，DCAS系统须控制车辆的纵向及横向运动，以维持与其他道路使用者的适当距离。

5.3.3 系统激活：DCAS系统可根据系统的操作设计在必要时激活相关车辆系统（例如，方向指示器、雨天激活刮水器、加热系统等）。

5.3.4 控制策略：考虑到驾驶员的反应时间，系统的控制策略应设计成在保持可控（如第5.3.6段所述）的同时降低碰撞风险。

5.3.5 系统边界响应

  5.3.5.1 边界检测：当DCAS或DCAS功能处于“开启”模式时，系统应旨在检测适用的系统边界。如果系统识别到超出系统或功能边界，它应转换到“待机”模式，并根据第5.3.5.2段中制造商描述的策略立即通知驾驶员。

  5.3.5.2 边界条件描述：制造商应详细描述DCAS系统及其功能的系统边界条件，以及在检测到边界条件被超过、满足或接近时通知驾驶员的策略。

  5.3.5.3 边界检测方法：制造商应识别系统能够检测到的系统边界，并应描述系统能够识别系统边界的方法。

  5.3.5.4 无法检测的边界：应记录系统无法检测到的任何声明的系统边界，并应证明无法检测不会影响系统或其功能的安全运行。

  5.3.5.5 驾驶员通知：当DCAS系统识别到处于“激活模式”的某功能正接近其系统边界时，应在适当的前置时间内通知驾驶员。

5.3.6 可控性

  5.3.6.1 控制动作：DCAS系统应设计为确保系统的控制动作，包括但不限于系统故障、达到系统边界或系统切换到“关闭”模式时的控制动作，对驾驶员保持可控。

  5.3.6.2 策略实施：为确保可控性，DCAS系统应在定义的系统边界内实施与系统能力相关的策略。

  5.3.6.3 减速和加速：当由系统控制时，车辆减速和加速应保持对驾驶员和周围交通的可管理性，除非需要增加减速水平以确保车辆或周围道路使用者的安全。

5.4 检测到故障时系统的安全响应

下图为故障响应的流程，包括故障检测、故障类型判断、整体故障和部分故障的处理方式。

5.4.1 故障检测：激活的DCAS系统应能够检测和响应影响系统或其功能安全运行的电气和非电气（例如，传感器遮挡、错位）故障。

5.4.2 故障响应：在检测到影响特定功能或整个系统的安全运行的故障时，应根据制造商的安全概念以安全方式终止受影响功能或整个系统的控制辅助。

  5.4.2.1 整体故障：如果故障影响整个DCAS系统，系统应在辅助终止时切换到“关闭”模式，并在适当的时间内向驾驶员提供至少一个光学故障警告信号。

  5.4.2.2 故障指示：除非DCAS系统处于“关闭”模式，否则影响系统的故障应至少用光信号向驾驶员指示。

  5.4.2.3 可控性：制造商应采取适当措施，以确保故障模式下DCAS系统对驾驶员而言仍是可控的。

5.4.4 功能受限：如果故障仅影响某些功能，则允许系统继续运行，前提是其余功能能够按照本法规运行。

  5.4.4.1 功能指示：应以易于理解的方式向驾驶员直观地指示由于故障而导致的剩余可用功能或缺失的功能。

  5.4.4.2 功能独立性：制造商应描述哪些功能能够相互独立运行，并根据进行评估。

5.5 人机交互界面（HMI）

5.5.1 操作方法：根据本法规定义的DCAS操作模式示意图。

5.5.2 一般要求

  5.5.2.1 模式切换：当系统切换到“开启”模式时，特定系统功能应处于“激活”模式或“待机”模式，而某些其他系统功能可能仍处于“关闭”模式。

  5.5.2.2 关闭模式：当驾驶员将DCAS系统切换到“关闭”模式时，DCAS不得自动转换到提供车辆连续纵向（ACC）或连续横向（LKA）控制的任何系统。

  5.5.2.3 独立控制：当DCAS系统处于“激活”模式时，除DCAS外，任何其他系统不得提供持续的纵向和横向控制辅助，除非根据段落5.2的规定认为需要紧急安全系统的干预。

  5.5.2.4 模式区分：HMI的设计应不会导致DCAS模式与车辆上配备的其他系统混淆。

5.5.3 激活、停用和驾驶员超控

  5.5.3.1 默认模式：在每次新发动机启动（或运行周期，视情况而定）开始时，DCAS系统应处于“关闭”模式。

  5.5.3.2 激活：只有在驾驶员有意识地采取行动时，系统才应将其模式从“关”变为“开”。

  5.5.3.3 停用：驾驶员应可随时将DCAS系统切换到“关闭”模式。

  5.5.3.4 驾驶员超控：DCAS系统可以保持在“激活”模式，前提是在超控期间优先响应驾驶员输入。

5.5.4 驾驶员信息、驾驶员脱离和警告策略

  5.5.4.1 驾驶员信息：DCAS系统应通知或警告驾驶员以下情况：

    系统或功能的状态；

    正在进行的机动；

    驾驶员需要执行的特定操作；

    系统边界状态；

    故障检测；

    需要驾驶员确认或系统自动启动的变动机动。

  5.5.4.2 驾驶员脱离监控：DCAS系统应监测驾驶员是否处于脱手状态和脱眼状态。

  5.5.4.3 警告类型：包括握方向盘请求（HOR）、注视请求（EOR）和直接控制警报（DCA）。

  5.5.4.4 警告升级序列：根据系统的安全概念，警告升级序列可以跳过任何警告阶段，直接从任何警告阶段开始。

下图为HMI设计的要求，包括模式切换、关闭模式、独立控制、模式区分、激活、停用和驾驶员超控。

5.6 驾驶员信息材料

制造商应提供DCAS系统操作的清晰易懂的信息，包括但不限于以下方面：

• 驾驶员的职责和系统的适当使用；
• DCAS系统及其功能如何以及在多大程度上帮助驾驶员；
• DCAS系统的能力和限制；
• DCAS系统的边界；
• DCAS系统的操作模式和模式之间的转换；
• 驾驶员脱离检测；
• 使用DCAS系统时的隐私管理；
• 如何超控DCAS系统或其功能的说明；
• 人机交互界面（HMI）的详细说明。

下图为驾驶员信息材料的内容，包括驾驶员职责、系统功能、系统能力、系统边界、操作模式、驾驶员脱离检测、隐私管理和超控说明。

6.DCAS功能的附加要求

6.1 行驶车道内位置的具体要求

增加横向加速度：对于M1和N1类车辆，允许产生高于3m/s²的横向加速度值，但需满足特定条件。

高速公路上的车道合流和分流：DCAS系统应旨在检测当前行车道与另一条行车道（包括匝道）合并的情况，并应设计为确保在考虑到相邻车道的道路使用者的情况下进行安全控制。

离开车道，为紧急和执法车辆让路：DCAS系统应仅离开其当前行车道，以（预防性地）在根据国家交通规则需要和允许的情况下形成应急通道。

无车道标线道路上的车道定位：如果DCAS系统设计用于可以在没有车道标线的道路上执行车道定位，则应利用其他信息源（如高精定位＋高精地图、SLAM、路沿检测、可行驶区域检测等），以便可靠地确定和追踪其他道路使用者的适当轨迹。

下图为车道内位置的附加要求，包括增加横向加速度、车道合流和分流、为紧急车辆让路和无车道标线道路定位。

6.2 换道的具体要求

信息充分性：只有当系统对其前方、侧面和后方的周围环境有足够的信息以评估变道的危险程度时，才应进行变道。

禁止对向车道变道：不得向对向车道进行变道。

横向加速度限制：在变道操纵期间，DCAS系统的设计应避免变道产生的横向加速度超过1.5m/s²，并避免总横向加速度超过3.5m/s²。

目标车道车辆：只有当目标车道上的车辆没有因DCAS车辆变道而被迫无法控制地减速时，才应开始变道机动。

系统设计：制造商应向型式认证机构说明第6.2.4段的规定是如何在系统设计中实施的。

方向指示器信号：DCAS系统应生成信号以启动和停用方向指示器（转向灯）。

换道指示：车道变更程序LDP应在车道变更操作开始前至少向其他道路使用者指示3秒钟。

故障通知：当变道程序被DCAS系统抑制时，系统应通过光信号与声学或触觉信号相结合的方式清楚地通知驾驶员。

换道的额外要求：包括驾驶员确认变道的额外要求和系统发起的车道变更的额外需求。

下图为换道的具体要求，包括信息充分性、禁止对向车道变道、横向加速度限制、目标车道车辆、系统设计、方向指示器信号、换道指示、故障通知和额外要求。

6.3 除变道以外的其他机动的附加要求

适用范围：本段规定适用于将车辆引向以下方向的机动。

环境响应：DCAS系统应设计成对已经在或可能进入计划轨迹或相应驾驶环境的车辆、道路使用者、基础设施或前方拥堵路径做出响应，以确保安全运行。

交通信号：DCAS系统应设计为响应交通信号灯、停车标志、通行权基础设施（如斑马线或公交车站）和DCAS系统禁用车道。

山峰巡航：DCAS系统应设计成在被认为与给定机动的可控性相关的山峰上安全、谨慎地巡航。

弱势道路使用者：如果机动可能导致DCAS系统与穿越行车道（例如自行车道、人行横道）的弱势道路使用者相交，则系统应设计为适当地响应道路使用者和基础设施。

交叉路径：如果机动将导致DCAS系统横穿交叉路径（例如，转弯时）或导致系统与从不同方向接近的交通合并（Y型路），则系统应设计为适当地响应这些道路使用者。

通行权规则：DCAS系统应旨在尊重适当的通行权规则。

绕过障碍物：DCAS系统应设计成在被认为与给定机动的可控性相关的山峰上安全、谨慎地巡航。

下图为其他机动的附加要求，包括适用范围、环境响应、交通信号、山峰巡航、弱势道路使用者、交叉路径、通行权规则和绕过障碍物。

7.DCAS运行监控

7.1 DCAS运行监控

制造商应建立一个全面的监控系统，以收集和分析与DCAS系统安全运行相关的关键事件数据。该系统应能够实时监测车辆的运行状态、系统性能以及驾驶员的行为，确保在各种工况下系统的安全性和可靠性。监控系统应包括但不限于以下方面：

车辆状态监测：实时监测车辆的速度、加速度、转向角度、制动压力等关键参数，确保车辆在DCAS系统的控制下保持稳定运行。

系统性能监测：监测DCAS系统的各项功能性能，包括车道保持、自适应巡航、变道辅助等，确保系统在不同工况下均能正常工作。

驾驶员行为监测：通过驾驶员监控系统（DMS）监测驾驶员的注意力、疲劳程度、操作行为等，确保驾驶员在系统运行过程中保持适当的参与度和警觉性。

监控系统应具备数据存储和分析功能，能够对收集到的数据进行深入分析，以识别潜在的安全风险和系统故障。制造商应定期对监控系统进行评估和优化，确保其能够有效支持DCAS系统的安全运行。

下图为DCAS运行监控系统的架构，包括车辆状态监测、系统性能监测、驾驶员行为监测、数据收集与传输、数据存储与分析、安全风险识别与预警和系统优化与改进。

7.2 DCAS运行报告

制造商需建立一套完善的运行报告机制，以便在发生安全关键事件时能够及时通知型式认证机构，并提供详细的事件报告。报告机制应包括以下几个方面：

初始通知：当发生安全关键事件时，制造商应在最短时间内向型式认证机构发出初始通知，报告事件的基本情况，包括事件发生的时间、地点、涉及的车辆信息等。

短期报告：在初始通知后，制造商应尽快进行事件调查，并向型式认证机构提交短期报告，详细说明事件的经过、可能的原因以及制造商拟采取的补救措施。

定期报告：制造商应至少每年向型式认证机构提交一次定期报告，总结DCAS系统的运行情况，包括系统性能数据、安全事件统计、改进措施等。

通过建立完善的运行报告机制，制造商能够及时掌握DCAS系统的运行状况，及时发现和解决潜在问题，确保系统的安全性和可靠性。

下图为运行报告的流程，包括初始通知、短期报告、定期报告、事件调查和补救措施。

8.系统验证

8.1 系统验证

系统验证是确保DCAS系统满足法规要求和安全标准的关键环节。制造商应建立一套全面的验证流程，涵盖系统的各个方面，包括功能验证、性能测试、安全评估等。验证流程应包括以下几个主要阶段：

功能验证：验证DCAS系统的各项功能是否正常工作，包括车道保持、自适应巡航、变道辅助、紧急制动等。功能验证应覆盖系统的所有工作模式和工况，确保系统在各种情况下均能正常运行。

性能测试：评估DCAS系统的性能指标，如响应时间、控制精度、稳定性等。性能测试应采用标准化的测试方法和工具，确保测试结果的准确性和可重复性。

安全评估：评估DCAS系统的安全性，包括系统的故障模式、风险等级、安全机制等。安全评估应基于国际公认的安全标准，如ISO 26262，确保系统满足最高的安全要求。

下图为系统验证的流程，包括功能验证、性能测试、安全评估、验证结果分析和系统优化。

8.2 验证方法

系统验证应采用多种方法相结合，以确保验证结果的全面性和可靠性。主要验证方法包括：

物理测试：在实际车辆上进行测试，验证系统在真实工况下的性能和安全性。物理测试应在专门的测试场地和公共道路上进行，以覆盖各种可能的使用场景。

仿真测试：利用仿真工具和模型进行测试，验证系统在虚拟环境下的性能和安全性。仿真测试可以模拟各种复杂的工况和场景，为系统验证提供重要的补充。

数据分析：对系统运行数据进行分析，评估系统的性能和安全性。数据分析可以揭示系统在实际运行中的表现，为系统优化提供依据。

验证方法的示意图，包括物理测试、仿真测试和数据分析。

8.3 验证流程

系统验证流程应包括以下几个主要步骤：

1. 验证计划制定：制定详细的验证计划，明确验证的目标、范围、方法、时间表等。
2. 验证准备：准备验证所需的资源，包括测试车辆、测试设备、测试场地、测试人员等。
3. 验证执行：按照验证计划进行测试和评估，记录测试结果和发现的问题。
4. 验证报告编写：编写验证报告，总结验证结果，提出改进建议。
5. 验证结果评审：组织专家对验证结果进行评审，确保验证结果的准确性和可靠性。

下图为验证流程，包括验证计划制定、验证准备、验证执行、验证报告编写、验证结果评审和系统优化。

9.系统信息数据

在型式认证时，制造商应将下列数据连同本法规中要求的留档包装一起提供给型式批准机构。这些数据包括：

• DCAS系统具有下表中的功能时，制造商应使用“x”或“不适用”来确认DCAS功能可以在哪个领域运行，并根据需要填写表格。
• DCAS系统及其功能可以被激活的条件和操作的边界（边界条件）。
• DCAS与其他车辆系统的交互（所有输入输出及连接方式）。
• DCAS系统激活、停用和超控的方法。
• 驾驶员监控方式和判断监控驾驶员脱离的方法。
• DCAS系统的每个功能提供的动态控制辅助。
• DCAS系统使用除车道标记以外的其他输入来可靠地确定行驶路线，并在没有完全标记的车道行驶时继续提供横向控制辅助。

下图为系统信息数据的内容，包括功能确认、激活条件、系统交互、激活/停用方法、驾驶员监控、动态控制辅助和其他输入

10.软件识别要求

10.1 软件识别

为确保DCAS系统软件可被识别，车辆制造商应实施R171SWIN。R171SWIN应保存在车辆上，或者，如果R171SWIN未保存在车辆上，制造商应向型式认证机构声明车辆或单个ECU的软件版本以及与相关型式认证的连接。

软件识别流程图，包括R171SWIN和软件版本声明。

10.2 软件更新

车辆制造商应通过满足UN ECE R156法规原始版本或后来的一系列修订版的要求，来证明符合R156法规（软件更新和软件更新管理系统）。

10.3 通信文档

车辆制造商应在本UN法规的通信文档中提供以下信息：

• R171SWIN；
• 如果车辆上没有R171SWIN，如何阅读R171SWIN或软件版本。

10.4 参数列表

车辆制造商可以在本法规的通信文档中提供相关参数列表，通过该列表可以识别R171SWIN代表的可以进行更新的软件。所提供的信息应由车辆制造商声明，可以不由型式认证机构验证。

10.5 软件版本更新

因为硬件更改或法规更新，主机厂可能会更新系统的软件版本，导致新车与市场上已注册上牌的车的软件版本不一致。在与测试机构达成协议的情况下，应尽可能避免重复测试。

11.系统安全要求

11.1 适用于审计/评估的特殊要求

11.1.1 一般要求

本章节界定电子系统和复杂电子控制系统的安全方面的留档、设计安全和验证的特殊要求。本章节未规定“系统”的性能标准，但涵盖了应用于设计过程的方法论以及为型式批准目的必须向型式批准机构或代表其行事的技术服务（以下简称型式批准机构）披露的信息。

11.1.2 定义

系统：指能够帮助驾驶员持续控制车辆纵向和横向运动的硬件和软件。

安全概念：指对DCAS系统中设计的措施的描述，例如在电子单元内，以解决系统完整性问题，从而确保在故障（功能安全）和非故障条件（操作安全）下的安全运行。

电子控制系统：指一组单元的组合，旨在通过电子数据处理合作生产所述车辆控制功能。

复杂电子控制系统：指由电子系统控制的功能可能被更高级别的电子控制系统/功能超控的电子控制系统。

高级电子控制：指采用额外的处理和/或传感装置，通过命令车辆控制系统功能的变化来改变车辆行为的系统。

单元：本章节将审议的系统组成部分的最小分类，为了识别、分析或更换的目的，这些组成部分的组合将被视为单一实体。

传输链路：用于连接分布式单元以传输信号、操作数据或能量供应的手段。

控制范围：指输出变量，并定义了系统可能行使控制的范围。

功能操作的边界：定义了系统设计用于维持控制的可验证或可测量限制的边界。

安全相关功能：指能够改变车辆动态行为的“系统”功能。

控制策略：指响应一组特定的环境或操作条件（例如道路表面条件、交通强度和其他道路使用者、恶劣天气条件等）确保系统功能稳健和安全运行的策略。

故障：指可能导致故障的异常情况。这可能涉及硬件或软件。

失效：指由于故障表现而终止系统的功能或系统的预期行为。

不合理风险：指车辆乘员和其他道路使用者的总体风险水平，与系统边界内的老司机（成熟谨慎驾驶员）驾驶车辆相比，风险水平有所增加。

高速公路：指禁止行人和骑自行车的道路，根据设计，该道路配备了物理隔离，将相反方向的交通分开。

非高速公路：指上述定义的高速公路以外的道路。

下图为系统安全要求与其他概念的详细关系，包括审计/评估、安全概念、电子控制系统、复杂电子控制系统、高级电子控制、单元、传输链路、控制范围、功能操作边界、安全相关功能、控制策略、故障、失效、不合理风险、高速公路和非高速公路。

11.1.3 文档

文档要求：制造商应提供一个留档包，以便访问DCAS系统的基本设计以及与其他车辆系统连接或直接控制输出变量的方法。

系统功能说明：应对系统的所有功能（包括控制策略）提供描述，并对为实现目标而采用的方法进行简单解释。

系统布局和原理图：应提供一份清单，整理系统的所有单元，并提及实现相关控制功能所需的其他车辆系统。

制造商的安全理念：制造商应提供一份声明，确认为实现系统目标而选择的策略在非故障条件下不会损害车辆的安全运行。

安全管理体系（过程审计）：制造商应向型式认证机构证明，在安全管理体系方面，有效的流程、方法和工具是最新的，且已经到位，并在组织内得到遵循，以管理整个产品生命周期（设计、开发、生产和运营）的安全性和持续合规性。

11.1.4 验证和测试

系统功能验证：型式认证机构应在非故障条件下通过测试制造商在上文第11.1.3.2段中声明的若干选定功能来验证系统。

安全概念验证：在任何单个单元的故障（模拟电气故障或非电气故障）影响下检查系统的反应。

仿真工具评估：型式认证机构应评估制造商提供的声明结果，特别是与安全指标和系统边界覆盖范围有关的结果。

HMI功能测试：型式认证机构应检查一些对系统HMI功能的表征至关重要的场景，并验证驾驶员脱离监测和警告系统的有效性能。

系统边界测试：型式认证机构还应检查法规中定义的对驾驶员控制系统边界至关重要的一些场景。

11.1.5 型式批准机构的报告

型式批准机构的评估报告应以允许可追溯性的方式执行，例如检查的文件版本已编码并列在评估记录中。

11.2 审计/评估期间要评估的系统设计

制造商应提供以下信息供型式认可机构评估：

与DCAS相关的一般信息：包括驾驶员交互和HMI、驾驶员脱离检测和重新参与支持的附加策略、为防止驾驶员合理预见的滥用和篡改系统而采取的措施等。

系统动态控制相关信息：如车道保持时，系统确定适当速度和由此产生的横向加速度的策略。

与DCAS功能相关的信息：如系统产生较高的横向加速度值且不再满足条件时，确保可控性的策略。

11.3 系统检测能力和相关系统边界的示例性分类

制造商应解释DCAS的检测能力（如适用，按功能区分）以及这些检测能力的系统边界。以下列表应作为不同操作场景下可能相关的对象和事件的指导：

• 道路：类型（高速公路、乡村道路等）、表面（类型、附着力）、几何形状、车道特征、车道标记的可用性、道路边缘、道路交叉口；
• 道路设施（交通管制设施、特殊设施（道路施工标线）、其他设施）；
• 道路事件（例如道路事故、交通拥堵、道路工程）；
• 环境条件，例如：恶劣天气，雾和薄雾；温度；降水；时间和光线条件；
• 其他道路使用者（例如机动车辆、摩托车、自行车、行人）。

11.4 系统能力声明

制造商应根据以下标准，根据第6段的分类声明系统的能力及其特性。应参考此声明进行基础测试。

系统响应其他道路使用者的能力：制造商应声明系统能够处理（即在没有驾驶员干预的情况下避免碰撞）以下与系统设计相关的情况的最大运行速度。

DCAS系统车道保持能力：参考B1-ACSF的申报值。

系统可能识别的与给定声明的系统边界和系统设计相关的道路事件：由制造商完成并扩展，或者表示为“不适用”。

系统在协助变道时确保安全操作的能力：如果DCAS系统配备了变道功能，制造商应声明系统能够感知目标的最大范围。

DCAS系统在非高速公路环境中安全执行驾驶员或系统启动的无需驾驶员干预的变道机动操作的能力：或者表示为“不适用”。

系统按照与特定驾驶员启动的机动相关的交通规则运行的能力：制造商应声明与特定操作相关的交通规则合规性。

系统按照交通流启动相关机动的能力：制造商应声明与特定操作相关的交通规则合规性。

12.物理测试要求

12.1 导言

本附件定义了物理测试，目的是验证适用于系统的技术要求和制造商根据第11.4章节所作的声明。本附件中的所有测试应在批准过程中由型式批准机构或代表其行事的技术服务（以下简称“型式批准机构”）执行或见证。

12.2 定义

碰撞时间（TTC）：指通过将VUT和目标之间的纵向距离（在VUT的行进方向上）除以VUT和目标的纵向相对速度而获得的时间。

偏移（Offset）：指测试车辆和相应目标的纵向中间平面在行驶方向上的距离。

行人目标（Pedestrian Target）：指代表行人的目标。

乘用车目标（Passenger Car Target）：指代表乘用车（M1类）车辆的目标。

动力两轮车目标（Powered Two-Wheeler Target）：指代表摩托车和摩托骑行者组合的目标。

自行车目标（Bicycle Target）：指代表自行车和自行车骑行者组合的目标。

被测车辆（Vehicle Under Test, VUT）：指装有待测DCAS系统的车辆。

基础测试（Base Test）：指制造商应声明系统能够安全控制车辆的边界条件（例如VUT速度）的测试场景。

扩展测试（Extended Testing）：指一系列测试参数变化的组合测试场景，以验证系统在声明的系统边界内，与基础测试中声明的值和策略相比，不会不合理地改变控制策略。

12.3 一般原则

测试条件：测试应在允许激活DCAS系统或其特定功能的条件（例如环境、道路几何形状）下进行。

测试目标物：用于车辆探测试验的目标应是M类或N类常规大批量系列生产车辆，或者是符合ISO19206-3要求的代表车辆的“软目标”。

试验参数变化：制造商应向型式认证机构声明系统边界。型式认证机构应定义测试参数的不同组合（例如，被测车辆的当前速度、目标的类型和偏移量、车道曲率）。

12.4 测试程序

确认符合本UN法规的一般测试场景的要求：符合本UN法规的要求应通过以下段落的物理测试来证明。

评估系统行为的测试场景：应根据系统激活的先决条件和系统边界来选择测试方案。

公共道路验证：在适用于系统特征类型的情况下，型式认证机构应在至少一个国家进行公开道路（有交通流）的DCAS（无故障）测试或见证测试。

下图为物理测试的流程，包括基础测试、扩展测试、测试场景和测试结果分析。

13.模拟仿真要求

13.1 一般要求

如果在DCAS验证时通过使用仿真测试来验证时，建议使用建模和仿真（M&S）工具链进行仿真测试。仿真测试的置信度可以通过调查和评估五个M&S属性来确定：

能力（Capability）：M&S能做什么，以及相关的风险是什么；

精确性（Accuracy）：M&S复现目标数据的精确性；

正确性（Correctness）：M&S工具中的数据和算法有多健全和健壮（鲁棒性）；

可用性（Usability）：需要哪些培训和经验，以及管理其使用的过程的质量如何；

适合目的（Suitable）：M&S工具链在其系统边界内评估DCAS的适用性如何。

仿真测试流程方法图，包括建模与仿真、置信度评估、测试场景和测试结果分析。

13.2 定义

抽象（Abstraction）：选择源系统或参考系统的基本方面以在模型或模拟中表示的过程，而忽略那些不相关的方面。

闭环测试（Closed Loop Testing）：一个虚拟环境，考虑了在环元素的动作。模拟对象响应系统的动作（例如DCAS系统与交通流模型的交互）。

确定性（Deterministic）：描述某个系统的术语，该系统的时间演化可以精确预测，一组给定的输入将始终产生相同的输出。

驾驶员在环（Driver-In-the-Loop, DIL）：通常在用于测试人类自动化交互设计的驾驶模拟器中进行。DIL具有供驾驶员操作和与仿真环境通信的组件（例如：方向盘、油门踏板、制动踏板）。

硬件在环（Hardware-In-the-Loop, HIL）：在特定车辆子系统的最终硬件上，运行最终软件，输入和输出连接到仿真环境以执行仿真测试。

模型（Model）：对系统、实体、现象或过程的描述或表示。

模型校准（Model calibration）：调整模型中的数值或建模参数以改善与参考对象的一致性的过程。

模型参数（Model Parameter）：用于支持表征系统功能的数值。模型参数的值不一定能直接在现实世界中观察到，但必须从现实世界中收集的数据中推断出来（在模型校准阶段）。

模型在环（Model-In-the-Loop, MIL）：允许算法快速开发而不涉及专用硬件的方法。通常，这种级别的开发涉及运行在通用计算系统上的高级抽象软件框架。

开环测试（Open Loop Testing）：一种虚拟测试方法，其中数据提供单元向DCAS提供输入刺激。DCAS和通过输入刺激提供的环境之间没有反馈，因此循环是“开放的”。

概率（Probabilistic）：与非确定性事件有关的术语，其结果由可能性的度量来描述。

试验场或测试轨道（Proving Ground or test-track）：一个封闭的物理测试场地，可以在真实车辆上研究DCAS的性能。其他道路使用者可以通过传感器刺激或定位在轨道上的虚拟设备引入。

传感器刺激（Sensor Stimulation）：一种技术，通过这种技术，人工生成的信号被提供给被测试的元件，以便刺激它产生对真实环境中的障碍物同样的结果。

仿真（Simulation）：对真实世界过程或系统随时间运行的模拟。

仿真工具链（Simulation toolchain）：用于支持DCAS验证的仿真工具的组合。

软件在环（Software-In-the-Loop, SIL）：开发模型的实现将在通用计算系统上进行评估的地方。这一步可以使用非常接近最终实现的完整软件实现。

随机（Stochastic）：指涉及或包含一个或多个随机变量的过程，与机会或概率有关。

仿真模型的验证（Validation of the simulation model）：从工具的预期用途的角度确定仿真模型在多大程度上是真实世界的准确表示的过程。

车辆在环（Vehicle -In-the-Loop, VIL）：真实测试车辆在现实世界和虚拟环境中的融合环境。它可以反映与现实世界相同水平的车辆动态，并且可以在车辆试验台或测试轨道上操作。

仿真模型的验证（Verification of the simulation model）：确定仿真模型或虚拟测试工具在多大程度上符合其概念模型、数学模型或其他结构中详述的要求和规范的过程。

虚拟测试（Virtual testing）：使用一个或多个仿真模型测试系统的过程。