CN117784739A - 数据处理系统及方法 - Google Patents

Abstract

本申请实施例提供一种数据处理系统及方法，其中，数据处理系统包括多个工控机和集控系统，工控机用于获取工控机对应的生产设备的设备运行状态，在设备运行状态与生产设备上一次的设备运行状态不同的情况下，获取生产设备的设备运行数据，在设备运行数据表征生产设备由第一状态变为第二状态的情况下，获取生产设备的设备变化原因，基于设备变化原因和设备运行数据，生成设备关联数据，并将设备关联数据上传至集控系统；集控系统，用于对多个工控机的设备关联数据进行分析对比，得到电池生产线上的多个工控机对应的生产设备的运行状态对比结果。如此，集控系统无需每次去本地获取数据，就能够对产线上生产设备的运行状态进行查询和对比。

Description

数据处理系统及方法

技术领域

本申请实施例涉及智能制造技术领域，涉及但不限于一种数据处理系统及方法。

背景技术

在电池的生产过程中，电池产线上通过上位机本地记录生产设备的运行状态，并将运行数据存储于本地数据库中，而生产设备报警是由独立的模块进行持续监测，用于集控系统统计各个机台的报警持续时间。

但是，由于生产设备的运行状态仅存储于本地数据库中，且设备报警与设备运行状态之间未关联，在发生设备报警时，集控系统需要根据报警时间在机台的本地数据库中进行设备运行状态的查询，实时性较差。因此，如何对生产线上生产设备的运行状态和报警处理进行集中管理是当前亟待解决的问题。

发明内容

为解决相关技术存在的问题，本申请实施例提供一种数据处理系统及方法，在生产线上的设备状态改变时，工控机采集设备的运行状态，并对运行状态与设备变化原因进行关联，将关联数据上传至集控系统，以使得集控系统无需每次去本地获取数据，就能够对多个工控机对应的生产设备的运行状态进行查询和对比，提升了查询效率和实时性。

第一方面，本申请实施例提供一种数据处理系统，所述数据处理系统应用于电池生产线；其特征在于，所述数据处理系统包括：工控机，用于获取所述工控机对应的生产设备的设备运行状态；所述电池生产线包括多个工控机；所述工控机，还用于在所述设备运行状态与所述生产设备上一次的设备运行状态不同的情况下，获取所述生产设备的设备运行数据；所述工控机，还用于在所述设备运行数据表征所述生产设备由第一状态变为第二状态的情况下，获取所述生产设备的设备变化原因；所述工控机，还用于基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至集控系统；所述集控系统，用于对所述多个工控机的设备关联数据进行分析对比，得到所述电池生产线上的所述多个工控机对应的生产设备的运行状态对比结果。

上述实施例中，首先，本申请实施例工控机可以在生产线上的设备状态改变时，采集设备的运行状态，并对运行状态与设备变化原因进行关联，将关联数据上传至集控系统。使得集控系统要查询设备停机时，能够根据关联数据快速确定停机原因和停机时间，数据更加精确，追溯更加便捷。其次，集控系统在接收到关联数据之后，得集控系统无需每次去本地获取数据，就能够对多个工控机对应的生产设备的运行状态进行查询和对比，不仅可以对同类型的工控机对应的生产设备进行横向，提升了查询效率和实时性，还可以对比一个工艺段中的全部生产设备，确定每个工艺段中容易堵料和停机的设备，以提升电池生产线的生产效率。

在一些实施例中，所述系统还包括控制器；其中，所述工控机，还用于对所述工控机与控制器之间的通信通道进行检测，得到检测结果；所述工控机，还用于在所述检测结果表征所述通信通道正常的情况下，触发控制器中的设备运行状态点位；所述控制器，用于在所述设备运行状态点位被触发的情况下，获取所述工控机对应的生产设备的设备运行状态，并将所述设备运行状态发送至所述工控机。

在一些实施例中，所述系统还包括发布订阅服务；其中，所述工控机，还用于对所述设备运行数据中所述生产设备变为所述第二状态的状态变化时刻、所述生产设备处于所述第二状态的状态持续时间与所述工控机的设备资源号进行关联，得到所述设备关联数据；所述工控机，还用于将所述设备关联数据上传至所述发布订阅服务的运行状态主题中；其中，所述集控系统订阅所述运行状态主题；所述集控系统，用于在所述运行状态主题中出现所述设备关联数据时，获取所述设备关联数据。

第二方面，本申请实施例提供一种数据处理方法，应用于上述的数据处理系统；其特征在于，所述数据处理方法包括：工控机获取所述工控机对应的生产设备的设备运行状态；电池生产线包括多个工控机；在所述设备运行状态与所述生产设备上一次的设备运行状态不同的情况下，所述工控机获取所述生产设备的设备运行数据；在所述设备运行数据表征所述生产设备由第一状态变为第二状态的情况下，所述工控机获取所述生产设备的设备变化原因；所述工控机基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至所述集控系统；所述集控系统对所述多个工控机的设备关联数据进行分析对比，得到所述电池生产线上的所述多个工控机对应的生产设备的运行状态对比结果。

上述实施例中，第一方面，本申请实施例工控机可以在生产线上的设备状态改变时，采集设备的运行状态，并对运行状态与设备变化原因进行关联，将关联数据上传至集控系统。使得集控系统要查询设备停机时，能够根据关联数据快速确定停机原因和停机时间，数据更加精确，追溯更加便捷。第二方面，集控系统在接收到关联数据之后，得集控系统无需每次去本地获取数据，就能够对多个工控机对应的生产设备的运行状态进行查询和对比，不仅可以对同类型的工控机对应的生产设备进行横向，提升了查询效率和实时性，还可以对比一个工艺段中的全部生产设备，确定每个工艺段中容易堵料和停机的设备，以提升电池生产线的生产效率。

在一些实施例中，所述工控机获取所述工控机对应的生产设备的设备运行状态，包括：所述工控机对所述工控机与控制器之间的通信通道进行检测，得到第一检测结果；在所述第一检测结果表征所述通信通道正常的情况下，所述工控机触发控制器中的设备运行状态点位；所述控制器在所述设备运行状态点位被触发的情况下，获取所述工控机对应的生产设备的设备运行状态，并将所述设备运行状态发送至所述工控机。

上述实施例中，在工控机获取生产设备的设备运行状态之前，对工控机与控制器之间的连接进行检测，在连接异常的情况下持续进行维护，避免因网络波动或其他原因导致工控机无法读取控制器中点位的问题，提高了数据处理效率。

在一些实施例中，所述第一状态包括多种第一运行状态；所述数据处理方法还包括：在所述设备运行数据表征所述生产设备在所述多种第一运行状态中变化的情况下，所述工控机基于所述设备运行数据确定所述生产设备在各第一运行状态对应的运行时间；所述工控机将所述生产设备在各第一运行状态对应的运行时间与所述工控机的设备资源号进行关联，得到运行关联数据；所述工控机将所述运行关联数据发送至所述集控系统。

上述实施例中，将生产设备在各第一运行状态对应的运行时间上传至集控系统，使得集控系统可以对各工控机对应的生产设备可以按照正常生产、待料、堵料等运行状态进行数据的统计，实现不同工控机之间的设备运行状态对比。

在一些实施例中，所述工控机获取所述生产设备的设备变化原因，包括：所述工控机获取控制器中的报警数组；所述报警数组中包含多个报警点位；所述工控机对所述报警数组与所述工控机配置的本地报警数组进行对比，在所述多个报警点位中确定所述生产设备由第一状态变为第二状态对应的目标报警点位；所述工控机将所述目标报警点位对应的报警原因，确定为所述生产设备的设备变化原因。

上述实施例中，基于设置的报警数组，确定被触发的报警点位，能够快速确定导致设备变化的原因，能够提醒工程师对停机原因进行处置，避免产线停滞导致物料无法处理发生堆积的情况，提升了产线运行效率。

在一些实施例中，所述报警数组中包含多个报警数值，所述多个报警数值对应多个报警点位，各报警点位对应一报警等级；所述工控机对所述报警数组与所述工控机配置的本地报警数组进行对比，在所述多个报警点位中确定所述生产设备由第一状态变为第二状态对应的目标报警点位，包括：所述工控机对所述报警数组的多个报警数值与所述工控机配置的本地报警数组的多个报警数值进行对比，将所述报警数组中报警数值发生变化的报警点位确定为初始报警点位；所述工控机基于所述初始报警点位的报警等级，将所述初始报警点位中报警等级满足设备变化条件的报警点位，确定为所述目标报警点位。

