为制造工厂构建实时OEE追踪系统

引言

在中国制造2025战略和工业互联网政策的推动下，中国制造业正经历从"制造大国"向"制造强国"的历史性跨越。长三角、珠三角和京津冀等制造业集群中，越来越多的企业意识到：仅靠压低人力成本已无法维持竞争优势，提升设备效率与数字化管理能力才是可持续发展的核心。

然而，许多工厂仍依赖纸质点检表、班次结束后的手工统计，或孤立的Excel报表——管理者无法实时掌握车间正在发生什么。

OEE（Overall Equipment Effectiveness，设备综合效率） 是衡量制造生产效率的国际标准指标。实时OEE追踪系统能将问题发现从"报告后得知"变为"发生时即知"。本指南将带你从零开始构建这套系统——从传感器接入到实时看板，全程详解。

什么是OEE？为什么它如此重要？

OEE衡量工厂对设备的有效利用程度，由三个因素计算得出：

OEE ＝可用率（Availability）× 性能率（Performance）× 质量率（Quality）

要素	衡量内容	典型损失来源
可用率	实际运行时间 ÷ 计划生产时间	突发故障、换线换模
性能率	实际速度 ÷ 理想速度	节拍超时、短暂停机
质量率	良品数 ÷ 总产出数	不良品、返工、报废

世界级OEE水平为 85%及以上。中国大多数制造企业的OEE在40%～60%之间，说明仍有巨大的提升空间——实时追踪是缩小差距的第一步。

中国制造背景： 根据工信部相关研究，中国制造业平均OEE约为50%～55%，与德国、日本等制造强国相比差距显著。《工业互联网创新发展行动计划（2021-2023年）》明确将设备数据采集与OEE提升列为重点任务，这意味着构建OEE系统不仅是企业内部的效率工具，更是申请工业互联网标杆企业、获得相关政策支持的重要依据。

系统架构概览

实时OEE追踪系统由四个核心层次构成：

┌─────────────────────────────────────────┐
│             展示层                       │
│     （看板、预警、报表）                 │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│             分析层                       │
│   （OEE计算引擎、AI洞察）               │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│             数据层                       │
│  （时序数据库、消息中间件/MQTT）         │
└─────────────────┬───────────────────────┘
                  │
┌─────────────────▼───────────────────────┐
│             边缘／设备层                 │
│   （PLC、传感器、边缘网关、IoT设备）     │
└─────────────────────────────────────────┘

各层职责分明，分层设计使每个组件可以独立扩展或替换，不影响整体系统。

第一步：连接设备

方案A — PLC直连

大多数现代设备配有PLC（可编程逻辑控制器），通过工业协议对外暴露数据：

OPC-UA — 现代国际标准，兼容大多数PLC
Modbus TCP/RTU — 老旧设备广泛使用
MQTT — 轻量级，适合IoT联网设备

使用边缘网关（如Ignition Edge、Node-RED或定制化树莓派方案）轮询PLC并将数据推送至中央消息代理。

# 示例：通过OPC-UA读取设备状态（Python）
from opcua import Client

client = Client("opc.tcp://192.168.1.100:4840")
client.connect()

machine_status = client.get_node("ns=2;i=1001").get_value()  # 1=运行中, 0=停止
parts_count    = client.get_node("ns=2;i=1002").get_value()
reject_count   = client.get_node("ns=2;i=1003").get_value()

client.disconnect()

中国设备接入提示： 中国工厂常见设备品牌包括汇川技术、信捷电气、台达、西门子S7系列（国内应用极广）及三菱FX/Q系列。汇川和信捷均支持Modbus RTU，部分新型号已支持OPC-UA。若使用西门子S7系列，推荐使用开源的 python-snap7 库通过S7协议直接读取数据，无需额外授权费用。

方案B — 传感器改造

对于没有数字输出的老旧设备，可直接加装传感器：

钳形电流传感器 — 检测电机是否运行
振动传感器 — 识别设备异常行为
光电计数器 — 统计通过的零件数量
机器视觉系统 — 自动检测不良品

传感器数据接入边缘设备（如Arduino、树莓派或工业IoT网关），经标准化后上传至系统。

第二步：构建数据管道

消息中间件（MQTT）

采用 MQTT 作为设备数据的骨干传输协议。它轻量、可靠，专为工业IoT场景设计。

Topic结构：
factory/{工厂}/{产线}/{设备}/status
factory/{工厂}/{产线}/{设备}/parts
factory/{工厂}/{产线}/{设备}/rejects
factory/{工厂}/{产线}/{设备}/downtime_reason

