简介：面向注塑机设备厂商与制造企业设备管理、运维及工业物联网方案学习者，这份文档围绕传统注塑机状态靠人工记录、故障报警滞后、工控与通信协议多样难以统一联网等痛点，梳理设备联网、数据采集与远程运维的解决思路。包内共1个docx文件，压缩包约169KB，内容以项目需求分析、工业物联网网关接入、运行参数采集、设备状态实时监控、故障远程诊断、云平台数据分析和历史数据查询等模块展开，并涉及模温机、下料机等周边设备的接入场景。已有228人学习，读者可据此了解注射压力、油温、模具温度、注射速度等数据如何上传后台，掌握从现场采集到集中监控、告警定位与趋势分析的方案框架，也可为设备利用率提升、预防性维护和后续数字化转型提供参考。

1. 一个班长的点检表和一台老注塑机的通讯口

很多注塑车间的交接班还在靠一本手写点检表：这台机今天停了几次、几点报的模温异常、这一班出了多少模，全凭操作工记，班长下班前对着本子核产量，对不上就翻班次记录。这套流程的问题不在人，而在于注塑机设备本身没把状态吐出来。注塑机设备物联网要解决的，就是把设备侧的运行状态、工艺参数、故障时刻变成可追溯的数据，再让这些数据支撑产量统计、故障诊断和维护决策。工业物联网在这里不是概念，而是一条从注塑机控制器寄存器到云端看板的完整链路。这套方案适合三类人：注塑厂里负责设备管理的人、给注塑厂做数字化改造的集成商，以及正在做相关毕设或课设、需要一套完整可交付结构的学生。它要对付的现实是——车间里既有带以太网口的新机，也有只有 RS485 串口、协议还是厂商私有的老机。

2. 现场摸底与协议适配：老注塑机能不能联网，先看这三张表

方案做得漂不漂亮是后面的事，第一步永远是把车间走一遍。注塑机设备物联网项目的成败，八成在进场第一周就定了：你到底能从那台机器上读到什么。不同年份、不同品牌的注塑机，控制器给的接口差别很大，有的留了 Modbus RTU 从站口，有的只给一个厂商调试口，有的以太网口只跑自己的上位机软件。所以摸底不是填个设备清单就完事，而是要把"通讯能力"当作设备属性登记下来。

2.1 设备台账与协议能力摸底：把"能读什么"写成表

我一般要求现场摸底至少产出三张表，缺一张后面就会返工。第一张是设备台账表，按车间、产线、机台号逐台登记品牌、型号、出厂年份、锁模力吨位、控制器型号、通讯物理口类型和数量。第二张是协议能力表，写清楚这台机用什么协议、从站地址是多少、波特率与数据位校验位、支持的功能码范围、是否有官方点位手册。第三张是点位映射表，这才是真正干活用的，把工艺量对应到具体寄存器地址。

这张表的每一列都不是凑数的。缩放系数错一位，看板上的油温就从 45 变成 450；数据类型选错，32 位计数器会高位低位颠倒；采集周期定得不合理，状态量采慢了抓不到顶针动作，工艺量采快了又白白占带宽。通常的做法是：状态量和循环动作相关的量走 500 ms 到 1 s，工艺参数走 1 到 5 s，能耗和累计量走 5 到 10 s。老设备没有官方点位手册时，用调试软件手动扫一遍寄存器区间，边改工艺参数边看哪个地址跟着变，这是笨办法但最可靠。

摸底阶段还有一个绕不开的判断：这台机到底能不能读。读不了的机器不要硬上，先记录在案，后期用外接传感器补齐——比如模具温度用贴片热电偶加采集模块，产量用开模信号加光电开关。这部分在方案里要单独列出来，答辩时被问到"老设备怎么办"，这就是答案。

2.2 网关形态与通信方式取舍：串口数、上网方式、边缘缓存

网关是这套方案的咽喉。选型不是看参数表上哪个数字大，而是看现场约束。串口数量要按摸底结果算：一个 RS485 口手拉手能挂多台从站，但实际项目里最好控制在 8 台以内，挂太多轮询周期会被拖长，某台掉线还会拖累整条总线。所以网关串口数一般按"每 6 到 8 台注塑机一个口"来估，再留一路接模温机、下料机这些周边设备。

