企业官网建设流程全解析

从事中药煎药工控开发三年，跑过十几家药企、上百套设备现场，最深的感触就是：从零搭建产线，上手就写温控逻辑的，最后基本都要返工。

很多新手甚至中小型团队，做煎药自动化总觉得核心就是PID控温，能加热能计时就算做完了。等到量产落地才发现：工序跳步、温控超调、多锅抢资源、断网丢数据、GMP验收通不过，问题成堆爆发。本质上就是从一开始就没搭对框架，忽略了状态机的严谨性、工艺的特殊性和追溯的强制性。

真正能落地量产的煎药自动化产线，永远是状态机做骨架、PID温控做核心、上位机追溯做闭环，三者缺一不可。PLC侧把工艺状态和安全逻辑焊死，就算上位机宕机、网络中断，也能独立把药跑完；上位机把业务、数据、合规管起来，满足生产管理和验收要求。

本文就从0到1完整拆解：从分层架构定边界，到单锅结构化状态机设计、分段自适应PID调优，再到多锅集群调度、上位机追溯系统落地，覆盖所有核心逻辑与现场避坑点，可直接用于项目开发与验收。

一、搭建第一步：先定分层架构，明确职责边界

从零搭建最忌讳上来就写代码，先把架构边界划清。整套产线采用经典五层架构，每层职责单一、依赖方向单向，后续不管是扩工位还是加功能，都不会打乱整体结构。

1.1 整体五层架构

从下到上依次是现场设备层、设备控制层、产线调度层、企业管理层、数据决策层，越往上越偏向业务，越往下越靠近工艺。

1.2 各层核心职责

1. 现场设备层：最底层执行终端，包含温度/压力/液位传感器、电磁阀、加热模块、搅拌电机等。负责信号采集和指令执行，是整个系统的感知与执行末梢。
2. 设备控制层：PLC/DCS核心，负责单锅工艺流转、分段PID温控、硬件安全联锁、异常保护。所有和时序、安全相关的逻辑全部沉在这一层，是产线稳定的底线。
3. 产线调度层：单机和产线的核心区别。负责多锅工单分配、生产节拍平衡、水电负载均衡、故障设备隔离，解决多锅并行的资源争抢与参数漂移问题。
4. 企业管理层：对接医院HIS、药企MES、ERP系统，实现处方自动接收、工单自动下发、生产状态回传，打通设备与业务的数据壁垒。
5. 数据决策层：基于历史生产数据统计产能、能耗、故障率，迭代最优工艺参数，实现故障预警与工艺升级。

核心原则：所有和工艺时序、安全联锁相关的逻辑，必须全部放在PLC里。上位机就算崩了、网断了，PLC也要能独立把当前这锅药跑完。这是医药工控的铁律，也是从零搭建最容易踩的边界误区。

二、核心基石：单锅结构化状态机设计

单锅是整条产线的基础，状态机设计不严谨，后续扩产只会把问题成倍放大。摒弃零散的标志位跳转，采用**「主状态 + 子步」**的分层结构化设计，每个状态严格遵循「入口动作 + 周期逻辑 + 出口条件」三段式规则，后期改工艺、加工序只需要新增节点，不用到处改逻辑。

2.1 完整主状态流转

标准中药煎煮完整工序共9个主状态，全程不可逆、不可跳步：
待机就绪 → 定量进水 → 恒温浸泡 → 武火升温煮沸 → 文火微沸煎煮 → 二次补水加料 → 浓缩静置 → 药液输出 → 药渣挤压 → CIP自动清洗 → 沥干复位 → 待机就绪。

每个主状态内部再拆分子步，比如定量进水拆分为：开进水阀 → 流量累计计量 → 关进水阀 → 液位校验四步，每一步都有独立的超时与异常判断，不会出现“阀门卡了还一直等”的死锁情况。

2.2 状态机三段式设计规范

每个状态统一按三段式逻辑编写，可维护性大幅提升：

• 入口动作：进入状态的瞬间执行一次，比如开阀、启动计时、复位标志位；
• 周期逻辑：每个扫描周期执行的逻辑，比如PID计算、温度检测、条件判断；
• 出口条件：满足条件后跳转下一状态，比如计时到、温度达标、液位到位。

2.3 硬安全联锁：独立于状态机的底层保护

安全逻辑不能写在状态机里，必须独立在最底层，就算状态机跑飞，保护机制依然生效。现场验证缺一不可的联锁包括：

• 罐门未完全闭合，锁定加热、升压、进水所有高危动作；
• 罐内压力超限，自动泄压并强制停止加热输出；
• 液位低于防干烧阈值，立即停机报警，锁定加热模块；
• 设备运行中检测到开盖动作，瞬时断电，终止所有工序；
• 电机过载、阀门卡滞，立即触发故障日志并停机保护。