Eclipse Mosquitto 或 EMQX（由国内团队开发的高性能MQTT Broker，在中国工业场景中应用广泛）负责处理边缘设备与后端之间的消息路由。

时序数据库

将所有设备事件存储在时序数据库中，支持对任意时间窗口的快速查询：

数据库	适用场景
InfluxDB	开源，开发体验好
TimescaleDB	兼容PostgreSQL，支持标准SQL
TDengine（涛思数据）	国产高性能时序数据库，专为工业IoT优化
Historian (OSIsoft PI)	企业级，大型工厂广泛使用

国产替代方案： TDengine 是由国内团队开发的开源时序数据库，针对工业物联网场景进行了深度优化，写入性能极高，且完全支持中文文档和国内社区支持。对于希望减少对境外云服务依赖的企业，TDengine是InfluxDB的优质替代选择。

第三步：构建OEE计算引擎

这是系统的核心。引擎消费原始设备事件，实时计算OEE。

数据模型

-- 设备事件表（存储于时序数据库）
CREATE TABLE machine_events (
    timestamp       TIMESTAMPTZ NOT NULL,
    machine_id      TEXT NOT NULL,
    event_type      TEXT,           -- 'running'（运行）, 'stopped'（停止）, 'fault'（故障）
    parts_produced  INTEGER,        -- 产出数量
    parts_rejected  INTEGER,        -- 不良数量
    downtime_reason TEXT            -- 停机原因
);

OEE计算逻辑

from datetime import datetime, timedelta

def calculate_oee(machine_id: str, start: datetime, end: datetime) -> dict:
    # 从数据库获取事件
    events = get_events(machine_id, start, end)

    planned_time     = (end - start).total_seconds() / 60  # 分钟
    unplanned_stops  = sum(e.duration for e in events if e.type == 'fault')
    planned_stops    = sum(e.duration for e in events if e.type == 'planned_stop')

    run_time         = planned_time - planned_stops - unplanned_stops
    total_parts      = sum(e.parts_produced for e in events)
    rejected_parts   = sum(e.parts_rejected for e in events)
    ideal_cycle_time = 0.5  # 分钟/件（依据设备规格）

    availability = run_time / (planned_time - planned_stops)
    performance  = (total_parts * ideal_cycle_time) / run_time
    quality      = (total_parts - rejected_parts) / total_parts

    oee = availability * performance * quality

    return {
        "oee":              round(oee * 100, 2),
        "availability":     round(availability * 100, 2),
        "performance":      round(performance * 100, 2),
        "quality":          round(quality * 100, 2),
    }

刷新频率设置

实时追踪采用滚动窗口重新计算OEE：

实时视图 → 每30～60秒重新计算
班次视图 → 每5分钟重新计算
日报/周报 → 期末批量计算

第四步：停机原因分类

原始停机数据还不够，你需要知道设备为何停机。

安灯（Andon）／操作员输入

设备停机时，通过工位平板或触摸屏提示操作员选择停机原因：

🔴 设备停机 — 产线3，设备7
请选择停机原因：

[ 1 ] 机械故障
[ 2 ] 等待物料
[ 3 ] 质量问题
[ 4 ] 计划保养
[ 5 ] 换线/换模
[ 6 ] 员工休息
[ 7 ] 短暂停机（微停）
[ 8 ] 其他

中国工厂实践建议： 由于工厂员工流动率较高，停机原因分类界面应尽量简洁直观，避免过多层级。建议限制在8个以内的一级分类，辅以图标提示。对于需要同时服务中外管理层的工厂，可采用中英双语界面。

该数据将成为帕累托分析（排列图）的基础——识别哪类停机最消耗OEE分值。

自动检测（进阶）

利用机器学习基于传感器信号自动分类停机原因，减少手动输入，降低人为误差。

第五步：构建实时看板

看板是将数据转化为决策的载体。一个优秀的OEE看板能即时回答三个问题：

现在发生了什么？
最大的损失在哪里？
今天比昨天好还是差？

看板核心组件

┌──────────────────────────────────────────────────────┐
│  工厂OEE: 73.2%   ▲ +4.1% 较昨日                    │
├──────────────┬───────────────┬───────────────────────┤
│   可用率      │    性能率     │       质量率          │
│    88.5%     │    86.3%      │       95.8%           │
├──────────────┴───────────────┴───────────────────────┤
│  产线状态                                             │
│  产线1 ● 运行中    OEE: 81%                          │
│  产线2 ● 运行中    OEE: 75%                          │
│  产线3 ● 停机中 ⚠  停机时长: 14分钟                 │
│  产线4 ● 运行中    OEE: 69%                          │
├──────────────────────────────────────────────────────┤
│  停机原因排列图（今日）                               │
│  ████████████ 机械故障         42分钟                │
│  ████████     等待物料         28分钟                │
│  ████         换线/换模        15分钟                │
└──────────────────────────────────────────────────────┘

