SoC设计****中功能安全的一个核心是：发现故障并进行上报给一个安全处理单元（FSI或安全MCU过ISO26262认证），然后这个安全单元进行决策怎么进行挽救处理。
当然这个是从系统提供的技术来说，具体的功能安全分析要根据业务去做。按照机制跟策略分离的方法，我们从SoC设计角度出发，提供各种安全机制，就是本文讨论的内容。然后实际操作的时候由专业功能安全人员根据功能安全的需求从技术上有可用的接口，然后再根据业务进行策略设计。
1. 故障上报能力
我们还是以主流的Orin设计介绍，这个上报的安全单元就是安全MCU，是SoC外部的。
安全单元为什么需要在SoC外部搞安全MCU？
安全MCU是传统车上使用很久的东西，例如英飞凌的TCXXX系列，闭源你想集成到SoC那是不可能的，除非英飞凌自己搞个SoC。SoC的技术则是从手机上学来的，走的arm高通的开源路子，很容易攒出来，但是没有经历过太多实战考验，需要一定的时间来做到传统的安全MCU。这只是其中一方面，硬件独立的安全MCU本身就有天然的安全特性。
1.1 SoC上报给安全MCU
上报给安全MCU的故障分为两类：
主动上报：（FSI汇总SoC内部的故障信息通过SPI、PIN上报给安全MCU）
被动上报：（FSI的心跳机制给安全MCU上报，或者卡死时停止响应安全MCU，安全MCU去做业务时发现）
发生故障时也可能通路故障了，例如SPI需要协议的这种，那就通过PIN（GPIO）来做兜底的上报。
为了安全，FSI跟安全MCU的SPI通信也需要加强：
从软件上需要增加数据包CRC校验
从硬件上需要增加GPIO，发送SPI数据前需要拉GPIO，对方感知到要做SPI业务且对方准备好了才开始回复进行下一步通信。
为了安全，PIN也需要一次使用两根且电平相反连接，因为PIN可能受到电磁干扰或者开路短路故障。
1.2 SoC内部各IP上报给FSI汇总
故障的种类分为：
软件故障（通过软件通路上报，SoC内部的核间通信技术）
硬件故障（FSI中的FCCU监测到的硬件故障通过SOC_ERROR引脚触发FCCU中断进行处理，然后FCCU将错误通过软件通知到外部安全MCU监视器，再进行功能安全处理。FCCU可以通过NOC总线跟其他IP通信）
FCCU本来就是FSI的硬件，有些严重的故障例如电压异常/高温等，会不经过FSI的软件处理直接上报给安全MCU。大多数的硬件故障会先触发FSI的中断，然后由FSI的软件去进一步处理。
2. 故障分类及常见处理
对于FSI搜集的故障，要进行处理的时候，需要进行分类：
普通故障（各种wdt超时、exception、assert、通信故障、存储故障、机制失效等）
致命故障（高温、高压、SoC损坏）
对于处理要看业务那些重要就归为致命故障，重点还是要保障业务，比如SoC主要做图像识别，那摄像头、信号传输及处理（NPU、ISP等）这一条通路上的IP的优先级都是非常高，必要的时候甚至可以按致命重启整个SoC来恢复。
对于普通故障：
FSI运行正常时，通过SPI上报给安全MCU。举几个例子：A核硬件例如STL检查失败ECC故障等，这时A核的硬件已经损坏无法满足一些业务，例如在汽车上不能自动驾驶了，那么通过SPI上报给安全MCU，安全MCU进行刹车限速提示驾驶员接管方向盘自己开，对于SoC可以进行重启恢复。同理A核的软件异常，其他核的软硬件异常也是一样的。
FSI的异常时（硬件R核异常、软件exception或看门狗超时），这时候不能通过SPI协议上报了，只能通过硬件的PIN进行上报安全MCU。安全MCU还做出相关的业务措施来保证人员的安全。
FSI的SPI控制器异常时，这时也不能SPI通信了，也是通过PIN进行上报安全MCU
各种IP的WDT看门狗触发的异常，一般把看门狗分为两级，第一级的时候尝试自己恢复，自己恢复不了再触发第二级就需要上报了。
3. 防止故障的一些保护措施
3.1 寄存器保护
寄存器的值需要保持正确性，为了防止某些寄存器的值改变，可以使用冗余、ECC/CRC校验、周期回读等策略保证值的正确
寄存器需要防止误操作，我们在写代码时可能会误操作别的模块的寄存器，这样就需要加一个lock寄存器，这样就会防止误操作的错误，需要操作的时候需要明文规定unlock。
3.2 看门狗
两级看门狗，第一级的时候尝试自己恢复，自己恢复不了再触发第二级就需要上报了。
3.3 复位
这个可以和看门狗配合使用，IP有复位自己的能力。
3.4 时钟保护
只在系统启动时使用外部晶振，之后需要使用PLL，再经过CRU输出给各个IP。对于FSI比较重要，可以单独使用一个外部晶振进行隔离保护。还有其他一些监测保护措施。
3.5 电源保护
对电压进行检测并异常上报。
3.6 IST
In-System-Test涉及执行结构化的ATPG（自动测试模式生成）向量，即确定性扫描压缩和逻辑内建自测试（LBIST），以及在钥匙开启和/或关闭期间执行一组全面的MBIST（存储器内建自测试）算法，以确定通过或失败状态。IST可以覆盖适用于较低几何FinFET技术的所有故障模型。挑战在于将这些向量的执行转化为一个完全独立的功能特性，该特性可以在汽车系统的整个使用寿命中反复使用，同时满足测试时间和功率预算的要求。
IST架构的主要目标可以分为以下几类：
•高品质测试**：** 为了达到最高的ASIL安全级别，被测设计（DUT）需要具有非常高的永久性测试覆盖率。期望测试支持一套全面的故障模型，以便检测较低几何FinFET设计中的缺陷。
•低延迟**：** 高品质测试模式是通过最短可能的测试时间和小巧的测试数据量实现的最高测试覆盖率来衡量的。
•架构灵活性**：** 架构应完全可扩展，以适应不同的时钟频率和数据速率，满足功率、存储和延迟要求。它还应该支持不同的设计配置。
•TDP（热设计功率）预算**：** 需要确保在IST执行过程中保持在功能性TDP的限制范围内。
•调试和诊断**：** 架构应支持所有模式的调试和诊断，并为现场返回提供可追溯性。参考：https://www.ctfiot.com/152148.html
3.7 STL
汽车的功能安全标准，如ISO26262，要求使用硬件和软件技术对潜在的故障进行现场测试。基于**软件自检（SBST）的软件测试库（STL）**是一种灵活的潜伏故障测试解决方案，可替代基于可测试性设计（DfT）特征的硬件方法。STL可以被集成到任务操作系统中，并在空闲时间定期执行。
然而，在为基于多核处理器的人工智能芯片开发STL时，彻底优化故障分级过程和用适当的软件模块管理STL的执行是至关重要的。
3.8 efuse保护
对应一些数据需要做双重备份。
3.9 增加调试手段
这个存在于整个生命流程中，主要有：
debug：可以支持exception打印，串口打印，JTAG中断调试等，gdb支持等手段
trace：更高级的CPU控制流状态跟踪
monitor：监控是否有故障
ramdump：把log保存下来，利于出问题时分析
接口测试：对各种IP的接口进行命令健壮性测试
3.10 编译器功能安全
程序需要安全，除了代码就是编译器可以决定。编译器作为影响程序安全性非常重要的因素。一些好的编译器都是商用的，免费的也就是gcc。
针对不同行业标准要求，国内在安全关键领域的编译器主要有两种解决方案：
一是直接向国外购买被这些领域高度认可的编译器，这些编译器均有相关行业标准的认证，无论是在安全性还是在各类优化方面都很有代表性，如Absint公司经过形式化验证的CompCert编译器、风河公司Diab编译器等。
另一来源是获得业界认可的开源编译器，如GCC和LLVM，通过对其限定或改造（如关闭某些优化选项、限定版本、改造前端对语言特性进行约束、增加某些静态检查功能、以及插入运行时检查代码，等等）来适应行业内部的安全性需求。
CompCert**：通过形式化验证的编译器绝对安全可靠？**
CompCert是一个高度可信的C语言编译器。CompCert提供了数学证明机制，以验证编译生成的代码与源代码之间的正确性。该编译器被认为是目前最可靠的C语言编译器之一，其代码生成质量和正确性已经得到了广泛的验证和认可。
尽管CompCert是一个开源项目，但它并不是免费的。其开源许可证允许用户查看和研究代码，但商业使用需要购买商业许可。详细的许可信息可以在CompCert官方网站上找到。https://compcert.org/publi.html
综上，就是对SoC内部所有的IP进行安全分析加强，主打一个为了安全不差钱。
后记：
今年以来工作比较忙，更新的也比较少，但是我又回来了，继续高质量免费分享程序员的奇怪知识。
之前功能安全的都快写不下去了，本人是软件程序员，对底层技术有些兴趣，这个功能安全算是软硬结合吧，大部分是自己不擅长的。文中具体到每一个小的知识点，在硬件或者专业的功能安全看来都是巨大的一堆技术和方案，这里算是科普吧，具体的设计可能多种技术一块用或者根据场景进行取舍。
本篇作为功能安全入门的结束，希望对广大程序员在知识面上得到扩展，遇到相关问题的时候可以多一些思考。
“啥都懂一点，啥都不精通，
干啥都能干，干啥啥不是，
专业入门劝退，堪称程序员杂家”。
欢迎各位有自己公众号的留言：申请转载！
纯干货持续更新，欢迎分享给朋友、点赞、收藏、在看、划线和评论交流！
公众号：“那路谈OS与SoC嵌入式软件”，欢迎关注！
个人文章汇总：https://thatway1989.github.io
