标准依据：UL 60730-1 第六版（2024-10-31）/ IEC 60730-1:2022（Edition 6.0），Annex H（规范性附录）
1. 问题场景：你的控制器软件属于哪一类？
你正在开发一款带 MCU 的家电控制器，送 UL 或 TÜV 认证时，实验室告诉你："这个控制器需要做 Annex H 软件评估。"
你第一反应可能是：我的代码只是控制温度和定时，也要做功能安全评估？
答案是：取决于你的控制功能失效后会发生什么。IEC 60730-1 Annex H 不是对所有软件一视同仁，而是按失效后果将控制功能分为三类——Class A、Class B、Class C。分类不同，评估工作量可能差十倍以上。
本文帮你理清分类逻辑和 Annex H 的核心要求，避免在认证时走弯路。
2. 分类决策框架
分类的核心判据只有一个：软件失效是否会导致危险？如果有，有没有其他独立保护措施兜底？
上图的决策逻辑可以简化为三个问题：
| 问题 | 回答"是" | 回答"否" |
|---|---|---|
| 软件失效影响设备安全吗？ | 进入下一问 | → Class A（豁免 Annex H 详细评估） |
| 有其他独立保护措施吗？（如机械温控器、热熔断器） | → Class B | 进入下一问 |
| 失效直接导致特殊危险吗？（如爆炸、无排气保护的密闭水系统） | → Class C | → Class B |
注意：分类针对的是控制功能，不是整个控制器。一个控制器可以同时有 Class A 功能（如显示驱动）和 Class B 功能（如过热保护），分别评估。
3. 三类要求对比
| 维度 | Class A | Class B | Class C |
|---|---|---|---|
| 典型场景 | 房间温控器、定时器 | 热限制器、压力限制器 | 燃烧器控制、密闭水系统热切断 |
| Annex H 详细评估 | 豁免 | 需要 | 需要（更严格） |
| 架构要求（H.9.12.1.2） | 无特殊要求 | 单通道+自检，或双通道无比较 | 单通道+自检+监控，或双通道+比较 |
| 故障分析 | 不需要 | FMEA（单故障） | FMEA + FTA（单故障 + 双故障） |
| 故障响应 | — | 进入声明的安全状态 | 必须有独立手段执行响应 |
| 硬件开发分析 | — | 参考 Table H.10 | 必须使用 Table H.10 a~p 组合之一 |
Class B 和 Class C 的本质区别：Class B 失效后，设备还有机械温控器或热熔断器兜底；Class C 失效后，没有其他独立保护，软件是最后一道防线。所以 Class C 要求双通道比较或独立监控——一个通道出问题，另一个能发现并采取措施。
4. Annex H 核心要求：V-Model 软件生命周期
Annex H 的软件开发要求直接提取自 IEC 61508-3，采用经典的 V-Model：
左侧每个设计阶段对应右侧一个验证阶段。核心要点：
4.1 需求 → 确认（H.9.12.3.2.1 → H.9.12.3.3.3）
你需要写一份软件安全需求规格书（SRS），列出每个安全相关功能及其响应时间。确认测试（Validation）直接对照这份 SRS 逐项验证——不是测代码写得对不对，而是测你做的东西是不是安全需要的。
4.2 架构 → 集成测试（H.9.12.3.2.2 → H.9.12.3.3.2）
架构设计要说明模块划分、调用结构、数据流、中断处理、故障控制技术。集成测试验证模块之间的接口是否正确，特别是安全相关模块与非安全模块的隔离。
4.3 编码 → 模块测试（H.9.12.3.2.3 → H.9.12.3.3.1）
编码阶段有几条硬性约束（Table H.6）：
- 禁止 GOTO（高级语言中无条件跳转）
- 限制递归（深度不可控，易栈溢出）
- 限制指针（避免野指针）
- 不使用动态内存分配（
malloc/free/new/delete），除非编译器能保证运行时前分配足够内存 - 子程序单入口/单出口
模块测试需要静态验证（代码审查、走查、静态分析）+ 动态验证（功能测试、白盒测试）两者结合。
4.4 自检库（STL）—— Table H.2 落地
Class B/C 控制器必须实现运行时自检（H.9.12.2，Table H.2）。常见自检项目：
| 组件 | 故障类型 | 检测方法 |
|---|---|---|
| CPU 寄存器 | Stuck-at | 周期性写 0/1 回读校验 |
| 程序计数器 | 跑飞 | 时间槽监控、逻辑序列监控 |
| RAM | 位翻转、地址线故障 | March 测试、GALPAT、ABRAHAM |
| Flash/ROM | 数据损坏 | CRC 校验 |
| 时钟 | 频率漂移/停摆 | 独立时钟源比较 |
| 看门狗 | 程序卡死 | 独立时间槽监控 |
实用建议：ST、NXP、Renesas、TI 都提供预认证的 IEC 60730 Class B STL 库。用预认证库可以节省大量评估时间，但你的应用层代码仍需单独评估。
5. 常见陷阱与设计建议
5.1 文档陷阱
问题：送认证时发现 Table H.1 要求的文档不全，打回重做。
建议：在开发初期就按 Table H.1 准备文档清单：
| Table H.1 编号 | 文档 | 什么时候准备 |
|---|---|---|
| H.3 | 软件序列文档 | 架构设计阶段 |
| H.4 | 程序文档（初始化/终止状态） | 编码阶段 |
| H.5 | 软件故障分析（FMEA/FTA） | 架构设计完成后 |
| H.6 | 软件类别和结构声明 | 分类确定后 |
| H.8 | 故障检测时间声明 | STL 集成后 |
| H.9 | 故障响应声明 | 系统设计阶段 |
5.2 RTOS 陷阱
问题：FreeRTOS 等多任务环境下，STL 周期性自检被任务调度打断，检测时间超出 H.8 声明的窗口。
建议：
- 将 STL 放在最高优先级任务或独立定时器中断中执行
- 栈空间与自检函数隔离，避免栈溢出影响自检
- 分批测试 RAM，每批测试时间不超过任务调度周期
5.3 EMC 联动陷阱
问题：EMC 抗扰度测试（H.25）中，浪涌或 EFT 导致程序跑飞，看门狗复位后软件未执行完整性校验，直接进入正常运行——安全功能可能已损坏。
建议：看门狗复位后必须执行上电自检（POST），确认 RAM/Flash/CPU 完整性后再恢复运行。
5.4 远程通信陷阱
问题：通过 Wi-Fi/蓝牙远程更新 Class B 软件，未实施 Hamming Distance ≥ 3 的通信完整性校验，也未使用密码技术（H.9.12.4.5）。
建议：
- OTA 固件包必须包含 CRC 或数字签名
- 通过公共网络传输时，必须实施密码技术（H.9.12.4.6，参考 ISO/IEC 9796 等标准）
- 更新前校验软件版本与硬件兼容性
- 更新过程中控制器必须保持在安全状态
6. 总结
| 要点 | 关键信息 |
|---|---|
| 分类先行 | 先确定每个控制功能的 Class（A/B/C），再决定评估深度 |
| Class A 豁免 | 与安全无关的功能不需要 Annex H 详细评估 |
| Class B 核心 | 单故障分析 + 自检库 + V-Model 文档 + EMC 抗扰度 |
| Class C 加码 | 双故障分析 + 双通道比较/独立监控 + 独立响应手段 + 硬件开发分析 |
| 文档是硬通货 | Table H.1 要求的文档缺一不可，越早准备越从容 |
| 预认证库是捷径 | 芯片厂商 STL 库可缩短周期，但应用代码仍需评估 |