CN114866877A - 一种污水处理远程数据的传输方法及系统 - Google Patents

Abstract

本申请涉及一种污水处理远程数据的传输方法及系统，属于数据传输的技术领域，其方法包括：获取污水处理信息；基于污水处理信息判断污水处理是否出现异常；若出现异常，则获取污水处理的异常记录以及实时记录；将异常记录和实时记录上传至主控端设备。本申请具有降低主控端设备进行信息处理的压力的效果。

Description

一种污水处理远程数据的传输方法及系统

技术领域

本申请涉及数据传输的技术领域，尤其是涉及一种污水处理远程数据的传输方法及系统。

背景技术

远程控制，是指计算机设备的管理人员或者系统支持人员等通过互联网连通远程的被控制端的计算机设备。远程控制的相关工作需要通过网络才能进行，位于本地的计算机设备是操作指令的发出端，称为主控端，而远程的被控制端计算机设备可以称为受控端，受控端接收并执行主控端发出的操作指令并在受控端予以执行。主控端和受控端可以是位于同一局域网中的计算机设备，也可以是连入互联网的处在任何位置的两部或多部计算机设备。

目前由于全球环保意识的不断增强，各级政府对于污水的处理的关注度也日益提高，为了便于对城市排放的污水进行统一管理，通常会通过受控端的设备实时对实际排放污水的企业或部门进行数据的采集，然后不同企业不同部门的受控端采集的数据，会统一传输至主控端的设备进行监控管理，从而实现对污水排放的监督工作。

但是，由于对于一个城市而言，受控端的设备众多，因此会采集大量数据上传至主控端设备，这会给主控端设备的信息处理造成较大的压力。

发明内容

为了降低主控端设备进行信息处理的压力，本申请提供一种污水处理远程数据的传输方法及系统。

本申请提供的一种污水处理远程数据的传输方法，采用如下的技术方案：

一种污水处理远程数据的传输方法，包括：

获取污水处理信息；

基于所述污水处理信息判断污水处理是否出现异常；

若出现异常，则获取污水处理的异常记录以及实时记录；

将所述异常记录和所述实时记录上传至主控端设备。

通过采用上述技术方案，判断污水处理是否出现异常，然后根据判断的结果确定是否传输异常记录和实时记录，不需要持续传输信息至主控端设备，从而能够降低主控端设备进行信息处理的压力。

作为优选，所述将所述异常记录和所述实时记录上传至主控端设备，包括：

获取在预设时间段内所述异常记录的异常次数；

判断所述异常次数是否大于次数阈值；

若所述异常次数大于所述次数阈值，则获取污水处理异常的所述实时记录；

将所述实时记录和所述异常记录上传至所述主控端设备；

若所述异常次数小于或等于所述次数阈值，则将所述异常记录上传至所述主控端设备。

通过采用上述技术方案，判断异常次数是否大于次数阈值，然后选择是否上传实时记录，能够提高判断是否传输实时记录的准确性。

作为优选，所述将所述异常记录和所述实时记录上传至主控端设备，还包括：

获取在预设时间段内所述异常记录的持续时长；

判断所述持续时长是否大于时长阈值；

若所述持续时长大于所述时长阈值，则获取污水处理异常的所述实时记录；

将所述实时记录和所述异常记录上传至所述主控端设备；

若所述持续时长小于或等于所述时长阈值，则将所述异常记录上传至所述主控端设备。

通过采用上述技术方案，判断持续时长是否大于时长阈值，从而确定是否上传实时记录，通过不同的方式进行选择，能够提高适用性。

作为优选，若出现异常时，还包括：

基于所述污水处理信息获取不同的异常次数对应的异常因素；

判断所有的所述异常因素是否相同；

若相同，则基于所述异常因素获取相应的处理设备的设备名称；

将所述设备名称上传至所述主控端设备；

若不同，则记录不同的所述异常因素的发生次数。

通过采用上述技术方案，判断异常因素是否相同能够判断处理设备是否发生异常，进而方便主控端设备获知发生异常的设备的设备名称。

作为优选，在所述基于所述污水处理信息获取不同所述异常次数对应的异常因素之后，还包括：

