3、IEC 62304 软件生命周期：软件安全等级分类（A/B/C）、软件开发计划、软件需求分析
好，咱们直接进入正题。这一章聊的是IEC 62304标准里最核心的几个概念。说实话，我当年第一次接触这个标准时，光看目录就有点懵。但干了几款呼吸机认证项目之后，我发现其实没那么玄乎。说白了，它就是一套帮你把软件做安全、做规范的流程。
3.1 软件安全等级分类：A/B/C 到底怎么分？
这个分类是整个IEC 62304的基石。你想想看，呼吸机上的软件，有的代码只是显示个波形，有的代码直接控制吸气阀。这两者的风险能一样吗？
标准把软件安全等级分成三类：
- A级（无伤大雅）：软件故障不会导致患者受伤。比如呼吸机的日志记录功能、Wi-Fi模块的驱动。我见过有些团队把所有驱动都归到B级，其实没必要，反而增加了验证工作量。
- B级（可能受伤）：软件故障可能导致非永久性伤害。比如报警延迟、参数显示偏差。嗯，这里要注意，呼吸机上的大部分功能模块其实都在B级。
- C级（可能致死）：软件故障可能导致患者死亡或严重永久伤害。比如吸气压力控制、呼气阀控制、氧浓度调节。这些是红线，碰都不能碰错。
关键判断原则：
一个软件单元的安全等级，取决于它可能造成的最严重后果。不是看它本身有多复杂，而是看它坏了会怎样。
我个人习惯的做法是：先画一张系统功能框图，把每个软件模块和它控制的硬件、以及可能导致的临床后果连起来。这样分类就一目了然了。我曾经在一个项目中，发现一个看似简单的“流量传感器滤波算法”被归到了A级，但仔细一分析——如果滤波出错导致流量测量偏差，进而触发错误的压力控制——这其实是个C级模块。
避坑指南：千万不要把整个呼吸机软件统一标成一个等级。我见过有公司把所有代码都标成C级，结果验证成本翻了3倍，认证周期拖了半年。正确的做法是：把C级代码隔离出来，单独管理，A/B级代码可以适当简化流程。
3.2 软件开发计划：不是写个文档就完事
软件开发计划（SDP），很多人把它当成一个应付审核的文档。其实不然。一个好的SDP，是你整个项目的导航图。
标准要求SDP至少包含这些内容：
| 要素 | 说明 | 我的经验 |
|---|---|---|
| 软件生命周期模型 | 选瀑布、迭代还是敏捷？ | 呼吸机我建议用迭代模型，但C级模块必须走严格瀑布 |
| 安全等级划分结果 | 每个软件单元的安全等级 | 用表格列出来，审核员最爱看这个 |
| 交付物清单 | 需求文档、设计文档、测试报告等 | 别漏了“软件异常处理说明” |
| 验证与确认策略 | 单元测试、集成测试、系统测试怎么做 | C级模块要100%语句覆盖+分支覆盖 |
| 风险管理接口 | 如何与ISO 14971风险分析联动 | 每个软件缺陷都要回灌到风险分析中 |
我建议你在SDP里明确一点：每个安全等级对应的开发活动深度。比如：
- A级：可以不做单元测试，但要有代码走查
- B级：需要单元测试，语句覆盖≥80%
- C级：单元测试+集成测试，语句覆盖100%，分支覆盖≥90%
小技巧：SDP里最好附上一张“软件架构与安全等级映射图”。把每个模块用颜色标出来——红色是C级，黄色是B级，绿色是A级。审核员一看就懂，你后面做验证时也方便追溯。
3.3 软件需求分析：别让医生和工程师鸡同鸭讲
软件需求分析，说白了就是把临床需求翻译成工程师能懂的技术语言。这一步做不好，后面全是坑。
标准要求软件需求必须包含：
- 功能需求：软件要做什么。比如“当气道压力超过40 cmH₂O时，在100ms内打开泄压阀”。
- 性能需求：做到什么程度。比如“压力控制精度±2 cmH₂O”。
- 接口需求：和谁打交道。比如“与压力传感器的SPI通信速率不低于1MHz”。
- 安全需求：出了故障怎么办。比如“检测到传感器断线时，自动切换到备用传感器并触发报警”。
- 异常处理需求：边界情况。比如“电池电量低于10%时，强制切换到交流供电并发出声光报警”。
我个人习惯用需求追溯矩阵来管理。每一行是一条需求，列分别是：需求ID、来源（临床需求/风险分析）、安全等级、测试用例ID、验证结果。这样审核时，对方问“这条需求测了没”，你一秒就能指出来。
一个真实的教训：我曾经接手过一个项目，需求文档里写着“报警功能正常”。你想想看，什么叫“正常”？是声音大于多少分贝？还是延迟小于多少毫秒？后来我们重新梳理，把一条需求拆成了12条可测试的需求。审核员看了直点头。
写需求时，我建议用“条件-动作-结果”的句式。比如：
条件：患者回路发生堵塞（气道压力 > 50 cmH₂O 持续 200ms）
动作：系统在 50ms 内关闭吸气阀，同时打开呼气阀
结果：气道压力在 300ms 内降至 < 10 cmH₂O，并在屏幕上显示“回路堵塞”报警这样的需求，测试工程师看了就知道怎么测，开发工程师看了就知道怎么实现。不会出现“我以为你懂了”的尴尬。
注意：C级软件单元的需求，必须经过正式评审。评审要有记录，参会人要签字。这不是走形式，而是万一出了事，你能证明自己当时认真考虑过。
好了，这一章的内容就这些。下一章我们会聊软件架构设计和详细设计，那才是真正考验嵌入式工程师功底的地方。到时候我会分享一些我在RTOS任务划分上的踩坑经历，保证有用。