做工厂的朋友应该都有体会——每个月统计OEE（设备综合效率），靠班组长拿着纸质记录表一项一项算，可用率、性能率、良率三个指标凑出来一个数，费时费力不说，数据还经常对不上。我做了十几年上位机开发，这几年接触最多的一个需求就是"能不能把OEE自动算出来"。今天这篇文章，我就结合实际项目经验，聊聊怎么用上位机把OEE自动核算这件事落地。

一、为什么工厂的OEE数据总是算不准？问题到底出在哪个环节？

先说说痛点。大部分工厂的OEE统计流程是这样的：设备操作员在交接班时手动记录开机时间、停机时间、产出数量、不良数量，然后工艺工程师用Excel表格汇总，最后算出OEE。这个过程有几个绕不开的问题：

第一，时间记录不精确。操作员凭记忆填写停机时间，"大概停了20分钟"这种描述太常见了。实际上可能停了35分钟，也可能只停了12分钟，但人工记录根本做不到精确到秒。第二，停机原因分类混乱。同样是停机，换模、缺料、设备故障、品质异常，每种原因对应的改善方向完全不同，但人工记录经常笼统写个"设备异常"就完事了。第三，数据汇总滞后。等月底报表出来，问题已经发生一个月了，根本来不及干预。

这些问题归根到底，是因为数据采集环节依赖人工。而解决这个问题的核心手段，就是通过上位机开发实现数据的自动采集和计算。在做PLC通讯数据采集的时候，我们把设备状态信号直接从PLC里读出来，什么时候开机、什么时候停机、停机时PLC内部的状态字是什么，全部自动记录，不经过人手，自然也就不存在误差。

二、OEE三大指标（可用率、性能率、良率）到底怎么通过上位机自动采集和计算？

OEE的计算公式大家都知道：OEE = 可用率 × 性能率 × 良率。但具体到上位机里怎么实现，这里面有不少细节。

可用率的自动采集。可用率 = 实际运行时间 / 计划运行时间。计划运行时间一般由生产排程确定，可以在上位机里预设班次计划。实际运行时间的采集，关键在于从PLC里读取设备运行状态。我们通常的做法是：在PLC里找一个能反映设备主状态的信号位，比如"主电机运行"或者"设备自动模式"，上位机通过PLC通讯数据采集每秒轮询这个信号位。状态从0变1，记录为开机时刻；状态从1变0，记录为停机时刻。两个时刻之间的差值就是实际运行时间。同时，上位机会自动判断停机原因——我们在PLC程序里规划了一组停机原因编码，设备停机时，上位机读取当前激活的停机原因编码，自动归类。这个环节涉及到非标上位机开发，因为每个工厂的PLC程序结构不一样，停机原因的编码规则需要逐一适配。

性能率的自动采集。性能率 = （产出数量 × 理论节拍时间）/ 实际运行时间。理论节拍时间是设备的铭牌参数，在上位机里配置好就行。产出数量的采集有两种方式：一是直接从PLC的产量计数器寄存器里读取累计产量；二是通过传感器信号，上位机自己做计数。前者更常用，因为大多数PLC程序里已经有产量统计的功能块。实际运行时间从可用率环节已经拿到了，直接代入公式就行。

良率的自动采集。良率 = 良品数量 / 产出数量。良品数量的采集取决于检测环节的配置。如果产线上有视觉检测设备或者在线检测工位，这些设备通常也会把检测结果写入PLC的指定寄存器。上位机读取良品数和不良品数，良率就自动出来了。如果产线上没有自动检测，那就需要在上位机里做一个手动录入的界面，让质检员在检测完成后输入数据。不过我建议有条件的工厂还是尽量走自动采集的路线，手动录入的环节越少，数据可靠性越高。

在上位机界面上，这三个指标会用实时曲线的方式展示出来。操作员在车间的显示屏上就能看到当前班次的OEE趋势，哪个时间段效率掉了、是因为什么原因掉的，一目了然。这种实时曲线对现场管理的帮助非常大，比月底看报表强太多了。我之前在宁波上位机公司的一个注塑车间项目里就做过这个，上线之后车间主任说终于不用每天追着班组长要数据了。

三、上位机数据采集架构怎么设计才能稳定可靠？

