Community wisdom operation resource monitoring and scheduling method and system based on open source honkong

Abstract

The application relates to the technical field of community wisdom operation, and particularly provides a community wisdom operation resource monitoring and scheduling method and system based on open-source Hongmeng, which comprises the following steps: constructing multiple types of resource nodes of community wisdom operation, completing networking communication and adaptation of the resource nodes based on open-source Hongmeng; collecting running state data of all types of resource nodes in real time and performing standardized processing; constructing a double-level intelligent scheduling model, generating a resource scheduling strategy through scheduling priority judgment and supply-demand matching analysis; training and optimizing the scheduling model, reasoning and outputting scheduling instructions based on the processed running data, and realizing self-adaptive monitoring and scheduling of community operation resources. The application can improve the utilization rate of community resources and the efficiency of emergency response, and meet the efficient, refined and intelligent operation and management requirements of modern communities.

Description

Technical Field

[0001] This invention relates to the field of smart community operation technology, specifically to a method and system for monitoring and scheduling smart community operation resources based on the open-source HarmonyOS. Background Technology

[0002] With the continuous advancement of smart and digital construction in urban communities, the number of IoT terminal devices for security monitoring, equipment management, and public services within communities is rapidly increasing. These devices are exhibiting diverse characteristics in terms of type, communication protocols, and functional interfaces, placing higher demands on the unified access, efficient scheduling, and intelligent operation of resources across the entire community. Achieving centralized management, data exchange, and dynamic scheduling of community devices based on a unified platform has become a core direction for improving community operational efficiency and optimizing service quality.

[0003] Existing community resource scheduling solutions mostly employ a combination of fixed rules and manual assistance, which generally suffers from poor device compatibility, inconsistent data parsing, and delayed scheduling decisions, making it difficult to achieve real-time linkage and intelligent matching across multiple devices and scenarios. Furthermore, existing technical solutions cannot dynamically adjust scheduling strategies based on the community's real-time operational status, and struggle to achieve unified access for heterogeneous devices and standardized parsing of data across the entire domain. This results in insufficient flexibility and adaptability in resource scheduling, low resource utilization, and slow emergency response, failing to meet the efficient and intelligent operation and management needs of modern communities.

[0004] To address these issues, this invention provides a community intelligent operation resource monitoring and scheduling method and system based on the open-source HarmonyOS. Summary of the Invention

[0005] To overcome the shortcomings of existing technologies, this invention provides a community intelligent operation resource monitoring and scheduling method and system based on open-source HarmonyOS, in order to solve the problems in existing technologies.

[0006] One embodiment of the present invention provides a community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS, comprising the following steps: S10. According to the preset type classification rules and device attributes, the heterogeneous IoT devices in the community are classified, and the same type of devices are grouped into the same resource node to form multiple different resource nodes. S20: Based on the open-source HarmonyOS distributed interconnection technology, interconnect and network various resource nodes to build a community-wide device interconnection network; S30. Collect resource status data corresponding to each resource node in real time and perform data preprocessing to obtain a standardized resource status dataset with resource nodes as the dimension. S40. Extract resource supply characteristics, resource demand characteristics, and abnormal status characteristics from the resource status dataset, and input them into the pre-built resource scheduling model for scheduling priority determination and supply-demand matching analysis, and generate a resource scheduling strategy that matches the real-time operation status of the community. The scheduling priority is dynamically set based on the community's smart operation goals. S50. Generate corresponding scheduling instructions based on the resource scheduling strategy, and send the scheduling instructions to the corresponding resource nodes through the open-source HarmonyOS distributed interconnection technology, so that each resource node can perform the corresponding scheduling operation.

[0007] This application also relates to a community intelligent operation resource monitoring and scheduling system based on the open-source HarmonyOS, including: The partitioning module is used to partition heterogeneous IoT devices in the community according to preset type partitioning rules and device attributes, and to group devices of the same type into the same resource node to form multiple different resource nodes; The module is used to interconnect and network various resource nodes based on the open-source HarmonyOS distributed interconnection technology, and build a community-wide device interconnection network. The acquisition module is used to collect resource status data corresponding to each resource node in real time and perform data preprocessing to obtain a standardized resource status dataset with resource nodes as the dimension. The strategy generation module is used to extract resource supply characteristics, resource demand characteristics and abnormal state characteristics from the resource status dataset, and input them into the pre-built resource scheduling model for scheduling priority determination and supply and demand matching analysis, and generate a resource scheduling strategy that matches the real-time operation status of the community. The scheduling priority is dynamically set based on the community's smart operation goals. The scheduling execution module is used to generate corresponding scheduling instructions based on the resource scheduling strategy, and to send the scheduling instructions to the corresponding resource nodes through the open-source HarmonyOS distributed interconnection technology, so that each resource node can perform the corresponding scheduling operation.

[0008] This application also relates to a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS.

[0009] This application also relates to a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS.

[0010] The community intelligent operation resource monitoring and scheduling method and system based on open-source HarmonyOS provided in the above embodiments have the following beneficial effects: By sequentially completing the standardized construction and unique identifier allocation of community resource nodes, node identity verification and type domain division, distributed networking and priority scheduling mechanism construction, standardized data collection and parsing, and dynamic scheduling process based on intelligent scheduling model, this solution effectively solves the technical problems of poor device access compatibility, inability to uniformly parse data, delayed scheduling decisions, and insufficient dynamic adaptive capabilities in existing community scheduling solutions. It enables unified access of heterogeneous devices, standardized parsing of data across the entire domain, and dynamic adjustment of scheduling strategies, significantly improving the utilization rate of community resources and the efficiency of emergency response, and meeting the needs of modern communities for efficient, refined, and intelligent operation and management. Attached Figure Description

[0011] Figure 1 A flowchart illustrating a community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS, provided as an embodiment of the present invention; Figure 2 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0012] The technical solutions in the embodiments of the present invention will now be clearly and completely described in conjunction with the accompanying drawings.

[0013] Reference Figure 1 One embodiment of the present invention provides a community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS, including the following steps: S10. According to the preset type classification rules and device attributes, the heterogeneous IoT devices in the community are classified, and the same type of devices are grouped into the same resource node to form multiple different resource nodes. S20: Based on the open-source HarmonyOS distributed interconnection technology, interconnect and network various resource nodes to build a community-wide device interconnection network; S30. Collect resource status data corresponding to each resource node in real time and perform data preprocessing to obtain a standardized resource status dataset with resource nodes as the dimension. S40. Extract resource supply characteristics, resource demand characteristics, and abnormal status characteristics from the resource status dataset, and input them into the pre-built resource scheduling model for scheduling priority determination and supply-demand matching analysis, and generate a resource scheduling strategy that matches the real-time operation status of the community. The scheduling priority is dynamically set based on the community's smart operation goals. S50. Generate corresponding scheduling instructions based on the resource scheduling strategy, and send the scheduling instructions to the corresponding resource nodes through the open-source HarmonyOS distributed interconnection technology, so that each resource node can perform the corresponding scheduling operation.

[0014] In this embodiment, step S10 is the basic equipment organization and resource node construction step for community smart operation resource monitoring and scheduling. The core is to standardize and aggregate various smart networked devices within the community based on unified rules, forming the smallest management unit for subsequent full-domain networking, data collection, and intelligent scheduling. The specific implementation logic is as follows: The classification is based on a preset type division rule, which predefines multiple resource node types and uniformly uses device function type, device communication adaptation, and community operation priority dimensions for division. Different resource node types correspond to different matching standards to ensure the consistency and standardization of device classification across the entire community. The classification is also based on the device's own attributes, which are inherent characteristics used to match the above three division dimensions and are the core parameters for determining the device's category.

[0015] The heterogeneous IoT devices addressed in this step refer to smart IoT devices of different types, functions, communication methods, and applications within a community setting. Specifically, these include low-cost sensing devices (such as community security cameras and millimeter-wave radar), edge computing units, community smart monitoring robots, smart wearable devices for staff, and conventional community operation IoT devices (such as community lighting, environmental monitoring, and security alarm equipment). These devices differ in function, communication protocols, and execution capabilities, forming the basis of the heterogeneous device structure in this solution.

[0016] This step first collects the device attributes of various heterogeneous IoT devices and matches these attributes with preset type classification rules to determine the resource node to which the device belongs. If a device is compatible with only a single resource node type, it is directly assigned to the corresponding resource node. If a device is compatible with multiple resource node types, it is assigned to the highest priority resource node type based on the dynamic weight of the community operation priority dimension in the rules. Finally, a unique identifier and type label are assigned to each resource node, forming multiple different resource nodes. Each resource node serves as a holistic resource management unit, eliminating management and scheduling obstacles caused by device heterogeneity and providing a standardized resource carrier for subsequent steps.

[0017] Step S20 involves constructing a comprehensive network for community smart operation resource monitoring and scheduling. Its core is based on open-source HarmonyOS distributed interconnection technology, which unifies and integrates the resource nodes built in Step S10, creating an integrated communication and scheduling network covering all scenarios and devices within the community. This provides underlying network support for subsequent data collection, intelligent scheduling, and command issuance. The specific implementation logic is as follows: The interconnection and networking objects in this step are all the community resource nodes formed by classification and grouping in step S10, specifically including device sensing nodes, edge computing unit nodes, robot duty nodes, smart wearable device nodes, and community operation IoT device nodes, so as to realize the network access of all types of resource nodes without discrimination.

[0018] The open-source HarmonyOS distributed interconnection technology is a distributed interconnection and interoperability technology for heterogeneous IoT devices. It can shield the differences in communication protocols between different devices and resource nodes, realize seamless connection and global interconnection of multiple types of smart devices, and adapt to the networking needs of heterogeneous resource nodes within the community.

[0019] By performing unified interconnection and networking operations on the aforementioned resource nodes, communication silos between independent resource nodes are broken down, and scattered device resources are integrated into a unified network collaboration system. After network integration, a community-wide device interconnection network is constructed. This network serves as the underlying communication foundation for smart community operations, ensuring stable data transmission, status interaction, and command coordination among resource nodes.

[0020] Step S30 involves data collection and standardized processing for community smart operation resource monitoring and scheduling. Its core is the real-time acquisition of operational and status information of each resource node within the community's interconnected network of devices. Standardized preprocessing eliminates the disorder and inconsistencies of the raw data, forming a unified and usable dataset. The specific implementation logic is as follows: The data collected in this step are the resource nodes constructed in step S10, including device sensing nodes, edge computing unit nodes, robot monitoring nodes, smart wearable device nodes, and community operation IoT device nodes. The collected resource status data are the real-time operation, sensing and monitoring, function execution, and abnormal alarm data generated by each resource node during community operation.

[0021] The collected raw resource status data undergoes preprocessing, which involves standardizing the data, removing invalid information, and unifying the data format to ensure its validity and standardization. After real-time collection and preprocessing, a standardized resource status dataset is formed, using a single resource node as the smallest statistical dimension. This dataset carries the status information of all resource nodes in the entire community in a unified format.