上网方式按现场环境定。车间有稳定有线网络且交换机端口够，优先走以太网，最省心。布线困难、机台经常移位，走 WiFi，但要注意注塑车间金属结构多、干扰大，AP 覆盖要实测而不是按图纸算。跨车间、跨厂区、临时产线，走 4G 更现实。5G 适合对时延敏感或者要回传视频/高频波形的场景，但模温、压力这类 1 s 级的量用不上，成本反而上去了。

比通信方式更容易被忽略的是边缘缓存。车间网络抖动是常态，网关必须能本地存一段时间的数据，等网络恢复再补传。选型时问清楚三件事：本地能缓存多少条、缓存满了是覆盖旧的还是停止采集、补传的时候会不会重复入库。这三点没问清，后面数据对不上账就是玄学问题。

2.3 采集点位表：状态量、工艺量、能耗量分开定周期

点位表定稿前，要把三类量分开对待，因为它们的用途完全不同。状态量服务于实时看板和状态机，要求快、要求沿变化能抓到；工艺量服务于质量追溯和工艺优化，要求准、要求带时间戳；能耗和累计量服务于成本核算，要求不丢不重。

状态量建议按位打包读取，一次读 16 位覆盖多个动作信号，减少请求次数。工艺量按连续寄存器块读，能合并的合并。累计量最麻烦，因为它会溢出回零，32 位计数器在高速机台上几周就绕一圈，所以除了读值本身，还要记录"上一次值"和"本次值"做差值累加，遇到本次小于上次就判定为回零。

点位表还要标注"是否参与告警"。不是所有点位都值得报警，油温超限要报，注射压力瞬时抖动不要报，否则告警面板一周就没人看了。这一列在写方案文档时经常被省略，但它直接决定了后面告警模块的工作量。

3. 总体架构设计：端、边、云三层与五个模块的职责划分

注塑机设备物联网的架构不复杂，复杂的是每一层该管什么、不该管什么。我见过不少方案把所有逻辑都堆在云端，结果网络一抖，现场看板就白屏；也见过把状态判定全放在网关里，云端只存结果，后来想改判定规则要挨个网关升级。合理的划分是按"延迟敏感度"和"变更频率"来切。

3.1 三层拓扑与数据流向：谁在什么时候把什么数据送到哪里

现场设备层是注塑机本体和周边设备，包括模温机、下料机、机械手、冷水机。这一层只负责产生信号，不承担任何计算。边缘网关层负责协议转换、点位解析、状态机判定、本地缓存和补传，是整套系统的稳定器。云平台层负责存储、看板、告警分发、历史查询和报表。

数据流向分两条。第一条是上行：网关按周期轮询寄存器，解析成带点位编码的键值对，打上设备本地时间戳，通过 MQTT 发到平台，平台落时序库并更新实时状态缓存。第二条是下行：平台的远程诊断指令、参数下发、网关程序升级包，通过同一个连接反向推下去。下行通道经常被忽略，但它决定了"远程运维"是不是真能做，而不是只能看不能动。

这里有个设计取舍值得说清楚：状态机放边缘还是放云。我的做法是边缘算状态、云端算指标。合模、注射、储料、顶针、座台这些动作判定放在网关里，因为它依赖毫秒级的信号变化，走一趟云端再回来早就错过沿了；产量、稼动率、故障时长这些统计放云端，因为它依赖跨设备、跨班次的数据，而且口径经常要改。这样切的好处是，网络断了现场看板还能显示当前状态，云端恢复后只补数据不补逻辑。

3.2 数据模型：设备、点位、事件三张主表加一张时序表

数据模型是这套方案里最容易被做薄的部分。很多人上来就建一张大宽表，把所有点位塞成列，结果加一个点位就要改表结构，历史数据还没法对齐。正常做法是窄表加编码。

