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

在功能安全标准或者一些教学中，经常会提到系统性失效和随机硬件失效两个概念作为电子电气系统的两大失效来源。在安全设计时，我们应当理解，并非所有的失效都能够通过安全机制来诊断或者控制，例如，基于系统层面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，而对通讯整体不提安全要求，这种情况下则无需考虑分解，将该控制措施直接按照对应的安全级别实施即可。）

独立性理解为：

分解后的两个