浅谈系统安全架构设计，从零基础到精通，收藏这篇就够了！

Python_chichi

于 2025-04-30 15:14:34 发布

阅读量722

点赞数 10

文章标签：系统安全安全网络安全 web安全

本文链接：https://blog.csdn.net/Javachichi/article/details/147633483

版权

引言：安全架构，是花架子还是真功夫？

各位同行，摸爬滚打网络安全这行当也有些年头了。眼瞅着汽车行业这几年“触网”越来越深，功能安全标准ISO 26262也成了香饽饽。最近，国家也开始强调智能网联汽车的安全准入，这架势，功能安全搞不好，车都卖不出去！

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

但问题来了，这玩意儿真正落地，难啊！尤其国内，很多企业还在摸着石头过河。系统安全架构设计，听着高大上，实际操作起来，一堆坑。架构设计的好坏，直接决定了系统的安全性。但功能安全标准那套东西，又臭又长，理解起来费劲。所以，今天就来聊聊我对系统安全架构设计的理解，希望能帮大家少踩点坑。

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

01	抛砖引玉：安全架构，没你想的那么简单
02	安全架构设计：那些“不说人话”的术语，得掰开了揉碎了讲
03	E-GAS三层架构：经典案例，但别迷信
04	ADAS系统安全架构：安全等级分解，到底怎么玩？
05	总结：安全这事儿，没有银弹
06	参考文献

抛砖引玉：安全架构，没你想的那么简单

说实话，国内真正重视功能安全设计，也就这几年的事儿。很多企业都是从2014年才开始关注，起步晚，底子薄。现在汽车电子电气系统发展速度飞快，安全设计跟不上，就容易出问题。

系统安全架构设计，是整个安全体系的基石。但功能安全标准的要求，那是相当复杂。如何在系统设计之初，就充分考虑安全因素，成了很多人的难题。

我个人在功能安全领域摸爬滚打了八年多，在外企、合资企业都干过，三电系统、ADAS系统都搞过。这次受邀来分享，就是想结合自己的经验，跟大家聊聊系统安全架构设计。当然，我水平有限，说的也不一定对，大家就当是交流讨论，别太当真。

内容框架：

安全架构设计：那些“不说人话”的术语，得掰开了揉碎了讲

E-GAS三层架构：经典案例，但别迷信

ADAS系统安全架构：安全等级分解，到底怎么玩？

安全架构设计：那些“不说人话”的术语，得掰开了揉碎了讲

ISO 26262标准，第三、四、九部分，一堆安全术语，什么故障类型、安全分解、故障控制/避免措施……看得人头大。但这些术语，是安全架构设计的核心。理解不透，设计就没法做。所以，咱们今天就来系统性地梳理一下这些术语，看看它们之间到底是什么关系。

故障控制措施（Fault control）VS 故障避免措施（Fault avoidance）：别把所有鸡蛋放一个篮子里

功能安全标准里，经常提到系统性失效和随机硬件失效，说这是电子电气系统的两大失效来源。但记住，不是所有失效都能靠安全机制来解决。得先做FMEA、FTA分析，找出可能违背安全目标的失效来源，然后才能制定对应的安全措施。

如果某个器件的随机硬件失效，或者某个功能的系统性失效，能通过安全机制诊断或者控制，达到安全状态，那这种安全措施就是故障控制措施。

但如果某个算法或者安全控制逻辑，没法用安全机制来诊断和控制，那就得在功能实现本身上下功夫，提高安全等级，覆盖系统性失效。这种就叫故障避免措施。

这里有个关键点：故障控制措施的安全需求，通常不用再分解了，直接按对应安全级别设计就行。但故障避免措施的安全需求，如果需要，可以进一步ASIL分解，做冗余设计。

安全分解（Decomposition）VS 分配（Allocation）：不是你想分，想分就能分

安全分解和分配，通常是在上游安全需求往下游设计细化时考虑的。分配是必须的，但分解不是。在考虑分解或分配时，得先有个大概的系统架构，包括物理和逻辑架构。然后结合FTA、FMEA等安全分析，将安全相关的诊断或控制需求分配到架构元素中。

分配和分解，有几个原则要记住：

分配最简原则： 能一个元素搞定的，就别分给多个。
分配最后原则： 能由安全关键路径的最后一个元素实施的，就分配给它。
分解最大可用性原则： 充分利用现有冗余元素，别没事找事新增冗余。
分解最简原则： 诊断或实施过程复杂的，就采取更简单有效的安全设计，给它分配更高的安全等级。

冗余（Redundant）VS 独立性 (Independent) 设计：鸡蛋不能放在同一个篮子里，篮子还得是独立的

安全分解后，得保证分解后的功能，既冗余又独立。

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

独立性，是指分解后的功能之间，不存在共同的失效来源，或者失效能被合理的安全机制覆盖。

独立性，就是要避免共因失效和级联失效。这两种失效，通常要通过FTA、FFI分析来识别，然后通过DFA分析来确认分解后的元素完全独立。

失效安全（Fail safe）、失效静默（Fail silent）、失效运行（Fail operational）VS 紧急运行（Emergency operation）：安全状态，不是你想选哪个就选哪个

考虑产品功能失效时，要根据产品功能的可用性要求，选择合适的失效属性，从而确定安全状态。

