随着智慧中药房、集中代煎中心大规模落地，中药煎药已经从传统人工煎煮，转向以PLC工艺控制、上位机监控、全链路追溯为核心的自动化模式。政策层面《医疗机构中药煎药室管理规范》对煎煮过程留痕、批次追溯提出硬性要求，倒逼行业软硬件体系快速升级。但在项目落地过程中，大量项目出现硬件自动化到位，软件协同、工艺数字化、合规能力跟不上现实业务的矛盾。本文从工程开发视角，梳理工业煎药自动化系统的技术演进方向，同时剖析现实项目中遇到的工程难点。
一、行业现状：从单机自动化走向产线数字化
早期工业煎药机只解决“自动加热、自动包装”，设备本身是独立单机，PLC只负责简单时序逻辑，没有统一上位机管理，处方录入、工艺参数配置、生产记录依赖人工填写纸质台账。
现在的集中煎药中心，十几台甚至几十台煎药锅并行工作，完整链路覆盖：HIS处方接收→药材调剂→浸泡‑煎煮‑挤压‑清洗全工序→药液灌装贴标→药渣处理→批次归档追溯。传统单机模式已经无法满足多锅调度、处方匹配、数据合规归档的需求。
硬件层面，国产PLC、传感器、执行机构普及率持续提升；软件层面，C# WPF上位机、OPC‑UA通信、边缘网关逐步成为标配。但软硬件割裂、工艺模型薄弱、数据孤岛、合规实现复杂，仍是绝大多数项目的共性痛点。
二、五大核心技术发展趋势
趋势1：控制架构演进，单机状态机升级多锅集群调度
单锅内部继续强化分层有限状态机FSM，浸泡、煎煮、挤压、清洗每个工序拆分为主状态+内部子步，入口动作、周期执行、出口判定三段式逻辑，实现断点续煎、异常暂停恢复，解决药材不可逆不能简单复位重启的行业痛点。
产线层面从单锅独立运行，演进为调度层+设备层两层架构。调度系统统一管理工单队列、公共资源仲裁（进水、排渣、清洗管路、总功率错峰），解决多锅并行时资源争抢、总功率过载跳闸问题。
不再是每台锅一套独立程序，而是FB功能块实例化，新增锅位只需要实例化功能块，调度配置即可完成扩容，软件可扩展性大幅提升。
趋势2：云‑边协同架构成为主流，边缘负责实时控制，云端负责业务分析
实时工艺控制下放到本地工控机与PLC，保证煎煮时序、温控、安全联锁不受网络波动影响；上位机作为边缘节点，完成设备采集、本地存储、告警处理；云端承担远程运维、处方统计、工艺大数据分析、设备预测性维护。
工程关键点：断网可本地完整生产，网络恢复后补传历史数据。不能把煎煮控制逻辑放到云端，网络抖动会直接造成生产事故。
OPC‑UA逐步替代Modbus成为产线内部主流通信，解决多设备统一接入，同时支持安全加密，满足医药行业对通信安全的基础要求。
趋势3：工艺数字化：从固定配方走向“一方一策”自适应煎煮
过去很多设备只是内置几组固定时间温度参数，不管什么处方，都是一套流程，很难还原先煎、后下、久煎等古法工艺逻辑。
未来系统会建立饮片工艺知识库，根据处方药材属性自动生成整套工序参数：根茎类延长浸泡煎煮时间、花叶类控制沸腾时长减少挥发成分流失；支持先煎后下自动分时投料。更进一步结合ML.NET等.NET原生AI能力，基于历史批次数据，对温度、时间、压力做小范围自适应调优，实现工艺自优化。
这里需要区分：AI不是替代药师，而是把老药师经验沉淀为可执行数字化参数，系统负责精准执行。
趋势4：全链路可信追溯，适配医药合规要求
合规不再是附加功能，而是硬性刚需。从处方ID、药材入库批次、操作人员、每一步煎煮曲线、告警记录、灌装时间一直到患者签收，全流程数据不可篡改存储，支持审计追踪。
上位机需要完整记录每一次人工干预：暂停、恢复、手动干预阀门、修改工艺参数，全部留下操作人员与时间戳，满足药监核查、医保飞检要求。
趋势5：国产软硬件全栈适配
国产统信、麒麟操作系统+国产PLC + C# .NET跨平台上位机的组合越来越多。过去很多项目依赖国外硬件，现在项目要求整套系统国产化适配，也对开发者提出新要求：处理不同PLC协议差异、操作系统IO行为差异、串口/网络驱动兼容等问题。
三、现实项目的核心工程挑战
挑战1：工艺控制和业务软件容易出现两张皮
PLC负责底层时序与安全联锁；C#上位机负责处方、工单、UI展示、数据存储。很多项目二者边界模糊，业务逻辑写到PLC，或者时序控制放到上位机。
工程坑：上位机软件崩溃、网络中断，直接导致煎药工序错乱。
正确边界：所有和安全、时序、工艺强相关逻辑全部留在PLC，上位机只下发参数、下发指令、读取状态，不参与实时流程驱动。就算上位机离线，PLC可以完整完成当前批次煎煮。
挑战2：多锅并行调度的资源冲突与功率管控
多锅同时工作，进水总管、排渣传送带、清洗水泵属于独占资源，如果不做统一仲裁，多锅同时请求，会出现阀门打架、水压不足，煎煮工艺达不到预期。
同时多锅同时升温会瞬间拉高总功率，容易触发车间空开跳闸。很多项目前期测试单锅一切正常，上线跑多锅之后才暴露问题。
解决思路：调度层做资源申请‑授权‑释放机制，总功率实时统计，对加热任务做错峰排队。
挑战3：断点续煎与异常处理的复杂性
普通流水线故障可以复位从头跑；煎药锅内已经投入药材，属于不可逆物料。
轻微故障断电、网络断开、传感器临时异常，恢复之后，必须从中断的状态、子步、剩余计时继续往下跑，不能复位重新开始。
要求PLC侧主状态、子步号、各个定时器剩余时间全部配置掉电保持；上位机同步缓存批次进度，故障恢复后双向状态同步。
区分两类故障：单锅故障只隔离单锅，其余锅继续生产；公共资源故障，所有依赖该资源任务进入等待；急停、安全故障触发全线安全停机。分级故障处理逻辑复杂，很容易出现考虑不周。
挑战4：医药合规带来软件复杂度上升
普通工控只需要实现功能，医药装备额外增加大量合规约束：
- 所有操作审计日志，不能简单日志打印，要保证数据防篡改；
- 用户权限分级，修改关键工艺参数需要二次校验；
- 完整批次数据归档，支持多年历史检索；
- 数据导出、报表格式要满足检查要求。
很多开发者习惯普通上位机开发，容易忽略审计追踪、权限校验这些非业务功能，等到验收阶段才大规模返工。
挑战5：协议碎片化，设备互联互通困难
市面上煎药设备厂商众多，大量设备使用私有协议，没有统一标准。同一个产线可能接入多家设备，每个设备报文格式、字节序、数据点位各不相同，上位机接入工作量巨大。
虽然已有团体标准，但落地普及率不高，现实项目经常需要做协议转换网关。对上位机设计要求：抽象设备接口层，对外统一接口，内部适配不同厂商协议，隔离上层业务。
挑战6：现场环境复杂，7×24小时长期稳定运行考验
煎药车间高温高湿，电磁干扰大，串口、网络通信偶发干扰，会出现CRC错误、报文异常。系统要具备通信容错：CRC校验、报文完整性解析、断线自动重连、报文丢弃过滤。
同时WPF上位机长期运行，高频刷新UI、图像、大量日志写入，如果不做好内存管控，运行数天出现内存泄漏，程序卡顿崩溃。
四、面向开发者的落地实践启示
- 严格分层解耦：PLC专注实时控制与安全联锁；C#上位机专注工单管理、人机交互、数据追溯；调度层负责多锅协同，三层职责清晰，不要越界。
- 优先保障PLC本地自治能力：网络、上位机故障不允许破坏正在执行的煎煮工序。
- 工艺知识库与控制逻辑分离：配方参数存放在可配置区域，不要硬编码写死在梯形图或者ST代码中，方便后续迭代优化工艺。
- 把合规需求提前纳入需求，不要作为后期补丁：审计日志、权限、批次追溯在架构阶段就要规划。
- 充分模拟多锅并发场景做压力测试，不要只用单锅测试就上线。
五、总结
中医药装备数字化，不只是把传统煎药机加上屏幕和网络。真正的升级，是把中医煎煮经验转化为一套可执行、可复现、可追溯的软硬件系统。
未来几年，行业会持续向着集群调度、云边协同、工艺AI自优化、全链路合规追溯方向演进。对于C#/.NET工控开发者，既要精通PLC状态机、工业通信、上位机性能优化这些通用工控技术，又要理解中医药业务的特殊约束（不可逆物料、先煎后下、合规审计），才能交付真正可以稳定跑在煎药中心的工程系统。