-- 设备主表：一台设备一行，存静态属性 CREATE TABLE dim_device ( device_id VARCHAR(32) PRIMARY KEY, -- 设备唯一编码，如 ZSJ-01-003 device_name VARCHAR(64) NOT NULL, -- 机台名称 workshop VARCHAR(32), -- 所属车间 line_code VARCHAR(32), -- 产线编码 controller VARCHAR(64), -- 控制器型号 protocol VARCHAR(16), -- modbus_rtu / modbus_tcp / opcua gateway_id VARCHAR(32), -- 挂载的网关编码 slave_addr SMALLINT, -- 从站地址 install_date DATE, status SMALLINT DEFAULT 1 -- 1 在用 0 停用 ); -- 点位定义表：点位编码与寄存器地址的映射，改点位不改表结构 CREATE TABLE dim_point ( point_code VARCHAR(32) PRIMARY KEY, -- 如 INJ_PRESS point_name VARCHAR(64) NOT NULL, device_type VARCHAR(32), -- 适用设备类型 register_addr INT, -- 寄存器地址 data_type VARCHAR(16), -- uint16 / int16 / uint32 / bool scale NUMERIC(10,4) DEFAULT 1, -- 缩放系数 unit VARCHAR(16), -- 单位 sample_ms INT DEFAULT 1000, -- 采集周期 alarm_enable BOOLEAN DEFAULT FALSE ); -- 事件表：故障、告警、停机、换模等离散事件 CREATE TABLE fact_event ( event_id BIGSERIAL PRIMARY KEY, device_id VARCHAR(32) NOT NULL, event_type VARCHAR(32) NOT NULL, -- fault / alarm / stop / mold_change event_code VARCHAR(32), -- 故障码 start_time TIMESTAMPTZ NOT NULL, -- 事件开始（设备时间） end_time TIMESTAMPTZ, -- 事件结束，NULL 表示未恢复 duration_s INT, -- 持续秒数，恢复时回填 severity SMALLINT, -- 1 提示 2 警告 3 严重 recover_note TEXT );

时序数据单独一张表，按设备加时间分区。窄表的好处是新增点位只往dim_point插一行，历史数据不用迁移。fact_event用开始时间加结束时间表达区间，而不是每条告警记一行日志，这样算停机时长只需要一次区间聚合，不用扫全表。

3.3 边缘侧断网续传与时间对齐：数据不能丢也不能重

断网续传的实现不复杂，但细节决定成败。网关本地维护一个环形队列，每条消息带一个自增序号seq和设备时间戳event_time。联网时按序发送，平台侧以(device_id, seq)做唯一约束，重复写入直接忽略。断网时消息进队列，队列快满时按策略处理——我的选择是丢最旧的原始工艺数据、保留事件和产量计数，因为工艺数据可以重采，事件丢了就没法追溯。

时间对齐是另一个坑。注塑机控制器基本没有可靠时钟，网关自己的时钟也会漂。做法是网关定时向平台 NTP 对时，采集时用网关本地时间打戳，平台入库时同时保存event_time（设备侧时间）和ingest_time（平台接收时间）。查询和统计一律用event_time，ingest_time只用来排查延迟。这两个字段分开存，后面查"某段时间为什么数据缺失"时能一眼看出是网络延迟还是设备没上报。

提示：补传的数据一定要带原始event_time，不要用补传时刻重打时间戳，否则历史曲线会出现一段数据全挤在恢复瞬间的假峰。

4. 核心功能实现：从实时状态看板到故障远程诊断

方案落到代码这一层，要解决的是四件事：怎么把寄存器读出来、怎么把读出来的数变成状态、怎么让告警只响一次、怎么让看板查历史不卡。这四件事对应的正是注塑机设备物联网最常被验收的四个功能点。

4.1 采集与上报：Modbus 轮询与 MQTT 消息体的写法

采集侧的核心是把寄存器块读回来并按点位表解析。下面这段是网关侧采集循环的骨架，用 Python 写只是因为它可读性好，实际量产网关里多是 C 或 Lua。