判断所述异常因素是否包括PH值因素；

若包括所述PH值因素，则获取来水PH值；

判断所述来水PH值是否稳定；

若稳定，则获取相应的水处理企业的信用扣分值；

将所述信用扣分值上传至所述主控端设备；

若不稳定，则获取泵机的动作信息；

基于所述动作信息判断所述泵机是否存在应急停机动作；

若存在，则记录所述应急停机动作的应急时长；

若不存在，则获取所述信用扣分值并上传至所述主控端设备。

通过采用上述技术方案，判断来水PH值是否稳定，并进一步通过判断泵机是否存在应急停机动作，从而判断是否获取水处理企业的信用扣分值，从而方便对水处理企业进行管控。

作为优选，在所述记录所述应急停机动作的应急时长之后，还包括：

判断所述应急时长是否与预设时长匹配；

若匹配，则不获取所述信用扣分值；

若不匹配，则获取所述信用扣分值并上传至所述主控端设备。

通过采用上述技术方案，进一步通过应急时长与预设时长的匹配关系，确定是否获取信用扣分值，能够尽可能防止水处理企业胡乱停机，提高信用扣分值获取的准确性。

作为优选，在所述将所述设备名称上传至所述主控端设备之后，还包括：

获取处理设备的状态信息；

基于所述状态信息判断所述处理设备是否运行正常；

若运行正常，则获取所述处理设备的用料记录；

将所述用料记录上传至所述主控端设备；

若运行异常，则获取相应的处理设备的位置信息。

通过采用上述技术方案，判断处理设备是否正常运行，在运行正常时获取用料记录并上传至主控端设备，方便主控端设备记录水处理企业的用料情况。

第二方面，本申请提供一种污水处理远程数据的传输系统，采用如下的技术方案：

一种污水处理远程数据的传输系统，包括：

信息获取模块，用于获取污水处理信息；

异常判断模块，用于基于所述污水处理信息判断污水处理是否出现异常；

记录获取模块，用于若出现异常，则获取污水处理的异常记录以及实时记录；

信息传输模块，用于将所述异常记录和所述实时记录上传至主控端设备。

通过采用上述技术方案，信息获取模块获取污水处理信息之后发送给与其相连的异常判断模块，异常判断模块根据污水处理信息判断污水处理是否发生异常，并将判断的结果发送给与其相连的记录获取模块。

当出现异常时，记录获取模块获取污水处理的异常记录以及实时记录，并发送给与其相连的信息传输模块，最后信息传输模块将异常记录和实时记录上传至主控端设备。不需要持续传输信息至主控端设备，从而能够降低主控端设备进行信息处理的压力。

作为优选，所述信息传输模块包括：

次数获取子模块，用于获取在预设时间段内所述异常记录的异常次数；

次数判断子模块，用于判断所述异常次数是否大于次数阈值；

记录获取子模块，用于若所述异常次数大于所述次数阈值，则获取污水处理异常的所述实时记录；

记录上传子模块，用于将所述实时记录和所述异常记录上传至所述主控端设备；还用于若所述异常次数小于或等于所述次数阈值，则将所述异常记录上传至所述主控端设备。

通过采用上述技术方案，次数获取子模块获取在预设时间段内异常记录的异常次数，并发送给与其相连的次数判断子模块。次数判断子模块判断异常次数是否大于次数阈值，并将判断的结果发送给与其相连的记录获取子模块和记录上传子模块。

当异常次数小于或等于次数阈值时，记录上传子模块将异常记录上传至主控端设备；当异常次数大于次数阈值时，记录获取子模块和获取污水处理异常的实时记录，并发送给与其相连的记录上传子模块，然后记录上传子模块将实时记录和异常记录上传至主控端设备。从而通过判断异常次数是否大于次数阈值，然后选择是否上传实时记录，能够提高判断是否传输实时记录的准确性。

综上所述，本申请包括以下至少一种有益技术效果：

1.判断污水处理是否出现异常，然后根据判断的结果确定是否传输异常记录和实时记录，不需要持续传输信息至主控端设备，从而能够降低主控端设备进行信息处理的压力；

