制药厂洁净空调西门子S7-1500 PLC控制系统设计与实践

1. 为什么制药厂洁净空调需要一套独立的PLC控制系统这几年陆陆续续做了不少暖通空调的项目但制药厂洁净空调这一类的确比较特殊。普通的办公大楼或者商场中央空调控制精度稍微差一点、温度波动几度人体感官上可能也就觉得闷一点或者凉一点但是制药车间的洁净空调如果控制不好直接涉及产品质量甚至会导致整批药品报废。我这次做的这个项目就是一套西门子S7-1500为核心的制药厂洁净空调PLC控制系统硬件全部采用1500系列CPU加分布式IO的方案这篇文章就围绕这个案例把整套系统的控制逻辑、硬件规划、程序结构和调试经验完整梳理一遍。先说说为什么制药厂洁净空调必须用独立的PLC控制系统。很多人觉得洁净空调和普通空调差别不大无非就是加个过滤器、控制一下温湿度用DDC控制器或者组合式空调箱自带的控制板也能搞定。但实际接触过制药项目之后才会明白这个思路在GMP认证和日常生产环节根本走不通。制药车间对环境的控制要求极其苛刻。以这个项目为例生产区域按照GMP规范划分为A级、B级、C级、D级四个洁净级别不同级别之间需要维持稳定的压差梯度。正常情况下相邻房间的压差要保持在5Pa以上洁净区与非洁净区之间的压差不能低于10Pa而且这种压差关系在运行过程中必须一直存在不能因为某个房间门开了、某台设备启停了就出现压差反向。温湿度方面多数固体制剂车间的控制范围是温度18到26摄氏度、相对湿度45%到65%部分特殊工艺段甚至要求温度控制在正负1摄氏度以内湿度控制在正负5%以内。这种控制需求并不是简单的温度高了就开制冷、湿度大了就加除湿这种位式控制能满足的。整个系统的风量、冷热量、加湿量、排风量之间是强耦合关系——调节送风量会同时影响温度和压差改变回风比例会扰动湿度场的平衡表冷器的开度变化又会反过来影响风机的运行工况。控制对象之间互相牵制任何一个参数调整都会引发连锁反应。普通DDC控制器虽然也能跑PID回路但算法能力、运算周期、抗干扰能力、故障自诊断能力都明显偏弱尤其是面对多回路协同控制时往往会出现这个回路调好了那个回路又抖起来的现象。另外一个关键因素是GMP对系统数据完整性的要求。药品生产质量管理规范明确要求洁净空调系统的运行参数、报警记录、操作日志都需要具备完整的可追溯性。谁来操作的、什么时候改了设定值、设备运行过程中温湿度曲线是什么样、过滤器压差变化趋势如何这些数据都要有记录。PLC系统配合上位机可以实现完整的数据归档和审计追踪而很多DDC系统在这方面做得不够完善。选择西门子S7-1500首先考虑的是运算性能和可靠性。1500系列的运算速度比经典的300系列快了一个量级特别是在浮点运算、PID调节和通讯处理方面有明显优势。洁净空调系统虽然I/O点数不算特别多但模拟量回路数量多、PID运算频率要求高加上还要跑联锁逻辑、模式切换逻辑、风机变频跟踪算法对CPU的负荷要求其实不低。另外1500系列内置的诊断能力非常强硬件故障、通讯中断、模块异常都能在诊断缓冲区里找到详细记录这对制药车间的设备维护来说非常友好。这个项目也让我形成了一个比较固定的选型思路——做洁净空调控制如果预算允许S7-1500会是第一选择。原因不光是性能更重要的是整个生态系统的完整性Profinet通讯的实时性、分布式IO的灵活扩展能力、与上位机SCADA系统的无缝对接、TIA Portal统一的组态环境这些都是在实际项目中真正能提升效率、降低风险的因素。2. 硬件架构与控制点位规划这个系统到底需要多少IO点硬件配置是这类项目的第一步也是最容易出问题的一步。很多初学者上来就急着写程序但点位都没弄清楚就写出来的逻辑后期往往要推翻重来。我习惯先把控制需求和现场设备清单摆出来一个一个对应过去把I/O清单做扎实再动硬件选型和程序框架。2.1 系统拓扑与CPU配置这个项目控制的洁净空调系统其实是两套组合式空调机组加一套新风机组。两套洁净空调机组分别对应两条独立的生产线新风机组统一承担新风预处理。由于空调机房和生产车间之间的距离比较远I/O点比较分散所以没有把所有模块都塞进一个控制柜而是采用了CPU机架加远程IO的分布式架构。系统拓扑大致是这样的S7-1500 CPU作为中央控制器通过Profinet总线连接两个分布式IO站每个空调机组附近部署一个IO站就近采集传感器信号和控制执行机构。这样做的好处非常明显——信号电缆的长度大幅缩短传感器信号不容易衰减和受干扰现场布线施工也方便很多。尤其是模拟量信号4到20mA信号虽然抗干扰能力比电压信号强但传输距离超过50米之后还是会有风险分布式IO从源头上规避了这个问题。CPU这一层选用的是1515-2PN型这个型号自带Profinet接口两个端口可以做环形拓扑或者星形拓扑支持同时连接多个IO设备和HMI。对这套系统来说带两台分布式IO站、两台触摸屏、一台SCADA服务器通讯负载完全在合理范围之内CPU的扫描周期也能保持在20ms左右完全满足洁净空调的控制实时性要求。存储方面也做了充分考虑。S7-1500的装载存储区比传统300系列大了很多但制药项目有个特殊要求——程序要保存完整的批次配方数据、操作记录和报警历史。所以额外加了一张存储卡用来存放历史数据缓存和配方数据备份。这里有个小经验存储卡一定要选原厂的市面上一些替代品虽然也能用但在高温环境下偶尔会出现数据读写异常制药车间一旦出现数据丢失追溯链就可能断掉这是非常严重的事故隐患。2.2 I/O点位的详细统计与分配逻辑做个粗略的盘点两套空调机组加一套新风机组整套系统的I/O点量大概是这样模拟量输入主要包含温湿度传感器送风温度、回风温度、室内温度、送风湿度、回风湿度、室内湿度、风管压力传感器送风管压力、回风管压力、过滤器压差开关/变送器初效过滤网、中效过滤网、高效过滤网前后压差、水管温度传感器冷水供回水温度、热水供回水温度、蒸汽温度。数字量输入方面风机运行状态反馈、风机故障反馈、手自动转换开关状态、柜门状态、就地远程切换、各种运行模式选择开关、过滤网堵塞报警信号、防冻开关状态、消防联动脉冲信号。模拟量输出主要有送风机变频器频率给定、排风机变频器频率给定、冷水电动调节阀开度控制、热水电动调节阀开度控制、加湿器开度或蒸汽调节阀开度控制、新风阀开度控制、回风阀开度控制、排风阀开度控制。数字量输出送风机启停控制、排风机启停控制、电加热器分级控制、各种电动风阀的开关控制、声光报警器驱动、运行状态指示灯。汇总下来一套空调机组大概需要模拟量输入12到16个、数字量输入15到20个、模拟量输出6到8个、数字量输出8到12个。两套机组加一套新风机组总点数算下来模拟量AI大约40个左右、DI大约55个左右、模拟量AO大约18个左右、DO大约28个左右。这个数据是方案设计阶段做出来的估算值实际施工过程中还会因为现场增加检测点而变动。比如业主要求增加了两个房间的温湿度监测点为了满足验证需要又增加了两个压差变送器。所以硬件选型时一定要留出冗余余量模拟量模块通常留出10%到20%的备用通道数字量模块也是如此。我在这个项目里把AI模块选成了每个模块8通道的规格本来5个模块就够用的点位装上了7个模块多出来的两个模块放在备用位置虽然暂时没有接线但心里有底。2.3 通讯接口和上位机联动整个控制系统的通讯架构分了三层第一层是Profinet实时通讯层连接CPU和两个分布式IO站还有变频器的通讯模块。送风机和排风机的变频器都支持Profinet通讯所以频率给定和运行状态反馈都通过通讯方式实现省掉了模拟量接线也避免了模拟量信号在变频器附近的干扰问题。这里顺便说一下PZD报文类型选的是标准报文1速度给定加状态字一个通讯周期同时完成下发和上传控制效果稳定可靠。第二层是CPU和HMI触摸屏之间的通讯。两台触摸屏分布在两个空调机房的门口操作人员可以就近查看设备运行状态、修改设定参数、确认报警。用1500和触摸屏组态非常方便在TIA Portal里拖动网络连接就完成了不需要额外写通讯程序。第三层是CPU和上位机SCADA系统之间的通讯。制药厂一般都有一个中央监控室通过服务器把各车间的PLC数据集中起来显示。这一层我用的是SIMATIC S7通讯1500做服务器端上位机通过S7协议直接读写数据块。数据块规划的时候就要考虑好哪些数据要开放给上位机、哪些只做本地操作——比如配方管理数据、用户登录信息这些就放在PLC本地生产运行参数、报警信息、温湿度历史数据则同步给上位机。3. 洁净空调的核心控制逻辑压差、温湿度、风量如何协同点表清楚之后接下来就是控制系统最核心的部分——控制逻辑设计。这部分没有捷径可走全靠对制冷空调工艺的理解。我一开始做这类项目的时候犯过一个错误拼命把精力花在PID参数整定上觉得只要PID调好了温度湿度就都能压得住。后来在现场被现实狠狠教训了一回。温度超调、湿度震荡、压差漂移问题层出不穷一个个去治标不治本。直到把整个控制策略重新梳理了一遍才算真正找到了门道。3.1 压差梯度控制洁净车间的空气秩序先讲压差因为这是洁净空调和普通空调最本质的区别。洁净车间的污染控制核心思路是通过不同区域之间的空气压力差形成一种梯度让空气只能从洁净级别高的区域流向洁净级别低的区域反过来则不行。这个逻辑相当于给车间建立了一套单向交通规则——走廊里的脏空气绝不能倒灌进正在灌装药品的洁净室。压差控制的实现原理可以拆解成三步第一步维持送风和排风之间的风量差值。每个房间的送风量、回风量或者排风量形成一个差值这个差值决定了房间相对走廊或者相邻房间的压差。差值为正说明送进去的空气比产出的空气多出的一部分要通过门缝等缝隙渗透出去这样房间内部压力就会高于外面。第二步通过变频器调节送风机和排风机的转速控制总送风量和总排风量的比例关系。第三步通过每个房间支管上的调节风阀微调单个房间的送排风量比例实现局部压差修正。算法上我用的是压差主回路加风量补偿前馈的方式。压差变送器读取当前房间和参照区域之间的实际压差值和目标压差值比较后送入PID调节器PID的输出作为该房间排风阀或者送风阀的修正信号。但如果仅仅依靠压差PID去调风阀响应速度会非常慢——因为从阀门动作到房间压差发生变化中间隔着风管道的容量、房间的体积、气流的混合时间纯反馈回路非常容易出现振荡。所以在压差PID的基础上增加了一个前馈量送风量、排风量这些实际测量值经过加权计算后直接叠加到阀门控制信号上。风量一变阀门马上跟着动压差的变化在萌芽阶段就被补偿掉了PID只需要处理小范围的修偏就行。这个策略应用下来各个房间的压差稳定效果非常理想多房间联动时也没有出现互相扰动的现象。3.2 温湿度控制一套表冷器外加湿器如何同时压住两个参数温湿度控制是洁净空调最让人头疼的部分关键在于温度和湿度两个参数强耦合而且制冷和除湿往往是同一个过程很难独立调节。先看温度控制加湿和电加热是解耦的关键。夏天工况时室外空气经过表冷器冷却除湿变成低温高湿的空气这时候如果要提高送风温度不是靠关小表冷器阀门来节省冷量而是靠开大热水阀或者电加热器重新加热。冬季工况则相反室外冷空气经过预热和加湿处理后再经过表冷器精确调节送风温度。控制系统用的是串级控制方案主回路是房间温度被控对象是房间内的温度传感器副回路是送风温度被控对象是送风管内的温度传感器。主回路的PID输出作为副回路的设定值副回路动作直接调节热水阀或者表冷器阀门。加湿控制相对独立一些用的是电极加湿器或者干蒸汽加湿器。湿度传感器检测送风湿度或者房间湿度PID控制器调节加湿器的加湿量。这里有个实验室里没法学到的经验——湿度传感器的响应时间比温度传感器慢得多而且安装位置对测量值的影响非常大。传感器如果装在空调箱内静压箱的位置由于局部气流不均匀测出来的湿度可能和房间实际湿度相差好几个百分点。所以加湿控制的PID周期要适当放长积分时间要加大否则湿度会一直过冲、震荡最终在超调和滞后之间反复折腾。再说除湿工况。夏季湿热天气如果只靠表冷器降温来顺带除湿往往会导致温度被拉到很低才能把湿度压下来白白浪费了再热能量。更合理的方式是采用双冷源系统高温冷源负责降温低温冷源负责深度除湿。这个项目的冷水系统刚好是两段供水一段是7到12度的冷冻水一段是12到18度的中温水。控制逻辑是先利用中温表冷器把空气温度降到露点附近再利用低温表冷器进行深度除湿最后根据温度需要重新加温。这种分级处理方式不仅能耗低而且除湿和降温两个功能可以分别优化互不牵制。3.3 风机变频与风量跟踪让送风和排风始终保持默契洁净空调的风机控制需要协同好送风量和排风量。风量不足会导致洁净度不达标风量过大则能耗浪费严重甚至引起噪声和振动问题。送风风机一般采用恒静压控制方式。在送风管道的适当位置安装静压传感器PID控制器根据静压设定值调节送风机变频器的频率。当末端风阀关小导致管道阻力增大时静压升高PID会降低风机频率当各支路风阀开大时静压下降PID会提升频率。这种控制方式比定量控制节能效果明显特别是部分负荷工况下风机频率能够自动降低到工频的70%甚至更低。排风机的控制逻辑稍微复杂一些。为了保证房间压差稳定排风量必须跟随送风量变化而变化。逻辑是取送风机的实际运行频率和送风管内的风量信号作为排风机频率的前馈量同时各房间的压差PID输出作为排风机的修正量。两个信号叠加之后形成排风机变频器的频率设定值。实际运行效果对比下来这种跟随加修偏的控制方式比单纯用房间压差闭环调节排风机频率要好得多——压差波动幅度至少缩小了50%以上。变频器方面的参数设置也有讲究。送风机和排风机都是大风量风机转动惯量大变频器加速时间如果设置太短容易出现直流母线过压报警设置太长系统响应又太慢。我根据风机规格书上的转动惯量参数做了估算加速时间设为30秒左右减速时间设为40秒。运行下来效果比较理想既没有过压报警也能在可接受的时间范围内完成风量爬坡。3.4 系统的运行模式切换洁净空调不像普通空调只有开机和关机两种状态它至少要区分日常生产模式、值班模式、预热预冷模式、消毒排风模式和紧急停机模式。日常生产模式温湿度必须精确控制在生产工艺要求范围内压差梯度保持正常换气次数达到设计值送风机和排风机都在变频运行状态。值班模式生产线停产后车间没有人在里面操作不需要维持全负荷的送风量只需要维持相对正压或者轻微的正压梯度防止外部污染物渗入。这种模式下送风机低频运行温湿度控制可以放宽精度只做低限保护比如冬季保证车间温度不低于某个下限值防止水管冻裂。值班模式切换的时机由操作人员通过上位机或者HMI手动触发一般在生产结束清场完毕后执行。预热预冷模式主要解决的是非生产时段往生产模式切换的过程。车间长时间停机后室内温度可能偏离设定值很多。如果一开机就直接进入正常生产模式PID会把阀门打到最大风机会满负荷运转不仅能耗大而且温湿度冲击剧烈对洁净室环境恢复反而不利。所以设置了预热预冷程序——先以最大能力快速调节温度和湿度当温湿度接近设定范围后再切回正常PID闭环控制。切换阈值一般设为主设定值正负2摄氏度和正负5%相对湿度。消毒排风模式制药车间定期要做甲醛或者VHP汽化过氧化氢熏蒸消毒。消毒期间空调系统要关闭新风、保持内循环或者切换到排风模式把消毒介质均匀分布在房间内消毒结束后再切换到强制排风快速把残留气体排出。这个过程涉及一系列阀门联动和风机联锁需要单独的程序段来处理绝不能让消毒介质窜到其他区域。4. 程序架构设计OB块、FB块和PID功能块的工程落地硬件架构和控制策略梳理清楚之后终于进入程序编写环节。这个项目的程序结构上我花了不少功夫做规划——洁净空调系统的程序不像简单设备控制控制回路多、模式切换多、联锁条件多如果程序结构设计得不好调试阶段改一个逻辑就像推倒一堵墙苦不堪言。4.1 OB组织块的分工策略S7-1500程序的执行基础是组织块OB。我的习惯是尽可能让不同功能在各自的OB块里独立运行互不干扰这样出问题时定位非常快速。这个项目用了四个主要的OBOB100启动组织块负责系统上电后的初始化工作——设定初始运行模式为预热模式将PID输出值复位清除上一次运行的残留数据恢复停电前保存的关键参数。因为洁净空调系统不能接受一上电就自动进入生产模式万一刚送电而车间还没准备好温湿度控制就可能出乱子。初始化逻辑里专门加了一个人工确认标志位——系统上电后默认进入待机状态必须等待操作人员确认才能进入预热预冷模式。OB1主循环负责常规的逻辑控制——模式状态机、阀门联锁、风机控制、报警判断等。这些逻辑对实时性要求不是特别高放在主循环里完全够用。OB30循环中断周期设为200ms负责所有的PID运算和模拟量处理。我把温湿度控制、压差控制、静压控制的PID功能块都放在这个中断里执行。使用200ms周期的原因在于温度、湿度、压差这些被控对象的时间常数比较大200ms的采样周期足够捕捉到过程变化同时又不会给CPU增加过多负荷。需要说明的是模拟量输入信号的滤波也在OB30里做。S7-1500的模拟量模块自带数字滤波功能但模块级的滤波是固定的灵活性不够我还是在程序里加了移动平均值滤波——连续取5个周期的采样值做平均效果有肉眼可见的提升尤其是压差信号这种本身波动就比较频繁的参数。OB82诊断中断负责硬件诊断处理。分布式IO站的模块故障、Profinet通讯中断、电池电量低等事件都会触发这个中断。处理逻辑很简单——把故障代码写入诊断数据块置位报警标志然后通过HMI弹出故障提示。有了这个功能车间操作人员不用到控制柜跟前逐个检查模块指示灯直接在触摸屏上就能看到哪个站哪个通道出了问题。4.2 FB功能块的设计思路程序的核心控制逻辑封装在几个功能块里通过参数化让同一套逻辑可以复用在多台机组上FB100空调机组主控块负责一台空调机组的整体启停和控制模式切换。输入参数包括手自动状态、启停指令、风机故障信号等输出参数包括风机启停命令、各种阀门的控制命令。这个块内部实现了完整的模式状态机——待机、预热、生产、值班、消毒、停机状态之间的切换条件都在块内集中管理。两套空调机组各调用一个FB100实例参数完全独立。FB110送风机控制块负责送风机的启停联锁、变频器控制和静压PID。块内部集成了变频器故障处理逻辑——变频器报警时先尝试自动复位一次如果复位后仍然报警则输出硬故障信号联锁停止相应的空调机组。FB120温湿度控制块这是整个程序里最复杂的一个功能块。内部包含两个温控PID房间温度主回路、送风温度副回路和两个湿控PID房间湿度回路、送风湿度回路还集成了冬夏工况切换逻辑。块内设计了一个工况判断代码——根据回风温度和室外温度自动判断当前应该执行加热模式、制冷模式、制冷除湿模式还是加湿模式然后对应的PID输出路由到正确的执行机构上。这个思路类似于汽车空调的自动模式只是判断依据和输出映射要复杂得多。FB130房间压差控制块负责各房间的压差闭环控制和排风阀的联动修正。因为车间里有六七个需要控制压差的房间每个房间分配一个FB130实例各实例之间的输出信号在做风量前馈计算时需要汇总到机组级别的FB140风量平衡计算块中统一处理。这些功能块都是在TIA Portal中用SCL语言编写的。早期的300时代很多人习惯用LAD梯形图写逻辑但对于PID运算、工况切换、批量数据处理这类逻辑梯形图写起来又长又难维护SCL的文本化表达清晰得多。而且S7-1500对SCL的支持已经非常成熟执行效率和代码可读性都有保障。4.3 PID参数整定的工程经验PID整定这部分想多聊几句。很多刚入行的工程师拿到一套系统之后第一件事就是问PID参数应该设多少。但实际上PID参数没有一个放之四海而皆准的数值它和系统的惯性大小、被控对象特性、采样周期都有关系。不过对于暖通空调这类温度控制对象还是有一些经验值可以参考的。以这个项目的温度控制为例送风温度副回路Kp2.5、Ti60秒、Td0不使用微分——这是比较典型的小惯性回路设置房间温度主回路Kp0.8、Ti300秒、Td15秒——大惯性对象需要更长的积分时间才能避免周期性超调波动。压力控制方面房间压差回路Kp1.2、Ti120秒、Td0。压差信号本身波动较大微分作用会放大高频噪声所以果断不用微分。湿度控制方面Kp1.8、Ti180秒、Td0。湿度对象滞后更大积分时间必须足够长否则湿度会在设定值附近来回摆动。但我必须强调这些参数并不是第一次就整定成功的。项目调试阶段我采取了这样的策略先手动控制各个执行机构观察被控量的开环响应特性粗略估算出过程增益和时间常数然后根据经验公式计算出初步的PID参数投入闭环后观察曲线再反复微调。前后大概花了两三天时间把四套控制回路的参数都调到了一个各自表现都比较理想的状态。还有一件事值得注意——洁净空调系统的PID我建议做积分分离和抗积分饱和处理。积分分离的逻辑是当偏差大于设定值的10%时停止积分作用只保留比例和微分当偏差回到10%以内时恢复积分。这样做的好处是避免大幅偏差时积分不断累积导致严重的超调。抗积分饱和方面S7-1500里实现的PID_Compact功能块本身就自带抗积分饱和机制直接利用即可但要确保输出上下限设置合理。我注意到有些同行把PID输出限幅设置得太保守结果执行机构根本达不到需要的开度控制器就在那里傻傻地积累偏差等偏差积累到一定程度输出又瞬间跳变整个系统就会周期性抖动。输出限幅一定要根据执行机构的实际行程范围来设定而不是随便填个0到100。5. 调试过程中避坑记录那些教科书上不会写的细节调试阶段是这个项目的重头戏前后大概持续了一个半月时间中间遇到的很多小意外恰恰是这套系统能否稳定长期运行的关键。单独把几类典型的坑记录下来希望能帮后来者少走弯路。5.1 传感器安装位置引起的假问题第一个坑是湿度传感器的安装位置。第一次调试的时候加湿器一投入工作送风湿度就一直往上冲PID已经把加湿量降到最低了湿度还在55%持续往上走。我开始以为是加湿器阀门的泄漏量太大检查了半天发现阀门关闭状态下关闭得很严密。后来去现场看了传感器安装位置——湿度传感器安装在了空调箱的送风竖管内离加湿器的喷口比较近。加湿器生产的高温高湿蒸汽直接喷射在传感器附近局部的湿度当然远远高于管道内的平均值。解决办法是把传感器位置后移了一段距离再加装了挡水板让气体充分混合后再经过传感器。这个问题如果处理不好控制系统会一直读取到偏高的湿度值从而错误地降低加湿量最终导致车间实际湿度偏低而不自知。温度传感器的安装位置也有类似的讲究。如果传感器安装在表冷器的出风端测到的是经冷却后的最低温空气温度如果安装在加热器之后测到的又可能是经过再热后的混合温度。不同位置测得的结果可能相差好几度直接影响串级控制副回路的准确度。这种安装细节虽然简单但牵扯到整个控制系统的测量基础处理不好后续所有整定都是白费功夫。5.2 过滤器压差信号的处理第二个坑和过滤器压差报警有关。洁净空调系统的初效、中效、高效过滤器都会设置压差监测用来判断过滤器是否堵塞。但直接使用压差变送器的实时值做报警判断会产生大量误报警——尤其是在风机变频启动阶段风量从零爬升到正常值的过程中过滤器两侧的压差也会从零逐渐上升到某个稳定值。如果报警值设置得太靠近运行值启动瞬间就会触发堵塞报警。我最终加入了一段启动抑制逻辑——风机启动后的120秒内过滤器压差报警自动屏蔽启动完成后通过比较实际压差和报警限值来决定是否触发报警。另外把报警限值设置成两个档位预报警提醒需要关注和正式报警提示需要更换或清洗中间设了恢复滞环。这样做的好处是报警触发之后如果压差出现轻微波动也不会反复报警和复位避免操作人员被连续的报警搞得麻木从而忽略了真正需要关心的问题。5.3 通讯故障时的设备动作策略调试过程中还特意做了一次Profinet通讯中断测试。正常通讯状态下一切都没问题但我好奇地问了自己一个问题如果分布式IO站的Profinet通讯突然断开变频器和执行机构会出现什么状态测试结果让我有些意外——有些变频器会保持断开前的运行频率继续运行有些执行机构会停止动作但保持当前开度。这种情况如果发生在生产过程中后果可能很严重通讯恢复之前送风机一直以某个固定频率运行房间压力可能会慢慢漂移温湿度控制也会失去调节能力。针对这个问题我给程序增加了一套通讯故障处理逻辑。在OB1中通过诊断指令实时监测Profinet设备状态一旦发现IO设备不可用立即执行如下动作保持送风机和排风机当前频率不变绝不直接停机否则洁净车间会迅速失压污染将所有的PID控制器切到手动模式并保持当前输出值不变HMI上弹出报警画面如果通讯中断持续超过5分钟触发声光报警通知值班人员检查网络。这套处理策略的核心理念是通讯故障时尽量保持系统回到手动稳态至少不要造成失控波动等通讯恢复后人工确认再切回自动模式。实际运维过程中这套机制确实在几次网络交换机故障时保护了生产环境。5.4 组态时的地址映射细节最后再记录一个TIA Portal组态过程中的细节问题。S7-1500和分布式IO站之间通过Profinet连接IO地址默认是自动分配的。如果先配置了模块但没做地址整理硬件组态里会有一些跳号的现象——比如AI模块的通道地址是IW64、IW66、IW76这种不连续的编号。这本身不影响功能但在编程的时候非常容易犯错尤其是模拟量通道较多的情况下地址映射关系一乱后续维护人员根本分不清哪个IW对应哪个传感器。我在项目开始时就在硬件组态里手动规划了地址分配方案所有DI模块统一用I0.0起连续编号AI模块统一用IW64起连续编号输出模块用Q0.0和QW80起编号。虽然手动改地址会多花些时间但换来的是程序里一目了然的对应关系。这个习惯后来在项目交付时收到了运维团队的明确好评——对他们来说根据图纸就能快速定位到指定通道不需要翻遍程序去查地址。6. 上位机SCADA系统与GMP数据完整性要求洁净空调项目不是PLC程序写完就能交差的上位机监控系统和数据管理也是整个系统的重要组成部分尤其在制药行业这部分和GMP认证直接相关。既然项目已经提到S7-1500为核心那上位机这一块配套的内容也一并梳理一下。6.1 监控画面的设计思路监控系统用的是经典的WinCC架构通过S7通讯协议从PLC读取数据。画面层次分为三个等级工厂总览画面——显示两套空调机组和新风机组的宏观状态用不同颜色区分运行、停机、故障状态机组详情画面——显示单台空调机组的完整控制系统图包括风管走向、阀门位置、风机状态、温湿度实时值、压差值等所有模拟量数值以数字和棒图两种形式呈现方便值班人员快速掌握运行状况参数设置画面——设置温湿度设定值、报警限值、PID参数需要更高权限等。为了满足GMP对操作可追溯性的要求在操作员画面上做了操作记录功能——每次操作员修改设定值、切换运行模式、确认报警WinCC都会自动记录操作人、操作时间、操作内容并存储到服务器数据库中不可更改。权限管理方面设置了三级操作员、管理员、工程师。操作员只能修改温湿度设定值和切换运行模式管理员可以修改报警限值、启停设备工程师拥有最高权限可以修改PLC程序、调整PID参数、配置系统参数。6.2 数据记录与审计追踪GMP的计算机化系统验证CSV对数据完整性有严格要求。这套系统实现了几个关键的数据记录能力连续趋势记录——温度、湿度、压差、风机频率、阀门开度等关键模拟量按1秒或者5秒的周期持续记录保存时间不少于一年事件记录——操作人员登录/退出、设定值修改、模式切换、报警产生/恢复等事件精确到秒报警记录——报警时间、报警点、报警值、恢复时间和确认人信息。数据备份也做了双通道——服务器端自动备份到本地存储阵列同时定时同步到异地备份服务器。这里有一个容易被忽略的地方PLC和上位机的时间必须保持同步。如果PLC的时钟和SCADA服务器的时钟存在偏差事件记录的时间线就会出现错乱这在GMP审计时可能会被判定为严重不符合项。我一般用NTP时间同步服务器统一整站时钟时间误差控制在几百毫秒以内。6.3 关于验证文档的补充说明聊到GMP就不能不提系统验证。洁净空调项目的PLC系统在上线之前通常需要完成全套验证文档——包括用户需求说明URS、功能设计规范FDS、软硬件设计说明HDS/SDS、风险评估RA等。这些文档的工作量不在程序本身之下而且很多内容需要依据实际的程序设计来写。作为工程师程序开发过程中如果就同步归档设计信息——例如修改记录、I/O清册、报警清单、配方参数表——验证阶段的工作量会大幅减少。我在这类项目中吃过亏程序都改了好几版了文档还停留在初始状态后来只能花大量时间重新追溯。所以在项目一开始就把文档同步率作为一项硬性要求——每一次PLC程序的变更都要对应更新FDS文件并且保留变更记录和确认记录。7. 项目交付后的运维要点和扩展思路系统交付并不等于项目结束。实际上制药厂的洁净空调系统需要长期稳定运行设备停摆带来的损失远超想象。最后分享几条运维阶段的心得以及后续的扩展思路。第一过滤器更换周期的管理。过滤网的更换不能单纯依赖固定时间周期。我给压差趋势记录做了长期跟踪随着运行时间推移会根据压差上升的趋势估算剩余寿命这个方法比固定周期更换要科学得多既能避免频繁更换浪费成本又能防止因过滤器堵塞导致送风量不足、洁净度下降。第二风机轴承和皮带更换提醒。风机运行小时数通过PLC累计到达设定阈值后系统自动提示保养。对制药厂来说不要等到风机报警停机了才去检查那个时候生产已经受到影响。第三冷热源联动的扩展。如果后续工厂的制冷机房和空调系统之间增加联动控制可以在PLC里增加一个通讯接口或者硬接点信号根据送风温度和冷源负载情况自动调节冷水阀开度和冷机启停台数实现冷源侧的按需供冷。这套系统的PLC程序架构已经预留了接口扩展起来会比较方便。最后再说说这个项目的整体感受。制药厂洁净空调的PLC控制难度不在某个单独的控制回路有多高深而在于整套系统如何把洁净度、压差、温湿度、能耗、合规性这些多维度的需求有机地统一在一起。刚接触这类项目可能会觉得头绪很多但顺着工艺需求→控制系统→硬件配置→程序设计→调试验证这条线走下来每一步都有逻辑可循。希望这篇文章能把我在这个项目中积累的经验传递出来特别是那些靠踩坑换来的细节能帮同行在后续项目中节省一些调试时间。