第3章 IEC 62304 标准解读

3、IEC 62304 标准解读：软件生命周期模型、软件安全等级分类（A/B/C）、软件开发流程要求、文档体系

好，咱们进入正题。IEC 62304，这个标准在医疗软件领域，说白了就是「圣经」。你做的贴片、监护仪、胰岛素泵，只要里面跑了代码，就绕不开它。我最早接触这个标准是在一个血糖连续监测项目上，当时觉得不就是写个文档嘛，后来被审核员问得满头大汗……嗯，从那以后我再也不敢小看它了。

IEC 62304 并没有强制你用什么模型。瀑布、V模型、迭代、敏捷，都可以。但有一条红线——你必须定义清楚你的生命周期模型，并且严格执行。

我个人习惯用 V 模型做医疗贴片项目。为什么？因为 V 模型的左侧是需求与设计，右侧是测试与验证，左右一一对应。你想想看，贴片上的算法如果错了，可能直接导致误报警或者漏报警，这是人命关天的事。V 模型能让你清晰地追溯：每个需求都有对应的测试用例。

关键点：无论你选什么模型，标准要求你必须包含以下阶段：

我在项目中遇到过一家公司，他们用敏捷开发，sprint 跑得飞起，但审核时拿不出完整的生命周期定义。审核员直接开了 major 不符合项。所以记住：模型不重要，定义和执行才重要。

这是 IEC 62304 最核心的概念之一。标准把软件安全等级分为三类：

等级	定义	典型场景
A 级	软件不会导致不可接受的风险	日志记录、数据显示（无决策）
B 级	软件可能导致不可接受的风险，但不会直接导致死亡或严重伤害	报警阈值计算、趋势分析
C 级	软件可能导致死亡或严重伤害	闭环给药控制、起搏器算法

怎么确定你的软件是哪个等级？标准说：基于风险管理。说白了，你要先做风险分析，看看软件失效后会造成什么后果。

我的经验：很多团队喜欢把等级定低一点，觉得省事。我曾经见过一个贴片项目，把心率算法定为 B 级，但风险分析显示算法失效可能导致漏报室颤——这明显是 C 级。审核员一眼就看穿了。别耍小聪明，实事求是地定级，后面反而少麻烦。

不同等级对开发流程的要求也不同：

标准把开发流程拆成了几个大块。我挑重点说：

你得写一份《软件开发计划》，里面要包含：生命周期模型、里程碑、资源分配、工具链、配置管理策略。我曾经见过一份计划写了 200 页，但核心内容没写清楚。审核员问：「你的测试策略是什么？」答不上来。计划不在厚，在精。

需求必须可追溯、可验证。什么叫可验证？「系统应稳定运行」——这不是需求，这是废话。「系统在 24 小时内无故障运行概率 ≥ 99.9%」——这才是需求。我习惯用表格把每个需求编号，对应到风险分析和测试用例。

架构图必须画清楚。我建议用分层架构，把安全关键功能和非安全关键功能隔离开。比如贴片上的无线通信模块和给药控制模块，必须物理或逻辑隔离。为什么？因为无线模块可能被攻击，如果它和给药模块混在一起，后果不堪设想。

编码规范必须定。MISRA C、CERT C，选一个。我个人的习惯是强制开启所有编译器警告，并且把警告当错误处理。你想想看，一个未初始化的变量，在贴片上可能跑几个月才出问题，到时候怎么查？

测试分三层：单元测试、集成测试、系统测试。C 级软件要求单元测试覆盖率达到 100% 的语句覆盖和分支覆盖。别觉得苛刻，我见过一个起搏器项目，因为一个分支没测到，导致在特定条件下起搏脉冲丢失——这是要出人命的。

警告：不要用「我们测试过了」来糊弄审核。测试必须有计划、有用例、有结果、有回归。我曾经被审核员要求现场演示测试过程，结果发现测试环境跟实际产品不一致……嗯，那次被开了 critical 不符合项。

IEC 62304 对文档的要求，说白了就是「你说你做了什么，你写下来；你写下来的，你做到了」。文档不是负担，是证据。

标准要求的核心文档包括：

我建议你用模板来管理文档。每个文档都有固定的章节结构，这样审核员看起来也舒服。另外，文档版本号必须和代码版本号对应。我曾经在一个项目里发现，文档版本是 1.2，代码版本是 2.0，审核员直接问：「你们到底按哪个版本做的？」场面一度非常尴尬。

一个小技巧：用 Git 管理文档，每次修改都写清楚变更原因。审核员最喜欢看变更历史，因为这能反映你的开发过程是否受控。

最后说一句：IEC 62304 不是用来折磨你的，它是用来保护患者的。你做的每一个贴片，都可能贴在某个老人、某个孩子身上。标准里的每一条要求，背后都可能是一个血淋淋的教训。认真对待它，就是认真对待生命。