联合国自动驾驶法规R157对L3级自动驾驶ALKS的要求⑧

1.背景

2.R157各名词定义

3.系统安全和故障安全响应要求

4.人机交互界面信息要求

5.障碍物和事件感知与响应要求

6.数据存储系统要求

7.网络安全和软件更新要求

8.交通干扰关键场景指南

9.ALKS功能和操作安全的特殊要求

10.试验场内测试规范

11.公共道路测试规范

9.  ALKS功能和操作安全的特殊要求

9.1  一般要求

       本段的要求旨在确保主机厂在设计和开发过程中对提供R157-ALKS法规规定的功能的自动化系统的功能安全和操作安全性进行了全面考虑，并将在车辆的整个生命周期（设计、开发、生产、运行、报废）中继续进行。

       主机厂必须向型式认证机构公开其功能安全和操作安全的相关文档，并由型式认证机构进行验证。

        主机厂需留档证明自动车道保持系统ALKS符合上文第3、4、5、6段所指明的性能规定，该系统在设计及开发上的运作方式不会对驾驶员、乘客及其他道路使用者构成不合理的安全风险。

       型式批准机构应通过有针对性的抽查和测试来验证留档的真实性，留档中描述的设计和工艺实际上是由主机厂实施的。

        虽然根据主机厂所提供的留档、证据和过程审核、产品评估等一系列验证，可以使型式批准机构对系统的合规性感到满意，被测评的ALKS的剩余风险被认为是可接受的，但根据本法规的要求，自动车道保持系统整个生命周期内的整体车辆安全仍然是请求型式批准的主机厂的责任。

9.2 定义

9.2.1

9.2.2

      “安全概念Safety Concept”是对系统中设计的措施的描述，以便车辆在故障和非故障条件下不会对驾驶员、乘客和其他道路使用者造成不合理的安全风险。回退到部分运行（功能降级）甚至是重要车辆功能的备用系统（冗余备份）的可能性应是安全概念的一部分。

9.2.3

9.2.4   “高级电子控制Higher-Level Electronic Control”系统是那些采用处理和/或传感装置来实现动态驾驶任务DDT的系统。

9.2.5   “单元Units”是本章将审议的系统组件的最小分类，为了识别、分析或替换的目的，这些组件的组合将被视为单一实体。

9.2.6   “传输链路Transmission links”是用于连接分布式单元以传输信号、操作数据或能量供应的手段。这种设备通常是电动的，但在某些部分可能是机械的、气动的或液压的。

9.2.7   “控制范围Range of control”是指输出变量，并定义了系统可能行使控制的范围。

9.2.8   “功能操作边界Boundary of functional operation”定义了系统能够执行动态驾驶任务的外部物理边界（即包括接管请求和最小风险操作MRM）。

9.2.9   自动车道保持系统ALKS的“操作设计域Operational Design Domain（ODD）”定义了本法规确定的边界内的特定操作条件（例如环境、地理、一天中的时间、交通、基础设施、速度范围、天气和其他条件），在这些条件下，自动车道保持系统被设计为在没有驾驶员任何干预的情况下运行。

9.2.10   “自动驾驶功能Automated Driving Function”是指“系统”能够执行车辆动态驾驶任务的功能。

9.2.11  “控制策略Control strategy”是指针对一组特定的环境和/或操作条件（如路面状况、交通强度和其他道路使用者、恶劣天气条件等）下，确保“系统”功能稳健和安全运行的策略。这可能包括功能的自动停用或临时性能限制（例如降低最高运行速度等）。

9.2.12   “功能安全Functional safety”：在电气/电子系统故障行为造成的危险发生时不存在不合理的风险（系统故障造成的安全危险）。

9.2.13   “故障Fault”：可导致某一要素（系统、部件、软件）或某一项目（实现车辆某一功能的系统或系统组合）发生故障的异常状况。

9.2.14  “失败Failure”是指一个元素或一个项目的预期行为的终止。

9.2.15  “操作安全Operational safety”是指在由于预期功能的功能不足（例如错误/漏检）、操作干扰（例如雾、雨、阴影、阳光、基础设施等环境条件）或驾驶员、乘客和其他道路使用者合理可预见的误用/错误（安全危险-没有系统故障）而导致的危险发生时，不存在不合理的风险。