[0022] Step S40 is the core intelligent analysis and strategy generation step for community smart operation resource monitoring and scheduling. Its core is based on standardized data, extracting key scheduling features and using intelligent models to complete analysis and decision-making, generating a scheduling plan that meets the real-time operational needs of the community. The specific implementation logic is as follows: Based on the standardized resource status dataset formed in step S30, core feature extraction is performed on the status data of device sensing nodes, edge computing unit nodes, robot duty nodes, smart wearable device nodes, and community operation IoT device nodes. Three types of core scheduling features are extracted from the dataset: resource supply features, resource demand features, and abnormal status features, which serve as key inputs for intelligent analysis.

[0023] The three types of features mentioned above are input into a pre-built resource scheduling model. The model is then used to determine scheduling priorities and perform supply and demand matching analysis. The scheduling priorities are dynamically set according to the community's smart operation goals to ensure that scheduling decisions are adapted to the actual operational needs of the community.

[0024] After model analysis and decision-making, a resource scheduling strategy matching the real-time operational status of the community is generated. This strategy is targeted and real-time, and can support the subsequent scheduling and collaborative execution of various resource nodes.

[0025] In this embodiment, step S50 is the instruction issuance and scheduling execution step for community smart operation resource monitoring and scheduling. The core is to transform the resource scheduling strategy generated by intelligent analysis into executable instructions, issue them to the target node through the underlying distributed network, and complete the scheduling implementation, thus achieving closed-loop execution of the entire community resource monitoring and scheduling process. The specific implementation logic is as follows: Based on the resource scheduling strategy generated in step S40, standardized scheduling instructions adapted to each resource node are generated according to the strategy content, ensuring that the instructions can be recognized and executed by the target nodes. Utilizing the stable communication and full-domain coverage capabilities of the open-source HarmonyOS distributed interconnection technology, the scheduling instructions are distributed to the corresponding device sensing nodes, edge computing unit nodes, robot monitoring nodes, smart wearable device nodes, and community operation IoT device nodes according to the corresponding resource scheduling strategy.

[0026] After receiving the scheduling instruction, each target resource node executes the corresponding scheduling operation according to the instruction requirements, realizing the coordinated response and efficient scheduling of resources across the entire community, and completing the closed loop of the entire process from data collection and intelligent analysis to instruction execution.

[0027] In one feasible embodiment, it is assumed that a large-scale integrated commercial and residential smart community fully deploys the community smart operation resource monitoring and scheduling method based on the open-source HarmonyOS of this invention. The community covers key areas such as entrances and exits, the central garden, the waterfront leisure area, pedestrian walkways, and the underground parking garage. A full range of heterogeneous IoT devices have been deployed, specifically including: low-cost security cameras and millimeter-wave radar deployed in key risk areas; edge computing units deployed in the community's server room; intelligent guard robots deployed at three fixed standby points at the community gate, the central garden, and the waterfront area; smart wearable bracelets and smart glasses provided to community security and maintenance personnel; and conventional community operation IoT devices such as public lighting, environmental monitoring, security alarms, and emergency broadcasting. Based on the scheduling method of this embodiment, the complete and detailed process for the community to achieve full-area smart operation resource monitoring and scheduling is as follows: First, execute step S10. According to the preset classification rules and attributes such as device function, communication adaptation, and operation priority, standardize and classify all heterogeneous IoT devices in the community. Low-cost cameras and millimeter-wave radars are uniformly classified into device sensing nodes, edge computing units are separately classified into edge computing unit nodes, three fixed-point guarding robots are classified into robot guarding nodes, smart wearable devices for security and maintenance personnel are classified into smart wearable device nodes, and public lighting, environmental monitoring and other devices are classified into community operation IoT device nodes. A unique identity identifier and type label are assigned to each type of resource node, completing the organization and management unit construction of all smart devices in the community. Then, step S20 is executed. Through core interconnection technologies such as open-source HarmonyOS distributed soft bus and distributed device virtualization, the device sensing nodes, edge computing unit nodes, robot duty nodes, and smart wearable device nodes (i.e., community operation IoT device nodes) built in step S10 are interconnected and networked in the whole domain. This shields the differences in communication protocols and data formats between different devices, breaks down the communication islands between devices, and builds a community-wide device interconnection network covering the entire area and all devices in the community, providing underlying network support for data transmission, command interaction, and collaborative scheduling. Next, step S30 is executed. Utilizing the existing interconnected network of devices across the entire community, resource status data of each node is collected in real time, with a single resource node as the smallest dimension. This includes collecting video footage and radar monitoring data from device sensing nodes, computing load and operational status data from edge computing unit nodes, standby location, battery level, and executable status data from robot monitoring nodes, online and location data from smart wearable device nodes, and lighting brightness, ambient temperature and humidity, and alarm status data from community operation IoT device nodes. The collected raw data undergoes preprocessing such as cleaning, deduplication, and format standardization to remove invalid and redundant data, ultimately forming a standardized resource status dataset with each resource node as the dimension. Then, step S40 is executed. Based on the standardized resource status dataset, the resource supply characteristics, resource demand characteristics, and abnormal state characteristics of each resource node are extracted hierarchically. Among them, the resource supply characteristics include the monitoring capabilities of sensing devices, the available computing power of edge units, and the standby status of robots. The resource demand characteristics include the security patrol needs of various areas of the community, the environmental monitoring needs, and the computing power support needs. The abnormal state characteristics include personnel entering water-restricted areas, personnel falling abnormally, smoke alarms, and equipment offline failures triggered by sensing devices. The extracted features are input into the pre-built resource scheduling model. Combined with the smart operation goal of "security first, emergency response first" of the community, the scheduling priority of each resource node and each event is dynamically determined. The resource corresponding to the device sensing node, edge computing unit node, and robot duty node is checked for supply and demand within the same type of domain and analyzed for cross-type domain collaborative allocation. A resource scheduling strategy matching the real-time operation status of the community is generated, which clarifies the device nodes to be scheduled, the scheduling order, the execution actions, and the collaboration methods. Finally, step S50 is executed, generating standardized executable scheduling instructions based on the resource scheduling strategy and distributing these instructions to the corresponding target resource nodes via the open-source HarmonyOS distributed interconnection network. For example, when a device sensing node detects someone entering a restricted area near water in a community, it sends an enhanced monitoring instruction to the device sensing node according to the scheduling strategy. Upon receiving the instruction, the device sensing node sends continuous tracking and zoom-in locking instructions to the corresponding low-cost security cameras and millimeter-wave radar devices within that node to perform uninterrupted monitoring of key areas. When a device sensing node detects someone abnormally falling in a public area of ​​the community, it sends emergency response instructions to robot monitoring nodes and smart wearable device nodes. Upon receiving the instruction, the robot monitoring node sends instructions to the nearest monitoring robot device within that node to rush to the scene, verify the video, and issue audible and visual warnings. Upon receiving the instruction, the smart wearable device node sends alarm push notifications and location guidance instructions to the smart wearable wristbands and smart glasses devices of the corresponding security personnel within that node to perform on-site handling and human-assisted operations. When a sensing node detects abnormal smoke in a no-smoking area of ​​the community, it sends a coordinated response command to the edge computing unit node and the community operation IoT device node. Upon receiving the command, the edge computing unit node sends a priority computing power allocation and high-speed data processing command to the corresponding edge computing unit device within the node. Upon receiving the command, the community operation IoT device node sends a voice reminder and brightness enhancement command to the corresponding emergency broadcast and public lighting equipment within the node to perform safety warnings and environmental linkage operations. When an edge computing unit node detects that any device in the community is offline or in an abnormal state, it sends a fault investigation command to the smart wearable device node. Upon receiving the command, the smart wearable device node sends a fault location and device information push command to the smart wearable bracelets and smart glasses of the corresponding maintenance personnel within the node to perform device maintenance operations.

[0028] After receiving the instruction, each target resource node synchronously executes the corresponding scheduling operation, realizing the coordinated response of community sensing, edge computing, robots, wearable devices, and conventional devices, and completing the closed loop of the entire process of community smart operation resource monitoring and scheduling from device classification, network networking, data collection, intelligent analysis to instruction execution.

[0029] It should be noted that the community smart operation scenarios listed above are merely illustrative examples of one feasible embodiment of the present invention, intended to enable those skilled in the art to more intuitively and clearly understand the technical solution of the present invention, and are not intended to limit the scope of protection of the present invention. The community smart operation resource monitoring and scheduling method based on open-source HarmonyOS described in this invention can also be applied to other operation scenarios within the community (such as equipment operation and maintenance scheduling, environmental control scheduling, emergency rescue scheduling, etc.). Any technical solution obtained by adopting equivalent substitution or equivalent transformation based on the core concept of this invention should fall within the scope of protection of this invention.

[0030] In one embodiment, step S10 specifically includes: S11. Collect the device attributes of each heterogeneous IoT device in the community according to the division dimensions of the preset type division rules. S12. Match the collected device attributes of each heterogeneous IoT device with the preset type classification rules to determine the resource node to which each heterogeneous IoT device belongs; S13. If the device attributes match a certain resource node type defined by the preset type classification rules, then the IoT device is classified into the resource node corresponding to that resource node type. S14. If the device attributes match the multiple resource node types defined by the preset type classification rules, then the IoT device is classified into the resource node corresponding to the highest priority resource node type based on the dynamic weight in the preset type classification rules. S15. Assign a unique identifier and type label to each type of resource node to form multiple different resource nodes.

[0031] In this embodiment, step S11 specifically involves: using the device function type dimension, device communication adaptation dimension, and community operation priority dimension set in the preset type classification rules as the collection guide, and collecting device attributes of all heterogeneous IoT devices in the community according to the attribute requirements corresponding to the above classification dimensions. The collected device attributes are adapted to the classified dimensions, specifically covering the inherent attribute information of each heterogeneous IoT device, such as the actual function type, communication protocol and communication capability, and priority positioning in the community operation scenario. The collection objects cover various IoT devices corresponding to device sensing nodes, edge computing unit nodes, robot guarding nodes, smart wearable device nodes, and community operation IoT device nodes, such as the low-cost security cameras, millimeter-wave radar, edge computing units, smart guarding robots, smart wearable bracelets and smart glasses for security and maintenance personnel, public lighting equipment, environmental monitoring equipment, security alarm equipment, and emergency broadcasting equipment deployed in the community in the above embodiment.

[0032] By collecting and classifying device attributes in a targeted manner to match the dimensions, we can ensure that the subsequent device ownership determination process is based on evidence and guarantee the accuracy and standardization of matching device and resource node types.

[0033] Step S12 specifically involves: using the attributes of each heterogeneous IoT device collected in step S11 as the matching basis, and using the device function type dimension, device communication adaptation dimension, and community operation priority dimension set in the preset type classification rules as the matching standards, performing a matching operation between attributes and rules. During the matching process, each device compares and verifies its actual function type, communication protocol and capabilities, operation priority positioning, and other attributes with the classification dimension standards corresponding to each resource node type. Through multi-dimensional cross-validation, the compatibility relationship between the device and the resource node type is determined, thereby determining the target resource node to which the device belongs. The matching objects cover all heterogeneous IoT devices in the community, such as low-cost security cameras, millimeter-wave radar, edge computing units, intelligent guard robots, intelligent wearable devices, and various conventional community operation IoT devices mentioned in the above embodiments, ensuring that each device can be matched to the corresponding resource node.