上述实施例中，基于设置的报警数组，确定被触发的报警点位，能够快速确定导致设备变化的原因，能够提醒工程师对停机原因进行处置，避免产线停滞导致物料无法处理发生堆积的情况，提升了产线运行效率。

在一些实施例中，所述设备运行数据至少包括所述生产设备变为所述第二状态的状态变化时刻和所述生产设备处于所述第二状态的状态持续时间；所述工控机基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至所述集控系统，包括：所述工控机对所述状态变化时刻、所述状态持续时间与所述工控机的设备资源号进行关联，得到所述设备关联数据；所述工控机将所述设备关联数据上传至发布订阅服务的运行状态主题中；其中，所述集控系统订阅所述运行状态主题；在所述运行状态主题中出现所述设备关联数据时，所述集控系统获取所述设备关联数据。

上述实施例中，工控机将设备关联数据上传到不同的主题中，使得集控系统可以分类获取数据，使得集控系统可以根据数据类别进行数据分析处理。

在一些实施例中，所述数据处理方法还包括：在所述运行状态主题中具有多个工控机上传的设备关联数据的情况下，所述发布订阅服务基于各工控机预设的优先级，对所述多个工控机上传的设备关联数据进行排序，形成数据序列；对应地，所述集控系统获取所述设备关联数据，包括：所述集控系统基于所述数据序列，依次获取所述运行状态主题中的多个设备关联数据。

上述实施例中，集控系统可以优先获取优先级高的数据，避免无法及时关注到优先级高的工控机对应的生产设备的运行状态。

在一些实施例中，所述数据处理方法还包括：在所述工控机与控制器之间的通信通道正常，且所述控制器中的急停点位被触发的情况下，所述工控机获取所述控制器中的设备急停数据；所述工控机将所述设备急停数据上传至发布订阅服务的急停主题中；其中，所述集控系统订阅所述急停主题，所述急停主题中包含所述电池生产线上的所述多个工控机对应的设备急停数据；在所述急停主题中出现所述设备急停数据时，所述集控系统获取所述设备急停数据，以获取所述多个工控机对应的设备急停数据。

上述实施例中，工控机对非故障停机进行数据采集，并将数据上传至集控系统，避免集控系统对生产线上的设备进行停机分析时，由于非故障停机导致分析结果不准确的问题，提升了分析结果的准确性。

在一些实施例中，所述数据处理方法还包括：在所述工控机与控制器之间的通信通道正常的情况下，所述工控机周期性的获取所述生产设备的设备运行数据，并将所述设备运行数据存储至所述工控机的数据库中。

上述实施例中，工控机将设备状态、停机原因、三色灯等设备运行数据存储到工控机的本地数据库，使得在集控系统的数据丢失的情况下，本地数据库可以进行溯查询，避免数据丢失。

在一些实施例中，所述数据处理方法还包括：所述工控机对所述工控机与数据库之间的连接通道进行检测，得到第二检测结果；在所述第二检测结果表征所述连接通道正常的情况下，所述工控机确定所述数据库中所述设备运行数据的存储日期；所述工控机基于所述存储日期，删除所述数据库中存储日期满足存储条件的设备运行数据，以对所述数据库中的设备运行数据进行数据清理。

上述实施例中，工控机定期对本地数据库中的数据进行清理，避免无用数据占用过多内存，导致工控机效率变低的问题，提升了工控机处理效率。

在一些实施例中，所述数据处理方法还包括：所述工控机确定所述工控机对应的线程池的最大可用线程数和获取所述设备运行状态的需求线程数；在所述需求线程数小于或等于所述最大可用线程数的情况下，所述工控机获取所述设备运行状态；在所述需求线程数大于所述最大可用线程数的情况下，所述工控机关闭进行数据清理的线程或者等待，直至所述需求线程数小于或等于所述最大可用线程数。

上述实施例中，基于工控机要执行的任务所需的线程数，对线程池中的线程进行管理，使得工控机可以优先执行优先级高的任务，保证优先级高的任务的实时数据获取和实时数据传输至集控系统。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

图1是本申请实施例提供的数据处理系统的结构示意图一；

图2是本申请实施例提供的数据处理系统的结构示意图二；

图3是本申请实施例提供的数据处理方法的一个可选的流程示意图一；

图4是本申请实施例提供的数据处理方法的一个可选的流程示意图二；

图5是本申请实施例提供的数采工具进行数据本地存储功能流程示意图；

图6是本申请实施例提供的数采工具进行数据库定时清理流程示意图；

图7是本申请实施例提供的设备状态采集上传流程示意图；

图8是本申请实施例提供的固定LOSS设备状态监控流程示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。除非另有定义，本申请实施例所使用的所有的技术和科学术语与属于本申请实施例的技术领域的技术人员通常理解的含义相同。本申请实施例所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

目前，从市场形势的发展来看，动力电池的应用越加广泛。动力电池不仅被应用于水力、火力、风力和太阳能电站等储能电源系统，而且还被广泛应用于电动自行车、电动摩托车、电动汽车等电动交通工具，以及军事装备和航空航天等多个领域。随着动力电池应用领域的不断扩大，其市场的需求量也在不断地扩增。

本申请人注意到，在电池的生产过程中，相关技术中电池产线上仅通过上位机本地记录生产设备的运行状态，并将运行数据存储于本地数据库中，设备报警是由独立的模块进行持续监测，用于集控系统统计各个报警持续时间。三色灯信息仅作为集控系统显示设备是否在线使用。

但是，设备状态仅在本地统计和展示，无法直接进行同类型机台之间的对比，数据对比需要人工整理，费时费力，并且实时性较差；且设备运行状态和报警停机原因没有形成关联，集控系统查询生产线上的设备发生报警停机时，需要根据停机发生时间在本地数据库中进行查询历史报警，导致查询困难；同时，在统计设备停机时，没有区分故障停机和非故障停机的区别，会对停机原因大数据分析造成影响，也会对正常生产效率的统计造成影响。

为了解决相关技术存在的问题，申请人研究发现，工控机可以在生产线上的设备状态改变时，采集设备的运行状态，并对运行状态与设备变化原因进行关联，将关联数据上传至集控系统，以使得集控系统无需每次去本地获取数据，就能够对多个工控机对应的生产设备的运行状态进行查询和对比，不仅可以对同类型的工控机对应的生产设备进行横向，提升了查询效率和实时性，还可以对比一个工艺段中的全部生产设备，确定每个工艺段中容易堵料和停机的设备，以提升电池生产线的生产效率。同时，对运行状态与设备变化原因进行关联，使得集控系统能够快速确定停机原因和停机时间，数据更加精确，追溯更加便捷。

基于上述发明构思，本申请实施例提供一种数据处理系统及方法，数据处理方法应用于电池生产线的数据处理系统，数据处理系统至少包括配置在电池生产线总服务器上的集控系统和各工艺段上的多个现场机台中的工控机，现场机台具有人机显示模组（HMI，Human Machine Interface），工控机中安装有数据采集软件，用于从控制器中采集工控机对应的生产设备的运行数据。每个现场机台的工控机对应电池生产线上的至少一个生产设备，生产设备可以是指生产线上的机械手、电芯卷绕机、极柱焊接设备、电池组装设备和产品运输车（AGV，Automated Guided Vehicle）等设备。

在本申请实施例中，工控机获取工控机对应的生产设备的设备运行状态，在设备运行状态与生产设备上一次的设备运行状态不同的情况下，获取生产设备的设备运行数据，在设备运行数据表征生产设备由第一状态变为第二状态的情况下，获取生产设备的设备变化原因，基于设备变化原因和设备运行数据，生成设备关联数据，并将设备关联数据上传至集控系统；集控系统对多个工控机的设备关联数据进行分析对比，得到电池生产线上的多个工控机对应的生产设备的运行状态对比结果。

这样，第一方面，本申请实施例工控机可以在生产线上的设备状态改变时，采集设备的运行状态，并对运行状态与设备变化原因进行关联，将关联数据上传至集控系统。使得集控系统要查询设备停机时，能够根据关联数据快速确定停机原因和停机时间，数据更加精确，追溯更加便捷。第二方面，集控系统在接收到关联数据之后，得集控系统无需每次去本地获取数据，就能够对多个工控机对应的生产设备的运行状态进行查询和对比，不仅可以对同类型的工控机对应的生产设备进行横向，提升了查询效率和实时性，还可以对比一个工艺段中的全部生产设备，确定每个工艺段中容易堵料和停机的设备，以提升电池生产线的生产效率。