9.2.16  “不合理风险Unreasonable risk”是指与老司机（熟练和谨慎驾驶的驾驶员）手动驾驶车辆相比，驾驶员、车辆乘员和其他道路使用者的总体风险水平有所增加。

9.3   文档

9.3.1  文档要求

       主机厂应提供一个留档包，以便访问“ALKS系统”的基本设计以及它与其他车辆系统的连接或直接控制输出变量的方式。

       应解释主机厂规定的“ALKS系统”的功能，包括控制策略和安全概念。

       文档应简短，但提供证据表明设计和开发受益于所涉及的所有系统领域的专业知识。

        对于定期技术检查，留档应描述如何检查“ALKS系统”的当前运行状态（系统状态显示）。

       关于软件版本（一个或多个）和故障警告信号状态的信息可以经由电子通信接口以标准化的方式被读取，至少可以是标准接口（OBD端口）。

型式认证机构应评估留档包，以显示“ALKS系统”：

（a）设计和开发的方式使其在宣布的ODD和边界内对驾驶员、乘客和其他道路使用者没有不合理的风险；

（b）遵守本UN ECE法规其他地方指明的要求；

（c）ALKS系统是根据主机厂声明的开发过程、方法开发的，这应至少包括第9.3.4段中列出的步骤。

文件应分三部分提供：

 （a）型式批准申请：在型式批准申请时提交给型式批准机构的信息（information）文件应包含附件1附录1中列出的项目的简要信息。它将成为批准的一部分。

（b）用于批准的正式留档包，包含第9.3段所列材料，应提供给型式批准机构，用于进行产品评估/工艺审核。型式批准机构应将此留档包用作第10、11段所列验证过程的基本参考。型式批准机构应确保此留档包在车型停产后至少10年内保持可用。

（c）第9.3.4段规定的其他机密材料和分析数据（知识产权），主机厂应保留这些数据，但在产品评估/工艺审核时开放供检查（例如在主机厂的工程设施现场）。主机厂应确保这些材料和分析数据在车型停产后至少10年内保持可用。

9.3.2   “ALKS系统”的功能描述，包括控制策略

        主机厂应提供一份描述，简单说明所有功能，包括“ALKS系统”的控制策略以及在ODD和自动车道保持系统设计运行的边界内执行动态驾驶任务DDT所采用的方法。主机厂应描述ALKS系统与驾驶员、车辆乘员和其他道路使用之间预期的交互（HMI）策略。

       任何启用或禁用自动驾驶功能的硬件和软件，应在车辆生产时已存在于车辆中，应在车辆使用前声明并受本附件要求的约束。主机厂还应记录实施连续学习算法时的数据处理。

   应提供所有输入和检测变量的列表，并定义这些变量的工作范围，以及每个变量如何影响系统行为的描述。

  应提供由“ALKD系统”控制的所有输出变量的列表，并在每种情况下给出控制是直接控制还是通过另一个车辆系统控制的解释。应定义对每个此类变量实施的控制范围。

  在自动车道保持系统ALKS性能正常的情况下，应说明界定功能操作界限的限值，包括ODD限值。

  应解释达到ODD限制时与驾驶员的交互信息，包括系统将向驾驶员产生接管请求的情况类型列表。

 应提供关于启动、override或停用系统的方法的信息，包括如何保护系统免受无意停用的策略。这还应包括关于系统如何检测到驾驶员可以接管驾驶控制（驾驶员可用）的信息，以及用于识别驾驶员注意力参数的规格和文件证据以及对转向阈值的影响。

9.3.3  系统布局和示意图

组件清单：

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

应提供显示这些单元组合的概要示意图，并明确设备分布和连接方式。

 该清单应包括：

（a）感知和物体检测，包括地图和定位；

（b）决策的描述；

（c）远程监督中心的远程监督和远程监控（如适用）；

（d）数据存储系统（DSSAD）。

各单元的功能：

 应概述“系统”每个单元的功能，并显示其与其他单元或其他车辆系统连接的信号。这可以通过标记的框图或其他示意图提供，也可以通过图表的辅助描述提供。

  “系统”内的互连应以电气传动环节的电路图、气动或液压传动设备的管线图和机械连杆的简化图解布局显示。还应显示通往和来自其他系统的传动环节。

 传输链路和单元之间传输的信号之间应有明确的对应关系。如果优先级可能是影响性能或安全的问题，则应说明多路复用数据路径上信号的优先级。