2.通过判断异常次数是否大于次数阈值，然后选择是否上传实时记录，能够提高判断是否传输实时记录的准确性。

附图说明

图1是本申请实施例提供的一种污水处理远程数据的传输方法的整体流程示意图；

图2是本申请一个实施例中步骤S11至步骤S15的流程示意图；

图3是本申请一个实施例中步骤S21至步骤S25的流程示意图；

图4是本申请一个实施例中步骤S31至步骤S35的流程示意图；

图5是本申请一个实施例中步骤S41至步骤S49的流程示意图；

图6是本申请一个实施例中步骤S51至步骤S53的流程示意图；

图7是本申请一个实施例中步骤S61至步骤S65的流程示意图；

图8是本申请实施例提供的一种污水处理远程数据的传输系统的结构框图。

附图标记说明：

1、信息获取模块；2、异常判断模块；3、记录获取模块；4、信息传输模块；41、次数获取子模块；42、次数判断子模块；43、记录获取子模块；44、记录上传子模块。

具体实施方式

以下结合附图1至8对本申请作进一步详细说明。

本申请实施例公开一种污水处理远程数据的传输方法。

参照图1，污水处理远程数据的传输方法包括：

S1.获取污水处理信息；

S2.基于污水处理信息判断污水处理是否出现异常；

S3.若出现异常，则获取污水处理的异常记录以及实时记录；

S4.将异常记录和实时记录上传至主控端设备。

具体来说，污水处理企业将处理完成的污水排放的过程中，受控端设备采集污水的污水处理信息，其中，污水处理信息包括污水处理之后各种成分的含量，获取方式可以通过相应的测量仪表测量获得，同时还包括相应的污水处理企业的位置以及相应的名称，位置可以通过受控端设备上设置的位置传感器或定位系统获取，然后相应的位置对应相应的企业名称，即获得位置即可获得相应的名称。

然后受控端设备根据采集的污水处理信息，判断污水处理是否出现异常，也就是判断排放的污水是否达到排放的标准。如果达到标准，也就是没有出现异常，此时不需要进行任何处理，正常排放即可。

如果没有达到标准，也就是污水处理出现异常，此时获取污水处理的异常记录以及实时记录。其中，异常记录是指污水中成分含量超过排放标准的物质的相关记录，实时记录是指污水处理各个环节中的数据，实时记录中的数据为受控端设备实时记录的数据，数据记录后存储在相应的存储设备中，需要使用时可以直接调取。

受控端设备获取异常记录和实时记录之后，将异常记录和实时记录上传给与受控端设备通讯连接的主控端设备，从而使水处理的相关数据，只有在发生异常的情况下再上传，不需要受控端设备将时时刻刻采集的实时记录的相关数据上传至主控端设备，进而能够降低主控端设备进行数据信息处理的压力，同时降低主控端设备的存储压力。

参照图2，为了进一步提高是否传输实时记录的准确性，在另一个实施例中，步骤S4即将异常记录和实时记录上传至主控端设备，包括：

S11.获取在预设时间段内异常记录的异常次数；

S12.判断异常次数是否大于次数阈值；

S13.若异常次数大于次数阈值，则获取污水处理异常的实时记录；

S14.将实时记录和异常记录上传至主控端设备；

S15.若异常次数小于或等于次数阈值，则将异常记录上传至主控端设备。

具体来说，将异常记录和实时记录上传至主控端设备的过程中，获取在预设时间段内异常记录的异常次数，其中，预设时间段可以根据实际情况进行设置。例如，部分水处理企业进行污水处理过程中，一天内会进行多次处理排放，因此，就可以记录一天内的发生异常的异常次数，也就是此时的预设时间段被设置为一天。

然后，判断异常次数是否大于次数阈值，污水处理企业在处理污水过程中，可能会由于偶尔的操作失误，导致处理过程中部分污水处理不彻底，导致污水处理异常，通过判断异常次数是否大于次数阈值，能够判断污水处理企业是否认真进行污水处理。例如，次数阈值设置为一天一次，也就是如果一天的时间内，企业出现的异常次数大于一次，就证明污水处理企业存在一定的问题。

