企业官网建设流程全解析

简介：面向制造企业信息化规划、制造执行系统实施与系统集成技术人员的一份架构参考图。资源以分层视角呈现企业级制造执行系统集成架构，涵盖统一门户访问、数据处理层、系统数据采集层、业务系统数据层、运维审计系统与管理运维支持层，并细化到实时警告、拓扑管理、报表系统、配置管理、安全审计、用户权限、数据交换监控等功能。针对数据采集，介绍了离线填报、移动设备填报与面向已有系统的自动采集方式，强调各层协同支撑生产过程自动化与智能化，帮助读者理解制造执行系统与周边业务系统的集成关系、数据流向和管控要点，也为后续安全配置核查与日志追溯提供了线索。压缩包共一个文件，为PDF格式，整体大小841KB，便于直接查看与分发。目前已有967人学习。适合项目规划、方案汇报或系统设计初期通读参考，可据此梳理企业自身的制造执行系统集成框架。

1. MES系统集成架构图：一张图扛不住，先分清它是给谁看的

做 MES 项目这些年，我见过太多团队一上来就画框框，把 ERP、MES、PLC、WMS 摆成几排方块，中间拉几根箭头，标上"数据交互"四个字，这张图就算交差了。等到现场联调，才发现物料主数据对不上、设备点位表缺了一整页、接口超时把下游系统打死——这时候回头再看那张架构图，除了一句"这里走接口"，什么都说明不了。

这张"企业MES级系统集成架构图"里的门道，和执行层的功能设计不一样。它本质上是一份系统集成的契约文档：画给评审专家看边界是否清晰，画给开发看接口怎么落地，画给运维看数据往哪里流。如果只是把它当成一张"关系图"，项目大概率会在集成阶段翻车。这篇文章按我自己的落地习惯，把这张图从分层逻辑、画法规范、参数设计到避坑清单拆开讲，新手能照着复现，熟手可以拿来做方案评审的核对底稿。

2. 架构图里的分层逻辑：从设备层到企业层的四层映射与选型取舍

2.1 从设备到企业：一张集成架构图的分段依据

企业 MES 级集成架构图，业界常用的参照是 ISA-95 的分层模型，从下往上分成 L0 设备层、L1 控制层、L2 执行层（MES）、L3 管理层（ERP）、L4 决策层。但真正画图时不必生搬硬套全部五层，多数离散制造和流程制造业的项目，按"设备/控制层 → MES 执行层 → ERP 管理层 → BI/决策层"四段来画，已经足够覆盖集成边界。

我一般会把架构图从上往下画：最顶层是决策与分析系统，比如 BI 报表、大数据看板；第二层是 ERP 和上游业务系统；第三层是 MES 核心，包括排产、工单、质量、物料、设备、人员等模块；最底层是 PLC、DCS、SCADA、条码枪、电子秤、检测仪器等现场设备。层与层之间的连接线，必须标注接口协议和流量方向，不能只画一条"数据总线"了事。

这张图的分段价值在于，它强制团队回答三个问题：谁产生数据，谁消费数据，谁负责维护数据的准确性。以 ERP 与 MES 的边界为例，物料主数据在 ERP 里维护，MES 只读引用；工单在 ERP 里下达，MES 负责执行和报工回传；库存静态数据在 ERP，动态库存和工序在制品在 MES。边界一旦画清楚，开发时就少了"这条数据到底谁改"的争执。

2.2 横向打通的非生产系统：WMS、QMS、数采与报工的集成边界

纵向分层之外，架构图还必须横向画清楚车间周边的辅助系统。最常见的四类横向系统是：WMS 仓储管理、QMS 质量系统、SCADA 数采系统、以及电子看板/OEE 分析系统。一条很实用的经验是，每个横向系统在图上只保留三个要素——数据源、交互接口、回写目标。

