浅谈系统安全架构设计
浅谈系统安全架构设计
笔者从事功能安全领域工作八年有余，结合个人经验分享一下对系统安全架构设计的理解，希望能够解决部分同行对于安全架构设计的痛点。
注：图片来源于网络，如有侵权，请及时联系作者删除。
➡本文主要内容分为6个部分（约7700字，30分钟阅读）
中国劳动力市场01 | 本文概述 |
02 | 爱你一生不后悔安全架构设计必须了解的术语及安全方法说明 | 如何关闭微信朋友圈
03 | E-GAS三层架构的理解及使用约束 |
04 | ADAS系统安全架构设计及安全等级的分解 |
05 | 总结 |
06 | 参考文献 |
| |
01
本文概述
随着汽车行业电气化智能化的快速发展，功能安全标准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 Cau 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）,通常对于有失效后可用性要求，又不需要完整的冗余接管的系统，例如，对于车辆灯光控制系统的防止近光灯非预期的完全关闭，这个安全目标需要考虑通过双电源和日间行车灯对近光灯的冗余，保证失效后至少有一个近光灯或者日间行车灯对路面进行照明。