所以，当异常次数大于次数阈值时，就需要获取污水处理异常的实时记录，异常记录包括污水处理过程中每个阶段的污水处理的结果数据，通过该实时记录，可以寻找企业在污水处理过程中的问题环节。最后将实时记录和异常记录上传至主控端设备，方便相关部门通过主控端设备对相应的企业的污水处理数据进行管理，并方便后续督促企业进行整改。

而当异常次数小于或等于次数阈值时，证明污水处理企业可能只是偶尔疏忽，所以不需要对所有的水处理环节进行数据的收集，所有受控端设备采集的实时记录就不需要上传至主控端设备，而只需要将异常记录上传至主控端设备，方便主控端设备对异常的企业的异常数据进行管理。

参照图3，进一步的，除了通过次数进行判断之外，还可以通过时长进行判断，因此，在另一个实施例中，步骤S4即将异常记录和实时记录上传至主控端设备，还包括：

S21.获取在预设时间段内异常记录的持续时长；

S22.判断持续时长是否大于时长阈值；

S23.若持续时长大于时长阈值，则获取污水处理异常的实时记录；

S24.将实时记录和异常记录上传至主控端设备；

S25.若持续时长小于或等于时长阈值，则将异常记录上传至主控端设备。

具体来说，将异常记录和实时记录上传至主控端设备的过程中，获取在预设时间段内异常记录的持续时长，即在污水处理完排放的过程中，污水处理企业可能发现了排放的污水存在问题，因此可能会对排放的污水进行拦截。而此时的预设时间段为根据污水处理企业每次排放污水的持续时间设置。即企业会在污水存储到一定的容量之后进行统一处理，处理完成之后再进行排放，而在该容量下污水的排放时长，即为预设时间段。

然后判断持续时长是否大于时长阈值，次数的时常阈值可以根据实际情况进行设置，且时长阈值小于预设时间段。判断持续时长是否大于时长阈值，即判断污水处理企业是否及时对处理不达标的污水进行拦截，以方便重新进行处理。

如果持续时间小于或等于时长阈值，证明污水处理企业发现问题，并及时对不达标的污水进行拦截，因此证明污水处理企业不是主观故意排放不达标污水，所以此时不需要上传实时记录，只需要将异常记录上传至主控端设备即可。

而如果持续时间大于时长阈值，证明污水处理企业对污水的管理还存在较大的问题，所以此时获取污水处理的实时记录，并将实时记录和异常记录均上传至主控端设备，从而方便相关部门对污水处理企业进行监督，尽可能保证污水处理的有效性。

参照图4，在另一个实施例中，若出现异常时，还包括：

S31.基于污水处理信息获取不同的异常次数对应的异常因素；

S32.判断所有的异常因素是否相同；

S33.若相同，则基于异常因素获取相应的处理设备的设备名称；

S34.将设备名称上传至主控端设备；

S35.若不同，则记录不同的异常因素的发生次数。

具体来说，在污水处理过程中出现异常时，根据污水处理信息获取不同的异常次数对应的异常因素，也就是获取每一次记录的污水异常的异常原因，其中异常因素就是指污水处理排放的过程中，不达标的成分。

然后判断所有的异常因素是否相同，也就是判断同一个污水处理企业，进行污水处理之后，每一次发生异常的异常原因是否均相同，从而能够判断是否为同一个污水处理环节出现问题。

如果所有的异常因素均相同，证明企业进行污水处理过程中，同一个环节发生问题，问题的原因具体可以是处理过程中，由于探针或者计量表发生故障，导致测量的污水的数据不准确，进而导致污水处理不彻底。

所以，此时获取异常因素对应的处理设备的设备名称，即污水中不同的成分会有不同的设备进行处理，而它们之间的对应关系可以通过预设的关系表获取，通过获取异常因素中对应的成分，然后根据关系表即可获取相应的处理设备的设备名称。最后将设备名称上传至主控端设备，方便相关部门的人员根据主控端设备收集的设备名称对相应污水处理企业进行查访。