单元的识别：

 每个单元应清晰明确地识别（例如，通过硬件标记，以及通过软件内容的标记或软件输出），以提供相应的硬件和留档关联。如果可以更改软件版本而无需更换标记或组件，则软件标识必须仅通过软件输出（如果后期会更新软件版本，则应更换标签或软件版本号不能在实体上体现）。

 如果功能在单个单元内或实际上在单个计算机内组合，但为了清晰和易于解释而在框图中以多个块显示，则只能使用单个硬件标识标记。制造商应通过使用此标识来确认所提供的设备符合相应的文件。

  标识定义了硬件和软件版本，如果后者发生变化，例如就本条例而言改变了装置的功能，则也应更改该标识。

感知系统组件安装：

主机厂应提供有关组成感知系统的各个组件将采用的安装选项的信息。这些选项应包括但不限于组件在车辆中/上的位置、组件周围的材料、组件周围材料的尺寸和几何形状以及组件周围材料的表面光洁度，一旦安装在车辆中。该信息还应包括对系统性能至关重要的安装规格，例如安装角度的公差。

  感知系统各个部件或安装选项的更改应通知型式认证机构，并接受进一步评估。

9.3.4  主机厂的安全理念

  对于“系统”中使用的软件，应解释概要架构，并确定使用的设计方法和工具。主机厂应在设计和开发过程中出示其确定系统逻辑实现方式的证据（仿真验证）。

  主机厂应向型式认证机构解释“系统”中内置的设计条款，以确保功能和操作安全。“系统”中可能的设计条款例如：

（a）回退到使用部分功能运行的状态（功能降级）。

（b）具有单独系统的冗余（冗余备份）。

（c）取消自动驾驶功能。

   如果所选设备在某些故障条件下（例如严重故障）选择部分性能操作模式，则应说明这些条件（例如严重故障类型），并定义由此产生的有效性限制（例如立即启动最小风险操作）以及对驾驶员的警告策略。

    如果所选设备选择第二种（冗余备份）方式来实现动态驾驶任务DDT的性能，则应解释转换机制的原则、冗余的逻辑和水平以及任何内置的备份检查功能，并定义备份有效性的最终限制。

   如果所选择的设置选择移除自动驾驶功能，则应符合本条例的相关规定。与此功能相关的所有相应输出控制信号应被禁止。

 应通过分析支持留档包，该分析总体上显示系统将如何减轻或避免可能影响驾驶员、乘客和其他道路使用者安全的危险。

  所选择的分析方法应由主机厂建立和维护，并应在型式认证时开放供型式认证机构检查。

 型式认证机构应对分析方法的应用进行评估：

（a）在概念（车辆）层面检查安全方法。此方法应基于适合系统安全的危险/风险分析。

（b）检查系统层面的安全方法，包括自上而下（从可能的危险到设计）和自下而上（从设计到可能的危险）的方法。安全方法可以基于故障模式和影响分析（FMEA）、故障树分析（FTA）和系统理论过程分析（STPA）或任何适合系统功能和操作安全的类似过程。

（c）验证/验证计划和结果的检查，包括适当的验收标准。这应包括适合验证的验证测试，例如硬件在环（HIL）测试、车辆道路运行测试、真实最终用户的测试或任何其他适合验证的测试。验证的结果可以通过分析不同测试的覆盖率和为各种指标设置覆盖率最小阈值来评估。

 检查应确认在（a）-（c）项适用的情况下至少涵盖以下每一项：

（i）与其他车辆系统交互相关的问题（例如制动、转向）；

（vii）对车辆安全有影响的网络攻击（可以通过根据《关于网络安全和网络安全管理系统的UN第155号条例》进行的分析来完成）。

 应通过以下方法证明车辆对驾驶员、车辆成员和其他道路使用者没有不合理的风险：

（a）由验证结果支持的总体验证目标（即验证接受标准），证明自动车道保持系统的投入使用总体上不会增加驾驶员、车辆乘员和其他道路使用者与手动驾驶车辆相比的风险水平；和

