浅谈系统安全架构设计

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

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

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

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

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

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

独立性理解为：

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

如何分配安全需求；

如何考虑安全分解；

如何考虑安全状态设计。

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

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

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

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

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

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

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

当前市场上ADAS系统的设计有很多，各家都在自研架构，但是整体的功能安全目标及最高级别通常均为ASIL D。为了实现最小成本的解决方案，我们需要从系统架构层级，在满足安全要求的前提下尽量简化系统的设计。因此建议在基于SAE标准下的系统架构要素，用于功能安全需求的分解。例如，将fallback系统与Main系统进行冗余，将控制指令可用性失效需求分解由fallback和Main系统实现，考虑两者之间的独立性设计，及可以将部分的安全指标降级。本文将引入一个抽象的ADAS系统架构，用于描述功能安全ASILD级别在架构上的分解及分配关系。假设该ADAS架构抽象为如下图：

图4.2-L3+ADAS自动驾驶系统抽象架构

注意：在图4.2 架构中，为实现ADAS域控制指令的独立性，实现安全分解，将ADAS指令仲裁功能分配给底盘动力域控制器。在实际项目中，指令仲裁功能也可能由ADAS Main控制器实现，通过一定的机制实现自动指令转换，基于此结构，运动域控可以不需要；另外指令仲裁功能也可以集成在底盘域控系统中。对于执行器端的冗余设计，可以基于不同的ADAS功能和安全降级的要求进行必要冗余，而非横纵向完全冗余。执行器端具体方案在本文不做详细展开。

防止非预期的不能提供控制指令，ASIL D：

基于图4.2，Fallback系统作为Main系统的冗余系统，通过完全的冗余和独立可以将安全指令的可用性需求分解为ASIL B（D）即：

1. Main 系统需要提供正确的横向和纵向控制指令ASIL B（D）

2. Fallback 系统需要提供正确的横向和纵向控制指令ASIL B（D）

3. Main 系统和Fallback系统的控制指令需要完全独立 ASIL D（独立性要求）

需要注意的是，Fallback和Main控制器需要”热冗余”。热冗余是指在Main运行过程中，Fallback也应当同时运行，主要用于减少主控制器失效时指令切换的时间。同时，从安全角度，两者对自身失效进行诊断以防止非预期的失效导致自身控制指令不可用，无论哪个控制器诊断出自身失效，ADAS系统需要在一次驾驶循环内进行MRM或者不允许ADAS功能下次激活

防止非预期的发出错误控制指令，ASIL D

基于图4.2，由于ADAS系统运行时主要由Main系统进行仲裁及整车控制，因此对于Main系统，其安全诊断级别应当做到ASIL D。

由于 Fallback的整车接管控制在Main失效后才会启动。因此，在考虑Fallback系统安全级别时，可以从如下角度考虑适度降低：

例如，如果我们定义SAE ADAS L4系统,在主系统失效后，Fallback系统接管后最大有效运行时间为1小时,  对Fallback接管功能做HARA分析：

1. Fallback系统的失效造成严重度与Main系统失效相同 （S3）;

2. Fallback系统失效后可控度与Main系统失效相同 （C3）；

3. 在评估暴露度时，基于Fallback功能控车总共时长不超过1小时，相比较Main系统失效场景暴露度E，可以降低其指标，分析过程如下表：

表4.1-1 Fallback系统暴露度指标评估参考

➡发生永久性故障后接管系统的最大操作时间： 假定在最坏情况下，Main控制器在其操作时间内失效。

➡假定系统运行过程由于瞬态切换而累积的接管操作持续时间：假定主系统由于系统性原因或者SOTIF影响短暂切换到Fallback系统，恢复后退回Main控制器。考虑在1000小时的ADAS操作时间内，每小时切换3s。

基于以上分析，我们可以看到，对于fallback系统，其实际的operation time只占ADAS系统operation time不到1%， 因此，可以将其E值由E4降为E2。 继而，对Fallback系统发出错误的控制指令ASIL级别由ASIL D降为 ASIL B。 

备注：1. 以上分析假定的前提为Main控制器与Fallback控制器完全独立，其指令仲裁在底盘系统中实施；2. HARA分析中对暴露度E值的评估方法与本文提及的降低策略有偏差，从本文的角度，实际上基于产品Operation time定义来降解，更多的是从降低随机硬件失效概率。对于Fallback控制器系统性失效，很多同行会认为需要按照原始等级（ASIL D）来实施。该分析仅做参考。

基于以上两点，可以简单总结ADAS系统的安全概念：  

FSR-1: 在ADAS系统运行过程中，如果Fallback控制器诊断出自身失效，导致无法发出控制指令，Main控制器应当基于Fallback状态，控制系统运行一段时间或者进入MRC*。ASIL B(D) （FSR a，可用性设计，*这里也可以考虑在一个驾驶循环内持续进行DDT）; 

FSR-2: 在ADAS系统运行过程中，如果Main控制器诊断出自身失效，导致无法发出控制指令，Fallback控制器应当基于当前失效状态，控制系统运行或者降级一段时间或者紧急操作进入MRC。ASIL B(D) （FSR a，可用性设计）; 

FSR-3: Main控制器应当监控并正确的发出横纵向控制指令，如果Main控制器失效导致无法发出正确的控制指令，Main控制器应当关闭控制输出。ASIL D（FSR b, 防止提供错误的控制指令)；

FSR-4: Fallback系统在进行紧急操作或者接管系统驾驶任务过程中，如果Fallback系统监测到自身失效，导致无法发出正确的控制指令，则应当停止发送控制指令 ASIL B (FSR b， 防止提供错误的控制指令)。

由于目前行业内ADAS系统设计，国内外还没有一个权威且受认可的方案，因此以上分析及见解仅作为参考。