如果所有的异常因素不同，或不完全相同，则记录不同的异常因素的发生次数，方便污水处理企业根据发生次数对企业的相关环节进行整改。在本申请的一种实施方式中，受控端设备通过判断每个异常因素的发生次数与预设的次数的阈值的大小关系，能够判断相应的设备是否出现异常。如果发生次数大于次数的阈值，证明相应的处理设备或者处理环节出现问题，需要及时进行整改，而如果发生次数小于或等于次数的阈值，证明处理设备大概率没有故障，此时可能是操作人员操作失误，因此方便记录发生次数之后，对相关的问题进行发现并解决。

参照图5，在另一个实施例中，在步骤S31即基于污水处理信息获取不同异常次数对应的异常因素之后，还包括：

S41.判断异常因素是否包括PH值因素；

S42.若包括PH值因素，则获取来水PH值；

S43.判断来水PH值是否稳定；

S44.若稳定，则获取相应的水处理企业的信用扣分值；

S45.将信用扣分值上传至主控端设备；

S46.若不稳定，则获取泵机的动作信息；

S47.基于动作信息判断泵机是否存在应急停机动作；

S48.若存在，则记录应急停机动作的应急时长；

S49.若不存在，则获取信用扣分值并上传至主控端设备。

具体来说，在基于污水处理信息获取不同异常次数对应的异常因素之后，判断异常因素是否包括PH值因素，即判断污水处理信息中是否包括PH值异常，如果包括就证明异常因素包括PH值因素，反之则不包括。

如果不包括PH值因素，则不需要进行后续的步骤。如果包括PH值因素，此时获取来水PH值，也就是获取进入污水处理设备中进行污水处理的污水的PH值。然后判断来水PH值是否稳定，即判断多次进行处理的污水的PH值是否位于一定的PH值范围内，该PH值范围可以根据实际情况进行设置。

如果PH值稳定，证明此时处理的污水不存在PH值不稳定导致水质控制出现不稳定的情况，因此此时证明污水处理企业连污水的PH值都没有控制良好，因此此时获取水处理企业的信用扣分值，每一个污水处理企业都会预设一个信用值，每记录一次信用扣分值，企业的信用值就会降低，当信用值降低到一定数值之后，相关部门会勒令企业进行整改，并且不能够继续进行污水处理的工作。

如果来水PH值不稳定，证明PH值处理过程中处理之后的PH值会存在较大的影响波动，而对于合格的污水处理企业，此时会将送入污水的泵机进行紧急停机处理，从而方便进行应急处理。

所以，来水PH值不稳定时，获取泵机的动作信息，其中，动作信息也就是泵机的开机动作、关机动作和应急停机动作。获取方式可以通过传感器获得，不同的动作信息会通过不同的按钮实现，因此通过不同的传感器获取不同的按钮反馈，即可获得相应的动作信息。

然后根据动作信息判断蹦极是否存在应急停机动作，即判断企业内部是否进行应急处理。如果不存在，证明污水处理企业管理不合格，此时获取信用扣分值并上传至主控端设备。如果存在应急停机动作，大概率证明企业内部对污水处理有严格的管理制度，此时获取应急停机动作的应急时长。获取方式可以通过记录操作应急停机动作按钮的时间，并记录在这之后操作开机动作按钮的时间，通过计算这两个时间的差值的绝对值，即可获得应急时长。

参照图6，为了尽可能防止恶意操作，在另一个实施例中，在记录应急停机动作的应急时长之后，还包括：

S51.判断应急时长是否与预设时长匹配；

S52.若匹配，则不获取信用扣分值；

S53.若不匹配，则获取信用扣分值并上传至主控端设备。

具体来说，记录应急时长之后，判断应急时长是否与预设时长匹配，即判断应急时长是否位于预设时长的区间值内，也就是说预设时长为一个范围值。其中，预设时长为主控端设备的相关人员，根据历史对来水PH值不稳定情况进行应急处理的时长进行预设的值，并将该预设值存储于受控端设备内，且该预设值设有保护密码。