看板推荐技术栈

组件	推荐工具
前端	Grafana、DataV（阿里云）、React + Echarts
后端API	FastAPI（Python）、Node.js/Express
实时更新	WebSockets、Server-Sent Events
告警通知	企业微信机器人、钉钉Webhook、飞书Bot

国内BI工具推荐： 阿里云 DataV 和腾讯云图雅专为大屏可视化设计，非常适合工厂车间大屏展示。开源方面，Apache ECharts（由百度开源）在国内有极强的生态支持，图表类型丰富，与React/Vue均可无缝集成。

第六步：告警与升级响应

实时系统的价值在于出现问题时能立即通知到正确的人。

需要配置的告警规则

OEE低于阈值（如低于65%）→ 通知产线班长
设备停机超过5分钟→ 通知维修团队
不良率超过2%→ 通知质量主管
性能率持续30分钟低于70%→ 通知生产经理

企业微信机器人告警示例

import requests

def send_wecom_alert(machine_id: str, message: str):
    payload = {
        "msgtype": "markdown",
        "markdown": {
            "content": (
                f"## 🔴 OEE告警 — {machine_id}\n"
                f"> {message}\n"
                f"> 时间：{datetime.now().strftime('%Y-%m-%d %H:%M:%S')}"
            )
        }
    }
    requests.post(WECOM_WEBHOOK_URL, json=payload)

# 使用示例
send_wecom_alert("产线3-设备7",
                 "设备已停机8分钟，尚未填写停机原因，请相关人员及时处理。")

国内主流通知渠道： 大多数中国制造企业使用企业微信、钉钉或飞书作为内部沟通工具，三者均提供Webhook机器人功能，可直接集成告警推送，无需额外付费。相较于短信或邮件，消息到达率和响应速度明显更高。

第七步：报表与持续改善

实时追踪产生数据，持续改善创造价值。利用系统驱动结构化的改善循环。

日报（自动生成）

按产线和设备分列的OEE
停机原因前5名
班次对比（白班 vs. 夜班）
实际产量 vs. 目标产量

周度帕累托分析

按每周停机总时长对分类排名，将改善重点集中在前2～3个原因上。遵循 80/20法则：通常20%的停机原因造成80%的生产时间损失。

与PDCA／精益改善的整合

将OEE数据直接纳入精益生产工作流：

计划（Plan）  → 从看板识别最大OEE损失来源
执行（Do）    → 在产线实施对策
检查（Check） → 监控未来两周OEE趋势
处理（Act）   → 效果确认后标准化，横向推广

与MES系统的集成： 许多中国工厂已部署或正在部署MES（制造执行系统）。自建OEE系统时，建议预留与主流MES平台（如SAP ME、Siemens Opcenter、金蝶云·制造、用友M+）的数据接口，避免形成新的数据孤岛，实现OEE数据与生产订单、物料追溯的打通。

常见误区与应对

1. 没有定义计划生产时间就追踪OEE
务必先定义计划生产排程。没有基准线的OEE毫无意义。

2. 将计划停机计入可用率损失
定期休息、保养时段和换线不应计入可用率损失，只有非计划停机才算。

3. 一开始就过度自动化停机分类
先从操作员手动输入开始。这能培养现场责任感，数据质量也比单纯自动检测更高。

4. 建了没人用的看板
让操作员和班组长参与设计过程。能回答他们疑问的看板才会被每天使用。

5. 追求100% OEE
世界级水平是85%。强行突破往往意味着带病运行或跳过必要保养。

技术栈汇总

层级	开源方案	商业/国产方案
边缘/接入	Node-RED、Ignition Edge	Kepware、紫光云工业网关
消息中间件	MQTT Mosquitto、EMQX	HiveMQ、阿里云IoT
时序数据库	InfluxDB、TDengine	OSIsoft PI、华为IoTDA
OEE计算引擎	自定义Python/Node.js	海克斯康、Rockwell FactoryTalk
看板	Grafana、ECharts、DataV	Power BI、帆软FineReport
告警通知	企业微信、钉钉、飞书	PagerDuty、OpsGenie