OEE 与安灯可视化
不只显示一个指标，而是把损失拆到可行动的原因与责任环
连接设备状态、生产计数和质量数据，按产线建立可解释的 OEE 与损失树，并将安灯事件接入响应、处置和复盘。系统可与现有 MES、SCADA 及维保流程协同；完整 TPM 或预测性维护平台不属于默认交付范围。
适用场景
适用场景
- • 设备数量较多，换型、微停、等待和降速等损失缺乏统一记录的产线。
- • 已有设备信号或 SCADA，希望进一步建立 OEE 分析和异常响应机制的车间。
- • 多产线需要统一生产日历、停机分类和指标口径，再开展横向复盘的工厂。
- • 希望把安灯从现场提醒升级为事件记录、升级通知和班组改善闭环的团队。
需要另行评估的场景
- • 仅希望得到一个漂亮的 OEE 数字，不愿统一生产日历、节拍和停机原因口径。
- • 设备没有任何状态或计数来源，也不允许增加采集点或人工事件确认。
- • 期望本产品直接提供完整 TPM、备件、维修工单和资产全生命周期管理。
- • 希望通过 OEE 数据自动诊断所有故障根因或直接预测设备剩余寿命。
精益生产方法关联
核心功能
设备状态自动采集
从 PLC、SCADA 或数据枢纽获取运行、待机、故障、生产计数和必要的人工事件，状态判定逻辑按设备工艺逐台确认。
可配置 OEE 口径
配置日历、班次、计划停机、理想节拍和合格品规则，保留计算依据与调整记录，避免不同工厂各算各的。
整线与单机损失分析
从整线 OEE 下钻到设备、班次、产品和原因，区分故障、换型、等待、微停、降速与质量损失，支持瓶颈关联观察。
安灯事件与响应计时
将设备自动报警和人工呼叫统一成事件，记录类型、位置、响应、恢复、升级与备注，并联动现场声光或显示终端。
微停与短时异常归集
按设定阈值识别短时停顿并聚合展示，结合设备状态和人工确认区分真实微停、正常工艺间歇及信号抖动。
班次复盘与改善跟踪
生成面向班组日会的损失清单、重点异常和原因分布，可关联措施、责任人与复核结论；完整工单维修流程可按项目扩展。
多层级可视化
为工位、产线、车间和管理层提供不同粒度的看板，支持实时状态、历史趋势与热力分布，避免所有角色只看同一张大屏。
数据与系统架构
现场信号与交互层
PLC、设备控制器、安灯按钮、声光终端和工位录入共同提供状态与异常事件，保留断线时的人工处置方式。
采集与事件处理层
数据枢纽完成协议适配、状态计算、去抖、时间对齐和事件分发；断网续传范围根据数据源缓存能力配置。
OEE 与安灯应用层
以设备模型、生产日历和损失分类为核心计算指标，管理异常响应链与复盘记录，并保留原始事件供核对。
展示与协同层
通过 Web 看板、现场大屏和约定的消息通道提供分级视图，与 MES、质量或维保系统交换必要数据。
- PLC 与设备控制器运行、计数及故障信号
- SCADA、OPC UA/DA 与实时数据库接口
- Modbus RTU/TCP 及已核验的设备通信协议
- 安灯按钮、声光报警器和现场显示终端
- MES 工单、产品、节拍与合格品数据接口
- 移动消息、邮件或企业协同平台通知接口
- REST API、数据库视图或报表导出接口
实施路径
- 1
统一指标与损失口径
与生产、设备和质量团队确认日历、节拍、合格品、计划停机及原因分类，先消除计算争议。
- 2
设备状态与约束核实
核验信号含义、工艺间歇、设备间阻塞与饥饿关系，明确整线和单机指标的解释边界。
- 3
示范线接入与安灯配置
接入设备状态、计数和异常源，配置响应角色、升级路径、看板与人工确认规则。
- 4
平行核对与班组试运行
用原始信号、现场观察和班次报表交叉核对，修正信号抖动、误分类和漏记，不直接以初期数据考核人员。
- 5
复盘机制与复制
将损失清单纳入日会和改善复盘，稳定后按模板复制；新线仍需重新标定节拍与状态逻辑。
交付成果
- ✓ OEE 指标口径、生产日历与损失分类说明
- ✓ 设备状态映射、采集点表与异常源清单
- ✓ 按范围配置的 OEE 分析和安灯应用
- ✓ 整线、单机、班次与原因分层看板
- ✓ 安灯响应、升级和班组复盘操作规则
- ✓ 接口联调、平行核对与约定验收记录
- ✓ 用户培训、运维说明及后续扩线建议
常见问题
OEE 是否可以直接套用统一公式？
基本结构可以统一，但生产日历、理想节拍、计划停机和质量数据来源必须按工艺定义。实施重点是让每项输入可解释、可复核，而不是追求一个看似统一却不可比的数字。
微停怎样避免被信号抖动污染？
需要结合采样周期、去抖阈值、最短持续时间和工艺间歇规则处理，并保留原始事件供抽查。阈值不是通用常数，应在示范线用现场观察校准。
安灯和普通报警推送有什么区别？
安灯关注异常从发生到响应、处置、恢复和复盘的完整责任链，普通推送只是其中一个通知环节。是否自动升级、谁可关闭事件及如何记录措施均可按现场规则配置。
是否包含完整 TPM 或预测性维护？
默认不包含完整 TPM 管理体系，也不承诺预测性维护。系统可为自主维护、计划维护和改善活动提供设备损失数据，并可按项目对接维保工单；寿命预测或 AI 诊断属于另行验证的方向。
上线后 OEE 会提升多少？
不能在缺少现场基线时承诺提升幅度。系统首先统一损失事实和响应过程，实际变化取决于瓶颈类型、改善措施、生产组织与执行质量，应以同口径前后数据评估。
相关文章
OEE损失树：从三个因子追到可行动的损失
OEE损失树的直接答案，是先用同一计划生产时间边界计算时间开动率、性能开动率和合格品率，再把三个因子的差额逐层拆到停机、微停、降速、启动与质量损失。OEE=时间开动率×性能开动率×合格品率；其中时间开动率=运行时间÷计划生产时间，性能开动率=理想周期×总产量÷运行时间，合格品率=合格数量÷总产量。公式必须在同一设备、同一时段和同一产量口径下使用。
安灯响应闭环：从异常呼叫到复盘改善
安灯响应闭环的直接答案，是让每一起异常都有明确的类型、责任、状态和升级路径，依次完成发现、呼叫、接单、到场、处置、恢复、关闭与复盘。灯号和看板只是信息入口，真正决定安灯是否有效的是响应责任是否清楚、计时口径是否一致、异常是否被转为可持续改善的证据。
OEE与TPM协同：指标、改善方法和软件如何分工
OEE与TPM协同的直接答案，是用OEE识别和量化设备损失，用TPM组织自主维护、计划维护、技能与改善活动，再用软件保留事件、工单和验证证据。OEE是指标，不是维护方法；TPM是管理体系，不是某个软件模块；数据采集和看板是支撑工具，不会自动产生维护效果。