import time, json from pymodbus.client import ModbusTcpClient # 点位配置：从 dim_point 同步下来的最小子集 POINTS = [ {"code": "INJ_PRESS", "addr": 100, "type": "uint16", "scale": 0.1, "unit": "bar"}, {"code": "OIL_TEMP", "addr": 102, "type": "int16", "scale": 0.1, "unit": "C"}, {"code": "MOLD_TEMP", "addr": 104, "type": "int16", "scale": 0.1, "unit": "C"}, {"code": "INJ_SPEED", "addr": 106, "type": "uint16", "scale": 0.01, "unit": "mm/s"}, ] def read_block(client, slave_id): """一次性读连续寄存器块，减少请求次数；块长度按最大地址跨度 +2 计算""" start = min(p["addr"] for p in POINTS) end = max(p["addr"] for p in POINTS) + 1 rr = client.read_holding_registers(start, end - start, slave=slave_id) if rr.isError(): return None # 读取失败交由上层做重试与告警 return rr.registers def parse(raw, base): """按点位定义解析，注意有符号数与缩放系数""" out = {} for p in POINTS: v = raw[p["addr"] - base] if p["type"] == "int16" and v > 32767: # 补码转有符号 v -= 65536 out[p["code"]] = round(v * p["scale"], 3) return out def main_loop(host, slave_id, device_id, interval=1.0): client = ModbusTcpClient(host, timeout=2) seq = 0 while True: raw = read_block(client, slave_id) if raw is not None: payload = { "device_id": device_id, "seq": seq, # 断网续传的幂等键 "event_time": int(time.time() * 1000), # 网关本地时间，单位 ms "values": parse(raw, min(p["addr"] for p in POINTS)), } publish_mqtt("iiot/inj/telemetry", json.dumps(payload), qos=1) seq += 1 time.sleep(interval)

这段代码有三个关键决策。第一，合并读取：四个点位地址跨度只有 8 个寄存器，一次读回来比读四次省三倍请求，总线负载直接降下来。第二，有符号数处理：模具温度和油温可能是负值，int16超过 32767 要减 65536，这一步漏了冬天就会出现 6550 度的油温。第三，seq是幂等键，MQTT 用 QoS 1 意味着一模一样的消息可能被投递多次，平台侧靠它去重。

上报消息体保持扁平，values里只放点位编码和值，单位在平台侧从dim_point里查，这样改单位不用网关重启。采集周期由点位配置决定，实际实现里通常拆成两个循环：状态量 500 ms 一轮，工艺量 1 到 5 s 一轮。

4.2 设备状态机：合模、注射、储料、顶针、座台怎么判

注塑机的一个完整循环大致是：合模 → 注射 → 保压 → 储料 → 开模 → 顶针 → 取件，座台在储料前后有前进后退动作。状态机的作用是把这些动作识别成离散状态，才能算单模周期、算有效生产时间、判断停机原因。

判定不能只看一个信号，要看信号组合和持续时间。

def judge_state(prev, cur): """基于开关量与压力信号的简化状态机，cur 为当前采样点""" # 合模到位且压力上升 -> 注射 if cur["clamp_closed"] and cur["inj_press"] > 20 and prev != "injecting": return "injecting" # 注射结束但压力保持 -> 保压（避免注射段被切成多个状态） if prev == "injecting" and cur["inj_press"] > 10 and not cur["screw_rotate"]: return "holding" # 螺杆旋转且座台前进 -> 储料 if cur["screw_rotate"] and cur["seat_forward"]: return "charging" # 模具打开 -> 开模顶针段 if not cur["clamp_closed"]: return "mold_open" return prev or "idle"

状态机最容易翻车的地方是"抖动"。信号在阈值附近来回跳，状态就会一天切几百次，产量和周期全乱。工程上的解法是加最小驻留时间：一个状态至少要维持 300 ms 才认，切换时做一次确认采样。另一个坑是"保压"和"注射"的区分，很多机器的注射压力信号在保压段仍然很高，只靠压力阈值分不开，得叠加"螺杆是否转动""座台位置"这类辅助信号。

