随着汽车行业电气化智能化的快速发展，功能安全标准ISO 26262逐渐被各大汽车制造企业及零部件供应商重视。近期，《智能网联汽车生产企业及产品准入指南》明确将功能安全和预期功能安全作为汽车制造和生产的准入要求，体现了国家对于汽车安全的重视，功能安全的实施与否已经成为了衡量汽车制造企业及零部件供应商造车能力的关键性指标。 然而，功能安全标准的发布和实施历史并不悠久。根据笔者观察，尤其国内大部分汽车制造和零部件供应商企业，基本从2014年起才开始关注功能安全设计。因此功能安全在国内的发展其实还远未达到成熟期，可以说目前依然处于概念建立期或者快速发展期。 因此，面对日新月异的汽车电子
电气系统的发展，如何正确地理解或者考虑该产品的安全设计给很多同行带来了困惑。 对于一个系统，架构设计通常决定了该系统的整体性能表现，而功能安全标准对架构设计的要求及安全分析方法论引用比较复杂，如何在系统设计之初，合理并充分的考虑其安全设计成为了当前很多同行在做安全设计的一个难点。 笔者从事功能安全领域工作八年有余，有过多家外企合资企业的三电系统，ADAS系统相关产品的安全开发设计经验。此次受SESETECH安全技术论坛幻灵游侠3.0邀请，结合个人经验分享一下对系统安全架构设计的浅薄理解，希望能够解决部分同行对于安全架构设计的痛点。限于个人认知，此文仅供各位同行交流讨论，
不针对任何企业或者产品安全提出设计建议。 内容框架：
安全架构设计必须了解的术语及安全方法说明
E-GAS三层架构的理解及使用约束
安全架构设计必须了解的术语及安全方法说明
在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，而对通讯整体不提安全要求，这种情况下则无需考虑分解，将该控制措施直接按照对应的安全级别实施即可。）
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议