IoT device resource allocation method and system for an industrial cloud platform

Abstract

This invention discloses a method and system for allocating IoT device resources on an industrial cloud platform, relating to the field of IoT device technology. The key technical solution includes the following steps: obtaining target demand information and access information of IoT devices to be allocated to the network, wherein the target demand information includes device demand type, and the access information includes initial access node and target transmission link; extracting features from the target demand information to obtain first pre-processed demand features; extracting cloud-edge collaborative resource data associated with the initial access node and target transmission link, and determining the access node switching status of the IoT devices to be allocated based on the cloud-edge collaborative resource data; and processing and analyzing historical objective feature data, historical feature data, historical pre-processed demand features, and current pre-processed demand features to output resource allocation results, thereby ensuring the rationality and feasibility of resource allocation.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) device technology, and more specifically, to a method and system for allocating IoT device resources on an industrial cloud platform. Background Technology

[0002] Due to the sheer number of IoT devices connected to industrial cloud platforms, and the differences in data transmission, computation, storage, and stability among these devices, traditional IoT resource allocation methods employ fixed node access and uniform resource ratios. These methods fail to segment device needs based on their characteristics or fully integrate cloud-edge collaboration for dynamic resource adaptation. Existing technologies neglect the real-time resource load of edge nodes, the actual performance of the target transmission link, and the matching degree between the target device's requirements. This can easily lead to initial node resource overload, transmission link congestion, and resource allocation imbalances. Consequently, data transmission latency may exceed limits, command response may be delayed, and even operational interruptions may occur, severely impacting the continuity and stability of industrial production and making it difficult to guarantee the rationality and reliability of resource allocation. Summary of the Invention

[0003] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a method and system for allocating IoT device resources on an industrial cloud platform.

[0004] To achieve the above objectives, the present invention provides the following technical solution: A method for allocating IoT device resources on an industrial cloud platform, the method comprising the following steps: Obtain the target requirement information and access information of the IoT devices to be configured on the network, wherein the target requirement information includes the device requirement type, and the access information includes the initial access node and the target transmission link; The first preprocessed requirement features are obtained by extracting features from the target requirement information; Extract cloud-edge collaborative resource data associated with the initial access node and the target transmission link, and determine the access node switching status of the IoT devices to be configured based on the cloud-edge collaborative resource data; Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics corresponding to the current switching status are obtained. Historical objective feature data, historical feature data, and historical preprocessing requirement features are extracted from historical distribution network feature data; wherein, the historical objective feature data includes resource allocation imbalance and fault report data during historical operation. The system processes and analyzes historical objective characteristic data, historical feature data, historical preprocessing requirement characteristics, and current preprocessing requirement characteristics, and then outputs resource allocation results.

[0005] Preferably, feature extraction is performed on the target demand information to obtain the first preprocessed demand features, specifically including the following steps: Obtain the device operation scenario tags corresponding to the target requirement information; Based on the equipment operation scenario tags, the target requirement information is divided into dimensions to obtain the target dimensions, and the requirement items of the target dimensions are extracted. Identify the constraints and priority adaptation conditions among the requirement items corresponding to different target dimensions, and clarify the influence weight of each constraint based on the constraints and priority adaptation conditions; The standardized demand characteristics are obtained by processing the influence weights and demand items; The effectiveness of the standardized requirement features is verified to obtain the first preprocessed requirement features.

[0006] Preferably, the standardized demand characteristics are obtained by processing the influencing weights and demand items, specifically including the following steps: The requirements are classified and filtered according to their impact weight, retaining high-priority core requirements and classifying and integrating low-priority auxiliary requirements. A requirement feature mapping relationship is constructed based on the integrated low-priority auxiliary requirement items and core requirement items; Based on the mapping relationship, core requirement items are converted into basic requirement features, and integrated auxiliary requirement items are converted into extended requirement features. The basic and extended requirement features are aligned according to time sequence; the aligned basic and extended requirement features are then merged to generate standardized requirement features.

[0007] Preferably, the extraction of cloud-edge collaborative resource data associated with the initial access node and the target transmission link specifically includes the following steps: The associated scope of cloud-edge collaborative resources is determined based on the initial access node and the target transmission link; Collect cloud-based collaborative resource basic data of edge node resources within the associated range, and collect edge-side collaborative resource basic data between edge nodes through which the target transmission link passes; wherein, the cloud-based collaborative resource basic data includes the resource occupancy, idle capacity, response efficiency, and stability of edge nodes; the edge-side collaborative resource basic data includes the link transmission capacity, transmission delay, and stability between edge nodes through which the target transmission link passes. By associating and integrating the basic data of collaborative resources on the edge side with the basic data of collaborative resources on the cloud side, cloud-edge collaborative resource data is obtained.

[0008] Preferably, determining the access node switching status of IoT devices in the network to be configured based on cloud-edge collaborative resource data specifically includes the following steps: The cloud-edge collaborative resource data is used to extract edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data corresponding to the initial access node. The resource supply capacity of the initial access node is obtained based on edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data. The switching status of access nodes for IoT devices in the network to be distributed is obtained based on whether the resource supply capacity of the initial access node matches the target demand of the IoT devices in the network to be distributed.

