[0001] 本申请涉及物联网数据采集技术领域，特别涉及数据采集方法、控制装置、系统及计算机可读存储介质。

[0002] 在物联网（Internet of Things，IoT）系统中，数据采集是核心环节之一，尤其在工业物联网（Industrial Internet of Things，IIoT）环境下，需要处理大量设备和传感器的数据，这些设备通常通过不同的协议（如PLC‑S7、Modbus、OPC UA等）进行通信。这些设备的数据采集需要在物联网平台中进行通道（例如网际互联协议（Internet Protocol，IP）、端口）及点表配置，以便边缘设备能够采集数据并上传至平台。在现有的IoT平台中，主要依赖于手动配置采集通道和点表（设备数据表），这是一个复杂且容易出错的过程，特别是在大规模工业应用场景中。由于缺乏对多种通信协议点表的有效聚合和基于网络拓扑结构的管理，使得传统的物联网平台通常面临以下问题：通道及设备点表配置过于复杂，特别是在大规模设备场景下，不同协议的设备需要单独配置采集通道和点表，难以进行统一管理。

[0003] 平台与边缘网关之间的数据交互过程不高效，每个点表配置需要单独从云端下发，浪费了大量网络流量，尤其是在设备需要频繁更新的点表的情况下。

[0004] 通道状态和设备状态查看不直观，尤其是多个协议和多尔个设备并存的场景，难以准确、实时地判断各通道的连接状态和设备的在线情况。

[0005] 边缘网关采集设备数据效率低，尤其是在多点表、多协议的情况下。

[0020] 为使本申请要解决的技术问题、技术方案和优点更加清楚，下面将结合附图及具体实施例进行详细描述。在下面的描述中，提供诸如具体的配置和组件的特定细节仅仅是为了帮助全面理解本申请的实施例。因此，本领域技术人员应该清楚，可以对这里描述的实施例进行各种改变和修改而不脱离本申请的范围和精神。另外，为了清楚和简洁，省略了对已知功能和构造的描述。

[0021] 应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。

[0022] 在本申请的各种实施例中，应理解，下述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

[0023] 应理解，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A 和/或B，可以表示：单独存在A，同时存在A 和B，单独存在B 这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

[0024] 在本申请所提供的实施例中，应理解，“与A 相应的B”表示B 与A 相关联，根据A可以确定B。但还应理解，根据A 确定B 并不意味着仅仅根据A 确定B，还可以根据A 和/或其它信息确定B。

[0025] 参见图1，本申请的一实施例提供了一种数据采集方法，应用于物联网平台，包括：步骤S101，接收到关于边缘采集网关的配置信息后，根据所述配置信息，确定所述边缘采集网关的至少一个采集通道、多个设备的点表以及所述采集通道与所述设备的连接关系；
步骤S102，根据各所述点表对应的协议类型，对所述点表进行聚合处理，得到目标聚合点表；
步骤S103，将所述目标聚合点表下发至所述边缘采集网关；
步骤S104，订阅接收所述边缘采集网关上传的根据所述聚合点表采集的采集数据；
步骤S105，对所述采集数据进行数据分析，得到各所述采集通道对应的采集通道状态和各所述设备对应的设备状态；
步骤S106，通过拓扑结构图展示所述采集通道、所述点表、所述连接关系、所述设备状态以及所述采集通道状态。

[0026] 在本申请的一具体实施例中，物联网平台在接收到关于边缘采集网关的配置信息后，会基于该配置信息确定边缘采集网关的至少一个采集通道、多个设备的点表以及采集通道与设备的连接关系，进而基于各点表对应的协议类型对所有的点表进行聚合处理，将不同设备、不同协议类型的点表聚合为一个目标聚合点表，从而在进行点表下发时，可直接将多种点表一次性下发至边缘采集网关，减少了点表下发次数且减少了数据传输量，从而节省了网络流量，且便于提高边缘采集网关的配置效率，进一步的，使边缘网关基于聚合点表进行数据采集，并上传得到的采集数据，挺高了数据采集效率；物联网平台通过订阅接收边缘网关上传的采集数据，其中订阅的方式优选采用消息队列遥测传输 （Message Queuing Telemetry Transport，MQTT）技术订阅；在接收到上传的采集数据后，可通过数据分析得到各采集通道对应的采集通道状态和各设备对应的设备状态，进而将配置信息中的采集通道、点表、连接关系以及通过数据分析得到的设备状态和采集通道状态通过拓扑结构图进行展示，便于实现对采集通道状态和设备状态的实时监控和故障排查，且便于用户通过该拓扑结构图进行配置，简化了采集通道和点表的配置流程，提升了系统的易用性和可扩展性。

