ADAS系统安全架构设计及安全等级的分解_onebox制动系统功能安全系统架构图

已剪辑自: https://mp.weixin.qq.com/s/PaFQDUR_iOnEeueYQ82m_w

笔者从事功能安全领域工作八年有余，结合个人经验分享一下对系统安全架构设计的理解，希望能够解决部分同行对于安全架构设计的痛点。

注：图片来源于网络，如有侵权，请及时联系作者删除。

➡本文主要内容分为6个部分（约7700字，30分钟阅读）

随着汽车行业电气化智能化的快速发展，功能安全标准ISO 26262逐渐被各大汽车制造企业及零部件供应商重视。近期，《智能网联汽车生产企业及产品准入指南》明确将功能安全和预期功能安全作为汽车制造和生产的准入要求，体现了国家对于汽车安全的重视，功能安全的实施与否已经成为了衡量汽车制造企业及零部件供应商造车能力的关键性指标。

然而，功能安全标准的发布和实施历史并不悠久。根据笔者观察，尤其国内大部分汽车制造和零部件供应商企业，基本从2014年起才开始关注功能安全设计。因此功能安全在国内的发展其实还远未达到成熟期，可以说目前依然处于概念建立期或者快速发展期。

因此，面对日新月异的汽车电子电气系统的发展，如何正确地理解或者考虑该产品的安全设计给很多同行带来了困惑。对于一个系统，架构设计通常决定了该系统的整体性能表现，而功能安全标准对架构设计的要求及安全分析方法论引用比较复杂，如何在系统设计之初，合理并充分的考虑其安全设计成为了当前很多同行在做安全设计的一个难点。

笔者从事功能安全领域工作八年有余，有过多家外企合资企业的三电系统，ADAS系统相关产品的安全开发设计经验。此次受SESETECH安全技术论坛邀请，结合个人经验分享一下对系统安全架构设计的浅薄理解，希望能够解决部分同行对于安全架构设计的痛点。限于个人认知，此文仅供各位同行交流讨论，不针对任何企业或者产品安全提出设计建议。

内容框架：

安全架构设计必须了解的术语及安全方法说明

E-GAS三层架构的理解及使用约束

ADAS系统安全架构设计及安全等级的分解

02 安全架构设计必须了解的

术语及安全方法说明

在ISO 26262的第三部分，第四部分及第九部分，提到了很多关于系统或者相关项的安全术语，包括故障类型判断，安全分解策略，故障控制/避免措施，等。如何正确地理解并应用这些术语及背后的方法论，对于安全架构设计尤为重要。本文主要针对涉及到系统安全架构设计的必要术语进行一些系统性阐述，帮助大家理解其中关系。

故障控制措施（Fault control）

和故障避免措施（Fault avoidance）

在功能安全标准或者一些教学中，经常会提到系统性失效和随机硬件失效两个概念作为电子电气系统的两大失效来源。在安全设计时，我们应当理解，并非所有的失效都能够通过安全机制来诊断或者控制，例如，基于系统层面FMEA或者FTA分析，导出可能违背安全目标的可能失效来源后，需要基于具体的失效原因制定对应的安全措施。

对于某个器件的随机硬件失效或者某个功能的系统性失效，如果可以通过特定安全机制进行诊断或者控制达到安全状态的，我们把这一类安全措施归纳为故障控制措施。(本文提到的故障控制措施包含故障诊断以及容错（fault tolerance）)

对于某个算法或者安全控制逻辑设计如果没有可以采用的安全机制能够对它合理性进行诊断及控制，那么就应该功能实现本身设计为对应的安全等级以对该功能的系统性失效进行覆盖，我们把它归纳为故障避免措施。

需要注意的是，从安全分解的角度，对于故障控制措施的安全需求，我们通常无需考虑进一步分解，对该功能直接进行对应安全级别的设计即可；对于故障避免措施的安全需求，如果有必要，我们才需要考虑进行进一步ASIL分解，进行冗余设计。（本文提到的故障避免措施，仅指代在功能设计时应当考虑的通过符合该功能安全设计流程和方法用于降低故障发生概率，其广泛含义还包含各阶段的安全分析，确认等标准要求的安全活动。）

安全分解（Decomposition）

和分配（Allocation）

对于安全分解和分配，通常在上游安全需求往下游设计细化时考虑。其中，安全分解并非是必须的，而安全分配则是必须的。在考虑安全分解或者分配时，需要有一定程度细化的系统初始架构，包括物理和逻辑架构。结合系统安全分析FTA, FMEA识别的故障控制措施或者故障避免措施，将安全相关的诊断或者控制需求分配到架构元素中去。

