本文依据 IEC 60730-1:2022（Ed 6.0）Annex H 撰写，面向带微控制器的温控器、电机控制器、定时器类产品的嵌入式研发和合规工程师。条款号均可对照原文。
先描述一个你可能正在经历的场景：产品里用了 MCU，温控保护、门锁检测这些安全功能都跑在软件里。认证机构看完原理图后丢回一句话——"这些功能按 Class B 评估，请提供 Annex H 文档"。然后你发现 Annex H 有六十多页，Table H.2 像天书，而交期就在下个季度。
这篇文章解决三件事：你的功能到底算不算 Class B；Class B（以及更严的 Class C）要求软件长成什么样；以及 MCU 厂商现成的 Class B 自检库能帮你到哪一步、帮不到哪一步。
一、分类判定：安全功能靠软件，就躲不开 Annex H
Annex H 按"故障后果"把控制功能分成三类（H.3.21）：
- Class A：不依赖它保证应用安全的功能，比如室温调节、湿度控制、普通定时。失效了顶多是体验问题。
- Class B：用于防止器具进入不安全状态的功能，比如过热限制器、压力限制器、洗衣机门锁。单看它自己失效不会直接出事故——但器具里同时存在另一个故障时就危险了。
- Class C：用于防止爆炸等特殊危险、或其失效本身就直接造成危险的功能，比如燃烧器控制、密闭无泄压水系统的热断路器。
判定的关键不在"你的软件写得多重要"，而在整机安全概念里这个功能承担什么角色（H.3.21 开篇就要求结合器具完整安全概念分类）。同一个温度采样代码，用在室温调节上是 Class A，用在防止干烧上就是 Class B。
软件类别和控制功能类别是绑定关系：Class B 控制功能里的软件必须满足软件 Class B 要求（H.13.2.2.1），Class C 同理。而 H.9.12 开篇就说，H.9.12.1 到 H.9.12.4 这一大套构造要求只适用于软件 Class B 或 C——Class A 的软件几乎没有额外负担。所以分类判定是整个合规路径的分水岭，判高了浪费几个月，判低了报告被推翻重来。拿不准的功能，建议和认证机构在正式测试前做一次分类预审，这个钱花得值。
二、软件结构：Class B 三选一，Class C 必须"看着对手下棋"
2.1 Class B 的三种合法结构（H.9.12.1.2.2）
标准不指定你怎么写代码，但指定你的安全相关软件必须落在三种结构之一：
- 单通道 + 功能测试（single channel with functional test，H.3.16.5）：在应用软件执行前，先向功能单元注入测试数据跑一遍自检，典型做法是上电自检（POST）。
- 单通道 + 周期自检（single channel with periodic self-test，H.3.16.6）：自检嵌在固件里，运行期间周期执行。这是 MCU 自检库的主战场。
- 双通道无比较（dual channel without comparison，H.3.16.1）：两个相互独立的通道各自完成指定操作。
Class C 的结构（H.9.12.1.2.1）整体高一档：单通道 + 周期自检和监测、双通道（同源）带比较、双通道（相异）带比较，三选一。"带比较"意味着两个通道的输出要被比较器或互检机制核对，而且比较测不出来的故障还得另配周期功能测试或独立监测手段（H.9.12.2.2）。Class C 结构自然向下兼容 Class B（H.9.12.1.2.2 末句）。
结构之外还有两条容易被忽略的硬性要求：安全相关的软件段和数据必须防用户篡改（H.9.12.2.10）；软件及其控制下的安全相关硬件必须初始化和终止于 Table H.1 requirement H.4 声明的状态（H.9.12.2.11）。如果你的产品支持远程升级或远程致动，H.9.12.4 还有一整套额外要求（传输错误、用户授权、软件下载安装），联网产品逃不掉。
2.2 Table H.2：每个部件的故障该用什么措施接住
Table H.2 是 Annex H 的核心工作表：左列是部件（CPU、中断、存储器、I/O、通信……），中列是故障/错误模式，右列给出标准认可的措施清单，并标注该措施覆盖 Class B 还是 Class C。挑几条最常被评估的：
| 部件 | 故障/错误 | Class B 可接受措施（举例） |
|---|---|---|
| CPU 寄存器 | stuck-at | 功能测试，或周期自检（静态存储测试 / 单比特冗余字保护） |
| 程序计数器 | stuck at | 周期自检，或程序序列的独立时隙监测，或逻辑监测 |
| 寻址 | 错误地址 | 周期自检配合校验类措施 |
| 数据路径 | stuck-at | 单比特冗余字保护等 |
| RAM | 各类故障 | 周期自检（walkpat、Abraham、透明 GALPAT 等） |
| 程序存储器 | 数据错误 | 校验和 / CRC 类周期校验 |
| 时钟 | 频率偏移 | 独立时隙监测（需第二时钟源） |
| 外部通信 | 数据/寻址/时序/序列错误 | 封闭网络内的错误识别与处理手段（H.9.12.2.3） |
措施可以替换——H.9.12.2.5 允许用表外措施，只要你能论证它满足 Table H.2 列出的要求。检出时间也有硬约束：故障/错误检出不得晚于 Table H.1 requirement H.8 声明的时间，而这个声明的合理性会在故障分析中被评估（H.9.12.2.6）。检出之后，控制必须执行 requirement H.9 声明的响应；Class C 还要求这个响应由独立手段完成（H.9.12.2.7）。
三、文档链：V 模型不是形式主义，是评估的输入物
很多团队把 Annex H 理解成"写几个自检函数"，送到实验室才发现被打回的是文档。H.9.12.3 要求软件 Class B/C 采用图 H.1 的 V 模型生命周期（或等价的、含设计与测试阶段的结构化流程），内容取自 IEC 61508-3 并做了适配。左侧每一步都有对应的规格要求，右侧每一步都有对应的验证要求：
要准备的文档在 Table H.1 的 requirement H.3~H.12 里列着：软件序列文档、程序文档、软件故障分析、软件类别与结构、采用的故障/错误控制技术、检出时间、故障响应、故障反应时间、控制功能类别。架构层面，H.9.12.3.2.2 要求文档覆盖软硬件交互、模块划分与功能分配、调用层级、中断处理、数据流与访问限制、时序依赖；编码层面，Table H.6 建议的措施包括使用编码规范、不用动态对象、限制中断/指针/递归使用、高级语言禁用无条件跳转——基本上就是 MISRA 风格那一套。
两个实操提醒。其一，架构规格与代码之间要求用静态分析（控制流/数据流分析、走查）做双向验证（H.9.12.3.2.2.2、H.9.12.3.2.3.3），"代码写完补文档"的做法在这一步会露馅。其二，文档不是越多越好，而是要让评审工程师能沿着"安全功能 → 模块 → 措施 → 测试用例"一条线走通，断在哪节就补哪节。
四、MCU 厂商的 Class B 自检库：能省什么，省不了什么
主流 MCU 厂商都提供过认证的 Class B 自检库，这是把 H.9.12.2 落地的最快路径：
- Microchip 为 8/16/32 位 PIC 和 dsPIC 提供 Class B Safety Software Library，覆盖 CPU 寄存器、程序计数器、RAM、Flash、时钟、中断等项目的周期自检，库本身带认证证书；
- ST 的 X-CUBE-STL（STM32）和 STM8-CLASSB-SPL 提供同类能力，支持 IEC 60730 Class B；
- 国产厂商也在跟上——极海 APM32F427、G32M3101 系列 2026 年刚通过 IEC 60730/60335 功能安全认证，配套安全手册、软件安全库和证书，国产方案做出口家电时不用再绕回进口 MCU；
- 还有一个新趋势是安全功能器件化：Microchip 的 maXTouch MXT336UD-MAUHA1 系列触摸屏控制器直接把 Class B 固件做进了触摸芯片，烤箱、灶具这类触控产品可以省掉外部安全停止按钮和配套 MCU。
但有几条边界必须说清楚。第一，库过了认证不等于你的产品过了认证——库覆盖的是"部件级"自检函数，Table H.2 之外的系统级故障分析（H.13.2）、defined state 设计、故障反应时间声明，仍然是你自己的责任。第二，集成有硬件前提：以时隙监测类测试为例，系统必须提供至少两个相互独立的时钟源（比如内部振荡器 + 晶振，或晶振 + 市电频率），单时钟方案在评估时说不通。第三，自检执行期间的中断处理要设计清楚——Microchip 的官方应用笔记专门提醒，自检例程运行中若发生中断，ISR 会改变寄存器内容，导致自检上下文失配，所以哪些测试需要关中断、哪些可以容忍，要按库的集成指南逐项决定。
还有两个供应链管理上的坑。一是库的认证证书是和具体 MCU 型号、库版本绑定的，量产中途换芯片衍生型号或升级库版本，证书覆盖范围要重新核对，不能只看出货丝印相近。二是如果你的编译器优化等级把自检代码优化出了意想不到的行为（比如把"无用"的校验循环删掉），评估时拿出来的二进制和你想象的源码可能不是一回事——把自检段声明为禁止优化的区域，是各个库集成指南里反复出现的建议。
五、故障评估：Class B 看单故障，Class C 看双故障
软件结构之外，H.13.2 还从电路层面做故障评估。Class B 控制功能的设计目标是：任一单一故障（Table 14 列出的故障模式）发生后，控制保持或进入 defined state，第二个独立故障不考虑（H.13.2.2.1）。所谓 defined state 有三种合法形态（H.3.22.4）：被动进入输出端安全的状态、主动执行保护动作实现关断、或者继续运行且仍满足全部安全功能要求。Class C 则要求在第一、第二故障条件下都保持或进入 defined state，第三故障不考虑；第二故障只在两次故障之间有过一次启动序列、或距第一故障 24 h 之后才考虑（H.13.2.3.3）。
时序上有两个时间要声明清楚：fault tolerating time（故障发生到受控设备关断之间、应用能容忍的最长时间）和 fault reaction time（故障发生到控制到达 defined state 的时间），后者写进 Table H.1 requirement H.11，具体限值由对应 Part 2 规定。评估时还要注意 H.13.2.1.1 的一个细节：如果用时隙监测，必须同时对时间间隔的上限和下限敏感——只盯"跑飞了"不盯"跑快了"是不完整的。Class C 还有二级防护要求：当一级防护自身的单故障会使其失效时，必须提供二级防护，可以是物理独立的监测电路，也可以是被防护电路与一级防护之间的相互看守（比如微处理器反过来喂狗）。