[0027] 综上所述，本申请通过点表聚合在进行点表下发时，减少了点表下发次数且减少了数据传输量，从而节省了网络流量，且便于提高边缘网关的数据采集效率；通过网络拓扑结构图展示数据分析得到的设备状态和采集通道状态等，便于实现对采集通道状态和设备状态的实时监控和故障排查，且便于用户通过该拓扑结构图进行配置，简化了采集通道和点表的配置流程，提升了系统的易用性和可扩展性。

[0028] 需要说明的是，所述配置信息可以为用户通过网络或设备上传的文件，或者，直接由用户直接通过网络拓扑模块输入的信息配置得到。

[0029] 需要说明的是，网络拓扑模块通过边缘网关的多个接口（例如RS485、RJ45等）来建立采集通道，并在通道上配置与设备通信所需的协议类型、连接方式及其他必要参数（如IP地址、端口号或串口波特率、采样周期等）。这些参数的设定确保了边缘网关与不同设备之间的通信稳定且高效。

[0030] 网络拓扑模块通过直观的拓扑结构图展示采集通道和设备之间的连接关系，并在通道和设备旁设置了状态指示灯（小圆圈）以实时反馈当前运行状态。绿色指示灯表示通道或设备处于在线状态，灰色则表示离线。用户通过可视化的网络拓扑结构图，可以快速识别每条通道的连接状态和设备的运行状态，大幅提升了配置管理的直观性和便捷性。

[0031] 该网络拓扑模块不仅简化了多协议、多设备的复杂配置流程，还通过图形化界面有效展示了边缘采集网关与各采集设备之间的关系，显著提高了物联网系统中数据采集的效率与准确性。

[0032] 需要说的是，物联网平台在接收到采集数据或对采集数据进行处理后，还会对采集数据或处理结果进行存储。同时通过状态更新功能向用户发送状态更新提醒。使得用户可在平台上查看边缘采集网关配置的通道、设备点表、连接状态和设备在线状态等信息，以便掌握采集系统的整体运行情况。

[0033] 参见图2，具体地，如上所述的方法，所述根据各所述点表对应的协议类型，对所述点表进行聚合处理，得到目标聚合点表包括：步骤S201，根据协议类型和地址类型对所述点表进行排序，得到排序后的点表队列；
步骤S202，根据所述点表队列中的所述协议类型，将所述点表分别导入对应所述协议类型的协议聚合处理流程；
步骤S203，执行各所述协议聚合处理流程，得到所述协议类型对应的子聚合点表；
步骤S204，对各所述子聚合点表进行合并，得到所述目标聚合点表。

[0034] 在本实施例中如何进行点表聚合进行了示例，其中，在进行点表聚合时会先根据协议类型和地址类型等对多个点表进行排序，使得各点表根据协议类型、地址类型甚至是具体的地址进行排序，以便后续对同一协议类型的点表进行分类聚合处理，避免不同协议类型的点表穿插设置影响聚合效率和聚合效果。进一步的还可以便于在进行点表下发后，边缘网关基于协议类型顺序进行设备连接，例如先对第一协议类型的设备连接，当第一协议类型的设备均连接后再对第二协议类型的设备进行连接，避免频繁进行协议类型切换影响设备连接效率。

[0035] 在一具体实施例中，点表排序可通过Sort函数实现，具体可以为：。

[0036] 其中， 为排序后的点表队列；为确定的点表的集合；
为协议类型；
为地址类型。

[0037] 在得到排序后的点表队列后，由于不同协议类型的点表中的数据信息存在差异，导致在进行点表聚合时，不同协议类型的点表之间无法直接聚合或聚合方法复杂，故将相同协议类型的点表导入到一个对应协议类型的协议聚合处理流程中进行处理，得到对应的子聚合点表，有利于提高聚合效率和聚合的准确性，同时，多个各协议聚合处理流程可同步执行，进一步提高聚合效率。进而，将多个子聚合点表进行合并，即可得到所需的目标聚合点表。在一具体实施例中，在将相同协议类型的点表导入到一个对应协议类型的协议聚合处理流程时，需要先根据协议类型进行分类处理，其具体可以表示为：，其中， 为预设协议类型 的点表子集。
最终得到的目标聚合点表可以表示为 ，其中， 表示第 个协议类型对应的子聚合点表， 表示协议类型的数量。

[0038] 参见图3，优选地，如上所述的方法，所述根据协议类型和地址类型对所述点表进行排序，得到排序后的点表队列之前，还包括：步骤S301，对各所述点表中的信息进行数据解析处理，得到具有预设数据结构且与所述协议类型对应的数据信息；
步骤S302，对各所述数据信息进行标准化处理，使所述点表具有统一点表格式。