[0009] Preferably, the access node switching status of the IoT devices to be configured is obtained based on whether the resource supply capacity of the initial access node matches the target demand of the IoT devices to be configured. This specifically includes the following steps: Determine whether the resource supply capacity of the initial access node matches the target requirements of the IoT devices to be networked. If the resource supply capacity of the initial access node can match the target needs of the IoT devices to be configured, then it is determined that there is no need to switch access nodes. If the resource supply capacity of the initial access node cannot match the target demand of the IoT devices to be distributed, the resource redundancy and transmission link adaptability of the adjacent access nodes are compared. Based on the resource redundancy of the adjacent access nodes, the transmission link adaptability, and the carrying limit of the target transmission link, the access node switching situation of the IoT devices to be distributed is determined.

[0010] Preferably, the current preprocessing requirement features corresponding to the current switching situation are obtained based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing requirement features. Specifically, this includes the following steps: Resource allocation information that matches historical collaborative resource data is filtered based on access node switching information; wherein, the resource allocation information includes resource supply parameters, resource scheduling response efficiency, and resource occupancy stability information; Basic feature information is obtained by associating and matching resource allocation information with the first preprocessing requirement features; An initial set of corrected features is obtained by correcting the basic feature information based on the historical demand index error. The initial set of corrected features is normalized to obtain the features required for current preprocessing.

[0011] Preferably, the resource allocation result is output after processing and analyzing historical objective feature data, historical feature data, historical preprocessing requirement features, and current preprocessing requirement features. Specifically, this includes the following steps: The comparison results are obtained by comparing the historical preprocessing requirements with the current preprocessing requirements. Based on the comparison results, historical objective characteristic data, and historical characteristic data, we can identify resource allocation problems and solutions in the historical power distribution network process. The resource allocation results are obtained by analyzing cloud-edge collaborative resource data, resource allocation issues, solutions, and current preprocessing requirements.

[0012] Preferably, the resource allocation results are obtained by analyzing cloud-edge collaborative resource data, resource allocation issues, solutions, and current preprocessing requirements. Specifically, this includes the following steps: Based on cloud-edge collaborative resource data, resource allocation issues and solutions, a resource adjustment and allocation scheme is obtained by adapting and adjusting the resource requirements according to the current preprocessing needs. The resource allocation plan is verified based on the access node switching situation to obtain the resource allocation result.

[0013] An IoT device resource allocation system for an industrial cloud platform includes: Acquisition module: Acquires target requirement information and access information of IoT devices to be configured on the network, wherein the target requirement information includes the device requirement type, and the access information includes the initial access node and the target transmission link; First extraction module: Extracts features from the target requirement information to obtain the first preprocessed requirement features; Judgment module: Extracts cloud-edge collaborative resource data associated with the initial access node and the target transmission link, and judges the access node switching status of the IoT device to be configured based on the cloud-edge collaborative resource data; Processing module: Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics are obtained to correspond to the current switching status. The second extraction module extracts historical objective feature data, historical feature data, and historical preprocessing requirement features from historical distribution network feature data; wherein, the historical objective feature data includes resource allocation imbalance and fault report data during historical operation. Output module: After processing and analyzing historical objective feature data, historical feature data, historical preprocessing requirement features, and current preprocessing requirement features, output resource allocation results.

[0014] Compared with the prior art, the present invention has the following beneficial effects: This invention categorizes demand dimensions by scene tags, identifies demand constraints, and quantifies influence weights. It distinguishes between core and auxiliary demands, transforming complex equipment requirements into standardized pre-processed demand features. This ensures resource allocation aligns with actual equipment operation scenarios, improving the accuracy and relevance of demand identification. By dynamically assessing access node switching based on cloud-edge collaborative resource data, it optimizes resource layout and transmission paths. When resource mismatches occur, it automatically compares the redundancy and link adaptability of adjacent nodes, effectively avoiding initial access node overload and link congestion. This enables dynamic optimization of access nodes. Based on access node switching data, it filters historical collaborative resource data and corrects current demand features using historical demand indicator errors. Furthermore, it incorporates historical resource allocation imbalance and fault report data, making current pre-processed demand features more closely match actual resource supply, reducing errors between resource allocation and actual equipment needs, and lowering the probability of resource waste and operational failures. This solution ensures both the rationality and feasibility of resource allocation and improves the scheduling efficiency and operational reliability of the industrial cloud platform IoT system. Attached Figure Description

[0015] Figure 1 This is a schematic diagram illustrating the steps of an IoT device resource allocation method for an industrial cloud platform according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a module for an IoT device resource allocation system on an industrial cloud platform, provided in an embodiment of the present invention. Detailed Implementation

[0016] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0017] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0018] Secondly, the term "an embodiment" or "embodiment" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the present invention. The phrase "in one embodiment" appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single embodiment or an embodiment selectively excluded from other embodiments.

[0019] Reference Figures 1-2 As shown.

[0020] The embodiments further illustrate the IoT device resource allocation method and system for an industrial cloud platform proposed in this invention.