（b）针对特定场景的测试表明，与每个安全相关场景的手动驾驶车辆相比，该系统总体上不会增加驾驶员、乘客和其他道路使用者的风险水平；和

  型式认证机构应执行或要求执行第9.4段规定的试验，以验证安全概念。

   本留档应逐项列出被监测的参数，并应针对本段所定义类型的每种故障情况，列出向驾驶员/车辆乘员/其他道路使用者和/或服务/技术检查人员发出的警告信号。

       本留档还应描述为确保“系统”的性能受到环境条件（如气候、温度、灰尘进入、水进入、冰填充）的影响时，不会对驾驶员、车辆乘员和其他道路使用者造成不合理的风险而采取的措施。

9.3.5   安全管理体系（过程审计）

  关于“系统”中使用的软件和硬件，主机厂应向安全管理体系的型式批准机构证明，有效的流程、方法和工具已经到位，是最新的，并在组织内得到遵循，以管理整个产品生命周期（设计、开发、生产、操作，包括遵守交通规则和报废）的安全和持续合规性。

 主机厂应建立设计和开发流程，包括安全管理体系、需求管理、需求实施、测试、故障跟踪、补救和发布。

  主机厂应建立和维护负责功能/操作安全、网络安全和与实现车辆安全相关的任何其他相关学科的制造商部门之间的有效沟通渠道。

  主机厂应具备监控由启用的自动车道保持系统引起的安全相关事件/碰撞/碰撞的流程，以及管理注册后潜在安全相关漏洞（现场监控闭环）和更新车辆的流程。当出现关键事件时，他们应向型式认证机构报告关键事件（例如与其他道路使用者的碰撞和潜在安全相关漏洞）。

  主机厂应证明进行了定期独立的内部过程审核，以确保按照本段建立的过程得到一致实施。

  主机厂应与供应商建立适当的安排（例如合同安排、明确的接口、质量管理体系），以确保供应商安全管理体系符合本段的要求（除了与车辆相关的方面，如“操作”和“报废”）。

9.4   验证和测试

 考虑到第9.3段中提到的主机厂留档包文件的分析结果，型式认证机构应要求技术服务部门进行或见证测试，以检查审计评估中出现的具体点。

9.4.1

验证"系统"的功能：

  型式认证机构应在非故障条件下验证“系统”，方法是在轨道上测试主机厂在上文第9.3.2段中描述的一些选定功能，并检查系统在实际驾驶条件下的整体行为，包括是否符合交通规则。

 这些测试应包括驾驶员override系统的情况。

这些测试可以基于第10部分和第11部分中列出的情景和/或第10部分和第11部分中未涵盖的其他情景。

 试验结果应符合主机厂在第9.3.2段中提供的描述，包括控制策略，并应符合本法规的要求。

  “系统”的反应应在任何单个单元的故障影响下进行检查，通过向电气单元或机械元件施加相应的输出信号，以模拟单元内部故障的影响。型式认证机构应至少对一个单个单元进行此检查，但不应检查“系统”对单个单元的多个同时故障的反应（模拟单个故障）。

型式认证机构应验证这些测试包括可能对车辆可控性和用户信息产生影响的方面（HMI方面，例如接管方案）。

型式批准机构还应检查一些对物体和事件检测和响应（OEDR）以及系统决策和HMI功能特征至关重要的场景（例如，当系统到达ODD边界时难以检测的物体、交通干扰场景）。

  验证结果应与记录在案的危险分析摘要相一致，达到总体效果水平，从而确认安全概念和执行是充分的，符合本法规的要求。

9.4.2

  型式认证机构可以通过第10部分和第11部分下进行的场地内和公共道路测试的结果，在需要时进行额外测试来验证所使用模拟工具的准确性。

9.5  评估报告

  本附件的附录1中给出了技术服务向型式认证机构提交的评估表的可能布局示例。本附录中列出的项目被概述为需要涵盖的最小项目集。

9.6   保留

9.7   审计师/评估员的能力

本附件下的评估只能由具有此类目的所需技术和行政知识的审计员/评估员进行。他们尤其应胜任ISO26262-2018（功能安全-道路车辆）和ISO/PAS 21448（道路车辆预期功能的安全）的审计员/评估员；并应能够根据UN ECE R155和ISO/SAE21434）与网络安全方面建立必要的联系。这种能力应通过适当的资格或其他同等培训记录来证明。