如果应急时长与预设时长匹配，此时证明企业进行处理的速度较为及时，所以不获取信用扣分值。如果应急时长与预设时长不匹配，即应急时长位于预设时长的区间值范围外，此时大概率证明企业没有认真进行应急处理，因此此时获取信用扣分值并上传至主控端设备。从而通过上述方式能够督促企业严格按照规定进行污水处理，尽可能的保证污水处理的质量。

参照图7，在另一个实施例中，在步骤S34即将设备名称上传至主控端设备之后，还包括：

S61.获取处理设备的状态信息；

S62.基于状态信息判断处理设备是否运行正常；

S63.若运行正常，则获取处理设备的用料记录；

S64.将用料记录上传至主控端设备；

S65.若运行异常，则获取相应的处理设备的位置信息。

具体来说，设备名称上传至主控端设备之后，获取处理设备的状态信息，其中状态信息包括设备运行的各项参数，可以通过传感器测得。然后根据状态信息判断处理设备是否运行正常，即判断设备运行的各项参数，与预设的处理设备的正常运行的参数进行对比，判断参数是否相同，如果相同，则证明运行正常，否则运行异常。

如果设备运行正常，但此时污水处理异常，此时获取设备的用料记录，即通过设备进行污水处理过程中，使用的污水处理试剂或中和调料的用量，并将用料记录上传至主控端设备，从而方便相关部门对企业的用料的用量进行检查。

如果设备运行异常，此时获取相应的处理设备的位置信息，从而方便企业根据位置信息寻找相应的位置，对设备进行检修。位置信息的获取方式，同样可以根据位置传感器获得。

本申请实施例一种污水处理远程数据的传输方法的实施原理为：首先获得污水处理信息，然后根据污水处理信息判断污水处理是否出现异常，若出现异常则获取异常记录和实时记录，并将异常记录和实时记录上传至主控端设备。不需要持续传输信息至主控端设备，从而能够降低主控端设备进行信息处理的压力。

本申请实施例还公开一种污水处理远程数据的传输系统，能够达到如上述一种污水处理远程数据的传输方法同样的技术效果。

参照图8，污水处理远程数据的传输系统包括：

信息获取模块1，用于获取污水处理信息；

异常判断模块2，用于基于污水处理信息判断污水处理是否出现异常；

记录获取模块3，用于若出现异常，则获取污水处理的异常记录以及实时记录；

信息传输模块4，用于将异常记录和实时记录上传至主控端设备。

具体来说，信息获取模块1获取污水处理信息之后发送给与其相连的异常判断模块2，异常判断模块2根据污水处理信息判断污水处理是否发生异常，并将判断的结果发送给与其相连的记录获取模块3。

当出现异常时，记录获取模块3获取污水处理的异常记录以及实时记录，并发送给与其相连的信息传输模块4，最后信息传输模块4将异常记录和实时记录上传至主控端设备。不需要持续传输信息至主控端设备，从而能够降低主控端设备进行信息处理的压力。

进一步的，在另一个实施例中，信息传输模块4包括：

次数获取子模块41，用于获取在预设时间段内异常记录的异常次数；

次数判断子模块42，用于判断异常次数是否大于次数阈值；

记录获取子模块43，用于若异常次数大于次数阈值，则获取污水处理异常的实时记录；

记录上传子模块44，用于将实时记录和异常记录上传至主控端设备；还用于若异常次数小于或等于次数阈值，则将异常记录上传至主控端设备。

具体来说，当出现异常时，次数获取子模块41获取在预设时间段内异常记录的异常次数，并发送给与其相连的次数判断子模块42。次数判断子模块42判断异常次数是否大于次数阈值，并将判断的结果发送给与其相连的记录获取子模块43和记录上传子模块44。

当异常次数小于或等于次数阈值时，记录上传子模块44将异常记录上传至主控端设备；当异常次数大于次数阈值时，记录获取子模块43和获取污水处理异常的实时记录，并发送给与其相连的记录上传子模块44，然后记录上传子模块44将实时记录和异常记录上传至主控端设备。从而通过判断异常次数是否大于次数阈值，然后选择是否上传实时记录，能够提高判断是否传输实时记录的准确性。

以上均为本申请的较佳实施例，并非依此限制本申请的保护范围，故：凡依本申请的结构、形状、原理所做的等效变化，均应涵盖于本申请的保护范围之内。

