这两年前后主导了8套不同规模煎药中心的上位机软件开发从单店4工位的小型系统到30工位的产线级全自动生产线都有覆盖。最深的感受是煎药上位机看起来门槛不高无非就是实时监控、参数设置、数据记录三件事但真要做到好用、稳定、符合医药行业GMP合规要求差距全在配方、报警、追溯这三个核心模块的设计功底。很多项目上线后问题百出配方改乱了没人知道、报警泛滥没人看、数据追溯缺东少西本质都不是PLC的问题而是上位机软件的模块设计太粗糙只做了表面功能没考虑业务逻辑和行业特性。本文就从实战角度完整拆解中药煎药上位机的软件架构以及三大核心模块的设计思路、实现细节和踩坑经验。一、先搭骨架煎药上位机的整体分层架构做上位机不能上来就写功能先把分层架构搭清楚各个模块边界划清后期维护和扩展才不会乱。我们一般采用经典的四层架构从下到上分别是通信接入层、数据存储层、业务逻辑层、交互展示层。通信接入层数据存储层业务逻辑层交互展示层实时监控界面配方管理界面报警管理界面追溯查询界面系统配置界面配方管理引擎报警管理引擎数据追溯引擎生产调度逻辑权限管理模块实时数据库历史数据库系统配置库日志审计库OPC UA客户端Modbus TCP驱动第三方系统接口PLC控制器/现场设备通信接入层负责和底层PLC、现场仪表以及上层MES、ERP等第三方系统对接核心是协议转换和数据交互。现在主流用OPC UA做标准通信老设备用Modbus TCP兼容对外提供HTTP/数据库接口对接第三方系统。数据存储层分库存储实时数据存内存数据库保证刷新速度历史数据存关系型数据库保证持久化还有专门的配置库和审计日志库数据分类管理性能和合规都兼顾。业务逻辑层是整个软件的核心配方、报警、追溯三大引擎都在这一层还有生产调度、权限管理等公共模块所有业务逻辑都在这里处理不泄露到展示层。交互展示层就是操作人员看到的各个功能界面只做数据展示和操作输入不处理复杂业务逻辑保证界面响应速度也方便后续改界面不动逻辑。架构的核心原则是分层解耦、接口标准。比如以后要换通信协议只改接入层要改界面只动展示层不会牵一发而动全身。二、核心灵魂配方管理模块设计配方是煎药生产的核心依据这个模块绝对不是做几个输入框存参数那么简单。很多系统的配方模块最后成了混乱的根源就是因为只考虑了“存”没考虑“管”。1. 常见的设计痛点参数不全只存温度、时间几个基础参数实际生产需要的工序配置、先煎后下、搅拌逻辑都没有到了PLC里还是要改程序版本混乱配方改来改去没有版本记录出了问题不知道当时用的哪个版本的参数权限失控操作工随便就能改配方参数工艺标准形同虚设下发无校验参数超范围也能下发导致设备异常或者质量事故。2. 配方数据模型设计我们设计的配方数据结构分为四个层级完整覆盖生产全要素基础信息层配方编号、配方名称、对应病症、药材类型、版本号、状态、创建人、审核人工艺参数层浸泡时间、升温速率、沸腾温度、文火功率、煎煮时长、加水量系数、搅拌频率等12项核心参数工序配置层工序节点列表支持自定义配置浸泡、先煎、升温、沸腾、文火、后下、二煎、出药、清洗等工序每个工序独立配置参数对应PLC的柔性状态机权限属性层适用工位、权限级别、是否允许现场修改、修改范围限制。这样一套数据结构既能满足标准配方的固化生产也能支持复杂处方的柔性配置。3. 全生命周期版本管理配方不能是“一存了之”必须有完整的生命周期管理这也是合规的要求。否是新建配方草稿提交审核审核通过?退回修改发布正式版本生产调用修改配方生成新版本归档停用历史版本留存新建工艺员新建配方填写参数提交审核审核由主管审核配方参数审核通过才能发布不通过退回修改发布审核通过的配方正式发布只有发布状态的配方才能被生产调用归档过时的配方归档处理不能再调用但保留历史数据版本追溯每次修改配方都生成新版本保留修改记录旧版本可查可追溯生产记录绑定对应版本号。4. 下发与校验机制配方从上层下发到PLC必须有严格的校验机制不能什么参数都往下发。范围校验每个参数都有上下限超出工艺范围的参数直接拦截禁止下发格式校验数据类型、格式错误自动校验下发确认下发前弹窗确认显示参数清单确认后再执行下发结果回读下发后自动回读PLC里的参数和下发值对比不一致则报警确保下发成功。5. 实战避坑一定要做权限分级操作工只有调用权限工艺员才有编辑权限管理员才有审核权限绝对不能全员都能改配方配方修改必须留痕谁改的、改了什么、什么时候改的全部记录到审计日志可追溯不要把配方逻辑写死在界面里要做成独立的引擎不然以后加工序、加参数会非常麻烦。三、稳定保障分级报警模块设计报警模块是最容易被轻视的模块很多系统就是做个弹窗、响个蜂鸣器就完事了。但实际生产中报警是保障生产安全、质量稳定的核心也是事后追溯的重要依据。1. 传统报警设计的通病报警泛滥不管大小问题都报警一天几百条操作工根本看不过来最后真有严重报警也被淹没了不分级别超温和传感器故障都是同一个级别的报警没有优先级没有闭环报警弹出来没人处理也没人确认最后就消失了有没有解决都不知道不做记录报警只在界面显示不存数据库出了问题查不到当时的报警记录。2. 四级分级报警机制我们根据报警的严重程度和影响范围把报警分成四个等级不同等级对应不同的处理策略一级提示不影响生产的提醒类信息比如批次完成、配方下发成功只做界面提示不触发声光二级预警参数接近阈值还没影响生产比如温度偏高、液位偏低界面黄色高亮触发轻量声光提醒操作人员关注三级故障影响正常生产的故障比如传感器故障、阀门动作异常界面红色高亮声光报警需要立即处理四级紧急涉及安全和质量的严重故障比如超温、超压、干烧界面红色闪烁强声光报警同时联动PLC切断对应动力回路强制停机。分级的核心目的是让操作人员能快速区分轻重缓急把注意力放在真正重要的报警上。3. 报警全闭环管理每一条报警都要有完整的生命周期形成闭环管理不能石沉大海。产生触发条件满足自动生成报警记录存入数据库同时界面展示确认操作人员看到报警后必须点击确认记录确认人和确认时间处理故障处理完成后填写处理结果标记为已处理消除报警条件消失自动消除报警记录消除时间归档历史报警归档存储支持按时间、级别、工位查询统计。这样每一条报警从产生到消除谁确认的、怎么处理的、用了多长时间全部可查既倒逼操作人员处理报警也方便事后分析故障原因。4. 报警联动与安全联锁高级的报警系统不能只负责“喊”还要能联动处理。对于四级紧急报警必须做硬联动超温报警联动切断加热回路停止加热超压报警联动打开排气阀同时停止加热干烧报警联动切断全部动力禁止加热和搅拌急停报警全线停止所有动力输出。报警联动逻辑要在上位机和PLC各做一套双重保险避免单一系统故障导致安全失效。5. 实战避坑绝对不要什么都做报警可报可不报的一律不要报警泛滥比没有报警还可怕报警必须有确认机制没有确认的报警要一直提示不能自动消失报警声音要做区分不同级别用不同的提示音紧急报警要有明显区别所有报警必须持久化存储不能只存在内存里程序重启就没了。四、合规核心全链路追溯模块设计追溯模块是医药行业的硬性要求也是最容易做“表面功夫”的模块。很多系统的追溯就是查个温度曲线根本算不上全链路追溯。1. 追溯设计的核心原则批次唯一每一批次有唯一的追溯码所有数据都和批次号绑定全程覆盖从药材入库、生产过程、质检结果到成品出库全链路数据都要关联不可篡改历史数据只能追加不能修改删除保证数据真实性快速可查支持扫码查询、条件查询快速定位全链路数据。2. 以批次为核心的数据模型追溯模块的核心是批次所有数据都围绕批次组织。一个完整的批次档案包含基础信息批次号、处方信息、药材批次、生产工位、操作人员、开始时间、结束时间过程数据秒级采集的温度、压力、液位、功率等所有工艺参数完整的过程曲线事件数据报警记录、操作记录、配方变更、异常处理等所有事件质检数据成品质量检验结果、检验人员、检验时间出库信息成品流向、接收单位、出库时间。3. 数据存储与防篡改设计追溯数据的真实性是生命线必须从存储层面保证不可篡改。追加式写入所有历史数据只允许新增不允许修改和删除任何修改操作都生成新的记录保留原始数据操作审计所有对数据的操作都记录审计日志包括操作人、操作时间、操作内容、操作前后值定时备份自动定时备份数据支持异地备份防止数据丢失电子签名关键节点比如批次放行、质量确认需要电子签名验证不可抵赖。4. 追溯功能设计药材批次扫码生产工单创建配方调用 绑定批次生产过程秒级数据采集报警/操作事件记录成品质检数据录入成品赋码出库批次完整档案正向追溯查询反向追溯查询批次报表导出正向追溯输入批次号查看从原料到成品的全流程数据反向追溯输入药材批次查询用到该批次药材的所有成品批次批次档案完整的批次报告包含所有数据和曲线支持导出PDF打印统计分析按时间段、配方、工位统计合格率、故障率辅助工艺优化。5. 实战避坑不要只存温度数据报警、操作、配方版本这些事件数据比过程数据更重要缺了就不算完整追溯一定要做全系统时间同步PLC、上位机、服务器都要同步NTP不然数据时序混乱追溯就没意义了不要用Excel存追溯数据既不安全也不可靠必须用专业的数据库数据保存周期要符合法规要求医药行业至少保存5年数据库要做好扩容和归档策略。五、三大模块的联动逻辑配方、报警、追溯不是三个独立的模块而是互相联动、形成闭环的整体。配方是起点生产由配方驱动配方参数决定工艺标准也决定了报警的阈值报警是过程保障生产过程中的异常都通过报警记录所有报警事件都存入追溯体系追溯是数据沉淀所有生产数据、报警数据、操作数据都沉淀到追溯模块反过来又可以辅助优化配方。三者共同构成了煎药上位机的核心业务闭环剩下的监控、调度、报表都是围绕这个核心的延伸功能。六、总结与落地建议中药煎药的上位机软件本质是工业控制技术和医药行业特性的结合。技术是基础但真正决定系统好不好用、合不合规的是对行业业务的理解。三个核心模块的设计各有侧重配方模块管标准解决的是“生产什么标准”的问题报警模块管稳定解决的是“过程异常怎么办”的问题追溯模块管合规解决的是“生产过程可不可证”的问题。最后给几点落地建议先搭架构再做功能不要上来就堆界面架构乱了后期全是坑权限和合规要前置设计不要等验收的时候才补很多东西补不了功能做深不做多把三个核心模块做扎实比加一堆花哨功能有用得多预留扩展接口后期对接MES、ERP、云端平台的时候不用重构系统。