[0039] 在本实施例中，为便于对点表进行排序和聚合处理的准确性，在进行排序之前，会对各点表中的信息进行数据解析处理和标准化处理，以使所有的点表具有统一点表格式。

[0040] 其中，数据解析用于根据协议类型将各点表中携带的原始信息，转化为具有预设数据结构的数据信息，以便于后续进行标准化处理，该预设数据结构其物联网平台中统一的内部数据结构。

[0041] 标准化处理用于将不同协议类型的点表转换为具有统一点表格式的点表，使后续的合并操作能够基于统一的标准进行。标准化处理的具有过程包括对点表的地址进行统一处理，确保地址格式的一致性，还可以包括标记各协议类型中的数据类型和数据长度等信息。

[0042] 进一步，在进行数据解析时，由于协议类型的不同，各点表进行数据解析处理得到的数据信息中的消息种类也存在一定的区别，故为便于本领域技术人员理解，本申请在一具体实施例中对点表中部分与所述协议类型对应的数据信息的种类进行了示例：若所述协议类型为PLC协议（例如：PLC‑S7协议），则所述数据信息至少包括数据地址、数据地址类型和数据类型；
若所述协议类型为Modbus协议，则所述数据信息至少包括寄存器类型、数据类型和寄存器地址；
若所述协议类型为OPC UA协议，则所述数据信息至少包括标识符、命名空间和数组索引。

[0043] 优选地，如上所述的方法，执行所述协议聚合处理流程，得到对应的子聚合点表，包括以下至少一项：若所述协议类型为PLC协议，则判断相邻所述点表的数据地址类型和数据类型是否相同，若相同，则将第一地址偏移量位于第一预设地址偏移量范围内的所述点表合并，得到与所述协议类型对应的所述子聚合点表，其中，所述第一预设地址偏移量范围与所述数据类型对应；若数据地址类型和数据类型中的至少一项不相同，或第一地址偏移量位于第一预设地址偏移量范围外，则直接根据顺序进行点表聚合。在一具体实施例中，第一地址偏移量即相邻两个点表的数据地址之间的差值的绝对值，计算公式可以表示为：
，其中， 为该第一地址偏移量， 为当前协议类型中第 个点表的数据
地址。在另一具体实施例中对不同数据类型对应的第一预设地址偏移量范围进行了示例，其中，若数据类型为位数据类型（Bit），则该第一预设地址偏移量范围为小于等于0.1；若数据类型为8位整数数据类型（Int8/Uint8），则该第一预设地址偏移量范围为小于等于11；若数据类型为16位整数数据类型（Int16/Uint16），则该第一预设地址偏移量范围为小于等于
2；若数据类型为32位整数数据类型（Int32/Uint32）或浮点型数据类型（Float），则该第一预设地址偏移量范围为小于等于4；若数据类型为位数据类型（Int64/Uint64）或双精度浮点型数据类型（Double），则该第一预设地址偏移量范围为小于等于8。

[0044] 若所述协议类型为Modbus协议，则判断相邻所述点表的寄存器地址类型和数据类型是否相同，若相同，则将第二地址偏移量位于第二预设地址偏移量范围内的所述点表合并，得到与所述协议类型对应的所述子聚合点表，其中，所述第二预设地址偏移量范围与所述数据类型对应；若寄存器地址类型和数据类型中的至少一项不相同，或第二地址偏移量位于第二预设地址偏移量范围外，则直接根据排列顺序进行聚合。在一具体实施例中，第二地址偏移量即相邻两个点表的寄存器地址之间的差值的绝对值，计算公式可以表示为：，其中， 为该第二地址偏移量， 为当前
协议类型中第 个点表的数据地址。在另一具体实施例中对不同数据类型对应的第二预设地址偏移量范围进行了示例，其中，若数据类型为位数据类型（Bit）、8位整数数据类型（Int8/Uint8）或16位整数数据类型（Int16/Uint16），则该第二预设地址偏移量范围为小于等于1；若数据类型为32位整数数据类型（Int32/Uint32）或浮点型数据类型（Float），则该第二预设地址偏移量范围为小于等于2；若数据类型为位数据类型（Int64/Uint64）或双精度浮点型数据类型（Double），则该第二预设地址偏移量范围为小于等于4。

