目录
1. Safety和Security
2.SMU概述
2.1 为什么设计SMU
2.2 SMU整体框架
2.3 SMU Alarm配置
2.4 SMU状态机
3.小结
1. Safety和Security
SMU是英飞凌TC3xx系列功能安全架构里最重要的组成部分，用于管理MCU故障状态下的行为。
但在聊SMU之前，我们有必要搞清楚Safety和Security分别指的什么？
虽然从字面看二者都有“安全”之意，但是它们关注的范畴和方向不是一样。
- Safety：功能安全，参考标准ISO26262、ISO21448；目的是尽量减少因系统设计问题导致的功能失效，同时也尽量保证功能按照预期功能实现，从而保证人财的安全；
- Security：信息安全，参考标准ISO21434、SAE J3061；目的是保护车辆和车内设备免受恶意攻击和未经授权的访问，如防止车辆被盗、防止车载系统被黑客入侵、确保车辆数据的机密性和完整性等；
- 虽然Safety和Security有各自的重点和侧重点，但它们的共同目标都是保护车辆、乘员和其他道路使用者的安全；同时二者关系也非常紧密，例如车辆的信息系统受到黑客攻击或恶意软件感染，可能会导致车辆失去控制、系统故障或其他安全问题，从而危及车辆和乘员的安全。
而针对Security和Safety，TC3xx分别设计了HSM子系统和FUSA架构（包含SMU）来满足需求，如下图：
所以，今天我们就先聊聊SMU。
2.SMU概述
2.1 为什么设计SMU
MCU一般由内核子系统、系统管理子系统、外设子系统、电源子系统等等组成；
在设计时每个子系统不可能保证完全没有bug，也不能保证芯片在运行过程中不会出现随机硬件失效（例如ECC，位反转等）；
针对系统失效：可以通过持续和严格的过程改进来尽量避免：
针对随机硬件失效：可以通过工艺设计预防、引入功能安全机制来探测和缓解；
如下：
在TC3xx里，每个功能安全机制都会产生一个名叫“SMU alarm”的信号；
试想，这么多的alarm如何管理？常规思路肯定是放到一个模块中来进行处理，为此SMU(Safety Management Unit)诞生了。
2.2 SMU整体框架
在TC3xx中，SMU的框架路径如下图：
当功能安全机制探测到失效后，会产生SMU alarm事件（可以是脉冲也可以是电平）给到SMU，SMU根据用于预定义配置触发相应行为，具体如下：
- alarm在MCU内部行为：
- 向CPUs发起中断请求
- 产生NMI
- 向CPUs发起CPU复位请求
- 向SCU发起系统\应用复位请求
- 向外部通知错误状态行为：
- 通过ErrorPin（P 33.8和P21.2，一般用P33.8连接35584）
当然一个alarm可以同时选择使用内部和外部行为。
进一步，SMU内部又分为了SMU_Core和SMU_Standby，如下图：
特点如下：
- SMU_core/stdby处于不同的时钟域和电源域
- SMU_core 处理绝大部分alarms 与SCU\RCU\IR\CPUx交互
- SMU_stdby 处理clock、power、温度等alarm
- 处理SMU_core_alive alarm
- 提供SMU self-test功能
2.3 SMU Alarm配置
在TC3xx里Alarm以Group形式进行分组，在39x的手册里可以看到多达14组Alarm Group，每个alarm都有对应的功能安全机制，如下：
那么我们应该如何来配置alarm？敲重点了，根据内部行为和外部行为分别配置不同的寄存器，如下图：
以配置ALM1[0]（第1组第0个功能安全机制）为例：
每个Alarm group有三个配置寄存器，AGi(0-11)CFj(0-2)， 每个配置寄存器CF0-31表示对应机制，功能安全机制0-31；
如AG1CF0.CF0，对应group ALM[1] Configuration0中的CF0 以此类推 ；
而相应alarm的behavior由这三个寄存器相应位共同决定：
而内部行为的配置码如下：
如果现在我们想把行为配置为SMU_RESET，那么对应AGCF寄存器就应该配置如下：
AGCF[1][0].CF0 =0
AGCF[1][1].CF0 =1
AGCF[1][2].CF0 =1如果还想通过FSP向外报告MCU内存错误状态，就需要配置AGiFSP：AGFSP[1].FE0 = 1，如下图：
2.4 SMU状态机
SMU不是随时都会产生相应行为的，只有它进入RUN状态，才会处理alarm并触发相应行为；根据芯片手册，自身定义的状态机如下
3.小结
本文主要描述了SMU的设计初衷，以及配置方法，但没有讲FSP的使用方法，因为在其官方推荐中它是要与TLF35584搭配使用，之前有相关文章进行描述，大家有兴趣可以回溯一下。
