UN ECE R157《自动车道保持系统 ALKS》解读

1.  关于UN ECE R157

UN ECE R157自动车道保持系统（Automated Lane Keeping System，简称“ALKS”）是针对“L3级”自动化驾驶的第一个具有约束力的国际法规，该法规标志着自动驾驶技术发展的重要一步，于2020年6月首次通过，于2021年1月起生效。

R157旨在制定关于自动车道保持系统（ALKS）车辆认证的统一规定。ALKS控制车辆长时间的横向和纵向移动，无需驾驶员进一步的命令。激活ALKS时，其应代替驾驶员执行驾驶任务，即管理包括故障在内的所有情况，并且不得危及车辆乘员或任何其他道路使用者的安全。但是，驾驶员必须随时都有可能接管该系统。

2022年6月22日WP29对该法规进行了修订，修订后的法规基本覆盖了高速公路点到点自动驾驶全场景，不再仅适用于高速公路低速或堵车场景。修订后的法规将适用范围由M1类车辆扩展到了M和N类车辆，将特定交通环境中的自动驾驶系统 (ADS)车速上限从当前的60km/h扩展到了130km/h。

  2.  国内外L3级别自动驾驶法规对比

自动驾驶的行为范围广泛复杂，相关法规基于行业发展经验的总结与反馈，概括了一系列技术需求：有些需求在高级别上定义系统行为，而有些则在较低层面限制系统行为或性能。尽管这些法规已经简化了复杂性，是以整车行为的角度定义需求的好处在于：对车厂来说，他们清楚了解自己开发的系统必须满足的最终行为；对于中层和底层供应商（包括软件或芯片供应商），他们了解自己的产品如何对整个系统的安全性做出贡献。这类类似“开源需求”的法规有助于统一汽车自动驾驶产业链对于开发目标和认知的理解。 

虽然最初的ECE R157e法规针对低速高级别自动车道保持功能，但它定义的系统行为中包含一些内容和行为，我认为可以适用于不同的自动驾驶功能：比如紧急调度策略、一般驾驶模式甚至故障模式的仲裁。这些行为很可能可以被其他未来的自动驾驶功能直接复用。 

国内的自动驾驶准入指南去年也发布了，但其定义的大多是高级的指导性需求：开发商需要通过流程方法和能力来确保产品开发的安全性。与ECE R157e相似之处在于：它们都关注功能安全、预期功能安全和网络安全这三个方面来确保产品安全。不同之处在于，ECE R157e尽可能地将这些安全属性融入产品开发的具体技术要求中，让这些安全属性如何一并考虑并落实成产品行为更加清晰。

目前国内的自动驾驶准入法规最终需要演化为具备具体技术需求的规定：这可能是定性的行为或定量的指标。在具体技术需求的定义上，未来ECE R157e很可能会成为重要的参考点：或许会基于它进一步细化或调整法规。当然，如果ECE R157e法规中定义的行为在实际量产车上经过市场考验（证明使用中没有问题），那么这些行为被全球标准化的可能性也非常高。

  3.  ISO26262、ISO21448和ECE R157e这三者之间的关系

这首先涉及到实现可靠的自动驾驶产品所需考虑的三个设计层次。

第一层：首先是功能基础框架的设计和开发：这包括了OEDR/DDT/ODD等构成自动驾驶基本要素的定义。目前在这个领域能够提供一些标准和法规的输入，包括ISO TR 4804和ECE R157e。作为欧盟准入法规，ECE R157e关注的不仅是安全议题，也关注了一些基础功能的标准化，比如DSSAD的设计要求；

第二层：其次是功能和性能细节上的微调和设定：这些调整需兼顾舒适性、可用性、性能突出性和最重要的安全性。不同的功能设定和性能调校如何与安全问题耦合，以及如何分析、评估和验证，都属于ISO 21448预期功能安全的范畴。在这方面，ECE R157e也有一些规范和要求，比如自动驾驶模式与制动力道之间的关系，是典型的预期功能安全议题；

第三层：最后是对设计的功能和系统架构必要的失效分析补强：如果失效会带来安全问题，那么对这个问题的设计补强就是功能安全技术的一部分。已有许多成熟的标准，比如ISO 26262 Ed.2。在处理功能安全问题时，ECE R157e也相当重视和要求，尽管其技术体系不及ISO 26262复杂，但它定义了初阶安全概念并引用了ISO 26262内的要求。

除了这些层次设计，还有与网络安全相关的设计，从ECE R157e的角度看，它与ECE R155和ISO 21434都有关系，不过这不在本文的讨论范围内。

总的来说，ECE R157e似乎是自动驾驶设计需求的管理员：涵盖了每个设计层面，但未真正深入到所有层面的细节。它主要关注在每个层面上必须满足的核心关键需求。但对开发者而言，如何快速、准确地实现这些工程需求是最具挑战性的。理论上，某些公司能够达到三大安全标准（功能安全、预期功能安全和网络安全）的产品合规，面对ECE R157e的要求，主要的产品开发影响可能出现在产品功能、安全概念或性能设定的设计变更上，而不是新的产品概念或细节。然而，现实并非如此理想：真正实现三大安全标准的产品合规对自动驾驶从业者来说是极具挑战性的。即使获得认证证书，也不代表完全合规，因为针对这类应用新技术的复杂产品，许多地方需要专业意见来调整和剪裁以满足需求，比如人工智能和开源Linux的使用，要确保完全产品安全合规需要的投入远远超出预期。

