传统工业煎药自动化解决的是**“按固定时序自动完成煎煮”**的问题。PLC执行预设时间‑温度曲线上位机只做监控、记录与工单下发工艺参数大多依靠人工配置设备故障依靠事后报修很难处理药材差异、环境扰动带来的工艺波动。随着边缘硬件性能提升以及.NET生态AI能力成熟ML.NET、ONNX RuntimeAI不再局限于云端大数据分析而是下沉到车间本地工控机形成边缘AI PLC实时控制 WPF上位机业务层的全新技术栈。AI不再直接接管硬实时控制而是做工艺分析、参数推荐、异常预判由PLC完成最终执行这也是医药工控最稳妥的落地模式。一、现状矛盾传统自动化的能力边界现有PLC上位机架构已经可以实现浸泡、煎煮、挤压、清洗完整工序也支持多锅并行调度、断点续煎、批次追溯。但依然存在几个难以靠传统逻辑解决的痛点参数固化无法适配药材波动同样的处方不同批次饮片含水率、质地存在差异固定的升温、沸腾、保沸时间会造成煎煮效果不一致。单纯靠定时器、阈值判断很难做动态调整。故障只能事后报警缺少预判能力加热管老化、阀门密封件磨损、传感器漂移都是缓慢劣化过程。传统逻辑只有发生超温、液位异常才触发告警往往已经出现药液质量问题或设备停机。大量工艺曲线数据沉睡每一个生产批次都会产生完整温度、压力时序数据但仅仅存入数据库归档没有被挖掘利用药师经验很难沉淀为可复用数字化模型。上位机与PLC职责固化PLC负责确定性时序控制上位机负责人机交互二者之间只有参数下发和状态上报缺少对历史工况的反馈闭环。AI边缘计算的介入不是要替换PLC而是在这套成熟工控体系之上增加感知‑分析‑建议‑反馈闭环。二、边缘AI在工业煎药系统四大典型落地场景场景1工艺自适应优化实现“一方一策”动态调参药师开方讲究先煎、后下、久煎还要根据药材品质微调煎煮强度。传统设备只能选择预设几套模板。边缘AI工作流程上位机读取处方信息药材组成、药性、饮片品类边缘AI模型结合历史大量合格批次数据输出推荐工艺参数浸泡时长、升温速率、保沸时间、后下投料窗口参数下发至PLCPLC的状态机执行整套工序实时采集本次煎煮温度‑压力曲线与标准模板做比对如果出现升温偏慢、沸腾异常在安全约束范围内做小幅度参数修正批次完成后把本次结果回写给模型完成持续迭代。重要工程约束AI只输出推荐参数关键修改保留人工确认所有安全硬限制依然锁死在PLC内部AI不能越过联锁直接控制执行机构避免医疗质量风险。技术实现上可以基于ML.NET在C#上位机内部完成推理不需要额外部署Python服务减少跨语言运维复杂度。场景2设备预测性维护从“故障抢修”转向“状态维护”煎药车间高湿高温环境加热管结垢老化、电磁阀磨损、温度传感器漂移是高频故障。边缘AI在本地持续分析PLC上传的工况特征加热达到沸腾的时间变化趋势相同设定功率下实际温升速率阀门开关动作之后压力、液位响应曲线电机、水泵电流波动特征AI识别出部件缓慢劣化趋势在上位机提前生成维护工单不等设备彻底失效就安排保养。区分两类告警预测预警部件性能下降建议择机维护不中断当前生产传统硬告警已经发生异常立即暂停锅位触发安全联锁。场景3工艺异常智能识别减少不良批次产生煎煮过程会出现糊底、局部暴沸、液位异常扰动部分异常不会触发简单阈值报警。边缘AI对整条时序曲线做模式识别识别出异常工况模式升温曲线畸变、沸腾波动过大、浸泡阶段液位非正常漂移。一旦识别风险上位机弹窗提醒PLC可以根据配置选择预警提醒或暂停当前工序降低药液报废率。场景4生产数据智能分析辅助工艺沉淀与质量复盘每天几十上百个批次产生海量时序数据人工查看效率极低。边缘端完成本地统计分析不同处方煎煮效果统计、设备效率OEE统计、异常批次聚类只把提炼后的特征摘要上传云端原始时序数据保存在本地既节省带宽又满足医药数据本地化合规要求。云端则做多工厂、多煎药中心横向对比输出工艺改进建议。三、PLC、上位机软件的技术演进方向1. PLC角色依然是硬实时安全底座增加“数据输出接口”PLC不会被边缘AI取代安全联锁、时序状态机、断点续煎这些核心能力依旧在PLC完成。变化在于丰富过程数据点位除状态、报警之外高频输出温度、压力、功率、执行机构动作时序供给边缘AI分析开放参数可配置接口允许接收上位机下发的工艺参数集合而不是写死在ST/梯形图程序设置安全边界锁AI/上位机下发的参数PLC内部做范围校验超出安全区间直接拒绝执行。关键点即使边缘AI、上位机完全离线PLC依然可以独立完成当前批次完整煎煮安全逻辑不受上层影响。2. C#上位机从单纯监控软件升级为“边缘AI业务中枢”WPF上位机职责发生明显扩充原有能力不变工单调度、多锅调度、UI监控、权限管理、审计追溯新增边缘AI模块ML.NET/ONNX Runtime推理引擎、特征提取、时序数据预处理增加人机确认闭环AI生成的工艺建议、维护预警全部提供人工审核界面本地数据治理原始时序数据存储、清洗、特征提取网络正常时向云端同步摘要数据断网模式全部功能本地可用。3. 通信架构演进从简单读写走向时序数据流传统Modbus更多是轮询读写寄存器点位面向AI分析需要高频时序数据流。OPC‑UA订阅模式逐步成为主流持续输出过程曲线数据供边缘端做推理分析。同时保留Modbus兼容存量设备。4. 云‑边分工更加清晰边缘车间工控机实时推理、参数建议、本地控制闭环、原始数据保存断网可完整生产云端批量模型训练、多中心数据汇总、远程运维、工艺知识库更新训练完成的模型文件下发到边缘端做本地推理。绝对禁忌把煎煮实时控制放到云端。网络抖动、断网会直接造成生产事故。四、落地过程中不可忽视的工程挑战挑战1AI不能越权医药场景安全约束优先级最高很多开发者容易陷入误区用AI直接输出开关阀门、启停加热指令。医药装备质量风险极高AI只做分析、预警、参数建议最终执行与安全联锁必须由PLC负责同时关键参数变更留下完整审计追踪日志满足药监核查。挑战2高质量标注工艺数据获取难度大AI模型效果高度依赖大量经过药师确认的合格/不合格批次数据。很多煎药中心历史数据只做简单存储缺少标注。项目前期需要做数据治理建立批次‑效果标签体系。挑战3边缘硬件性能与成本平衡多路锅位同时输出时序数据AI推理会消耗CPU资源。需要做推理策略优化不需要每毫秒推理按工艺阶段做周期触发推理降低硬件压力普通工控机即可承载不必盲目升级高配硬件。挑战4模型版本管理与合规可追溯边缘端运行的AI模型同样需要版本记录什么时候更新、更新原因配合批次记录保证后续可以复盘某一批次使用的是哪一版模型。不能模型随意替换不留下痕迹。挑战5原有存量设备兼容改造大量已部署煎药机PLC不支持高频时序输出。改造项目需要权衡是升级PLC程序还是通过网关做数据采集实现边缘AI能力保护原有投资。五、给开发者的工程实践建议坚持分层架构不变PLC硬实时安全层 → C#上位机边缘AI业务层 → 云端大数据层职责不越界。优先做“辅助型AI”预测维护、异常识别、参数推荐不直接接管设备控制更容易落地验收。优先选用.NET原生AI栈ML.NET ONNX Runtime减少引入Python服务带来部署、运维、跨进程通信的复杂度。断网工况必须完整测试边缘所有AI分析、生产业务在离线状态下可正常运行。AI相关操作全部纳入审计日志参数建议、人工确认、模型版本全部留痕适配医药合规要求。六、总结AI边缘计算不是要颠覆已经成熟的工业煎药PLC上位机体系而是给这套系统增加智能分析闭环。PLC守住实时控制与安全底线C#上位机作为边缘载体承载AI推理云端负责训练与汇总。未来的工业煎药系统不再仅仅是“自动按时间加热”而是可以参考处方与历史生产数据给出工艺建议、预判设备故障、识别工艺异常在保证安全合规前提下推动中药煎煮工艺的标准化与数字化。