[0034] Step S13 specifically involves the following: This step is performed on the premise that, after the matching determination in step S12, it is confirmed that the attributes of a heterogeneous IoT device are fully compatible with only one type of resource node defined by the preset type classification rules, and there is no multi-type compatibility. When the above compatibility condition is met, according to the correspondence principle of "attribute compatibility → node inclusion," the IoT device is directly included in the resource node corresponding to the resource node type that matches its attributes, thus achieving the corresponding binding between the device and the resource node.

[0035] This step applies to all heterogeneous IoT devices that are determined to be single-adapted. For example, in the above embodiment, when it is determined that a low-cost security camera or millimeter-wave radar only has sensing and monitoring functions and meets the sensing communication adaptation standard, it is assigned to the corresponding device sensing node; when it is determined that an edge computing unit only has edge computing power support functions and meets the computing power node adaptation requirements, it is assigned to the corresponding edge computing unit node.

[0036] Step S14 specifically involves the following: This step is predicated on the fact that, after the matching determination in step S12, it is confirmed that the attributes of a heterogeneous IoT device are compatible with two or more resource node types defined by the preset type classification rules, thus forming a multi-node adaptation scenario. When the above adaptation conditions are met, according to the pre-set dynamic weight system in the preset type classification rules (this weight is dynamically adjusted based on the community smart operation goals; for example, in a security-priority scenario, robot execution and sensing nodes have higher weights than regular operation nodes), the multiple resource node types adapted to the device are prioritized, and the device is ultimately assigned to the resource node corresponding to the highest priority resource node type, achieving corresponding classification in multiple adaptation scenarios.

[0037] This step applies to all heterogeneous IoT devices that are determined to be multi-adaptable. For example, in the above embodiment, when it is determined that the smart wearable glasses have both the wearable collaboration function of "personnel positioning and command reception" (adapted smart wearable device node) and the perception function of "simple video acquisition" (adapted device perception node), based on the dynamic weight setting of "human collaborative response priority" in the community, they are classified into the smart wearable device node with higher priority. When it is determined that the emergency broadcasting device has both the regular operation function of "audio broadcasting" (adapted community operation IoT device node) and the collaborative function of "emergency alarm linkage" (adapted robot duty node association type), based on the dynamic weight of "emergency response priority", it is still classified into the community operation IoT device node with higher priority (the weight of regular operation nodes is dynamically increased in emergency scenarios).

[0038] Step S15 specifically involves the following: This step assumes that after completing the classification and grouping of all heterogeneous IoT devices in steps S13 (single adaptation inclusion) and S14 (multiple adaptation weight determination inclusion), a preliminary form of different types of resource nodes has been formed, including device sensing nodes, edge computing unit nodes, robot monitoring nodes, smart wearable device nodes, and community operation IoT device nodes. For each type of resource node, following the principle of "one node, one identifier, one tag," a globally unique identifier (such as a code, ID, etc.) and a corresponding type tag are assigned to each type of resource node (the tag content directly corresponds to the node type, such as device sensing node tag, edge computing unit node tag). The unique identifier is used for accurate node identification and network communication addressing, while the type tag is used to clarify the node's functional positioning and scheduling adaptation scenarios.

[0039] This step covers all resource nodes after classification and grouping. For example, in the above embodiment, a unique identifier "GN-SZ-001" and a type label "Device Sensing Node" are assigned to the resource node that aggregates low-cost security cameras and millimeter-wave radar; a unique identifier "GN-BY-001" and a type label "Edge Computing Unit Node" are assigned to the resource node that aggregates edge computing units, and so on. Through the allocation of identifiers and labels, the differentiation and standardization of each resource node are achieved, ultimately forming multiple resource nodes with clearly defined functions and accurate scheduling capabilities.

[0040] In one embodiment, the preset type division rule predefines multiple resource node types and sets the same division dimension for each resource node type. The division dimension includes device function type dimension, device communication adaptation dimension, and community operation priority dimension. Among them, the matching standards for the device function type dimension and the device communication adaptation dimension are different for different resource node types. The matching standard for the device function type dimension is determined based on the actual functional attributes of the IoT device, and the matching standard for the device communication adaptation dimension is that the IoT device must meet the preset communication adaptation threshold. The community operation priority dimension is configured with a dynamic weight that is dynamically adjusted according to the community smart operation goals. The dynamic weight is used to determine the final resource node type to which a device belongs when it adapts to multiple resource node types at the same time. The determination logic of the preset type classification rule is as follows: When a device attribute simultaneously meets the matching criteria of the device function type dimension and the device communication adaptation dimension corresponding to a certain resource node type, it is determined that the device is compatible with that resource node type. When a device attribute simultaneously meets the matching criteria of multiple resource node types for both device function type and device communication adaptation, its resource node type is determined based on the dynamic weight configured in the community operation priority dimension.

[0041] In this embodiment, the core is to establish a standardized, implementable, and dynamically adaptable matching and determination system for heterogeneous IoT devices and resource nodes in the community. This system clarifies the core criteria, matching standards, and priority rules for determining device ownership, ensuring the standardization, consistency, and adaptability of resource node classification to the community's smart operation goals. This provides rigid rule support for the device attribute collection, ownership determination, and classification grouping in steps S11-S15. The specific implementation logic and core content are as follows: The predefined classification rules predefine multiple resource node types and set identical classification dimensions for each type, ensuring a unified standard for device classification across the entire community. The classification dimensions are fixed and include three core dimensions: device function type, device communication compatibility, and community operation priority. These three dimensions work together to form the matching and judgment system between devices and resource node types. Specifically, for the device function type and device communication compatibility dimensions, the rules clearly stipulate that different resource node types have different matching standards, which must be set based on the functional positioning and operational attributes of each resource node.

[0042] Device Function Type Dimension: The matching standard is based on the actual functional attributes of the IoT device, serving as the core functional basis for device-resource node type adaptation. Different resource node types correspond to different functional attribute requirements. For example: device sensing nodes require the device to possess the core functional attributes of "environmental perception, data monitoring, and signal acquisition"; edge computing unit nodes require the device to possess the core functional attributes of "computing power support, data processing, and edge analysis"; robot monitoring nodes require the device to possess the core functional attributes of "autonomous movement, on-site execution, and emergency response"; smart wearable device nodes require the device to possess the core functional attributes of "personnel positioning, command interaction, and status perception"; and community operation IoT device nodes require the device to possess the core functional attributes of "public services, routine maintenance, and scenario linkage". Only when the actual functional attributes of the device fully match the functional requirements of a certain resource node type can the judgment conditions of this dimension be met.

[0043] Device communication adaptation dimension: The matching standard is that IoT devices must meet a preset communication adaptation threshold, which is a prerequisite for devices to access the global interconnection network corresponding to the resource nodes. The communication adaptation threshold is preset based on the device access requirements of the open-source HarmonyOS distributed interconnection technology. Those skilled in the art can flexibly set the above communication adaptation threshold based on actual application scenarios. The specific value does not constitute a limitation of the present invention, as long as it can meet the device interconnection and data transmission requirements of the corresponding resource nodes, covering core indicators such as communication protocol compatibility, communication signal stability, data transmission bandwidth, and communication power consumption. Different resource node types have different communication adaptation thresholds. For example: device sensing nodes require devices to support low-power communication protocols (such as Bluetooth and ZigBee) to meet the networking communication needs of large-scale sensing devices; edge computing unit nodes require devices to support high-speed communication protocols (such as Ethernet and 5G) to meet the needs of large-scale computing power interaction and data transmission; robot monitoring nodes require devices to support stable communication in mobile scenarios (such as WiFi and 5G) to meet the continuous communication needs of dynamic mobile devices; smart wearable device nodes require devices to support short-range low-power communication (such as Bluetooth BLE) to meet the lightweight communication needs of portable terminals; community operation IoT device nodes require devices to support conventional communication protocols (such as Modbus and RS485) to meet the stable networking needs of batch conventional devices. Only when the communication attributes of a device reach the communication adaptation threshold of the corresponding resource node type can it meet the judgment conditions of this dimension.

[0044] Specifically, regarding the community operation priority dimension, the rules clearly define dynamic weights that are dynamically adjusted based on the community's smart operation goals. This dimension is the core priority criterion for determining the final allocation of a device when it simultaneously adapts to multiple resource node types. The community's smart operation goals can be dynamically set according to the actual operation scenarios of the community. For example, during the daily operation phase, the core goals are "efficient equipment operation and maintenance, and reasonable resource allocation," while during the emergency operation phase (such as security incidents, extreme weather, and public events), the core goals are "safety emergency response and collaborative handling of personnel and equipment."

[0045] Dynamic weights are pre-set for different resource node types and dynamically adjusted according to changes in the community's smart operation goals. It's important to note that dynamic weights can be flexibly set using weight scores, priority levels, etc., and do not require fixed values. For example, during emergency operations, the dynamic weights of device sensing nodes and robot-attended nodes are significantly higher than those of community operation IoT device nodes, prioritizing the classification and grouping of emergency sensing and on-site response resources. During routine operations, the dynamic weights of edge computing unit nodes and smart wearable device nodes are dynamically adjusted according to maintenance needs, prioritizing the classification and grouping of computing power support and personnel collaboration resources. The setting and adjustment of dynamic weights ensure that device ownership determination always aligns with the community's real-time smart operation goals, improving the operational adaptability of classification and grouping.

[0046] The overall judgment logic of the preset type classification rules follows the core principle of "dual-dimensional adaptation judgment + multiple adaptation weights as a fallback", and is specifically divided into two steps: The first step is the single-adaptation judgment logic: When the attributes of a certain IoT device simultaneously meet the matching standards of the device function type dimension and the device communication adaptation dimension corresponding to a certain resource node type, and do not meet the dual-dimensional matching standards of any other resource node type, the rule directly determines that the device is adapted to the resource node type, providing a judgment basis for the "direct inclusion" in step S13.

[0047] The second step is the multi-adaptation judgment logic: When the attributes of an IoT device simultaneously meet the matching standards of the device function type dimension and the device communication adaptation dimension corresponding to multiple resource node types, the rule no longer directly judges any adaptation relationship, but instead activates the dynamic weight judgment mechanism of the community operation priority dimension: for the multiple resource node types that the device adapts to at the same time, the priority is sorted according to the dynamic weight currently configured, and finally the device is assigned to the resource node corresponding to the resource node type with the highest weight, providing core rule support for the "multi-adaptation weight judgment and assignment" in step S14.

[0048] Taking smart wearable glasses deployed in the community as an example: Their actual functional attributes simultaneously satisfy the "personnel positioning and command interaction" function of a "smart wearable device node" and the "simple video capture" function of a "device sensing node"; their communication attributes simultaneously meet the communication adaptation thresholds corresponding to both types of nodes (Bluetooth BLE adapts to smart wearable device nodes, short-range wireless adapts to device sensing nodes), meaning the device adapts to both resource node types. In this case, based on the community's dynamic weight setting of "daily operation with human collaborative response as the core objective," the dynamic weight of the smart wearable device node is higher than that of the device sensing node. Therefore, the rule determines that the smart wearable glasses belong to the smart wearable device node category.

