嵌入式 MCU 的 Class B 安全功能实现
嵌入式 MCU 的 Class B 安全功能实现
在嵌入式系统设计中,安全性始终是至关重要的考虑因素。IEC60730标准为家用电器及类似电气控制设备的安全性提供了全面的规范,其中Class B安全功能要求在硬件和软件层面都具备较高的错误检测和恢复能力。本文将详细介绍如何在嵌入式MCU中实现Class B安全功能,包括CPU寄存器自检、存储器检查、时钟检查、中断检测、IO检测、ADC检测和通信检测等关键环节。
前言
在家用电器及类似电气控制设备的设计和制造中,安全性始终是至关重要的。全球标准化机构,如国际电工委员会(IEC)、美国保险商实验室(UL)和加拿大标准协会(CSA),制定了相关安全标准,以确保电器的可靠性和安全性。其中,IEC60730 标准为电器设备的自动控制系统提供了一套全面的规范,旨在确保设备在各种使用场景中的安全性、可靠性和性能。尽管该标准最初主要针对家用电器,如洗衣机、冰箱和烤箱,但其应用范围已经扩展到商业和某些工业设备。如今,TUV、VDE(主要在欧洲)、UL及CSA(主要在美国和加拿大)等机构均认可并要求在认证过程中应用这一标准。
IEC60730 标准的 A、B、C三类功能
IEC60730 标准定义了A、B、C三类功能,分别关注于设备的使用便利性、安全性和特殊危险预防。这些分类帮助设计人员确保设备在各种操作条件下能够安全可靠地运行,为用户提供了更高的操作安全和舒适体验。
A类功能是指那些用于一般自动控制目的的设备,这些设备的主要目标是提高使用便利性和效率,而不直接涉及到设备的基本安全保障。A类功能的设计通常关注设备的操作舒适性和用户友好性。如智能家居系统中的智能灯光控制,可以通过定时器或传感器自动调节室内灯光。家用洗衣机的洗涤程序控制提供选择不同的洗涤模式,如快速洗、节能洗等。
B类功能是指那些直接涉及到设备安全的自动控制功能。这些功能的主要目标是防止设备在使用过程中出现可能导致用户受伤或设备损坏的情况。比如烤箱或电热水壶的热切断装置,防止烤箱或电热水壶等设备过热,当温度超过设定值时自动切断电源,以避免火灾或设备损坏。
C类功能是指那些用于防止特殊危险、或更高风险的自动控制功能,特别是在可能出现爆炸、火灾等严重事故的环境中。如热水器的压力保护装置,实时监控热水器内部的压力,防止因压力过高而导致的爆炸或水箱损坏。电动窗帘的安全装置,在窗帘升降过程中,如果感应到障碍物,自动停止或反向操作以防止夹伤等等。
IEC60730 标准认证对软硬件的要求
Class A、B 和 C 等级反映了对设备安全性、可靠性和错误处理能力的不同要求。Class A 认证适用于那些对安全性和可靠性要求较低的设备,Class B 认证针对的是那些需要较高安全性但不如 Class C 严格的自动电气控制装置,Class C 的要求比 Class B 更高,涵盖了更广泛的安全性和可靠性方面,确保设备在更苛刻的环境下也能稳定、安全地运行。
Class A:
- 硬件要求:基础的电气安全和机械强度,主要确保设备在正常条件下的稳定运行。
- 软件要求:实现基本功能并提供用户友好的操作界面。错误检测和恢复能力要求较低,关注点在于操作的简便性和基本功能的实现。
- 安全上的要求主要看硬件设计,软件正常业务通常足以满足要求。
Class B:
- 硬件要求:提升了电气安全性,要求更高的耐用性和抗干扰能力。
- 绝缘和保护:必须确保设备的绝缘设计满足安全标准,以防电气冲击和短路。
- 机械强度:硬件应具备足够的机械强度,能抵御正常使用中的物理压力或碰撞。
- 组件需经得起长期使用中的磨损和老化,确保长期的安全运行。
- 必须符合电气安全标准,如电气绝缘、电气间隙等要求,避免出现过热或短路问题。
- 硬件设计需考虑电磁兼容性(EMC),避免或减轻电磁干扰(EMI)对设备功能的影响。
- 软件要求:要求较高的错误检测和恢复能力,致力于实现高水平的功能安全和长期可靠性。
- 软件设计需要满足功能安全要求,包括对故障条件的处理能力和错误检测机制。
- 应用程序应能有效处理意外的操作错误,避免因软件故障导致的安全问题。
- 安全上的要求除了看硬件设计,还要考虑硬件失效后软件的保护,以及软件的周期性自检以保证软件保护功能能正常起作用。
Class C:
- 硬件要求:重点在于特殊危险预防,要求额外的防护措施,以应对潜在的特殊风险,如高温、高湿等。
- 软件要求:针对特殊危险情境的软件处理,如应对极端条件下的功能失效。实现额外的错误处理和预防机制,确保在特殊情况下仍能保持功能安全。
- 无论硬件设计还是软件设计,都要提供更多重的保护机制,比如软硬件的一重保护失效后,有第二重保护防范。
Class B 安全功能设计
在嵌入式设备的设计中,安全功能的定义往往是基于特定业务场景而拆分出来的,这种方法通常满足了初步的安全需求,例如移动机器人,机器人在自动导航时遇到障碍物(如人)会立即停止,这一功能是符合基本的安全要求的。然而,这种基于业务场景的安全定义通常只是一个起点,它并未考虑到更深层次的问题和潜在的安全隐患。例如,如果机器人的雷达传感器发生故障,导致其无法准确感应到障碍物,或者控制机器移动的轮毂失控,那么原本设计良好的安全功能就会失效。这种问题的存在说明,安全功能的设计不仅需要关注单一场景的正确实现,还必须在系统层面上考虑到各种可能的故障模式和失效情况。
为应对这些复杂的安全挑战,需要从更高级别的认证标准(如Class B)出发,细化安全功能的分类,以全面覆盖潜在的故障模式和风险。
例如,MCU(微控制单元)自检功能可以确保处理器在正常工作状态下进行自我监测,从而保证系统的稳定性。同时,通信检测功能能够确保当雷达检测到障碍物时,相关的控制指令(如轮毂停止)能够及时且准确地传递。轮毂的编码器检测,能够确保轮毂真实地移动或停止等等,这些措施帮助确保在复杂或异常情况下,系统的安全功能仍能有效地保护人身安全。
具体来说,我们可以从以下方面实现安全功能:
安全功能 | 说明 |
---|---|
CPU 寄存器自检 | 包括 R13(栈指针)、R14(链接寄存器)和 PSP(进程栈指针) |
PC程序计数器 | 防止程序计数器丢失或终止 |
看门狗自检 | 避免出现复位时间太快、太慢或卡滞不工作的情况 |
非易失性存储器完整性检查 | 主要是 FLASH,避免目标 FLASH 区域被修改或损坏 |
易失性存储器检查 | 主要是 RAM,检查 RAM 是否可正常读写 |
系统时钟频率检查 | 检查外部输入时钟源是否准确 |
IO 外设检查 | 涉及安全功能的输入输出信号,如限位传感器信号、PWM 脉冲信号 |
ADC 检查 | 涉及安全功能的模拟信号量,如温度、电压、电流 |
中断检查 | 避免中断频率过高或过低或无中断响应 |
通信检查 | 涉及安全功能的通信,如基于 SPI、UART、CAN 通信的轮毂电机控制 |
安全功能软件库
在实际开发中,部分 MCU 厂商会提供符合认证要求的安全功能包,以便用户快速实现 MCU 功能自检。例如,STM32 的 STL 软件包。
经过认证的 STM32 STL 固件包由下列软件模块组成:
- CPU寄存器测试
- 系统时钟监控
- RAM功能检查
- Flash CRC完整性检查
- 看门狗自检
- 栈上溢监控
借助厂商提供的安全功能固件包,我们可以针对性地开发自检程序,从而加速认证过程。
启动自检与运行自检
在复位微控制器后,首次检查应包括在初始化阶段运行启动自检。这一过程在应用业务尚未启动之前,对 MCU 相关组件(CPU寄存器、看门狗、Flash完整性、RAM功能、系统时钟)进行全面的检测,确保系统的基础功能都处于最佳状态。
启动自检结构:
运行时测试是在主循环中定期执行的测试块。除了包含 MCU 启动自检相关的测试(其中部分启动自检功能可能在运行时检测时会简化),还应包括应用业务中的安全功能相关测试。这些测试应涵盖与安全功能相关的 IO、ADC、中断、通信等模块,以确保这些功能在运行期间的正确性和可靠性。
运行时自检结构:
CPU 寄存器自检
CPU启动自检检查内核标记、寄存器和栈指针的正确功能。如果发现任何错误,应进行故障处理并上报异常。
具体实现:从 ACC 寄存器开始,用 0x55、0xAA分别填充全部 CPU 寄存器(可能引起 CPU 工作异常的特殊寄存器除外),再读出对比,测试读写是否正常。
以下是ST提供的部分CPU自检代码:
/********************/
/* CPU Test modules */
/********************/
#ifdef ARTI_FAILING_CPU_TM
/* Artificial failing feature -
when activated, it forces the STL outputs to predefined values */
ArtifFailing.aCpuTmStatus[0] = STL_PASSED;
ArtifFailing.aCpuTmStatus[1] = STL_PASSED;
ArtifFailing.aCpuTmStatus[2] = STL_FAILED;
STL_SCH_StartArtifFailing(&ArtifFailing);
#endif /* ARTI_FAILING_CPU_TM */
/* CPU TM1L */
if (STL_SCH_RunCpuTM1L(&StlCpuTm1LStatus) != STL_OK)
{
FailSafe_Handler(TM1L_ERR_CODE + DEF_PROG_OFFSET);
}
if (StlCpuTm1LStatus != STL_PASSED)
{
FailSafe_Handler(TM1L_ERR_CODE);
}
/* CPU TM7 */
if (STL_SCH_RunCpuTM7(&StlCpuTm7Status) != STL_OK)
{
FailSafe_Handler(TM7_ERR_CODE + DEF_PROG_OFFSET);
}
if (StlCpuTm7Status != STL_PASSED)
{
FailSafe_Handler(TM7_ERR_CODE);
}
/* CPU TMCB */
if (STL_SCH_RunCpuTMCB(&StlCpuTmCBStatus) != STL_OK)
{
FailSafe_Handler(TMCB_ERR_CODE + DEF_PROG_OFFSET);
}
if (StlCpuTmCBStatus != STL_PASSED)
{
FailSafe_Handler(TMCB_ERR_CODE);
}
#ifdef ARTI_FAILING_CPU_TM
STL_SCH_StopArtifFailing();
#endif /* ARTI_FAILING_CPU_TM */
看门狗启动自检
看门狗自检基于复位状态寄存器内容,不同的复位原因会有相应的寄存器标志。在系统正常上电时,IWDG 和 WWDG 都应处于未触发状态。首先进行 IWDG 的复位测试,将 IWDG 设置为最短复位周期,清除所有复位标志后,进入等待状态。经过设定时间后,IWDG 应触发系统复位。复位重启后,IWDG 标志应被设置,并且应该是唯一的复位原因,否则需清除所有复位标志并重新开始检测。随后进行 WWDG 测试,将 WWDG 设置为最短复位周期,等待系统再次触发复位,复位重启后,IWDG 和 WWDG 寄存器标志均被设置时,测试才算通过,否则需清除所有复位标志并重新开始检测。测试通过后记得清除所有复位标志。
以下是ST提供的看门狗自检代码:
/******************************************************************************/
/**
* @brief Verifies the watchdog by forcing watchdog resets
* @param : None
* @retval : None
*/
void STL_WDGSelfTest(void)
{
/* ==============================================================================*/
/* MISRA violation of rule 12.4 - side effect */
本文原文来自CSDN