本申请实施例公开的电池生产线生产的电池包可以但不限用于车辆、船舶或飞行器等用电装置中。可以使用具备本申请公开的电池包、电池等组成该用电装置的电源系统，这样，有利于缓解并自动调节电芯膨胀力恶化，补充电解液消耗，提升电池性能的稳定性和电池寿命。

本申请实施例公开的电池生产线生产的电池包可以作为电源的用电装置，用电装置可以为但不限于手机、平板、笔记本电脑、电动玩具、电动工具、电瓶车、电动汽车、轮船、航天器等等。其中，电动玩具可以包括固定式或移动式的电动玩具，例如，游戏机、电动汽车玩具、电动轮船玩具和电动飞机玩具等等，航天器可以包括飞机、火箭、航天飞机和宇宙飞船等等。

本申请实施例中，电池生产线生产的电池包可以由多个电池串并联形成，其中，电池可以是电池单体。电池单体是指能够实现化学能和电能相互转换的基本单元，可以用于制作电池模组或电池包，从而用于向用电装置供电。电池单体可以为二次电池，二次电池是指在电池单体放电后可通过充电的方式使活性材料激活而继续使用的电池单体。电池单体可以为锂离子电池、钠离子电池、钠锂离子电池、锂金属电池、钠金属电池、锂硫电池、镁离子电池、镍氢电池、镍镉电池、铅蓄电池等，本申请实施例对此并不限定。

在一些实施例中，电池包中包含多个电芯，多个电芯之间可串联或并联或混联，混联是指多个电芯中既有串联又有并联。通过电芯的电芯极柱与汇流组件焊接实现多个电芯之间的串联或并联或混联。其中，每个电芯可以为二次电池或一次电池；还可以是锂硫电池、钠离子电池或镁离子电池，但不局限于此。电芯可呈圆柱体、扁平体、长方体或其它形状等。

在本申请实施例中，数据处理系统及方法不仅可以应用于电池生产线，还可以应用于任一种生产线，例如，汽车生产线或钢铁制造生产线，本申请实施例对数据处理系统及方法的具体应用场景不做限制。

接下来基于数据处理方法应用于电池生产线为例进行说明。

本申请实施例提供一种电池生产线，包括数据处理系统和多个生产设备。在一个电池生产线上具有一个集控系统，集控系统可以布置在电池生产线的总服务器上。该电池生产线包含多个工艺段，例如，极片卷绕、电芯成组、电池包寻址和电池焊接等工艺段，每个工艺段通过多个生产设备来执行该工艺段上的多种工艺操作，例如焊接工艺中除了焊接机器人，还有移动电池包的生产设备、电芯卷绕的设备、电池组装设备和焊接时放置汇流片的生产设备。每个工艺段配置有包含工控机和HMI的现场机台，工控机通过控制器（PLC，Programmable Logic Controller）来采集生产设备的运行数据，现场的工程师可以基于HMI根据生产现场的情况进行报警信息的设置，并将报警信息导入工控机和集控系统。在一些实施例中，工控机可以是上位机。

本申请实施例提供一种数据处理系统，图1是本申请实施例提供的数据处理系统的结构示意图一，如图1所示，数据处理系统10至少包括集控系统101和电池生产线上的多个工控机102-1至102-n。

在一些实施例中，一个电池生产线上配置有一个集控系统101，集控系统101可以布置在电池生产线的总服务器上，该电池生产线包含多个工控机102-1至102-n，每个工控机对应至少一个生产设备，电池生产的每个工艺段通过多个生产设备来执行该工艺操作，例如通过焊接工艺中的焊接机器人来进行电池焊接。

在一些实施例中，各工控机102-1至102-n，用于获取各工控机对应的生产设备的设备运行状态，用于在设备运行状态与生产设备上一次的设备运行状态不同的情况下，获取生产设备的设备运行数据，还用于在设备运行数据表征生产设备由第一状态变为第二状态的情况下，获取生产设备的设备变化原因，还用于基于设备变化原因和设备运行数据，生成设备关联数据，并将设备关联数据上传至集控系统101。集控系统101，用于对所述多个工控机的设备关联数据进行分析对比，得到所述电池生产线上的所述多个工控机对应的生产设备的运行状态对比结果，并将运行状态对比结果显示于集控系统101的显示界面101-1。

在一些实施例中，数据处理系统10还包括各工控机102-1至102-n对应的多个控制器103-1至103-n和发布订阅服务104，控制器可以是指PLC、单片机、中位机以及上位机中的任意一种；发布订阅服务104可以是指卡夫卡服务器（Kafka服务器），Kafka服务器是分布式发布订阅消息系统，各工控机102-1至102-n可以将设备关联数据上传至Kafka服务器对应的主题（Topic）中，集控系统订阅Kafka服务器对应的主题，以获取各工控机102-1至102-n对应的生产设备的设备运行数据和设备变化原因。

在一些实施例中，发布订阅服务104还可以是消息队列，各工控机102-1至102-n可以将设备关联数据上传至消息队列中，集控系统基于消息队列获取各工控机102-1至102-n对应的生产设备的设备运行数据和设备变化原因。

图2是本申请实施例提供的数据处理系统的结构示意图二，如图2所示，各工控机102-1至102-n还用于对各工控机102-1至102-n与对应的控制器103-1至103-n之间的通信通道进行检测，得到检测结果，还用于在检测结果表征通信通道正常的情况下，触发各控制器103-1至103-n中的设备运行状态点位，各控制器103-1至103-n用于在设备运行状态点位被触发的情况下，获取各工控机102-1至102-n对应的生产设备的设备运行状态，并将设备运行状态发送至各工控机102-1至102-n。

在一些实施例中，各控制器103-1至103-n还用于将生产设备的设备变化原因和设备运行数据发送至各工控机102-1至102-n。

在一些实施例中，各工控机102-1至102-n还用于对设备运行数据中生产设备变为第二状态的状态变化时刻、生产设备处于第二状态的状态持续时间与工控机的设备资源号进行关联，得到设备关联数据，并将设备关联数据上传至发布订阅服务104的运行状态主题中，集控系统101订阅运行状态主题，在运行状态主题中出现设备关联数据时，获取设备关联数据。

需要说明的是，本申请实施例中系统的描述，与下述方法实施例的描述是类似的，具有同方法实施例相似的有益效果，对于本系统实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

基于前述数据处理系统，本申请实施例提供一种数据处理方法，图3是本申请实施例提供的数据处理方法的一个可选的流程示意图一，如图3所示，本申请实施例提供的数据处理方法可以通过步骤S301至步骤S305实现：

步骤S301、工控机获取所述工控机对应的生产设备的设备运行状态；电池生产线包括多个工控机。

在本申请实施例中，电池生产线包括多个工控机，可以是一个工艺段上的全部生产设备对应一个工控机，也可以是一个工艺段上有多个工控机，每个工控机对应相同或不同的生产设备，这里，如果两个工控机分别对应相同的生产设备，则这两个工控机为同类型的工控机。

在一些实施例中，生产设备的设备运行状态是指生产设备的当前运行状态，例如，生产设备处于停机、正常运行、待料或者堵料状态。

工控机获取设备运行状态可以是通过触发并读取PLC中的设备运行状态的点位，以获取该工控机对应的生产设备的设备运行状态。

在一些实施例中，工控机读取PLC中的设备运行状态的点位可以是周期性读取，例如每隔1秒（s）读取一次。

步骤S302、在所述设备运行状态与所述生产设备上一次的设备运行状态不同的情况下，所述工控机获取所述生产设备的设备运行数据。

在一些实施例中，工控机在读取了生产设备的设备运行状态之后，会将设备运行状态存储至工控机的数据库中，因此，工控机在获取了生产设备的设备运行状态之后，可以与上一次的设备运行状态进行对比，如果运行状态发生变化，则工控机需要获取生产设备的设备运行数据，来确定生产设备发生了什么变化，是否停机或者是否发生了堵料等情况。

这里，设备运行数据可以包括生产设备发生变化时的状态变化时刻、生产设备变化后的状态持续时间、生产设备三色灯和状态变化原因等数据。其中，生产设备三色灯可以是读取PLC中的设备三色灯点位得到的，红灯表示生产设备停机，绿灯表示生产设备正常生产，黄灯表示生产设备待料堵料；状态变化原因、状态变化时刻和状态持续时间都可以是读取PLC中的对应的点位得到的。

在一些实施例中，如果设备运行状态与生产设备上一次的设备运行状态相同，则无需进行后续操作，可以在1s后再次读取设备运行状态。

