企业官网建设流程全解析

这两年前后主导了8套不同规模煎药中心的上位机软件开发，从单店4工位的小型系统到30+工位的产线级全自动生产线都有覆盖。
最深的感受是：煎药上位机看起来门槛不高，无非就是实时监控、参数设置、数据记录三件事，但真要做到好用、稳定、符合医药行业GMP合规要求，差距全在配方、报警、追溯这三个核心模块的设计功底。

很多项目上线后问题百出：配方改乱了没人知道、报警泛滥没人看、数据追溯缺东少西，本质都不是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年，数据库要做好扩容和归档策略。

五、三大模块的联动逻辑

配方、报警、追溯不是三个独立的模块，而是互相联动、形成闭环的整体。

• 配方是起点：生产由配方驱动，配方参数决定工艺标准，也决定了报警的阈值；
• 报警是过程保障：生产过程中的异常都通过报警记录，所有报警事件都存入追溯体系；
• 追溯是数据沉淀：所有生产数据、报警数据、操作数据都沉淀到追溯模块，反过来又可以辅助优化配方。

三者共同构成了煎药上位机的核心业务闭环，剩下的监控、调度、报表都是围绕这个核心的延伸功能。

六、总结与落地建议

中药煎药的上位机软件，本质是工业控制技术和医药行业特性的结合。技术是基础，但真正决定系统好不好用、合不合规的，是对行业业务的理解。

三个核心模块的设计，各有侧重：

• 配方模块管标准，解决的是“生产什么标准”的问题；
• 报警模块管稳定，解决的是“过程异常怎么办”的问题；
• 追溯模块管合规，解决的是“生产过程可不可证”的问题。

最后给几点落地建议：

1. 先搭架构再做功能，不要上来就堆界面，架构乱了后期全是坑；
2. 权限和合规要前置设计，不要等验收的时候才补，很多东西补不了；
3. 功能做深不做多，把三个核心模块做扎实，比加一堆花哨功能有用得多；
4. 预留扩展接口，后期对接MES、ERP、云端平台的时候，不用重构系统。