Claims (9)

1.一种污水处理远程数据的传输方法，其特征在于，包括：

获取污水处理信息；

基于所述污水处理信息判断污水处理是否出现异常；

若出现异常，则获取污水处理的异常记录以及实时记录；

将所述异常记录和所述实时记录上传至主控端设备；

若未出现异常，则不进行任何操作。

2.根据权利要求1所述的传输方法，其特征在于，所述将所述异常记录和所述实时记录上传至主控端设备，包括：

获取在预设时间段内所述异常记录的异常次数；

判断所述异常次数是否大于次数阈值；

若所述异常次数大于所述次数阈值，则获取污水处理异常的所述实时记录；

将所述实时记录和所述异常记录上传至所述主控端设备；

若所述异常次数小于或等于所述次数阈值，则将所述异常记录上传至所述主控端设备。

3.根据权利要求1所述的传输方法，其特征在于，所述将所述异常记录和所述实时记录上传至主控端设备，还包括：

获取在预设时间段内所述异常记录的持续时长；

判断所述持续时长是否大于时长阈值；

若所述持续时长大于所述时长阈值，则获取污水处理异常的所述实时记录；

将所述实时记录和所述异常记录上传至所述主控端设备；

若所述持续时长小于或等于所述时长阈值，则将所述异常记录上传至所述主控端设备。

4.根据权利要求1所述的传输方法，其特征在于，若出现异常时，还包括：

基于所述污水处理信息获取不同的异常次数对应的异常因素；

判断所有的所述异常因素是否相同；

若相同，则基于所述异常因素获取相应的处理设备的设备名称；

将所述设备名称上传至所述主控端设备；

若不同，则记录不同的所述异常因素的发生次数。

5.根据权利要求4所述的传输方法，其特征在于，在所述基于所述污水处理信息获取不同所述异常次数对应的异常因素之后，还包括：

判断所述异常因素是否包括PH值因素；

若包括所述PH值因素，则获取来水PH值；

判断所述来水PH值是否稳定；

若稳定，则获取相应的水处理企业的信用扣分值；

将所述信用扣分值上传至所述主控端设备；

若不稳定，则获取泵机的动作信息；

基于所述动作信息判断所述泵机是否存在应急停机动作；

若存在，则记录所述应急停机动作的应急时长；

若不存在，则获取所述信用扣分值并上传至所述主控端设备。

6.根据权利要求5所述的传输方法，其特征在于，在所述记录所述应急停机动作的应急时长之后，还包括：

判断所述应急时长是否与预设时长匹配；

若匹配，则不获取所述信用扣分值；

若不匹配，则获取所述信用扣分值并上传至所述主控端设备。

7.根据权利要求4所述的传输方法，其特征在于，在所述将所述设备名称上传至所述主控端设备之后，还包括：

获取所述处理设备的状态信息；

基于所述状态信息判断所述处理设备是否运行正常；

若运行正常，则获取所述处理设备的用料记录；

将所述用料记录上传至所述主控端设备；

若运行异常，则获取相应的处理设备的位置信息。

8.一种污水处理远程数据的传输系统，其特征在于，包括：

信息获取模块(1)，用于获取污水处理信息；

异常判断模块(2)，用于基于所述污水处理信息判断污水处理是否出现异常；

记录获取模块(3)，用于若出现异常，则获取污水处理的异常记录以及实时记录；

信息传输模块(4)，用于将所述异常记录和所述实时记录上传至主控端设备。

9.根据权利要求8所述的传输系统，其特征在于，所述信息传输模块(4)包括：

次数获取子模块(41)，用于获取在预设时间段内所述异常记录的异常次数；

次数判断子模块(42)，用于判断所述异常次数是否大于次数阈值；

记录获取子模块(43)，用于若所述异常次数大于所述次数阈值，则获取污水处理异常的所述实时记录；

记录上传子模块(44)，用于将所述实时记录和所述异常记录上传至所述主控端设备；还用于若所述异常次数小于或等于所述次数阈值，则将所述异常记录上传至所述主控端设备。

Images