WMS 与 MES 的交互集中在物料批次、出入库台账、线边库库存三个点。MES 给 WMS 下发领料申请，WMS 回传批次号和数量，两边的"物料编码 + 批次号"必须作为唯一键对齐，这是仓库集成里最容易出主数据口径问题的地方。QMS 则更复杂，它既有从 MES 接收检验任务的下行接口，又有回传合格判定结果的上行接口，还可能在离散行业里反过来驱动 MES 冻结不合格批次——架构图里要把这两个方向分开画，并在备注里写明异常分支谁先触发。

SCADA 数采系统的集成边界，按数据流向分两类：一类是 MES 主动采，按节拍读 PLC 点位，适合需要控制节拍的产线；另一类是 SCADA 侧定时推送，聚合之后批量写 MES 接口，适合数据量大、实时性要求稍低的场景。在图上标注"主动读/被动收"这种方向性关键词，比画一堆箭头更有用。

2.3 单体、微服务与若依系快速落地：架构图里的技术选型压力测试

架构图画到系统边界之后，下一步要回答的是落地形态。近几年热门的"基于若依框架的 MES""芋道系统架构图"，本质上都是低成本的模块化单体或微服务改造方案。若依这类基于 Spring Boot 的后台管理框架，自带用户权限、代码生成、定时任务、若依工作流，很多 MES 团队的选型是拿它做底座，在上层挂排产、报工、质量模块。

选型的核心矛盾在于：MES 的实时性要求不高，但事务一致性要求极高。一个报工事务要同时更新工单进度、工序在制品、设备运行时长、人员绩效、物料消耗余额，一旦拆成微服务走分布式事务，要么引入 Seata 这类组件，要么把强一致的逻辑留在单体里、微服务只拆非核心旁路。架构图里如果画了十几个微服务小方块，一定要同步画出事务边界，否则评审专家第一个问题就是"报工这个事务跨了几个服务，一致性怎么保证"。

提示：MES 领域里，微服务架构图好看但难落地。建议按"核心链路单体优先、统计与报表独立拆出"的原则做压力测试。若依这类框架适合中小型车间的快速交付，但架构图里要额外标注多租户和并发上限的评估值。

3. 从一份 Word 文档到能落地的集成架构图：七类图元、分区规范与绘制顺序

3.1 架构图里必须有哪七类图元

很多架构图画得花哨却不实用，缺的是图元规范。我按交付和评审的要求，把一张可以拿去开工的 MES 集成架构图拆成七类必画元素：系统/服务节点、接口连接线、数据实体、消息队列/中间件、外部系统边界框、接口协议标注、主数据流向箭头。

节点框里必须写清楚系统全称和版本，比如"MES 生产执行系统（Spring Boot 3.x）"，不能只写"MES"；接口连接线上要标协议（HTTP/REST、OPC UA、WebSocket、MQTT、SFTP）；数据实体用圆角矩形或圆柱形，标注关键表名，比如 wip_work_order、material_batch、quality_inspection_result；外部系统边界框一般用虚线画在最外层或侧边，把往来单位系统隔离在 MES 核心域之外。

主数据流向箭头是这张图和普通拓扑图最大的区别。物料主数据从 ERP 流向 MES，报工数据从 MES 流向 ERP，品检结果从 QMS 回传 MES，这三条主线必须用实心粗箭头，辅助查询、配置文件同步用细箭头。箭头粗细本身就是契约：粗箭头表示强依赖，断了产线就停；细箭头表示弱关联，偶尔失败可以重试补传。

3.2 在 Word 里画层级架构图的操作顺序与分区规范

标题里的"docx.pdf"揭示了大多数甲方团队的真实工作方式——用 Word 画图，再转 PDF 走签审流程。Word 里画图不是不行，但讲究操作顺序，否则改一次就散架。我的习惯是先建画布分区，再连线，最后填文字。