[0045] 若所述协议类型为OPC UA协议，则判断相邻所述点表的标识符和命名空间是否相同，若相同，则对所述数组索引连续的所述点表进行点表合并，得到对应的所述子聚合点表。其中，若标识符和命名空间中的至少一项不相同，或数组索引不连续，则直接根据排列顺序进行聚合。在一具体实施例中判断两个相邻点表是否可合并的算法可以表示为，其中，的值表示相邻点表 和 是否满足上述条件， 表示当前协议类型中
第个点表对应的标识符和/或命名空间，其中，命名空间用于区分同名标识符；
表示当前协议类型中第个点表对应的数组索引； 表示第 个点表对应的
数组长度。

[0046] 需要说明的是，上述执行所述协议聚合处理流程，得到对应的子聚合点表的步骤为基于作为示例的三种协议类型进行的示例，当协议类型不同于上示例的协议类型的其他协议类型时，技术人员可根据具体的协议类型判断相邻两个点表之间是否可进行合并。

[0047] 参见图4，本申请的另一实施例还提供了一种数据采集方法，应用于边缘采集网关，包括：步骤S401，订阅接收物联网平台下发的目标聚合点表；
步骤S402，根据所述目标聚合点表中的点表，与配置的各协议类型的设备建立连接，并执行数据采集任务；
步骤S403，将采集到设备的采集数据上传至所述物联网平台。

[0048] 在本申请的另一实施例中对应用于边缘采集网关的数据采集方法进行了示例，其中，边缘采集网关与物联网平台通讯连接，且通过订阅的方式接收物联网平台下发的目标聚合点表，其中订阅的方式优选采用MQTT技术订阅。在得到该目标聚合点表中，即可基于目标聚合点表中的点表，与配置的各协议类型的设备建立连接，并执行数据采集任务，由于目标聚合点表中的点表为基于点表对应的协议类型进行聚合处理得到，通过一次订阅即可得到多个设备的数据表，故边缘网关可以一次实现对多种协议类型的多个设备进行配置连接和数据采集，相较于单独下发每个点表，减少了点表接收次数且减少了数据传输量，从而节省了网络流量，且便于提高边缘网关的数据采集效率，提高了系统响应速度。进一步的，可将基于目标聚合点表采集到多个设备的采集数据一起上传至物联网平台，以便于物联网平台基于采集数据进行数据分析，并基于数据分析得到的结果通过拓扑结构图进行展示，以便于实现对采集通道状态和设备状态的实时监控和故障排查。

[0049] 需要说明的是，边缘采集网关与物联网平台通讯连接的方式包括但不限于无线局域网（例如WIFI）、移动通信技术（例如4G、5G）、有线网等。

[0050] 在一具体实施中，边缘采集网关还订阅物联网平台的指令、空中下载技术信息（Over‑the‑Air，OTA）等。

[0051] 在一具体实施中，边缘采集网关上传采集数据时，会将数据进行封装，且根据预配置进行变化上传或全量上传。

[0052] 参见图5，本申请的再一实施例还提供了一种控制装置，应用于物联网平台，包括：配置模块501，用于接收到关于边缘采集网关的配置信息后，根据所述配置信息，确定所述边缘采集网关的至少一个采集通道、多个设备的点表以及所述采集通道与所述设备的连接关系；
点表聚合模块502，用于根据各所述点表对应的协议类型，对所述点表进行聚合处理，得到目标聚合点表；
点表下发模块503，用于将所述聚合点表下发至所述边缘采集网关；
数据接收模块504，用于并订阅接收所述边缘采集网关上传的根据所述聚合点表采集的采集数据；
第一数据处理模块505，用于对所述采集数据进行数据分析，得到各所述采集通道对应的采集通道状态和各所述设备对应的设备状态；
网络拓扑模块506，用于通过拓扑结构图展示所述采集通道、所述点表、所述连接关系、所述设备状态以及所述采集通道状态。

[0053] 具体地，如上所述的控制装置，点表聚合模块502包括：排序单元，用于根据协议类型和地址类型对所述点表进行排序，得到排序后的点表队列；
协议设别和分流单元，用于根据所述点表队列中的所述协议类型，将所述点表分别导入对应所述协议类型的协议聚合处理流程；
子聚合单元，用于执行各所述协议聚合处理流程，得到所述协议类型对应的子聚合点表；
总聚合单元，用于对各所述子聚合点表进行合并，得到所述目标聚合点表。

[0054] 优选地，如上所述的控制装置，还包括：数据解析单元，用于对各所述点表中的信息进行数据解析处理，得到具有预设数据结构且与所述协议类型对应的数据信息；
标准化单元，用于对各所述数据信息进行标准化处理，使所述点表具有统一点表格式。

