1. 医疗设备固件工程导论

在医疗设备中，固件并不是“跑在硬件上的普通程序”这么简单。它通常直接参与信号采集、剂量控制、报警判断、通信协议、状态机切换和安全联锁，是设备预期用途能否成立的关键组成部分。以一台输液泵为例，压力传感器采样、阻塞报警阈值判断、步进电机速度闭环、电池管理、与护士站的通信，以及升级失败时的回退，都依赖固件。固件一旦缺陷暴露，后果可能是剂量错误、报警失效或设备不可用，因此它同时属于工程对象和法规对象。

理解固件工程，先要区分它与应用软件、硬件和配置数据的边界。硬件提供电气与机械能力，固件把硬件能力组织成可预测的行为；应用软件通常负责人机界面、联网和业务逻辑；配置数据则决定具体型号、语言、参数集。很多医疗设备把关键安全逻辑放在固件中，因为固件离传感器和执行器更近，实时性更好，但也因此更难在现场修改。固件工程的核心目标不是“功能多”，而是在确定的硬件与使用环境下，持续保持安全、有效和可追溯。

从生命周期看，医疗设备固件不是一次开发交付就结束，而是覆盖概念、需求、架构、实现、验证、确认、发布、维护、升级和退役。IEC 62304 把软件安全等级分为 A、B、C：A 级指软件失效不会造成伤害或不合理风险；B 级指可能造成非严重伤害；C 级指可能造成死亡或严重伤害。等级不是按代码规模划分，而是按软件失效对危害的贡献划分。等级越高，需求追溯、架构设计、单元验证、集成测试、风险控制和变更控制的严格度越高。例如，输液泵的阻塞报警判断若失效可能导致严重伤害，通常按 C 级处理；而设备日志导出功能若失效只影响可维护性，可能按 A 级处理。

法规与标准并不是彼此孤立的。IEC 62304 规定软件生命周期过程；ISO 14971 提供风险管理框架；IEC 62366 关注可用性工程；IEC 60601-1 及其并列标准约束电气安全和基本性能。FDA 的预市指南要求上市前提交软件描述、风险分析、验证与确认证据，尤其关注网络安全和现成软件；上市后指南则要求建立上市后监督、缺陷处理、纠正和移除、以及网络安全漏洞响应。欧盟 MDR 则把软件纳入医疗器械定义，按风险分类，并要求符合通用安全与性能要求、临床评价、上市后监督和唯一器械标识。对固件团队而言，这些要求最终会落到需求、设计、测试、发布、变更和记录上。

安全升级是固件生命周期中最容易出问题的环节。医疗设备的升级不是“刷个包重启”，而要回答：升级包是否真实、完整、适用于当前型号和硬件版本；升级过程中断电或通信中断怎么办；升级后如何确认版本和功能正常；失败后能否回退到已知安全版本；升级是否改变已批准的预期用途或风险控制措施。一个可落地的升级流程通常包含版本识别、镜像签名校验、双分区或备份区、升级前条件检查、写入与校验、回滚策略、升级后自检和审计记录。下面这张图把固件在设备中的位置、生命周期主线与安全升级的关键控制点放在同一张关系图中，便于建立整体认识。

把这张图落到实际工作中，可以用一个输液泵固件升级的教学示例来理解。假设当前设备固件版本为 2.3.1，硬件版本为 H2，升级包为 2.4.0，升级前检查项包括：设备处于空闲状态、电池电量不低于 50%、与升级工具的通信稳定、当前无报警未处理。升级包内包含镜像、版本清单和签名。设备先校验签名和型号匹配，再把新镜像写入备份分区，写入完成后计算校验值并与清单比对。比对通过后，设备标记“下次启动切换到新分区”，重启后运行新固件并执行自检：传感器零点、报警阈值、电机响应、通信心跳。自检通过则记录版本 2.4.0 和升级时间；若自检失败或启动异常，引导程序切回旧分区 2.3.1，并记录失败原因。这个示例说明，安全升级的关键不是“写入成功”，而是可验证、可回退、可追溯。

对固件工程师来说，法规要求最终会转化为日常可执行的动作：需求要能追溯到风险控制措施；代码变更要评估对安全等级和已有验证的影响；测试要覆盖正常、异常和边界条件；发布要保留版本、配置、工具链和校验记录；上市后要能快速定位缺陷、评估风险并决定是否升级或召回。IEC 62304 关注过程，ISO 14971 关注风险，FDA 和 MDR 关注证据与监督，三者共同构成固件从开发到退市的约束框架。理解这一点，后续章节中的需求、架构、测试、发布和升级策略才有统一的判断依据。