做药厂自控这几年，凡是带公用工程的项目，十有八九会碰到两个缩写：BMS和EMS。而只要聊到怎么把这两套系统落地，S7-1500和结构化编程这两个词就会被反复提起——它们几乎是现在药厂自控项目的标准解法。这篇文章不打算讲太多手册里的东西，就想用实际做过的项目视角，聊聊BMS/EMS程序到底怎么拆、怎么搭、怎么避坑。
如果你正准备接手药厂公用工程的自控系统，或者刚从S7-1200/S7-300往S7-1500平台迁移，再或者只是想知道BMS和EMS为什么总被放在同一个控制柜里，这篇内容应该能给你一套从架构到细节的参考。
1. BMS与EMS在药厂里到底差在哪：边界不清是所有混乱的起点
1.1 BMS管的是一套房子的"骨架和呼吸"
药厂里的BMS，行业全称是Building Management System，中文常叫楼宇管理系统。本质上跟商业综合体里的楼宇自控是同一类东西，只不过服务对象从"让租户舒服"变成了"让设备和房间维持在要求的状态"。覆盖范围一般包括空调机组（AHU）、排风机组、冷水机组、冷却塔、水泵、纯化水/注射用水循环泵、空压站、污水站、照明等等公用工程设施。
BMS的核心诉求是控制：把设备开起来、把温湿度拉回到设定值、把能耗压下去。它的控制精度不一定要达到工艺级那么苛刻，但逻辑可靠性、设备保护、故障恢复这些必须扎实。在药厂里，BMS做得不好，最常见的结果不是产品直接报废，而是洁净区的温湿度反复超限，逼得EMS不停报警，产品质量部门就得天天写偏差报告。
1.2 EMS管的是产品存活所需的"气候条件"
EMS在药厂语境里通常指Environmental Monitoring System，环境监测系统。它盯的是洁净室本身的状态：房间温度、相对湿度、相邻房间压差、尘埃粒子数、风速/换气次数，可能还有CO2、微生物采样状态等。这些参数直接和药品生产的洁净等级挂钩，属于GMP合规的硬指标，不是"差不多就行"的舒适度问题。
EMS并不具体控制某台设备，它的工作重心是连续采集、可靠记录、及时报警、留存证据。换句话说，BMS是“做事的”，EMS是“作证的”。一个洁净区房间压差不合格，BMS要负责调节送风/排风量去恢复，EMS要负责把"什么时候开始不合格、持续了多久、超了多少"完整记录下来，供QA评估产品质量风险。一个管执行，一个管证据，少了谁都不行。
1.3 两套系统为什么会出现在同一个控制柜里
既然定位不同，为什么项目里总是把BMS和EMS混在一个系统里讲？原因也很简单：从传感器和控制器的角度看，它们的物理层高度重叠。房间温湿度探头既给BMS做控制反馈，也给EMS做监测数据源；压差变送器装在墙上，信号都进同一个PLC或采集站。
我在实际项目里见过几种组织方式。一种是把BMS和EMS分别做两套独立PLC，物理隔离最干净，但造价高、IO浪费严重；另一种是共用一个PLC，BMS做控制逻辑，EMS用专门通道做数据采集和记录，上位机软件分层展示；还有一种是BMS负责全部采集，然后通过通讯把数据转发给一套独立的EMS服务器。最后一种在改造项目里最常见，因为旧厂已经有BMS，补EMS时最省事。没有绝对最好的方案，关键是把"谁能写、谁能读、数据归谁保管"在架构图里写清楚，否则后面联调时每一条数据的归属都要扯皮。
2. S7-1500做药厂BMS/EMS平台的选型逻辑：不是越贵越好
2.1 规模与算力：先数点位再选CPU
S7-1500的选型，第一步不是看品牌资料，而是把手里的点位表拉出来数。药厂一个中型制剂车间，BMS侧IO点大概三四百点，EMS侧采集点可能也是两三百点，再加上通讯对接的第三方设备，总规模很容易超过六百点。
点位数量直接决定CPU型号。我做过的最小项目用CPU 1511-1 PN就够，主要跑2台AHU和1套冷源系统，程序块满打满算不到二十个。后来换到一个综合性厂房，BMS加EMS总点数接近一千，我改用了带PN接口的1515-2 PN，算力和内存都留了余量。选CPU时还要看两个容易被忽略的指标：工作存储器和保持性存储器。大数据块、配方表、报警文本都吃内存，宁可多留30%余量，也不要卡在临界线上，后面加功能时根本没有后悔药。
2.2 通讯能力：Profinet为主，Modbus兜底
药厂BMS/EMS项目的通讯对象很杂：变频器、冷机群控网关、EMS上位机、洁净室粒子计数器、第三方多功能电表、制水间设备。S7-1500本身以Profinet为原生生态，IO设备、分布式IO站、第三方设备只要支持Profinet都能挂。但实际项目里，很多第三方小设备只支持Modbus RTU或Modbus TCP。
所以选型时我会特别确认CPU上有没有可用通讯模块位置。S7-1500用CM PtP模块做RS485/RS232，或者直接用Modbus TCP指令库走Profinet端口。如果你预期现场有超过两台Modbus RTU从站，建议直接预留CM PtP模块，不要用第三方网关转来转去——网关多一层，故障点就多一层，现场调试时定位问题的时间会成倍增加。
2.3 可靠性设计：冗余、电源与环网
药厂公用工程一般不允许长时间停机，BMS/EMS站的可靠性设计往往比算力更关键。制冷站冷机群控、总送排风系统这类核心站，预算允许时可以考虑S7-1500R冗余系统，两套CPU、一套环网，主备切换时间百毫秒级，大多数公用工程能接受。预算有限时，至少要把电源做成冗余，PLC机架、交换机、传感器回路分开供电。
还有一个常被忽略的点是Profinet网络拓扑。尽量把分布式IO、变频器、网关组成环网并启用MRP，这样单点断线不会导致整条链路上的设备全部失控。我在某个项目里就吃过亏：一条星形网络里中端的网线被叉车压断，后面二十多台IO设备全掉线，现场一片混乱，教训很实在。
2.4 软件生态：TIA里的库与版本管理
硬件定了，软件侧的选型同样影响后面的开发效率。S7-1500必须用TIA Portal编程，版本选择要统一，因为V15、V16、V17之间互不兼容，不同版本对CPU固件也有要求。我通常一个项目从头到尾只用同一个版本，中间不升不降，否则程序上传下载时版本冲突会非常折腾。
更值得花心思的是TIA的库功能。把常用的AHU控制、水泵控制、阀门控制、传感器采集做成全局库，拖到新项目里就能用，参数通过接口实例化。药厂项目之间重复度很高，上一套程序沉淀下来的库，往往是下一套项目进度最快的那部分。我会在每个项目结束时把修改后的库导回公共库，让库版本持续演进。这一点坚持下来，项目做得越多你会越轻松。
3. 结构化编程落地：把一个复杂系统拆成可以维护的积木
3.1 先从OB说起：谁在什么时间跑什么程序
结构化编程的第一步不是写FB，而是先规划OB组织块。OB1负责主循环，适合放设备控制的周期性逻辑；OB10这种时间中断块，适合做周期性采集任务，比如每5秒把所有EMS模拟量刷新一次，把温湿度、压差、粒子计数器的数据统一归档；OB82是诊断中断块，专门接收硬件诊断事件，比如Profinet设备掉站、模块故障；OB100在CPU启动时执行一次，用来做初始化和恢复操作模式。
实际项目里很多人只在OB1里写一大坨程序，这在几百点的小项目里问题不大，但到了药厂BMS/EMS这种规模，一定要把周期任务和事件任务分开。举个例子：EMS温度采集如果放在OB1里，逻辑扫描周期一变，记录间隔就跟着变，审计追踪里两条记录之间的时间差忽大忽小，解释起来非常被动。而放在OB10定时中断里，间隔是确定的，数据完整性更好看。
3.2 FB管设备，FC管算法：职责分离的思路
结构化编程最核心的理念是"一个功能块只做一类事"。在BMS/EMS程序里，我习惯把设备控制封装成FB，把计算和转换封装成FC。
FB适合做有状态的对象，比如一台空调机组、一台水泵、一个阀门。因为设备有启停状态、故障状态、手自动状态、联锁状态，这些状态必须存在背景数据块里，FB实例化之后天然携带这些数据。FC适合做纯函数型的逻辑，输入传参、输出结果，比如露点温度计算、焓值计算、Modbus报文解析、模拟量工程值换算。FC不持有状态，调用一次算一次，方便多处复用。
这样切分还有个好处：调试时思路清晰。设备不动作，先查FB的联锁条件；数值不对，去查FC的换算系数。如果混在一起写，你很难说是设备逻辑问题还是算法问题，光挨个查变量就能耗掉半天。
3.3 UDT和DB：把上千个点变成有名字的数据结构
点位多了以后，最怕的就是DB里一个一个定义变量，量大、容易错、改起来想哭。我的做法是先定义UDT（用户自定义类型），把同一类对象的属性打包。
比如定义UDT_AHU，里面包含：运行命令、运行反馈、故障反馈、手自动状态、送风温度实际/设定、回风温湿度、风机频率、压差报警、累计运行时间；再定义UDT_SENSOR，包含通道地址、工程值、量程上下限、报警上下限、质量戳、滤波时间。然后在全局DB里直接定义数组：AHU[1..8]、SENSOR[1..200]。这样上千个IO点不再是散落的变量，而是一个个有结构、有名字、可批量遍历的对象。
批量处理时配合FOR循环，对200个传感器做统一扫描、换算、报警判断，程序量一下子从两千行缩到几十行。真正改点位时，也只需要动UDT和数组大小，不用逐个变量去改。这一步做完，你会发现整个项目的复杂度和可控性有了质的变化。
3.4 状态机：设备控制的逻辑骨架
设备控制逻辑如果全用梯形图写互锁，会是一团乱麻。我在药厂项目中逐步转向用SCL写状态机，把每台设备看成"停止→启动中→运行→停止中→故障"几个状态，用CASE语句处理状态迁移条件和每个状态里的动作。
以AHU为例，停止状态下，只有"远程自动+无联锁故障"才能进入启动中；启动中时先开送风机，确认运行反馈到位再开加热/制冷阀、加湿器，然后进入运行；运行中只要收到急停、火灾联锁、风机故障，立刻跳故障或停止。SCL的写法大致是这样的骨架：
CASE state OF IDLE: IF start_cmd AND NOT fault THEN state := STARTING; END_IF; STARTING: IF fan_feedback THEN state := RUNNING; END_IF; RUNNING: IF stop_cmd OR fault THEN state := STOPPING; END_IF; END_CASE;状态机的好处是每个时刻程序只处理当前状态允许的动作，不会出现那种"阀门开了没关、风机停了还在锁"的交叉耦合问题。
状态迁移的记录一定要加时间戳和触发原因，这不仅是调试手段，也是报警追溯的证据。药厂QA问你"这台设备为什么停了"，你能直接调出状态记录说"9点12分35秒收到高温报警联锁，9点12分36秒执行停止命令"，整个沟通成本会低很多。
4. 药厂程序里的合规细节：报警、数据与权限的设计要点
4.1 报警分层：让操作员在300条报警里一眼看到重点
BMS/EMS报警设计如果只是把报警一股脑送到HMI，操作员在异常时会被几百条报警淹没。我习惯在程序里做报警分层分级，参考IEC 62682报警管理的基本思路来划分。
第一层是优先级区分，比如紧急报警（火灾、断电、核心设备故障、洁净室压差严重偏离）、高级报警（温湿度超限、EMS关键点失效）、中级报警（一般设备故障、参数偏离）、低级报警（维护提醒、累积量提示）。不同优先级对应不同HMI显示颜色、是否需要确认、是否进入报表。第二层是报警死区和延时，给波动信号一个缓冲，避免阀门动作引起的压力脉冲反复触发报警。第三层是报警抑制，比如设备停机状态下，它的停机原因报警不应弹出，否则一台停机设备能制造出一屏幕无效报警，真正重要的信息反而被淹没了。
4.2 数据记录：从PLC到审计追踪的完整链路
EMS的核心价值在数据记录。PLC采集的原始数据，经过换算和质量戳判断，按固定周期写入历史数据库。这个链路上有几个点必须设计清楚：时间戳、数据不可篡改性、记录完整性。
时间戳方面，S7-1500本体时钟要配置NTP同步，保证PLC和EMS服务器、HMI的时钟一致，否则两条记录之间时间对不上，偏差报告没法写。数据不可篡改性方面，PLC侧记录不要存在容易被人直接修改的普通数据块里，推荐通过上位机数据库入库，并给每条记录加校验字段或递增序列号，方便发现数据缺失或异常修改。记录完整性方面，一旦传感器断线或者质量戳异常，宁可记录"无效"标记，也不能假装没有数据。在审计里，缺数据比数据异常更麻烦。
4.3 权限管理与操作留痕：守住数据完整性的底线
能改设定值的人越少越好，但药厂倒班运行，操作员、班长、工艺员、维护工程师、系统管理员都可能碰系统。我的做法是三层权限模型：操作员只能看画面、消音、确认报警；工程师能修改设定值、启停设备、查看趋势；管理员负责用户管理、配方维护、系统配置。
更关键的是操作留痕。所有设定值修改、设备手动启停、报警确认动作都要记录"谁、什么时候、从什么值改成什么值"。HMI端的用户登录日志、操作日志属于审计追踪的一部分，PLC侧对关键变量的每一次写操作也应当通过专门的记录功能块处理。别让操作员能直接从HMI写数据块却不留痕，这是数据完整性的硬伤，一旦QA追溯起来，整个系统的可信度都会打折扣。
4.4 与验证团队的配合：程序交付不只是代码
药厂项目一定有验证流程，IQ/OQ/PQ里对自控系统有一堆要求。和验证团队配合时，我总结出一个原则：文档比代码更早开始。
程序设计阶段就要同步产出功能需求说明（FDS）、I/O清单、报警清单、联锁逻辑描述。验证团队拿到这些文档，才能制定测试用例。我见过一个项目，程序都写完了才补FDS，结果发现报警逻辑和设计文档不一致，整套联锁测试几乎是推翻重做。正确的节奏是：架构图上先把BMS/EMS边界画清楚，点位表定版本，FDS评审通过后再开始编码，程序完成后按FDS逐条做对照测试。这样看起来前期慢，后期反而最省时间。
5. 实战踩坑实录：通讯掉站、传感器断线与点位表管理
5.1 PROFINET设备离线之后，CPU差点停机
第一个坑是Profinet掉站导致的CPU停机。S7-1500默认情况下，分布式IO站或者PROFINET设备掉线，如果没有在CPU属性里配置反应，控制系统可能直接进入STOP。现场网线接头松动、某个IO设备断电，都会造成整条产线级别的故障。
解决办法有两个：一是在程序里组态OB82诊断中断，把设备掉站事件记录下来而不让CPU停机；二是给每个Profinet从站配置系统报警，把掉站信息发到HMI。我在项目里还会额外做心跳监控，用IO设备上的某个BOOL周期性翻转，CPU侧扫描翻转间隔，超过设定时间就认为是通讯中断，这样即使硬件诊断没触发，程序也能感知到异常。
5.2 4-20mA断线：温度低报还是传感器故障？
模拟量断线是BMS日常最频繁的假报警来源。标准的4-20mA电流信号，传感器断线后电流降到0mA，S7-1500模拟量输入模块转换出来的数值往往低于正常量程下限。如果程序里只做了正常量程报警判断，断线会被当成"温度低报"，操作员跑去现场查了半天，结果发现只是线松了。
正确做法是模拟量采集FC里做三件事：一是超量程判断，工程值超出传感器量程上限或下限，判定为信号异常；二是质量戳标记，异常信号在数据记录里标记为"BAD"而不是真实温度；三是专门报警，信号异常报"传感器故障"而不是"温度低报/高报"。我在设计UDT_SENSOR时专门加了Quality字段，所有报警判断和记录归档都要先看质量戳好不好，质量不好时数值不进控制逻辑。这一条看起来简单，但能帮你在项目后期省掉一大半的假报警排查时间。
5.3 模拟量滤波与PID的配合：稳和快如何平衡
洁净室温湿度控制的滤波参数，是调试时最容易反复折腾的地方。温度传感器响应本来就慢，如果再做太重的一阶滤波，PID看到的是一个"迟滞"的信号，控制输出会越来越钝，甚至出现振荡；如果完全不过滤，又会被瞬时扰动带偏。
经验做法是：传感器原始值先做质量判断和坏值剔除，再做一阶滤波，滤波时间常数根据房间体积和送风方式调，一般温度选30到60秒，压差选5到10秒，温湿度变送器出厂默认时间常数也要考虑进去。调试时把滤波后的值、PID输出、房间实际温度同时拉趋势对比，滤波时间一步步加，直到控制稳定且超调可接受。另外，手自动切换时PID的积分项要做无扰初始化，否则切换瞬间执行机构会猛地开大或关小，风口呼呼响，值班人员第二天一定会来找你。
5.4 点位表：Excel和TIA之间的一百个手误
药厂BMS/EMS项目点位动辄几百上千，点位表是唯一能串联电气图纸、PLC程序、HMI画面、验证文档的东西。点位表和PLC程序不一致，后面全是雷。
我的做法是把点位表当成程序开发的主索引：每个点位的PLC通道地址、符号名、量程、单位、报警设置全部在Excel里维护，再通过TIA的导入导出功能批量生成PLC变量。电气完成后用万用表逐点排查实际接线与点位表一致，程序里使用统一的符号名，HMI画面引用同样的符号。这样后期改点时，先改点位表，再同步到程序，电气、自控、验证三方拿到的永远是同一份数据。靠人肉一点一点在软件里敲IO地址，早晚要出一个隐蔽的错位，而错位一旦到了验证阶段，定位成本会非常高。
最后说点个人体会。药厂BMS/EMS项目做到后面，我越来越觉得结构化编程的本质从来不是"用没用FB/FC"这种形式问题，而是你有没有把系统边界、数据归属、职责分工想清楚。BMS和EMS的边界想清楚了，点位表自然就清楚；点位表清楚了，程序结构才能清楚；程序结构清楚了，后面的调试、验证、维护才会顺利。S7-1500只是把这一整套工程实践落地的载体，真正让项目稳定跑起来的，还是那些看不见的设计决策。
如果你也正在做类似项目，建议从一个小站开始：把UDT建好、把状态机搭起来、把通讯诊断补上，先跑通一台AHU再铺开。不要急着堆功能，先把"怎么拆"想明白，后面的路会顺很多。
