2. 医疗法规与标准对架构的驱动

在医疗嵌入式软件领域，架构设计从来不是纯粹的技术选择。一个看似简单的“把报警判断放在主循环还是独立任务中”的决定，背后可能牵涉到安全分级、风险控制措施的有效性、标准符合性证据链，以及监管审查时能否自证清白。IEC 62304、ISO 14971、IEC 60601-1 和 FDA 指南共同构成了一套“外部约束系统”，它们不直接规定你必须用哪种 RTOS 或哪种通信协议，但会通过安全分级、风险控制、结构要求和文档要求，深刻影响架构的边界划分、模块隔离、冗余策略和可追溯性设计。

一、四类标准/指南在架构决策中的角色分工

IEC 62304 是医疗器械软件生命周期过程标准，它把软件安全分级为 A、B、C 三级：A 级指软件失效不会造成伤害或不合理风险；B 级指软件失效可能造成非严重伤害；C 级指软件失效可能造成死亡或严重伤害。分级结果直接决定架构必须提供多少“隔离”和“可验证性”。例如，C 级软件通常要求将安全相关功能与非安全相关功能在架构上分离，避免非安全模块的缺陷传播到安全路径。

ISO 14971 是风险管理标准，它要求从“伤害”反推“风险控制措施”，再反推“软件安全需求”。在架构层面，这意味着每个安全相关模块都应能追溯到具体的风险控制措施。例如，如果风险分析识别出“输液泵流速过高可能导致药物过量”，那么架构中必须存在独立的流速监控通道或硬件限流机制，并且该机制不能被主控制软件的单一故障所绕过。

IEC 60601-1 是医用电气设备通用安全标准，它更关注电气安全、机械安全和基本性能。对软件架构的影响主要体现在“基本性能”的识别与保持：哪些软件功能一旦失效或降级，会导致设备不再满足基本性能？这些功能在架构中应被标记为关键路径，并具备自检、看门狗、冗余或安全状态切换能力。

FDA 指南（如《General Principles of Software Validation》和《Cybersecurity for Medical Devices》）则更强调上市前审查中的“设计控制”和“网络安全”。它要求架构文档能够说明：安全相关功能如何被验证、网络接口如何被隔离、软件更新如何被授权和回滚。这些要求会直接影响通信架构、启动链和固件更新模块的设计。

二、安全分级如何改变架构的“粒度”

安全分级不是贴在文档封面上的标签，它会直接改变架构的粒度。以输液泵为例，假设风险分析将“流速控制”定为 C 级，“电池管理”定为 B 级，“蓝牙通信”定为 A 级。那么架构上通常需要做到：流速控制任务拥有独立的看门狗和独立的 AD 采样通道，不能与蓝牙协议栈共享同一个任务优先级或同一个内存池；电池管理可以共享部分系统服务，但需要独立的过流保护逻辑；蓝牙通信可以运行在非安全分区，但必须通过受控接口向安全分区传递数据，且该接口要有长度校验、超时和拒绝非法命令的能力。

这种“分级隔离”在 RTOS 上通常体现为：C 级任务使用独立栈空间和独立定时器，B 级任务允许共享系统服务但需有边界检查，A 级任务可以运行在低优先级后台。如果资源紧张，无法做到完全独立，则必须在架构文档中说明“共享资源已通过 MMU/MPU 保护”或“共享资源失效不会导致安全功能失效”，并给出分析依据。

三、ISO 14971 如何把风险控制“翻译”成架构约束

ISO 14971 的核心逻辑是：识别危害 → 估计风险 → 决定风险控制措施 → 验证措施有效性。在软件架构中，风险控制措施通常表现为三种形式：

• 预防型：通过架构隔离防止故障传播。例如，将“剂量计算”与“电机驱动”放在不同分区，剂量计算错误不会直接改写电机 PWM 寄存器。
• 检测型：通过独立监控通道发现异常。例如，主控 MCU 计算流速，独立监控 MCU 通过另一路传感器复核流速，两者偏差超过阈值即触发报警并停泵。
• 缓解型：通过安全状态切换降低伤害。例如，检测到异常后，架构必须保证能在规定时间内切断电机使能、关闭阀门并点亮报警灯。

在架构设计文档中，每个风险控制措施都应有一个唯一标识，并映射到具体的模块、接口和验证用例。例如，风险控制措施 RC-07“防止流速超过设定值 20%”对应架构模块“FlowMonitorTask”和“MotorCutoffDriver”，对应验证用例“TC-07-01 注入流速偏差 +25% 并观察 200ms 内停泵”。这种追溯关系是 FDA 审查和 IEC 62304 审核中最常被检查的内容之一。

四、IEC 60601-1 对“基本性能”的架构要求

IEC 60601-1 要求制造商识别设备的“基本性能”，即一旦丧失或降级就会导致不可接受风险的性能。对软件架构而言，基本性能通常对应一组“关键功能”，这些功能在架构中应具备：

• 启动时自检，确认关键外设（ADC、PWM、看门狗、通信）可用；
• 运行时周期性自检，发现故障后进入安全状态；
• 故障注入测试接口，便于验证安全机制是否有效；
• 独立的故障日志，记录故障类型、时间和系统状态。

例如，某监护仪将“心率报警”定为基本性能。架构上，心率计算任务和报警输出任务应具备独立看门狗；如果心率计算任务超时未刷新，报警任务应在 500ms 内发出技术报警，而不是继续显示旧数据。这种“超时即安全”的设计，是 IEC 60601-1 对架构最直接的影响之一。

五、FDA 指南对通信与更新架构的影响

FDA 网络安全指南要求医疗器械具备“网络安全的全生命周期管理”。在架构层面，这意味着：

• 网络接口与安全关键功能之间必须有明确的隔离边界，通常通过网关或消息代理实现；
• 固件更新必须经过签名验证，且支持回滚到已知安全版本；
• 调试接口（如 JTAG、UART）在生产版本中应禁用或受认证保护；
• 安全日志应记录登录、更新、配置变更等事件，并防止篡改。

这些要求会直接改变启动架构：Bootloader 需要验证应用固件的签名，应用固件需要验证更新包的签名，更新失败时 Bootloader 应能回滚到备份分区。如果架构中没有预留双分区或备份区，后期再补会非常困难。

六、文档要求：架构文档不是“事后补”

IEC 62304 和 FDA 设计控制都要求架构文档与需求、风险、验证保持双向追溯。实际执行时，建议在架构设计阶段就维护一张“架构-风险-验证”追溯表，至少包含以下字段：

这张表在审查时比任何文字描述都更有说服力。它让审查员能快速确认：每个安全相关模块都有明确的风险来源和验证证据，每个风险控制措施都没有“悬空”。如果某个模块在表中找不到对应的风险控制措施，要么它被错误地标高了安全级别，要么风险分析遗漏了它。

总结来看，IEC 62304 决定“分几级、隔离到什么程度”，ISO 14971 决定“每个模块为什么存在、要防住什么”，IEC 60601-1 决定“哪些功能不能失效、失效后如何安全”，FDA 指南决定“通信和更新如何被约束、证据如何被审查”。四者共同作用，使医疗嵌入式软件架构从“能跑就行”变成“可分级、可追溯、可验证、可审查”的工程对象。