企业官网建设流程全解析

传统工业煎药自动化，解决的是**“按固定时序自动完成煎煮”**的问题。PLC执行预设时间‑温度曲线，上位机只做监控、记录与工单下发，工艺参数大多依靠人工配置，设备故障依靠事后报修，很难处理药材差异、环境扰动带来的工艺波动。

随着边缘硬件性能提升以及.NET生态AI能力成熟（ML.NET、ONNX Runtime），AI不再局限于云端大数据分析，而是下沉到车间本地工控机，形成边缘AI + PLC实时控制 + WPF上位机业务层的全新技术栈。AI不再直接接管硬实时控制，而是做工艺分析、参数推荐、异常预判，由PLC完成最终执行，这也是医药工控最稳妥的落地模式。

一、现状矛盾：传统自动化的能力边界

现有PLC+上位机架构已经可以实现浸泡、煎煮、挤压、清洗完整工序，也支持多锅并行调度、断点续煎、批次追溯。但依然存在几个难以靠传统逻辑解决的痛点：

1. 参数固化，无法适配药材波动
   同样的处方，不同批次饮片含水率、质地存在差异，固定的升温、沸腾、保沸时间，会造成煎煮效果不一致。单纯靠定时器、阈值判断很难做动态调整。
2. 故障只能事后报警，缺少预判能力
   加热管老化、阀门密封件磨损、传感器漂移，都是缓慢劣化过程。传统逻辑只有发生超温、液位异常才触发告警，往往已经出现药液质量问题或设备停机。
3. 大量工艺曲线数据沉睡
   每一个生产批次都会产生完整温度、压力时序数据，但仅仅存入数据库归档，没有被挖掘利用，药师经验很难沉淀为可复用数字化模型。
4. 上位机与PLC职责固化
   PLC负责确定性时序控制，上位机负责人机交互，二者之间只有参数下发和状态上报，缺少对历史工况的反馈闭环。

AI+边缘计算的介入，不是要替换PLC，而是在这套成熟工控体系之上增加感知‑分析‑建议‑反馈闭环。

二、边缘AI在工业煎药系统四大典型落地场景

场景1：工艺自适应优化，实现“一方一策”动态调参

药师开方讲究先煎、后下、久煎，还要根据药材品质微调煎煮强度。传统设备只能选择预设几套模板。

边缘AI工作流程：

1. 上位机读取处方信息：药材组成、药性、饮片品类；
2. 边缘AI模型结合历史大量合格批次数据，输出推荐工艺参数：浸泡时长、升温速率、保沸时间、后下投料窗口；
3. 参数下发至PLC，PLC的状态机执行整套工序；
4. 实时采集本次煎煮温度‑压力曲线，与标准模板做比对；
5. 如果出现升温偏慢、沸腾异常，在安全约束范围内做小幅度参数修正；
6. 批次完成后，把本次结果回写给模型，完成持续迭代。

重要工程约束：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. 云‑边分工更加清晰

• 边缘（车间工控机）：实时推理、参数建议、本地控制闭环、原始数据保存，断网可完整生产；
• 云端：批量模型训练、多中心数据汇总、远程运维、工艺知识库更新；训练完成的模型文件下发到边缘端做本地推理。

绝对禁忌：把煎煮实时控制放到云端。网络抖动、断网会直接造成生产事故。

四、落地过程中不可忽视的工程挑战

挑战1：AI不能越权，医药场景安全约束优先级最高

很多开发者容易陷入误区：用AI直接输出开关阀门、启停加热指令。
医药装备质量风险极高，AI只做分析、预警、参数建议；最终执行与安全联锁必须由PLC负责，同时关键参数变更留下完整审计追踪日志，满足药监核查。

挑战2：高质量标注工艺数据获取难度大

AI模型效果高度依赖大量经过药师确认的合格/不合格批次数据。很多煎药中心历史数据只做简单存储，缺少标注。项目前期需要做数据治理，建立批次‑效果标签体系。

挑战3：边缘硬件性能与成本平衡

多路锅位同时输出时序数据，AI推理会消耗CPU资源。需要做推理策略优化，不需要每毫秒推理，按工艺阶段做周期触发推理，降低硬件压力，普通工控机即可承载，不必盲目升级高配硬件。

挑战4：模型版本管理与合规可追溯

边缘端运行的AI模型，同样需要版本记录：什么时候更新、更新原因，配合批次记录，保证后续可以复盘某一批次使用的是哪一版模型。不能模型随意替换，不留下痕迹。

挑战5：原有存量设备兼容改造

大量已部署煎药机PLC不支持高频时序输出。改造项目需要权衡：是升级PLC程序，还是通过网关做数据采集，实现边缘AI能力，保护原有投资。

五、给开发者的工程实践建议

1. 坚持分层架构不变：PLC硬实时安全层 → C#上位机边缘AI业务层 → 云端大数据层，职责不越界。
2. 优先做“辅助型AI”：预测维护、异常识别、参数推荐，不直接接管设备控制，更容易落地验收。
3. 优先选用.NET原生AI栈ML.NET + ONNX Runtime，减少引入Python服务带来部署、运维、跨进程通信的复杂度。
4. 断网工况必须完整测试，边缘所有AI分析、生产业务在离线状态下可正常运行。
5. AI相关操作全部纳入审计日志，参数建议、人工确认、模型版本全部留痕，适配医药合规要求。

六、总结

AI+边缘计算不是要颠覆已经成熟的工业煎药PLC+上位机体系，而是给这套系统增加智能分析闭环。PLC守住实时控制与安全底线，C#上位机作为边缘载体承载AI推理，云端负责训练与汇总。

未来的工业煎药系统，不再仅仅是“自动按时间加热”，而是可以参考处方与历史生产数据，给出工艺建议、预判设备故障、识别工艺异常，在保证安全合规前提下，推动中药煎煮工艺的标准化与数字化。