[0021] A method for allocating IoT device resources on an industrial cloud platform, the method comprising the following steps: Obtain the target requirement information and access information of the IoT devices to be configured on the network. The target requirement information includes the device requirement type, and the access information includes the initial access node and the target transmission link. The first preprocessed requirement features are obtained by extracting features from the target requirement information; Extract cloud-edge collaborative resource data associated with the initial access node and the target transmission link, and determine the access node switching status of the IoT devices to be configured based on the cloud-edge collaborative resource data; Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics corresponding to the current switching status are obtained. Historical objective feature data, historical feature data, and historical preprocessing requirement features are extracted from historical distribution network feature data; among them, historical objective feature data includes resource allocation imbalance and fault report data during historical operation. The system processes and analyzes historical objective characteristic data, historical feature data, historical preprocessing requirement characteristics, and current preprocessing requirement characteristics, and then outputs resource allocation results.

[0022] The first preprocessed requirement features are obtained by extracting features from the target requirement information, specifically including the following steps: Obtain the device operation scenario tags corresponding to the target requirement information; Based on the equipment operation scenario tags, the target requirement information is divided into dimensions to obtain the target dimensions, and the requirement items of the target dimensions are extracted. Identify the constraints and priority adaptation conditions among the requirement items corresponding to different target dimensions, and clarify the influence weight of each constraint based on the constraints and priority adaptation conditions; Obtain the device operation scenario tags corresponding to the target requirement information. The device operation scenario tags are used to identify the specific application scenarios of IoT devices on the industrial cloud platform.

[0023] Based on the equipment operation scenario tags, the target requirement information is divided into dimensions to obtain the target dimensions and extract the requirement items for each target dimension. For example, in the production line data acquisition scenario, the target requirement information is divided into target dimensions such as data transmission dimension, calculation and processing dimension, storage and retrieval dimension, and stability assurance dimension, and the corresponding requirement items are extracted from each target dimension.

[0024] Identify the constraints and priority adaptation conditions among the corresponding requirements of different target dimensions, and determine the influence weight of each constraint accordingly. For example, the upper limit requirement for transmission latency in the data transmission dimension constrains the single data processing latency requirement in the computational processing dimension. If the transmission latency exceeds the upper limit, even if the processing latency meets the standard, the overall scenario requirements cannot be met. In this case, the influence weight of this constraint is set to 0.4. At the same time, data integrity requirement is a priority adaptation condition in this scenario, and its corresponding constraint influence weight is set to 0.6. A normalization method is used when calculating the weights: standardized influence weight = initial weight value of a constraint / sum of initial weight values ​​of all constraints.

[0025] The influence weights and requirement items are processed to obtain standardized requirement features. The effectiveness of these standardized requirement features is then validated to obtain the first preprocessed requirement features. Requirement items are tiered and filtered according to their influence weights, retaining high-priority core requirement items and categorizing and integrating low-priority auxiliary requirement items. A requirement feature mapping relationship is then constructed between core and auxiliary requirement items, converting core requirement items into basic requirement features and integrating auxiliary requirement items into extended requirement features. The basic and extended requirement features are time-series aligned to ensure consistent time scales across different features. Finally, the aligned basic and extended requirement features are fused to generate standardized requirement features. The standardized requirement features are then validated to ensure they meet the requirement threshold range corresponding to the scenario label. For example, it is verified whether the data transmission bandwidth requirement is within a reasonable bandwidth range for the production line acquisition scenario. If it does, the feature is confirmed as the first preprocessed requirement feature; otherwise, the process returns to the dimension partitioning stage for readjustment.

[0026] The standardized demand characteristics are obtained by processing the influencing weights and demand items, specifically including the following steps: The requirements are classified and filtered according to their impact weight, retaining high-priority core requirements and classifying and integrating low-priority auxiliary requirements. A requirement feature mapping relationship is constructed based on the integrated low-priority auxiliary requirement items and core requirement items; Based on the mapping relationship, core requirement items are converted into basic requirement features, and integrated auxiliary requirement items are converted into extended requirement features. Perform time-series alignment on the basic and extended requirement features; then merge the aligned basic and extended requirement features to generate standardized requirement features. The effectiveness of the standardized requirement features is verified to obtain the first preprocessed requirement features.

[0027] The requirements are categorized and filtered based on their impact weights, retaining high-priority core requirements while classifying and consolidating low-priority auxiliary requirements. First, a weight threshold is set, classifying requirements with an impact weight higher than the threshold as core requirements. Core requirements determine the core capabilities of equipment operation and scenario adaptability; for example, in a production line data acquisition scenario, requirements for data transmission latency limits and data integrity assurance are core requirements. Requirements with an impact weight lower than the threshold are classified as auxiliary requirements, further categorized according to their functional attributes. For example, requirements for data compression ratios and log storage cycles are classified as data management auxiliary requirements, while requirements for equipment status reporting frequency and alarm threshold adjustment are classified as equipment monitoring auxiliary requirements.

[0028] A requirement feature mapping relationship is constructed based on the integrated low-priority auxiliary requirement items and core requirement items. For example, the core requirement item is that the data transmission delay limit is no more than 10 milliseconds, and the corresponding auxiliary requirement item is mapped to a transmission link bandwidth reservation ratio of no less than 30% and a link retransmission count of no more than 2 times. The corresponding logic between core requirements and auxiliary requirements is established through the mapping relationship.