状态机放在网关里跑，输出两个东西：当前状态和状态切换时刻。切换时刻用于算周期，当前状态用于实时看板。看板上以动态形式显示合模、注射、储料、顶针、座台，操作工一眼就能看出这台机现在卡在哪一段，比看一堆数值直观得多。

4.3 故障判定与告警收敛：怎么让一条告警只响一次

故障远程诊断的前提是故障被正确识别。注塑机的故障来源有三类：控制器自己报的故障码、工艺量超限、状态异常停留。第一类最准，直接读故障码寄存器映射成故障类型；第二类靠阈值，比如油温超过设定上限持续 30 s；第三类靠状态机，比如"合模中"状态停留超过正常周期 3 倍还没进入注射，基本可以判定卡模或液压异常。

告警收敛要做三件事。去抖：连续 N 个采样周期都满足条件才触发，N 按采样周期算，一般取 3 到 5。分级：提示类只进事件流不推送，警告类进看板，严重类才发短信或推送到设备管理人员的移动端。抑制：同一台设备在 5 分钟内产生同类告警只保留第一条，后续合并计数。

恢复判定也要写清楚。告警的结束时间不是"人点了确认"的时间，而是"条件不再满足并持续 M 个周期"的时间。这两个时间混在一起，算出来的停机时长会虚高一大截。事件表里end_time和recover_note就是干这个用的，duration_s在恢复时回填，未恢复的事件end_time留空，看板上显示为"进行中"。

4.4 历史查询与产量统计：SQL 怎么写得让看板不卡

历史数据查询的需求很具体：查任意时段的设备参数、事件记录、告警记录，出班次产量和稼动率。看板卡不卡，取决于有没有在正确的粒度上预聚合。

-- 按小时预聚合的产量与运行时长，看板直接查这张表 CREATE TABLE agg_device_hourly ( device_id VARCHAR(32), stat_hour TIMESTAMPTZ, shot_count INT, -- 模数 run_seconds INT, -- 运行秒数 stop_seconds INT, -- 停机秒数 fault_count INT, -- 故障次数 avg_oil_temp NUMERIC(6,2), PRIMARY KEY (device_id, stat_hour) ); -- 班次产量：按事件表区间聚合，避免扫描原始时序 SELECT d.device_name, COUNT(*) FILTER (WHERE e.event_type = 'mold_change') AS mold_changes, SUM(h.shot_count) AS total_shots FROM agg_device_hourly h JOIN dim_device d ON d.device_id = h.device_id LEFT JOIN fact_event e ON e.device_id = h.device_id AND e.start_time >= h.stat_hour AND e.start_time < h.stat_hour + INTERVAL '1 hour' WHERE h.stat_hour >= '2024-06-01 08:00+08' AND h.stat_hour < '2024-06-01 20:00+08' GROUP BY d.device_name;

预聚合表按小时或按班次生成，原始时序数据只保留最近三个月，更早的降采样归档。这样看板查询永远打在小表上，响应稳定在几百毫秒。稼动率的算法要在方案里写死：运行时间除以计划时间，计划时间扣掉计划停机（换模、保养、无订单），而不是简单用 24 小时做分母，否则算出来的数永远偏低，没人信。

5. 避坑与排查：五类现场最容易翻车的点

这一章是我最想让人看到的部分。前面讲的都是顺利路径，实际项目里九成的时间花在处理这些破事上。下面五条按出现频率排序，每条都按现象、原因、解决三步写。

5.1 通讯类：时通时断、丢包、站号冲突

现象：网关日志里某台设备的读取成功率只有 70%，白天更差，晚上反而正常；或者一条 RS485 总线上，只要有一台机开机，其他几台就集体失联。

原因：第一种多半是电磁干扰加接线问题。注塑车间变频器、加热圈、伺服驱动器全在附近，RS485 双绞线如果没有屏蔽层接地、没有终端电阻、没做共地，信号完整性会很差，机器一加热干扰就上来了。第二种是站号重复，两台设备设了同一个从站地址，轮询时互相应答，数据随机错乱。