步骤S303、在所述设备运行数据表征所述生产设备由第一状态变为第二状态的情况下，所述工控机获取所述生产设备的设备变化原因。

在一些实施例中，第一状态可以是生产设备正常生产、待料和堵料等运行状态，第二状态可以是停机状态，在生产设备变成停机的时候，PLC中对应的报警点位会被触发，因此，这里可以根据被触发的报警点位确定生产设备的设备变化原因。例如，安全门被打开的报警点位被触发了，可以认为安全门被打开是生产设备的设备变化原因。

在一些实施例中，包含工控机的机台上设置有HMI，现场的工程师根据产线情况设置产线的多个（例如10000个）报警点位，每个报警点位都包括报警原因、报警类型，例如，安全门被打开、运输车发生碰撞或光栅有不明物体进入等报警点位，为了减少数据量，可以对多个报警点位进行标准化处理，对报警点位标准化之后可以得到一个具有600个文字（Word）的报警数组，报警数组中的每个Word与多个报警点位一一对应，例如，每16个报警点位对应一个Word。即600个Word与10000个报警点位之间具有映射关系，一个Word点读出16个报警点位。这里，一个Word点对应的16个报警点位可以是指16位的二进制，每个位置为0代表该Word对应16个报警点位均不触发，里面有1代表该报警点位被触发。

这里，工程师在HMI设置了报警数组之后，可以将报警数组导入工控机中，工控机在生产设备由第一状态变为第二状态的情况下，获取PLC的报警数组，对PLC的报警数组和工控机的报警数组进行对比，确定被触发的报警点位，进而得到停机的停机原因，即生产设备的设备变化原因。

在一些实施例中，第一状态可以包括多种第一运行状态，例如生产设备正常运行、待料、堵料等状态，因此，生产设备除了停机，还可以在所述多种第一运行状态中变化，因此，本申请实施例提供的数据处理方法还可以包括步骤S1至步骤S3：

步骤S1、在所述设备运行数据表征所述生产设备在所述多种第一运行状态中变化的情况下，所述工控机基于所述设备运行数据确定所述生产设备在各第一运行状态对应的运行时间。

在一些实施例中，生产设备在所述多种第一运行状态中变化可以是指正常生产变堵料、正常生产变待料等情况，此时，报警点位均未被触发，可以确定生产设备在各第一运行状态对应的运行时间，例如上午9点55从正常生产变为待料，待料时间持续15分钟后变为正常生产。

步骤S2、所述工控机将所述生产设备在各第一运行状态对应的运行时间与所述工控机的设备资源号进行关联，得到运行关联数据。

在本申请实施例中，各工控机具有对应的设备资源号，本申请实施例将各第一运行状态对应的运行时间与工控机的设备资源号进行关联得到运行关联数据，并将运行关联数据发送给集控系统，使得集控系统可以按照正常生产、待料、堵料等运行状态进行数据的统计，实现不同工控机之间的设备运行状态对比。

步骤S3、所述工控机将所述运行关联数据发送至所述集控系统。

本申请实施例将生产设备在各第一运行状态对应的运行时间上传至集控系统，使得集控系统可以对各工控机对应的生产设备可以按照正常生产、待料、堵料等运行状态进行数据的统计，实现不同工控机之间的设备运行状态对比。

步骤S304、所述工控机基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至所述集控系统。

在一些实施例中，将设备变化原因和设备运行数据关联，生成设备关联数据再上传至集控系统，使得集控系统根据设备停机时间查询停机报警原因时，能够根据设备关联数据快速得到，无需在该生产设备对应的机台出进行查询，提升了查询效率。

步骤S305、所述集控系统对所述多个工控机的设备关联数据进行分析对比，得到所述电池生产线上的所述多个工控机对应的生产设备的运行状态对比结果。

在一些实施例中，集控系统在得到多个工控机的设备关联数据之后，可以对各工控机的设备关联数据进行分析对比，得到运行状态对比结果。例如，针对电芯成组工艺段一共有24个机台，如果23个机台中的工控机上传的设备关联数据均正常生产，其中某个机台对应的生产设备经常停机，通过横向对比就可以排查出哪个机台出了问题；也可以通过纵向对比确定一个工艺段中的某个机台对应的生产设备是否经常停机，导致整条产线的产量低。

在本申请实施例中，在得到生产设备的运行状态对比结果之后，可以将运行状态对比结果显示于集控系统的显示界面。这里，可以将运行状态对比结果通过报表的形式进行展示，并生成日报表、月报表等直观的对生产线上不同机台的生产设备的运行状态进行展示，能够帮助管理人掌握产线各工艺段、各机台的生产情况，大大提高了生产效率。

如此，第一方面，本申请实施例工控机可以在生产线上的设备状态改变时，采集设备的运行状态，并对运行状态与设备变化原因进行关联，将关联数据上传至集控系统。使得集控系统要查询设备停机时，能够根据关联数据快速确定停机原因和停机时间，数据更加精确，追溯更加便捷。第二方面，集控系统在接收到关联数据之后，得集控系统无需每次去本地获取数据，就能够对多个工控机对应的生产设备的运行状态进行查询和对比，不仅可以对同类型的工控机对应的生产设备进行横向，提升了查询效率和实时性，还可以对比一个工艺段中的全部生产设备，确定每个工艺段中容易堵料和停机的设备，以提升电池生产线的生产效率。

在一些实施例中，数据处理系统还包括控制器（PLC），工控机用于触发PLC中的对应的点位，来获取生产设备的运行数据。步骤S301可以通过步骤S3011至步骤S3013实现：

步骤S3011、所述工控机对所述工控机与控制器之间的通信通道进行检测，得到第一检测结果。

在一些实施例中，工控机首先会对工控机与控制器之间的通信通道进行检测，确定工控机与控制器之间的连接是否正常，如果不正常，可能是因为网络波动导致的连接失败，此时可以生成错误日志，间隔预设时间段（例如可以是100毫秒）后再次确认工控机与控制器之间的连接是否正常。如果多次连接异常可以在工控机的显示界面或者机台的HMI界面弹窗提示，以提示现场工程师对工控机与控制器之间的连接进行维护。

步骤S3012、在所述第一检测结果表征所述通信通道正常的情况下，所述工控机触发控制器中的设备运行状态点位。

在一些实施例中，在工控机与控制器之间的连接正常的情况下，触发控制器中的设备运行状态点位，以读取设备运行状态点位对应的设备运行数据。这里设备运行状态点位可以是布尔点，未被触发时为false，被触发后为true。

步骤S3013、所述控制器在所述设备运行状态点位被触发的情况下，获取所述工控机对应的生产设备的设备运行状态，并将所述设备运行状态发送至所述工控机。

在一些实施例中，控制器在设备运行状态点位被触发的情况下，通过PLC的程序获取工控机对应的生产设备的设备运行状态，并将设备运行状态基于通信通道发送至工控机。

本申请实施例在工控机获取生产设备的设备运行状态之前，对工控机与控制器之间的连接进行检测，在连接异常的情况下持续进行维护，避免因网络波动或其他原因导致工控机无法读取PLC中点位的问题，提高了数据处理效率。

在一些实施例中，生产设备由第一状态变为第二状态可以是指由运行状态变为停机状态，当生产设备停机时，会触发PLC中的停机报警点位，进而可以获取停机原因。因此，确定生产设备的设备变化原因，即步骤S103可以通过步骤S1031至步骤S1032实现：

步骤S1031、所述工控机获取控制器中的报警数组；所述报警数组中包含多个报警点位。

在一些实施例中，工程师在HMI设置了报警数组之后，可以将报警数组导入工控机和控制器中，工控机在生产设备由运行状态变为停机状态的情况下，会触发控制器中的报警点位，此时，控制器获取PLC的报警数组，对PLC的报警数组和工控机的报警数组进行对比，确定被触发的报警点位，进而得到停机的停机原因，即生产设备的设备变化原因。

在一些实施例中，现场的工程师根据产线的实际运行情况设置产线的多个（例如10000个）报警点位，每个报警点位都包括报警原因、报警类型，例如，安全门被打开、运输车发生碰撞或光栅有不明物体进入等报警点位。为了减少数据量，可以对多个报警点位进行标准化处理，对报警点位标准化之后可以得到一个具有600个文字（Word）的报警数组，报警数组中的每个Word与多个报警点位一一对应，例如，每16个报警点位对应一个Word。即600个Word与10000个报警点位之间具有映射关系，一个Word点读出16个报警点位。这里，一个Word点对应的16个报警点位可以是指16位的二进制，每个位置为0代表不触发，里面有1代表该报警点位被触发。

