设备在线之后，问题怎么闭环？
JM-IoT 是金牧科技自研的工业物联网平台，后端基于 Spring Boot，前端为 Angular 管理控制台。 平台把 采集、时序存储、实时看板、告警通知、工单闭环与分析 串在同一条链路上： 设备状态只有一份源头，看板说在线 62 台、报表就是 62 台；告警一键转工单，验收通过自动关回告警。
内置 MQTT、Modbus TCP、HTTP 三类采集驱动，物模型（TSL）定义属性、服务与事件，新增品类不用改代码。 覆盖离散制造的多车间机加工与注塑、公用工程的空压与冷冻水站房、装备制造商的远程运维等场景， 支持多租户与私有化部署。
九个模块，覆盖设备的一生
多协议接入与物模型
MQTT 上行、Modbus TCP 读寄存器、HTTP 定时拉取，统一走「影子 → 时序 → 实时 → 规则」一条链路。产品先定义属性、服务与事件，新增品类不用改代码。
实时看板与状态时间轴
在线率、运行/停机/故障分布、各车间在线情况同屏；单台设备可回看状态跃变，停机发生在几点、持续多久一目了然。
SCADA 工艺组态
拖拽画工艺图，图元绑定设备与指标，管线按流量动态显示流速。草稿与发布分离、支持版本回滚，折点可编辑，流量可用公式计算。
告警规则与四渠道通知
阈值、持续时长、恢复条件可配，支持规则试算再启用。触发后按渠道配置发站内信、邮件、企微与短信；通道未配置会明确标「未配置」，不假装发送成功。
工单闭环
待派单 → 待接单 → 处理中 → 待验收 → 已完成 → 已关闭。超时实时提示并自动收尾；验收通过会回写告警，避免「设备好了、告警还挂着」。
点检与保养
模板、计划、任务三层：按日历排期，或按运行时长、产量计量触发（如每 500 小时换油）。到期自动建单，漏掉的轮次只补一轮，不会堆积成灾。
OEE 与停机帕累托
时间开动率 × 性能开动率 × 合格品率，三要素逐项可见并对得上账。停机按原因排帕累托，改善先打头部那三项，投入产出比最高。
AI 质检与设备预测
外观缺陷自动框选、判定类型并给置信度，判定依据逐条可查；设备侧做异常检测、趋势预测与剩余寿命估计，数据不足时如实说不足，不编造预计时长。
平台化：租户、权限、集成
多租户数据隔离、组织架构与权限码（模块:对象:动作）精细到按钮。开放 API 带 API Key 鉴权与签名，Webhook 订阅设备、告警、工单事件，失败自动补投。
不是效果图，是运行中的界面
以下截图来自平台实际运行画面，数据由演示环境的设备模拟器产生，界面与真实使用完全一致。
实时看板：先看哪里出事
进入系统第一屏就是答案：在线率掉了几个点、哪台在故障、哪台停机超过一小时。设备卡片直接显示主轴负载、温度等关键参数，点卡片进详情。
- 状态与遥测同帧推送，不会出现「卡片在转、图表停了」
- 按车间、产品、状态筛选，定位到具体产线
- 离线设备不报数，不拿最后一次读数冒充当前值
SCADA 组态：把工艺图画活
空压站、冷冻水这类站房，看表格看不出问题。工艺图上管线按流向动起来，图元按运行/停机/故障着色，一眼就知道是哪一段卡住了。
- 拖拽编辑，草稿与发布分离，改坏了能回滚
- 管线可加折点、可整段平移，接入点自动吸附
- 点图元直接下钻到设备详情或运行状态时间轴
工单看板：谁在拖，看得见
维修最怕的不是修得慢，是没人知道它慢了。每张卡带剩余时限，超时变红并计入按时完成率，班前会不用再挨个问。
- 告警一键转单，已有工单不重复开
- 验收通过自动关闭对应告警，台账不会两边对不上
- 派单只认人员 ID，改名不影响历史归属
OEE 分析：把效率拆开看
73% 这个数字本身没有意义，有意义的是「损失在哪」。三要素分开、车间横向对比、停机按原因排序，改善从头部那几项下手。
- 目标线可配，默认 85%，低于目标一眼看出
- 停机原因帕累托：时长合计等于总停机，账对得上
- 支撑日 / 周 / 月切换，可导出报表
AI 视觉质检：判定要能追溯
缺陷被框出来只是第一步，更难的是「为什么判它是划痕」。每个结论都附判定依据与置信度，质检员可以核对、可以驳回，标准不会随人漂移。
- 划痕、污渍、裂纹、缺料分类判定，不受尺寸大小误导
- 检测记录留原图，可比对「系统判定 vs 人工复判」
- 缺陷率超阈值自动告警并转维修工单
一条链路，五段不换系统
很多项目卡在「采集一套、看板一套、工单又是另一套」。平台把五段串在同一条链路上，告警能查到原始数据，工单能追到哪条告警。
一份状态源头
设备影子只保留一份最新状态，看板、告警、报表都从它读。分系统拼接的典型后果是口径不一致，这里从根上避免。
告警可回溯
每条告警都能查回触发时刻的原始读数与曲线，不用再去翻另一套采集系统的历史库核对。
工单追到告警
工单保留来源告警编号，验收通过自动回写关闭告警，设备台账与维修台账不会两边对不上。
这些现场用得上
不追求「什么行业都能做」，只做设备密集、停机代价高、需要把维修过程管起来的场景。
多车间机加工与注塑
CNC、注塑机、装配线分布在不同车间，需要按车间看在线率、按设备看运行时长与停机原因。
空压、冷冻水、配电
站房设备分散、没人值守，压力温度异常要靠人巡检才能发现，适合做工艺组态与超限告警。
设备厂做远程运维
卖出去的设备需要远程看状态、接告警、派工单，多租户模式让每个客户各自独立、互不可见。
要把 OEE 从 70% 推到 85%
已经有产量与停机记录，但散在 Excel 里，无法按原因排序、无法验证改善是否有效。
外观件需要全检
划痕、污渍、裂纹、缺料靠人眼抽检，漏检与标准漂移同时存在，需要留图与可追溯的判定依据。
已有 MES / ERP 要数据
生产系统需要设备状态与产量数据，但不想为此重做一套采集，通过开放 API 与 Webhook 对接。
选型时要对的参数
下面这些是可以直接拿去和方案比对的硬指标，不是宣传语。标「可配」的项在部署时按现场调整。
| 采集协议 | MQTT（EMQX 接入）、Modbus TCP（单次读不超过 125 个寄存器，地址按 1 基编号）、HTTP 定时拉取；OPC UA 未内置驱动，需按项目评估 |
|---|---|
| 设备建模 | 物模型（TSL）定义属性、服务与事件；一个产品对应一张时序超级表，新增品类不改代码 |
| 实时性 | 看板默认 3 秒一帧（可配），WebSocket 推送；单设备、多设备与大屏共用一条实时通道，避免多路状态机打架 |
| 时序查询 | 单次返回不超过 600 个数据点，超出自动降采样（interval=auto）；支持历史回放 |
| 告警 | 阈值 + 持续时长 + 恢复条件；站内信、邮件、企业微信、短信四渠道；通道未配置明确标注，不计为发送失败 |
| 工单 | 六状态流转（待派单 / 待接单 / 处理中 / 待验收 / 已完成 / 已关闭）；超时判定实时计算，可配自动收尾；验收回写告警 |
| 点检保养 | 模板 / 计划 / 任务三层；按日历排期，或按运行时长、产量计量触发；到期自动建单 |
| OEE | 时间开动率 × 性能开动率 × 合格品率；目标基线默认 85%（可配）；停机原因帕累托与车间横向对比 |
| AI 能力 | 视觉质检（缺陷框选、类型判定、置信度与判定依据）、异常检测、趋势预测、剩余寿命趋势；数据不足时明确返回空结果 |
| 权限模型 | 权限码「模块:对象:动作」，精确到按钮级；菜单与路由按角色裁剪，越权访问返回 403 |
| 多租户 | 数据按租户隔离，租户可设设备配额；支持装备制造商为多个客户分别开户 |
| 集成方式 | 开放 API（API Key 鉴权、HMAC 签名）、Webhook 订阅设备 / 告警 / 工单事件，失败自动重试与补投 |
| 部署形态 | 私有化部署（厂区机房或企业自有云），服务端 Java 17 + PostgreSQL + Redis + EMQX + TDengine + MinIO，前端浏览器访问 |
如实说明平台边界，免得选型时误判：
- 不替代 PLC 逻辑控制——平台做采集、监视、告警与流程管理，控制逻辑仍由 PLC / DCS 承担，避免把安全回路交给上层系统。
- OPC UA 未内置——当前版本不做「看起来能用」的占位驱动，需要时按项目评估（多数场景用现场网关转 MQTT 更省事）。
- 预测类结论依赖历史数据——剩余寿命与趋势判断需要积累一定周期数据，刚上线时会给「数据不足」，不会编一个数字出来。
- 计量触发有前提——按运行时长或产量保养时，需要设备侧提供状态跃变或累计读数；数据缺失时显示「暂无数据」而不是按 0 处理。
三步落地，先小范围验证
不建议一上来全厂铺开。先选一条产线或一个站房跑通，验证数据准不准、人用不用，再横向复制。
1. 场景澄清
- 选哪条线、哪类设备先上
- 设备有没有网口或网关
- 现在最痛的是停机、质量还是效率
2. 方案与验证
- 采集方式与点位清单
- 告警规则与工单流程对齐现场
- 用演示环境先跑一遍再装现场
3. 部署与推广
- 私有化部署、账号与权限配置
- 班组培训与告警处置约定
- 按月复盘 OEE 与工单数据，逐步扩线
选型时常被问到的六个问题
和传统组态软件有什么区别？
传统组态以本地画图和监控为主，数据留在单机，告警与维修靠电话和纸单。平台把采集、时序存储、实时看板、告警通知、工单闭环与分析放进同一条链路：告警一键转单，验收后自动关回告警，停机原因沉淀为帕累托。组态只是其中一个模块。
接入需要改造现有设备吗？
多数不用。有网口的 PLC、仪表、空压机可用 Modbus TCP 直接读寄存器；已有上位机或网关的现场用 MQTT 上报；只能提供接口的系统用 HTTP 定时拉取。只有既无网口也无网关时才需要加装采集网关。
支持私有化部署吗？数据会不会出厂？
支持，整套服务可运行在厂区机房或企业自有云，数据保存在客户自己的数据库与对象存储里，不经过第三方。也支持多租户，适合装备制造商给多个客户分别开户、数据互相隔离。
支持 OPC UA 吗？
当前内置 MQTT、Modbus TCP、HTTP 三类驱动，OPC UA 未内置，需按项目评估。通常通过现场网关转成 MQTT 或 Modbus TCP 上报，成本更低也更稳定。我们没有把未实现的协议做成「看起来可用」的选项。
OEE 数据准不准？口径是什么？
按行业通用口径：时间开动率 × 性能开动率 × 合格品率，三要素逐项可见。明细只保留「日期 × 车间」一层，其余指标由明细推导、不做二次计算，因此看板与报表的数字能逐项对上。
视觉质检要额外买相机和算法盒子吗？
平台侧已完成缺陷检测、类型判定与置信度计算，相机按现场视野与节拍选型。边缘盒子可选：算法可跑在边缘端本地推理，只上报结论与缺陷图；也可先送平台侧推理，验证效果后再决定是否上边缘设备。