从ECER157e看L3自动驾驶的FuSa与SOTIF工程实践

安全又复杂。

预期的功能是安全且复杂的。。

L3级自动驾驶，非常复杂。。。

ECER157e，三个叠在一起，挺简单的？

***************************

L3级自动驾驶仪和国内外法规

早在2016年甚至更早的时候，汽车行业就在讨论或者炒作L3或者L3+以上的自动驾驶系统。直到今天，6-7年过去了。在这段漫长的时间里，我们的汽车工业并非没有成功:虽然我们只量产了L2和L2+系统，但全球首个限制L3自动驾驶的法规:ECE-R157e已于2021年在欧洲正式推出。当然，作为人类进入高级自动驾驶世界的第一块敲门砖，它也有其最初不可避免的局限性:首先，它只适用于L3自动驾驶中的一项功能:alks——自动车道保持辅助系统；再者，目前适用于低速场景的设定。但第二版的规定将限速进一步提高到130 kph，更符合一般高速公路行驶情况。

ECR157E是全球首个L3自动驾驶法规。笔者认为，这一规定对于自动驾驶行业来说，具有很大的技术价值。主要原因如下:

1.自动驾驶涵盖的行为众多且复杂。《规定》在收集和反馈行业发展经验的基础上，总结了一系列技术要求:部分要求在更高的粒度上定义系统行为；一些要求限制了系统的低细节行为或性能。但达到了简化复杂的目的，从车辆行为的角度定义了这些需求。这样做的好处是，汽车制造商可以清楚地看到自己开发的整个系统最终必须符合什么行为；对于中下层供应商来说，他们可以看到他们的产品最终将如何有助于整个系统的安全。像法规这样的“开源需求”可以普及整个自动驾驶产业链的开发目的和认知的统一。

2.虽然首个ECE R157e法规针对的是低速高级自动车道保持功能，但其定义的系统行为中有一些内容和行为，在我看来是可以普遍适用于不同的自动驾驶特性:比如em模式和一般驾驶模式甚至故障模式之间的仲裁:这些行为估计了特性中其他不同的自动驾驶特性:变道控制；；飞行员导航；城市飞行员...等等，可以原封不动地重复使用。

3.国内自驾准入指南也是去年发布的，但国内准入指南中的定义大多是高层次的指导性要求:开发者需要从流程方法和能力上保证产品开发的安全性。与ECER157e相同的是，它着重从功能安全/预期功能安全和网络安全三个维度来保障产品安全。但不同的是，ECER157e将功能安全/预期功能安全和网络安全这三个安全属性尽可能地放到产品开发的具体技术需求中，并给出了这些安全属性如何综合考虑并落实到产品行为中的更清晰的轮廓。

4.笔者认为，国内的自动驾驶准入法规，最终一定会演变成有具体技术要求的法规:这可能是定性的行为，也可能是定量的指标。在具体技术要求的定义上，笔者认为ECE R157e在未来一定会成为一个重要的参考点:可能会在此基础上进一步细化或调整。当然，如果R157e法规中定义的行为已经在具体的量产车上通过了市场测试，并且在使用中被证明是没有问题的，那么这些行为很有可能会在全球层面被标准化。

***************************

ISO26262ISO21448与ECE R157e的关系

为了完全实现可靠的市场导向的自动驾驶产品，必须考虑三个层次的设计:

第一个层面是功能性基本框架的设计和开发:这包括OEDR/ DDT/ ODD的定义……这些自动驾驶的基本组件。这方面能提供的标准法规很少，目前包括ISO TR 4804ECR157E...可以为设计考虑提供一些输入。ECR157E作为欧盟的准入法规，关注的不仅仅是安全问题本身，还有一些基本功能的标准化。

第二个层次是功能和性能细节的微调和设置:这些微调设置必须考虑舒适性；可用性；出色的性能，最重要的是安全性。不同的功能设置和性能调整如何与安全问题耦合，甚至如何分析；评价；验证？这些内容类别都属于ISO 21448预期功能安全的目标。在这个问题上，ECER157e也有一些规范和要求:比如自动驾驶模式和制动力的关系就是典型的预期功能安全问题。

第三个层次是对设计的功能和系统架构进行必要的失效分析和加固:如果失效本身会造成安全问题，则针对问题的设计加固工作属于功能安全技术的范畴。已经有很多成熟的标准，如ISO 26262第二版关于功能安全问题的处理，ECER157e也有相当的重视和要求，但其技术体系没有ISO 26262复杂。它定义了主要安全的概念，并引用了ISO 26262提到的要求。

当然，另一个维度的设计与网络安全有关。从ECE R157e的角度来看，它将与ECE R155和ISO 21434相关，但这超出了本文的范围。

所以ECER157e看起来是自动驾驶设计需求的管理者:每个设计层面都有涉及，但并没有真正深入到各个层面的细节，主要集中在各个层面必须满足的核心关键需求上。但是对于开发者来说，如何快速准确的实现这些工程需求，才是最具挑战性的地方。理论上，如果一家公司能够满足自动驾驶系统的三大安全标准(功能安全；预期的功能安全性和网络安全性)完全符合产品要求。当其面对ECER157e的要求时，主要的产品开发影响会发生在产品功能、安全概念或性能设定的设计变更上，但不应涉及新产品概念或细节的开发。然而现实并没有那么美好:真正的自动驾驶从业者很难做到三大安全标准的产品完全合规:即使拿到了认证，也不能代表已经完全合规。毕竟，对于自动驾驶等新技术应用的复杂产品，很多地方都涉及到利用专家的意见来量身定制和调整需求:比如人工智能和开源Linux的使用，他们申报完整的产品安全合规性所需的投入远远超出想象。