[0029] Based on the mapping relationship, core requirement items are converted into basic requirement characteristics, and integrated auxiliary requirement items are converted into extended requirement characteristics. Basic requirement characteristics are core indicators that the equipment must meet to operate. For example, the core requirement item of data transmission latency not exceeding 10 milliseconds is converted into a transmission latency characteristic with a value of 10 milliseconds. Extended requirement characteristics are a supplement and optimization of basic requirement characteristics.

[0030] The basic and extended demand features are time-aligned, and then fused to generate standardized demand features. Time alignment unifies the time scales of different features to the same granularity. Fusion uses a weighted summation method, combining basic and extended demand features according to their influence weights. The standardized demand feature value = basic demand feature value × core demand weight + extended demand feature value × auxiliary demand weight. When the transmission delay feature value is 10 milliseconds, the core demand weight is 0.7, the bandwidth reservation feature value is 30%, and the auxiliary demand weight is 0.3, the standardized demand feature value = 10 × 0.7 + 30 × 0.3 = 7 + 9 = 16.

[0031] The standardized requirement features are validated to obtain the first preprocessing requirement features. The validation process compares the standardized requirement features with preset threshold ranges for the scenario. For example, it checks whether the transmission latency corresponding to the standardized requirement feature meets the upper limit requirements of the production line acquisition scenario, and whether the bandwidth reservation ratio is within a reasonable range. If all features meet the threshold requirements, the standardized requirement feature is confirmed as the first preprocessing requirement feature. If any feature does not meet the threshold requirements, the process returns to the hierarchical screening stage, readjusting the priority and mapping relationship of the requirement items until validation is successful.

[0032] Extracting cloud-edge collaborative resource data associated with the initial access node and the target transmission link specifically includes the following steps: The associated scope of cloud-edge collaborative resources is determined based on the initial access node and the target transmission link; Collect cloud-based collaborative resource basic data of edge node resources within the associated range, and collect edge-side collaborative resource basic data between edge nodes through which the target transmission link passes. Among them, cloud-based collaborative resource basic data includes the resource occupancy, idle capacity, response efficiency, and stability of edge nodes; edge-side collaborative resource basic data includes the link transmission capacity, latency, and stability between edge nodes through which the target transmission link passes. By associating and integrating the basic data of collaborative resources on the edge side with the basic data of collaborative resources on the cloud side, cloud-edge collaborative resource data is obtained.

[0033] The associated scope of cloud-edge collaborative resources is determined based on the initial access node and the target transmission link. Taking the initial access node as the core, and combining the path of the target transmission link, the set of edge nodes and links that need to be included in the resource analysis is delineated. For example, if the initial access node is edge node A, and the target transmission link passes through edge nodes B and C, then the associated scope will cover the resources of edge nodes A, B, and C themselves, as well as the link resources between nodes A and B, and B and C. At the same time, it will be associated with the core resource pool of the corresponding scheduling edge nodes in the cloud to ensure complete coverage of the resource status of the entire path of device access and data transmission.

[0034] The system collects basic cloud-based collaborative resource data for edge nodes within the associated range, and simultaneously collects basic edge-side collaborative resource data between edge nodes along the target transmission link. The basic cloud-based collaborative resource data includes the resource occupancy, idle capacity, response efficiency, and stability of edge nodes. Resource occupancy represents the percentage of computing, storage, and bandwidth currently allocated to an edge node; for example, edge node A has a CPU resource occupancy of 65% and a storage resource occupancy of 72%. Idle capacity refers to the remaining amount of resources available for allocation to an edge node, calculated as: Total resource capacity of the edge node - Occupied resource capacity. For example, edge node A has a total storage capacity of 1000GB, with 720GB already occupied, resulting in an idle capacity of 280GB. Response efficiency is measured by the average latency of the edge node processing cloud scheduling commands; for example, edge node A has an average response latency of 15 milliseconds. Resource stability is characterized by the number of resource fluctuations or failures per unit time; for example, edge node A experiences 2 resource fluctuations per hour. The basic data of edge-side collaborative resources also includes the link transmission capacity, transmission delay, and transmission stability between each edge node along the target transmission link. The link transmission capacity refers to the maximum data transmission rate that the link can carry. For example, the link transmission capacity between node A and B is 100Mbps. The transmission delay refers to the average delay of data transmission in the link. For example, the average transmission delay of the link between node A and B is 8 milliseconds. The transmission stability is characterized by the link packet loss rate or the number of retransmissions per unit time. For example, the packet loss rate of the link between node A and B is 0.2% every 10 minutes.

[0035] The basic data of edge-side collaborative resources and cloud-side collaborative resources are linked and integrated to obtain cloud-edge collaborative resource data. The integration process takes the initial access node and the target transmission link as the main link, and binds the cloud-side collaborative resource data with the edge-side collaborative resource data of adjacent links in the target transmission link to form a complete mapping relationship between nodes, links, and resources. For example, the resource occupancy, idle capacity, response efficiency, and stability data of edge node A are linked with the transmission capacity, transmission delay, and transmission stability data of the link between nodes A and B, and then bound with the cloud-side collaborative resource data of edge node B, finally generating a cloud-edge collaborative resource dataset covering the entire target transmission path.

