目录

1.TLF35584安全状态输出响应对象

1.1 响应ERR 收集到的错误信号

1.2 响应监控功能引发的ROT

1.3 响应看门狗引发的错误

1.4 环境过温引发的错误状态

1.5 为什么设计SSx？

2. 安全状态输出给谁 

3.小结

---

在之前文章里，我们简述了TC3xx SMU如何与PMIC TLF35584协同工作，并且主要从datasheet推荐的应用连接分析了功能安全方面的实现机制，如下图：

但是仍然遗漏了一个关键点，从ECU级别来看，35584的SS1\2到底可以输出给谁？ 

1.TLF35584安全状态输出响应对象

那么首先，我们来看SS1\2可以输出哪些状态？根据DataSheet，SS1\2根据不同错误状态会产生输出波形，具体如下：

1.1 响应ERR 收集到的错误信号

该错误信号，一般由TC3xx SMU模块的error pin根据FSP协议输出，35584通过ERR pin这个引脚收集。

当检测到波形异常后，35584会立即设置SS1\2两个引脚产生错误信号，如下图：

可以看到，此时SS1\2对外输出的是低电平，并且两者是有时间间隔的。

当然，由于SMU的FSP协议支持多种波形输出，35584为此也做了适配。

1.2 响应监控功能引发的ROT

 当35584发现某些受监控电压异常时，有可能会向MCU发起复位信号，同时SS1\2也会根据复位类型（软复位和硬复位）将电平下拉，如下图：

软复位 

硬复位 

1.3 响应看门狗引发的错误

当没有及时喂狗的情况下，会引发SS1\2变为低电平，如下图：

1.4 环境过温引发的错误状态

当环境温度过高时，同样也会触发SS1\2的低电平产生.

1.5 为什么设计SSx？

一方面，我们可以看到有这么多种不同种类的错误状态都会导致SS1、SS2变成低电平，那么我们可以用到什么场合呢？

从另一方面来想，TC3xx既然是ASIL D的芯片，那么为啥不用芯片本身来做安全状态管理呢？ 

这就不得不考虑这个系统安全状态是什么概念？

从应用角度来看，在汽车上所谓进入安全状态，常见的有整车进跛行，电压异常IVI关闭屏幕并停发车内报文等。通常情况，上述安全状态一般是有某主控MCU来进行控制，但是如果MCU里面出现了随机硬件失效，那是不是就需要另一个独立的路径来让整车或者MCU进入到安全状态？

所以我理解，在功能安全设计方面，35584是作为MCU之外的独立功能安全控制路径补充。

即：当主路径失效后，第二安全路径仍然能够使得系统进入到安全状态。

如下图：

2. 安全状态输出给谁 

上一章节我们讲到，在汽车领域常见的安全状态有：某些执行器的关闭，MCU的通信通道关闭、甚至某些系统的全部关闭。这些安全状态的进入路径至少应该有两条相互独立的路径进入。

为了方便描述，我们以最简单的关闭CAN通信为例。

要关闭通信，其实从MCU角度来看，只要直接关闭Transceiver即可。

以TLE9252V为例，其引脚定义如下：

 通过EN和NSTB可以使其进入standby或者监听模式，

 很明显，如果想要两条独立路径控制，最好就是MCU(TC3xx)和PMIC(35584)单独控制一个transceiver引脚的输入。

例如，MCU控制NSTB，PMIC控制EN脚，MCU和PMIC之间通过ErrorPin连接，如果MCU内部出现错误，PMIC可以直接将SS1\2设置为低电平，从而使收发器进入到监听或者stand-by模式。

当然，如果出现了共因失效，例如TLF35584的QCO过大，有可能会烧毁TLE9252V，这时候就要考虑到给TLE9252V断电，同时也就关闭了transceiver。

3.小结

通过上面简单的例子，我们完成了MCU、PMIC、Transceiver之间的功能安全逻辑闭环，也进一步勾起了我对功能安全的兴趣。

接下来，我会继续从功能安全的项目是如何定义、安全目标的设置来源、应用的功能安全概念：例如如何定义安全状态、监控通道独立性等等方面继续梳理自己的思路，充实弹药库。