基于这种真实的产业情况，一个合理的自动驾驶工程实践方案，可以让厂商宣称ECE R157e 100%合规，三大安全标准关键点合规(至少风险是合理的，足够低)，这将是当前产业真正需要的答案:尤其是那些必须出口欧洲，拥有L3feature的车辆和厂商。

***************************

如何在目前的产品中实践ECER157e的工程化要求？

现在让我们来看看这个令人生畏的规定。它定义了哪些需求？我们如何实现它？下面我们列举一个功能需求和一个安全相关需求(ASILC-D)来分别解释。

第一个要求来自ECER157e法规的8.6.1。虽然法规中没有标明每个要求的安全级别，但根据YAI的实践和分析，这是安全级别QM的要求:

「DSSAD应能与系统通信，告知DSSAD正在运行」

这一要求要求整个自动驾驶系统必须了解自动化系统数据存储系统的工作状态。

为了让我们知道如何更好更完整地实践这个需求，我们仅仅了解需求本身的内容是不够的。我们还必须知道为什么这样设置这个要求。

优雅分析小组对ECER157e的内容进行全面了解后，确认该要求对应另一个ASIL级别的监管要求，要求如下:

6.2.3:只有在驾驶员有意采取行动并且满足以下所有条件的情况下，系统才应激活:

驾驶员坐在驾驶员座椅上，并根据段落6.1.1系好驾驶员安全带。和6.1.2。；

驾驶员可根据第6.1.3段接管滴滴涕的控制权。；

不存在影响ALKS安全运行或功能的故障；

DSSAD投入运行(QM)；

环境和基础设施条件允许作业；

系统自检的积极确认；和

车辆行驶在禁止行人和骑自行车者通行的道路上，并且按照设计，道路上设有物理隔离带，用于分隔反向行驶的车辆。」

这里，我们不讨论依赖的问题，所以为什么ASIL需求可以被QM需求覆盖。但从这个关联要求中我们可以看出，DSSAD的工作状态是决定整个系统能否使用或退出的关键条件之一。基于这种理解，优雅的分析团队在工程实践方案中定义了DSSAD必须与系统沟通的关键数据和变量如下:

信号

目的

Dssad_Sta

用于判断DSSAD操作状态

Dssad _失败

用于认定DSSAD失败状态

Dssad_Timeout

用于检测DSSAD总线状态

同时，我们还定义了每个数据中变量的取值范围，使法律法规的工程化理念落到实处。

这里可以再举一个例子，针对另一个与安全高度相关，也承载ASIL级别的需求，6.2.5.4:

在严重的车辆故障或严重的ALKS故障的情况下停用

在严重的车辆故障或严重的ALKS故障的情况下，ALKS可以采用不同的停用策略。

这些不同的策略应由制造商声明，其有效性应由技术服务机构根据附录4]对苏恩环从系统到人类驾驶员的控制安全转换进行评估

这里法律要求的核心工程概念是，当系统遇到严重故障时，系统必须考虑阶段性退出机制。

同样，优雅的分析工程团队必须明确定义以下内容，以便将上述工程概念实现为满足法规要求的底层实现:

1.哪些故障属于严重的车辆故障？

2.哪些故障属于严重的自动驾驶故障？

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

第一个问题和第二个问题与功能安全直接相关，第三个问题是功能安全和预期功能安全的耦合。基本思想是MRC和安全状态的具体设计。这三个问题的综合设计就是安全概念设计。

但是对于这三个问题的分析和实现，仅仅熟悉相关的安全标准ISO 26262/ ISO 21448是远远不够的，必须要有一定的自动驾驶至少L2+到L3级别的工程实践经验，才能提出相应的实现方案。基于此，Ya分析工程团队还在我们的解决方案中定义了严重车辆故障的类型；自动驾驶系统的故障类型(如:车道线识别等感知模块的关键要素等。);以及MRC机制的应对策略。

对于ECER157e法规中提到的114项技术要求，YAI工程团队提出了解释，并以以下三种形式作为实现结果或方案实施:

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

2.参见系统设计方案。

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

***************************

我们优雅的现成解决方案和案例

现在这个高度内卷化的时代，产品的竞争力来源于快速准确的实现目标！

为了帮助国内自动驾驶开发者在1-2年内成功嫁接到L3和L3+的先进自动驾驶领域，甚至成功向欧盟或全球出口具有L3或以上特征的车辆，基于我们过去多年的安全实践和参与自动驾驶开发项目的经验，我们的工程团队针对过去客户的技术咨询需求，开发并提供了专用的SDK- ASIL D安全模式仲裁器，该仲裁器具有以下技术和实现特点:

基于ISO26262 SEooC的开发

2.针对ASILD安全完整性级别的自动驾驶应用可以适应L2+和L3(失效降级架构)

3.软件模块的行为要考虑以下设计:ECE R157e定义的系统必须实现行为；形状记忆合金模块的内部故障及相关安全机制:贯彻必须采取故障响应措施来处理整车系统级故障的安全理念；Ecr157e指的是对ISO 21448的必要触发响应。

4.对于L3以上的应用，考虑冗余架构的部署和相关安全投票机制的设计，能够满足L3的失效降级目标。

5.整个ASILDSMA模块的规模为:141个子系统/函数调用；；c代理号码是13152 LoC。

6.能够适应SOA架构下的控制器和软件实现，通过ASILDSMA和应用服务/功能服务的调度协作，完成L3级功能和ECER157e规程的要求。

7.完整的工程文档支持工程集成；设置API参考设计方案...诸如此类。