[0036] Determining the access node switching status of IoT devices to be configured on the cloud-edge collaborative resource data includes the following steps: The cloud-edge collaborative resource data is used to extract edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data corresponding to the initial access node. The resource supply capacity of the initial access node is obtained based on edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data. The cloud-edge collaborative resource data extracts edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data corresponding to the initial access node. Specifically, the edge node resource supply data includes the edge node's idle capacity, resource response efficiency, and resource stability, characterizing the resource support capabilities provided by the initial access node itself. The cloud platform core resource scheduling data includes the cloud's available computing, storage, and bandwidth resource quotas for the edge node, as well as the response latency of cloud scheduling commands, characterizing the cloud's resource support for the edge node. The target transmission link resource occupancy data includes the currently used transmission capacity percentage and remaining available bandwidth, characterizing the link's data transmission capacity potential after device access. The transmission stability data includes the link packet loss rate, retransmission count, and edge node resource fluctuation count, characterizing the reliability of resource supply under the current path.

[0037] The initial access node's resource supply capacity is determined based on edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data. The data across each dimension is standardized, and pre-defined weights are assigned to each dimension. Considering the priority requirements of the industrial scenario, edge node resource supply data is assigned a weight of 0.4, cloud platform core resource scheduling data a weight of 0.3, target transmission link resource occupancy data a weight of 0.2, and transmission stability data a weight of 0.1.

[0038] The initial access node's resource supply capacity is calculated as follows: Edge node resource supply standardization value × 0.4 + Cloud platform core resource scheduling standardization value × 0.3 + Target transmission link resource occupancy standardization value × 0.2 + Transmission stability standardization value × 0.1. For example, if an initial access node has an edge node resource supply standardization value of 0.8, a cloud platform core resource scheduling standardization value of 0.7, a target transmission link resource occupancy standardization value of 0.9, and a transmission stability standardization value of 0.85, then its resource supply capacity is calculated as: 0.8 × 0.4 + 0.7 × 0.3 + 0.9 × 0.2 + 0.85 × 0.1 = 0.795. The closer this value is to 1, the stronger the initial access node's resource supply capacity, and the better it matches the needs of the network-configured devices. A lower value indicates a weaker resource supply capacity, requiring consideration of switching access nodes.

[0039] The access node switching status of the IoT devices to be configured is obtained based on whether the resource supply capacity of the initial access node matches the target demand of the IoT devices to be configured. This includes the following steps: Determine whether the resource supply capacity of the initial access node matches the target requirements of the IoT devices to be networked. If the resource supply capacity of the initial access node can match the target needs of the IoT devices to be configured, then it is determined that there is no need to switch access nodes. If the resource supply capacity of the initial access node cannot match the target demand of the IoT devices to be distributed, the resource redundancy and transmission link adaptability of the adjacent access nodes are compared. Based on the resource redundancy of the adjacent access nodes, the transmission link adaptability, and the carrying limit of the target transmission link, the access node switching situation of the IoT devices to be distributed is determined.

[0040] Determine whether the resource supply capacity of the initial access node matches the target requirements of the IoT devices to be networked. Compare the resource supply capacity value of the initial access node with the threshold corresponding to the target requirements of the devices to be networked. For example, if the threshold is set to 0.75, if the calculated value of the resource supply capacity of the initial access node is 0.795, it is considered a match; if the calculated value of the resource supply capacity of the initial access node is 0.68, it is considered a mismatch.

[0041] If the resource supply capacity of the initial access node can match the target needs of the IoT devices to be configured, it is determined that there is no need to switch access nodes. The devices to be configured continue to complete network configuration and data transmission through the initial access node, thus avoiding the resource consumption and transmission interruption risks caused by unnecessary node switching.

[0042] If the resource supply capacity of the initial access node cannot match the target requirements of the IoT devices to be configured, a comparison of adjacent access nodes is performed. This involves traversing the physically or logically adjacent edge nodes of the initial access node, collecting resource redundancy and transmission link adaptability data for each adjacent access node. Resource redundancy is characterized by the proportion of idle capacity of adjacent nodes. Transmission link adaptability is characterized by the path overlap between adjacent nodes and the target transmission link, link transmission delay, and transmission stability indicators. The adjacent access node adaptability score = resource redundancy ratio × 0.5 + transmission link adaptability score × 0.3 + remaining capacity of the target transmission link. For example, if the initial access node's resource supply capacity is 0.68, its neighboring node B has a resource redundancy ratio of 0.45, a transmission link adaptability score of 0.82, and a target transmission link remaining capacity ratio of 0.6, then node B's adaptability score = 0.45 × 0.5 + 0.82 × 0.3 + 0.6 × 0.2 = 0.591; and its neighboring node C has a resource redundancy ratio of 0.62, a transmission link adaptability score of 0.78, and a target transmission link remaining capacity ratio of 0.75, then node C's adaptability score = 0.62 × 0.5 + 0.78 × 0.3 + 0.75 × 0.2 = 0.694.

