简介：这份ISPE GAMP良好实践指南第二版，面向制药与生物技术企业的验证、质量及自动化工程师，帮助其以基于风险的方法设计、实施和维护GxP过程控制系统，并应对FDA 21 CFR Part 11等法规要求。压缩包内仅含1个PDF文件，约17.46MB，虽为单一文档，却系统覆盖风险评估、生命周期管理、验证与确认、变更控制、数据完整性、用户培训、故障预防及持续监控等模块，并给出硬件、软件、网络与外部因素的分析思路。目前已有178人学习下载。读者可借此建立从需求定义到退役的全流程风险控制框架，理解如何将风险融入系统验证与运行确认，并获取审计追踪、权限管理、备份策略等落地参考，适合作为制药过程控制合规建设的案头指南。
1. 别再把验证工时花在按钮上：GxP 过程控制系统的风险起点
不少自动化工程师第一次接触 GxP 过程控制系统（Process Control Systems）验证时，会把大部分精力放在操作界面的按钮响应、报警弹窗颜色和报表导出格式上，却在一次 PID 参数整定后只在变更单里写一句“工艺未变化”就结束了流程。现场检查时被追问的往往不是按钮，而是那条参数整定有没有经过风险评估、有没有建立与批记录放行之间的追溯关系。
基于风险的方法不是给验证额外加戏，而是把有限的 IQ/OQ/PQ 测试工时、文件评审和复核资源，优先投到最可能影响产品质量、患者安全和数据完整性的控制节点上。它回答的核心问题很直接：这个控制回路或这段 PLC 逻辑，值不值得用完整测试深度去覆盖；如果答案是否定的，用什么证据证明低风险判断本身成立。
适合读下去的人有三类：负责 DCS/PLC/SCADA 验证的自动化工程师、负责数据完整性与放行的 QA、以及接手老旧过程控制系统整体整改的运维负责人。三者的共同痛点是验证资源永远不够，而检查员永远会问“你凭什么认为这里风险低”。
2. GxP 过程控制系统的风险分级：从 GAMP 5 软件分类到关键性评估
风险分级不是给系统贴一个“高/中/低”就完事。常见做法是先把过程控制系统拆成可独立评估的节点，再用软件分类确定基线验证动作，用关键性评分确定额外测试深度。两个维度交叉之后，验证计划才有可辩护的颗粒度。
2.1 GAMP 5 软件类别在 PLC、SCADA 与 DCS 上的映射
GAMP 5 的软件类别经常被误当成风险等级。类别 5 的定制 PLC 逻辑不一定是高风险，类别 4 的 DCS 组态也不一定是低风险。它描述的是“软件从哪里来、需要多少设计层面的证据”，真正决定测试深度的是后续的关键性评分。
| GAMP 5 类别 | 典型过程控制系统组件 | 基线验证动作 |
|---|---|---|
| 1 基础设施软件 | 操作系统、虚拟化平台、数据库引擎 | 记录版本与补丁，依赖供应商评估 |
| 3 非配置软件 | 历史数据库、OPC 通信中间件 | 功能测试加配置记录 |
| 4 配置软件 | DCS 组态、SCADA 画面与报警配置 | 基于风险的 OQ 加配置审计 |
| 5 定制软件 | PLC 自定义逻辑、脚本、与 MES 的定制接口 | 设计审核加 OQ/PQ，必要时代码走查 |
我一般会在风险登记表里同时记录gamp_category和criticality_score，因为审计时这两个字段回答的是不同问题：类别解释“为什么这类软件需要这些设计文档”，评分解释“为什么这个节点需要更多测试”。
2.2 关键性评估：质量、患者安全与数据完整性三维打分
把每个控制节点按三个维度打分，再乘以使用频率或放行依赖度作为放大因子，是一种容易落地又经得起追问的做法。下面这段 Python 脚本用于批量计算关键性得分，输入来自工艺、QA 和自动化三方共同确认的评分表。
# 对每个过程控制系统功能节点计算关键性得分 # Q: 对产品质量的影响 (1-5) # P: 对患者安全的影响 (1-5) # D: 对数据完整性的影响 (1-5) # F: 放行依赖度或使用频率放大因子 (1-3) def criticality(q, p, d, f): # 患者安全权重最高，符合 GxP 风险优先原则 score = q * 0.35 + p * 0.45 + d * 0.20 # 频率作为放大因子，避免低频但高风险的节点被低估 return round(score * f, 2) nodes = { "反应釜温度 PID 回路": (5, 4, 4, 3), "CIP 清洗步骤配方": (4, 3, 3, 2), "操作员登录与电子签名": (3, 5, 5, 3), } for name, (q, p, d, f) in nodes.items(): print(name, criticality(q, p, d, f))参数说明：Q的 1 到 5 分别对应“无质量影响”到“直接影响最终产品关键质量属性”；P的 1 到 5 对应“无患者接触”到“可能造成严重伤害”；D的 1 到 5 对应“可轻松重建”到“无法重建且影响放行”；F的 1 到 3 对应“季度级使用”到“每批放行依赖”。权重不是固定值，但必须在验证计划中写明理由，不能随口说“我们一直这么算”。
得分落地后，用下表把关键性转换成验证策略：
| 关键性得分 | 风险等级 | 验证策略 |
|---|---|---|
| 大于等于 14 | 高 | 完整 IQ/OQ/PQ，加严挑战测试，独立复核审计追踪 |
| 8 到 13.9 | 中 | IQ 加 OQ，抽样 PQ，配置审计 |
| 小于 8 | 低 | 配置核对加定期回顾 |
注意：权重和阈值一旦写入验证计划，后续任何调整都必须走变更控制，否则检查员会认为评分标准可以随时被“调”到想要的结论。
2.3 把分级结果固化成可审计的风险登记表
评分过程如果只停留在 Excel 里，审计时很难证明每个节点都被一致地评估过。我通常会把结果导出为机器可读的 YAML，便于版本控制、差异对比和自动检查。
# pcs_risk_register.yaml # 每个过程控制系统节点的风险分级结果 system: "API 反应车间 DCS" nodes: - id: PCS-101 name: "反应釜温度 PID 回路" gamp_category: 5 criticality_score: 14.85 risk_level: high required_tests: - IQ - OQ - PQ data_integrity: audit_trail: true review_frequency: "每批" - id: PCS-205 name: "CIP 清洗步骤配方" gamp_category: 4 criticality_score: 8.4 risk_level: medium required_tests: - IQ - OQ data_integrity: audit_trail: true review_frequency: "每周"这份清单的价值在于把“风险等级”翻译成了可执行的测试范围和回顾频率。review_frequency字段尤其容易被忽略，但它是后续周期性回顾能否自动触发的前提。字段值一旦与验证计划不一致，用文本差异工具就能立刻发现，比人工翻几十页文件可靠得多。
3. 风险基础方法落到控制参数：用 FMEA 与风险优先数给控制回路定验证深度
关键性评分回答的是“这个节点重不重要”，FMEA 回答的是“这个节点可能怎么失效、失效后有多难发现”。两者不能互相替代。我见过只做关键性评分就把所有高风险节点都塞进完整 PQ 的项目，结果是测试资源被耗尽，真正需要挑战测试的传感器漂移反而只做了一次点检。
3.1 FMEA 在过程控制系统里的三个评分维度
对过程控制系统做 FMEA 时，严重度、发生度和可检测度的定义需要贴合控制回路本身，而不是照搬整机 FMEA 的通用表格。下面这套评分口径在多个 DCS/PLC 场景下都能直接用。
| 维度 | 1 到 2 分 | 3 到 4 分 | 5 到 6 分 | 7 到 8 分 | 9 到 10 分 |
|---|---|---|---|---|---|
| 严重度 S | 无质量影响 | 轻微偏差，可返工 | 批次报废 | 患者伤害风险 | 患者严重伤害 |
| 发生度 O | 几乎不发生 | 每年偶发 | 每月可能发生 | 每周可能发生 | 每批都可能发生 |
| 可检测度 D | 在线仪表实时报警 | 批记录复核可发现 | 仅离线检验可发现 | 需要审计追踪回溯 | 几乎无法检测 |
可检测度最容易打分失真。工程师习惯把“有报警”等同于“容易检测”，但报警是否被确认、是否进入审计追踪、是否在批放行前被复核，都会改变真实的 D 值。把“报警存在但操作员可静音且无记录”打成 3 分以下，通常会在检查时被推翻。
3.2 用 Python 批量算 RPN 并映射到 IQ/OQ/PQ 范围
RPN 是三个维度的乘积。下面脚本把 RPN 映射到测试深度，输出结果可以直接粘贴进验证计划的风险评估章节。
# FMEA RPN 计算与测试深度映射 # S: 严重度 (1-10)，O: 发生度 (1-10)，D: 可检测度 (1-10) # D 值越高表示越难检测，因此 RPN 直接相乘 def rpn(s, o, d): return s * o * d def test_depth(value): # 阈值应写入验证计划并经过 QA 批准 if value >= 200: return "完整 IQ/OQ/PQ 加挑战测试加独立复核" if value >= 100: return "IQ/OQ 加抽样 PQ" if value >= 40: return "IQ 加配置核对" return "仅记录版本与定期回顾" fmea_items = [ ("PCS-101 温度传感器漂移", 9, 4, 6), ("PCS-205 阀门执行器滞后", 6, 3, 4), ("PCS-310 报警确认延迟", 3, 5, 3), ] for name, s, o, d in fmea_items: value = rpn(s, o, d) print(f"{name}: RPN={value}, 测试深度={test_depth(value)}")参数说明：S取 9 表示该失效可能导致患者伤害，O取 4 表示每年偶发但并非不可能，D取 6 表示需要离线检验才能发现。这段代码的重点不是算乘法，而是把“为什么这个回路要做挑战测试”写成可复现的判据。任何一条 RPN 超过 200 的条目，验证计划里都应该能找到对应的挑战测试用例编号。
3.3 阈值被审计挑战时怎么解释
审计员常问的一句话是：“为什么 200 是分界线，不是 150？”标准答案不是“行业惯例”，而是把 RPN 拆回三个维度，说明在你们的具体工艺里，哪个维度的取值导致了高风险结论。下表是一种可用的解释模板。
| 被挑战的阈值 | 拆解维度 | 支持证据 |
|---|---|---|
| RPN 大于等于 200 需要挑战测试 | S 大于等于 8 且 D 大于等于 5 | 历史偏差记录、传感器校验周期、在线检测覆盖率 |
| RPN 小于 40 仅做回顾 | S 小于等于 4 且 O 小于等于 3 | 同类回路三年无偏差、操作频率低、有离线检验兜底 |
真正让检查员接受的不是数字本身，而是数字背后有工艺数据、偏差趋势和检测能力评估。把这三类证据放进同一个风险文件，比在检查现场临时解释有效得多。
4. GxP 过程控制系统的审计追踪与数据完整性：按风险分配验证工作量
数据完整性在过程控制系统里不是一个独立模块，而是分散在操作记录、时间戳、用户标识和参数变更历史中。基于风险的做法是：先确认哪些操作与放行直接相关，再决定审计追踪需要覆盖到什么程度，而不是对所有点位一视同仁地开启全量记录。
4.1 ALCOA+ 在 PCS 时间戳与操作记录上的具体要求
ALCOA+ 的九个属性落到过程控制系统时，最容易出问题的是“同步记录”和“准确”。PLC 扫描周期是毫秒级，而审计追踪写入历史数据库可能是秒级甚至分钟级。如果批记录放行依赖某个关键参数的时间点，这个时间偏差就必须被评估，不能假设“差不多就行”。
| ALCOA+ 属性 | 过程控制系统落地要求 | 常见缺口 |
|---|---|---|
| 可归属 | 每个操作关联唯一用户 ID，服务账号操作需有人复核 | 共用操作员账号 |
| 可辨识 | 时间戳使用统一时区并带来源 | 本地时间与服务器时间混用 |
| 同步 | 关键操作与审计记录偏差在定义阈值内 | NTP 未覆盖控制器 |
| 准确 | 参数值来自实际过程值而非画面缓存 | 画面显示值与控制器值不一致 |
| 完整 | 关键参数修改前后值均记录 | 只记录新值 |
| 一致 | 审计追踪不可被普通用户关闭或编辑 | 管理员可停用审计 |
| 持久 | 记录保留周期覆盖产品有效期加一年 | 历史库自动归档后丢失 |
| 可获取 | 检查时能按批号导出完整操作链 | 导出功能未验证 |
| 可读 | 导出格式在保留期内可解析 | 依赖已停用的专用软件 |
4.2 用 SQL 检查审计追踪覆盖率与时间戳偏差
把数据完整性检查写成 SQL，好处是每次回顾或变更后可以重复执行，结果可比。下面查询针对关键性评分大于等于 8 的节点，找出缺失审计记录或时间戳偏差过大的操作。
-- 检查过去 30 天内关键过程控制操作的审计追踪覆盖情况 -- 目标：找出没有审计记录的操作，或时间戳偏差超过 60 秒的记录 SELECT o.operation_id, o.timestamp AS op_time, a.timestamp AS audit_time, a.user_id, a.action, ABS(TIMESTAMPDIFF(SECOND, o.timestamp, a.timestamp)) AS diff_seconds FROM process_operations o LEFT JOIN audit_trail a ON o.operation_id = a.operation_id WHERE o.timestamp >= DATE_SUB(NOW(), INTERVAL 30 DAY) AND o.criticality_score >= 8 AND ( a.audit_id IS NULL OR a.user_id IS NULL OR ABS(TIMESTAMPDIFF(SECOND, o.timestamp, a.timestamp)) > 60 ) ORDER BY o.timestamp DESC;参数说明：criticality_score >= 8复用第 2 章的风险分级结果，避免对所有点位做全量扫描；60秒是时间戳偏差阈值，需要根据控制器时钟同步方案在验证计划中定义，不能直接照搬。查询返回的每一行都应该有对应的偏差调查记录或缓解措施，否则数据完整性章节在审计时会被直接挑战。
4.3 审计追踪缺口的风险缓解与再验证触发
不是所有缺口都需要立刻停机整改。按风险等级分配缓解措施，可以把有限资源用在最需要的地方。
| 缺口类型 | 风险等级 | 缓解措施 | 再验证触发范围 |
|---|---|---|---|
| 操作者标识缺失 | 高 | 暂停放行，人工复核对应批记录 | 该节点审计追踪模块 OQ |
| 时间戳偏差大于 60 秒 | 中 | 校时，增加 NTP 监控 | 时间同步服务 IQ/OQ |
| 关键参数修改无审计记录 | 高 | 启动偏差调查，评估批次影响 | 该功能节点完整 OQ 加 PQ |
| 审计追踪可被管理员停用 | 高 | 立即限制权限，增加独立监控 | 用户权限模块 OQ |
注意：把“再验证触发范围”写进风险登记表，比事后争论要不要重做验证更省时间。触发条件越具体，变更控制流程越不容易被绕过。
5. 让风险评估持续有效：GxP 过程控制系统的周期回顾与变更触发技巧
风险登记表做完第一版之后，真正的挑战才开始。系统在运行、工艺在调整、人员在流动，如果风险评估只在项目验证阶段更新一次，两年后它和现场实际情况的差距会大到无法辩护。把回顾周期和变更触发条件做成可执行的检查项，比每年集中补文件更可靠。
5.1 按风险等级设定回顾周期
高风险节点每批或每周回顾，中风险节点每月或每季度，低风险节点至少每年一次。这个频率不是拍脑袋定的，而是从关键性评分和 FMEA 的严重度、可检测度推导出来的。下面这条命令借助 yq 从风险登记表中筛出已超过回顾周期的节点。
# 从风险登记表中列出已超过回顾周期的过程控制节点 # last_review_days_ago 与 review_interval_days 由回顾记录维护 yq -r '.nodes[] | select(.last_review_days_ago > .review_interval_days) | [.id, .name, .risk_level] | @tsv' pcs_risk_register.yaml参数说明：last_review_days_ago是当前日期减去上次回顾日期得到的天数；review_interval_days由风险等级映射而来，高风险建议不超过 30 天，中风险不超过 90 天，低风险不超过 365 天。把这条命令挂到每月工单里，可以让回顾任务自动出现，而不是依赖某个人记得。
5.2 变更触发重新评估的三个具体条件
不是所有变更都需要重做风险评估。我通常把触发条件限定在以下三类，避免变更控制流程被无意义的评估拖慢：
第一类，控制逻辑或配方参数发生变化，且该节点关键性评分大于等于 8。第二类，审计追踪配置、用户权限模型或时间同步方案发生变更，无论节点风险等级如何。第三类，出现与该节点相关的偏差、投诉或检查发现项，且根本原因指向过程控制功能。
满足任一条件时，重新计算关键性评分和 RPN，更新风险登记表，并检查required_tests字段是否发生变化。如果测试范围扩大，再验证计划必须同步更新；如果缩小，必须有足够的历史数据支持，否则检查员会认为你在主动降低验证深度。
5.3 一个实用技巧：把风险回顾结果写回登记表
每次回顾后，除了更新last_review_days_ago，还应该记录回顾结论和依据。最简单的做法是在每个节点下增加一个review_history列表，保留最近三次的结论摘要。这样在检查现场，不需要翻找独立文件，直接从登记表就能看出这个节点的风险判断是否持续被复核过。字段不必复杂，但必须有人对结论负责，并且结论要能追溯到具体批记录、偏差编号或变更单号。
把这段命令挂到每月工单里，比年底集中补文件更能经得起现场检查。
本文还有配套的精品资源，点击获取