步骤S1032、所述工控机对所述报警数组与所述工控机配置的本地报警数组进行对比，在所述多个报警点位中确定所述生产设备由第一状态变为第二状态对应的目标报警点位。

在一些实施例中，工控机对控制器的报警数组与所述工控机配置的本地报警数组进行对比，确定控制器的报警数组中与本地报警数组不同的报警点位，即被触发的点位，将该点位确定为生产设备由第一状态变为第二状态对应的目标报警点位。例如，安全门被打开的报警点位在控制器的报警数组中为1，而在本地报警数组中为0，说明安全门被打开的报警点位被触发，此时，可以将安全门被打开的报警点位确定为目标报警点位。

在一些实施例中，所述报警数组中包含多个报警数值，所述多个报警数值对应多个报警点位，各报警点位对应一个报警等级，报警等级至少可以包括一级（F-Alarm）、二级（Alarm）、三级（Warning）和四级（Info），其中，一级（F-Alarm）和二级（Alarm）对应的报警点位被触发会导致生产设备停机。步骤S1032可以通过步骤S4和步骤S5实现：

步骤S4、所述工控机对所述报警数组的多个报警数值与所述工控机配置的本地报警数组的多个报警数值进行对比，将所述报警数组中报警数值发生变化的报警点位确定为初始报警点位。

在一些实施例中，在生产设备停机时，可能有很多报警点位被触发，例如一级报警对应的安全门未关闭，三级报警对应的运输小车发生拥挤等，但是多个被触发的报警点位不一定全都会导致设备停机，只有一级（F-Alarm）和二级（Alarm）对应的报警点位被触发会导致生产设备停机，因此，需要在多个被触发的报警点位（即初始报警点位）中确定导致停机的报警点位。

这里，报警数组中报警数值发生变化的报警点位的报警等级可以是由工程师在设定报警点位时进行设置的。

步骤S5、所述工控机基于所述初始报警点位的报警等级，将所述初始报警点位中报警等级满足设备变化条件的报警点位，确定为所述目标报警点位。

在一些实施例中，设备变化条件可以是报警等级为一级和二级，即目标报警点位为多个被触发的报警点位中一级和二级的报警点位。

在一些实施例中，在设备停机时，可能会有多种因素共同导致停机，因此，在将设备变化原因发送至集控系统时，会设置将置信度最高的五个停机原因发送至集控系统。在前述实施例中，在生产设备的设备运行状态与生产设备上一次的设备运行状态不同的情况下，工控机会获取生产设备的设备运行数据，设备运行数据包含一个PLC发送的设备停机原因，因此，设备变化条件还可以是报警等级为一级和二级，且置信度最高的四个报警点位，此时，目标报警点位为四个，基于四个目标报警点位可以得到四个停机报警原因，四个停机报警原因和一个设备停机原因，构成生产设备停机的设备变化原因，发送至集控系统。

这里，不同报警级别的报警点位的置信度是在设置报警点位时一起设置的，例如，安全门被打开的置信度高于光栅有不明物体进入。

步骤S1033、所述工控机将所述目标报警点位对应的报警原因，确定为所述生产设备的设备变化原因。

在本申请实施例中，可以将目标报警点位对应的报警原因，确定为生产设备的设备变化原因。还可以将PLC发送的设备停机原因与目标报警点位对应的报警原因，确定为生产设备的设备变化原因。

在一些实施例中，工控机在确定了设备变化原因之后，可以将设备变化原因弹窗显示于工控机的显示界面。

本申请实施例基于设置的报警数组，确定被触发的报警点位，能够快速确定导致设备变化的原因，能够提醒工程师对停机原因进行处置，避免产线停滞，导致物料无法处理发生堆积的情况，提升了产线运行效率。

在一些实施例中，所述设备运行数据至少包括所述生产设备变为所述第二状态的状态变化时刻和所述生产设备处于所述第二状态的状态持续时间。图4是本申请实施例提供的数据处理方法的一个可选的流程示意图二，如图4所示，步骤S104可以通过步骤S401至步骤S403实现：

步骤401、所述工控机对所述状态变化时刻、所述状态持续时间与所述工控机的设备资源号进行关联，得到所述设备关联数据。

在一些实施例中，将生产设备的状态变化时刻和状态持续时间与工控机的设备资源号进行关联后上传，使得集控系统在根据时间查询设备的运行状态时，能够快速确定设备的情况，并基于状态持续时间对设备的运行情况进行分析对比。

步骤402、所述工控机将所述设备关联数据上传至发布订阅服务的运行状态主题中；其中，所述集控系统订阅所述运行状态主题。

在一些实施例中，发布订阅服务中有多种不同的主题，集控系统订阅对应的主题，以在该主题出对应的数据时，获取该数据。

步骤403、在所述运行状态主题中出现所述设备关联数据时，所述集控系统获取所述设备关联数据。

在一些实施例中，集控系统订阅发布订阅服务的运行状态主题，工控机将设备关联数据上传至发布订阅服务的运行状态主题后，集控系统即可获取该设备关联数据。

本申请实施例将设备关联数据上传到不同的主题中，使得集控系统可以分类获取数据，使得集控系统可以根据数据类别进行数据分析处理。

在一些实施例中，电池生产线上全部工控机生成的设备关联数据都会发送至发布订阅服务的运行状态主题中，因此，运行状态主题中有时会存在数量较多的设备关联数据，此时，需要对多个设备关联数据进行排序，以使得集控系统可以优先获取重要的数据。这里，本申请实施例提供的数据处理方法还可以包括：在所述运行状态主题中具有多个工控机上传的设备关联数据的情况下，所述发布订阅服务基于各工控机预设的优先级，对所述多个工控机上传的设备关联数据进行排序，形成数据序列。

在一些实施例中，各工控机预设的优先级可以是技术人员预先根据各工控机对应的工艺段确定的，例如电池注液工艺对应的工控机的优先级大于电池焊接工艺对应的工控机的优先级；优先级的设置还可以基于技术人员想要对哪些工艺段的生产设备运行状态进行观察，例如，本月需要对电池成组的多个工艺段进行观察，则电池成组对应的工控机的优先级大于其他工艺段的优先级。

这里，在确定了各工控机对应的优先级之后，发布订阅服务基于各工控机预设的优先级，对多个工控机上传的设备关联数据进行排序，形成数据序列。对应地，步骤403可以实现为集控系统基于该数据序列，依次获取运行状态主题中的多个设备关联数据，以使得集控系统可以优先获取优先级高的数据，避免无法及时关注到优先级高的工控机对应的生产设备的运行状态。

在一些实施例中，生产设备由运行状态变为停机状态，可能是因为故障停机，也可能是因为设备维修，工程师拍下了生产线上的急停按钮导致的非故障停机，但是生产设备由第一状态变为第二状态中未对非故障停机进行区分，因此，集控系统对设备关联数据进行分析时，会因为其中的非故障停机导致得到的生产设备的运行状态对比结果不准确，因此，需要对停机中的非故障停机进行区分。因此，本申请实施例提供的数据处理方法还可以包括步骤S10至步骤S12：

步骤S10、在所述工控机与控制器之间的通信通道正常，且所述控制器中的急停点位被触发的情况下，所述工控机获取所述控制器中的设备急停数据。

在一些实施例中，如果由于产线上的设备需要维修，或者产线切拉换型等情况时，工程师会拍下产线上的急停按钮，使产线上的设备停机，避免移动的设备对产线上的人员造成伤害，此时，拍下急停按钮导致的停机为非故障停机，报警点位不会被触发，生产设备由第一状态变为第二状态的设备变化原因为默认原因。

这里，设备急停数据可以是急停开始时间和急停持续时间，将急停开始时间和急停持续时间于发生急停的生产设备对应的工控机设备资源号进行关联得到设备急停数据。

步骤S11、所述工控机将所述设备急停数据上传至发布订阅服务的急停主题中；其中，所述集控系统订阅所述急停主题，所述急停主题中包含所述电池生产线上的所述多个工控机对应的设备急停数据。

步骤S12、在所述急停主题中出现所述设备急停数据时，所述集控系统获取所述设备急停数据，以获取所述多个工控机对应的设备急停数据。

在本申请实施例中，电池生产线上全部工控机在急停时生成的设备急停数据都会发送至发布订阅服务的急停主题中，集控系统基于急停主题会获取生产线上全部的急停数据。