[0043] The adjacent access node with the highest adaptation score that exceeds the required threshold will be selected as the switching target.

[0044] Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics corresponding to the current switching status are obtained, specifically including the following steps: Resource allocation information that matches historical collaborative resource data is filtered based on access node switching information; the resource allocation information includes resource supply parameters, resource scheduling response efficiency, and resource occupancy stability information. Basic feature information is obtained by associating and matching resource allocation information with the first preprocessing requirement features; An initial set of corrected features is obtained by correcting the basic feature information based on the historical demand index error. The initial set of corrected features is normalized to obtain the features required for current preprocessing.

[0045] Resource allocation information is filtered based on historical collaborative resource data matching access node switching status. First, the current access node switching status is identified. If it is determined that no switching is needed, resource allocation data from the same node and scenario in the past that did not involve switching is filtered. If it is determined that a switch to an adjacent node is required, resource allocation data from the same type of node switching scenario in the past is filtered. Resource allocation information includes resource supply parameters, resource scheduling response efficiency, and resource occupancy stability information. Resource supply parameters refer to the idle capacity and allocable bandwidth of edge nodes in historical scenarios. Resource scheduling response efficiency refers to the average response latency of the cloud sending scheduling commands to the corresponding node in the past. Resource occupancy stability information refers to the fluctuation range of the resource occupancy rate of the corresponding node and the frequency of failures in the past.

[0046] Basic feature information is obtained by associating and matching resource allocation information with the first preprocessing requirement features. Based on the requirement dimensions of the first preprocessing requirement features, the corresponding indicators of resource allocation information are bound to each requirement dimension. For example, the bandwidth idle ratio in the resource supply parameters is bound to the transmission bandwidth requirement in the requirement dimension; the resource scheduling response efficiency is bound to the real-time requirement in the requirement dimension; and the resource occupancy stability information is bound to the stability requirement in the requirement dimension. This generates basic feature information, which includes the core requirement quantification values ​​of the devices to be configured on the network and historical resource allocation reference values ​​for the same scenario.

[0047] An initial set of corrected features is obtained by correcting the basic feature information based on the historical demand index error. The historical demand index error refers to the deviation between the actual allocated resources and the equipment demand in the same historical scenario. Historical demand index error = historical actual allocated resource value - historical demand target value. The correction process uses this error as a correction factor to adjust the demand quantification value of the basic feature information. The corrected feature value = basic feature value - historical demand index error. If the basic feature value of a certain transmission bandwidth demand is 40Mbps, the actual allocated bandwidth in the same historical scenario is 35Mbps, and the demand target value is 38Mbps, then the historical demand index error = 35 - 38 = -3Mbps, and the corrected feature value = 40 - (-3) = 43Mbps. This corrects the demand feature and avoids the recurrence of historical allocation deviations.

[0048] The initial set of correction features is regularized to obtain the current preprocessing requirement features. During the regularization process, the units and magnitudes of all features are standardized. For example, latency features in milliseconds and bandwidth features in Mbps are converted into standardized values ​​between 0 and 1. Then, the feature values ​​are deduplicated and outlier filtered to remove extreme values ​​that deviate significantly from the threshold of the scenario requirements. Finally, the current preprocessing requirement features that are adapted to the current access node switching situation are generated.

[0049] After processing and analyzing historical objective feature data, historical feature data, historical preprocessing requirement features, and current preprocessing requirement features, the resource allocation results are output, specifically including the following steps: The comparison results are obtained by comparing the historical preprocessing requirements with the current preprocessing requirements. Based on the comparison results, historical objective characteristic data, and historical characteristic data, we can identify resource allocation problems and solutions in the historical power distribution network process. The resource allocation results are obtained by analyzing cloud-edge collaborative resource data, resource allocation issues, solutions, and current preprocessing requirements. Specifically, this includes the following steps: Based on cloud-edge collaborative resource data, resource allocation issues and solutions, a resource adjustment and allocation scheme is obtained by adapting and adjusting the resource requirements according to the current preprocessing needs. The resource allocation plan is verified based on the access node switching situation to obtain the resource allocation result.

[0050] The comparison results are obtained by comparing historical preprocessing requirement features with current preprocessing requirement features. The comparison is broken down into requirement dimensions, numerical magnitudes, and temporal characteristics. At the requirement dimension level, the comparison examines whether the scenario types and core requirement items of historical and current requirements are consistent. At the numerical magnitude level, the difference between each requirement feature is calculated: requirement feature difference = current preprocessing requirement feature value - historical preprocessing requirement feature value. At the temporal characteristic level, the comparison examines whether the effective periods and fluctuation patterns of the requirements match. Finally, a comparison result is generated that includes requirement similarity, difference magnitude, and temporal matching degree. For example, in a certain production line data acquisition scenario, the similarity between current and historical requirements is 0.85, the bandwidth requirement difference is 5Mbps, and the temporal matching degree is 0.9.