解决：RS485 总线严格手拉手，禁止星形分支，总线两端各加 120 欧终端电阻，屏蔽层单端接地。布线远离动力线，交叉时垂直走。上线前用调试工具逐台单独通讯，确认站号唯一、波特率一致、校验位一致。读取成功率低于 95% 就不要往下做业务，先把物理层修好。这个顺序不能反，血泪经验是先在烂总线上调业务逻辑，最后发现是接线问题，前面几天全白干。

5.2 数据类：数值翻倍、小数点错位、字节序反了

现象：看板上注射压力显示 3200 bar，实际只有 32 bar；或者一个 32 位累计计数器每次读数都在几十万和个位数之间跳。

原因：三个典型错误。缩放系数没乘，或者乘了两次——网关乘一次，平台又乘一次。字节序搞反，Modbus 是 big-endian，但有些控制器把 32 位量的高低字顺序调换，直接按标准解析就会得到荒谬值。数据类型判断错，把有符号当无符号，负温度变成 6550。

解决：点位表里把scale、data_type、byte_order三列做成必填。接入新设备时先在调试工具里读原始值，跟设备面板显示值对照，确认换算关系后再写进配置。32 位量一定要拿实际值验算高低字顺序，不能靠猜。平台侧加一道合理性校验，值超出物理量程的直接丢弃并记录异常，比让它进看板误导人强。

5.3 业务类：产量重复计数、告警风暴、时间戳对不上

现象一：班次产量比实际多出一截，且多出来的数量大致等于断网时长内的模数。原因是补传的数据没做幂等，同一条记录入库两次。解决办法是用(device_id, seq)唯一约束，补传时冲突忽略；同时产量统计不要数"开模次数"的原始记录，要数去重后的模次。

现象二：一台机跳闸，看板瞬间弹出四十条告警，值班人员直接不看告警面板了。原因是同一根因触发了压力、温度、状态等多个判据，而系统没有做根因合并。解决办法是告警分组加时间窗抑制，同一设备 5 分钟内的同类告警合并成一条并计数，同时给告警加父子关系，设备停机类告警作为父，工艺参数异常作为子。

现象三：历史曲线整体偏移 8 小时。原因是网关用本地时间打戳但没带时区，平台按 UTC 解析。解决办法是全链路统一用带时区的 ISO 8601 或统一毫秒时间戳，网关启动时强制 NTP 对时，对时失败要上报告警而不是静默继续。

注意：这三类问题都不会在单机联调时暴露，只在多设备、长时间、断网恢复之后才出现。验收测试必须包含断网 30 分钟后恢复的场景。

6. 验收与答辩：用一份联调记录表证明系统真的跑通了

方案写完只是纸面功夫，能不能交付看验收。我习惯在项目开始就把验收表定下来，让开发和现场都照着这张表干活，避免最后各说各话。

答辩或交付演示的时候，不用把所有功能点过一遍，演示三个动作就够了。第一个，拔掉网关网线，让看板上的数据停住，等三十秒插回去，指着历史曲线说明数据没有断档，这一下就证明了边缘缓存和补传是真的。第二个，用调试工具人为把油温设定值改到超限，让告警在看板上弹出来，再改回去，展示告警的开始时间、结束时间和持续时长，证明事件是有区间的而不是一串日志。第三个，随手查一个跨班次的时间段，出一张产量和停机原因分布，证明预聚合表真的在跑，不是临场算的。这三个动作对应采集、告警、分析三条主链路，做扎实了，剩下的问题都是参数调整。

答辩被问得最多的是"老设备怎么办"和"数据不准怎么办"。前者的答案在摸底表里，把读不了的设备列出来，给出外接传感器的替代路径和成本估算。后者的答案在点位表和校验规则里，说清楚缩放系数怎么定的、字节序怎么验的、异常值怎么拦的。能答到这一层，说明是真做过现场，而不是拼了一份文档。

从那以后我每次接手这类项目，进场第一周一定先把三张表填完再谈架构，宁可前期多花三天扫寄存器，也不在后面拿数据对不上账返工。希望这套结构能帮到你，无论是交一份设计，还是真去车间把一台老注塑机接上云。

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