[0049] Taking the emergency broadcasting equipment deployed in the community as an example: its actual functional attributes meet the "audio broadcasting" function of "community operation IoT device node" and the "emergency alarm linkage" function of "robot duty node association type"; its communication attributes meet the communication adaptation thresholds of both types of nodes. Under the smart operation goal of "emergency response first" in the community, the rules dynamically increase the dynamic weight of the community operation IoT device node, and finally determine that the emergency broadcasting equipment is classified as a community operation IoT device node, which not only meets the core function adaptation but also conforms to the priority requirements of emergency operation.

[0050] Through the aforementioned preset type classification rules, the standardized, accurate, and dynamic matching and determination of heterogeneous IoT devices and resource node types in the community are realized, providing a clear, implementable, and scalable rule system for device classification and grouping in step S10, which is fully adapted to the diversified needs of smart community operation.

[0051] In one embodiment, step S20 specifically includes: S21. Based on the unique identifier of each resource node, perform node identity verification on each resource node through the open-source HarmonyOS distributed soft bus. S22. Based on the type label corresponding to each resource node, the type domain of each resource node that has completed node identity verification is divided through the open source HarmonyOS distributed soft bus to obtain at least one type domain corresponding to the resource node type. S23. For each type of domain, configure the communication transmission priority and link scheduling authority of each resource node in the distributed network according to the dynamic weight of the resource node type corresponding to the domain. S24. Based on HarmonyOS distributed device virtualization technology, resource nodes within the same type of domain are virtualized into corresponding distributed device units. Each distributed device unit is interconnected through global routing to form a community global device interconnection network with a priority scheduling mechanism.

[0052] In this embodiment, step S21 specifically involves: using the globally unique identifier of each resource node allocated in step S15 as the verification basis, and utilizing the node identity authentication mechanism built into the open-source HarmonyOS distributed soft bus, performing identity verification operations on each of the device sensing nodes, edge computing unit nodes, robot monitoring nodes, smart wearable device nodes, and community operation IoT device nodes. During the verification process, the distributed soft bus compares and verifies the unique identifier reported by each resource node in real time with the system's pre-stored legitimate node identifier library. Only legitimate resource nodes that pass the verification can obtain subsequent network access permissions; abnormal nodes that fail the verification will be temporarily isolated and temporarily not allowed to access the community's full-domain device interconnection network. For temporarily isolated nodes, the system can periodically initiate re-identity verification and simultaneously push node abnormality alarm information to the smart wearable device nodes. After the operation and maintenance personnel have investigated issues such as abnormal node identifiers and device failures, the identity verification process will be executed again, and once the verification is successful, the nodes can normally access the network.

[0053] The verification objects in this step cover all resource nodes that have been classified and grouped and configured with unique identifiers in the aforementioned embodiments. For example, standardized identity verification is performed on device sensing nodes identified as “GN-SZ-001” and edge computing unit nodes identified as “GN-BY-001” to ensure that all nodes accessing the network are legitimate and valid nodes, thereby ensuring the security and stability of subsequent full-domain network communication.

[0054] Step S22 specifically involves: using the type labels assigned to each resource node in step S15 as the basis for classification, for all legitimate resource nodes that have passed identity verification in step S21, the open-source HarmonyOS distributed soft bus automatically classifies and classifies them according to the node type labels, grouping resource nodes with the same type label into the same type domain, forming at least one type domain that corresponds one-to-one with the resource node type. After classification, resource nodes with different functional positioning belong to independent type domains. Within each type domain, efficient data sharing and collaboration between nodes of the same type can be achieved. Between type domains, cross-domain linkage communication can be achieved through the distributed soft bus, ensuring unified management of devices of the same type and meeting the collaborative scheduling needs of multiple types of devices across the entire community.

[0055] The classification objects in this step cover all the verified resource nodes in the aforementioned embodiments. For example, all nodes carrying the "Device Sensing Node" label are classified into the Sensing and Monitoring Type Domain, nodes carrying the "Edge Computing Unit Node" label are classified into the Edge Computing Power Support Type Domain, nodes carrying the "Robot Guardian Node" label are classified into the On-site Execution Type Domain, nodes carrying the "Smart Wearable Device Node" label are classified into the Human Collaboration Type Domain, and nodes carrying the "Community Operation IoT Device Node" label are classified into the Public Operation Type Domain, thereby forming multiple type domains with clear functions.

[0056] Step S23 specifically involves: For each type of domain defined in step S22, based on the dynamic weight of the resource node type corresponding to that type of domain in the community operation priority dimension, the communication transmission priority and link scheduling permissions of each resource node within the type of domain are configured differently through the open-source HarmonyOS distributed soft bus. Specifically, for type of domains with higher dynamic weights, the internal resource nodes are configured with higher communication transmission priorities and greater link scheduling permissions. In scenarios of network congestion and concurrent transmission by multiple nodes, they can prioritize occupying communication links and completing data uploads and command issuance. For type of domains with relatively lower dynamic weights, the corresponding communication priorities and link permissions are configured according to the weight ratio, avoiding the communication needs of high-priority nodes while ensuring basic operation.

[0057] The configuration objects in this step cover the various type domains formed in the aforementioned embodiments. For example, under the community emergency response operation objective, the dynamic weights of the perception and monitoring type domain and the on-site execution type domain are relatively high, and correspondingly, higher communication transmission priorities and priority link scheduling permissions are configured. The edge computing support type domain and the manual collaboration type domain are configured with medium communication priorities according to their weights, while the public operation type domain is configured with basic communication priorities and regular link scheduling permissions, so as to adapt to the network resource allocation needs under different community operation scenarios.

[0058] Step S24 specifically involves: Based on HarmonyOS distributed device virtualization technology, for each type of domain where communication priority and link permission configurations have been completed in step S23, virtualization aggregation processing of nodes within the same domain is performed. All resource nodes within the same type of domain are uniformly virtualized into distributed device units corresponding to that node type, masking the hardware differences of individual device nodes and achieving unified management, scheduling, and data interaction for devices of the same type. On this basis, stable communication links are established between each distributed device unit through the global routing mechanism of the community-wide device interconnection network, enabling cross-unit data forwarding, command coordination, and state synchronization. Simultaneously, combined with the communication transmission priority and link scheduling permissions configured in step S23, a community-wide device interconnection network with dynamic priority scheduling capabilities is formed.

[0059] The virtualization and networking objects in this step cover all the type domains divided in the previous embodiments. For example, the device sensing nodes in the sensing and monitoring type domain are virtualized into sensing distributed device units, the edge computing unit nodes in the edge computing power support type domain are virtualized into edge computing power distributed device units, the robot duty nodes in the on-site execution type domain are virtualized into duty execution distributed device units, the smart wearable device nodes in the human collaboration type domain are virtualized into wearable collaboration distributed device units, and the community operation IoT device nodes in the public operation type domain are virtualized into public operation distributed device units. Each distributed device unit is interconnected through the whole domain routing to form a community whole domain device interconnection network with a clear structure, clear permissions, and priority scheduling mechanism.

[0060] In one embodiment, step S30 specifically includes: S31. Configure differentiated data acquisition strategies for each resource node according to the type domain and communication transmission priority corresponding to each distributed device unit. S32. Based on differentiated data collection strategies and the unique identifiers and type labels of each resource node, real-time collection of resource status data corresponding to each resource node is carried out in the community-wide device interconnection network. S33. Based on the node type and type domain corresponding to each resource node, the resource status data is categorized and cleaned by dimension, and redundant data segments unrelated to the smart operation of the community are removed. S34. Using the unique identifier of the resource node as the index key, the cleaned resource status data of various types are uniformly formatted into a standard data structure to obtain a standardized resource status dataset with a single resource node as the smallest dimension.

