简介这份PPT资料面向智能制造规划人员、工厂信息化负责人及数字化转型从业者系统梳理智能工厂从顶层设计到落地实施的完整方法论。内容围绕总体设计方法、业务调研与分析、智能工厂总体规划、建设路线规划及系统初步设计展开重点覆盖业务架构、应用架构、系统架构、数据架构与技术架构五大维度并延伸至智能化场景梳理、流程制造业务框架、集成设计、标准框架与项目卡片等模块可帮助读者理解流程制造场景下九大业务域的规划逻辑与实施路径。资源包共1个pptx文件约1.2MB以图文架构图与规划模板为主便于直接参考或二次编辑。目前已有210人学习下载适合需要搭建智能工厂规划框架、梳理业务与系统关系、编制建设路线图的技术与管理人员借鉴使用。1. 智能工厂四层架构拆解从一张 PPT 到可落地的技术骨架很多制造企业的数字化项目死在“PPT 很漂亮落地全走样”上。一份名为《智能工厂技术架构、系统架构、数据架构、应用架构及场景应用方案》的 PPT往往把四层架构画成四个彩色方块但真正动手时才发现技术架构选错了通信协议系统架构没考虑产线级时延数据架构把时序数据和关系数据塞进同一个库应用架构的接口对不上 PLC 的地址表。这篇笔记不聊虚的直接按“技术架构 → 系统架构 → 数据架构 → 应用架构”这条线把每一层该填什么、参数怎么定、哪些坑必踩讲清楚。适合正在做智能工厂方案设计、系统集成或数据平台选型的工程师也适合需要评审乙方 PPT 的甲方技术负责人。2. 技术架构现场层到云端的五级链路怎么选技术架构回答的是“数据从哪来、走什么路、存哪里、怎么算”。智能工厂的技术架构通常分五级现场设备层、边缘控制层、车间汇聚层、工厂平台层、集团云层。每一级的选型逻辑完全不同不能拿一套技术栈从头套到尾。2.1 现场层通信协议选型OPC UA 还是 Modbus TCP现场层是血泪经验最集中的地方。老设备只有 RS-485 串口新设备支持 OPC UA中间还有一堆 Profinet 和 EtherCAT。常见做法是对已有 PLC 且支持以太网口的优先走 OPC UA因为它的信息模型可以带语义后续做数据架构时不用再手工映射字段名对只有串口的老设备用 Modbus TCP 网关转一道但要注意网关的轮询周期。# Modbus TCP 采集示例用 pymodbus 读取保持寄存器 from pymodbus.client import ModbusTcpClient import time client ModbusTcpClient(192.168.1.10, port502) client.connect() # 从站地址 1起始寄存器 0读取 10 个寄存器 # 参数说明slave1 对应产线上第一台老式注塑机 while True: rr client.read_holding_registers(address0, count10, slave1) if not rr.isError(): # 寄存器 0-1 是温度32位浮点2-3 是压力 temp client.convert_from_registers(rr.registers[0:2], client.DATATYPE.FLOAT32) pressure client.convert_from_registers(rr.registers[2:4], client.DATATYPE.FLOAT32) print(f温度: {temp:.1f}℃, 压力: {pressure:.2f}MPa) time.sleep(1) # 轮询周期 1 秒再快网关扛不住这段代码的关键参数是slave和address。slave必须和产线电气图纸上的从站号一致address是寄存器偏移量不是物理地址。轮询周期设 1 秒是经验值再快串口网关的缓冲区会溢出表现为数据跳变或丢包。如果产线有 20 台以上老设备建议把轮询周期放到 2 秒并在边缘层做一次数据缓存。注意Modbus 没有时间戳边缘层收到数据后必须立刻打上本地时间否则后续做 OEE 分析时无法对齐。2.2 边缘层与车间汇聚层的算力分配边缘层不是“小服务器”那么简单。它要同时跑协议转换、数据清洗、本地缓存和断网续传。我一般会按产线数量分配每条产线配一台边缘网关CPU 不低于 4 核内存 8GB 起步存储 128GB 用于本地缓存。车间汇聚层则用工业交换机做环网协议上走 OPC UA 或 MQTT。# 边缘网关上的 MQTT 桥接配置mosquitto 为例 # 将本地采集数据转发到车间汇聚层 connection bridge-to-workshop address 10.10.20.1:1883 topic # out 1 bridge_protocol_version mqttv311 try_private false notifications false cleansession truetopic # out 1表示把所有本地主题转发到汇聚层cleansession true保证断线重连后不保留旧会话。这里有个坑如果边缘网关和汇聚层之间走的是无线网络cleansession要设成false否则每次断线重连都会丢失 QoS 1 的消息。但设成false又要求汇聚层有足够的会话存储通常 4GB 内存的汇聚节点最多支撑 50 个边缘网关。2.3 工厂平台层与集团云层的边界工厂平台层跑 MES、SCADA、时序数据库和报警服务集团云层跑 ERP、BI 和跨工厂对标。边界划在哪我的原则是控制指令不下云实时数据不上云。工厂平台层保留最近 3 个月的全量时序数据集团云层只接收小时级聚合指标和事件告警。这样做的原因是广域网时延不可控一旦把 PLC 的急停信号绕到云端翻车是迟早的事。技术架构选型对照表层级典型协议时延要求数据保留常见坑现场层Modbus/OPC UA10ms不保留寄存器地址与图纸不符边缘层MQTT/OPC UA100ms7天断网续传缓存溢出车间汇聚OPC UA/MQTT500ms30天环网风暴工厂平台Kafka/HTTP2s3个月时序库写入瓶颈集团云HTTPS/Kafka1min3年聚合口径不一致3. 系统架构MES、SCADA、PLC 的三角关系怎么摆系统架构解决的是“谁指挥谁、谁汇报谁”。智能工厂的系统架构不是简单的分层图而是有明确控制流和数据流的拓扑。MES 下发工单SCADA 监控设备状态PLC 执行动作三者之间的接口定义决定了系统能不能跑起来。3.1 MES 与 SCADA 的工单同步接口设计MES 和 SCADA 之间最常见的接口方式是数据库中间表或 REST API。数据库中间表简单但耦合高REST API 解耦但需要处理重试。我一般推荐 REST API 消息队列兜底。-- MES 工单下发中间表如果走数据库方式 CREATE TABLE mes_work_order ( order_id VARCHAR(32) PRIMARY KEY, product_code VARCHAR(64) NOT NULL, target_qty INT NOT NULL, line_code VARCHAR(16) NOT NULL, status TINYINT DEFAULT 0, -- 0待下发 1已下发 2生产中 3已完成 create_time DATETIME DEFAULT CURRENT_TIMESTAMP, dispatch_time DATETIME NULL, INDEX idx_line_status (line_code, status) );status字段是核心。SCADA 只轮询status0的记录取走后立刻改成 1避免重复下发。dispatch_time用于计算工单响应时延。如果产线超过 50 条这张表每天新增记录在 5000 条左右需要按月分区。更稳妥的做法是 MES 通过 Kafka 发工单事件SCADA 消费后回写确认但这对 MES 团队的消息中间件运维能力有要求。3.2 PLC 与 SCADA 的地址映射与心跳机制PLC 和 SCADA 之间的地址映射是系统架构里最容易出错的地方。电气工程师给的地址表是DB100.DBD0SCADA 组态里要填DB100,REAL,0到了 OPC UA 服务器又变成ns3;sDB100.Temperature。三层映射错一个字符就读不到数。// OPC UA 节点读取示例node-opcua const { OPCUAClient, AttributeIds } require(node-opcua); const client OPCUAClient.create({ endpointMustExist: false, connectionStrategy: { maxRetry: 5, initialDelay: 1000 } }); await client.connect(opc.tcp://192.168.1.50:4840); const session await client.createSession(); // 节点 ID 必须和 PLC 工程师确认ns3 是厂商命名空间 const nodeId ns3;s\DB100\.\Temperature\; const dataValue await session.read({ nodeId: nodeId, attributeId: AttributeIds.Value }); console.log(温度: ${dataValue.value.value});ns3这个命名空间索引在不同 PLC 项目里可能不同必须用 UaExpert 连上去确认。心跳机制方面SCADA 每 500ms 读一次 PLC 的Heartbeat变量如果连续 3 次读不到就触发断线报警。这个变量通常放在DB1.DBX0.0由 PLC 程序每 100ms 翻转一次。3.3 系统架构的冗余与故障切换智能工厂的系统架构必须考虑冗余。SCADA 双机热备、PLC 冗余 CPU、网络环网这三样至少要做到两样。SCADA 双机热备的切换时间通常在 2-5 秒期间数据会丢失所以边缘层要缓存至少 10 秒的数据。PLC 冗余切换在 50ms 以内对产线基本无感。网络环网的收敛时间取决于协议RSTP 在 1-2 秒专用环网协议可以做到 20ms 以内。提示冗余切换测试一定要在停产检修时做生产过程中切一次轻则丢数据重则停线。4. 数据架构时序数据、关系数据、文件数据的混存策略数据架构是智能工厂里最容易被低估的一层。很多方案把 PLC 数据直接写进关系数据库结果三个月后查询慢到无法忍受。正确的做法是按数据特征分三类存储时序数据进时序库关系数据进关系库文件数据进对象存储。4.1 时序数据库选型InfluxDB 与 TDengine 的实测对比时序数据库选型主要看写入吞吐、压缩率和查询灵活性。InfluxDB 生态好Flux 查询语言功能强TDengine 在国产化场景下用得多写入性能好但 SQL 方言有学习成本。-- TDengine 建表每个设备一张子表 CREATE DATABASE factory KEEP 90; USE factory; CREATE STABLE device_metrics ( ts TIMESTAMP, temperature FLOAT, pressure FLOAT, vibration FLOAT ) TAGS ( line_code BINARY(16), device_code BINARY(32) ); -- 插入数据 INSERT INTO device_metrics_plc01 USING device_metrics TAGS (LINE-A, PLC-001) VALUES (NOW, 185.5, 12.3, 0.8);KEEP 90表示保留 90 天超期自动删除。STABLE是超级表每个设备通过TAGS区分子表。这种模型的好处是查询单设备数据时只扫描一张子表查询整条产线时用超级表聚合。实测下来单节点 TDengine 在 10 万点/秒的写入下磁盘占用约为原始数据的 1/8。InfluxDB 在同样负载下压缩率稍好但内存占用更高。4.2 关系数据与时序数据的关联查询MES 的工单数据在关系库设备时序数据在时序库两者需要关联分析。常见做法是在时序库里冗余工单号字段或者用数据虚拟化层做联邦查询。# 用 pandas 做跨库关联先查工单再查对应时段的时序数据 import pandas as pd from sqlalchemy import create_engine from influxdb_client import InfluxDBClient # 关系库查工单 pg_engine create_engine(postgresql://user:pass10.0.0.5:5432/mes) orders pd.read_sql( SELECT order_id, line_code, start_time, end_time FROM mes_work_order WHERE status3, pg_engine ) # 时序库查对应时段数据 influx InfluxDBClient(urlhttp://10.0.0.6:8086, tokenxxx, orgfactory) query f from(bucket: plc_data) | range(start: {orders.iloc[0][start_time]}, stop: {orders.iloc[0][end_time]}) | filter(fn: (r) r[line_code] {orders.iloc[0][line_code]}) result influx.query_api().query(query) # 后续做 OEE 计算或质量关联这段代码的关键是时间对齐。工单的start_time和end_time来自 MES精度到秒时序数据的时间戳精度到毫秒。关联时要统一时区否则会出现工单时间对不上数据的情况。我一般会在边缘层就把时间戳统一成 UTC展示时再转本地时区。4.3 数据质量治理缺失值、跳变、时钟漂移数据架构不只是存储还要治理。智能工厂数据最常见的三个问题缺失值网络闪断、跳变传感器故障、时钟漂移设备时钟不同步。问题类型检测方法处理策略缺失值连续 5 个周期无数据线性插值 标记质量码跳变相邻值变化超过量程 20%剔除 报警时钟漂移与 NTP 服务器偏差 1s边缘层统一打时间戳时钟漂移是最隐蔽的坑。PLC 的时钟一个月能漂几十秒如果不处理做批次追溯时会出现“后生产的产品时间戳反而更早”的玄学现象。解决办法是在边缘层统一打时间戳PLC 自己的时间戳只做参考。5. 应用架构从场景倒推功能模块的划分应用架构回答的是“给谁用、解决什么问题”。智能工厂的应用架构不能按技术分层来切要按场景来切。常见的场景有生产监控、质量追溯、设备维保、能耗管理、排产调度。每个场景对应一组功能模块模块之间通过 API 网关和消息总线通信。5.1 场景驱动的微服务拆分粒度微服务拆得太细运维成本高拆得太粗一个模块故障影响全厂。我的经验是按“场景 数据边界”来拆。生产监控服务只读时序库和报警表质量追溯服务只读工单和检测数据两者不共享数据库。# docker-compose 片段生产监控服务 version: 3.8 services: production-monitor: image: factory/production-monitor:1.2.0 ports: - 8081:8080 environment: - DB_HOST10.0.0.5 - TSDB_HOST10.0.0.6 - ALERT_TOPICfactory.alerts depends_on: - redis deploy: resources: limits: memory: 2Gmemory: 2G是硬限制防止某个服务内存泄漏拖垮整台服务器。ALERT_TOPIC是 Kafka 主题报警消息通过消息总线广播而不是服务之间直接调用。这样新增一个“短信通知服务”时只需要订阅同一个主题不用改生产监控的代码。5.2 应用间接口的版本管理与兼容智能工厂的应用生命周期很长MES 可能用十年不换但上层应用每年都在迭代。接口版本管理必须从第一天就做。# FastAPI 版本化接口示例 from fastapi import FastAPI, APIRouter app FastAPI() v1 APIRouter(prefix/api/v1) v2 APIRouter(prefix/api/v2) v1.get(/work-order/{order_id}) def get_work_order_v1(order_id: str): # 旧版返回字段少 return {order_id: order_id, status: running} v2.get(/work-order/{order_id}) def get_work_order_v2(order_id: str): # 新版增加产线、设备、工艺参数 return { order_id: order_id, status: running, line_code: LINE-A, device_code: PLC-001, process_params: {temp: 185.5, pressure: 12.3} } app.include_router(v1) app.include_router(v2)版本号放在 URL 里是最简单的做法但要注意v1不能永远保留一般维护两个大版本旧版本在一年后下线。下线前要统计调用方逐个通知迁移。我见过一个厂因为没做版本管理MES 升级后 SCADA 直接读不到工单停线两小时。5.3 低代码平台在场景应用中的边界现在很多智能工厂方案会带一个低代码平台让工艺工程师自己拖拽做报表。这东西有用但边界要清楚低代码适合做展示层和简单流程不适合做实时控制和复杂计算。我一般会把低代码平台限制在只读时序库和关系库的视图上不允许它直接写 PLC。注意低代码平台生成的 SQL 往往没有索引优化数据量超过 1000 万行后查询会拖垮数据库。必须限制查询时间范围和返回条数。6. 避坑与排查智能工厂架构落地中最容易翻车的五件事6.1 现象OPC UA 连接频繁断开重连后数据缺失原因OPC UA 服务器的会话超时设置太短或者网络中有防火墙定期清理长连接。边缘层没有做会话保持和断线缓存。解决把 OPC UA 服务器的maxSessionTimeout调到 3600000ms边缘层开启keepAlive间隔 10000ms。断线期间的数据由边缘层缓存重连后补传。补传时要带原始时间戳不能打补传时间。6.2 现象时序数据库写入越来越慢磁盘 IO 跑满原因没有按时间分区或者标签基数太高。比如把order_id作为标签写入每个工单一个标签标签数爆炸。解决order_id应该作为字段而不是标签。标签只保留低基数的维度如line_code、device_code。同时设置合理的KEEP和分片策略TDengine 默认按天分片InfluxDB 按周分片。6.3 现象MES 工单下发后 SCADA 没反应但数据库里有记录原因SCADA 轮询中间表时用了status0但 MES 写入时status默认值是NULL而不是 0。或者 SCADA 和 MES 连接的不是同一个数据库实例。解决建表时给status设DEFAULT 0和NOT NULL。上线前用SELECT COUNT(*) FROM mes_work_order WHERE status IS NULL检查。跨库场景要确认连接字符串。6.4 现象PLC 数据在 SCADA 上显示正常但时序库里数值翻倍原因边缘层做了两次采集一次走 OPC UA一次走 Modbus 网关两个数据源都往时序库写。或者浮点数的字节序搞反了。解决确认边缘层的数据源唯一。浮点数字节序问题用已知值验证比如 PLC 里设 100.0看时序库里是不是 100.0。如果是 1.4e-43 之类的数就是字节序反了。6.5 现象系统运行三个月后报表查询超时原因关系库里的历史数据没有归档单表超过 5000 万行。或者时序库的查询没有加时间范围限制。解决关系库按月分区超过一年的数据归档到历史库。时序库查询强制加WHERE time now() - 30d。低代码平台的查询模板里预置时间范围选择器默认最近 7 天。7. 用一套最小验证环境把四层架构跑通如果你正准备评审一份智能工厂 PPT或者要动手搭第一版架构我建议先花两天搭一个最小验证环境。不需要真实 PLC用软件模拟器就能跑通全链路。# 用 docker 启动最小环境MQTT TDengine Grafana docker run -d --name mqtt -p 1883:1883 eclipse-mosquitto docker run -d --name tdengine -p 6030:6030 -p 6041:6041 tdengine/tdengine docker run -d --name grafana -p 3000:3000 grafana/grafana然后写一个 Python 脚本模拟 PLC 数据通过 MQTT 发到 TDengine最后在 Grafana 里看曲线。这个环境跑通后再把模拟器换成真实 PLC 的 OPC UA 地址把 MQTT 换成边缘网关架构不用改。验证清单验证项通过标准工具数据采集10 个点位 1 秒周期无丢包MQTTX Wireshark数据存储写入 100 万条后查询 1sTDengine CLI断网续传断网 30 秒后数据不丢拔网线测试接口兼容v1 和 v2 同时可用Postman报警时延从 PLC 触发到 Grafana 显示 3s秒表这套环境搭下来你对四层架构的理解会比看十份 PPT 都深。我自己的习惯是每接一个新厂的项目先搭这个最小环境把数据跑通再谈上层应用。希望帮到你。本文还有配套的精品资源点击获取