目录
在之前文章里,我们简述了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之间的功能安全逻辑闭环,也进一步勾起了我对功能安全的兴趣。
接下来,我会继续从功能安全的项目是如何定义、安全目标的设置来源、应用的功能安全概念:例如如何定义安全状态、监控通道独立性等等方面继续梳理自己的思路,充实弹药库。