第一步，把页面设为横向 A3 或 A4 横版，用表格或矩形框圈出四个横向大区，从上到下依次是"决策分析区""ERP/管理层""MES 执行层""设备/控制层"。每个大区用浅灰色底纹填充，这样系统框移动到分区内时一眼就能看出层归属。第二步，先在每个分区内摆系统节点，节点之间用"肘形箭头连接符"连接，不要用直线箭头——MES 架构图里两条线交叉是常态，肘形线能自动绕行，减少重叠。第三步，全部节点定位完成后再统一加文字标注。

分区规范上有一条血泪经验：同一个分区内的节点间距保持基本一致，MES 执行层的核心模块放在中轴线附近，外部系统全部靠边排布。转 PDF 之前，把 Word 的网格线打开，检查是否有框线超出页边距。低版本 Word 里插入的文本框在转 PDF 时会偶发偏移，转完最好逐页看一眼。

3.3 架构图软件的取舍：从 Visio 到在线协同

Word 画图的优点是签审顺手，缺点是好用的连接线管理能力弱。如果项目规模上了两三条产线以上，我更推荐用专业架构图软件先画，再导出图片嵌进文档。Visio 依然是主流选择，它的分层布局和动态连接线在"调整一个模块、整层自动重排"上比 Word 强太多。对于团队协作场景，在线工具如 ProcessOn，以及免费开源的 Draw.io 也够用，Draw.io 支持离线部署，适合对数据有隔离要求的制造企业。

这里给一个实用的存档规范：架构图的主文件用 .drawio 或 .vsdx 格式保留，每次评审改版后导出 PDF 或 PNG 归档。文件名用"项目名_架构图_V版本号_日期"的格式，别用"最终版""最新版"这种命名——MES 项目三五年生命周期里架构图至少改七八版，版本不清晰，后面运维的人根本不知道哪张图和现场一致。

4. 集成落地中的五个常见翻车点：现象、根因、处置思路

4.1 翻车点一：主数据口径不一致，两套物料编码对不上

现象：ERP 下发物料主数据到 MES，MES 按物料编码关联工单，结果报工时报"物料不存在"，白班停了两个小时。原因：两边虽然都叫"物料编码"，但 ERP 的编码规则是"物料大类 + 流水号"，MES 建立时没做映射，测试环境造的数据看着对，生产环境真实编码一同步就冲突。解决：集成架构图里必须单独画出一个"主数据映射表"的数据实体，字段设计成 erp_item_code、mes_item_code、item_name、unit、status、last_sync_time 六个字段。ERP 下发走全量快照 + 增量变更两张表，MES 侧接收后先落入映射表，再供工单模块引用。

4.2 翻车点二：接口超时导致雪崩，下游系统全被拖死

现象：MES 重启后积压了一批报工事务，自动重试把 ERP 的接口打满，ERP 响应变慢，反过来 MES 等待超时的时间更长，最终两边的连接池全部耗尽。原因：架构图里只画了"接口调用"，没有画超时阈值、重试策略和熔断降级方案。解决：在接口清单里为每个接口补三个参数——超时时间、重试次数、降级动作。报工类强一致接口超时设为 3 秒，最多重试 2 次，超过后落本地失败表人工处理；查询类接口超时设为 5 秒，不重试，降级为读取前一天快照。这张参数表要作为集成架构图的附件一并评审。

4.3 翻车点三：PLC 点位表滞后，数采数据错位

现象：SCADA 采上来的温度值显示正常，但对应到设备 OEE 统计时，每一炉都记到了前一炉的产品上。排查发现设备侧新增了几个点位，点位表 Excel 更新了，但架构图里标注的数据字典没有同步，MES 侧按旧点位解析。原因：数采链路的点位映射没有版本管理。解决：点位表要纳入架构图的数据字典附件，每个点位带 PLC 地址、数据类型、采样频率、所属设备编号、启用日期。设备改造后，点位表升版本，MES 侧同步校验点位总数和 CRC。这一条看是小事，每次都能让项目在试产阶段多加班两周。