在本申请实施例中，对非故障停机进行数据采集，并将数据上传至集控系统，避免集控系统对生产线上的设备进行停机分析时，由于非故障停机导致分析结果不准确的问题，提升了分析结果的准确性。

在一些实施例中，为了在集控系统出现设备数据异常/丢失时候，工控机可以在对应机台查询本地数据库进行验证，PLC会在循环遍历对应点位时，将设备状态、停机原因、三色灯等点位数据存储到工控机的本地数据库，使得在集控系统的数据丢失的情况下，本地数据库可以进行追溯查询。因此，本申请实施例提供的数据处理方法还可以包括步骤S20：

步骤S20、在所述工控机与控制器之间的通信通道正常的情况下，所述工控机周期性的获取所述生产设备的设备运行数据，并将所述设备运行数据存储至所述工控机的数据库中。

在一些实施例中，周期性可以是指每隔固定的时间获取一次生产设备的设备运行数据，由于产线上生产设备的运行状态时刻可能发生变化，因此，周期性的时间可以较短，例如一分钟获取一次，避免获取的数据不准确。

本申请实施例将设备状态、停机原因、三色灯等设备运行数据存储到工控机的本地数据库，使得在集控系统的数据丢失的情况下，本地数据库可以进行追溯查询，避免数据丢失。

在一些实施例中，为了不让本地数据库中的数据占用过多内存，导致工控机效率变低的问题，工控机可以通过一个线程去定时清理本地数据库中的数据。因此，本申请实施例提供的数据处理方法还可以包括步骤S30至步骤S32：

步骤S30、所述工控机对所述工控机与数据库之间的连接通道进行检测，得到第二检测结果。

步骤S31、在所述第二检测结果表征所述连接通道正常的情况下，所述工控机确定所述数据库中所述设备运行数据的存储日期。

在一些实施例中，设备运行数据的存储日期是指设备运行数据存入数据库的时间。

步骤S32、所述工控机基于所述存储日期，删除所述数据库中存储日期满足存储条件的设备运行数据，以对所述数据库中的设备运行数据进行数据清理。

在一些实施例中，存储条件可以是一个月，即，工控机会定期（例如每天）清理超过1个月的过期数据。

本申请实施例定期对本地数据库中的数据进行清理，避免无用数据占用过多内存，导致工控机效率变低的问题，提升了工控机处理效率。

在一些实施例中，工控机获取生产线上的生产设备的设备运行状态和设备急停数据，进行数据本地存储和删除过期数据都是基于线程实现的，因此，本申请实施例还提供一种线程分配的方法，如步骤S33至步骤S35所示：

步骤S33、所述工控机确定所述工控机对应的线程池的最大可用线程数和获取所述设备运行状态的需求线程数。

在一些实施例中，工控机可以根据获取设备运行状态对应的任务量来确定执行该操作对应所需的需求线程数，并查询线程池当前的最大可用线程数。

步骤S34、在所述需求线程数小于或等于所述最大可用线程数的情况下，所述工控机获取所述设备运行状态。

步骤S35、在所述需求线程数大于所述最大可用线程数的情况下，所述工控机关闭进行数据清理的线程或者等待，直至所述需求线程数小于或等于所述最大可用线程数。

在一些实施例中，在需求线程数小于或等于最大可用线程数的情况下，工控机获取设备运行状态；在需求线程数大于最大可用线程数的情况下，工控机可以关闭进行数据清理的线程或者等待，直至需求线程数小于或等于最大可用线程数。这里，进行数据清理的优先级低于获取生产设备的设备运行状态，因此，工控机可以关闭进行数据清理的线程。

在一些实施例中，工控机获取设备急停数据、获取设备运行状态、进行数据本地存储和删除过期数据之间的优先级可以是依次降低的关系，基于上述排序以对优先级低的线程进行关闭，以满足优先级高的任务的线程数。

在一些实施例中，工控机在执行获取设备急停数据，进行数据本地存储和删除过期数据等操作时，都可以基于步骤S33至步骤S35来进行线程的分配，以使得工控机能够有序的运行。

本申请实施例基于工控机要执行的任务所需的线程数，对线程池中的线程进行管理，使得工控机可以优先执行优先级高的任务，保证优先级高的任务的实时数据获取和实时数据传输至集控系统。

下面，将说明本申请实施例在一个实际的应用场景中的示例性应用，具体涉及一种生产线上设备的设备状态采集流程。

相关技术中上位机本地记录生产线上设备的设备运行状态，存储于本地数据库并进行统计各个状态运行时间。设备报警是由集控系统中独立的模块进行持续监测，用于集控系统统计各个报警持续时间。三色灯信息仅作为集控系统显示设备是否在线使用。

相关技术中设备状态仅在本地统计和展示，无法直接进行同类型机台之间的对比。同类型机台之间上位数据对比需要人工整理，费时费力，并且实时性较差；设备运行状态和报警停机原因没有形成关联，需要根据停机发生时间进行查询历史报警，查询困难，三色灯仅作为显示信息，也没有显示依据；非故障停机（例如拍了急停按钮、产线切拉换型和设备维修等）也统计进了故障停机时间，会对停机原因的大数据分析造成影响，也会对正常生产效率的统计造成影响。

基于相关技术存在的问题，本申请实施例提供一种设备状态采集流程，通过生产线上的现场机台和电池生产线对应的集控系统实现，现场机台中设置有工控机和人机交互模组（HMI，Human Machine Interface），工控机中设置有数据采集软件（即数采工具），用于采集生产线上设备的运行状态和运行数据。

本申请通过在机台的工控机采集设备状态，通过Kafka协议上传到kafka服务器。集控系统订阅kafka服务器，使得每次设备停机都能查询到对应的设备停机原因；集控系统统计设备状态即可简单得按正常生产、待料、堵料和停机进行统计，也可细分到具体停机原因，使得数据更加精确，追溯更加便捷。

在集控系统收到各个机台对应的生产设备（例如，生产线上的机械手、电芯卷绕机、极柱焊接设备、电池组装设备和产品运输车（AGV）的设备状态后，以设备资源号为主键存储到集控系统的数据库中。集控系统提供信息查询界面，可以以单设备各个状态进行统计；也可以通过选择多个设备进行横向对比。

生产线上的设备在触发停机时，机台上的工控机会立即上传一次设备状态，然后开启一个线程去监控固定LOSS（即非故障停机，例如，按下生产线上的急停按钮）触发点位，如果现场操作人员（OPN，Operations）在触摸屏（即人机交互模组）上选择对应固定LOSS的停机原因（例如切拉换型和设备维修等原因），就会被监控并采集，再次上传一次关于固定LOSS的数据至集控系统。如此，集控系统就可以统计固定LOSS相关信息。

本申请实施例提供的设备状态采集流程一共分为四部分，第一部分为设备状态信息本地存储，生产线上设备状态的变化是偶然的，并不确定发生在什么时候，设备状态是否发生数据丢失也不能保证。为了在集控系统出现设备数据异常或数据丢失时，工控机（即数采工具）可以在对应机台查询本地数据库进行验证，PLC会在循环遍历对应点位时，将设备状态，停机原因和三色灯等点位数据存储到本地数据库。因此，如果集控系统的数据丢失，本地数据库可以进行留底回溯查询。

第二部分为本地数据自动清理，本地数据库中的数据过多会使得数采工具的运行变慢，效率会变低，因此，为了不让本地数据库中的数据占用过多内存，数采工具可以开一个线程去定时清理超过1个月过期数据。

第三部分为设备状态上传，集控系统为了能多维度查看设备运行状态，进行跨机台对比，数采工具可以通过一个线程去采集设备运行的相关信息，打包上传这些数据到Kafka服务器，让集控系统去订阅并分析这些数据。

第四部分为固定LOSS（非故障停机）上传，如果设备由非停机变为停机，则就打开一个固定LOSS监控线程去采集固定LOSS报警并上传到集控系统，用于集控系统区分故障停机和固定LOSS。

本申请实施例提供一种数采工具进行数据本地存储功能流程，当工控机中数采工具程序运行时，包含数采工具的工控机会有一个线程去不断将设备运行状态、设备三色灯、设备停机原因等关键点位不断存储到本地数据库中。该功能主要由PLC和数采工具两个部分组成，

图5是本申请实施例提供的数采工具进行数据本地存储功能流程示意图，如图5所示，数采工具进行数据本地存储功能流程可以通过步骤S501至步骤S504实现：

步骤S501、检测PLC连接是否正常。