[0051] Based on the comparison results, historical objective feature data, and historical feature data, resource allocation problems and solutions in historical distribution network processes are obtained. Historical objective feature data includes resource allocation imbalance reports and fault reports from historical operation processes. Historical feature data includes node resource status and link performance information from historical distribution network scenarios. Combined with demand comparison results, resource allocation problems in historical scenarios similar to current demands are located, such as insufficient bandwidth leading to excessive transmission latency. Historical solutions to these problems are extracted, such as increasing link bandwidth quotas, switching to adjacent nodes with higher resource redundancy, and adjusting resource scheduling cycles.

[0052] By analyzing cloud-edge collaborative resource data, resource allocation issues, solutions, and current preprocessing requirements, a resource allocation result is obtained. Based on this data, the resource requirements are adjusted to better suit the current preprocessing needs, resulting in a resource adjustment and allocation scheme. This adjustment is based on the current preprocessing requirements, combined with the actual available resource capacity from the cloud-edge collaborative resource data, and references historical issues and solutions to reasonably scale the requirements. For example, if the current bandwidth requirement is 45Mbps, and the cloud-edge collaborative resource data shows a remaining link bandwidth of 40Mbps, and historically similar scenarios have shown link congestion due to bandwidth over-allocation, the solution is to reduce the requirement to 90% of the available bandwidth. Therefore, the adjusted allocated bandwidth would be 40 × 0.9 = 36Mbps, thus forming the resource adjustment and allocation scheme.

[0053] The resource allocation plan is validated based on the access node switching status to obtain the resource allocation result. The validation process verifies whether the plan is suitable for the current access node status. If no node switching is needed, the plan is verified to be within the resource supply capacity of the initial access node. If node switching is required, the plan is verified to be within the resource redundancy range of the target switching node, and the link capacity limit is also verified to meet the plan requirements. If the validation passes, the resource allocation plan is determined as the final resource allocation result. If the validation fails, the process returns to the adaptation and adjustment stage, re-optimizing the plan by combining cloud-edge collaborative resource data with historical solutions until the validation passes, and finally outputting the resource allocation result.

[0054] An IoT device resource allocation system for an industrial cloud platform includes: Acquisition module: Acquires target requirement information and access information of IoT devices to be configured on the network. The target requirement information includes the device requirement type, and the access information includes the initial access node and the target transmission link. First extraction module: Extracts features from the target requirement information to obtain the first preprocessed requirement features; Judgment module: Extracts cloud-edge collaborative resource data associated with the initial access node and the target transmission link, and judges the access node switching status of the IoT device to be configured based on the cloud-edge collaborative resource data; Processing module: Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics are obtained to correspond to the current switching status. The second extraction module extracts historical objective feature data, historical feature data, and historical preprocessing requirement features from historical distribution network feature data; among them, historical objective feature data includes resource allocation imbalance and fault report data during historical operation. Output module: After processing and analyzing historical objective feature data, historical feature data, historical preprocessing requirement features, and current preprocessing requirement features, output resource allocation results.

[0055] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0056] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0057] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. An industrial cloud platform's IoT device resource allocation method, characterized by, The method includes the following steps: Obtain the target requirement information and access information of the IoT devices to be configured on the network, wherein the target requirement information includes the device requirement type, and the access information includes the initial access node and the target transmission link; The first preprocessed requirement features are obtained by extracting features from the target requirement information; Extract cloud-edge collaborative resource data associated with the initial access node and the target transmission link, and determine the access node switching status of the IoT devices to be configured based on the cloud-edge collaborative resource data; Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics corresponding to the current switching status are obtained. Historical objective feature data, historical feature data, and historical preprocessing requirement features are extracted from historical distribution network feature data; wherein, the historical objective feature data includes resource allocation imbalance and fault report data during historical operation. The system processes and analyzes historical objective characteristic data, historical feature data, historical preprocessing requirement characteristics, and current preprocessing requirement characteristics, and then outputs resource allocation results.

2. The method for allocating IoT device resources on an industrial cloud platform according to claim 1, characterized in that, The first preprocessed requirement features are obtained by extracting features from the target requirement information, specifically including the following steps: Obtain the device operation scenario tags corresponding to the target requirement information; Based on the equipment operation scenario tags, the target requirement information is divided into dimensions to obtain the target dimensions, and the requirement items of the target dimensions are extracted. Identify the constraints and priority adaptation conditions among the requirement items corresponding to different target dimensions, and clarify the influence weight of each constraint based on the constraints and priority adaptation conditions; The standardized demand characteristics are obtained by processing the influence weights and demand items; The effectiveness of the standardized requirement features is verified to obtain the first preprocessed requirement features.

3. The method for allocating IoT device resources on an industrial cloud platform according to claim 2, characterized in that, The standardized demand characteristics are obtained by processing the influencing weights and demand items, specifically including the following steps: The requirements are classified and filtered according to their impact weight, retaining high-priority core requirements and classifying and integrating low-priority auxiliary requirements. A requirement feature mapping relationship is constructed based on the integrated low-priority auxiliary requirement items and core requirement items; Based on the mapping relationship, core requirement items are converted into basic requirement features, and integrated auxiliary requirement items are converted into extended requirement features. The basic and extended requirement features are aligned according to time sequence; the aligned basic and extended requirement features are then merged to generate standardized requirement features.