4.4 翻车点四：中间库共享表被多系统同时读写，锁等待爆炸

现象：多个系统共用一套 Oracle 中间库的几张表，大促或月末盘点时，MES 的写入事务把表锁住，WMS 的查询全部排队，耗时从 50 毫秒涨到 30 秒。原因：集成架构图里把中间库画成了一个"黑匣子"，没有标识表和接口的归属。解决：中间库存活的前提是每张表只有一个生产者、可以有多个消费者。架构图里要标出每个数据实体的 owner 系统，比如"mq_package_info"表只有 WMS 写，MES 和 ERP 只读。如果一张表确实需要两个系统写，就该拆成两张表或引入消息队列。

4.5 翻车点五：OEE/KPI 口径不一致，管理层报表互相打架

现象：MES 的 OEE 是 82%，BI 大屏显示 76%，车间主任拿着两份报表来找 IT。原因：两边的 OEE 公式不一样，MES 用"良品数/理论产能"，BI 用"实际产出/计划产出"，分母分子各差一项，比率自然不同。解决：架构图里增加一个"指标口径注册表"数据实体，对每个关键 KPI 记录公式、数据来源表、计算频率、负责系统。OEE 的计算基准以 MES 为准，BI 通过接口读 MES 的日结结果，不再自行重算。

5. 把架构图落成接口台账与数据模型：协议选型、字段口径与代码示例

5.1 接口台账长什么样：从架构图到开发可执行的清单

架构图定方向，接口台账定细节。我的习惯是图里见系统、台账里见字段，台账是架构图的直接展开产物。每个集成接口在台账里至少记录 14 个字段：接口编号、接口名称、源系统、目标系统、协议类型、调用方向、消息格式、超时时间、重试次数、触发方式、责任人、依赖表名、状态、备注。这张台账放在代码仓里，做接口评审的第一份检查单。

以下是一个 JSON 格式的接口台账示例，用于工单下发接口的定义：

{ "interface_id": "IF-MES-001", "interface_name": "ERP工单下发至MES", "source_system": "ERP", "target_system": "MES", "protocol": "HTTP/REST", "direction": "ERP -> MES", "message_format": "JSON", "timeout_ms": 3000, "retry_count": 2, "trigger_mode": "ERP定时任务+手动触发", "owner": "生产计划科", "dependency_table": "erp_work_order", "status": "已上线", "remark": "工单状态变更时增量推送，同步更新MES侧工单状态机" }

这个示例里的关键参数是timeout_ms和retry_count。ERP 侧批量下发 1000 张工单时，MES 接收端如果处理耗时超过 3 秒，ERP 侧会认为超时并自动重试——这就可能造成重复接收，所以接口幂等性必须靠interface_id+ 工单号做唯一索引来兜底。trigger_mode字段看着简单，但"定时任务+手动触发"的组合在生产环境特别实用——定时任务挂掉时，计划员还能手动补发，不需要等开发来捞数据。

5.2 数据模型与状态流转：工单物料消耗的字段口径

架构图上的数据实体，最后要落到数据库表和状态机。以离散制造最典型的"工单物料消耗"为例，MES 与 ERP 之间的物料消耗回传，口径必须精确到每一个操作。常见的设计是两张表：wip_material_consume记录消耗明细，wip_consume_summary记录按工单聚合的结果。以下是一个简化版建表脚本：

