功能安全，复杂。
预期功能安全，很复杂。。
L3级别自动驾驶，非常复杂。。。
这三者叠在一起的ECE R157e，挺简单？
***************************
（一）L3级别自动驾驶与国内外法规
早在2016年或甚至更早的时间，汽车业就在讨论或炒作L3或L3+级别以上的自动驾驶系统，一直到今天，6-7年的时间已经过去，這段漫長時間裡我们汽车业也不是毫无斩获：虽然我们仅量產了宣告L2与L2+系统，但全世界首部约束L3级别自动驾驶的法规: ECE-R157e也在2021年正式在欧洲推出。当然，做为人类进入高级别自动驾驶世界的首部法规敲门砖，它也有初期不可避免的局限性：首先，它只适用于L3自动驾驶里面的一个feature: ALKS- Automatic Lane Keeping Assistance System；再者，目前它适用的是低速场景的設定。然而，法规的第二版将把速度上限进一步提升到更符合一般高速公路驾驶情境考虑的130 kph。
ECE R157e作为全球的第一部L3级别自动驾驶法规，笔者认为该法规对自动驾驶产业具备极大技术价值，主要原因有以下：
1. 自动驾驶覆盖的行为又多又杂，法规基于产业开发经验的收集与反馈，归纳了一连串的技术需求：有的需求在较高的颗粒度上定义系统行为；有的需求又是在较低的细节行为或性能表现上约束了系统。但它已经做到了化繁为简的目的，并且是以整车行为的角度去定义这些需求，这样的好处是对车厂而言能清楚看见自己开发的系统整体最终必须符合的行为为何；对中底层的供应商（包含软件或IC供应商）而言，他们能窥见自己的产品最终该如何贡献在整个系统的安全性上。类似法规这种的「开源需求」，能普及整个汽车自动驾驶产业链对开发目的与认知的统一。
2. 虽然首部的ECE R157e法规是针对低速高级别自动车道保持功能，但它定义的系统行为里面，有一些内容与行为，就笔者观点认为是能够通用到不同自动驾驶feature的：如EM模式（紧急调度策略）与一般驾驶模式甚至故障模式的仲裁：这些行为估计未来的其他不同的自动驾驶feature：Lane Change Control；Navigation On Pilot；City Pilot……etc，都能够原封不动的复用。
3. 国内的自动驾驶准入指南也是在去年发布的，但国内的准入指南里面定义的多半是高阶的指导性需求：开发商需要从流程方法与能力上去保障产品开发的安全性。与ECE R157e相同的地方是：它一样着眼从功能安全/预期功能安全与网络安全这3个维度去保障产品的安全。但差别在于，ECE R157e把功能安全/预期功能安全与网络安全这三种安全属性尽可能地揉入在产品开发的具体技术要求上，让这些安全属性如何能一并考虑并落实成产品行为给出了了更清楚的轮廓（笔者将在第三章节以案例解释这件事）
4. 笔者认为，国内的自动驾驶准入法规最终仍然是必须进化成有具体技术需求的法规：这可能是定性的行为或定量的指标。在具体技术需求的定义上，笔者认为将来ECE R157e必定会成为重要的参照点：可能会以此为基础来更加细化或调整。当然，若R157e法规定义的行为在具体量产车上经过市场考验proven in use没啥问题，这些行为就此在全球层级上被标准化下来也是非常有可能的。
***************************
（二）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虽提及功能安全，但ASIL这个字却从未出现），主要还是关注在各个层面上必须符合的核心关键需求为何。但对开发者而言，如何快狠准地去实践这些工程需求，是最富有挑战性的地方。理论上，若有某间公司能达成对自动驾驶系统三大安全标准（功能安全；预期功能安全与网络安全）的完整产品合规，当它面对ECE R157e的要求时，主要的产品开发冲击会发生在对产品功能，安全概念或性能设定上的设计变更，但应该不会涉及到开发新的产品概念或细节。然而，现实并非如此美好：真正自动驾驶从业者要达到三大安全标准的完整产品合规是非常困难的：即使拿到了认证证书，都不能代表已经完整合规：毕竟针对自动驾驶这类有着新技术应用的复杂产品而言，不少地方是涉及到运用专家意来针对需求的剪裁与调整：如人工智能与开源Linux的使用，它们要宣告完整产品安全合规需要的投入远超乎想象。
基于这种真实产业情况，一个合理的自动驾驶工程实践方案，能够让制造商宣告ECE R157e 百分之百符合（这点是产业界能够做到的）以及三大安全标准的重点符合（至少风险是合理足够低的），将是目前产业真正需要的解答：尤其是那些必须出口欧洲且具备L3 feature的车型与制造商。
***************************
（三）如何实践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」
这条需求要求整个自动驾驶系统必须知道Data Storage System for Automated System的工作状态。
为了让我们知道该如何更好地也更完整地去实践这条需求，我们光理解需求的内容本身是不够的，我们还必须要了解为啥么这条需求要这样定。
经过雅析团队对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 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. 」
这里不额外展开谈dependency的问题，以至于为何ASIL需求内可以包覆一条QM需求在内。但是由这条关联需求我们可以看到，DSSAD的工作状态是决定整个系统是否能使用或退出的关键条件之一。基于这样的理解，雅析团队在工程实践方案中定义DSSAD必须与系统沟通的关键数据与变量如下：
|
Signal |
Purpose |
|
Dssad_Sta |
For deeming DSSAD operating status |
|
Dssad_Failed |
For deeming DSSAD failed status |
|
Dssad_Timeout |
For detecting the DSSAD Bus status |
同时我们也对每个数据里面的变量取值范围做了定义，让法规的工程概念能够落实到具体的底层实践中。
我们这里可以再举一个例子，针对另外一条跟安全高度相关并且也携带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」
这里法规需求的核心工程概念是系统遇到严重的失效时，系统必须考虑阶段性的退出机制。
同样，雅析工程团队必须定义清楚以下几件事，才能将上述工程概念落实为符合法规要求的底层实现：
1. 哪些失效属于严重整车失效？
2. 哪些失效属于严重自动驾驶系统失效？
3. 阶段性退出机制必须设计几个阶段？分别适用条件为何？这几个不同阶段对风险降低的有效性又是如何影响？
第一个问题与第二个问题都是直接与功能安全相关的议题，第三个问题则是耦合了功能安全议题与预期功能安全议题。基本核心思路就是MRC与安全状态的具体设计。这三个议题整合在一起的设计就是安全概念设计。
但针对这3个问题的分析与实现，若仅仅是对相关安全标准ISO 26262/ ISO 21448的足够熟悉是远远不够的，必须对自动驾驶至少L2+至L3级别以上的工程实践有一定经验才能提出对应的实现方案。基于此，雅析工程团队也在我们的解决方案中定义了严重整车失效的种类（如：供电系统，人机交互接口……等等）；自动驾驶系统失效的种类（如：感知模块关键要素如车道线识别……等等）；及MRC机制的响应策略。
对ECE R157e法规中提及的114条技术需求（网络安全除外），雅析工程团队都提出了解释，并且以如下三种形式落实为实现结果或方案：
1. 控制逻辑实现后的软件SDK
2. 参考系统设计方案（对软件无法实现的部分）
3. 相关控制与状态信号的message定义
***************************
（四）我们雅析的现成解决方案与案例
现在这个高度内卷的时代，产品竞争力来自于对目标实现的快狠准！
为了助力国内自动驾驶开发商顺利嫁接到L3及L3+级别以上的高级自动驾驶领域，甚至成功在1-2年的时间内出口具备L3级以上feature的车辆到欧盟或全世界，雅析工程团队基于我们过去多年的安全实践经验与自动驾驶开发项目参与经验，在针对过往客户的ECE R157e技术咨询需求上，开发并提供了专用的SDK- ASIL D Safety Mode Arbitrator，它具备以下的技术与实现特征：
-
基于符合ISO 26262 SEooC的方式开发
2. 目标针对ASIL D安全完整性等级的自动驾驶应用，可适配于L2+（fail safe architecture）与L3（fail degraded architecture）
3. 软件模块的行为考虑以下设计：ECE R157e定义的系统必须实现行为；SMA模块内部失效与相关安全机制；整车与系统级失效必须采取应对的故障响应措施的安全概念实施；ECE R157e提及关于ISO 21448的必要触发事件（triggering event）响应
4. 这对L3以上应用，考虑了冗余架构（diversified redundancy）部署及相关的安全投票机制的设计，能符合L3级应达成的Fail degraded目标
5. 整个ASIL D SMA模块大小为：141 subsystems/ function calls；C 代行数为13152 LoC
6. 可以适配SOA架构下的与控制器与软件实施，透过ASIL D SMA与应用服务/ 功能服务的调度协作完成L3级别功能与ECE R157e法规的需求
7. 完整工程文档支持工程集成；API设定；参考设计方案……等等