进行安全分配和分解考虑时需要注意：

分配最简原则：如果对于某个安全目标或者故障控制措施，能够由系统架构中的一个单独元素完成。则将该安全功能完全分配到该元素中去，并保持该功能元素与其他非安全功能之间的独立性。

分配最后原则：如果对于某个安全目标或者故障控制措施，能够由一条安全关键路径的最后一个元素来实施，那么可以将该安全功能分配到该路径的最后一个元素中去。需要保证该元素对安全需求的实现不受前级输入影响。

分解最大可用性原则：充分利用初始架构中已经存在的冗余元素进行安全需求的分解，而不是去新增新的冗余元素。这里的冗余元素不局限于相同的传感器或者控制器执行机构等，只要两者之间有固定的算法或者合理性关系皆可以考虑构成分解。

分解最简原则：考虑安全分解时，如果实现安全目标或者故障避免措施的诊断或者实施过程比较复杂，那么采用分解策略时，应当采取更为简单有效的安全设计对预期的功能进行分解，并给其分配更高的安全等级，通常推荐QM(X)+X(X)方式进行分解。

冗余（Redundant）

和独立性 (Independent) 设计

基于标准描述，进行安全分解后，需要保证分解后的两个功能具备对上级安全需求的实现的冗余并且完全独立。

冗余理解为：分解后的两个或者多个功能能够分别独立地完成上游安全需求。注意，通常预期功能和其安全机制不能直接构成冗余，除非该安全机制能够完全执行预期功能的安全要求并能独立的控制系统进入安全状态。

例如，MCU的功能控制与外部看门狗不能构成安全分解的关系，因为外部看门狗并不能取代MCU单独的完成所有安全诊断和控制任务；而对于CAN通讯的E2E安全机制可以与CAN总线协议的诊断功能构成安全分解，因为E2E机制可以通过CRC和Rolling Counter覆盖信号传输过程中的信号安全诊断要求，并且独立于CAN总线协议使系统进入安全状态。（E2E诊断要求可以作为安全控制措施成为FSR，而对通讯整体不提安全要求，这种情况下则无需考虑分解，将该控制措施直接按照对应的安全级别实施即可。）

独立性理解为：

分解后的两个或者多个功能之间不存在共同的导致初始安全需求被违背的失效来源或者该类型的失效能够被合理的安全机制覆盖；

注意，标准不仅要求对分解后的安全功能之间做共因失效分析，用于评估安全机制的有效性也需要做分析（预期功能与安全机制之间的独立性）。

要素共存的需要，如果在系统或者软件层面存在不同安全级别或非安全的功能运行在同一块资源区间，则需要保证低安全等级的功能失效不会导致高安全等级的功能失效，或者该失效类型能够被合理的安全机制覆盖。

以上独立性的要求，可以被概括为避免共因失效（Common Cause Failure）和避免级联失效（Cascading Failure）,这两类失效通常由FTA及FFI分析后识别，通过DFA分析才能确认分解后的元素完全独立。

失效安全（Fail safe）

失效静默（Fail silent）

失效运行（Fail operational）

及紧急运行（Emergency operation）

在考虑不同产品的功能失效时，需要基于产品功能的可用性要求，在行业内，经常会有如下几个关于安全架构概念阶段的名词，用于定义产品架构级别的失效属性，从而判断该采取哪一种设计作为安全状态。

失效安全（Fail safe）：是指一个系统失效后特定功能关闭能够让系统维持在安全状态。例如，对于发动机管理系统的避免非预期扭矩输出这个安全目标，可以考虑采用关闭发动机扭矩输出作为安全状态。或者对于L2及以下的自动驾驶系统功能，也通常考虑采用关闭该特定功能作为安全状态。

失效静默（Fail silent）：失效静默类似于失效安全，但是通常理解为系统失效后的一种状态属性，失效静默表示系统失效后对外表现为静默状态，不对其他的功能和输出产生干扰。该词汇用于描述功能失效后的影响，不常用于安全状态定义。

失效运行（Fail operational）：如果一个安全状态无法通过功能关闭来实现，而是要保证系统的可用性，那么就需要选择失效运行作为其安全状态。例如对于L4及以上的自动驾驶系统，如果设计要求系统失效后车辆依然可以按照既定的操作进行自动驾驶，则需要设计一套冗余的控制系统，在主控制系统失效后，Fallback系统能够及时接管车辆在既定的ODD运行。类似失效运行的概念，还有失效降级（fail degraded, fail partial）,通常对于有失效后可用性要求，又不需要完整的冗余接管的系统，例如，对于车辆灯光控制系统的防止近光灯非预期的完全关闭，这个安全目标需要考虑通过双电源和日间行车灯对近光灯的冗余，保证失效后至少有一个近光灯或者日间行车灯对路面进行照明。

