1. 这份安全手册到底在防什么别跟我一样等到认证现场再去翻说实话第一次拿到意法半导体官方那本《STM32G0系列安全手册》时我把它当成了参考资料的附件扫一眼就丢给认证公司。后来一个小家电项目要过IEC61508认证工程师追着我问“你们有没有按手册做时钟失效测试”“FMEDA表里诊断覆盖率填的是多少”“G0的哪些安全机制需要软件配合”我才被迫从头啃了一遍。啃完才发现参考手册里那些“可选功能”在这本手册里全是安全逻辑的一部分看门狗不是简单防死机而是证据链时钟监控不是为了让系统更健壮而是为了满足危险失效的覆盖指标。今天就把我对这本安全手册的读法、用法和踩坑整理出来。这里要先把概念对齐这本安全手册里的“安全”英文是Safety和Security要分开。它防的主要是随机硬件故障、系统性设计错误、程序跑飞、供电异常这一类会导致设备进入危险状态的问题而不是防黑客、防固件盗取。固件加密、读保护这些Security内容ST通常放在参考手册或专门的安全说明里安全手册会引用但主角不是它。你要做IEC61508、IEC60730、ISO13849这类功能安全相关产品看的应该是这本Safety Manual。1.1 安全手册和参考手册的分工很多工程师习惯在参考手册里搜寄存器却忽略了安全手册存在的原因。参考手册告诉你WWDG有窗口窗口设多少、什么时候喂狗但不会告诉你如果主循环已经卡死只有中断在跑把喂狗放中断里会导致看门狗失效。安全手册则会从故障诊断角度说明WWDG配合执行顺序校验可以覆盖哪些CPU失效模式达到多少诊断覆盖率并且要求你周期性地对看门狗本身做测试。所以两本手册的关系是参考手册解决“这个功能怎么用”安全手册解决“这个功能在安全功能里怎么配、能探测什么故障、需要额外做什么测试”。认证机构看的不是你懂不懂外设而是你有没有按照安全手册的建议实现安全机制并有证据。1.2 谁该读什么时间读建议硬件工程师在原理图阶段就读特别是涉及电源监控、复位、时钟和GPIO安全输出软件工程师在搭框架阶段读特别是看门狗、自检和安全状态机部分项目管理层也要知道这本手册的存在因为它直接影响开发进度和认证周期。最怕的情况是板子画完了、软件写完了才开始读安全手册然后发现SIL等级对于片上机制覆盖率不够只能加外部芯片、改电源方案。这种追加改动比一开始多花三倍时间都正常。2. STM32G0的能力边界SIL等级、失效模式和安全声明2.1 STM32G0能撑起多大的安全要求在ST官方的安全手册里STM32G0被定位为可用于支持安全功能开发的通用MCU主要面向IEC61508的SIL2及以下等级在传统家电行业也能配合IEC60730 B类认证做开发。注意这是“可用于支持”不是“随便用就自动满足”。你必须按照手册给出的安全机制、软件诊断措施和FMEDA数据来搭建系统最终安全完整性是由整个系统共同决定的。G0用的是Cortex-M0内核单核、没有锁步冗余所以在高可用、高完整性的SIL3需求下并不合适。不是说它绝对不行而是需要外部架构补充比如两个MCU互相监控、外部安全继电器、独立电压监控芯片等。但如果你只需要做单通道SIL2或简单的B类家电控制G0加上手册里的机制是够用的。2.2 失效模式不能只盯着“芯片坏了”安全的重点不是避免芯片坏而是坏的时候能被发现并在进入危险状态前进入安全状态。所以失效模式要分成两类看一类是永久故障比如Flash单元损坏、引脚短路另一类是瞬态故障比如RAM位翻转、时钟瞬间跑偏、寄存器被干扰改写。后者在MCU应用里更隐蔽也更容易被忽视。STM32G0安全手册会给出各个子模块的典型失效模式。举个例子时钟系统如果外部晶振停振系统后续执行全部乱套电源电压缓慢跌落CPU可能执行错误指令。每种失效模式都有对应的诊断机制有些是片上自带有些需要软件配合。读手册时不要只看机制列表要看每个机制覆盖了哪个失效模式还有没有覆盖不到的。2.3 安全声明是证据链不是宣传文案安全手册不会写“这个MCU很安全”它会写“在特定配置和测试下某个失效模式的诊断覆盖率可以达到多少”。这些数字要写进你的FSM安全状态机和FMEA/FMEDA文档里作为认证依据。所以读手册时要养成一个习惯看到某个机制先在旁边记下它对应的失效模式、诊断覆盖率、建议的测试周期。后面做FMEDA汇总表的时候这些就是你填表的原始数据。别等到评审现场再翻PDF那场面相当难看。3. 硬件安全机制逐条精读哪些机制真正进安全逻辑3.1 电源监控BOR和PVD是两道不同的防线STM32G0的BOR欠压复位是芯片自己在上电和运行期间监控VDD的当电压低于阈值时会触发复位。它属于默认的硬件保护能避免MCU在非正常供电下运行。但是BOR的阈值通常比较低而且触发后的动作是直接复位不一定适合所有安全状态。PVD可编程电压检测器就灵活得多。你可以把阈值配得比BOR高电压掉到阈值但不至于引起复位时就产生中断让软件有时间把输出切到安全电平、保存错误信息然后进入安全关机流程。对马达驱动、加热控制这类设备这是很关键的一道防线。我在实际项目中一般这么配BOR保持默认作为最后兜底PVD配在“正常电压范围下限往上一点”中断优先级拉高中断服务函数里只做安全状态切换不做业务处理。这样即使主程序被打断安全通道也能在几十微秒内响应。3.2 时钟监控CSS不是可选项是安全配置的一部分STM32G0在启用外部高速晶振HSE时可以打开时钟安全系统CSS。一旦HSE失效系统会自动切换时钟源并产生NMI中断。安全手册里CSS通常被用来覆盖“外部晶振停振”这一失效模式。注意几个细节第一CSS只有在HSE使能并且被选中为系统时钟时才有效第二NMI中断里要尽快进入安全状态不能做复杂操作第三如果项目直接用内部HSI就没有这一层的诊断需要考虑其他时钟监控手段。不少工程师把CSS当成可选优化项没开。但在安全评审中如果外部晶振是唯一时钟源又不做任何时钟失效检测认证通常不给过。你需要要么开CSS并写好NMI处理要么换成内部RC作为系统时钟并论证为什么安全。3.3 看门狗IWDG和WWDG不是二选一是组合拳独立看门狗IWDG的时钟来自LSI和主系统时钟独立。程序跑飞时只要喂狗代码没执行就会复位。窗口看门狗WWDG则使用系统时钟并有一个窗口限制太早喂、太晚喂都会复位。这意味着WWDG不仅能检测“代码卡死”还能检测“程序乱跳到某个路径后又莫名其妙地执行了喂狗指令”的情况。安全手册通常会建议你把两者结合IWDG作为最终兜底WWDG用来约束主循环执行时序。喂狗的位置只能放在正常安全循环的固定点不能在中断里喂。一个常见错误是为了保证不死机把喂狗放在一个高优先级定时器中断里结果是主循环卡死时中断还在喂狗看门狗毫无作用。还有一点很容易被忽略为了证明看门狗有效需要在开发阶段做故障注入测试比如把喂狗代码屏蔽几十毫秒确认复位发生或者把窗口寄存器改成非法值确认无法通过。测试结果要留记录认证机构可能会看。3.4 数据完整性CRC、RAM测试、关键变量冗余STM32G0内置CRC外设可以用来快速计算内存区域或通信数据的校验值。对于Flash中的固件区一般做法是编译后生成一个CRC烧写时写入固定位置启动时用CRC外设重新计算和存储值比对不一致就进入安全状态。运行中可以周期性地对关键函数区段做抽检但要注意计算耗时会挤占主循环需要评估。RAM测试也是一个绕不开的点。常见做法是用March C算法在开机时跑一遍如果系统运行时间长、不允许长时间停机的可以分块在后台周期执行。但要保证每一块RAM在足够短的时间间隔内都被测过覆盖周期要写入文档。关键变量建议采用冗余存储同一个安全变量存两份一份取反读取时比对如果双份不一致说明RAM可能被干扰应该进入安全状态或尝试恢复。这套方法不依赖芯片特殊硬件任何M0都能实现安全手册和IEC60730 B类都在推荐。3.5 温度、复位源、中断优先级的配套作用内部温度传感器可以用来做过温诊断复位源寄存器能区分上电复位、外部复位、IWDG复位、WWDG复位等对故障记录很关键。例如IWDG复位说明主程序跑飞过如果复位后直接当正常启动处理就会掩盖故障。中断这方面的坑更典型。安全关键的中断比如PVD、NMI、外部安全信号输入优先级必须设到最高而且中断服务函数要尽量短。否则系统满负荷时安全中断被普通业务中断阻塞故障处理延迟可能超过安全阈值。我把相关机制整理成了一张对照表硬件机制主要覆盖的失效模式常见软件配合动作注意事项BORVDD欠压无需但注意复位源记录阈值由芯片决定PVD电压跌落进入安全中断切断负载阈值高于BOR时才有预警价值CSS外部晶振失效NMI里切安全状态保存错误码仅在HSE作为时钟源时有效IWDG程序跑飞、死循环固定点喂狗禁止中断喂狗LSI独立计数WWDG执行顺序异常、提前喂狗窗口内喂狗定期测试窗口留裕量防温漂CRCFlash/RAM内容变化启动校验周期抽检注意计算耗时冗余变量RAM位翻转双副本取反存储适合安全关键变量复位源寄存器各类复位原因识别启动时记录并上报不要清太快这张表不是官方手册截图只是一个项目上的归总。具体每个机制的诊断覆盖率和测试周期必须以对应型号的安全手册为准。4. FMEDA表是安全手册的心脏诊断覆盖率到底怎么算4.1 先看懂FMEDA的每一列FMEDA全称是Failure Modes, Effects and Diagnostic Analysis对应中文就是失效模式、影响与诊断分析。安全手册里会给出多张FMEDA表每行描述一个硬件模块的一个失效模式。典型列包括模块名称、失效模式、失效占比、现有检测机制、诊断覆盖率、安全状态、是否可见等。很多人拿到表之后第一反应是“好密集看不懂”。其实只要抓住三个关键列失效模式、检测机制、诊断覆盖率。失效模式决定了你需要在系统里防什么检测机制决定了用片上外设还是软件自检诊断覆盖率决定这个失效模式被可靠发现的概率。比如某个模块的某种失效模式安全手册说用WWDG可以检测DC90%那你就要在软件里启用WWDG并做周期测试然后才能在FMEDA汇总表里把90%填进去。4.2 一个示意性的FMEDA小节计算我这里给一个简化的示意数据只是为了讲计算方法不是STM32G0的真实数据。假设一个安全检测通道使用了IWDG安全手册给出IWDG自身失效模式中 STM32G0功能安全手册精读：从失效模式到FMEDA诊断覆盖率
1. 这份安全手册到底在防什么别跟我一样等到认证现场再去翻说实话第一次拿到意法半导体官方那本《STM32G0系列安全手册》时我把它当成了参考资料的附件扫一眼就丢给认证公司。后来一个小家电项目要过IEC61508认证工程师追着我问“你们有没有按手册做时钟失效测试”“FMEDA表里诊断覆盖率填的是多少”“G0的哪些安全机制需要软件配合”我才被迫从头啃了一遍。啃完才发现参考手册里那些“可选功能”在这本手册里全是安全逻辑的一部分看门狗不是简单防死机而是证据链时钟监控不是为了让系统更健壮而是为了满足危险失效的覆盖指标。今天就把我对这本安全手册的读法、用法和踩坑整理出来。这里要先把概念对齐这本安全手册里的“安全”英文是Safety和Security要分开。它防的主要是随机硬件故障、系统性设计错误、程序跑飞、供电异常这一类会导致设备进入危险状态的问题而不是防黑客、防固件盗取。固件加密、读保护这些Security内容ST通常放在参考手册或专门的安全说明里安全手册会引用但主角不是它。你要做IEC61508、IEC60730、ISO13849这类功能安全相关产品看的应该是这本Safety Manual。1.1 安全手册和参考手册的分工很多工程师习惯在参考手册里搜寄存器却忽略了安全手册存在的原因。参考手册告诉你WWDG有窗口窗口设多少、什么时候喂狗但不会告诉你如果主循环已经卡死只有中断在跑把喂狗放中断里会导致看门狗失效。安全手册则会从故障诊断角度说明WWDG配合执行顺序校验可以覆盖哪些CPU失效模式达到多少诊断覆盖率并且要求你周期性地对看门狗本身做测试。所以两本手册的关系是参考手册解决“这个功能怎么用”安全手册解决“这个功能在安全功能里怎么配、能探测什么故障、需要额外做什么测试”。认证机构看的不是你懂不懂外设而是你有没有按照安全手册的建议实现安全机制并有证据。1.2 谁该读什么时间读建议硬件工程师在原理图阶段就读特别是涉及电源监控、复位、时钟和GPIO安全输出软件工程师在搭框架阶段读特别是看门狗、自检和安全状态机部分项目管理层也要知道这本手册的存在因为它直接影响开发进度和认证周期。最怕的情况是板子画完了、软件写完了才开始读安全手册然后发现SIL等级对于片上机制覆盖率不够只能加外部芯片、改电源方案。这种追加改动比一开始多花三倍时间都正常。2. STM32G0的能力边界SIL等级、失效模式和安全声明2.1 STM32G0能撑起多大的安全要求在ST官方的安全手册里STM32G0被定位为可用于支持安全功能开发的通用MCU主要面向IEC61508的SIL2及以下等级在传统家电行业也能配合IEC60730 B类认证做开发。注意这是“可用于支持”不是“随便用就自动满足”。你必须按照手册给出的安全机制、软件诊断措施和FMEDA数据来搭建系统最终安全完整性是由整个系统共同决定的。G0用的是Cortex-M0内核单核、没有锁步冗余所以在高可用、高完整性的SIL3需求下并不合适。不是说它绝对不行而是需要外部架构补充比如两个MCU互相监控、外部安全继电器、独立电压监控芯片等。但如果你只需要做单通道SIL2或简单的B类家电控制G0加上手册里的机制是够用的。2.2 失效模式不能只盯着“芯片坏了”安全的重点不是避免芯片坏而是坏的时候能被发现并在进入危险状态前进入安全状态。所以失效模式要分成两类看一类是永久故障比如Flash单元损坏、引脚短路另一类是瞬态故障比如RAM位翻转、时钟瞬间跑偏、寄存器被干扰改写。后者在MCU应用里更隐蔽也更容易被忽视。STM32G0安全手册会给出各个子模块的典型失效模式。举个例子时钟系统如果外部晶振停振系统后续执行全部乱套电源电压缓慢跌落CPU可能执行错误指令。每种失效模式都有对应的诊断机制有些是片上自带有些需要软件配合。读手册时不要只看机制列表要看每个机制覆盖了哪个失效模式还有没有覆盖不到的。2.3 安全声明是证据链不是宣传文案安全手册不会写“这个MCU很安全”它会写“在特定配置和测试下某个失效模式的诊断覆盖率可以达到多少”。这些数字要写进你的FSM安全状态机和FMEA/FMEDA文档里作为认证依据。所以读手册时要养成一个习惯看到某个机制先在旁边记下它对应的失效模式、诊断覆盖率、建议的测试周期。后面做FMEDA汇总表的时候这些就是你填表的原始数据。别等到评审现场再翻PDF那场面相当难看。3. 硬件安全机制逐条精读哪些机制真正进安全逻辑3.1 电源监控BOR和PVD是两道不同的防线STM32G0的BOR欠压复位是芯片自己在上电和运行期间监控VDD的当电压低于阈值时会触发复位。它属于默认的硬件保护能避免MCU在非正常供电下运行。但是BOR的阈值通常比较低而且触发后的动作是直接复位不一定适合所有安全状态。PVD可编程电压检测器就灵活得多。你可以把阈值配得比BOR高电压掉到阈值但不至于引起复位时就产生中断让软件有时间把输出切到安全电平、保存错误信息然后进入安全关机流程。对马达驱动、加热控制这类设备这是很关键的一道防线。我在实际项目中一般这么配BOR保持默认作为最后兜底PVD配在“正常电压范围下限往上一点”中断优先级拉高中断服务函数里只做安全状态切换不做业务处理。这样即使主程序被打断安全通道也能在几十微秒内响应。3.2 时钟监控CSS不是可选项是安全配置的一部分STM32G0在启用外部高速晶振HSE时可以打开时钟安全系统CSS。一旦HSE失效系统会自动切换时钟源并产生NMI中断。安全手册里CSS通常被用来覆盖“外部晶振停振”这一失效模式。注意几个细节第一CSS只有在HSE使能并且被选中为系统时钟时才有效第二NMI中断里要尽快进入安全状态不能做复杂操作第三如果项目直接用内部HSI就没有这一层的诊断需要考虑其他时钟监控手段。不少工程师把CSS当成可选优化项没开。但在安全评审中如果外部晶振是唯一时钟源又不做任何时钟失效检测认证通常不给过。你需要要么开CSS并写好NMI处理要么换成内部RC作为系统时钟并论证为什么安全。3.3 看门狗IWDG和WWDG不是二选一是组合拳独立看门狗IWDG的时钟来自LSI和主系统时钟独立。程序跑飞时只要喂狗代码没执行就会复位。窗口看门狗WWDG则使用系统时钟并有一个窗口限制太早喂、太晚喂都会复位。这意味着WWDG不仅能检测“代码卡死”还能检测“程序乱跳到某个路径后又莫名其妙地执行了喂狗指令”的情况。安全手册通常会建议你把两者结合IWDG作为最终兜底WWDG用来约束主循环执行时序。喂狗的位置只能放在正常安全循环的固定点不能在中断里喂。一个常见错误是为了保证不死机把喂狗放在一个高优先级定时器中断里结果是主循环卡死时中断还在喂狗看门狗毫无作用。还有一点很容易被忽略为了证明看门狗有效需要在开发阶段做故障注入测试比如把喂狗代码屏蔽几十毫秒确认复位发生或者把窗口寄存器改成非法值确认无法通过。测试结果要留记录认证机构可能会看。3.4 数据完整性CRC、RAM测试、关键变量冗余STM32G0内置CRC外设可以用来快速计算内存区域或通信数据的校验值。对于Flash中的固件区一般做法是编译后生成一个CRC烧写时写入固定位置启动时用CRC外设重新计算和存储值比对不一致就进入安全状态。运行中可以周期性地对关键函数区段做抽检但要注意计算耗时会挤占主循环需要评估。RAM测试也是一个绕不开的点。常见做法是用March C算法在开机时跑一遍如果系统运行时间长、不允许长时间停机的可以分块在后台周期执行。但要保证每一块RAM在足够短的时间间隔内都被测过覆盖周期要写入文档。关键变量建议采用冗余存储同一个安全变量存两份一份取反读取时比对如果双份不一致说明RAM可能被干扰应该进入安全状态或尝试恢复。这套方法不依赖芯片特殊硬件任何M0都能实现安全手册和IEC60730 B类都在推荐。3.5 温度、复位源、中断优先级的配套作用内部温度传感器可以用来做过温诊断复位源寄存器能区分上电复位、外部复位、IWDG复位、WWDG复位等对故障记录很关键。例如IWDG复位说明主程序跑飞过如果复位后直接当正常启动处理就会掩盖故障。中断这方面的坑更典型。安全关键的中断比如PVD、NMI、外部安全信号输入优先级必须设到最高而且中断服务函数要尽量短。否则系统满负荷时安全中断被普通业务中断阻塞故障处理延迟可能超过安全阈值。我把相关机制整理成了一张对照表硬件机制主要覆盖的失效模式常见软件配合动作注意事项BORVDD欠压无需但注意复位源记录阈值由芯片决定PVD电压跌落进入安全中断切断负载阈值高于BOR时才有预警价值CSS外部晶振失效NMI里切安全状态保存错误码仅在HSE作为时钟源时有效IWDG程序跑飞、死循环固定点喂狗禁止中断喂狗LSI独立计数WWDG执行顺序异常、提前喂狗窗口内喂狗定期测试窗口留裕量防温漂CRCFlash/RAM内容变化启动校验周期抽检注意计算耗时冗余变量RAM位翻转双副本取反存储适合安全关键变量复位源寄存器各类复位原因识别启动时记录并上报不要清太快这张表不是官方手册截图只是一个项目上的归总。具体每个机制的诊断覆盖率和测试周期必须以对应型号的安全手册为准。4. FMEDA表是安全手册的心脏诊断覆盖率到底怎么算4.1 先看懂FMEDA的每一列FMEDA全称是Failure Modes, Effects and Diagnostic Analysis对应中文就是失效模式、影响与诊断分析。安全手册里会给出多张FMEDA表每行描述一个硬件模块的一个失效模式。典型列包括模块名称、失效模式、失效占比、现有检测机制、诊断覆盖率、安全状态、是否可见等。很多人拿到表之后第一反应是“好密集看不懂”。其实只要抓住三个关键列失效模式、检测机制、诊断覆盖率。失效模式决定了你需要在系统里防什么检测机制决定了用片上外设还是软件自检诊断覆盖率决定这个失效模式被可靠发现的概率。比如某个模块的某种失效模式安全手册说用WWDG可以检测DC90%那你就要在软件里启用WWDG并做周期测试然后才能在FMEDA汇总表里把90%填进去。4.2 一个示意性的FMEDA小节计算我这里给一个简化的示意数据只是为了讲计算方法不是STM32G0的真实数据。假设一个安全检测通道使用了IWDG安全手册给出IWDG自身失效模式中