CREATE TABLE wip_material_consume ( id BIGINT AUTO_INCREMENT PRIMARY KEY, work_order_no VARCHAR(32) NOT NULL COMMENT '工单号，关联ERP下发工单', operation_seq INT NOT NULL COMMENT '工序序号', material_code VARCHAR(32) NOT NULL COMMENT '物料编码，采用ERP编码', batch_no VARCHAR(64) COMMENT '批次号', consume_qty DECIMAL(12,3) NOT NULL COMMENT '消耗数量', consume_unit VARCHAR(8) NOT NULL COMMENT '消耗单位', consume_time DATETIME NOT NULL COMMENT '实际消耗时间', source_system VARCHAR(16) NOT NULL COMMENT '数据来源：MES手动报工/SCADA采集', status TINYINT NOT NULL DEFAULT 0 COMMENT '0待同步 1已同步ERP 2同步失败', sync_time DATETIME COMMENT '回传ERP时间', create_by VARCHAR(32) NOT NULL, create_time DATETIME NOT NULL, UNIQUE KEY uk_work_order_op_material (work_order_no, operation_seq, material_code, batch_no, consume_time) ) COMMENT='工单物料消耗明细表';

这段 SQL 里有三个关键落点。source_system字段是用来区分消耗数据的生产方式的：手动报工的消耗可能有估算成分，SCADA 采集的是实测值，两边的consume_qty在月结时可以对账。status字段实现回传 ERP 的状态机，0 待同步、1 已同步、2 同步失败，同步失败的记录要提供定时重扫任务，而不是靠人工改库。唯一索引uk_work_order_op_material是防止 ERP 重试导致的重复消耗，同一工单同一工序同一物料同一批次同一时间只允许一条消耗记录。

5.3 集成方案的评审检查点：接口归属与超时策略

架构图和接口台账齐了之后，评审环节要有人专盯三个检查点。第一，每个接口必须有唯一的 owner 系统，推数据的系统负责正确性、收数据的系统负责幂等性，台账里source_system和target_system不能出现两个系统"共同负责"的模糊地带。第二，接口超时与重试参数必须写进开发任务单，不能只停留在台账文档里——见过太多团队接口写完了，超时策略还是 HTTP 客户端默认值。

第三，凡是涉及跨系统写操作的接口，必须在架构图上标注"事务隔离级别"或"最终一致性"字样。比如报工事务内更新 6 张表，这属于本地事务，MES 自己保证；回传 ERP 的接口，属于跨系统最终一致，不能放在同一事务里。评审时要追问一句："如果 ERP 收口失败，MES 这边是回滚还是标记失败待重试？"正确答法是报工成功、回传状态置为失败、定时任务补偿。

6. 验证一张架构图是否靠谱的四个小技巧

架构图画完不是结束，验证它是否经得起现场考验，我有四个习惯。第一个是"查环"：顺着接口方向走一圈，看有没有形成循环依赖——比如 MES 调 QMS，QMS 调 ERP，ERP 又调 MES，这种环一旦出现，任何一个节点变慢都会拖动整条链路，架构图上该用红色标注并商议断开。第二个是"查线"：每一条连接线都必须能对应到接口台账里的一条记录，画了线却没有接口定义的，一律视为无效连接；相反，台账里有但图上没画的，说明图漏了东西。

第三个是"查点"：找出整个架构里的单点，最常见的是中间库、消息队列、主数据同步服务这三类。架构图上它们是否标识了高可用方式，比如中间库是双机热备还是集群，消息队列是否支持持久化。MES 这类 7×24 系统，单点不可怕，可怕的是架构图里没标、出事了才想起来。第四个是"查史"：找过去半年因为集成故障产生的工单，对照架构图里的接口和参数，看哪些故障在图上完全找不到——找不到的部分就是架构图与实际系统脱节的地方。

我自己做项目时有一条规定：架构图的每个版本都必须跟着一次真实故障复盘走一遍，复盘出的新接口、新参数、新表，必须在下个版本里长出来。这套流程执行一年后，架构图的"预测能力"会明显变强，新产线接入时，光看图就能判断出哪些环节要提前扩容、哪些接口要做降级。做集成这个方向，图纸的准确度比图纸的美观度贵得多，希望这些习惯能帮到你少走几趟现场。

本文还有配套的精品资源，点击获取