简介一份聚焦制药工业数字化转型的完整方案PPT面向药企生产管理者、自动化与信息化工程师梳理行业在质量合规、成本效率及外部环境方面的核心痛点。内容结合“中国制造2025”与医药工业“十三五”规划给出智能化转型路线并重点展开西门子数字化工厂实践包括数字化建模与仿真、SCADA数据采集、DCS/PLC先进控制、MES一体化协同优化以及网络互联与信息安全体系。对于正在规划或推进药厂数字化项目的团队可作为现状诊断、方向参考与方案选型的实用资料。资源为1个pptx文件大小8.45MB内容约含60页左右的体系化框架与案例研究便于直接阅读与二次整理。已有60人学习适合需要快速理解制药数字化整体架构、政策导向与西门子落地路径的中高层技术及管理人员。1. 换模 8000 小时背后的制药数字化账本第一次拆这份 Siemens Process Industries and Drives 资料时最刺眼的不是 MES 模块图而是一组生产损失账某医药集团全年 240 次换模折算约 8000 小时加上 1900 小时设备维修合计约 5000 万元成品价值损失。另一个残酷的数字是 70% 的制药企业仍处于工业 2.0 阶段大量批记录靠手填数据可靠性经不起一次飞行检查。数字化工厂在这些厂里很容易被做成“上一套 MES 看板”但实际上要做的是把工艺配方、批记录、设备状态、物料和质量管理流程串成一条可审计的数据链。这篇文章按我实际拆这类方案时的思路先看行业账本再搭指标骨架然后拆组件最后落到电子批记录和验证上。2. 从 ISA-95 到两个 90%数字化工厂的指标和骨架2.1 ISA-95 分层不是流程行业口号制药数字化工厂落地的第一件事是把数据链路画清楚。ISA-95 把工厂信息系统分成 L0 到 L4L0 是阀门、电机、传感器L1 是 PLC 和 DCS 的控制逻辑L2 是 SCADA 和历史库L3 是制造执行系统 MESL4 是 ERP 和 PLM。很多项目把 MES 买回来后发现和 DCS 对不上就是因为 L3 和 L2 的接口没有先定义。制药行业比离散制造更强调 L2/L3 绑定。一批药从投料到放行过程参数、设备运行状态、操作员动作都要和批记录关联GMP 环境下的每一次修改变更、电子签名都要可回放。这种要求下ISA-95 分层不是挂在嘴边的架构图而是设计数据模型和接口时的边界线。比如 MES 里的称量指令最终要落到 DCS/PLC 的执行机构放行时又要从 L2 的历史库把温度、压力曲线拉出来核对分层的目的是让每个系统只做自己那一层的事。2.2 数采率与自控投用率先算账再建系统智能制造试点示范和医药工业规划里反复出现两组数字生产工艺数据自动采集率达到 90% 以上工厂自控投用率达到 90% 以上。数采率不是“系统画面上有多少实时值”而是“需要进批记录、影响放行判断的参数中有多少点具备自动采集并且落到历史库”。自控投用率则要看投入自动闭环控制的回路占全部设计与运行回路比例把只有报警、没有自动调节的回路算进去就没意义。我一般会在项目前期用参数点清单先跑一遍测算脚本避免方案写完了才发现还有一半关键参数要靠人工录入# 点表字段定义 # tag: 位号, setpoint: 设定值, signal_type: 0人工录入 1自动采集 # auto_control: 0开环/报警 1闭环控制, required_archive: 是否必须进批记录 def calc_metrics(points): need_auto [p for p in points if p[required_archive]] # 需要追溯的参数 auto_collected [p for p in need_auto if p[signal_type] 1] loops [p for p in points if p[setpoint] is not None] # 有设定值的回路 closed_loops [p for p in loops if p[auto_control] 1] data_rate len(auto_collected) / len(need_auto) * 100 control_rate len(closed_loops) / len(loops) * 100 return data_rate, control_rate这段脚本的逻辑不复杂关键是required_archive这个字段。它把“可监控点位”和“必须追溯的点位”分开比如反应釜温度必须进批记录而环境温湿度只需要报警留痕。算出来的data_rate才是可追溯覆盖率而不是采集覆盖率。自控投用率里的setpoint用于判断回路是否有自动闭环基准否则会把大量手动操作回路误判成自动。2.3 数据链路与网络架构分层明确后还要决定数据怎么在层与层之间流动。下面是常用的系统映射层典型系统关键数据常用接口L4ERP生产订单、物料账、成本RFC / WebServiceL3SIMATIC IT eBR主批记录、物料称量、偏差SQL / WebServiceL2PCS7 / SCADA实时过程值、报警、批报告OPC UA / ProfinetL1PLC / DCS回路控制、联锁ProfinetL0传感器 / 执行器温度、压力、流量、阀位硬接线 / ProfinetL2 和 L3 之间用 OPC UA 比较稳妥历史和批数据要同时落库L3 和 L4 之间一般走 WebService不要在 ERP 里直接查 DCS 历史库。网络架构上建议把 IT 网和 OT 网做 VLAN 隔离加上工业防火墙接口只开放白名单端口。还要统一 NTP 时钟源否则电子批记录上的时间戳和 DCS 报表对不上审计时会被记为数据可靠性缺陷。3. 西门子制药数字化组件COMOS、PCS7 与 MES 的分工3.1 COMOS把工程数据搬到运维西门子这套方案的源头不是 MES而是 COMOS。它把 PID、电气仪表图、管道图、设备台账、DCS 组态数据放进同一个数据库设计阶段建好的模型直接移交运维阶段。COMOS 的价值在于避免“图纸一套、现场一套、DCS 点表又一套”的三张皮问题改造项目尤其明显管道变更后在 COMOS 里修模型DCS 组态和竣工图同步更新。对 IT 人员来说COMOS 像是一个工厂对象数据库每台泵、每个仪表都有独立对象 ID和 PCS7 的控制器组态、仪表索引关联。做设备维修或偏差调查时可以直接从批号钻进设备历史再跳到底层图纸不用再翻纸质归档文件。这点在审计追踪里非常有用。3.2 PCS7S88 批控制与批次报告的原始数据PCS7 是这套方案的 DCS 核心支持 S88 批控制模型。配方按 Procedure、Unit Procedure、Operation、Phase 组织和制药工艺里的“工序、工步、动作”对应。批次启动时 PCS7 根据配方顺序调用控制模块同时生成批次报告记录每个阶段的开始时间、设定值、实际值、报警和操作员动作。批次报告是电子批记录最扎实的数据来源。前面说的换模 8000 小时损失放在 DCS 层面就是配方切换和批次衔接的效率问题。用 S88 的配方参数化和清洗验证流程可以把批间换模从“手工改设定点”改成“配方自动加载 清场确认”。PCS7 同时记录清洗批和产品批中间的空档时间也能统计出来为优化排产提供数据。3.3 SIMATIC IT eBRMES 层的主批记录与电子批记录MES 在西门子体系里对应 SIMATIC IT eBR。它管的是主批记录模板和电子批记录实例定义称量配料、生产、包装各工序的步骤、参数范围、物料批次和取样计划执行时把 MBR 实例化为 EBR所有操作都要按模板走偏离就触发偏差流程。实际项目里我最关注四个模块称量配料模块负责物料防错称量前扫原料条码核对名称批号效期物料追溯模块从仓储到成品一路绑定电子签名单元强制指定操作员和复核人偏差管理把异常事件和 EBR 关联。eBR 的字段设计直接决定放行效率比如称量时允差设得太严会导致大量偏差太松又卡不住错投料。3.4 SIPAT在线质量预测与实时放行SIPAT 是西门子的过程分析技术系统对应 PAT 和 QbD 概念。常规做法是生产结束后取样送 QC结果出来才能放行SIPAT 用近红外、拉曼等在线传感器的数据建立模型实时估算关键质量属性配合反馈控制。搞均质工艺时可以通过在线粒度数据判断是否达到目标不用等两个小时后的实验室结果。SIPAT 与 LIMS 的差别在于LIMS 管离线样品和结果SIPAT 管在线过程数据和模型。实际落地时我一般会让两者共存SIPAT 做实时预警LIMS 做官方留样结果两者同时写进放行结论。3.5 组件集成关系与数据流组件层级主要职责关键集成点COMOS工程/运维工厂对象与文档PID、设备、DCS 点表PCS7L1/L2批控制与批报告OPC UA、批报告文件SIMATIC IT eBRL3主批记录、电子批记录称量、物料、偏差SIPATL2/L3在线质量预测传感器模型、放行规则XHQ运营层OEE、KPI 报表从各系统取数数据流整体是单向闭环COMOS 定义工厂对象PCS7 执行批次并回传过程值和批报告eBR 把工艺步骤和批报告绑定质量审核完成放行最后 XHQ 展示 OEE 和设备可用率。PCS7 侧采集数据时我一般用 OPC UA 直接订阅实时标签from opcua import Client # 实际地址由 DCS 组态决定这里用模拟示例 client Client(opc.tcp://pcs7-ot:4840) client.connect() node client.get_node(ns2;sReactor1.Temperature) temp node.get_value() print(freactor temp: {temp:.1f} C) client.disconnect()这样拿到的是 L2 实时值写完必须确认标签是否进历史库否则只能看现场值不能用于放行判断。OPC UA 订阅适合点位少的场景点位多时建议改用 DA 批量读取或让 PCS7 主动推送批报告文件。4. 实战电子批记录的数据模型与批次放行校验逻辑4.1 电子批记录的核心对象电子批记录不能简单理解成一张 Excel 大表。它至少要拆成批号主表、过程参数表、物料使用表、偏差表和电子签名表否则审计追踪没法做。主批记录 MBR 是模板电子批记录 EBR 是实例二者通过 recipe_id 和 recipe_version 关联。批次放行时要校验模板要求的参数是否都有值每个值是否在允许范围物料批次号是否准确偏差是否全部闭环签名是否齐全。4.2 表结构设计我通常先建批记录主表和过程参数表这两张表能支撑绝大部分放行校验-- 批记录主表一个批号一条记录 CREATE TABLE batch_record ( batch_no VARCHAR(30) NOT NULL, recipe_id VARCHAR(30) NOT NULL, recipe_version VARCHAR(10) NOT NULL, material_code VARCHAR(20) NOT NULL, batch_size NUMERIC(10,2), start_time TIMESTAMP, end_time TIMESTAMP, status VARCHAR(12) NOT NULL DEFAULT DRAFT, PRIMARY KEY (batch_no, recipe_version) ); -- 过程参数归档表 CREATE TABLE batch_parameter ( batch_no VARCHAR(30) NOT NULL, operation VARCHAR(20) NOT NULL, param_tag VARCHAR(40) NOT NULL, param_type VARCHAR(10), -- ANALOG / DISCRETE / TEXT value_text VARCHAR(64), unit VARCHAR(10), source VARCHAR(10), -- DCS / MANUAL / LIMS recorded_at TIMESTAMP, PRIMARY KEY (batch_no, operation, param_tag, recorded_at), FOREIGN KEY (batch_no) REFERENCES batch_record(batch_no) );batch_record 表里的recipe_id和recipe_version对应主批记录 MBR换配方或升版时不会把新旧版本数据混在一起。batch_parameter 表的source字段很关键它标记数据来自 DCS 自动采集还是人工录入。审计时如果发现一个关键工艺参数 source 是 MANUAL就要解释为什么没有自动采集。4.3 批次放行的校验逻辑数据模型定好后放行校验就是一套规则引擎。我习惯用 Python 写一个可重复执行的校验函数项目现场改造成 Java 或 C# 也容易def validate_batch(batch_no, specs): params get_batch_params(batch_no) # 从 batch_parameter 读取 missing [ s for s in specs if not any(p.param_tag s[tag] for p in params) ] bad [] for p in params: spec specs.get(p.param_tag) if spec is None or p.value_text is None: continue try: v float(p.value_text) except ValueError: bad.append((p.param_tag, p.value_text)) continue if not (spec[low] v spec[high]): bad.append((p.param_tag, p.value_text)) open_devition get_open_deviation(batch_no) # 未闭环的偏差 if missing or bad or open_devition: return BLOCKED, { missing: missing, out_of_range: bad, open_deviation: open_devition, } return RELEASED, {}这个函数的逻辑很直接先检查该有的参数是否缺失再检查数值是否在合格范围最后看有没有未关闭的偏差。specs是从 MBR 模板里解析出来的参数范围最容易被忽略的是 missing 检查——如果 DCS 采集点没配上param 表里根本没有 tag数值范围检查发现不了所以必须先查缺失。4.4 和 DCS 批报告的映射PCS7 的 Batch Report 通常按批号生成 XML 或 CSV里面每个步骤有开始时间、结束时间、参数名、设定值和实际值。做集成时我会把批报告里的步骤名映射到 batch_parameter 表的 operation 字段参数名映射到 param_tag时间点映射到 recorded_at。这样 EBR 界面展示的趋势曲线和 PCS7 历史站看到的是同一份数据。换模记录也放在这个模型里清洗批和下一产品批通过material_code关联清洗过程的温度、时间、电导率作为离散参数记入 batch_parameter。设备调试人员可以直接看到清洗批的 end_time 和产品批的 start_time 之间的距离算出真正浪费的换模时间。5. 验证与排错数据可靠性、CSV 与数采率核对5.1 数据可靠性检查点GMP 审计最常抓的问题是数据可靠性核心是 ALCOA 原则可归属、清晰、同步、原始、准确。放到技术层面就是三件事第一每条批记录操作必须有登录用户和电子签名第二系统时间必须统一DCS、MES、数据库服务器都指向同一台 NTP 服务器第三原始数据不能被覆盖PCS7 历史库的归档文件要设置只读权限数据库删除操作要走审批流程。时钟同步是排查时最先看的地方。DCS 和 MES 各走各的时钟批报告里的时间和电子签名时间差几十秒审计员会直接给缺陷。我会在验证阶段把所有服务器的 Windows Time 服务和 ICS 同步都检查一遍不只查偏差还要看重启后是否自动同步。5.2 CSV 验证范围计算机化系统验证不能等系统上线再做通常是补课。验证阶段和关键活动可以按下表展开验证阶段关键活动常见输出URS明确法规和业务需求用户需求说明FAT/SAT工厂和现场测试测试记录IQ/OQ安装和运行确认安装报告、功能测试脚本PQ工艺与数据完整性确认放行流程模拟报告做 CSV 时最容易漏的是数据完整性测试。OQ 里要专门写一个用例制造一条带偏差的批次验证 MES 能阻止放行再制造一条参数超限的批次验证校验函数返回 BLOCKED。这样才算把本章的校验逻辑真正验证过。5.3 数采率核对方法系统上线后数采率不是算一次就完了。我建议每个批次关闭后跑一遍 SQL核对自动采集点数量和占比SELECT SUM(CASE WHEN source MANUAL THEN 1 ELSE 0 END) AS auto_points, COUNT(*) AS total_points, ROUND( SUM(CASE WHEN source MANUAL THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 1 ) AS data_rate FROM batch_parameter WHERE batch_no BATCH20250101;这个查询把源字段里所有非 MANUAL 的点位都算成自动采集能快速抓出“某个工序临时改手工记录”的问题。如果发现 data_rate 明显低于 90%就回到点位配置表检查是 OPC UA 断连、PCS7 归档没配还是操作员手动录入覆盖了自动值。奥比中光的典型案例是新增设备后点表没有同步批次执行到一半才发现参数没归档这种问题的根因往往是 COMOS 和 PCS7 的点位同步流程没走完而不是系统本身不稳定。建议每个批次关闭后跑一次这个 SELECT并核对满 90% 的比例是否随生产品种波动。本文还有配套的精品资源点击获取