失效安全（Fail safe）： 系统失效后，特定功能关闭，系统维持在安全状态。
失效静默（Fail silent）： 系统失效后，对外表现为静默状态，不干扰其他功能。
失效运行（Fail operational）： 系统失效后，仍然能按照既定操作进行。
紧急运行（Emergency operation）： 安全状态无法在可接受时间内实现时，让系统在FTTI时间内过渡到安全状态。

总而言之，安全架构设计，要考虑：

如何分配安全需求？
如何考虑安全分解？
如何考虑安全状态设计？

当然，具体设计时，还得参考安全标准的具体要求。

E-GAS三层架构：经典案例，但别迷信

搞功能安全的，应该都知道汽油发动机管理系统的E-GAS三层安全架构。这架构虽然不是专门为功能安全设计的，但它提供了一个很好的安全分解解决方案。基于Lockstep Core设计，可以支持到最高ASIL D级别。

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

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

用三层架构做安全分解，要注意：

L2层级的安全控制功能输入，要独立于L1层级，保证独立性。
L2可以对L1层级的输出信号进行诊断，诊断输出控制要独立于L1的输出控制，直接对系统进行关断控制，保证安全状态控制的独立性。
L2也可以通过输入信号进行独立的功能诊断，诊断输出控制要独立于L1的输出控制，直接对系统进行关断控制，保证安全状态控制的独立性。
外部监控设备，要能独立地对系统进行关断控制，不依赖L1或L2的控制指令，避免相关性失效。

E-GAS架构的安全分解策略，没有固定要求，但通常推荐QM(X) + X(X)的分解策略。原因很简单：

系统功能设计已经比较成熟，重构复杂程度高。
系统功能安全需求不多，且能用相对简单的策略做冗余设计。

所以，传统的三电系统、发动机管理系统、变速箱控制系统、车身控制系统，都可以用E-GAS架构。配合英飞凌AURIX（带Lockstep）+SBC(ASIL D)硬件解决方案，能快速实现高等级的功能安全设计。VCU、MCU等新能源汽车控制器，也经常用E-GAS架构来实现ASIL D等级设计。

但要注意，对于复杂的新系统，或者安全需求多且不易分解的，不建议直接用E-GAS三层架构。比如，自动驾驶系统的域控制器和备份控制器，安全需求除了MCU控制功能，还涉及感知、定位和规划算法。SoC和MCU之间，很难采取统一的安全监控架构。即使用了E-GAS架构，也需要做大量冗余功能和独立性设计，成本太高。这种系统，可以考虑直接对安全的功能路径进行对应级别的开发，做好独立性设计就行。

ADAS系统安全架构设计：安全等级分解，到底怎么玩？

设计ADAS系统的安全架构，首先要确定系统的自动驾驶等级，这决定了系统的安全状态。参考SAE J3016定义：

图4.1-SAE J3016自动驾驶功能等级定义

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

SAE LEVEL 2及以下的ADAS功能，驾驶员要时刻监督系统运行，保证驾驶安全。这种系统，可以考虑失效静默架构，系统失效时，关闭功能就行。

但SAE LEVEL 3级别的ADAS功能，系统失效后，仍然需要在一定时间内（通常10秒以上），正确执行DDT，或者进行功能降级运行。这种系统，需要设计紧急操作或失效运行功能（L4及以上）。主控制器失效后，备份系统至少要在规定时间内保持动态驾驶任务，并提示驾驶员接管。

SAE并没有要求自动驾驶系统必须做完全的失效运行，只要求接管系统在失效时，能在一定时间内让车辆到达最小风险状态。所以，设计ADAS架构时，不一定需要考虑系统失效时还能执行完整DDT的能力，只需要考虑接管系统是否有能力通过功能降级，以及驾驶员未接管后由紧急运行使车辆达到最小风险状态即可。

L3及以上级别自动驾驶系统安全等级评估：别一上来就ASIL D

高安全等级的自动驾驶系统，允许驾驶员脱眼或脱手。评估功能安全目标时，部分危害事件S、E、C会评定为最高分，得到ASIL D级别的安全目标。安全目标被违背时，系统又无法通过功能静默直接进入安全状态，控制信号的可用性设计也会要求满足ASIL D。

现在市场上，ADAS系统设计五花八门，但整体的功能安全目标和最高级别，通常都是ASIL D。为了实现最小成本的解决方案，需要在满足安全要求的前提下，尽量简化系统设计。建议基于SAE标准下的系统架构要素，分解功能安全需求。比如，将fallback系统与Main系统进行冗余，将控制指令可用性失效需求分解由fallback和Main系统实现，考虑两者之间的独立性设计，可以将部分的安全指标降级。下面用一个抽象的ADAS系统架构，来描述功能安全ASILD级别在架构上的分解和分配关系。

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

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

假设ADAS系统的整体安全目标简化为：

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

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

Main 系统需要提供正确的横向和纵向控制指令ASIL B（D）
Fallback 系统需要提供正确的横向和纵向控制指令ASIL B（D）
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分析：

Fallback系统的失效造成严重度与Main系统失效相同（S3）;
Fallback系统失效后可控度与Main系统失效相同（C3）；
评估暴露度时，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系统设计，还没有一个权威且受认可的方案，以上分析和见解仅供参考。

总结：安全这事儿，没有银弹

本文基于ISO 26262标准的定义，结合当前汽车零部件供应商和主机厂的功能安全架构设计实践，以及我个人的经验，对功能安全产品架构设计进行了一些描述。希望能解答大家的一些疑惑和难点。

```