[0061] In this embodiment, step S31 specifically involves: using the type domain corresponding to each distributed device unit as defined in step S22 (clarifying the node's functional positioning) and the communication transmission priority configured in step S23 (clarifying the network resource allocation weight) as dual configuration bases, the system backend differentiates the data acquisition strategies for each resource node. These acquisition strategies cover core parameters such as data acquisition frequency, data acquisition accuracy, data filtering rules, and real-time / batch transmission modes. Specifically, distributed device units of different type domains and priorities are configured with differentiated acquisition strategies: resource nodes in high communication transmission priority type domains (such as sensing and monitoring type domains and on-site execution type domains) are configured with higher acquisition frequencies, finer acquisition accuracy, and real-time transmission modes to ensure that critical data is uploaded immediately; resource nodes in medium- and low-priority type domains (such as public operation type domains) are configured with appropriate acquisition frequencies and basic acquisition accuracy based on actual operational needs, and a batch transmission mode is used to reduce network load, achieving "on-demand acquisition and priority adaptation."

[0062] This step configures all resource nodes included in the community-wide device interconnection network in the aforementioned embodiments. For example, it configures a high-frequency environmental data acquisition strategy of "100ms / time", "millisecond-level" data accuracy, and real-time transmission mode for device sensing nodes (high communication priority) in the sensing and monitoring type domain; it configures a computing power status acquisition strategy of "5s / time", "percentage-level" accuracy, and near real-time transmission mode for edge computing unit nodes in the edge computing power support type domain; and it configures a device operation status acquisition strategy of "1min / time", "basic status level" accuracy, and batch transmission mode for community operation IoT device nodes (low communication priority) in the public operation type domain. This achieves precise adaptation of differentiated acquisition strategies to node functions and network priorities.

[0063] Step S32 specifically involves: using the differentiated data acquisition strategy configured in step S31 as the execution standard, and using the globally unique identifier (for data attribution and location) and type label (for data function classification) of each resource node as the basis for data association, in the community-wide device interconnection network formed in step S24, real-time data acquisition operations are performed on all network-connected resource nodes through the dedicated communication links of the distributed device units. During the acquisition process, each resource node strictly adheres to its corresponding acquisition frequency, accuracy requirements, and transmission mode, uploading resource status data (including device operating parameters, environmental perception data, computing load data, personnel collaboration status data, etc.) in real time. The system backend automatically binds and stores the acquired data with the node's unique identifier and type label, forming a three-dimensional associated data structure of "node identifier - type label - status data," ensuring that each piece of data can be traced back to a specific node and function type. At the same time, relying on network communication priority, real-time transmission and delay-free acquisition of high-priority data are guaranteed.

[0064] This step collects data from all resource nodes included in the community-wide device interconnection network in the aforementioned embodiments. For example, low-cost security cameras in the perception and monitoring domain collect video frame data at a frequency of 100ms / time, millimeter-wave radar collects distance perception data, edge computing units in the edge computing support domain collect computing power status data such as CPU load and memory usage at a frequency of 5s / time, smart wearable devices in the human collaboration domain collect the location information and command response status of the wearer, and public lighting equipment in the public operation domain collects switch status and power consumption data at a frequency of 1min / time, thereby achieving full coverage and real-time collection of status data of all resource nodes in the entire domain.

[0065] Step S33 specifically involves performing a systematic preprocessing operation on the three-dimensional associated resource status data collected in step S32, based on the dual classification dimensions of the node type (device sensing node, edge computing unit node, etc.) and the type domain (sensing and monitoring type domain, edge computing power support type domain, etc.) corresponding to each resource node, and using "relevance to community smart operation goals" as the data cleaning standard.

[0066] First, dimensional classification is performed: following the hierarchical logic of "type domain → node type → data category", all raw data is divided into corresponding data sets (such as "video perception data set" and "environmental monitoring data set" under the perception and monitoring type domain, and "computing load data set" under the edge computing support type domain), forming a structured data storage system; then, data cleaning is performed: through preset relevance filtering rules, the correlation between each data segment and the community's smart operation goals is verified one by one, and invalid, duplicate, or irrelevant redundant data segments are eliminated (such as temporary logs of device power-on self-test, blank perception data without environmental changes, redundant parameters that exceed operational needs, etc.), retaining only the core valid data.

[0067] This step processes all resource status data collected in step S32. For example, for video data from security cameras in the perception and monitoring domain, blank frames without moving objects and low-resolution invalid frames are removed, while valid video segments containing target objects are retained. For computing power data from edge computing units, redundant records occupied by temporary caches are removed, while core computing power parameters such as CPU load and memory usage are retained. For data from lighting equipment in the public operation domain, redundant signals detected by internal circuits of the equipment are removed, while operation-related data such as switch status and power consumption are retained. Redundancy removal of data is achieved through classification and cleaning, providing high-quality data support for subsequent in-depth data processing and intelligent scheduling decisions.

[0068] Step S34 specifically involves: using the globally unique identifiers of each resource node allocated in step S15 as the primary index key, uniformly formatting the various resource status data after dimensional classification and cleaning in step S33. Following the preset community smart operation standard data specifications, the data field names, data encoding formats, numerical units, and storage structures are unified to eliminate format differences between different types of nodes and different types of data. After formatting, all data is organized and stored with a single resource node as the smallest dimension, and each data record is bound to a unique identifier, forming a standardized resource status dataset with a unified structure, standardized fields, and clear indexes. This facilitates the system's rapid retrieval, retrieval, and analysis of the real-time operating status of each node.

[0069] The formatting in this step covers all valid resource status data after cleaning. For example, for the device sensing node with the unique identifier "GN-SZ-001", its sensing data is formatted into a unified environmental monitoring standard data structure; for the edge computing unit node with the unique identifier "GN-BY-001", its computing power data is formatted into a unified device operation standard data structure; the same formatting process is performed on each robot monitoring node, smart wearable device node, and community operation IoT device node, ultimately forming a standardized resource status dataset covering all networked resource nodes in the entire domain.

[0070] In one embodiment, step S40 specifically includes: S41. Using a single resource node as the smallest dimension, based on the node's unique identifier, corresponding node type, and type domain, extract the resource supply characteristics, resource demand characteristics, and abnormal state characteristics of each resource node from the standardized resource status dataset in a hierarchical manner. S42. Based on the current smart community operation goals and the dynamic weights of resource node types corresponding to each type of domain, set scheduling priorities; S43. Input the resource supply characteristics, resource demand characteristics and abnormal state characteristics into the pre-built resource scheduling model, and determine the scheduling priority of each resource node and its type domain in combination with the set scheduling priority. S44. Based on the scheduling priority determination result and the resource supply characteristics, resource demand characteristics and abnormal state characteristics, perform supply and demand matching analysis on each resource node, including supply and demand matching verification within the same type of domain and resource collaborative allocation analysis across different type of domains. S45. Based on the scheduling priority determination results and supply and demand matching analysis results, generate a resource scheduling strategy that is adapted to each distributed device unit and has hierarchical scheduling permissions.

[0071] In this embodiment, step S41 specifically involves: using a single resource node as the minimum dimension, and employing a three-dimensional analysis approach—a globally unique node identifier (ensuring accurate feature attribution), the corresponding node type (clarifying functional positioning), and the type domain (associating with priority and collaborative scenarios)—to perform a hierarchical feature extraction operation on the standardized resource status dataset constructed in step S34, extracting three core types of features: Resource supply characteristics: refers to the core functions or resource capabilities that nodes can provide for smart community operation. Based on node type and actual operating status data extraction, for example, the "environmental data acquisition accuracy and real-time transmission capability" of device sensing nodes, the "remaining computing power and data processing throughput" of edge computing unit nodes, and the "mobility range and emergency response speed" of robot-attended nodes; Resource requirement characteristics: refers to the external resource support required for a node to maintain normal operation or perform its functions. It is extracted based on node operating parameters and energy consumption data. For example, the "power supply requirement and communication link bandwidth requirement" of smart wearable device nodes, and the "power supply stability requirement and operation and maintenance inspection cycle requirement" of community operation IoT device nodes. Abnormal state characteristics: These refer to abnormal indicators that deviate from the normal operating threshold of a node. They are extracted by comparing the preset node operating standard threshold with real-time status data. For example, "abnormally low frame rate and substandard video clarity" for security cameras, "CPU load continuously exceeding 80% and memory overflow" for edge computing units, and "sudden increase in power consumption and delayed switch response" for public lighting equipment.

[0072] This step extracts data from all nodes in the standardized resource status dataset. For example, for the device sensing node with the unique identifier "GN-SZ-001", it extracts the resource supply characteristics of "100ms-level acquisition accuracy and real-time wireless transmission", the resource demand characteristics of "low-power supply", and the abnormal state characteristics of "signal strength below -70dBm". For the edge computing unit node "GN-BY-001", it extracts the supply characteristics of "80% remaining computing power and 1GB / s data processing", the demand characteristics of "stable power supply and heat dissipation guarantee", and the abnormal characteristics of "temperature exceeding 60℃". Through layered extraction, a precise profile of the core characteristics of each node is achieved.

[0073] Step S42 specifically involves the following: The prerequisite for this step is that the current smart community operation goals (such as daily maintenance, emergency response, and public event support) have been clearly defined, and that step S23 has configured corresponding dynamic weight systems for each type of domain. Guided by the current smart community operation goals and using the dynamic weights of the resource node types corresponding to each domain as the quantitative basis, the system scheduling module sets the scheduling priority of all domain resource nodes, forming a mapping relationship of "operation goals → dynamic weights → scheduling priority".

[0074] The scheduling priority setting follows the core principle of "the higher the dynamic weight, the higher the scheduling priority", and is dynamically adjusted with the changes in the community's smart operation goals: when the operation goals are switched, the dynamic weights of each type of domain are updated synchronously, and the scheduling priorities are also reordered accordingly, ensuring that the scheduling strategy always fits the real-time operation needs and avoids resource mismatch caused by fixed priorities.

[0075] The target of this step covers all resource nodes included in the community-wide device interconnection network in the aforementioned embodiments. For example, when the community is in the "emergency response" operation objective, the device sensing nodes corresponding to the perception and monitoring type domain (highest dynamic weight) and the robot duty nodes corresponding to the on-site execution type domain (second highest dynamic weight) are set as first-level scheduling priority; the edge computing unit nodes corresponding to the edge computing power support type domain are set as second-level scheduling priority; and the nodes corresponding to the manual collaboration type domain and the public operation type domain are set as third-level scheduling priority. When the operation objective is switched to "daily equipment operation and maintenance", the dynamic weights of the edge computing power support type domain and the public operation type domain are increased, and the scheduling priority of the corresponding nodes is adjusted accordingly, thereby achieving dynamic adaptation of scheduling priority.

[0076] Step S43 specifically involves the following steps: This step assumes that the three core feature extractions were completed in step S41, the basic scheduling priority was set in step S42, and a resource scheduling model with priority determination functionality has been pre-built within the system. Using the resource supply features, resource demand features, and abnormal state features extracted in step S41 as core input data, and the scheduling priority set in step S42 as the constraint benchmark, the pre-built resource scheduling model is synchronously input. The model then determines the scheduling priority for each resource node and its corresponding type domain.

[0077] During the judgment process, the model will first combine dynamic weights and operational goals to perform preliminary calibration of the overall scheduling priority of each type of domain. Then, based on the characteristics of individual nodes (such as the strength of supply capacity, the urgency of demand, and the severity of anomalies), the priority of each node in the domain will be adjusted. Finally, a judgment result that takes into account both the "overall priority of the type of domain" and the "individual differences of nodes" will be formed, ensuring that the priority judgment is both in line with the community operation goal orientation and can be adapted to the actual operating status of the nodes.

[0078] The judgment objects in this step cover all resource nodes and corresponding type domains in the aforementioned embodiments. For example, in a community emergency response scenario, the model receives data such as "real-time video acquisition (resource supply characteristics), low power consumption demand (resource demand characteristics), and stable signal (no abnormal characteristics)" from each node in the perception and monitoring type domain. Combined with the high basic scheduling priority of this type domain, the perception and monitoring type domain is determined to be a first-level domain-level priority. Security camera nodes with no abnormalities and high acquisition accuracy within the domain are determined to be first-level node-level priorities. For edge computing unit nodes with "CPU load exceeding 90% (abnormal state characteristics) and remaining computing power less than 10% (resource supply characteristics)," combined with the second-level basic priority of the edge computing power support type domain, they are determined to be second-level node-level priorities (lower than edge computing unit nodes in the same domain that are in normal condition). The model achieves precise hierarchical priority through intelligent judgment.

[0079] Step S44 specifically involves the following steps: This step presupposes obtaining the scheduling priority determination result (clarifying the scheduling order) in step S43, and extracting complete resource supply characteristics (clarifying what can be provided), resource demand characteristics (clarifying what is needed), and abnormal state characteristics (clarifying what limitations exist) in step S41. Using these three types of characteristics as the core data analysis and scheduling priority as the analysis weight, a hierarchical supply and demand matching analysis is performed on each resource node, prioritizing analysis within the same type of domain and then across different type domains. This includes two core operations: Supply and demand matching verification within the same type of domain: For all resource nodes within the same type of domain, based on node-level scheduling priority ranking, the resource supply capacity and demand gap of each node in the domain are compared to verify whether the supply and demand are balanced. For example, in the perception and monitoring type domain, the "redundant video acquisition computing power (resource supply characteristic)" of high-priority security cameras is matched with the "data supplementation demand (resource demand characteristic)" of signal-weakened nodes in the same domain to determine whether the demand gap can be made up through the collaboration of nodes in the domain; in the public operation type domain, the "power supply stability (resource supply characteristic)" and "operation and maintenance inspection demand (resource demand characteristic)" of each lighting device are checked to ensure that operation and maintenance resources are tilted towards nodes with urgent needs, while avoiding duplicate configuration or idle resources in the same domain.

[0080] Cross-domain resource coordination and allocation analysis: For resource complementarity needs between different domain types, based on domain-level scheduling priorities and core node characteristics, this analysis examines whether the core needs of high-priority domains / nodes can be met by resource supply from other domain types. For example, in emergency response scenarios, the "real-time video analysis needs (resource demand characteristics)" of the on-site execution domain (robot-attended nodes) are matched across domains with the "remaining computing power supply (resource supply characteristics)" of the edge computing power support domain (edge ​​computing unit nodes). In routine operation and maintenance scenarios, the "fault reporting needs (resource demand characteristics)" of the public operation domain (lighting equipment) are adapted across domains with the "personnel positioning and scheduling capabilities (resource supply characteristics)" of the human collaboration domain (smart wearable device nodes). Simultaneously, it incorporates abnormal state characteristics to avoid restrictions (e.g., if the edge computing unit experiences a "load exceeding threshold" anomaly, no new cross-domain computing power needs will be allocated).

[0081] Throughout the analysis, the principle of "high-priority supply and demand matching" was consistently followed: the supply and demand needs of domains / nodes with first-level scheduling priority were analyzed and adapted first to ensure the rapid implementation of core operational objectives (such as emergency response and critical equipment maintenance); supply and demand needs of medium and low priority were optimized and matched without affecting high-priority needs. Simultaneously, for situations such as "oversupply" and "unmet demand" discovered during the matching process, allocation gaps and potential matching targets were recorded to provide a basis for subsequent scheduling strategy adjustments.

[0082] This step analyzes all resource nodes and corresponding type domains in the aforementioned embodiments. For example, in a community emergency response scenario, the "distance perception data supply" of high-priority radar nodes in the perception and monitoring type domain is first checked against the "blind spot monitoring needs" of cameras in the same domain to complete the same-domain matching. Then, the "massive data processing needs" of this type domain are analyzed against the "remaining 80% computing power supply" of the edge computing power support type domain to complete the cross-domain collaborative analysis. For smart wearable device nodes with "insufficient power" abnormal state characteristics, the "charging and replenishment resource supply" in the human collaboration type domain is matched first to ensure that the high-priority human collaboration function is not affected. Through dual analysis, efficient adaptation of resources across the entire domain is achieved.

[0083] In this embodiment, step S45 specifically involves the following: The prerequisite for this step is obtaining a clear scheduling priority determination result (clarifying the scheduling hierarchy and order) through step S43, and completing the supply-demand matching analysis of "same-domain verification + cross-domain collaboration" (clarifying the supply-demand adaptation relationship and allocation direction) through step S44. Based on these two core results, and combined with the type attributes, communication transmission priorities, and core node characteristics of each distributed device unit, a resource scheduling strategy covering all resource nodes is generated according to the principles of "priority-oriented + supply-demand adaptation + hierarchical permission." The core content of the scheduling strategy includes three parts: Hierarchical scheduling permission definition: Strictly correspond to the scheduling priority sequence in step S43, configure differentiated scheduling permissions for distributed device units and resource nodes with different priorities. High-priority nodes (such as perception and monitoring nodes and on-site execution nodes in emergency scenarios) have the right to occupy communication links first, obtain resource support first, and execute scheduling instructions first. Medium and low-priority nodes execute adaptation strategies without interfering with high-priority scheduling. Distributed device unit adaptation rules: For different types of distributed device units, such as sensing and monitoring, edge computing support, and on-site execution, formulate scheduling logic that matches their functional positioning. For example, sensing and monitoring type domain units focus on "data acquisition-real-time upload" scheduling, edge computing support units focus on "computing power allocation-data processing" scheduling, and human collaboration units focus on "personnel positioning-instruction transmission" scheduling. Specific resource allocation plan: Based on the supply and demand matching analysis results, clarify the specific operations for resource complementarity within the same domain and resource coordination across domains, including the allocation objects of resource supply nodes, the replenishment sources of demand nodes, the time window for scheduling execution, and the rules for avoiding abnormal nodes.

[0084] The generated objects in this step cover all distributed device units and corresponding resource nodes in the aforementioned embodiments. For example, in a community emergency response scenario, the generated scheduling strategy is as follows: Level 1 scheduling authority: Perception and monitoring distributed device unit (domain-level level 1 priority), executes the strategy of "full high-frequency collection + real-time upload to edge computing unit", among which, security cameras with node-level level 1 priority occupy the 5G communication link first; Level 2 scheduling authority: Edge computing power distributed device unit (domain-level level 2 priority), executes the strategy of "prioritizing the allocation of 80% computing power to the sensing data + real-time analysis of target features", and avoids edge computing nodes with "load exceeding threshold" anomalies; Cross-domain collaboration strategy: The on-site distributed device unit (robot duty node) receives the analysis results from the edge computing unit and dispatches the robot to the target area according to the principle of "nearest response + high endurance priority". At the same time, the distributed device unit pushes dispatch instructions to the operation and maintenance personnel through manual collaboration to ensure efficient linkage in emergency response. In daily operation and maintenance scenarios, the generated scheduling strategy is as follows: the public operation distributed device unit (domain-level three priority) executes the "batch status reporting + on-demand operation and maintenance" strategy, matches the location of lighting equipment with abnormal power consumption with the operation and maintenance personnel of the manual collaboration unit, schedules low-priority communication links to complete the instruction issuance, and achieves precise adaptation of resource scheduling and operation scenarios.

[0085] In one embodiment, the construction and training of the pre-built resource scheduling model specifically includes the following steps: S401. Construct a two-branch model architecture that includes a scheduling priority determination branch and a supply-demand matching analysis branch; S402. Collect and integrate historical operational data of smart community operations, corresponding historical scheduling decision results and decision execution results to obtain a training dataset; S403. Based on the goals of smart community operation, and combining historical scheduling decision results and decision execution results, the training dataset is labeled to obtain a labeled training dataset. S404. Divide the labeled training dataset into a training subset and a validation subset according to a preset ratio. Input the training subset into the constructed dual-branch model architecture and perform iterative training with the scheduling priority determination accuracy and supply-demand resource matching degree as optimization objectives. S405. The performance of the trained dual-branch model architecture is verified using the verification subset. If the accuracy of the scheduling priority determination and the matching degree of supply and demand resources both meet the preset thresholds, the trained resource scheduling model is obtained. If not, the model parameters are adjusted and the training is returned to continue iteratively until all indicators meet the preset threshold requirements.

[0086] In this embodiment, the core is to construct a dual-branch model architecture adapted to the smart community operation scenario, and to complete supervised training, verification, and optimization based on actual historical operation data, so as to obtain a resource scheduling model that can stably support scheduling priority determination and supply-demand matching analysis, providing algorithmic support for intelligent scheduling of resources across the entire domain, as detailed below: Step S401 is as follows: The resource scheduling model constructed in this step is a hierarchical dual-branch model architecture, which includes the following from bottom to top: common input layer, scheduling priority determination branch, supply and demand matching analysis branch, and result output layer; among which the scheduling priority determination branch and the supply and demand matching analysis branch are independent of each other and can achieve data communication. The overall hierarchy is clearly divided and adapted to IoT distributed node scheduling scenarios.

[0087] Common Input Layer: This is the unified entry layer for the entire model. It is used to receive and standardize input data, including node resource supply characteristics, resource demand characteristics, abnormal state characteristics, community smart operation goals, dynamic weights of various types of domains, etc. After data normalization and format alignment, it is distributed to the two branches for processing.

[0088] Scheduling Priority Determination Branch: This branch, from top to bottom, includes a branch input sub-layer, a hybrid algorithm processing layer, and a priority output sub-layer. It adopts a hybrid algorithm architecture that combines Multilayer Perceptron (MLP) with Gradient Boosting Tree (XGBoost): The branch input sub-layer receives multidimensional node features, operational objectives, and dynamic weight data distributed by the common input layer; the hybrid algorithm processing layer is the core processing layer of this branch, where MLP performs domain-level priority classification inference and XGBoost performs node-level priority numerical regression, completing the two-layer priority calculation through a combination of classification and regression; the priority output sub-layer outputs domain-level scheduling priorities and node-level scheduling priorities, which are used for subsequent supply and demand matching analysis within the model and as part of the final output of the model.

[0089] Supply and Demand Matching Analysis Branch: This branch, from top to bottom, includes a branch input sublayer, a graph topology construction layer, a matching optimization processing layer, and a supply and demand result output sublayer. It adopts an architecture combining a Graph Convolutional Neural Network (GCN) with a bipartite graph optimal matching algorithm. The branch input sublayer receives two types of data simultaneously: node feature data from the common input layer and priority results from the scheduling priority determination branch. These two are then fused as the basis for analysis. The graph topology construction layer constructs a community resource scheduling topology graph using various domain types as graph nodes and the supply and demand relationships between nodes as graph edges. The matching optimization processing layer is the core processing layer of this branch. It extracts supply and demand relationship features through GCN and then uses the bipartite graph optimal matching algorithm to complete intra-domain supply and demand verification and cross-domain collaborative allocation analysis. The supply and demand result output sublayer outputs analysis results such as supply and demand matching relationships and resource allocation schemes.

[0090] Results Output Layer: Integrates the output results of the scheduling priority determination branch and the supply and demand matching analysis branch to form a unified model inference result, including scheduling priority sequence, supply and demand matching relationship, resource allocation suggestions, etc.

[0091] Both branches employ mature machine learning algorithms adapted to IoT distributed node scenarios, and achieve data interoperability through branch input sub-layers, enabling simultaneous adaptation to the feature inputs of heterogeneous resource nodes and the operational needs of multiple community scenarios. The aforementioned algorithms are all conventionally preferred algorithms in community smart operation scenarios. Those skilled in the art can flexibly select equivalent algorithms based on computing power conditions to ensure the professionalism, feasibility, and synergy of model inference.

[0092] Step S402 specifically involves collecting and integrating multi-dimensional historical data from the community smart operation scenario. This data primarily includes three core categories: historical community operation data (including node operation status, environmental perception, and computing load data under different scenarios such as daily maintenance, emergency response, and public event support); corresponding historical scheduling decision results (including historical scheduling priority settings and records of intra-domain / cross-domain resource allocation); and decision execution results (including scheduling execution effectiveness, resource matching success rate, and achievement of operational goals). By cleaning, aligning, and integrating the collected multi-source data, a standardized training dataset without missing or anomalies is formed. This dataset covers the historical operation and scheduling information of all types of resource nodes, including sensing nodes, edge nodes, robot nodes, wearable device nodes, and community operation equipment nodes, ensuring comprehensive training data and preventing model training from deviating from actual application scenarios.

[0093] Step S403 specifically involves: using the community's smart operation goals as the core annotation benchmark, and combining historical scheduling decision results with actual decision execution effects, labeling each sample in the training dataset accordingly to obtain an annotated training dataset. The annotation content mainly includes: scheduling priority category annotation (e.g., domain-level first / second / third-level priority, node-level high / medium / low priority), supply-demand matching effect annotation (e.g., successful matching, insufficient matching, redundant matching), and execution effectiveness annotation (e.g., operational goals achieved after scheduling, anomalies not eliminated after scheduling). For example, in the community's historical security emergency event samples, the perception and monitoring type domain and robot-guarded nodes are labeled as high-priority positive samples, and samples with perfect matching of computing power supply and demand after scheduling are labeled as high-matching samples. Standardized annotation provides a clear optimization direction for model iterative training.

[0094] Step S404 specifically involves: First, dividing the labeled training dataset into a training subset and a validation subset according to a preset ratio (e.g., 8:2 or 7:3). The training subset is used for model parameter learning, while the validation subset is used for subsequent model performance verification. Then, the training subset is input into the dual-branch model architecture built in step S401, with scheduling priority determination accuracy and supply-demand resource matching degree as the core optimization objectives, and undergoing multiple rounds of iterative training. During training, the scheduling priority determination branch and the supply-demand matching analysis branch simultaneously update parameters. The model continuously learns the mapping relationship between node features, operational goals, dynamic weights, and the optimal scheduling result, gradually reducing the error between the inference result and the labeled true value, and improving the model's intelligent scheduling inference capability.

[0095] Step S405 specifically involves: using the obtained validation subset, independently verifying the performance of the completed iteratively trained dual-branch model architecture, focusing on calculating two core metrics: scheduling priority determination accuracy and supply-demand resource matching degree. If both metrics reach the preset qualified thresholds (e.g., scheduling priority determination accuracy ≥ 95%, supply-demand resource matching degree ≥ 90%), the model training is considered complete, and a resource scheduling model ready for direct use is obtained. If either metric fails to reach the preset threshold, the model performance is deemed insufficient, and the system automatically adjusts relevant model parameters (e.g., learning rate, number of network layers, feature weight coefficients, etc.) and returns to step S404 for iterative training again. This process is repeated until all performance metrics meet the preset requirements, ultimately outputting a stable and reliable resource scheduling model.

[0096] In one embodiment, step S43 specifically includes: S431. Input the resource supply characteristics, resource demand characteristics, and abnormal state characteristics into the scheduling priority determination branch; S432. Based on the set scheduling priority, the scheduling priority determination branch sequentially performs scheduling priority reasoning and determination on each type of domain and each resource node to obtain the corresponding domain-level scheduling priority and node-level scheduling priority. S433. Integrate the domain-level scheduling priority and the node-level scheduling priority to obtain a scheduling priority sequence as the scheduling priority determination result.

[0097] In this embodiment, step S431 specifically involves the following: The prerequisite for this step is that the hierarchical extraction of resource supply characteristics, resource demand characteristics, and abnormal state characteristics has been completed in step S41, and the scheduling priority determination branch (including the MLP+XGBoost hybrid algorithm architecture comprising a branch input sublayer, a hybrid algorithm processing layer, and a priority output sublayer) has been established in step S401. The three types of features are first normalized and format-aligned through the model's common input layer. Then, according to the preset format of the branch input sublayer of the scheduling priority determination branch, the unique node identifier and type domain information corresponding to each feature are synchronously bound to ensure a one-to-one correspondence between features and node identities. Subsequently, the integrated feature data is batch-inputted into the branch input sublayer of the scheduling priority determination branch, providing complete data support for the hybrid algorithm processing layer of this branch.

[0098] The input objects in this step cover the feature data of all resource nodes in the aforementioned embodiments. For example, the data such as "100ms-level acquisition accuracy (resource supply characteristics), low power consumption requirements (resource demand characteristics), and stable signal (no abnormal characteristics)" of the "GN-SZ-001" device sensing node, and "80% remaining computing power (resource supply characteristics), heat dissipation guarantee requirements (resource demand characteristics), and temperature exceeding 60℃ (abnormal state characteristics)" of the "GN-BY-001" edge computing node are all passed into the branch input sub-layer of the scheduling priority determination branch in a unified format to ensure the consistency and accuracy of data input.

[0099] Step S432 specifically involves: using the multidimensional features input to the branch input sub-layer in step S431 as inference data, and using the basic scheduling priority set in step S42 as the constraint benchmark, the scheduling priority determination branch performs inference determination in the order of "domain level first, then node level" through the hybrid algorithm processing layer (MLP+XGBoost architecture). Domain-level scheduling priority determination: The MLP algorithm of the hybrid algorithm processing layer is used to classify and reason about the overall characteristics of each type of domain (such as the average supply capacity of nodes in the domain, the overall anomaly rate, and the corresponding dynamic weights), and the calibration is completed in combination with the basic scheduling priority to output the domain-level priority of each type of domain (such as the perception and monitoring type domain as level one and the edge computing power support type domain as level two). Node-level scheduling priority determination: Within each type domain, the XGBoost numerical regression algorithm of the hybrid algorithm processing layer is used to quantify and sort the feature differences of each node in the domain (such as the strength of supply capacity, the urgency of demand, and the severity of anomalies). Combined with the domain-level priority, the node-level priority of each node in the same domain is output (for example, in the same perception and monitoring type domain, the priority of security camera nodes without anomalies is higher than that of signal weakening nodes).

[0100] This step covers all types of domains and resource nodes within those domains. For example, in a community emergency response scenario, the MLP algorithm in the hybrid algorithm processing layer first determines the perception and monitoring type domain and the on-site execution type domain as domain-level first-priority. Then, within the perception and monitoring type domain, the XGBoost algorithm in the hybrid algorithm processing layer determines camera nodes with "high acquisition accuracy and no anomalies" as node-level first-priority, and millimeter-wave radar nodes with "signal strength below -70dBm" as node-level second-priority, thus achieving hierarchical and differentiated priority determination.

[0101] Step S433 specifically involves: using the domain-level scheduling priority and node-level scheduling priority derived from the hybrid algorithm processing layer in step S432 and output by the priority output sublayer as the integration basis, and following the rule of "domain-level priority as the first-level sorting dimension and node-level priority as the second-level sorting dimension," all resource nodes across the entire domain are uniformly sorted and integrated. During the integration process, each type of domain is first arranged from high to low according to its domain-level priority. Then, within the same domain-level priority, the nodes within the domain are arranged from high to low according to their node-level priority, forming a three-dimensional binding scheduling priority sequence of "domain-level priority - node-level priority - node unique identifier." This sequence is the final determination result of step S43.

[0102] This step integrates all resource nodes across the entire domain. For example, the integrated sequence is as follows: Perception and Monitoring Type Domain (Domain Level 1) - Node Level 1 (Security cameras without anomalies); Perception and Monitoring Type Domain (Domain Level 1) - Node Level 2 (Signal-weakened millimeter-wave radar); On-site Execution Type Domain (Domain Level 1) - Node Level 1 (High-endurance robots); Edge Computing Power Support Type Domain (Domain Level 2) - Node Level 1 (Edge computing units with 80% remaining computing power). Through orderly integration, a clear priority guide is provided for subsequent S44 supply and demand matching analysis, ensuring that the supply and demand needs of high-priority nodes are responded to first.

[0103] In one embodiment, step S44 specifically includes: S441. Input the scheduling priority sequence, resource supply characteristics, resource demand characteristics, and abnormal state characteristics into the supply and demand matching analysis branch; S442. Verify the supply and demand matching within the same type of domain for each resource node through the supply and demand matching analysis branch. S443. Based on the supply and demand matching verification results and the scheduling priority sequence, perform cross-type domain resource collaborative allocation analysis to complete the supply and demand matching analysis.

[0104] In this embodiment, step S441 specifically involves the following: The prerequisite for this step is that the scheduling priority sequence (defining the scheduling order of all nodes) has been obtained in step S433, three core features have been extracted in step S41, and the supply-demand matching analysis branch (including the GCN+ bipartite graph optimal matching algorithm architecture with branch input sublayer, graph topology construction layer, matching optimization processing layer, and supply-demand result output sublayer) has been built in step S401. The scheduling priority sequence is associated and bound with resource supply features, resource demand features, and abnormal state features. Unique identifiers and type domain information for each node are simultaneously added. Data normalization and format alignment are first completed through the model's common input layer, and then standardization processing is performed according to the preset data format of the branch input sublayer (e.g., converting the priority sequence into algorithm-recognizable weight coefficients and feature data into graph node attributes). Subsequently, the data is batch-inputted into the branch input sublayer of the supply-demand matching analysis branch, providing structured data support for the subsequent graph topology construction layer and matching optimization processing layer.

[0105] The input objects for this step cover the relevant data of all resource nodes in the entire domain. For example, the scheduling priority information of "perception and monitoring type domain - node level one" is bound with the "video acquisition supply characteristics, low power consumption demand characteristics, and no abnormality characteristics" of the corresponding security camera. After being standardized by the common input layer, it is passed to the branch input sub-layer to ensure the correspondence between priority and node characteristics.

[0106] Step S442 specifically involves: using the associated data input to the branch input sub-layer in step S441 as the basis for analysis, constructing a graph topology layer for the supply and demand matching analysis branch (constructing a local topology with nodes within the same type of domain as graph nodes and supply and demand relationships as graph edges), and then performing supply and demand matching verification on each type of domain using the GCN algorithm of the matching optimization processing layer: first, sorting the nodes within the domain according to the node-level scheduling priority, and prioritizing the verification of the supply and demand relationship of high-priority nodes; comparing the resource supply capacity of each node within the domain with the demand gap of other nodes, and identifying complementary supply and demand pairs within the same domain (such as the "redundant acquisition computing power" of high-priority cameras and the "data supplementation demand" of nodes with weakened signals in the same domain within the perception and monitoring type domain). Filtering effective supply and demand nodes based on abnormal state characteristics: if a node has serious abnormalities such as overload or signal interruption, it is determined that it does not have the supply capacity and is not included in the same domain supply-side matching; if the node's demand cannot be met by the same domain due to abnormal conditions (such as power depletion), it is marked as a cross-domain allocation demand.

[0107] This step of the verification covers all types of domains and nodes within those domains. For example, in a public operation type domain, the topology of nodes within the domain is constructed through a graph topology construction layer, and then the GCN algorithm of the matching optimization processing layer is used to verify the "power consumption stability supply characteristics" of high-priority lighting equipment and the "operation and maintenance inspection requirements characteristics" of faulty equipment in the same domain, thus completing the adaptation of operation and maintenance resources in the same domain. For edge computing nodes with "temperature overheating" anomalies, their "computing power supply characteristics" are temporarily not matched with the requirements of nodes in the same domain to ensure that the verification results are consistent with the actual operating status of the nodes.

[0108] Step S443 specifically involves: using the same-domain verification results from step S442 (clarifying the same-domain requirements that can be met and the cross-domain requirements that need to be matched) and the scheduling priority sequence (clarifying domain-level and node-level priorities) as the core basis, and employing the bipartite graph optimal matching algorithm of the supply-demand matching analysis branch matching optimization processing layer, cross-type domain collaborative analysis is performed. Prioritize requests based on domain-level scheduling priority, and process cross-domain requests from high-priority domains first (such as unmet requests from the perception and monitoring domain in emergency scenarios, and on-site execution domain); construct a cross-domain supply and demand bipartite graph: with the demand-side domain (and its nodes) as the bipartite points. Figure 1 Side nodes are defined with the supply-side type domain (and nodes within that domain that have supply capabilities) as the other side nodes, and "supply-demand fit" as the edge weight (fit is calculated from feature matching degree and abnormal state impact coefficient). The optimal allocation relationship is solved through the bipartite graph optimal matching algorithm of the matching optimization processing layer. For example, the "real-time video analysis demand" of the on-site execution type domain (robot node) is matched with the "remaining computing power supply" of the edge computing power support type domain (edge ​​computing nodes without abnormalities), and the "repair demand" of the public operation type domain (faulty lighting equipment) is matched with the "location scheduling capability supply" of the manual collaboration type domain (wearable devices for maintenance personnel). Abnormal constraints are avoided simultaneously: if a supply-side node has a serious abnormality (such as an edge computing node "load exceeding 90%), the cross-domain supply qualification of that node is removed, and the optimal matching is solved again.

[0109] This step analyzes all types of domains and nodes with cross-domain requirements. For example, in a community emergency response scenario, the bipartite graph algorithm of the matching optimization processing layer is used first to achieve optimal matching between the "cross-domain requirement for massive data processing" of the perception and monitoring type domain and the "supply of surplus computing power" of the edge computing power support type domain. In a daily operation and maintenance scenario, the "cross-domain requirement for equipment failure" of the public operation type domain is matched with the "supply of operation and maintenance resources" of the manual collaboration type domain. Finally, the complete analysis results are output through the supply and demand result output sub-layer to provide corresponding adaptation basis for the generation of S45 scheduling strategy.

[0110] In one embodiment, a community intelligent operation resource monitoring and scheduling system based on open-source HarmonyOS is provided. This system corresponds to the community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS described in the previous embodiment. The community intelligent operation resource monitoring and scheduling system based on open-source HarmonyOS includes: The partitioning module is used to partition heterogeneous IoT devices in the community according to preset type partitioning rules and device attributes, and to group devices of the same type into the same resource node to form multiple different resource nodes; The module is used to interconnect and network various resource nodes based on the open-source HarmonyOS distributed interconnection technology, and build a community-wide device interconnection network. The acquisition module is used to collect resource status data corresponding to each resource node in real time and perform data preprocessing to obtain a standardized resource status dataset with resource nodes as the dimension. The strategy generation module is used to extract resource supply characteristics, resource demand characteristics and abnormal state characteristics from the resource status dataset, and input them into the pre-built resource scheduling model for scheduling priority determination and supply and demand matching analysis, and generate a resource scheduling strategy that matches the real-time operation status of the community. The scheduling priority is dynamically set based on the community's smart operation goals. The scheduling execution module is used to generate corresponding scheduling instructions based on the resource scheduling strategy, and to send the scheduling instructions to the corresponding resource nodes through the open-source HarmonyOS distributed interconnection technology, so that each resource node can perform the corresponding scheduling operation.

[0111] Specific limitations regarding the community intelligent operation resource monitoring and scheduling system based on open-source HarmonyOS can be found in the limitations of the community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS mentioned above, and will not be repeated here. Each module in the aforementioned community intelligent operation resource monitoring and scheduling system based on open-source HarmonyOS can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0112] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 2As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database is used for data storage, data processing, and data analysis. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a community-based intelligent operation resource monitoring and scheduling method based on the open-source HarmonyOS.

[0113] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a community smart operation resource monitoring and scheduling method based on the open-source HarmonyOS.

[0114] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements a community intelligent operation resource monitoring and scheduling method based on the open-source HarmonyOS.

[0115] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0116] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0117] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application 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. Such 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 this application, and should all be included within the protection scope of this application.