做OEE自动核算，上位机的数据采集架构设计是关键。我分享一个在实际项目中验证过的架构方案。

整体架构分为三层：设备层、采集层、应用层。设备层就是车间里的PLC、传感器、检测设备等。采集层是部署在车间工控机上的上位机采集程序，负责跟所有设备通信、读取数据、做初步处理。应用层是部署在服务器上的数据服务，负责数据存储、计算、报表生成和对外接口。

采集层的设计有几个要点。首先，通信驱动要模块化。每个PLC品牌、每种协议对应一个独立的通信驱动模块。比如西门子S7协议一个模块、三菱MC协议一个模块、Modbus TCP一个模块。这样做的好处是，新增设备类型的时候只需要增加对应的驱动模块，不影响已有功能。其次，数据采集要带时间戳。每条数据在上位机里采集到的时候，立刻打上毫秒级时间戳，然后存入本地缓存。这样即使跟服务器的网络连接中断了，数据也不会丢。等网络恢复后，缓存里的数据自动补传。这个机制在嘉兴PLC数据采集的一个项目里帮了大忙，那个工厂的网络环境不太好，经常断网，如果没有本地缓存机制，数据丢失会很严重。

应用层的设计重点在于数据存储和计算。我们一般用时序数据库（比如TDengine或者InfluxDB）存储设备状态数据，用关系型数据库（比如MySQL或者PostgreSQL）存储OEE计算结果和报表数据。时序数据库在处理大量带时间戳的数据时性能优势很明显，查询某台设备过去一个月的状态变化记录，毫秒级就能返回。

另外，上位机程序本身要做看门狗机制。采集线程如果因为通信超时卡住了，看门狗会自动重启采集线程，保证数据采集不中断。在杭州PLC开发服务的一个项目里，客户那边设备有200多台，上位机程序要同时维护200多个通信连接，看门狗机制确保了程序的长期稳定运行。

四、停机原因自动记录怎么实现？分类规则如何设计？

停机原因的自动记录是OEE分析中最有价值的部分之一。光知道设备停了多久不够，还得知道为什么停，才能针对性地改善。

实现停机原因自动记录，需要PLC程序和上位机程序配合。在PLC程序里，我们设计一个停机原因编码表。当设备发生故障或者异常停机时，PLC程序会自动或者由操作员通过HMI选择对应的停机原因编码。常见的停机原因分类包括：

  • 设备故障类：机械故障、电气故障、液压系统故障、气动系统故障等
  • 品质异常类：来料不良、工艺参数偏移、模具异常等
  • 计划停机类：换模换线、设备保养、计划检修等
  • 外部因素类：缺料停机等水电气中断、人员缺岗等

上位机在检测到设备状态从运行变为停机时，立刻读取当前激活的停机原因编码，并记录停机的起止时间。如果一次停机过程中原因发生了变化（比如先是缺料等待，后来变成了设备故障），上位机会自动分段记录，确保每种停机原因的时长都被准确统计。

在南昌物联网系统开发的一个汽配工厂项目里，我们给12台CNC加工中心做了停机原因自动记录。上线三个月后，工厂发现排名前三的停机原因分别是"刀具寿命到期换刀"、"工件装夹偏差报警"和"冷却液温度过高"。这三个原因占了总停机时长的68%，工厂针对性地优化了刀具管理流程和冷却系统维护周期，OEE提升了将近7个百分点。

停机原因的统计结果，我们通常会在上位机界面上用帕累托图（柏拉图）展示，让管理人员一眼就能看出哪些停机原因占比最大，优先改善哪些。这种数据驱动的改善方式，比拍脑袋决定有效得多。在上海PLC上位机的多个项目里，这个功能都被客户评价为"最实用的功能"。

五、OEE报表自动生成和数据追溯功能怎么实现？

报表和数据追溯是OEE管控闭环的最后一步，也是管理层最关心的部分。

报表自动生成方面，上位机系统一般支持以下几种报表：班次报表（每个班次的OEE三大指标、停机原因分布、产量统计）、日报表（当天各设备的OEE排名、趋势对比）、周报表和月报表（OEE趋势分析、停机原因帕累托图、改善效果跟踪）。报表可以自动导出为Excel或者PDF格式，通过邮件发送给相关人员，也可以直接在上位机界面或者Web端查看。