首先，工控机的数采工具软件判断PLC和数采工具软件连接状态是否正常，如果PLC连接异常，就会把PLC断连情况写入到错误日志中，执行步骤S503，并休眠100ms后重复步骤S501；如果连接状态正常，执行步骤S502。

步骤S502、读取设备状态、三色灯、停机原因点位。

在一些实施例中，如果PLC连接状态正常，PLC就会去批量读取以下点位：设备运行状态（PackTags.Status.MachineStatus）、设备停机原因（PackTags.Admin.FirstOutAlarm）和设备三色灯（PackTags.Status.LightStack.words）。

步骤S503、写入错误日志。

步骤S504、将数据存储到本地数据库。

在一些实施例中，PLC将这些点位数据存储到数采工具的本地数据库中，休眠100ms后回到步骤S501。

本申请实施例提供一种数采工具数据库定时清理流程，当数采工具程序启动时，会有一个线程去监控数据库中的数采工具设备状态信息表并自动清除过时数据，防止数据库内存不足。该流程主要由本地数据库和数采工具两个部分组成。

图6是本申请实施例提供的数采工具进行数据库定时清理流程示意图，如图6所示，数采工具进行数据库定时清理流程可以通过步骤S601至步骤S606实现：

步骤S601、检测数据库连接是否正常。

在一些实施例中，首先判断一下本地数据库和数采工具之间的连接是否正常，如果本地数据库连接异常，执行步骤S603，写入一次异常日志，然后休眠5s后回到步骤S601；如果本地数据库连接正常，执行步骤S602。

步骤S602、查询关于设备的关键点数据。

在一些实施例中，设备的关键点数据是指保存在本地数据库中的设备运行状态和设备停机原因。如果数据库连接正常，就会去数据库中查询设备状态记录（device_state_record），

步骤S603、写入错误日志。

步骤S604、判断关键点数据是否日期大于1个月。

在一些实施例中，为了保证数据库中的数据不会因为数量过多而导致数采工具运行效率低的问题，需要将本地数据库中一个月之前的数据清除，所以需要判断关键点数据是否日期大于1个月，如果大于1个月，执行步骤S605。

步骤S605、调用数据库。

步骤S606、删除对应记录。

在一些实施例中，数采工具发现本地数据库中有超过一个月的数据时，调用数据库删除超过一个月的数据。

本申请实施例提供一种设备状态采集上传流程，当程序启动时，数采工具会有一个线程去采集PLC中对应的点位，当设备状态点位发生改变，就打包相关数据上传Kafka服务器，集控系统也有一个线程在持续订阅Kafka服务器中对应Topic中的数据，用于更新设备状态信息和统计结果。设备状态采集上传流程主要由PLC、数采工具、集控系统三个部分组成。

图7是本申请实施例提供的设备状态采集上传流程示意图，如图7所示，设备状态采集上传流程可以通过步骤S701至步骤S714实现：

步骤S701、检测PLC连接是否正常。

在一些实施例中，工控机的数采工具判断PLC和数采工具之间的连接状态是否正常，如果PLC连接异常，就会把PLC断连情况写入到错误日志中，并休眠1000ms后重复步骤S701；如果连接状态正常，执行步骤S702。

步骤S702、读取PLC点位。

在一些实施例中，这里读取PLC点位是指，指示PLC读取生产线上的设备运行状态点位，判断设备状态是否与上次一致。

步骤S703、和上次设备状态是否一致。

在一些实施例中，和上次设备状态一致说明设备一致稳定运行，没有发生停机，此时休眠100ms后，再次执行步骤S701。和上次设备状态不一致，说明该设备发生了变化，可能是停机，也可能是由生产状态变为了待料状态，此时，需要读取设备三色灯和设备停机原因等点位，来确定是否发生停机以及停机持续时间和原因。

步骤S704、关闭监控固定LOSS的线程，读取PLC点位。

在一些实施例中，在设备运行状态和上次设备状态不一致的情况下，说明该设备发生了变化，可能是停机，也可能是由生产状态变为了待料状态，此时，需要读取设备三色灯和设备停机原因等点位，来确定是否发生停机以及停机持续时间和原因。

步骤S705、设备状态是否非停机变停机。

这里，可以根据设备三色灯来确定设备当前是否是由非停机变停机，如果是，则执行步骤S706，如果不是，执行步骤S707。

步骤S706、读取报警点位数组。

在一些实施例中，报警点位数组中包含工控机对应的全部生产设备的报警点位，读取报警点位数组，根据读取的报警点位数组与工控机中配置的报警点位进行对比，可以确定具体的被触发的报警点位是什么，进而确定出停机原因。

步骤S707、停机原因为0，报警信息设置默认，与三色灯信息一起上传。

在一些实施例中，如果不是非停机变停机，则将报警信息设置默认，与三色灯信息一起上传至Kafka服务器中的指定topic（例如，设备运行状态主题）。

步骤S708、检测是否已配置的报警点位被触发。

在读取报警点位数组之后，根据读取的报警点位数组与工控机中配置的报警点位进行对比，检测是否已配置的报警点位被触发，如果有，将PLC给出的停机原因上传至Kafka服务器中的指定topic（例如，设备运行状态主题）。

步骤S709、将停机原因打包上传。

步骤S710、开启一个线程去监控固定LOSS触发。

在一些实施例中，设备停机不确定是故障停机还是固定LOSS（即非故障停机），此时，需要开启一个线程去监控固定LOSS触发，避免集控系统分析机台停机原因时，将固定LOSS对应的停机也进行分析，导致分析结果不准确的问题。

步骤S711、订阅Kafka中对应的Topic。

在一些实施例中，集控系统有一个线程在持续订阅Kafka服务器中对应Topic（例如，设备运行状态主题）中的数据，用于更新设备状态信息和统计结果。

步骤S712、获取对应数据。

步骤S713、计算上次停机状态持续时间。

基于获取的设备运行状态、三色灯数据和设备停机原因，可以得到设备停机持续时间和停机原因，进而进行不同机台之间的对比。

步骤S714、新建一条关于新设备状态开始的记录。

本申请实施例提供一种固定LOSS设备状态监控流程，当线程启动后，数采工具会在不断监控固定loss对应触发点（PLC中的布尔），当触发点位True时，就会上传数据到集控系统。集控系统也有一个线程在持续订阅对应Topic中的数据，用于更新设备状态信息和统计结果。本功能主要由数采工具、PLC和集控系统组成。

图8是本申请实施例提供的固定LOSS设备状态监控流程示意图，如图8所示，固定LOSS设备状态监控流程可以通过步骤S801至步骤S810实现：

步骤S801、检测PLC连接是否正常。

在一些实施例中，工控机的数采工具判断PLC和数采工具之间的连接状态是否正常，如果PLC连接异常，就会把PLC断连情况写入到错误日志中，并休眠1000ms后重复步骤S801；如果连接状态正常，执行步骤S802。

步骤S802、读取PLC点位。

在一些实施例中，这里读取PLC点位是指，指示PLC读取生产线上的固定LOSS点位，判断固定LOSS点位是否被触发。

步骤S803、固定LOSS是否是True。

在一些实施例中，如果固定LOSS触发点为False，休眠100ms后回到步骤S801；如果固定LOSS触发点为True，执行步骤S804。

步骤S804、读取PLC点位。

在一些实施例中，这里的读取PLC点位是指读取设备三色灯、设备停机原因、报警数组最后一个Word，最后一个Word包含固定LOSS的原因。

步骤S805、解析Word，提取固定LOSS信息。

在本申请实施例中，解析最后一个Word可以得到固定LOSS的停机原因。

步骤S806、打包固定LOSS信息。

在一些实施例中，将固定LOSS的停机原因上传至Kafka服务器中对应Topic（例如，固定LOSS主题）中。

步骤S807、订阅Kafka对应Topic。

在一些实施例中，集控系统有一个线程在持续订阅Kafka服务器中对应Topic（例如，固定LOSS主题）中的数据，用于基于前述实施例中的数据，确定固定LOSS的持续时间，进行修改机台中数据故障停机的持续时间。

步骤S808、拉取对应数据。

步骤S809、计算上次状态持续时间。

步骤S810、新建一条关于新设备状态开始的记录。