Claims

1. A community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS, characterized in that, Includes the following steps: S10. According to the preset type classification rules and device attributes, the heterogeneous IoT devices in the community are classified, and the same type of devices are grouped into the same resource node to form multiple different resource nodes. S20: Based on the open-source HarmonyOS distributed interconnection technology, interconnect and network various resource nodes to build a community-wide device interconnection network; S30. Collect resource status data corresponding to each resource node in real time and perform data preprocessing to obtain a standardized resource status dataset with resource nodes as the dimension. S40. Extract resource supply characteristics, resource demand characteristics, and abnormal status characteristics from the resource status dataset, and input them into the pre-built resource scheduling model for scheduling priority determination and supply-demand matching analysis, and generate a resource scheduling strategy that matches the real-time operation status of the community. The scheduling priority is dynamically set based on the community's smart operation goals. S50. Generate corresponding scheduling instructions based on the resource scheduling strategy, and send the scheduling instructions to the corresponding resource nodes through the open-source HarmonyOS distributed interconnection technology, so that each resource node can perform the corresponding scheduling operation.

2. The community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in claim 1, characterized in that, Step S10 specifically includes: S11. Collect the device attributes of each heterogeneous IoT device in the community according to the division dimensions of the preset type division rules. S12. Match the collected device attributes of each heterogeneous IoT device with the preset type classification rules to determine the resource node to which each heterogeneous IoT device belongs; S13. If the device attributes match a certain resource node type defined by the preset type classification rules, then the IoT device is classified into the resource node corresponding to that resource node type. S14. If the device attributes match the multiple resource node types defined by the preset type classification rules, then the IoT device is classified into the resource node corresponding to the highest priority resource node type based on the dynamic weight in the preset type classification rules. S15. Assign a unique identifier and type label to each type of resource node to form multiple different resource nodes.