数据追溯功能的核心是"任意时间点的数据都能查回来"。当某天的OEE突然下降，管理人员需要追溯具体原因：是哪台设备在什么时间段出了问题？停机原因是什么？当时的工艺参数有没有异常？这些问题，系统都应该能快速回答。我们的做法是：设备状态数据、OEE计算结果、工艺参数数据，全部按时间序列存储，支持按设备、按时间段、按停机原因等多维度交叉查询。在苏州上位机系统开发的一个电子厂项目里，客户的质量部门用数据追溯功能发现了一个隐蔽的问题——某台设备每天凌晨3点到4点的良率会周期性下降，后来排查发现是夜班温控系统的设定值被误改了。这种问题靠人工统计根本发现不了。

报表模板支持自定义配置，不同岗位的人关注的数据维度不一样。车间主任可能更关心单台设备的详细数据，生产经理可能更关心整条产线的OEE趋势，厂长可能只关心各车间的OEE排名。系统根据角色权限，展示不同维度的报表视图。

六、上位机如何与MES系统对接？数据打通有哪些注意事项？

OEE数据如果只停留在上位机层面，价值会打折扣。把OEE数据推送到MES系统里，跟生产工单、物料批次、质量数据关联起来，才能真正发挥数据驱动改善的作用。

上位机与MES系统对接，常见的接口方式有三种：RESTful API、数据库中间表和消息队列。RESTful API是最推荐的方式，实时性好、标准化程度高。上位机采集到OEE数据后，通过HTTP接口推送给MES。数据库中间表方式比较简单，上位机把数据写入约定的数据库表，MES定时去读取。消息队列（比如RabbitMQ或者Kafka）适合数据量大、对实时性要求高的场景。

对接过程中有几个容易踩的坑。第一，数据编码要统一。上位机里的设备编号、停机原因编码，必须跟MES系统里的编码保持一致，否则数据对不上。第二，时间基准要统一。上位机和MES服务器的系统时间必须同步，建议都对接NTP时间服务器。时间不同步会导致数据关联出错。第三，异常处理机制要完善。网络中断期间，上位机本地缓存的数据，在网络恢复后要能自动补传给MES，不能丢数据。

在无锡上位机开发的一个汽车零部件工厂项目里，我们把OEE数据推送到了客户的MES系统，MES再跟工单数据关联，实现了"每个工单对应一个OEE结果"的追溯。客户做IATF 16949审核的时候，审核员对这种数据追溯能力评价很高。这个案例也说明，OEE自动核算不仅仅是提升效率的工具，也是质量管理体系的重要支撑。

七、做了这么多OEE项目，有哪些经验教训值得分享？

最后说几点个人体会。做OEE自动核算上位机方案这些年，踩过的坑不少，总结几条经验供大家参考。

第一，不要追求一步到位。有些工厂一上来就想把全厂几百台设备全部接入OEE系统，结果项目周期拖得太长，迟迟看不到效果。我建议分阶段实施：先选一条产线或者几台关键设备做试点，跑通了再推广。这样既能快速验证方案，又能让现场人员逐步适应。

第二，PLC程序配合很重要。OEE数据采集不是上位机单方面的事，PLC程序里需要有规范的停机原因编码、产量计数、状态信号等。如果PLC程序本身不规范，上位机采集到的数据质量就会很差。所以项目启动前，一定要先梳理PLC程序，该改的改，该补的补。

第三，现场网络环境要提前摸底。很多工厂的车间网络覆盖不好，尤其是老旧厂房。上位机采集数据需要稳定的网络环境，如果网络条件不满足，需要提前规划网络改造方案，或者采用本地存储加异步上传的架构。

第四，数据展示要接地气。OEE的展示界面不要搞得太复杂，车间的人需要一眼就能看懂。大字体、颜色区分（绿色正常、黄色预警、红色异常）、实时曲线，这些直观的展示方式比花哨的3D图表实用得多。

OEE自动核算这件事，技术本身不算特别复杂，关键在于对现场工艺的理解和数据采集细节的把控。做上位机开发的，不能只懂写代码，还得懂设备、懂工艺、懂现场。这也是为什么我一直觉得，非标上位机开发的核心竞争力不在技术栈，而在于行业经验的积累。希望这篇文章对正在考虑做OEE自动核算的朋友有所帮助。