本申请实施例通过在机台的工控机采集设备状态，通过Kafka协议上传到kafka服务器。集控系统订阅kafka服务器，使得每次设备停机都能查询到对应的设备停机原因；集控系统统计设备状态即可简单得按正常生产、待料、堵料和停机进行统计，也可细分到具体停机原因，使得数据更加精确，追溯更加便捷。在集控系统收到各个机台对应设备的设备状态后，以设备资源号为主键存储到集控系统的数据库中。集控系统提供信息查询界面，可以以单设备各个状态进行统计；也可以通过选择多个设备进行横向对比。生产线上的设备在触发停机时，机台上的工控机会立即上传一次设备状态，然后开启一个线程去监控固定LOSS触发点位，如果现场操作人员在触摸屏上选择对应固定LOSS的停机原因，就会被监控并采集，再次上传一次关于固定LOSS的数据至集控系统。如此，集控系统就可以统计固定LOSS相关信息。

以上所述，仅为本申请的实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和范围之内所作的任何修改、等同替换和改进等，均包含在本申请的保护范围之内。

Claims (14)

1.一种数据处理系统，所述数据处理系统应用于电池生产线；其特征在于，所述数据处理系统包括：

工控机，用于获取所述工控机对应的生产设备的设备运行状态；所述电池生产线包括多个工控机；

所述工控机，还用于在所述设备运行状态与所述生产设备上一次的设备运行状态不同的情况下，获取所述生产设备的设备运行数据；

所述工控机，还用于在所述设备运行数据表征所述生产设备由第一状态变为第二状态的情况下，获取所述生产设备的设备变化原因；

所述工控机，还用于基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至集控系统；

所述集控系统，用于对所述多个工控机的设备关联数据进行分析对比，得到所述电池生产线上的所述多个工控机对应的生产设备的运行状态对比结果。

2.根据权利要求1所述的数据处理系统，其特征在于，所述系统还包括控制器；其中，

所述工控机，还用于对所述工控机与控制器之间的通信通道进行检测，得到检测结果；

所述工控机，还用于在所述检测结果表征所述通信通道正常的情况下，触发控制器中的设备运行状态点位；

所述控制器，用于在所述设备运行状态点位被触发的情况下，获取所述工控机对应的生产设备的设备运行状态，并将所述设备运行状态发送至所述工控机。

3.根据权利要求1或2所述的数据处理系统，其特征在于，所述数据处理系统还包括发布订阅服务；其中，

所述工控机，还用于对所述设备运行数据中所述生产设备变为所述第二状态的状态变化时刻、所述生产设备处于所述第二状态的状态持续时间与所述工控机的设备资源号进行关联，得到所述设备关联数据；

所述工控机，还用于将所述设备关联数据上传至所述发布订阅服务的运行状态主题中；其中，所述集控系统订阅所述运行状态主题；

所述集控系统，用于在所述运行状态主题中出现所述设备关联数据时，获取所述设备关联数据。

4.一种数据处理方法，应用于数据处理系统；其特征在于，所述数据处理方法包括：

工控机获取所述工控机对应的生产设备的设备运行状态；电池生产线包括多个工控机；

在所述设备运行状态与所述生产设备上一次的设备运行状态不同的情况下，所述工控机获取所述生产设备的设备运行数据；

在所述设备运行数据表征所述生产设备由第一状态变为第二状态的情况下，所述工控机获取所述生产设备的设备变化原因；

所述工控机基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至集控系统；

所述集控系统对所述多个工控机的设备关联数据进行分析对比，得到所述电池生产线上的所述多个工控机对应的生产设备的运行状态对比结果。

5.根据权利要求4所述的数据处理方法，其特征在于，所述工控机获取所述工控机对应的生产设备的设备运行状态，包括：

所述工控机对所述工控机与控制器之间的通信通道进行检测，得到第一检测结果；

在所述第一检测结果表征所述通信通道正常的情况下，所述工控机触发控制器中的设备运行状态点位；

所述控制器在所述设备运行状态点位被触发的情况下，获取所述工控机对应的生产设备的设备运行状态，并将所述设备运行状态发送至所述工控机。

6.根据权利要求4所述的数据处理方法，其特征在于，所述第一状态包括多种第一运行状态；所述数据处理方法还包括：

在所述设备运行数据表征所述生产设备在所述多种第一运行状态中变化的情况下，所述工控机基于所述设备运行数据确定所述生产设备在各第一运行状态对应的运行时间；

所述工控机将所述生产设备在各第一运行状态对应的运行时间与所述工控机的设备资源号进行关联，得到运行关联数据；

所述工控机将所述运行关联数据发送至所述集控系统。

7.根据权利要求4至6任一项所述的数据处理方法，其特征在于，所述工控机获取所述生产设备的设备变化原因，包括：

所述工控机获取控制器中的报警数组；所述报警数组中包含多个报警点位；

所述工控机对所述报警数组与所述工控机配置的本地报警数组进行对比，在所述多个报警点位中确定所述生产设备由第一状态变为第二状态对应的目标报警点位；

所述工控机将所述目标报警点位对应的报警原因，确定为所述生产设备的设备变化原因。

8.根据权利要求7所述的数据处理方法，其特征在于，所述报警数组中包含多个报警数值，所述多个报警数值对应多个报警点位，各报警点位对应一报警等级；

所述工控机对所述报警数组与所述工控机配置的本地报警数组进行对比，在所述多个报警点位中确定所述生产设备由第一状态变为第二状态对应的目标报警点位，包括：

所述工控机对所述报警数组的多个报警数值与所述工控机配置的本地报警数组的多个报警数值进行对比，将所述报警数组中报警数值发生变化的报警点位确定为初始报警点位；

所述工控机基于所述初始报警点位的报警等级，将所述初始报警点位中报警等级满足设备变化条件的报警点位，确定为所述目标报警点位。

9.根据权利要求4至6任一项所述的数据处理方法，其特征在于，所述设备运行数据至少包括所述生产设备变为所述第二状态的状态变化时刻和所述生产设备处于所述第二状态的状态持续时间；

所述工控机基于所述设备变化原因和所述设备运行数据，生成设备关联数据，并将所述设备关联数据上传至所述集控系统，包括：

所述工控机对所述状态变化时刻、所述状态持续时间与所述工控机的设备资源号进行关联，得到所述设备关联数据；

所述工控机将所述设备关联数据上传至发布订阅服务的运行状态主题中；其中，所述集控系统订阅所述运行状态主题；

在所述运行状态主题中出现所述设备关联数据时，所述集控系统获取所述设备关联数据。

10.根据权利要求9所述的数据处理方法，其特征在于，所述数据处理方法还包括：

在所述运行状态主题中具有多个工控机上传的设备关联数据的情况下，所述发布订阅服务基于各工控机预设的优先级，对所述多个工控机上传的设备关联数据进行排序，形成数据序列；

对应地，所述集控系统获取所述设备关联数据，包括：

所述集控系统基于所述数据序列，依次获取所述运行状态主题中的多个设备关联数据。

11.根据权利要求4至6任一项所述的数据处理方法，其特征在于，所述数据处理方法还包括：

在所述工控机与控制器之间的通信通道正常，且所述控制器中的急停点位被触发的情况下，所述工控机获取所述控制器中的设备急停数据；

所述工控机将所述设备急停数据上传至发布订阅服务的急停主题中；其中，所述集控系统订阅所述急停主题，所述急停主题中包含所述电池生产线上的所述多个工控机对应的设备急停数据；

在所述急停主题中出现所述设备急停数据时，所述集控系统获取所述设备急停数据，以获取所述多个工控机对应的设备急停数据。

12.根据权利要求4至6任一项所述的数据处理方法，其特征在于，所述数据处理方法还包括：

在所述工控机与控制器之间的通信通道正常的情况下，所述工控机周期性的获取所述生产设备的设备运行数据，并将所述设备运行数据存储至所述工控机的数据库中。

13.根据权利要求12所述的数据处理方法，其特征在于，所述数据处理方法还包括：

所述工控机对所述工控机与数据库之间的连接通道进行检测，得到第二检测结果；

在所述第二检测结果表征所述连接通道正常的情况下，所述工控机确定所述数据库中所述设备运行数据的存储日期；

所述工控机基于所述存储日期，删除所述数据库中存储日期满足存储条件的设备运行数据，以对所述数据库中的设备运行数据进行数据清理。

14.根据权利要求4至6任一项所述的数据处理方法，其特征在于，所述数据处理方法还包括：

所述工控机确定所述工控机对应的线程池的最大可用线程数和获取所述设备运行状态的需求线程数；

在所述需求线程数小于或等于所述最大可用线程数的情况下，所述工控机获取所述设备运行状态；

在所述需求线程数大于所述最大可用线程数的情况下，所述工控机关闭进行数据清理的线程或者等待，直至所述需求线程数小于或等于所述最大可用线程数。