软件生命周期：IEC 62304对智能药盒嵌入式软件的分类要求与文档体系

好，咱们进入正题。说到智能药盒的软件开发，绕不开一个标准——IEC 62304。这个标准，说白了就是医疗器械软件的“游戏规则”。我刚开始接触这个标准时，觉得它又厚又绕，后来做多了才发现，它其实就干一件事：根据你的软件对患者的风险，决定你要写多少文档、做多少测试。

智能药盒的嵌入式软件，到底属于哪一类？文档要写到什么程度？今天我就把这块掰开揉碎了讲清楚。

一、软件安全等级分类：你的药盒属于哪一类？

IEC 62304把软件分成三个等级：A级、B级、C级。等级越高，风险越大，要求越严。判断标准很简单——如果软件出故障，会不会导致患者死亡或重伤？

我见过不少团队，一上来就把智能药盒定为B级甚至C级，觉得“反正多做点总没错”。其实没必要。分级不是越严越好，而是越准越好。分级高了，文档量翻倍，开发周期拉长，成本也上去了。

咱们具体分析一下智能药盒的场景：

• 核心功能：定时提醒服药、记录服药状态、锁定药仓防止误取
• 潜在风险：漏提醒、错误解锁、时间偏差
• 最坏后果：患者漏服或错服药物，可能导致病情加重，但通常不会直接致命

根据我的经验，绝大多数智能药盒的嵌入式软件，属于A级。为什么？因为软件故障不会直接导致不可逆的伤害。举个例子，药盒没提醒，患者可能少吃了一顿降压药，血压波动一下，但不会当场出大事。当然，如果你设计的药盒是给ICU患者用的，那另当别论。

不过，这里有个坑。有些智能药盒集成了剂量计算或药物交互检查功能。一旦这些功能出问题，后果就严重了。比如，药盒自动算出患者该吃2片，但算错了给了4片——这就可能涉及B级甚至C级。所以，功能边界决定了安全等级，不是整个产品一刀切。

二、A级软件要写哪些文档？

很多人以为A级软件不用写文档，随便搞搞就行。大错特错。IEC 62304对A级的要求虽然比B/C级少，但该有的东西一样不能缺。我整理了一下，智能药盒A级软件至少需要以下文档：

文档名称	核心内容	我的建议
软件需求规格说明书	功能需求、接口需求、性能指标	用自然语言写清楚，别用伪代码
软件架构描述	模块划分、任务调度、通信方式	画个框图，比写一千字管用
软件详细设计	关键算法、状态机、数据结构	重点写清楚状态切换逻辑
单元测试报告	每个模块的测试用例和结果	覆盖率不用100%，但核心路径必须覆盖
集成测试报告	模块间接口测试、系统联调	重点关注时钟同步和通信稳定性
软件问题清单	已知缺陷、已修复记录、未解决项	保持实时更新，别等审核前才补

嗯，这里要注意。A级软件不需要做软件风险管理文档，但需要把风险分析结果体现在需求文档里。说白了，你不需要单独写一本风险报告，但要在需求里说清楚“我考虑了哪些风险，怎么规避的”。

三、嵌入式软件特有的文档要求

智能药盒的嵌入式软件，跟纯PC软件不一样。它跑在资源受限的MCU上，有实时性要求，还要跟硬件打交道。所以，IEC 62304里有些条款对嵌入式软件特别重要。

我个人习惯，在文档体系里额外增加以下几项：

• 中断响应时间分析：药盒的按键响应、闹钟触发，这些都有实时要求。你得证明在最坏情况下，中断不会丢。
• 看门狗策略文档：嵌入式系统容易死机，看门狗怎么喂、喂多久、复位后怎么恢复，这些都要写清楚。
• 低功耗模式说明：智能药盒通常用电池，休眠唤醒的时序、外设的电源管理，这些容易出bug。
• 固件升级流程：OTA升级时，万一断电怎么办？升级失败怎么回滚？这些必须提前设计好。

四、文档体系的结构建议

我见过很多团队，文档写得乱七八糟，审核时被问得哑口无言。其实，文档体系不需要多复杂，关键是可追溯。什么意思？就是需求、设计、测试、问题，这四者要能串起来。

举个例子：需求里写“药盒在低电量时发出报警声”。那么，设计文档里就要有对应的模块和逻辑，测试报告里要有对应的测试用例，问题清单里要记录这个功能有没有出过bug。一条线拉到底，清清楚楚。

我建议的文档结构是这样的：

1. 顶层：软件需求规格说明书（SRS）——所有功能的源头
2. 中间层：架构设计、详细设计——怎么实现需求
3. 底层：测试报告、问题清单——验证需求是否实现

每一层之间，用需求编号做关联。比如，需求编号REQ-001，在设计中标注“对应REQ-001”，在测试中标注“验证REQ-001”。这样审核老师一看就懂，你自己维护起来也方便。

五、A级软件的生命周期活动

IEC 62304规定了软件生命周期要干哪些事。A级软件虽然要求少，但该走的流程一步不能省。我列一下核心活动：

• 软件开发计划：定好时间表、资源分配、工具链。别小看这一步，很多项目延期就是因为计划没做好。
• 需求分析：把用户需求转化成软件需求。这里要注意，用户说“提醒我吃药”，软件需求要写成“每天8:00、12:00、18:00触发蜂鸣器，持续30秒”。
• 架构设计：划分模块，定义接口。嵌入式软件通常按任务划分，比如显示任务、通信任务、闹钟任务。
• 详细设计：写清楚每个模块怎么实现。我习惯用状态机来描述，清晰又不容易遗漏。
• 编码与测试：写代码，做单元测试。A级软件不要求代码覆盖率工具，但你自己心里要有数。
• 集成测试：把模块拼起来，看能不能跑通。智能药盒的集成测试，重点看通信和时序。
• 系统测试：整机测试，模拟真实使用场景。比如，连续运行7天，看会不会死机。
• 发布与维护：出问题怎么办？要有问题反馈和修复流程。

你看，A级软件的生命周期跟B/C级差不多，只是每个活动的深度和文档量不同。说白了，A级可以做得“轻”一点，但不能“跳”过去。

六、我的经验总结

做了这么多年医疗器械软件，我最大的感受是：文档不是写给审核老师看的，是写给自己看的。你想想看，一个项目做了一年半载，代码改了无数版，如果没有文档，三个月后你自己都看不懂当初为什么那么写。

所以，我建议你从一开始就把文档体系搭好。不用追求完美，先有再优。哪怕一开始只是画个框图、列个需求列表，也比什么都没有强。随着项目推进，慢慢补充完善。

最后说一句：IEC 62304不是枷锁，而是工具。它帮你把风险想在前头，把问题暴露在早期。等你真正用熟了，会发现它其实是在帮你省钱、省时间。

好，这一章就到这里。下一章咱们聊聊智能药盒的嵌入式软件架构设计，怎么搭一个既稳定又容易维护的框架。