4. The method for allocating IoT device resources on an industrial cloud platform according to claim 1, characterized in that, Extracting cloud-edge collaborative resource data associated with the initial access node and the target transmission link specifically includes the following steps: The associated scope of cloud-edge collaborative resources is determined based on the initial access node and the target transmission link; Collect cloud-based collaborative resource basic data of edge node resources within the associated range, and collect edge-side collaborative resource basic data between edge nodes through which the target transmission link passes; wherein, the cloud-based collaborative resource basic data includes the resource occupancy, idle capacity, response efficiency, and stability of edge nodes; the edge-side collaborative resource basic data includes the link transmission capacity, transmission delay, and stability between edge nodes through which the target transmission link passes. By associating and integrating the basic data of collaborative resources on the edge side with the basic data of collaborative resources on the cloud side, cloud-edge collaborative resource data is obtained.

5. The method for allocating IoT device resources on an industrial cloud platform according to claim 1, characterized in that, Determining the access node switching status of IoT devices to be configured on the cloud-edge collaborative resource data includes the following steps: The following data are extracted from the cloud-edge collaborative resource data: edge node resource supply data corresponding to the initial access node, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data. The resource supply capacity of the initial access node is obtained based on edge node resource supply data, cloud platform core resource scheduling data, target transmission link resource occupancy data, and transmission stability data. The switching status of access nodes for IoT devices in the network to be distributed is obtained based on whether the resource supply capacity of the initial access node matches the target demand of the IoT devices in the network to be distributed.

6. The method for allocating IoT device resources on an industrial cloud platform according to claim 5, characterized in that, The access node switching status of the IoT devices to be configured is obtained based on whether the resource supply capacity of the initial access node matches the target demand of the IoT devices to be configured. This includes the following steps: Determine whether the resource supply capacity of the initial access node matches the target requirements of the IoT devices to be networked. If the resource supply capacity of the initial access node can match the target needs of the IoT devices to be configured, then it is determined that there is no need to switch access nodes. If the resource supply capacity of the initial access node cannot match the target demand of the IoT devices to be distributed, the resource redundancy and transmission link adaptability of the adjacent access nodes are compared. Based on the resource redundancy of the adjacent access nodes, the transmission link adaptability, and the carrying limit of the target transmission link, the access node switching situation of the IoT devices to be distributed is determined.

7. The method for allocating IoT device resources on an industrial cloud platform according to claim 1, characterized in that, Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics corresponding to the current switching status are obtained, specifically including the following steps: Resource allocation information that matches historical collaborative resource data is filtered based on access node switching information; wherein, the resource allocation information includes resource supply parameters, resource scheduling response efficiency, and resource occupancy stability information; Basic feature information is obtained by associating and matching resource allocation information with the first preprocessing requirement features; An initial set of corrected features is obtained by correcting the basic feature information based on the historical demand index error. The initial set of corrected features is normalized to obtain the features required for current preprocessing.

8. The method for allocating IoT device resources on an industrial cloud platform according to claim 1, characterized in that, After processing and analyzing historical objective feature data, historical feature data, historical preprocessing requirement features, and current preprocessing requirement features, the resource allocation results are output, specifically including the following steps: The comparison results are obtained by comparing the historical preprocessing requirements with the current preprocessing requirements. Based on the comparison results, historical objective characteristic data, and historical characteristic data, we can identify resource allocation problems and solutions in the historical power distribution network process. The resource allocation results are obtained by analyzing cloud-edge collaborative resource data, resource allocation issues, solutions, and current preprocessing requirements.

9. The method for allocating IoT device resources on an industrial cloud platform according to claim 8, characterized in that, The resource allocation results are obtained by analyzing cloud-edge collaborative resource data, resource allocation issues, solutions, and current preprocessing requirements. Specifically, this includes the following steps: Based on cloud-edge collaborative resource data, resource allocation issues and solutions, a resource adjustment and allocation scheme is obtained by adapting and adjusting the resource requirements according to the current preprocessing needs. The resource allocation plan is verified based on the access node switching situation to obtain the resource allocation result.

10. An IoT device resource allocation system for an industrial cloud platform, applied to the IoT device resource allocation method for an industrial cloud platform as described in any one of claims 1 to 9, characterized in that, include: Acquisition module: Acquires target requirement information and access information of IoT devices to be configured on the network, wherein the target requirement information includes the device requirement type, and the access information includes the initial access node and the target transmission link; First extraction module: Extracts features from the target requirement information to obtain the first preprocessed requirement features; Judgment module: Extracts cloud-edge collaborative resource data associated with the initial access node and the target transmission link, and judges the access node switching status of the IoT device to be configured based on the cloud-edge collaborative resource data; Processing module: Based on the access node switching status, historical collaborative resource data, historical demand index errors, and the first preprocessing demand characteristics, the current preprocessing demand characteristics are obtained to correspond to the current switching status. The second extraction module extracts historical objective feature data, historical feature data, and historical preprocessing requirement features from historical distribution network feature data; wherein, the historical objective feature data includes resource allocation imbalance and fault report data during historical operation. Output module: After processing and analyzing historical objective feature data, historical feature data, historical preprocessing requirement features, and current preprocessing requirement features, output resource allocation results.

Images