2.4 断点续煎：掉电保持与分级校验

医药生产物料不可逆，断电不能直接复位重来。

• 核心变量掉电保持：主状态编号、子步序号、工序剩余计时、故障代码、当前配方参数，全部设置为掉电保持，非核心变量不勾选，避免加快闪存损耗。
• 分级续跑校验：上电恢复后先校验中断时长、温度变化、工序阶段。短时中断且状态正常自动续跑；长时中断或状态异常，锁定状态等待人工确认，不盲目续煎导致质量问题。

三、温控核心：分段自适应PID调优方案

温控是煎药机的核心功能，但很多人栽在“一套PID参数用到底”。中药煎煮不是恒温控制，不同工序对温控的需求完全相反，固定参数必然超调溢锅、沸腾不稳。

3.1 为什么固定PID行不通

煎煮过程分为浸泡、升温、保沸、文火四个阶段，需求差异极大：

• 浸泡阶段：只需要低温补偿，温度不能波动大；
• 升温阶段：要快速升温，响应速度优先；
• 保沸阶段：要维持剧烈沸腾，功率在高位波动；
• 文火阶段：要维持微沸，输出要小要稳，避免挥发和糊底。

一套参数根本无法同时满足“快升”和“稳温”，必须分段配置。

3.2 四段PID分段方案

按照工艺阶段拆成四段，每段独立PID参数、独立输出限幅，从根源解决超调、沸腾不稳的问题。

升温阶段增加提前降功率逻辑：距离沸点预估阈值还差5℃时，逐步限制输出上限，从100%降到70%，靠余热冲温，避免冲温溢锅。

3.3 沸腾复合判定：不硬编码100℃

不要用“温度≥100℃判定沸腾”，不同海拔、不同气压沸点不一样，硬编码到高原项目直接翻车。
采用**「温度区间 + 温升速率」**双条件复合判断：

1. 温度进入沸点预估区间（现场可配置，默认95~100℃）；
2. 连续3秒温升速率小于0.3℃/分钟。

两个条件同时满足才判定沸腾，适配不同现场环境，现场只需要微调温升速率阈值即可。

3.4 现场调参心得

• PID不用追求完美曲线，煎药不是实验室恒温槽。不溢锅、不糊底、沸腾稳定，工艺达标就够了；
• 所有参数都做成可配置的，放在配方参数里，不同处方、不同现场，运维自己就能调，不用改程序；
• 调试的时候先把功率上限锁在30%，确认方向和逻辑没问题，再慢慢往上加，不然一上来就满功率很容易溢锅。

四、产线扩展：多锅集群调度逻辑

单锅稳定后，直接复制多套并行运行，是90%项目翻车的根源。多锅共用供水、供电系统，集中动作会导致负载波动，必须加上集群调度层。

4.1 公共资源负载均衡

进水总管、清洗水泵、排渣传送带这类独占公共资源，统一执行**「申请 → 排队等待 → 授权使用 → 用完释放」**的闭环流程。
锅位执行到需要公共资源的工序，先向调度块发申请；资源被占用就进入队列按优先级排队；资源空闲后按顺序分配；工序执行完立刻释放。从根源上杜绝多锅抢资源的冲突。

4.2 整机功率错峰

多锅同时武火升温，瞬时功率很容易跳车间总闸。
调度层实时统计所有锅位的加热输出总功率，当总功率接近供电上限时，对新申请的升温任务做延后排队；优先保证已经进入沸腾、文火阶段的锅位功率。不用改工艺，只是错开升温时间，就能把功率峰值压下来，完全不影响整体产能。

4.3 分级故障隔离

产线最忌讳“一锅故障，全线停工”，采用三级故障处理机制：

• 单锅级故障：只暂停当前锅位，锁定工单，释放公共资源，其他锅位正常生产；
• 资源级故障：比如清洗泵坏了，所有需要该资源的工序进入等待状态，不影响正在煎煮的锅位，故障排除后自动恢复；
• 全线级故障：急停、总电源异常，所有锅位立刻执行安全停机流程。

4.4 分层通讯组网

产线采用分层组网，兼顾实时性与稳定性，适配工业复杂环境：

• 底层设备与IO：RS485/PROFIBUS总线，保障控制指令实时响应；
• PLC与上位机：TCP/IP以太网，传输工艺数据、运行日志、故障信息；
• 上位机与MES/云端：MQTT/HTTP协议，实现工单同步、数据上传、远程监控。

同时增加心跳检测、断线缓存、自动重连机制，杜绝现场网络波动导致的工序中断、数据丢失问题。

五、数据闭环：上位机与追溯系统实现

量产项目的验收核心从来不是设备能跑，而是数据合规、全程可追溯。上位机是整个产线的数据核心，也是GMP验收的关键载体。