3. The community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in claim 2, characterized in that: The preset type classification rules predefine multiple resource node types and set the same classification dimensions for each resource node type. The classification dimensions include device function type dimension, device communication adaptation dimension, and community operation priority dimension. Among them, the matching standards for the device function type dimension and the device communication adaptation dimension are different for different resource node types. The matching standard for the device function type dimension is determined based on the actual functional attributes of the IoT device, and the matching standard for the device communication adaptation dimension is that the IoT device must meet the preset communication adaptation threshold. The community operation priority dimension is configured with a dynamic weight that is dynamically adjusted according to the community smart operation goals. The dynamic weight is used to determine the final resource node type to which a device belongs when it adapts to multiple resource node types at the same time. The determination logic of the preset type classification rule is as follows: When a device attribute simultaneously meets the matching criteria of the device function type dimension and the device communication adaptation dimension corresponding to a certain resource node type, it is determined that the device is compatible with that resource node type. When a device attribute simultaneously meets the matching criteria of multiple resource node types for both device function type and device communication adaptation, its resource node type is determined based on the dynamic weight configured in the community operation priority dimension.

4. The community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in claim 2, characterized in that, Step S20 specifically includes: S21. Based on the unique identifier of each resource node, perform node identity verification on each resource node through the open-source HarmonyOS distributed soft bus. S22. Based on the type label corresponding to each resource node, the type domain of each resource node that has completed node identity verification is divided through the open source HarmonyOS distributed soft bus to obtain at least one type domain corresponding to the resource node type. S23. For each type of domain, configure the communication transmission priority and link scheduling authority of each resource node in the distributed network according to the dynamic weight of the resource node type corresponding to the domain. S24. Based on HarmonyOS distributed device virtualization technology, resource nodes within the same type of domain are virtualized into corresponding distributed device units. Each distributed device unit is interconnected through global routing to form a community global device interconnection network with a priority scheduling mechanism.