[0055] 可选地，如上所述的控制装置，与所述协议类型对应的数据信息包括以下至少一项：若所述协议类型为PLC协议，则所述数据信息至少包括数据地址、数据地址类型和数据类型；
若所述协议类型为Modbus协议，则所述数据信息至少包括寄存器类型、数据类型和寄存器地址；
若所述协议类型为OPC UA协议，则所述数据信息至少包括标识符、命名空间和数组索引。

[0056] 优选地，如上所述的控制装置，子聚合单元，包括以下至少一项：第一聚合单元，用于若所述协议类型为PLC协议，则判断相邻所述点表的数据地址类型和数据类型是否相同，若相同，则将第一地址偏移量位于第一预设地址偏移量范围内的所述点表合并，得到与所述协议类型对应的所述子聚合点表，其中，所述第一预设地址偏移量范围与所述数据类型对应；
第二聚合单元，用于若所述协议类型为Modbus协议，则判断相邻所述点表的寄存器地址类型和数据类型是否相同，若相同，则将第二地址偏移量位于第二预设地址偏移量范围内的所述点表合并，得到与所述协议类型对应的所述子聚合点表，其中，所述第二预设地址偏移量范围与所述数据类型对应；
第三聚合单元，用于若所述协议类型为OPC UA协议，则判断相邻所述点表的标识符和命名空间是否相同，若相同，则对所述数组索引连续的所述点表进行点表合并，得到对应的所述子聚合点表。

[0057] 本申请的控制装置实施例是与上述应用于物联网平台的数据采集方法的实施例对应的装置，上述方法实施例中的所有实现手段均适用于该装置的实施例中，也能达到相同的技术效果。本申请实施例提供的上述控制装置，能够实现上述方法实施例所实现的所有方法步骤，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

[0058] 参见图6，本申请的又一实施例还提供了一种控制装置，应用于边缘采集网关，包括：数据通信模块601，用于订阅接收物联网平台下发的目标聚合点表；
数据采集模块602，用于根据所述目标聚合点表中的点表，与配置的各协议类型的设备建立连接，并执行数据采集任务；
所述数据通信模块601，还用于将采集到设备的采集数据上传至所述物联网平台。

[0059] 在另一实施例中，上述的控制装置还包括：第二数据处理模块，用于对采集数据进行存储和封装。

[0060] 本申请的控制装置实施例是与上述应用于边缘采集网关的数据采集方法的实施例对应的装置，上述方法实施例中的所有实现手段均适用于该装置的实施例中，也能达到相同的技术效果。本申请实施例提供的上述控制装置，能够实现上述方法实施例所实现的所有方法步骤，且能够达到相同的技术效果，在此不再对本实施例中与方法实施例相同的部分及有益效果进行具体赘述。

[0061] 本申请的另一实施例还提供了一种物联网数据采集系统，包括：物联网平台、边缘采集网关以及多个设备；其中，所述物联网平台中设置有第一处理器、第一存储器及存储在所述存储器上并可在所述第一处理器上运行的第一计算机程序，所述第一计算机程序被所述第一处理器执行时实现如上所述的数据采集方法的步骤，且能达到相同的技术效果，为避免重复，这里不再赘述；
所述边缘采集网关分别连接所述物联网平台和多个所述设备，所述边缘采集网关中设置有第二处理器、第二存储器及存储在所述存储器上并可在所述第二处理器上运行的第二计算机程序，所述第二计算机程序被所述第二处理器执行时实现如上所述的数据采集方法的步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

[0062] 为便于本领域技术人员理解，参见图7，提供一种物联网数据采集系统的架构示意图。

[0063] 其中，用户向物联网平台发送配置信息；物联网平台基于配置信息进行点表聚合，得到目标聚合点表并向边缘采集网关下发该目标聚合点表；边缘采集网关基于目标聚合点表进行点表配置，并开始进行设备的数据收集；边缘采集网关对采集数据上传至物联网平台，物联网平台对采集数据进行数据处理，并将处理结构通过网络拓扑结构展示给用户。

[0064] 本申请的另一实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如上所述的应用于物联网平台的数据采集方法的步骤，或者，所述计算机程序被处理器执行时实现如上所述的应用于边缘采集网关的数据采集方法的步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

[0065] 本申请的另一实施例还提供了一种计算机程序产品，包括计算机指令，所述计算机指令被处理器执行时实现如上所述的应用于物联网平台的数据采集方法的步骤，或者，所述计算机指令被处理器执行时实现如上所述的应用于边缘采集网关的数据采集方法的步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

[0066] 此外，本申请可以在不同例子中重复参考数字和/或字母。这种重复是为了简化和清楚的目的，其本身不指示所讨论各种实施例和/或设置之间的关系。

[0067] 还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含。

[0068] 以上所述是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请所述原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。