5.1 上位机基础架构

采用MVVM分层架构开发，分层解耦，可维护性强，完全匹配工控场景的多设备复用、高频刷新需求。技术栈选用WPF + CommunityToolkit.Mvvm + OPC UA客户端，和PLC侧完全解耦，替换任意一边都不影响另一边。

• View层：纯展示和输入，所有数据通过绑定，后台代码几乎没有业务逻辑。包含主监控界面、参数面板、报表界面等；
• ViewModel层：业务逻辑核心。接收服务层数据，转换成界面显示格式，封装用户操作命令，全程不引用任何界面控件；
• Model层：纯数据实体。对应PLC节点结构、业务数据表结构，不包含任何逻辑；
• 服务层：基础设施封装。OPC UA通信服务、数据归档服务、报表服务等，向上层提供接口。

5.2 追溯系统核心设计

追溯系统围绕“批次”展开，实现从处方到成品的全链路可查。

1. 配方版本管控

配方不是普通参数，是受控技术文件。遵循「草稿→审批→生效→归档」完整流程：

• 每个版本独立完整，不基于差异存储，追溯的时候直接取对应版本即可；
• 生效中的配方禁止修改，要改必须新建版本，走审批流程；
• 工单启动的瞬间，绑定当时生效的配方版本号，批次运行中途，配方升级不影响当前批次。

2. 批次全链路追溯

每一批次完整保存：

• 基础信息：工单编号、处方版本、操作人员、开始结束时间；
• 过程数据：全程秒级温度、压力、液位曲线，各工序执行时长；
• 事件记录：告警信息、操作记录、异常处理、断点续煎记录。
  所有数据采用追加式存储，禁止修改删除，满足GMP审计要求。

3. 双写持久化机制

单靠数据库非常不可靠，数据库挂了、服务器重启，都会导致生产数据丢失。
采用本地文件优先，数据库异步同步的双写策略：

• 所有生产数据优先写入本地文件，写入成功就算成功；
• 后台异步同步到关系数据库，用于查询和报表；
• 数据库故障时，本地正常写入，恢复后自动补同步，完全不影响生产。

5.3 上位机核心功能

• 实时可视化：整线设备状态、工序进度、温度压力参数实时展示，支持单锅详情弹窗；
• 配方管理：新增、修改、批量导入导出处方工艺参数，支持版本查询；
• 工单调度：接收MES工单、手动派单、优先级任务调度，自动分配空闲锅位；
• 故障报警：弹窗+声光提醒，自动记录故障时间、位置、原因、处理记录；
• 报表导出：生产、能耗、故障报表一键导出，满足验收需求。

六、落地避坑与选型建议

6.1 现场高频踩坑汇总

结合十几条产线落地经验，整理出从零搭建最容易踩的6个坑，提前规避能节省大量调试时间：

• 全程固定PID参数：煎煮各阶段温控需求不同，固定参数必然超调、温度不稳，必须采用分段自适应方案；
• 多锅无调度直接并行：资源争抢导致时序错乱、参数漂移，量产必须加负载均衡调度逻辑；
• 无断线容错机制：车间网络波动频繁，无缓存重连逻辑会导致工序中断、数据丢失；
• 安全连锁逻辑缺失：重控制、轻安全，忽略开盖、超压、干烧保护，无法通过药企安全验收；
• 数据无结构化存储：仅显示参数不存日志，无法满足量产溯源合规要求；
• 忽略电磁干扰：加热模块、电机启停干扰模拟量信号，必须做好接地、屏蔽、信号滤波处理。

6.2 不同场景方案选型

• 小型诊所/单锅设备：一体式PLC+简易上位机，基础工艺+定时控制，低成本落地；
• 中型煎药车间（4-8锅）：PLC+分布式IO+独立上位机，支持多锅调度与数据记录；
• 大型药企量产产线（16锅以上）：DCS集散控制+MES对接+云端数据平台，全自动化合规生产。

6.3 稳妥迭代流程

单锅硬件调试→单锅工艺与容错逻辑完善→多锅硬件组网→集群调度逻辑开发→上位机数据系统搭建→MES云端对接→压力测试与合规优化，循序渐进迭代，最大程度规避项目返工风险。

总结

中药煎药自动化产线，是典型的工艺+硬件+软件+安全+合规系统性工程。从零搭建，核心就是抓好三件事：用结构化状态机把工艺流程焊死，用分段PID把温控精度做准，用追溯系统把数据合规闭环。

很多项目做不好，不是代码能力不足，而是一开始就没理清边界，把工艺逻辑放上位机、把安全逻辑当可选、把数据追溯当摆设。本文分享的架构设计、核心逻辑、避坑方案，完全适配中小型车间到大型药企的全场景量产需求，开发者可直接借鉴落地，快速解决现场90%以上的疑难问题。