功能安全软件架构_软件安全架构(1)，渣本逆袭大厂面经分享

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

（2） Level2 功能监控层

Level2 是功能监控层，用于监控 Level1 功能的运行是否正常。Level2 的核心是设计一套方法去判断Level1 的运行是否正常。虽然判断 Level1 运行是否正常的方法，往往跟被监控的功能相关，不同被监控功能有不同的判定方法，比如 : 通过软件多样化冗余。但也有一些适用范围较广的判断方法，比如合理性校验。

图3 合理性检查

如上图 所示，Level2 在使用合理性校验方法判断 Level1 功能是否正常运行时，先根据传感器输入的信号，计算控制量允许输出的合理范围，再计算从执行器反馈的实际输出量，最后判定 Level1 的实际输出量是否在允许的合理范围，如果超出了合理的范围，则判定 Level1 功能异常，执行错误处理。

（3） Level3 控制器监控层

Level3 是控制器监控层，主要由三部分功能构成。

电子电气系统硬件诊断：监控电子电气系统硬件故障，比如 : 控制器的 CPU 核故障、RAM 故障、ROM 故障等。

独立监控：控制器相关的故障发生后，此时控制器已经无法可靠地执行安全相关逻辑，为了保证安全性，需要外部额外的独立监控模块，来确保即使 MCU 发生严重故障后，依然能够进入安全状态。这个额外的独立监控模块，通常是集成看门狗的电源管理芯片。

应用程序流检查：监控 Level1 和 Level2 的监控程序是否运行正常。该监控功能通过将程序流检查和看门狗喂狗绑定实现。如果 Level1 和 Level2 相关的监控程序没有按照设定的顺序运行，或者没有在规定的时间内执行，则程序流检查失败，无法正常喂狗，从而进入系统安全状态。

2. 国外功能安全软件架构发展情况

提到功能安全与软件架构，我们可以从 “符合功能安全的软件架构” 和 “功能安全软件架构” 这两个维度去看待它们之间的关系。

前者侧重点是从软件开发角度看我们的软件架构设计过程对功能安全的符合性，也就是我们的软件架构设计过程需要满足 ISO 26262 提出的各种要求，如：标记方法、设计原则、设计要素要求、安全分析要求、错误探测机制要求、错误处理机制以及设计验证方法等，其中，软件架构层面的安全分析主流手段是“软件 FMEA（Failure Mode and Effects Analysis）” 和 “软件 DFA（Dependent Failure Analysis）” 。

后者侧重点是从嵌入式软件系统角度看对系统级功能安全的支撑。基于 E-Gas 安全架构的思想，我们认为 “分层监视思想” 、“安全措施” 和 “诊断框架” 是 “功能安全软件架构” 的核心，“分层监视思想”和 “安全措施” 在上文有说明，本节接下来内容主要围绕 “诊断框架” 进行说明。无论我们使用的基础软件开发平台是 AUTOSAR CP、AP 或者是非 AUTOSAR，功能安全软件架的设计思路是类似的，这里基于 AUTOSAR CP 进行说明。

**1） 功能安全诊断框架技术要求

**

图5 故障响应时间和容错时间间隔

我们结合 FTTI（故障容忍时间间隔，fault tolerant time interval）理解故障诊断过程。从故障发生到产生可能危害之间的这段时间就是 FTTI 时间，此期间主要有诊断测试、故障响应过程，并且希望在产生可能危害之前进入安全状态 ( 图 4.1-8)。诊断测试过程需要考虑诊断测试触发、故障确认（去抖）等，
故障响应过程需要考虑进入合理的操作模式（如：Fail safe, Fail operational, Emergency operation 等）、故障存储等。

综上，“诊断框架” 的核心设计需要考虑覆盖诊断测试、故障响应过程。主要的功能安全诊断框架技术要求有：

• 故障统一管理：对 E-GAS 多层监视框架各故障监视层上报的故障进行状态统一管理
• 故障响应时间要求：故障检出到进入安全状态需满足故障容忍时间间隔（FTTI）的要求
• 独立性要求：片上安全机制与功能存在共因问题，需支持独立性监视（MCU 片外监视）
• 多样化要求：软件架构须满足框架设计通用化和支持安全策略多样化（不同项目对安全机制有不同要求）
• 诊断测试时机：上下电，周期，条件触发等
• 故障去抖 / 延时检查：需支持安全机制的去抖测试功能，至少支持基于时间和基于计数去抖算法
• 诊断事件和功能解耦：诊断事件和功能独立管理，之间存在映射关系
• 故障存储：支持故障信息非易失存储

2） 国外诊断框架技术情况解读

在对诊断框架技术展开解读之前，有两个方面的建议供参考。

① 建议 1：根据需求确定诊断测试的时机

a. 上电时：这里结合一个典型应用需求进行说明。安全机制（safety mechanism）和对应的功能构成了双点，为了降低潜伏多点故障失效率，一般在系统启动阶段（上电时），安全机制需要做自检。此外，在多处理器系统中还需要考虑诊断测试同步问题。

b. 运行时：一般分周期性诊断测试和条件诊断测试。诊断周期的定义需要考虑 FDTI（fault detection time interval）的约束，而条件诊断测试一般是发生状态迁移时或在激活某个功能前对功能进行的诊断。

c. 下电时：可以选择执行一些比较耗时的测试，而测试结果一般放在下一次启动时处理。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注网络安全）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

-1713226387897)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！