5. The community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in claim 4, characterized in that, Step S30 specifically includes: S31. Configure differentiated data acquisition strategies for each resource node according to the type domain and communication transmission priority corresponding to each distributed device unit. S32. Based on differentiated data collection strategies and the unique identifiers and type labels of each resource node, real-time collection of resource status data corresponding to each resource node is carried out in the community-wide device interconnection network. S33. Based on the node type and type domain corresponding to each resource node, the resource status data is categorized and cleaned by dimension, and redundant data segments unrelated to the smart operation of the community are removed. S34. Using the unique identifier of the resource node as the index key, the cleaned resource status data of various types are uniformly formatted into a standard data structure to obtain a standardized resource status dataset with a single resource node as the smallest dimension.

6. The community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in claim 5, characterized in that, Step S40 specifically includes: S41. Using a single resource node as the smallest dimension, based on the node's unique identifier, corresponding node type, and type domain, extract the resource supply characteristics, resource demand characteristics, and abnormal state characteristics of each resource node from the standardized resource status dataset in a hierarchical manner. S42. Based on the current smart community operation goals and the dynamic weights of resource node types corresponding to each type of domain, set scheduling priorities; S43. Input the resource supply characteristics, resource demand characteristics and abnormal state characteristics into the pre-built resource scheduling model, and determine the scheduling priority of each resource node and its type domain in combination with the set scheduling priority. S44. Based on the scheduling priority determination result and the resource supply characteristics, resource demand characteristics and abnormal state characteristics, perform supply and demand matching analysis on each resource node, including supply and demand matching verification within the same type of domain and resource collaborative allocation analysis across different type of domains. S45. Based on the scheduling priority determination results and supply and demand matching analysis results, generate a resource scheduling strategy that is adapted to each distributed device unit and has hierarchical scheduling permissions.

7. The community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in claim 1, characterized in that, The construction and training of the pre-built resource scheduling model specifically includes the following steps: S401. Construct a two-branch model architecture that includes a scheduling priority determination branch and a supply-demand matching analysis branch; S402. Collect and integrate historical operational data of smart community operations, corresponding historical scheduling decision results and decision execution results to obtain a training dataset; S403. Based on the goals of smart community operation, and combining historical scheduling decision results and decision execution results, the training dataset is labeled to obtain a labeled training dataset. S404. Divide the labeled training dataset into a training subset and a validation subset according to a preset ratio. Input the training subset into the constructed dual-branch model architecture and perform iterative training with the scheduling priority determination accuracy and supply-demand resource matching degree as optimization objectives. S405. The performance of the trained dual-branch model architecture is verified using the verification subset. If the accuracy of the scheduling priority determination and the matching degree of supply and demand resources both meet the preset thresholds, the trained resource scheduling model is obtained. If not, the model parameters are adjusted and the training is returned to continue iteratively until all indicators meet the preset threshold requirements.

8. A community intelligent operation resource monitoring and scheduling system based on open-source HarmonyOS, used to implement the steps of the community intelligent operation resource monitoring and scheduling method based on open-source HarmonyOS as described in any one of claims 1-7, characterized in that, include: The partitioning module is used to partition heterogeneous IoT devices in the community according to preset type partitioning rules and device attributes, and to group devices of the same type into the same resource node to form multiple different resource nodes; The module is used to interconnect and network various resource nodes based on the open-source HarmonyOS distributed interconnection technology, and build a community-wide device interconnection network. The acquisition module is used to collect resource status data corresponding to each resource node in real time and perform data preprocessing to obtain a standardized resource status dataset with resource nodes as the dimension. The strategy generation module is used to extract resource supply characteristics, resource demand characteristics and abnormal state characteristics from the resource status dataset, and input them into the pre-built resource scheduling model for scheduling priority determination and supply and demand matching analysis, and generate a resource scheduling strategy that matches the real-time operation status of the community. The scheduling priority is dynamically set based on the community's smart operation goals. The scheduling execution module is used to generate corresponding scheduling instructions based on the resource scheduling strategy, and to send the scheduling instructions to the corresponding resource nodes through the open-source HarmonyOS distributed interconnection technology, so that each resource node can perform the corresponding scheduling operation.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the community intelligent operation resource monitoring and scheduling method based on open source HarmonyOS as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the community intelligent operation resource monitoring and scheduling method based on open source HarmonyOS as described in any one of claims 1-7.

Images