在这种真实产业情况下，一个合理的自动驾驶工程实践方案，能够让制造商宣称符合ECE R157e和三大安全标准的核心要求，将是当前产业急需的解决方案，特别是对于那些需要出口欧洲且具备L3功能的车型和制造商。

  4. 应用ECE R157e工程需求于现有产品的有效方法

让我们重新审视这个引人注目的法规，探究其中所定义的需求内容以及我们应如何加以实现。我们将提取一个功能级需求（QM）和一个安全相关需求（ASIL C-D）来加以说明。第一个需求源自于ECE R157e法规中的8.6.1条款，尽管法规未明确标注每个需求的安全等级，但根据我们的实践和分析，这是一项安全级别为QM的需求：

DSSAD shall be able to communicate with the system to inform that the DSSAD is operational

该需求要求整个自动驾驶系统必须了解自动系统的数据存储系统的工作状态。仅仅理解需求的内容是不够的，我们还需了解为何要设定这项需求。

通过对ECE R157e内容的全面了解，我们确认这一需求与另一携带ASIL等级的法规需求相对应，其内容如下：

6.2.3：The system shall become active only upon a deliberate action by the driver and if all the following conditions are met:

(a) The driver is in the driver's seat and the driver’s safety belt is fastened according to paragraphs 6.1.1. and 6.1.2.;

(b)  The driver is available to take over control of the DDT according to paragraph 6.1.3.;

(c) No failure affecting the safe operation or the functionality of the ALKS is present;

(d)  DSSAD is operational (QM);

(e) The environmental and infrastructural conditions allow the operation;

(f)  Positive confirmation of system self-check; and

(g)  The vehicle is on roads where pedestrians and cyclists are prohibited and which, by design, are equipped with a physical separation that divides the traffic moving in opposite directions. 

我们不会深入探讨依赖性问题，导致ASIL需求可以包含QM需求的原因。然而，从这一关联需求我们可以看出，Data Storage System for Automated System（DSSAD）的工作状态是系统能否使用或退出的关键条件之一。基于此理解，项目团队在工程实践方案中定义了DSSAD必须与系统沟通的关键数据与变量如下：

同时，我们也对每个数据内的变量取值范围进行了定义，以确保法规中的工程概念能够落实到具体的底层实践中。

我们还可以举一个例子，针对另一条与安全高度相关且携带ASIL等级的需求，即6.2.5.4：

Deactivation in case of a severe vehicle failure or a severe ALKS failure
In case of a severe vehicle failure or a severe ALKS failure, the ALKS may employ different strategies with regard to deactivation.These different strategies shall be declared by the manufacturer and their effectiveness shall be assessed by the Technical Service with regard to ensuring a safe transition of control from the system to the human driver according to Annex 4

该法规需求的核心工程概念是，当系统遭遇严重故障时，必须考虑阶段性退出机制。

同样地，工程团队必须明确定义以下几点，以将上述工程概念转化为符合法规要求的底层实现：

哪些故障属于严重整车故障？

哪些故障属于严重自动驾驶系统故障？

阶段性退出机制必须设计几个阶段？各个阶段的适用条件是什么？这些不同阶段对降低风险的有效性有何影响？

前两个问题直接关联到功能安全议题，而第三个问题则融合了功能安全议题和预期功能安全议题。基本上，核心思路是MRC与安全状态的具体设计。这三个议题综合在一起形成了安全概念设计。

然而，要解决这三个问题并将其实施为符合法规的底层实现，仅仅熟悉相关的安全标准如ISO 26262/ISO 21448是不够的。必须对自动驾驶至少L2+至L3级别以上的工程实践有相当经验，才能提出相应的实现方案。基于此，工程团队在我们的解决方案中定义了严重整车故障的种类（例如：供电系统、人机交互接口等），自动驾驶系统故障的种类（例如：感知模块的关键要素如车道线识别等），以及MRC机制的响应策略。

对于ECE R157e法规提及的114条技术需求（排除网络安全），工程团队已提出解释，并将其落实为以下三种形式的实现结果或方案：

1.控制逻辑实现后的软件SDK。

2.参考系统设计方案（对于软件无法实现的部分）。

3.相关控制与状态信号的消息定义。

  5.  结束语

随着自动驾驶技术的发展，车辆上将部署越来越多的电子控制系统及复杂软件，该类系统的安全性和可靠性也需要被重视。因此UN-R157 法规在与安全相关的电子系统方面也进一步提出了具体要求，即系统的安全设计需要考虑功能安全和信息安全的理念，在型式认证批准方面需要制造商提供相应的证明文件，同时对企业及其供应商的安全开发流程进行审核，从安全设计到安全管理流程全方位地进行监管。

除此之外，最终通过技术和流程评审的ALKS系统需要依据附录4和5要求，在封闭试验场和真实道路交通环境下分别进行验证系统的性能和安全性，试验场景包含 （但不限于） 如行车跟随、切入、切出、前方静态和动态的跟车目标，道路感知区域和目标识别等。依据不同的环境条件，车辆行驶状态进行组合，届时测试场景会非常复杂。如何选择合适的代表性场景进行道路测试将是企业所面临的难题。