紧急运行（Emergency operation）：这个术语不等同于失效运行。紧急运行是指如果安全状态无法在可接受的时间内实现，则需要定义一个紧急操作，让系统在FTTI时间之内能够顺利的过渡到安全状态。这里的安全状态可能是指fail silent或者fail operational。例如，对于L3级别的自动驾驶系统，如果MRC作为系统的安全状态（fail silent）,那么fallback系统的MRM功能则可以定义为紧急运行。

限于篇幅，对于概念和系统阶段其他的术语笔者不作展开，主要阐述在安全架构设计时应当考虑的几个基本点，即：

如何分配安全需求；

如何考虑安全分解；

如何考虑安全状态设计。

在开展具体的安全架构设计时，还需要充分地参考安全标准具体要求。

03 E-GAS三层架构的理解及使用约束

早期从事功能安全的同行对汽油发动机管理系统的E-GAS三层安全架构应该都有了解。虽然该架构并非为实现功能安全而专门设计，但是该架构提供了一个很好的应用安全分解的解决方案。基于目前市场上的类似电控系统设计，该架构基于Lockstep Core设计可以支持到最高ASIL D级别的设计要求。

图3.1-E-GAS三层安全架构带LC示意图

（图片来源参考文献[3]）

对于三层架构，如果运用安全分解策略，我们应该要注意：

a. L2层级的安全控制功能的输入需要独立于L1层级，以保证两者的独立性；

b. L2可以对L1层级的输出信号进行诊断，诊断输出控制应该独立于L1的输出控制，能够直接对系统进行关断控制，以保证安全状态控制的独立性；

c. L2 也可以通过输入信号进行独立的功能诊断，诊断输出控制应该独立于L1的输出控制，能够直接对系统进行关断控制，以保证安全状态控制的独立性。

外部监控设备需要能够独立的对系统进行关断控制而不必依赖于L1或者L2的控制指令，用于避免L1和L2的相关性失效。

在考虑应用E-GAS架构时，对其安全分解策略并无固定要求，但是通常推荐采用QM(X) + X(X)的分解策略。主要考虑：

a. 如果系统功能设计已经比较成熟，而引入功能安全后，对该系统进行功能重构复杂程度高。因此采用QM(X) + X(X)的分解能够让系统设计本身保持QM的等级，而只是对安全要求进行冗余的设计，这样能够最小化的影响功能的稳定性。

b. 系统功能安全需求数量不多，并且该系统能够采用相对简单的策略对故障避免措施进行额外的冗余设计。这样能够最小化地增加开发成本。

c. L2 也可以通过输入信号进行独立的功能诊断，诊断输出控制应该独立于L1的输出控制，能够直接对系统进行关断控制，以保证安全状态控制的独立性。

例如，传统的三电系统，发动机管理系统，变速箱控制系统及车身控制系统皆可以采用上述架构。通过E-GAS三层架构，对安全的功能和系统控制功能进行合理的分解，再配合目前主流的英飞凌AURIX（带Lockstep）+SBC(ASIL D)硬件解决方案，能够高效快速的实现高等级的功能安全设计。除此之外，对于VCU, MCU等新能源汽车上的一些控制器，通过E-GAS三层架构来实现ASIL D等级的设计也是很多主机厂和供应商的优先选择。

需要注意的是，对于一个复杂的新系统开发，或者系统功能安全需求数量大且不易做安全分解的，则不建议首先采用E-GAS三层架构。例如，对于自动驾驶系统的域控制器及备份控制器开发，安全需求除了MCU本身控制功能之外，对于感知，定位和规划算法均有涉及，而SoC和MCU之间很难采取统一的安全监控架构。因此，即使采用E-GAS架构实施安全分解策略后，也需要做大量冗余功能及独立性设计，并不能获得很好的时间或者成本的收益。对于这样的系统，可以考虑直接对安全的功能路径进行对应级别的开发，并做好独立性设计。

给大家的福利

零基础入门

对于从来没有接触过网络安全的同学，我们帮你准备了详细的学习成长路线图。可以说是最科学最系统的学习路线，大家跟着这个大的方向学习准没问题。

同时每个成长路线对应的板块都有配套的视频提供：

因篇幅有限，仅展示部分资料

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！