结论:软件没冻结,报告只对送检的那一版负责
含软件的医用电气设备送检,绕不开一句话:检测结论只对提交时的那一版软件有效。这不是实验室推卸责任,而是 IEC 62304 与 IEC 60601-1 的基本逻辑——软件是产品的组成部分,软件变了,产品就变了。
所以送检准备的核心动作只有两个:把版本冻结,把变更做成可追溯的。这两件事做扎实,后续所有沟通都有据可依;做不好,项目就会在"到底测的是哪一版"这个问题上反复打转,而这种打转不产生任何技术价值。
先把"一版"的定义写清楚
很多团队栽在这一步:每个人对"版本"的理解不一样。研发说的是代码仓库里的某个提交,测试说的是打包出来的固件,市场说的是对外宣称的产品版本。三个说法互不对应,送检时报一个标识上去,实验室拿到手根本不知道对应哪个产物。
可执行的做法是,在送检前把版本标识规则写成一页纸,明确下面几点:
- 对外发布的版本标识由哪几段构成,每一段在什么情况下会变。
- 哪一段是给使用者看的,哪一段是内部构建号。
- 使用者在设备界面的什么位置能看到版本,看到的是完整标识还是截断之后的。
- 送检申请表上填的、设备界面显示的、随机文件里印的,是不是同一个串。
这四点确认完,后面的沟通成本会下降一大截。设备界面显示的版本与文件里印的版本对不上,是相当常见的退回原因,而它本可以在出发前就避免。
变更类型对照:什么必须报,什么会导致重做
送检期间难免要改软件。改之前先看这张表,判断这次改动会带来什么后果。
| 变更内容 | 对已完成结论的影响 | 需要补什么 | 常见误判 |
|---|---|---|---|
| 界面文案、语言包 | 一般不影响电气安全类结论 | 更新随机文件与界面显示的对照 | 以为"只是改字",结果文件里的界面图全部作废 |
| 报警逻辑、限值判断 | 直接影响报警与安全相关功能的试验 | 相关项目重做 | 当作参数微调,不主动申报 |
| 驱动层、通信协议 | 可能影响电磁兼容与功能表现 | 按对应分部重新评估,具体以标准原文现行有效版本确认 | 认为不涉及应用层就不必说明 |
| 缺陷修复且不改功能 | 取决于该缺陷本身是否与安全相关 | 提供缺陷记录与影响分析 | 用一句"修复问题"带过,无法追溯 |
| 外部组件升级 | 取决于该组件承担的职责 | 更新 SOUP 清单与对应的风险评估 | 忘记外部组件也属于软件组成部分 |
| 编译工具链或编译选项变化 | 生成物不同,构建不可复现 | 重新出具构建记录并说明差异 | 认为源码没动就等于软件没变 |
表里"编译工具链变化"这一行值得单独说一句:源码相同、工具链不同,生成的二进制可以有实质差异。如果实验室或者审核方要求提供构建可复现的证据,而你只能拿出源码,这个问题会一直挂在那里,拖到申报前也解决不了。
软件安全性级别要在送检之前定完
IEC 62304 要求对软件做安全性级别的判定,这个判定结果直接决定了需要提交哪些过程文档、需要做到什么颗粒度的验证。实操上要注意两点。
其一,级别判定的依据来自风险分析,不能拍脑袋。判定过程里引用的危害与风险控制措施,要能在 ISO 14971 框架下的风险管理文件里找到出处。两边对不上,评审时会被直接追问,而现场是补不出来的。
其二,判定结果一旦确定,送检材料清单也就随之固定。到了受理阶段才发现级别定高了、材料准备不足,只能临时补;定低了,又要面对"依据不充分"的质疑。这一步建议在方案阶段做完并留档,留档的意义在于把当时的判断依据固定下来,免得半年后没人说得清为什么这么定。
风险管理文件与检测结论之间怎么逐项对应,是另一个独立话题,思路可以在 检测知识 里单独看,这里不展开。
送检包里应该有什么
除了样机本身,含软件产品的送检包建议至少包含以下内容。缺哪一项,就会多产生一轮往返。
- 版本标识规则说明,以及本次送检对应的完整版本标识。
- 构建记录:什么源码状态、什么工具链、什么配置,生成了送检的这个产物。
- 软件功能清单,标明哪些功能与安全相关、哪些不相关。
- SOUP 清单,含每个外部组件的用途、来源,以及已知问题的处理方式。
- 软件相关的风险控制措施清单,以及它们分别在什么条件下生效。
- 用于验证的操作说明:工程师如何进入各功能界面、如何触发报警、在哪里读取版本。
- 若有专用上位机或调试工具,一并提供并说明使用方式。
尤其是末尾这一项。很多项目卡住,是因为设备上的某个功能实验室根本进不去,而研发那边默认"我们自己都是用调试工具进的"。这类信息不写出来,就是纯粹的时间浪费,而且浪费的是双方的时间。
可追溯做没做到位,有一个简单的检验方法
随便拿一份检测报告出来,看能不能沿着上面的版本标识,一路回到当时的源码状态和构建配置。链条上任何一环断了,可追溯就是没做到。这个检验不需要工具,自己花点功夫走一遍就知道。
常见的断点有三处:一是设备上显示的版本与申报的不一致;二是版本标识对应不到确定的源码状态,因为构建时用的是"当前分支末端"而不是打了标签的确定点;三是构建环境没有记录,换一台机器编不出同样的东西。这三处提前堵上,后面无论是做变更评估还是应对审核,都会轻松很多。
三个典型失败场景与代价
场景一:样机送到实验室,试验做了一部分,研发那边并行修了几个缺陷并把新固件刷进了另一台备用样机,后来两台样机混着用。结果是所有已完成项目的软件版本存疑,只能重做,整个排期作废。
场景二:随机文件里印的版本标识是排版时随手写上去的,与实际固件不符。文件核查环节直接判不符合,重新排版加重新打印,包装印刷件跟着报废。这类损失往往落在采购口,而问题出在研发口,复盘的时候还容易扯皮。
场景三:外部通信组件在送检期间升了一个小版本,团队没当回事。后续被追问该组件已知问题的处理情况时,发现新旧两版的问题清单不同,风险评估要重做,连带影响到软件安全性级别判定的依据。
这三种场景的共同点是:成本都不出在检测本身,而出在返工与排期上。把版本冻结写进项目节点,比事后补救划算得多。受理与排期方式见 检测流程;准备过程中遇到拿不准的地方,也可以走 技术支持 先问清楚再动手。
关于认可范围的说明
含软件的产品经常涉及多份报告拼接使用,这里明确一点:认可标志只证明实验室在其认可范围内具备相应技术能力,不构成对目标市场准入结果的承诺。软件相关的过程文档能否被目标市场的主管部门接受,还要看当地的具体审查要求,建议在方案阶段就把目标市场讲清楚,而不是等报告出来再问。
电磁兼容相关的项目同样与软件版本绑定,变更之后需要重新评估的范围,可以参考 电磁兼容检测。
想少走弯路,重心不在样机
含软件的产品,送检准备的重心不在样机,而在文档与版本管理。把版本标识规则、构建记录、SOUP 清单这三样先做扎实,后面的沟通基本不会出大问题;这三样含糊,再好的样机也救不回来。
需要在方案阶段就把送检材料清单确认下来,或者想让人帮着看一遍现有的版本管理够不够用,拨打 132 4819 8029 说明产品形态和目标市场即可,也可以直接 联系报价。