Task-oriented cooperative distributed device adaptive networking method and system

Abstract

The application provides a task-oriented cooperative distributed device adaptive networking method and system, relates to the technical field of distributed device communication and cooperation, and first receives and analyzes cross-domain task demand information, generates a task execution element set and a cooperative constraint condition; then starts a distributed device capability autonomous activation process, generates atomic capability description information and interacts to converge into a full-capability resource graph; then constructs a distributed networking architecture according to the full-capability resource graph and the cooperative constraint condition; finally controls the device to perform cross-domain task cooperative operation, and updates the networking form according to real-time state data. The application realizes decentralized distributed device adaptive networking, improves the cooperative perception and scheduling efficiency of the system, and enhances the adaptability to complex scenes.

Description

Technical Field

[0001] This invention relates to the field of distributed device communication and collaboration technology, and more specifically, to a distributed device adaptive networking method and system oriented towards task collaboration. Background Technology

[0002] In various scenarios such as new energy power plants and industrial IoT, there are a large number of heterogeneous sensing devices from multiple sources. Traditional device networking and collaboration methods face many severe challenges. On the one hand, the rigidity of the communication architecture is a prominent issue. Most systems adopt a centralized scheduling model, relying on a fixed central node for communication coordination and task allocation between devices. This model makes the system inflexible. Once the central node fails or experiences a performance bottleneck, the communication and collaboration functions of the entire system will be severely affected, and may even lead to system paralysis.

[0003] On the other hand, centralized scheduling leads to inefficient data exchange. Data from all devices must be forwarded and processed through a central node, increasing data transmission latency and path length, making it difficult to meet the demands of tasks with high real-time requirements. Furthermore, due to significant functional differences and inconsistent interface standards between different devices, efficient collaborative operation is difficult to achieve, resulting in low utilization of device resources and failing to fully leverage the overall advantages of distributed devices.

[0004] Furthermore, existing systems have shortcomings in network adaptability. With the continuous changes in application scenarios and the dynamic increase or decrease in the number of devices, traditional systems struggle to quickly and autonomously adjust network topology and communication relationships, making them unable to adapt to complex and ever-changing real-world environments. Summary of the Invention

[0005] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, the present invention provides a distributed device adaptive networking method for task collaboration, the method comprising:

[0006] Receive cross-domain task requirement information, parse the cross-domain task requirement information, extract functional requirements, interaction logic and constraint parameters, and generate a set of task execution elements and collaborative constraints. The set of task execution elements reflects the functional types and interaction relationships required to complete the cross-domain task, and the collaborative constraints include the operating specifications in the networking process.

[0007] Based on the set of task execution elements, the autonomous activation process of the distributed device capability is initiated, triggering each distributed device to disassemble its own functional modules, generate atomic capability description information, and release it to the network environment.

[0008] Through a distributed peer-to-peer discovery process, atomic capability description information of all distributed devices is exchanged and aggregated to generate a global capability resource map, which presents the distribution and correlation characteristics of all atomic capabilities in the network.

[0009] Based on the global capability resource map and the collaborative constraints, a communication domain partitioning without a central node and a device collaborative link construction are performed to generate a distributed networking architecture.

[0010] Based on the distributed networking architecture, the control device performs cross-domain task collaborative operations, while collecting device operation status data and link communication status data. The atomic capability combination method and communication domain boundary are updated according to the status data to generate an updated networking configuration.

[0011] Furthermore, the present invention also provides a distributed device adaptive networking system for task collaboration, comprising:

[0012] A processor; a machine-readable storage medium for storing machine-executable instructions of the processor; wherein the processor is configured to execute the above-described task-oriented cooperative distributed device adaptive networking method by executing the machine-executable instructions.

[0013] In another aspect, the present invention also provides a computer program product, the computer program product including machine-executable instructions stored in a computer-readable storage medium, wherein a processor of a task-cooperative distributed device adaptive networking system reads the machine-executable instructions from the computer-readable storage medium, and the processor executes the machine-executable instructions, thereby causing the task-cooperative distributed device adaptive networking system to execute the above-described task-cooperative distributed device adaptive networking method.

[0014] Based on the above, by receiving and parsing cross-domain task requirement information, a precise set of task execution elements and collaborative constraints are generated. Then, the autonomous activation process of distributed device capabilities is initiated, enabling each device to autonomously disassemble functional modules and release atomic capability description information, achieving fine-grained decoupling and open sharing of device capabilities. Through a distributed peer-to-peer discovery process, the atomic capability description information of all devices is aggregated to generate a global capability resource map, presenting the distribution and correlation characteristics of atomic capabilities in the network. Next, based on the global capability resource map and collaborative constraints, communication domain division and device collaborative link construction are performed to generate a distributed network architecture. This abandons the dependence on traditional central nodes and realizes a decentralized networking mode. Based on this distributed network architecture, devices are controlled to perform cross-domain task collaborative operations, and device operation and link communication status data are collected in real time. The atomic capability combination method and communication domain boundary are dynamically updated, enabling the network form to adaptively adjust with task requirements and environmental changes, always maintaining the optimal collaborative state. This constructs a flexible, efficient, and scalable self-organizing device network for task collaboration, significantly improving the overall collaborative perception and scheduling efficiency of the distributed system and enhancing the system's adaptability to complex multi-domain scenarios. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the execution flow of the task-oriented distributed device adaptive networking method provided in an embodiment of the present invention.

[0016] Figure 2 This is a schematic diagram of exemplary hardware and software components of a task-oriented distributed device adaptive networking system provided in an embodiment of the present invention. Detailed Implementation

[0017] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a task-oriented collaborative distributed device adaptive networking method according to an embodiment of the present invention. The following is a detailed description of this task-oriented collaborative distributed device adaptive networking method.

[0018] Step S110: Receive cross-domain task requirement information, parse the cross-domain task requirement information, extract functional requirements, interaction logic and constraint parameters, and generate a set of task execution elements and collaborative constraints. The set of task execution elements reflects the functional types and interaction relationships required to complete the cross-domain task, and the collaborative constraints include the operating specifications in the networking process.

[0019] In the scenario of smart power stations for new energy, the system first receives cross-domain task request information from the dispatch center. This cross-domain task request information is a structured data message containing fields such as task identifier, task description, involved power station area, and task priority. Taking the task of "joint power scheduling between new energy power station A and B" as an example, this message is parsed. The parsing process uses an XML-based parser to extract key information according to preset tag rules. In terms of functional requirements, the system extracts functions such as power prediction, load allocation, data acquisition, and command issuance. In terms of interaction logic, it clarifies that the data acquisition module must be executed before the power prediction module, and the power prediction result serves as the input for the load allocation module. Constraint parameters include a communication delay of less than X milliseconds, data transmission using an encryption protocol, and equipment resource utilization not exceeding Y%. The extracted information is then integrated to generate a set of task execution elements and collaborative constraints. The set of task execution elements is a data structure containing a list of function types and a directed graph of interaction relationships. The list of function types records all required function names and their corresponding identifiers, and the directed graph of interaction relationships uses nodes to represent function modules and directed edges to represent the sequential execution relationships between functions. Cooperative constraints are stored in key-value pairs to define the operational specifications.

[0020] Step S120: Based on the set of task execution elements, initiate the autonomous activation process of distributed device capabilities, trigger each distributed device to disassemble its own functional modules, generate atomic capability description information, and release it to the network environment.

[0021] In smart renewable energy power stations, once the task execution element set is generated, it is broadcast to all distributed devices (such as photovoltaic inverters, energy storage converters, and meteorological monitoring equipment). Upon receiving the broadcast, each distributed device initiates its autonomous capability activation process. Taking a photovoltaic inverter as an example, the device's built-in control unit first analyzes the task execution element set to determine the functional modules it needs to participate in. Then, the control unit initiates a functional module scanning process. This process traverses the physical functional units corresponding to the device's internal hardware components (such as CPU, sensor interfaces, and communication modules) and the logical functional units supported by the software system (such as data acquisition algorithm modules and power regulation algorithm modules), extracting all independently executable basic functional items, such as voltage acquisition, current acquisition, and power calculation. Next, these basic functional items are broken down according to the smallest granularity standard of function execution, decomposing composite functional items into atomic capability units. Next, attribute description information is added to each atomic capability unit, including input resource type (e.g., voltage signal, current signal), output result format (e.g., digital quantity, analog quantity), interaction trigger conditions (e.g., receiving a start command), and resource consumption characteristics (e.g., CPU utilization, memory usage), and interactive attributes are configured. The attribute description information of the atomic capability unit is then associated with its corresponding function identifier, integrating them into structured atomic capability description information, organized using a unified JSON format. Based on the interaction relationship description in the task execution element set, a collaboration tag is added to each atomic capability description information, such as "power data acquisition collaboration" or "power regulation collaboration." Capability release trigger conditions are configured in the device; when the matching degree between the collaboration tag in the atomic capability description information and the task execution element set reaches a preset threshold, release is triggered. The atomic capability description information is sent to the network environment in the form of data frames through a preset broadcast interface. Each data frame contains a unique device identifier and an atomic capability identifier. During transmission, a dynamic time slot allocation method is used, adjusting the transmission time window according to the number of devices in the network and the data transmission frequency to reduce the probability of data frame collisions. After receiving the data, other devices parse and store it according to a unified data format, generate a local atomic capability resource cache set, and continuously listen for capability release signals in the network until all relevant devices have completed the release.

[0022] Step S121: Each distributed device receives the task execution element set, matches function type keywords and interaction relationship descriptions from the task execution element set, and generates the association mapping relationship of its own functional modules.

[0023] After receiving the task execution element set, the distributed device's built-in parsing module performs a deep analysis of the set. Taking an energy storage converter as an example, the function type list in the task execution element set contains keywords such as "data acquisition" and "power regulation." The device's parsing module uses a string matching algorithm to search its own function module list for modules that match these keywords. For example, it finds that "battery status data acquisition module" matches the "data acquisition" function type, and "charge / discharge power regulation module" matches the "power regulation" function type. Simultaneously, based on the interaction relationship description, such as "the data acquisition module must execute before the power regulation module," it determines the execution order of these function modules. The matched function modules and their interaction relationships are stored in the form of an association mapping table. This association mapping table contains fields such as function module identifier, corresponding function type keywords, associated module identifier, and interaction direction, thereby generating the association mapping relationship of its own function modules.

[0024] Step S122: Start the device's built-in function module scanning process, traverse the physical function units corresponding to the hardware components and the logical function units supported by the software system, and extract all basic function items that can be executed independently.

[0025] After generating the association mapping relationship, the device initiates a functional module scanning process. This process first traverses the device's hardware components, such as the physical functional units corresponding to the voltage, current, and temperature sensors of the photovoltaic inverter, determining the functions these units can independently perform, such as voltage acquisition, current acquisition, and temperature acquisition. Next, it scans the logical functional units supported by the software system, such as the data filtering algorithm module and the power calculation algorithm module. These logical functional units can also independently execute specific functions. During the scan, it determines whether each unit is a basic function item that can be executed independently by checking whether each unit has independent input and output interfaces and whether it can complete a specific function without the assistance of other units. All extracted basic functional items are summarized to form a basic functional item list, which includes information such as the function item name, function description, input parameters, and output parameters.

[0026] Step S123: According to the minimum granularity standard of function execution, the extracted basic function items are split into indivisible atomic capability units, and each atomic capability unit corresponds to a single execution target.

[0027] For the extracted basic functional items, they need to be broken down according to the minimum granularity standard of functional execution. The minimum granularity standard for functional execution is defined as follows: an atomic capability unit has an independent input interface, processing logic, and output interface, and its processing logic cannot be broken down into multiple sub-logic units with complete input and output. Taking the composite functional item "data acquisition and processing" as an example, it includes sub-processes such as data acquisition, data filtering, and data conversion. Each sub-process can be triggered independently and generate intermediate outputs. Therefore, it needs to be broken down into sub-functional items such as "data acquisition atomic unit," "data filtering atomic unit," and "data conversion atomic unit." Execution logic analysis is performed again on each sub-functional item to check whether it meets the minimum granularity standard. If it does not meet the standard, the breakdown continues until all the decomposed functional units meet the standard. A unique capability identifier is assigned to each atomic capability unit. This capability identifier, combined with the device identifier, forms a unique global capability identifier. The execution target description of each atomic capability unit is configured, the execution environment requirements are analyzed, and the hardware support conditions and software dependencies required for operation are extracted. The independent execution capability of each atomic capability unit is tested. Without involving other functional units, given the required resources, it is checked whether it can independently complete the execution objective and output a valid result. If any atomic capability unit is found to be unable to execute independently, the splitting method is readjusted to ensure that all atomic capability units possess independent execution capability. Finally, all qualified atomic capability units are compiled to generate a device atomic capability list.

[0028] Step S1231: Define the minimum granularity standard for function execution. The minimum granularity standard includes: the atomic capability unit has independent input interface, processing logic and output interface, and its processing logic cannot be divided into multiple sub-logic units with complete input and output.

[0029] In the distributed equipment of smart new energy power stations, the minimum granularity standard for function execution is the foundation for ensuring that atomic capability units can work independently and efficiently together. This standard clearly stipulates that an atomic capability unit must have an independent input interface capable of receiving external data or instructions; it must possess independent processing logic, which is a complete functional implementation process and cannot be divided into multiple sub-logic units with independent inputs and outputs; and it must have an independent output interface capable of outputting the processing results. For example, in meteorological monitoring equipment, a "wind speed acquisition atomic unit" has an independent input interface (connecting to a wind speed sensor), processing logic (performing AD conversion and data calibration of the sensor signal), and an output interface (sending the calibrated wind speed data to other units). Furthermore, its processing logic cannot be further divided into smaller sub-logic units with complete inputs and outputs, thus meeting the minimum granularity standard.

[0030] Step S1232: Traverse each extracted basic function item, parse its execution logic. If its logic flow contains sub-flows that can be triggered independently and produce intermediate outputs, it is determined to be divisible. For divisible composite function items, according to the order of the core execution steps, it is divided into multiple sub-function items, and each sub-function item corresponds to an intermediate execution target.

[0031] Traversing each basic function item in the list, taking the "Power Calculation" function item as an example, its execution logic includes data reception, data verification, calculation processing, and result output. The data reception process can be triggered independently, receiving externally input voltage and current data and generating intermediate output (raw data). The data verification process uses the output of the data reception process as input, can be triggered independently, verifies the validity of the data, and generates intermediate output (verified data). Therefore, the "Power Calculation" function item is determined to be a decomposable composite function item. Following the sequence of core execution steps, it is divided into a "Data Reception Sub-function Item," a "Data Verification Sub-function Item," a "Calculation Processing Sub-function Item," and a "Result Output Sub-function Item." Each sub-function item corresponds to an intermediate execution goal; for example, the intermediate execution goal of the "Data Reception Sub-function Item" is to accurately receive external data.

[0032] Step S1233: Perform execution logic analysis on each sub-function item again to check whether it meets the minimum granularity standard for function execution. If it does not meet the standard, continue to split it until all the split functional units meet the minimum granularity standard.

[0033] The decomposed sub-functional items are analyzed again. Taking the "calculation and processing sub-functional item" as an example, its execution logic is to calculate the power value based on the verified data. This sub-functional item has an independent input interface (receiving the verified data), processing logic (power calculation formula), and output interface (outputting the calculated power value). Furthermore, its processing logic cannot be further divided into smaller sub-logical units with complete input and output, thus meeting the minimum granularity standard. If a sub-functional item does not meet the standard, such as the "data processing sub-functional item" which includes two independently triggerable sub-processes—data cleaning and data transformation—that produce intermediate outputs, it needs to be further decomposed into "data cleaning atomic units" and "data transformation atomic units" until all functional units meet the minimum granularity standard.

[0034] Step S1234: Assign a unique capability identifier to each split atomic capability unit. This capability identifier is combined with the device identifier to form a unique global capability identifier.

[0035] After the atomic capability units are decomposed, a unique capability identifier is assigned to each atomic capability unit. The capability identifier uses a combination of letters and numbers, such as "ACU001", "ACU002", etc. The device identifier is a unique identifier for each distributed device in the network, such as "DEV001", "DEV002", etc. The capability identifier and the device identifier are combined to form a unique global capability identifier, such as "DEV001-ACU001", ensuring that each atomic capability unit can be uniquely identified throughout the entire network environment.

[0036] Step S1235: Configure the execution target description for each atomic capability unit, analyze the execution environment requirements of each atomic capability unit, and extract the hardware support conditions and software dependency components required for its operation.

[0037] Detailed execution objective descriptions are configured for each atomic capability unit. For example, the execution objective description for "DEV001-ACU001" is "to collect the output voltage data of the photovoltaic inverter and perform preliminary filtering." Simultaneously, the execution environment requirements for each atomic capability unit are analyzed, including the necessary hardware support conditions and software dependencies. Hardware support conditions may include specific sensor interfaces, CPU processing power requirements, etc.; software dependencies may include specific drivers, algorithm libraries, etc. This information is recorded in the attribute description information of the atomic capability unit.

[0038] Step S1236: Test the independent execution capability of each atomic capability unit. Without the help of other functional units, input the required resources to it and check whether it can independently complete the execution target and output a valid result.

[0039] A dedicated test environment was set up to test the independent execution capability of each atomic capability unit. Taking the "DEV001-ACU001" atomic capability unit as an example, in the test environment, only the hardware devices required for this atomic capability unit (such as voltage sensors) were connected, and connections to other functional units were disconnected. Resources meeting the requirements (such as simulated voltage signals) were input, and its ability to independently complete the execution objective (collecting and filtering voltage data) and output valid results (filtered voltage data) was observed. By comparing the output results with the expected results, the independent execution capability of this atomic capability unit was determined to be qualified.

[0040] Step S1237: When an atomic capability unit that cannot be executed independently is detected, the splitting method is readjusted so that all atomic capability units have the ability to execute independently.

[0041] During testing, if it is found that a certain atomic capability unit cannot execute independently—for example, if the "data conversion atomic unit" depends on the output of the "data cleaning atomic unit" to execute—then the splitting method needs to be readjusted. This might involve merging these two atomic capability units into a larger one, or redesigning their input / output interfaces so that the "data conversion atomic unit" can receive directly input data from external sources, thus gaining independent execution capability. After adjustments, testing is repeated until all atomic capability units possess independent execution capability.

[0042] Step S1238: Organize all eligible atomic capability units to generate a device atomic capability list. Each list entry includes an atomic capability identifier, an execution target description, execution environment requirements, and independent execution test results.

[0043] All tested and compliant atomic capability units are organized and arranged in order of their atomic capability identifiers to generate a device atomic capability list. Each entry in the list details the atomic capability identifier, execution target description, execution environment requirements (hardware support conditions and software dependent components), and independent execution test results (pass or fail and related test data). This device atomic capability list is stored in the device's local storage module and can be used in subsequent autonomous capability activation processes.

[0044] Step S124: Add attribute description information to each atomic capability unit. The attribute description information includes the input resource type required for execution, the output result format, the interaction triggering conditions and resource consumption characteristics, and configure interactive attributes for the atomic capability unit.

[0045] After generating atomic capability units, attribute description information is added to each atomic capability unit. Input resource type refers to the type of data or signal required for the atomic capability unit to execute, such as "DEV001-ACU001" having an input resource type of "analog voltage signal". Output result format refers to the data format and type of the result produced after the atomic capability unit executes, such as "digital voltage value (unit: V)". Interaction trigger condition refers to the condition that triggers the execution of the atomic capability unit, such as "receiving a start command from the superior control unit". Resource consumption characteristics refer to the CPU resources, memory resources, network bandwidth, etc. consumed during the execution of the atomic capability unit, such as "CPU utilization: X%, memory usage: YMB". Simultaneously, interactive attributes are configured for the atomic capability units, such as whether other devices are allowed to call them, and calling permissions, enabling the atomic capability units to interact with other devices.

[0046] Step S125: Associate the attribute description information of each atomic capability unit with the corresponding functional identifier to form a structured atomic capability description information. The atomic capability description information is organized in a unified data format to support mutual recognition of atomic capability description information of different devices.

[0047] Each atomic capability unit's attribute description information is associated with its capability identifier, ensuring that each attribute description corresponds to a specific atomic capability unit. Then, following a pre-defined unified data format (such as JSON), the associated information is integrated to form structured atomic capability description information. The JSON format includes fields such as "Capability Identifier," "Execution Target Description," "Input Resource Type," "Output Result Format," "Interaction Trigger Conditions," "Resource Consumption Characteristics," and "Interactive Attributes." Using a unified data format ensures that atomic capability description information generated by distributed devices from different manufacturers and models can be correctly parsed and recognized by other devices in the network.

[0048] Step S126: Based on the interaction relationship description in the task execution element set, add a collaboration tag to each atomic capability description information. The collaboration tag is used to identify the collaboration role and associated atomic capability type of the atomic capability unit in the cross-domain task.

[0049] The interaction descriptions in the task execution element set clarify the collaborative relationships between various functional modules. Based on these descriptions, a collaboration tag is added to each atomic capability description. For example, for atomic capability units participating in data acquisition collaboration, a "data acquisition collaboration" tag is added; for atomic capability units participating in power regulation collaboration, a "power regulation collaboration" tag is added. Collaboration tags can also identify the role of the atomic capability unit in the collaboration process, such as "master collaboration unit," "slave collaboration unit," etc., as well as other associated atomic capability types, such as "requires collaboration with the power calculation atomic capability unit," etc. Through collaboration tags, atomic capability units can clearly define their collaborative positioning in cross-domain tasks.

[0050] Step S127: Configure capability release trigger conditions in the distributed device. The trigger conditions are based on the matching degree between the collaborative tags in the atomic capability description information and the task execution element set, and trigger the release of the atomic capability description information.

[0051] Configure capability release trigger conditions in the control module of the distributed device. These trigger conditions are determined by calculating the matching degree between the collaboration tag in the atomic capability description information and the functional type keywords in the task execution element set. The matching degree is calculated using a semantic similarity algorithm, comparing the collaboration tag with the functional type keywords to obtain a similarity value. When the similarity value reaches a preset threshold (e.g., Z%), the release of the atomic capability description information is triggered. For example, if the functional type keyword in the task execution element set is "data acquisition," and the collaboration tag of a certain atomic capability unit is "data acquisition collaboration," and its similarity value is higher than the threshold Z%, then the release of the atomic capability description information of that atomic capability unit is triggered.

[0052] Step S128: When the triggering condition is met, the distributed device sends its atomic capability description information in the form of a data frame to all reachable devices in the network environment through a preset broadcast interface. The data frame contains the device identifier and the atomic capability identifier.

[0053] When the capability release trigger condition is met, the communication module of the distributed device is activated, and the atomic capability description information is sent out through a preset broadcast interface (such as an Ethernet interface, wireless communication interface, etc.). During transmission, the atomic capability description information is encapsulated into a data frame, and the format of the data frame conforms to a network communication protocol (such as TCP / IP protocol). In addition to the atomic capability description information, the data frame also contains the device identifier of the sending device and the capability identifier of the atomic capability unit, so that the receiving device can accurately identify the sender and the corresponding atomic capability unit.

[0054] Step S129: During the transmission of atomic capability description information, a dynamic time slot allocation method is adopted to adjust the transmission time window according to the number of devices in the network and the data transmission frequency, so as to reduce the probability of data frame collision.

[0055] To reduce the probability of data frame collisions during network transmission, a dynamic time slot allocation method is used during the transmission of atomic capability description information. The device's communication module monitors the number of devices and data transmission frequency in the network in real time. Based on the number of devices N and the data transmission frequency F, the average transmission time slot length T for each device is calculated, where T = total time slot length / (N). F). Then, a random number is generated based on the device identifier to determine the starting position of the device's transmission time window. By dynamically adjusting the transmission time window, the transmission times of different devices are staggered as much as possible, thereby reducing the possibility of data frame collisions.

[0056] Step S1210: After receiving the atomic capability description information sent by other devices, each distributed device parses and stores it according to a unified data format, generates a local atomic capability resource cache set, and continuously listens for capability release signals in the network until all relevant devices complete the release of atomic capability description information.

[0057] After receiving atomic capability description information data frames from other devices, the communication module of the distributed device decapsulates the data frames and extracts the atomic capability description information. It then parses the data according to a unified data format (such as JSON) to verify the integrity and validity of the data. After parsing, the atomic capability description information is stored in a local atomic capability resource cache set. This atomic capability resource cache set is stored in the form of a database table, containing fields such as device identifier, atomic capability identifier, and attribute description information. Simultaneously, the device's communication module continuously listens for capability release signals in the network, determining whether other devices are sending atomic capability description information by detecting specific broadcast ports or signal flags. When no new capability release signal is received within a preset time (e.g., A seconds), it is determined that all relevant devices have completed the release of atomic capability description information.

[0058] Step S130: Through the distributed peer discovery process, the atomic capability description information of all distributed devices is exchanged and aggregated to generate a global capability resource map, which presents the distribution and association characteristics of all atomic capabilities in the network.

[0059] In smart renewable energy power stations, after the release of atomic capability description information, each distributed device initiates a distributed peer-to-peer discovery process. Each device initiates a peer-to-peer discovery protocol, such as the Simple Service Discovery Protocol (SSDP) based on UDP, to scan the broadcast signals of other devices in the network environment and obtain the device identifier and communication address (such as IP address and port number) of the device whose atomic capability description information has been released. Based on these communication addresses, temporary peer-to-peer communication connections are established between devices. This connection does not rely on the central node for forwarding and directly enables data exchange between devices. Through these temporary peer-to-peer communication connections, devices send their own atomic capability description information to each other and receive information sent by other devices, completing bidirectional information exchange. The received information is integrated holistically, categorized according to functional type, and a mapping relationship between functional type, atomic capability, and device identifier is generated. The attribute description information of different atomic capability units under the same functional type is compared, and complementary and dependent relationships are established based on input-output matching rules and execution target combinations. Based on these relationships, a capability association topology is generated, where each node represents an atomic capability unit, and the connections between nodes represent association relationships. In the topology, device location information and resource consumption characteristic data are associated. Atomic capability nodes with completely identical attribute descriptions are traversed and merged. Redundant associated links are removed to generate an initial version of the global capability resource graph. Each device merges its own generated initial version with versions received from other devices, supplements missing nodes and associated edges, and handles inconsistencies using preset conflict resolution rules to generate a unified global capability resource graph.

[0060] Step S131: Each distributed device initiates a peer discovery protocol to scan the broadcast signals of other devices in the network environment and obtain the device identifiers and communication addresses of all devices that have released atomic capability description information.

[0061] The peer discovery module of the distributed device initiates a preset peer discovery protocol, which is implemented based on the UDP protocol. The module sends broadcast messages to the network at regular intervals (e.g., B milliseconds), each containing its own device identifier and a query request. Other devices that have released atomic capability descriptions receive these broadcast messages and reply with a response message containing their own device identifier and communication address (IP address and port number). The local device's peer discovery module parses the received response messages, extracts the device identifiers and communication addresses of other devices, and stores them in a device list. By continuously scanning the network environment, the device list is constantly updated until all device identifiers and communication addresses that have released atomic capability descriptions are obtained.

[0062] Step S132: Based on the obtained communication address, each distributed device establishes a temporary peer-to-peer communication connection with other devices. The temporary peer-to-peer communication connection does not rely on the central node for forwarding and directly realizes data interaction between devices.

[0063] After obtaining the communication addresses of other devices, the communication modules of the distributed devices establish temporary peer-to-peer communication connections using the TCP protocol based on the communication addresses (IP addresses and port numbers). When establishing a connection, a connection request is first sent, containing the device's own identifier and a digest of its atomic capabilities. The receiving device verifies the sender's identity and digest; if the verification is successful, it replies with a connection confirmation message, completing the connection establishment. This temporary peer-to-peer communication connection is established directly between the two devices, without going through a central node for forwarding, allowing data to be exchanged directly between devices, improving communication efficiency and real-time performance.

[0064] Step S133: Through the established temporary peer-to-peer communication connection, each distributed device sends its own atomic capability description information to other connected devices, and at the same time receives atomic capability description information sent by other devices, thus completing bidirectional information exchange.

[0065] After a temporary peer-to-peer communication connection is established, the communication module of the distributed device sends the locally stored atomic capability description information to other devices through this connection. During transmission, the atomic capability description information is serialized and converted into a byte stream for transmission. The receiving device's communication module receives the byte stream, deserializes it to restore the atomic capability description information, and stores it in its local temporary buffer. Simultaneously, the local device also receives atomic capability description information sent by other devices, completing bidirectional information exchange. During this interaction, a data verification mechanism (such as CRC checksum) is used to ensure the accuracy of data transmission.

[0066] Step S134: Perform complete integration of the received atomic capability description information, classify the atomic capability description information from different devices according to function type, and generate an association mapping relationship of function type-atomic capability-device identifier.

[0067] The data integration module performs an integrity check on the received atomic capability description information, including whether the fields are complete and the data format is correct. For incomplete or incorrectly formatted information, it requests retransmission from the sending device. After the check passes, the atomic capability description information from different devices is categorized according to the function type field in the atomic capability description information. For example, all atomic capability description information with the function type "data acquisition" is grouped into one category, and those with the function type "power calculation" are grouped into another category, and so on. Then, an association relationship is established between the atomic capability unit under each function type and the device identifier, generating a function type-atomic capability-device identifier association mapping table. This association mapping table uses the function type as the key and the atomic capability identifier and device identifier as the values, displaying the atomic capability units under different function types and their respective devices.

[0068] Step S135: Compare the attribute description information of different atomic capability units under the same functional type, and establish complementary and dependent relationships between atomic capability units according to the input-output matching rules and the execution target combination. The complementary relationship refers to different atomic capability units jointly completing a certain composite function, and the dependent relationship refers to the execution of one atomic capability unit taking the output of another atomic capability unit as input.

[0069] Obtain the attribute description information of all atomic capability units under the same functional type, including input resource type, output result format, and execution target description. Match the output result format of each atomic capability unit with the input resource type of other atomic capability units. If a match is successful (e.g., the output result format of atomic capability unit A is "digital voltage value", and the input resource type of atomic capability unit B is "digital voltage value"), then establish a potential dependency relationship between them. For atomic capability unit pairs marked with potential dependencies, simulate the execution process in a simulation environment to verify whether the output of the former unit can drive the execution of the latter unit and produce an output that meets its execution target. Test valid dependencies, configure dependency directions and conditions, and record them as formal dependencies. Analyze the execution target descriptions of multiple atomic capability units under the same functional type to identify atomic capability combinations that can jointly complete a composite function not covered by a single atomic capability unit. Perform collaborative execution simulation on the identified atomic capability combinations to check whether the set of their output results meets the composite functional target. Record successful simulation verification as complementary relationships. Classify and organize formal dependencies and complementary relationships according to functional type to establish an atomic capability association table. Traverse the dependencies in the association table, check for circular dependency paths, and if they exist, adjust the splitting granularity or input / output attribute descriptions of the atomic capability units involved in the cycle until the circular path is eliminated. Then, associate and store the adjusted association table with the atomic capability description information.

[0070] Step S1351: Obtain the attribute description information of all atomic capability units under the same functional type. The attribute description information includes the input resource type, output result format, and execution target description.

[0071] From the locally stored atomic capability resource cache set, the attribute description information of all atomic capability units under the same functional type (such as "data acquisition") is filtered out. This attribute description information includes fields such as input resource type (such as "analog signal" or "digital signal"), output result format (such as "integer data" or "floating-point data"), and execution target description (such as "acquire temperature data" or "acquire humidity data"). This information is extracted to form an attribute description information list for subsequent comparison and analysis.

[0072] Step S1352: Match the output format of each atomic capability unit with the input resource type of other atomic capability units. If the match is successful, establish a potential dependency relationship marker between the two.

[0073] For each atomic capability unit in the attribute description information list, its output format is compared one by one with the input resource type of other atomic capability units in the list. For example, if the output format of atomic capability unit C is "digital temperature value (unit: ℃)" and the input resource type of atomic capability unit D is "digital temperature value", then the two match successfully. At this time, a potential dependency relationship is established between atomic capability units C and D, recorded as "C→D", indicating that the execution of atomic capability unit D may depend on the output of atomic capability unit C.

[0074] Step S1353: For atomic capability unit pairs marked with potential dependencies, simulate the execution process in the simulation environment to verify whether the output of the previous unit can drive the execution of the next unit and produce an output that meets its execution goal.

[0075] Set up a simulation environment and deploy atomic capability unit pairs (e.g., C→D) marked with potential dependencies into the simulation environment. First, start atomic capability unit C, input the required resources to it, and make it execute and output the result. Then, use this output result as the input resource for atomic capability unit D, start atomic capability unit D, observe whether it can execute normally, and check whether the output result matches its execution target description. For example, if atomic capability unit C outputs a digital temperature value of 25℃, and atomic capability unit D receives this input, executes the corresponding processing logic, and outputs the judgment result "temperature normal", which matches its execution target description, then the verification is successful.

[0076] Step S1354: Test the valid dependencies, configure the dependency direction and dependency conditions, and record them as formal dependencies. The dependency direction refers to the previous atomic capability unit pointing to the next atomic capability unit, and the dependency condition refers to the specific matching requirements of the input resource.

[0077] For potential dependencies that pass simulation verification, they are designated as formal dependencies. The dependency direction is configured, explicitly specifying that the preceding atomic capability unit (e.g., C) points to the following atomic capability unit (e.g., D). Simultaneously, dependency conditions are configured, i.e., the specific matching requirements of the input resources. For example, the input resource of atomic capability unit D must be the digital temperature value output by atomic capability unit C, with a value range between -40℃ and 125℃. The formal dependencies are recorded in the atomic capability association table, including the association type (dependency), the identifiers of the associated parties (C and D), the dependency direction, and the dependency conditions.

[0078] Step S1355: Analyze the execution target descriptions of multiple atomic capability units under the same functional type, and identify the atomic capability combinations that can jointly complete a composite function not covered by a single atomic capability unit.

[0079] The analysis identifies combinations of atomic capability units within the same functional type that can collectively accomplish a specific composite function. For example, in the functional type "Environmental Monitoring," there are atomic capability units E (execution objective: collecting temperature data), F (execution objective: collecting humidity data), and G (execution objective: collecting air pressure data). The composite function "Complete Environmental Parameter Monitoring" requires the simultaneous collection of temperature, humidity, and air pressure data, which cannot be accomplished by a single atomic capability unit. Therefore, the combination of atomic capability units E, F, and G can collectively complete this composite function and is identified as a complementary combination.

[0080] Step S1356: Perform collaborative execution simulation on the identified atomic capability combinations, call the atomic capability units in the atomic capability combinations in a reasonable order, and detect whether the set of output results achieves the composite functional objective; record the atomic capability combinations that are successfully verified by simulation as complementary relationships, and store the atomic capability unit identifier list, preset calling sequence and interaction interface protocol of the atomic capability combination.

[0081] In the simulation environment, the identified atomic capability combinations (such as E, F, G) are invoked in a reasonable order (e.g., E first, then F, then G). Corresponding resources are input to each atomic capability unit to execute and output results. The outputs of all atomic capability units are collected, and it is checked whether the set of results satisfies the composite functional objective (e.g., "complete environmental parameter monitoring" requires temperature, humidity, and air pressure data). If satisfied, the simulation verification is successful, and the atomic capability combination is recorded as a complementary relationship. Simultaneously, the list of atomic capability unit identifiers (E, F, G), the preset invocation sequence (E→F→G), and the interaction interface protocol (such as data transmission format, communication rate, etc.) for this atomic capability combination are stored.

[0082] Step S1357: Classify and organize formal dependencies and complementarities according to their functional types, and establish an atomic capability association table. The association table includes the association type, the identifiers of the associated parties, and the dependency conditions or collaboration methods.

[0083] Formal dependencies and complementarities are categorized by functional type, such as dependencies and complementarities under the "Data Acquisition" functional type, and dependencies and complementarities under the "Power Calculation" functional type. An atomic capability relationship table is created for each functional type, containing fields such as relationship type (dependency or complementarity), identifiers of the related parties (atomic capability unit identifiers), dependency conditions (for dependencies) or coordination methods (for complementarities, such as call sequence, interface protocol, etc.). This relationship table allows users to view the relationships between atomic capability units under different functional types.

[0084] Step S1358: Traverse the dependencies in the association table, check for the existence of circular dependency paths, and if they exist, adjust the splitting granularity or input / output attribute descriptions of the atomic capability units involved in the cycle according to preset rules until the circular path is eliminated. Then, associate and store the adjusted association table with the atomic capability description information.

[0085] The process iterates through all dependencies in the atomic capability relationship table, using a graph traversal algorithm (such as depth-first search) to detect circular dependencies (i.e., atomic capability unit A depends on atomic capability unit B, and atomic capability unit B depends on atomic capability unit A, forming a cycle A→B→A). If a circular dependency exists, adjustments are made according to preset rules. For example, if the circular dependency is due to insufficient granularity of atomic capability unit splitting, the splitting granularity is readjusted, merging or further splitting related atomic capability units; if the circular dependency is due to unreasonable input / output attribute descriptions, the input resource type or output result format of the atomic capability unit is modified to break the circular dependency. After adjustment, the circular dependency path is checked again until all circular paths are eliminated. Finally, the adjusted relationship table is associated and stored with the atomic capability description information to ensure consistency between the two.

[0086] Step S136: Based on the association mapping relationship and the identified complementary and dependent relationships, generate a capability association topology structure. In the capability association topology structure, each node represents an atomic capability unit, and the connection between nodes represents the association relationship.

[0087] Based on the mapping relationship between function type, atomic capability, and device identifier, as well as the identified complementary and dependent relationships, a capability association topology is generated using graph theory. In this topology, each node represents an atomic capability unit, and the node's attributes include atomic capability identifier, device identifier, and function type. Connections between nodes represent associations, with directed connections indicating dependencies (arrows pointing to the dependent node) and undirected connections indicating complementarities. This visualized topology structure clearly shows the associations between atomic capability units.

[0088] Step S137: Associate device location information and resource consumption characteristic data on each node in the capability association topology, traverse the capability association topology, merge atomic capability nodes with completely consistent attribute description information, remove redundant association links, and integrate the adjusted capability association topology with association mapping relationships, complementary relationships, and dependency relationships to generate an initial version of the global capability resource graph.

[0089] The system acquires the location information (such as latitude and longitude coordinates) and resource consumption characteristics (such as CPU utilization and memory usage) of the devices belonging to each atomic capability unit, and associates this information with the corresponding nodes in the capability association topology. Then, it traverses the entire capability association topology, comparing the attribute descriptions of each node. If two nodes have completely identical attribute descriptions (including input resource type, output result format, execution target description, etc.), they are merged into one node, retaining the identifier of one node, and the association relationship is updated. Simultaneously, the system checks the association links; if redundant links exist (such as two links connecting the same two nodes with identical association relationships), the redundant links are removed. The adjusted capability association topology is then integrated with the association mapping relationships, complementary relationships, and dependency relationships to form the initial version of the global capability resource graph.

[0090] Step S138: Each distributed device merges its own generated initial version of the global capability resource graph with the version received from other devices, supplements missing nodes and related edges, handles inconsistent descriptions using preset conflict resolution rules, and generates a unified global capability resource graph.

[0091] Each distributed device receives an initial version of the global capability resource map from other devices via a temporary peer-to-peer communication connection. It then merges its own generated initial version with the received version, first comparing the node set to fill in missing nodes and their attribute information; then comparing the set of associated edges to fill in missing associated edges and their relationship information. For inconsistencies in descriptions during the fusion process (such as different attribute descriptions for the same atomic capability unit), pre-defined conflict resolution rules are applied. These rules can be based on device priority (e.g., descriptions from higher-priority devices take precedence) or information timestamps (e.g., the most recent description takes precedence). After data fusion and conflict resolution, a unified global capability resource map is generated, containing the distribution and association characteristics of all atomic capability units in the network.

[0092] Step S140: Based on the global capability resource map and the collaborative constraints, perform communication domain partitioning without a central node and construct device collaborative links to generate a distributed network architecture.

[0093] In smart new energy power stations, after obtaining the overall capability resource map and collaborative constraints, the process of communication domain partitioning and device collaborative link construction begins. First, the collaborative constraints are analyzed to extract communication latency requirements (e.g., less than X milliseconds), data transmission security requirements (e.g., AES encryption), resource usage limits (e.g., CPU utilization not exceeding Y%), and collaborative response requirements (e.g., response time less than Z milliseconds), generating hard constraint indicators. Based on the device location information and atomic capability associations in the overall capability resource map, devices are grouped into candidate communication domains according to preset geographical proximity thresholds (e.g., distance less than M meters) and correlation thresholds (e.g., correlation greater than N%). The communication latency between devices within each candidate communication domain is measured. If the latency exceeds the requirement, the candidate communication domain is split or adjusted according to preset rules (e.g., removing the farthest device from the domain). The total resources (e.g., total CPU processing power, total memory capacity, etc.) of devices within each candidate communication domain are calculated and compared with the estimated total consumption of planned atomic capability resources within that domain. If the total resources are lower than the estimated consumption, the candidate communication domain is expanded according to preset rules (e.g., adding nearby idle devices). Assign a unique domain identifier to each candidate communication domain, and configure communication protocols (such as MQTT protocol) and data interaction rules (such as data format, transmission frequency, etc.) for devices within the domain, ensuring compliance with data transmission security requirements. Based on the atomic capability dependencies and complementarities in the global capability resource graph, plan device collaborative links within each communication domain, configure the calling order and data transmission path of atomic capability units, and configure backup links and primary / backup switching trigger conditions (such as primary link latency exceeding a threshold) for each link. Analyze the atomic capability association requirements between different communication domains, plan cross-communication domain collaborative links, and configure interface specifications (such as API interfaces) and routing paths for cross-domain data transmission. Integrate the communication domain division results, intra-domain collaborative links, cross-domain collaborative links, communication protocols, and data interaction rules to generate a preliminary distributed network architecture. Load the preliminary architecture in the simulation environment, run the atomic capability collaborative execution process, collect simulated communication latency, resource consumption, and data security parameters, compare them with hard constraint indicators, iteratively optimize parts that do not meet the indicators, and output the final distributed network architecture.

[0094] Step S141: Analyze the collaborative constraints, extract the communication delay requirements, data transmission security requirements, resource usage limits and collaborative response requirements contained therein, and generate hard constraint indicators in the networking process.

[0095] The collaborative constraints are a structured document containing multiple constraint clauses. The parsing module parses this document and extracts the key constraints related to network topology. Communication latency requirements refer to the maximum allowable delay time for data transmission between devices, such as "communication latency between devices should be less than X milliseconds". Data transmission security requirements include data encryption algorithms and authentication methods, such as "data transmission must use AES-256 encryption algorithm, and communication between devices must perform two-way authentication". Resource usage limits refer to the maximum allowable percentage of CPU, memory, and network bandwidth resources used by a device during task execution, such as "CPU utilization must not exceed Y%, and memory usage must not exceed ZGB". Collaborative response requirements refer to the maximum allowable response time from the issuance of a task request to the start of task execution by the device, such as "collaborative response time should be less than W milliseconds". The extracted constraints are integrated to generate hard constraint indicators for the network topology process, stored in key-value pairs, such as {"communication latency requirement": "X milliseconds", "data transmission security requirement": "AES-256 encryption, two-way authentication", ...}.

[0096] Step S142: Based on the device location information and atomic capability association relationship in the global capability resource map, according to the preset geographical proximity threshold and association degree threshold, the devices are grouped into candidate communication domains. Each candidate communication domain contains multiple distributed devices whose atomic capabilities meet the preset association conditions.

[0097] The location information (latitude and longitude coordinates) and atomic capability relationships of each device are extracted from the global capability resource map. A preset geographical proximity threshold of P meters and a correlation threshold of Q% are used. For each device in the network, other devices within a distance of P meters are searched, forming an initial device set. Then, the atomic capability correlation degree between devices in the initial device set is calculated. The correlation degree is calculated based on the atomic capability correlation table, counting the number of dependencies and complementarities between devices, and dividing by the total number of possible correlations to obtain the correlation degree value. Devices with a correlation degree value greater than Q% are retained in the initial device set, forming candidate communication domains. This process is repeated until all devices are assigned to their respective candidate communication domains, ensuring that each device belongs to only one candidate communication domain.

[0098] Step S143: According to the communication delay requirement in the hard constraint index, measure the communication delay between devices within each candidate communication domain. If the communication delay exceeds the communication delay requirement, split or adjust the device composition of the candidate communication domain according to preset rules.

[0099] For each candidate communication domain, the communication latency between any two devices within the domain is measured using network testing tools. During measurement, test data packets are sent, and the round-trip time from the sender to the receiver is recorded. The average of multiple measurements is taken as the communication latency. The measured communication latency is compared with the communication latency requirement (X milliseconds) in the hard constraint index. If the communication latency between devices exceeds X milliseconds, the candidate communication domain is split or adjusted according to preset rules. The preset rules may be to remove devices with communication latency exceeding the threshold from the current candidate communication domain and assign them to other neighboring candidate communication domains, or to split the current candidate communication domain into two smaller communication domains, ensuring that the communication latency between devices in the split communication domains both meet the requirement.

[0100] Step S144: Calculate the total resource amount of the devices in each candidate communication domain according to the resource occupancy limit in the hard constraint index, and compare it with the estimated total amount of atomic capacity resource consumption planned to be scheduled in the candidate communication domain. If the total resource amount is lower than the estimated total consumption, expand the device composition of the candidate communication domain according to the preset rules.

[0101] Resource information for all devices within the candidate communication domain is collected, including CPU processing power, memory capacity, storage capacity, and network bandwidth, and the total amount of each resource is calculated. Simultaneously, based on the resource consumption characteristics of the atomic capability units scheduled within the candidate communication domain, the total resource consumption required for the execution of these atomic capability units (such as total CPU utilization and total memory usage) is estimated. The total resource amount is compared with the estimated total resource consumption. If the total resource amount is lower than the estimated total consumption, the device composition of the candidate communication domain is expanded according to preset rules. These preset rules may include transferring resource-rich devices from neighboring candidate communication domains or adding idle devices not assigned to any communication domain to the candidate communication domain to increase the total resource amount and meet resource occupancy restrictions.

[0102] Step S145: Assign a unique domain identifier to each candidate communication domain, and configure the communication protocol and data interaction rules for devices within the domain. The communication protocol and data interaction rules shall meet the data transmission security requirements in the hard constraint indicators.

[0103] Assign a unique domain identifier to each candidate communication domain, such as "Domain001", "Domain002", etc. Configure communication protocols and data exchange rules for devices within the domain based on the data transmission security requirements in the hard constraints. The communication protocol can be a protocol that supports encryption and authentication, such as MQTT (using SSL / TLS encryption) or CoAP (using DTLS encryption). Data exchange rules include data format (e.g., JSON format), data transmission frequency (e.g., R times per second), and data verification method (e.g., CRC32 checksum). Simultaneously, configure an authentication mechanism between devices, such as digital certificate-based authentication, to ensure that only authorized devices can join the communication domain and exchange data.

[0104] Step S146: Based on the atomic capability dependencies and complementarities in the global capability resource graph, plan device collaborative links in each communication domain, configure the calling order and data transmission path of each atomic capability unit, configure a backup link for each device collaborative link, and set the primary / backup switching trigger conditions.

[0105] Extract the atomic capability dependencies and complementarities within the current communication domain from the global capability resource graph, generating an atomic capability association subgraph within the domain. Starting from the execution goal of the cross-domain task, traverse the atomic capability association subgraph within the domain, selecting atomic capability units that can directly or indirectly contribute to the execution goal, and marking them as core and associated atomic capability units. Based on the atomic capability dependencies, perform topological sorting on the core and associated atomic capability units to generate a preliminary execution sequence that satisfies the dependencies. Based on the atomic capability complementarities, mark the groups of atomic capability units that can be executed in parallel in the preliminary execution sequence and configure data synchronization points. Based on the physical location of the execution device corresponding to each atomic capability unit and historical communication quality data, calculate the data transmission path, and select the path with fewer hops and historical communication quality higher than a preset threshold. Assign a unique path identifier to each data transmission path and configure the data transmission format and verification method. Configure data cache nodes in the path to temporarily store the output results of the atomic capability units. Analyze the execution time of each atomic capability unit, allocate execution time windows, and ensure that the execution window does not conflict with the data transmission time. Generate a device collaborative link model, including the execution sequence, data transmission path, path identifier, data cache node location, and time window allocation information. Run the model in the simulation environment to verify whether the calling order, data transmission path latency, and time window meet the requirements, and iteratively correct any failures. Configure a backup link for each device's collaborative link, select a different physical path from the primary link, and set the primary / backup switchover trigger conditions. If the primary link communication latency exceeds a preset threshold of S milliseconds or the packet loss rate exceeds T%, the system will automatically switch to the backup link.

[0106] Step S1461: Extract the atomic capability dependencies and complementarities within the current communication domain from the global capability resource graph, and generate an atomic capability association subgraph within the domain.

[0107] The atomic capability units and their relationships belonging to the current communication domain are selected from the global capability resource graph. Based on the communication domain to which the device identifier of each atomic capability unit belongs, the set of atomic capability units within the current communication domain is determined. Then, the dependencies and complementarities between these atomic capability units are extracted from the atomic capability relationship table. Based on these atomic capability units and their relationships, a domain-specific atomic capability relationship subgraph is generated. This subgraph is a subset of the global capability resource graph and contains only atomic capability units and their relationships within the current communication domain.

[0108] Step S1462: Starting from the execution target of the cross-domain task, traverse the atomic capability association subgraph within the domain, select atomic capability units that can directly or indirectly contribute to the execution target, and mark them as core and associated atomic capability units.

[0109] Define the execution objective of the cross-domain task, such as "achieving joint power scheduling between region A and region B". Starting from this execution objective, perform a reverse traversal of the atomic capability association subgraph within the domain to find atomic capability units that directly or indirectly support the execution objective. For example, the execution objective requires power prediction results, and the power prediction atomic capability unit needs historical data provided by the data acquisition atomic capability unit, which in turn requires the support of the sensor interface atomic capability unit. Therefore, atomic capability units such as power prediction, data acquisition, and sensor interface are all marked as core and associated atomic capability units.

[0110] Step S1463: Based on the atomic capability dependencies, perform topological sorting on the core and associated atomic capability units to generate a preliminary execution sequence that satisfies the dependencies, in which the preceding unit is located before the following unit.

[0111] Based on the dependencies in the atomic capability association table, the core and associated atomic capability units are topologically sorted. The Kahn algorithm is used for topological sorting. First, all atomic capability units without preceding dependencies (nodes with an in-degree of 0) are identified and added to the execution sequence. Then, these nodes and their associated dependencies are removed, and new nodes with an in-degree of 0 are identified and added to the execution sequence. This process is repeated until all atomic capability units are added to the execution sequence. The generated initial execution sequence ensures that the execution of preceding atomic capability units precedes that of subsequent atomic capability units, satisfying the dependencies.

[0112] Step S1464: Based on the atomic capability complementarity relationship, mark the atomic capability unit groups that can be executed in parallel in the preliminary execution sequence, and configure the data synchronization points between units within the atomic capability unit groups.

[0113] Analyze the complementary relationships in the atomic capability relationship table to identify atomic capability unit groups that can be executed in parallel. For example, atomic capability units H and I are complementary; their execution goals are both to collect different types of environmental data, and they have no dependencies on each other, therefore they can be executed in parallel. In the initial execution sequence, H and I are marked as a group of atomic capability units that can be executed in parallel. A data synchronization point is configured for this unit group, meaning that only after H and I have both completed their execution can their outputs be aggregated and passed to subsequent atomic capability units.

[0114] Step S1465: Based on the physical location of the execution device corresponding to each atomic capability unit and historical communication quality data, calculate the data transmission path between each atomic capability unit, and select the path with fewer hops and historical communication quality higher than a preset threshold.

[0115] Obtain the physical location (latitude and longitude coordinates) and historical communication quality data (such as communication latency, packet loss rate, etc.) of the execution device corresponding to each atomic capability unit. Based on the physical location, calculate the distance between devices and generate possible data transmission paths by combining the network topology. For each possible path, calculate the hop count (the number of intermediate devices traversed) and view the historical communication quality data of that path. Select the data transmission path with a low hop count (e.g., no more than U hops) and historical communication quality higher than a preset threshold (e.g., communication latency less than V milliseconds, packet loss rate less than W%).

[0116] Step S1466: Assign a unique path identifier to each data transmission path, and configure the data transmission format and verification method on each data transmission path.

[0117] Assign a unique path identifier to each selected data transmission path, such as "Path001", "Path002", etc. Configure the data transmission format according to the communication protocol and data interaction rules, such as using JSON format, including a data header (path identifier, sender identifier, receiver identifier, timestamp) and a data body (atomic capability unit output results). Configure the data verification method, such as using the CRC32 checksum algorithm. Calculate the checksum before data transmission and append it to the end of the data. The receiver recalculates the checksum upon receiving the data and compares it with the appended checksum to ensure the accuracy of data transmission.

[0118] Step S1467: Configure data cache nodes in the planned data transmission path to temporarily store the output results of atomic capability units.

[0119] Based on the length of the data transmission path and the execution frequency of the atomic capability units, data cache nodes are configured along the path. A data cache node can be an intermediate device within the path or a dedicated cache server. When the output of an atomic capability unit is transmitted to a cache node, the cache node temporarily stores the data, awaiting requests from subsequent atomic capability units or automatically pushing it to them. The cache node configuration can set the expiration time of the cached data based on the importance and real-time requirements of the data to ensure data freshness.

[0120] Step S1468: Analyze the execution time of each atomic capability unit in the execution sequence, and allocate an execution time window to each atomic capability unit. The execution window does not conflict with the data transmission time.

[0121] The average execution time of each atomic capability unit in the execution sequence is obtained through historical execution data or simulation tests. An execution time window is allocated to each atomic capability unit based on the initial execution sequence and the transmission time of the data transmission path. The start time of the execution time window is the time when the preceding atomic capability unit completes execution and data transmission, and the end time is the start time plus the execution time of that atomic capability unit. It is ensured that the allocated execution time window does not conflict with the data transmission time; that is, the atomic capability unit begins execution only after receiving input data, and data transmission only occurs after execution is completed.

[0122] Step S1469: Generate a device collaboration link model, which includes execution sequence, data transmission path, path identifier, data cache node location and time window allocation information.

[0123] The execution sequence, data transmission path, path identifier, data cache node location, and time window allocation information are integrated to generate a device collaboration link model. This device collaboration link model is stored in the form of structured data, such as XML or JSON, and details the calling order of atomic capability units, the data transmission path between devices, the identifier of each path, the physical location of data cache nodes, and the execution time window of each atomic capability unit.

[0124] Step S14610: Run the device collaborative link model in the simulation environment to verify whether the calling order of atomic capability units violates the definition of dependency and complementarity, detect whether the delay of the data transmission path exceeds the limit, and whether the time window overlaps. Iteratively correct the links that fail to be verified according to the preset strategy, and output the final device collaborative link.

[0125] The device collaboration link model is loaded into the simulation environment to simulate the execution and data transmission processes of atomic capability units. During the simulation, the calling order of atomic capability units is monitored in real time to ensure it conforms to the definitions of dependencies and complementarities, such as whether a subsequent atomic capability unit executes before its dependent preceding atomic capability unit. Simultaneously, the actual latency of the data transmission path is checked to ensure it does not exceed the communication latency requirements in the hard constraints, and whether the execution time windows of each atomic capability unit overlap. For any failed verification steps, iterative corrections are performed according to a preset strategy, such as adjusting the calling order of atomic capability units, changing the data transmission path, and reallocating the time window. After multiple iterative corrections, the device collaboration link model meets all requirements, and the final device collaboration link is output.

[0126] Step S147: Analyze the atomic capability association requirements between different communication domains, plan cross-communication domain collaborative links, and configure the interface specifications and routing paths for cross-domain data transmission to support the collaborative scheduling of atomic capabilities across all domains.

[0127] The atomic capability relationships between different communication domains are extracted from the global capability resource map. The requirements for cross-communication domain atomic capability relationships are analyzed, such as an atomic capability unit in communication domain A requiring the output of an atomic capability unit in communication domain B as input. Based on these requirements, cross-communication domain collaborative links are planned. The planning of cross-domain collaborative links needs to consider factors such as network connectivity, communication latency, and data transmission security between communication domains. Interface specifications for cross-domain data transmission are configured, such as using a RESTful API, defining the request method, parameter format, and return value format. Simultaneously, routing paths are configured, selecting paths that pass through core network devices and have good communication quality as the routing paths for cross-domain data transmission to ensure the stability and reliability of the cross-domain collaborative links.

[0128] Step S148: Integrate the communication domain division results, intra-domain collaborative links, cross-domain collaborative links, communication protocols, and data interaction rules to generate a preliminary distributed networking architecture.

[0129] The communication domain partitioning results (domain identifier, list of devices within the domain), intra-domain collaborative links (execution sequence, data transmission path, etc.), cross-domain collaborative links (interface specifications, routing paths, etc.), as well as communication protocols and data interaction rules, are integrated. The integrated information is stored in a structured document, forming a preliminary distributed network architecture. This distributed network architecture details the communication domain partitioning of the entire network, the collaborative links between devices, and the communication rules.

[0130] Step S149: Load the preliminary distributed networking architecture in the simulation environment, run the atomic capability collaborative execution process, collect the communication latency, resource consumption, and data security parameters of the simulation, compare them with the hard constraint indicators, iteratively optimize the communication domain division or collaborative links that do not meet the indicators, and output the final distributed networking architecture.

[0131] A preliminary distributed networking architecture is loaded into the simulation environment to simulate the execution process of cross-domain tasks and run the atomic capability collaborative execution process. During the simulation, communication latency (data transmission latency between devices), resource consumption (CPU utilization, memory usage, etc.), and data security parameters (encryption strength, authentication success rate, etc.) are collected in real time. The collected parameters are compared with hard constraints. If any parameters are not met, such as communication latency exceeding requirements, resource consumption being too high, or data security parameters not meeting standards, adjustments and optimizations are made to the communication domain division or collaborative links. For example, communication domains are re-divided to reduce the number of devices within a domain, the routing paths of collaborative links are optimized to reduce communication latency, and communication protocols are changed to improve data transmission security. After multiple iterations of optimization until all parameters meet the hard constraints, the final distributed networking architecture is output.

[0132] Step S150: Based on the distributed networking architecture, control the device to perform cross-domain task collaborative operation, and at the same time collect device operation status data and link communication status data. Update the atomic capability combination method and communication domain boundary according to the status data to generate an updated networking form.

[0133] In smart new energy power stations, after the distributed network architecture is generated, it is synchronized to all participating distributed devices. Each device resolves its corresponding communication domain identifier, collaborative link role (such as master node, slave node, cache node, etc.), and data interaction rules within the architecture. Based on the resolution results, it activates the corresponding communication module and establishes communication connections with associated devices in the collaborative link according to the domain communication protocol and data interaction rules. Based on the atomic capability call order in the global capability resource graph, each device sequentially activates its corresponding atomic capability unit, executes predetermined functional operations, and records operational status data (execution progress, resource consumption, and output results). During collaborative execution, each device sends its own operational status data and atomic capability output results to associated devices in real time through the collaborative link, while simultaneously receiving information sent by associated devices to complete information synchronization. Each device has a built-in status acquisition module that continuously collects its own hardware operating parameters (CPU usage ratio, memory usage, temperature, etc.), software process status (process ID, running status, resource usage, etc.), and link communication parameters (communication latency, data transmission rate, packet loss ratio, etc.), generating device operational status data and link communication status data. The collected data is uploaded to the domain-wide collaborative control node. This node is elected autonomously by the devices within the domain (selecting the device with the best overall performance by comparing factors such as CPU performance, remaining memory, and network bandwidth). It is solely responsible for summarizing and analyzing status data. The collaborative control node analyzes the received data by type, identifying device operational anomalies (unexpected resource consumption, interruption of atomic capability execution, etc.) and link communication anomalies (increased communication latency, excessively high packet loss rate, etc.). When an anomaly is identified, the domain-wide atomic capability combination method is readjusted based on the global capability resource map (replacing the atomic capability execution device, adjusting the calling order, or enabling backup atomic capability units). Simultaneously, the communication domain boundaries and collaborative links are readjusted (removing the abnormal device from the current communication domain or splitting the communication domain into multiple subdomains), generating an updated plan, and replanning the collaborative links. The updated network architecture status data is collected, and the anomaly marking and readjustment process is repeated until the cross-domain task collaborative execution is completed.

[0134] Step S151: Synchronize the distributed networking architecture to all participating distributed devices, and each device parses its own corresponding communication domain identifier, collaborative link role and data interaction rules in the architecture.

[0135] After the distributed network architecture is generated, it is broadcast to all participating distributed devices. Upon receiving the distributed network architecture data, the device's communication module stores it in its local storage module. The parsing module parses the distributed network architecture, extracting information relevant to itself, including the communication domain identifier (e.g., "Domain001"), the collaborative link role (e.g., "master node"), and data interaction rules (e.g., data transmission format, communication frequency, encryption method, etc.). After parsing, this information is transmitted to the device's control module, enabling the control module to perform subsequent operations based on this information.

[0136] Step S152: Each distributed device starts its corresponding communication module based on the parsing result and establishes a communication connection with the associated device in the collaborative link according to the intra-domain communication protocol and data interaction rules.

[0137] The device's control module activates the corresponding communication module (such as an Ethernet module or a wireless communication module) based on the parsed communication domain identifier, cooperative link role, and data interaction rules. The communication module establishes a communication connection with associated devices in the cooperative link according to the intra-domain communication protocol (such as MQTT) and data interaction rules. When establishing a connection, a connection request is first sent, containing information such as the device's own identifier, communication domain identifier, and cooperative link role. The receiving device verifies the sender's identity and permissions; if verification is successful, it replies with a connection confirmation message, completing the establishment of the communication connection.

[0138] Step S153: Based on the atomic capability call order in the global capability resource graph, each distributed device sequentially activates the corresponding atomic capability unit, executes the predetermined functional operation, and records the running status data of the atomic capability unit, which includes execution progress, resource consumption and output results.

[0139] The device's control module obtains the atomic capability invocation order from the global capability resource map. This order is determined during the planning of the device's collaborative links. Following the invocation order, the corresponding atomic capability units are activated sequentially. During activation, the necessary resources (such as CPU time slices and memory space) are allocated to the atomic capability units, and they are initiated to execute predetermined functional operations. Simultaneously, the running status data of the atomic capability units is recorded. Execution progress is expressed as a percentage (e.g., 0% indicates not started, 100% indicates execution completed). Resource consumption includes CPU utilization and memory usage. The output is the data generated after the atomic capability units execute. This running status data is stored in real-time in the device's local log file.

[0140] Step S154: During the collaborative execution process, each distributed device sends its own operating status data and atomic capability output results to the associated device in real time through the collaborative link, and at the same time receives the operating status data and output results sent by the associated device to complete information synchronization.

[0141] During the execution of atomic capability units, the device's communication module sends its own operational status data (execution progress, resource consumption) and atomic capability output results to associated devices in real time via the collaborative link. The sending frequency is determined according to data interaction rules, such as once per second. Simultaneously, the communication module receives the operational status data and output results sent by associated devices and stores them in a local cache. The device's control module periodically reads the data from the local cache, updates its understanding of the operational status of associated devices, and completes information synchronization. Through information synchronization, each device can promptly understand the operational status of other devices in the collaborative link, ensuring the smooth progress of collaborative execution.

[0142] Step S155: Each distributed device has a built-in status acquisition module that continuously collects its own hardware operating parameters, software process status, and link communication parameters to generate device operating status data and link communication status data.

[0143] The device's built-in status acquisition module runs continuously in a multi-threaded manner, collecting data at fixed time intervals (e.g., E milliseconds). Hardware operating parameters include CPU utilization, memory usage, hard disk space utilization, power supply voltage, and device temperature, obtained by reading hardware interface parameters or system kernel parameters. Software process status includes the currently running process ID, process name, process priority, and CPU and memory resources used by the process, obtained through system calls. Link communication parameters include communication latency (obtained by sending test data packets and calculating round-trip time), data transmission rate (bytes transmitted per unit time), packet loss rate (number of lost packets divided by the total number of sent packets), and link connection stability (number of connection drops), obtained through network interface statistics and testing tools. These collected parameters are integrated to generate device operating status data and link communication status data.

[0144] Step S156: Upload the collected device operation status data and link communication status data to the domain collaborative control node. The collaborative control node is elected autonomously by the devices within the domain and is only responsible for the aggregation and analysis of status data.

[0145] The device's communication module encapsulates the collected device operating status data and link communication status data according to a preset format and uploads them to the domain's collaborative control node via the collaborative link. The collaborative control node is elected autonomously by the devices within the domain. The election process is as follows: Each device in the domain periodically sends its own performance metrics (CPU performance, remaining memory, network bandwidth, etc.) to other devices. Each device calculates a comprehensive score for other devices based on the received performance metrics and then sends its vote to the device with the highest comprehensive score. The device with the most votes is elected as the collaborative control node, with a term of F minutes. A new election is held after the term ends. The collaborative control node is only responsible for receiving, summarizing, and analyzing the status data uploaded by each device in the domain; it does not participate in the execution of specific atomic capability units or the control of the collaborative link.

[0146] Step S157: The collaborative control node analyzes the received device operation status data and link communication status data according to the data type to identify device operation anomalies and link communication anomalies. Among them, anomalies include resource consumption exceeding expectations, increased communication latency, and interruption of atomic capability execution.

[0147] After receiving device operation status data and link communication status data uploaded by all distributed devices within the domain, the collaborative control node classifies the data according to its source and indicator type, adds timestamps, and generates a status data time series. Key indicators are extracted from the status data time series. Key indicators for device operation status include CPU utilization, memory usage, atomic capability execution progress, and output result integrity; key indicators for link communication status include communication latency, data transmission rate, packet loss rate, and link connection stability. From the collaborative constraints of cross-domain tasks and the attribute description information of atomic capability units, preset normal operation thresholds for each key indicator are extracted, generating an indicator threshold set. The values ​​of key indicators in the status data time series are compared with the corresponding indicator thresholds to identify indicator data exceeding the normal operation range, marking them as abnormal candidate data. For abnormal candidate data, it is checked whether the same indicator appears repeatedly within a preset number of consecutive collection periods for the same device or link. If so, a persistent flag is marked for the abnormal candidate data. Based on the type of persistent abnormal indicator, it is categorized as resource consumption exceeding expectations, increased communication latency or link instability, or atomic capability execution interruption. Based on the atomic capability relationships and collaborative link structure, the device, link, or atomic capability unit directly associated with the anomaly is located and identified. The identified anomaly type, the directly associated device, link, or atomic capability unit identifier, the anomaly occurrence time, and the source tracing analysis results are integrated to generate an anomaly analysis report.

[0148] Step S1571: The collaborative control node receives device operation status data and link communication status data uploaded by all distributed devices in the domain, classifies them according to data source and indicator type, adds timestamps, and generates a status data time series.

[0149] After receiving data uploaded by each device, the receiving module of the collaborative control node first decapsulates the data, extracting information such as device identifier, data type (device operating status data or link communication status data), indicator name, and indicator value. Then, it categorizes the data according to its source (device identifier) ​​and indicator type (such as CPU utilization rate, communication latency, etc.). Each data entry is timestamped to the millisecond level. The categorized, timestamped data is arranged chronologically to generate a time series of status data. For example, for the CPU utilization rate indicator of device "DEV001," a sequence containing the timestamp and the corresponding CPU utilization rate value is generated.

[0150] Step S1572: Extract key indicators from the time series of status data. Key indicators of device operation status include CPU utilization ratio, memory usage, atomic capability execution progress, and output result integrity. Key indicators of link communication status include communication latency, data transmission rate, packet loss ratio, and link connection stability.

[0151] Key metrics are extracted from the time series of status data. For device operation status data, key metrics include CPU utilization (percentage of device CPU used), memory usage (current memory usage of the device), atomic capability execution progress (percentage of atomic capability units completed), and output completeness (whether the output result is complete, represented by a Boolean value). For link communication status data, key metrics include communication latency (round-trip time for data transmission), data transmission rate (amount of data transmitted per unit time), packet loss rate (ratio of lost packets to total number of packets sent), and link connection stability (number of times the link connection is lost per unit time).

[0152] Step S1573: Extract the preset normal operation threshold of each key indicator from the collaborative constraints of cross-domain tasks and the attribute description information of atomic capability units, and generate an indicator threshold set.

[0153] The collaborative constraints of cross-domain tasks include overall requirements for device operation and link communication, while the attribute description information of atomic capability units includes specific indicators such as resource consumption during the execution of that unit. From this information, preset normal operation thresholds for each key indicator are extracted, such as a normal threshold for CPU utilization of 0%-Y% and a normal threshold for communication latency of 0-X milliseconds. These thresholds are then organized according to the key indicator names to generate an indicator threshold set, such as {"CPU Utilization":[0, Y%], "Communication Latency":[0, X milliseconds], ...}.

[0154] Step S1574: Compare the key indicator values ​​in the time series of status data with the corresponding indicator thresholds, identify indicator data that exceeds the normal operating range, and mark them as abnormal candidate data.

[0155] Iterate through each data point in the time series of status data, comparing the key indicator value with the corresponding threshold in the indicator threshold set. If the indicator value is less than the lower threshold or greater than the upper threshold, the data point is outside the normal operating range and is marked as an abnormal candidate data. For example, if the CPU usage ratio is (Y+1)%, exceeding the upper threshold Y%, it is marked as an abnormal candidate data.

[0156] Step S1575: For abnormal candidate data, check whether the same abnormal candidate data of the same indicator appears in the same device or link within a continuous preset number of collection cycles. If so, mark the abnormal candidate data with a persistence flag.

[0157] The preset number of consecutive data collection periods is G. For indicator data marked as abnormal candidate data, it is checked whether the same device or link shows abnormal candidate data for the same indicator in the next (G-1) collection periods. For example, if the CPU utilization rate of device "DEV001" exceeds Y% in G consecutive collection periods, then these abnormal candidate data are marked with a persistence flag, indicating that the anomaly is not an accidental phenomenon, but a persistent one.

[0158] Step S1576: Based on the type of persistent anomaly indicator, classify it as an anomaly of resource consumption exceeding expectations, an anomaly of increased communication latency or link instability, or an anomaly of interruption of atomic capability execution.

[0159] Based on the key indicator type of persistent anomalies, anomalies are categorized. If the anomaly indicator is CPU usage or memory usage, it is categorized as resource consumption exceeding expectations. If the anomaly indicator is communication latency, packet loss rate, or link connection stability, it is categorized as increased communication latency or link instability. If the anomaly indicator is atomic capability execution progress (stagnant for a long time) or output integrity (incomplete output), it is categorized as atomic capability execution interruption.

[0160] Step S1577: Based on the atomic capability association and cooperative link structure, locate and determine the device, link or atomic capability unit identifier directly associated with the anomaly.

[0161] Based on the atomic capability association table and the collaborative link structure, analyze the device, link, or atomic capability unit to which the abnormal indicator belongs. For example, if the device with abnormal CPU utilization is "DEV001", then the directly associated device is identified as "DEV001"; if the link with abnormal communication latency is "Path001", then the directly associated link is identified as "Path001"; if the atomic capability unit with abnormal atomic capability execution progress is "ACU001", then the directly associated atomic capability unit is identified as "ACU001-DEV001".

[0162] Step S1578: Integrate the identified anomaly type, directly associated device, link or atomic capability unit identifier, anomaly occurrence time, and source tracing analysis results to generate an anomaly analysis report.

[0163] The anomaly analysis report is generated by integrating the anomaly type (e.g., resource consumption exceeding expectations), the identifier of the directly associated device, link, or atomic capability unit, the anomaly occurrence time (the earliest timestamp of the anomaly), and the results of the source tracing analysis (e.g., possible causes of the anomaly, such as hardware failure or software bug). The report is in a structured document format and includes basic anomaly information, a detailed description of the anomaly, and possible solution suggestions.

[0164] Step S158: When an anomaly is identified, the collaborative control node readjusts the atomic capability combination method within the domain based on the global capability resource map. The readjustment includes replacing the atomic capability execution device, adjusting the calling order, or enabling a backup atomic capability unit. At the same time, the communication domain boundary and collaborative link are readjusted to generate a scheme to remove the abnormal device from the current communication domain or split the communication domain into multiple subdomains, and the collaborative link is replanned based on the new scheme.

[0165] When an anomaly is detected, the collaborative control node determines the target range for recalculating atomic capability combinations and collaborative links based on the anomaly type and its associated device, link, or atomic capability unit identifier in the anomaly analysis report. When the anomaly type is resource consumption exceeding expectations, devices within the current communication domain that have the same capability identifier in their attribute description information as the anomaly atomic capability unit and whose real-time resource remaining amount is higher than a preset safety threshold are retrieved from the global capability resource graph as candidate replacement devices. In the simulation environment, the atomic capability units of the candidate replacement devices are tested using the input data of the current collaborative link to verify whether their output meets the input requirements of subsequent units. Instructions are generated to direct the atomic capability execution tasks on the anomaly device to the candidate replacement device, an updated collaborative link configuration is generated, and instructions to terminate the operation of the atomic capability unit on the anomaly device are generated. When the anomaly type is atomic capability execution interruption, atomic capability units with complementary functions are searched from the global capability resource graph, their dependencies with other atomic capability units in the current collaborative link are analyzed, the atomic capability call order is adjusted, and a new call sequence is generated. When the anomaly type is increased communication latency or link instability, the number or proportion of cross-communication domain atomic capability calls in the current atomic capability combination method is counted. If it exceeds a preset threshold, the call order is adjusted, replacing cross-domain calls that can be replaced by intra-domain atomic capability units with intra-domain calls. If there is no suitable replacement device or complementary atomic capability unit within the domain, devices with corresponding atomic capabilities in other communication domains are searched from the global capability resource map, the cross-domain atomic capability call process is initiated, and the cross-domain collaborative link is replanned. At the same time, the communication domain boundaries are readjusted, the abnormal device is removed from the current communication domain or the communication domain is split into multiple subdomains, and the collaborative link is replanned based on the new communication domain division scheme.

[0166] For example, in step S1581: when an anomaly is marked, the cooperative control node determines the target range of the atomic capability combination and cooperative link that needs to be recalculated based on the anomaly mark and its associated device, link or atomic capability unit identifier.

[0167] After receiving the anomaly analysis report, the collaborative control node determines the target scope for recalculating atomic capability combinations and collaborative links based on the anomaly type marked in the report and the associated device, link, or atomic capability unit identifier. For example, if the anomaly is associated with a specific atomic capability unit, the target scope is the collaborative link where that atomic capability unit resides; if the anomaly is associated with a communication link, the target scope is all atomic capability units using that link and their collaborative links; if the anomaly is associated with a device, the target scope is all atomic capability units on that device and the collaborative links they participate in.

[0168] Step S1582: When the anomaly type is resource consumption exceeding expectations, retrieve from the global capability resource map devices in the current communication domain that have the same capability identifier as the abnormal atomic capability unit in the attribute description information and whose real-time resource remaining amount is higher than the preset security threshold, and use them as candidate replacement devices.

[0169] When the anomaly type is resource consumption exceeding expectations, the collaborative control node filters all devices within the current communication domain from the global capability resource map. For each device, its atomic capability description information is checked, and atomic capability units with the same capability identifier as the anomalous atomic capability unit are found. Then, the real-time remaining resources of these devices (such as remaining CPU processing power, remaining memory capacity, etc.) are obtained and compared with preset safety thresholds (such as remaining CPU processing power greater than H%, remaining memory capacity greater than 1GB). Devices with real-time remaining resources higher than the preset safety threshold are marked as candidate replacement devices.

[0170] Step S1583: In the simulation environment, use the input data of the current cooperative link to test the atomic capability unit of the candidate replacement device and verify whether its output meets the input requirements of the subsequent unit.

[0171] The collaborative control node sets up a test environment identical to the current collaborative link in the simulation environment, and deploys the atomic capability units of the candidate replacement device into the simulation environment. Using the input data of the abnormal atomic capability units in the current collaborative link as test input, the execution of the atomic capability units of the candidate replacement device is initiated. The output results are collected and compared with the expected output results of the abnormal atomic capability units to check whether they meet the input requirements of subsequent atomic capability units (such as data format, data range, etc.). If the output results meet the requirements, the candidate replacement device is considered qualified.

[0172] Step S1584: Generate an instruction to direct the execution task of the atomic capability on the faulty device to the candidate replacement device, generate an updated cooperative link configuration, the configuration including a new device identifier and data transmission path, and generate an instruction to terminate the operation of the atomic capability unit on the faulty device.

[0173] For a verified candidate replacement device, the collaborative control node generates instructions to transfer the atomic capability execution task on the faulty device to the candidate replacement device. Simultaneously, it generates an updated collaborative link configuration, updating the configuration so that the device identifier related to that atomic capability unit is the identifier of the candidate replacement device, and re-plans the data transmission path (the path from the candidate replacement device to subsequent atomic capability units). Furthermore, it generates instructions to terminate the operation of that atomic capability unit on the faulty device, ensuring that the faulty device no longer executes the task and releasing resources.

[0174] Step S1585: When the exception type is atomic capability execution interruption, search for atomic capability units with complementary functions from the global capability resource graph. The atomic capability unit can replace the failed atomic capability unit to complete the same execution goal.

[0175] When the exception type is atomic capability execution interruption, the collaborative control node searches the global capability resource graph for atomic capability units that have a complementary relationship with the failed atomic capability unit. These complementary atomic capability units can jointly complete the same execution goal as the failed atomic capability unit, or can complete the execution goal individually. The node finds atomic capability units that meet the criteria by checking the complementary relationship records in the atomic capability association table.

[0176] Step S1586: Analyze the dependencies between complementary atomic capability units and other atomic capability units in the current cooperative link, adjust the atomic capability call order, generate a new call sequence, and include the complementary atomic capability units in the new call sequence.

[0177] Obtain the attribute description information of complementary atomic capability units and analyze their dependencies with other atomic capability units in the current collaborative link (whether the input resource types match, whether the output result format meets the input requirements of subsequent units, etc.). Based on the dependencies, adjust the calling order of atomic capabilities, insert complementary atomic capability units into appropriate positions, and generate a new calling sequence. Ensure that the new calling sequence satisfies the dependencies of all atomic capability units.

[0178] Step S1587: When the anomaly type is communication latency increase or link instability anomaly, count the number or proportion of atomic capability calls across communication domains in the current atomic capability combination method and compare it with a preset threshold; if it exceeds the preset threshold, adjust the call order and replace cross-domain calls that can be replaced by intra-domain atomic capability units in the call order with intra-domain calls to reduce the amount of cross-domain data transmission.

[0179] When the anomaly type is increased communication latency or link instability, the collaborative control node counts the number or proportion of cross-communication domain atomic capability calls in the current atomic capability combination method (number of cross-domain calls divided by the total number of calls). The statistical results are compared with a preset threshold (e.g., J%). If the threshold is exceeded, it indicates excessive cross-domain data transmission, which may be the cause of increased communication latency or link instability. In this case, the cross-domain calls in the call sequence are analyzed to check for cross-domain calls that can be replaced by atomic capability units within the domain (i.e., atomic capability units with the same function exist within the domain). If such replacements exist, the call sequence is adjusted, replacing cross-domain calls with intra-domain calls to reduce cross-domain data transmission and alleviate communication pressure.

[0180] Step S1588: When there is no suitable replacement device or complementary atomic capability unit in the domain, search for devices with corresponding atomic capabilities in other communication domains from the global capability resource map, start the cross-domain atomic capability invocation process, and re-plan the cross-domain collaborative link.

[0181] If no suitable replacement device or complementary atomic capability unit can be found within the current communication domain, the collaborative control node searches for devices with the corresponding atomic capabilities in other communication domains from the global capability resource map. Once found, it initiates the cross-domain atomic capability invocation process, negotiating with the collaborative control node in the communication domain where the target device resides to establish a cross-domain collaborative link. The routing path and interface specifications of the cross-domain collaborative link are then redesigned to ensure the smooth execution of the cross-domain atomic capability invocation.

[0182] Step S1589: After generating a new atomic capability combination and cooperative link scheme, synchronously update the local atomic capability association and cooperative link model, and distribute the updated execution instructions and communication parameters to all relevant devices.

[0183] After generating a new atomic capability combination and collaborative link scheme, the collaborative control node updates its locally stored atomic capability association table and collaborative link model to ensure consistency with the new scheme. Then, it distributes the updated execution instructions (such as atomic capability call order and device identifiers) and communication parameters (such as data transmission paths and interface specifications) to all relevant devices via the collaborative link. Upon receiving the updated instructions and parameters, the relevant devices update their own configurations and execute collaborative operations according to the new scheme.

[0184] Step S15810: After implementing the adjustment plan, collect new device operating status data and link communication status data, and execute the anomaly marking process again.

[0185] After the relevant devices perform collaborative operations according to the updated plan, the collaborative control node continuously collects new device operating status data and link communication status data. Then, the anomaly marking process is executed again to check whether the adjusted plan has resolved the previous anomalies and whether any new anomalies have occurred. If anomalies still exist, the adjustment process is repeated until the anomalies are resolved.

[0186] Step S159: Collect the updated device operation status data and link communication status data of the distributed networking architecture, repeat the anomaly marking and readjustment process until the cross-domain task collaborative execution is completed.

[0187] After updating the distributed network architecture, the collaborative control node continues to collect device operating status data and link communication status data. Following the anomaly marking process in step S157, the above data is analyzed to identify any new anomalies. If an anomaly is found, it is processed according to the readjustment process in step S158 to generate a new adjustment plan. The anomaly marking and readjustment process is repeated until the cross-domain task collaborative execution is completed, all atomic capability units have successfully executed, and the output meets the requirements.

[0188] In one exemplary embodiment, a task-coordinated distributed device adaptive networking system is provided. This system can be a terminal, a server, etc., and its internal structure diagram can be as follows: Figure 2 As shown, this task-oriented collaborative distributed device adaptive networking system includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. 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 and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, near-field communication, or other technologies. When the computer program is executed by the processor, it implements a task-oriented collaborative distributed device adaptive networking method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device can be a touch layer covering the display screen, or a button, trackball, or touchpad set on the shell of a distributed device adaptive networking system for task collaboration, or an external keyboard, touchpad, or mouse, etc.

[0189] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A distributed device adaptive networking method for task collaboration, characterized in that, The method includes: Receive cross-domain task requirement information, parse the cross-domain task requirement information, extract functional requirements, interaction logic and constraint parameters, and generate a set of task execution elements and collaborative constraints. The set of task execution elements reflects the functional types and interaction relationships required to complete the cross-domain task, and the collaborative constraints include the operating specifications in the networking process. Based on the set of task execution elements, the autonomous activation process of the distributed device capability is initiated, triggering each distributed device to disassemble its own functional modules, generate atomic capability description information, and release it to the network environment. Through a distributed peer-to-peer discovery process, atomic capability description information of all distributed devices is exchanged and aggregated to generate a global capability resource map, which presents the distribution and correlation characteristics of all atomic capabilities in the network. Based on the global capability resource map and the collaborative constraints, a communication domain partitioning without a central node and a device collaborative link construction are performed to generate a distributed networking architecture. Based on the distributed networking architecture, the control device performs cross-domain task collaborative operation, while collecting device operation status data and link communication status data. The atomic capability combination method and communication domain boundary are updated according to the status data to generate an updated networking configuration. The process of initiating the autonomous activation of distributed device capabilities based on the set of task execution elements triggers each distributed device to decompose its own functional modules, generate atomic capability description information, and release it to the network environment, including: Each distributed device receives the task execution element set, matches function type keywords and interaction relationship descriptions from the task execution element set, and generates the association mapping relationship of its own functional modules; Initiate the device's built-in function module scanning process, traverse the physical function units corresponding to the hardware components and the logical function units supported by the software system, and extract all independently executable basic function items; Based on the minimum granularity standard of function execution, the extracted basic functional items are broken down into indivisible atomic capability units, and each atomic capability unit corresponds to a single execution target. Add attribute description information to each atomic capability unit. The attribute description information includes the input resource type required for execution, the output result format, the interaction triggering conditions and resource consumption characteristics, and configure interactive attributes for the atomic capability unit. The attribute description information of each atomic capability unit is associated with the corresponding functional identifier and integrated to form a structured atomic capability description information. The atomic capability description information is organized in a unified data format to support mutual recognition of atomic capability description information of different devices. Based on the interaction relationship description in the set of task execution elements, a collaboration tag is added to each atomic capability description information. The collaboration tag is used to identify the collaboration role and associated atomic capability type of the atomic capability unit in the cross-domain task. Configure capability release trigger conditions in distributed devices. The trigger conditions are based on the matching degree between the collaborative tags in the atomic capability description information and the set of task execution elements, and trigger the release of the atomic capability description information. When the triggering condition is met, the distributed device sends its atomic capability description information in the form of a data frame to all reachable devices in the network environment through a preset broadcast interface. The data frame contains the device identifier and the atomic capability identifier. During the transmission of atomic capability description information, a dynamic time slot allocation method is adopted to adjust the transmission time window according to the number of devices in the network and the data transmission frequency, so as to reduce the probability of data frame collision. After receiving atomic capability description information sent by other devices, each distributed device parses and stores it according to a unified data format, generates a local atomic capability resource cache set, and continuously listens for capability release signals in the network until all relevant devices complete the release of atomic capability description information. The distributed peer-to-peer discovery process enables the exchange and aggregation of atomic capability description information among all distributed devices, generating a global capability resource map. This map presents the distribution and correlation characteristics of all atomic capabilities in the network, including: Each distributed device initiates a peer discovery protocol to scan the broadcast signals of other devices in the network environment and obtain the device identifiers and communication addresses of all devices that have released atomic capability description information. Based on the obtained communication address, each distributed device establishes a temporary peer-to-peer communication connection with other devices. The temporary peer-to-peer communication connection does not rely on the central node for forwarding and directly realizes data interaction between devices. Through the established temporary peer-to-peer communication connection, each distributed device sends its own atomic capability description information to other connected devices, and at the same time receives atomic capability description information sent by other devices, thus completing bidirectional information exchange; The received atomic capability description information is integrated in a complete manner, and the atomic capability description information from different devices is classified according to function type, generating an association mapping relationship between function type, atomic capability, and device identifier; By comparing the attribute description information of different atomic capability units under the same functional type, and based on the input-output matching rules and execution target combination, complementary and dependent relationships are established between atomic capability units. The complementary relationship refers to different atomic capability units jointly completing a certain composite function, and the dependent relationship refers to the execution of one atomic capability unit taking the output of another atomic capability unit as input. Based on the association mapping relationship and the identified complementary and dependent relationships, a capability association topology is generated. In the capability association topology, each node represents an atomic capability unit, and the connection between nodes represents the association relationship. Associate device location information and resource consumption characteristic data on each node in the capability association topology, traverse the capability association topology, merge atomic capability nodes with completely consistent attribute description information, remove redundant association links, and integrate the adjusted capability association topology with association mapping relationships, complementary relationships, and dependency relationships to generate an initial version of the global capability resource graph. Each distributed device merges its own generated initial version of the global capability resource graph with the versions received from other devices, supplements missing nodes and related edges, and handles inconsistent descriptions using preset conflict resolution rules to generate a unified global capability resource graph.

2. The distributed device adaptive networking method for task collaboration according to claim 1, characterized in that, Based on the global capability resource map and the collaborative constraints, the process of performing communication domain partitioning without a central node and constructing device collaborative links to generate a distributed network architecture includes: The collaborative constraints are analyzed, and the communication latency requirements, data transmission security requirements, resource consumption limits, and collaborative response requirements contained therein are extracted to generate hard constraint indicators for the networking process. Based on the device location information and atomic capability association relationship in the global capability resource map, the devices are grouped into candidate communication domains according to the preset geographical proximity threshold and association degree threshold. Each candidate communication domain contains multiple distributed devices whose atomic capabilities meet the preset association conditions. Based on the communication delay requirements in the hard constraint indicators, the communication delay between devices within each candidate communication domain is measured. If the communication delay exceeds the communication delay requirements, the device composition of the candidate communication domain is split or adjusted according to preset rules. Based on the resource occupancy limit in the hard constraint index, calculate the total resource amount of the devices in each candidate communication domain and compare it with the estimated total consumption of atomic capacity resources to be scheduled in the candidate communication domain. If the total resource amount is lower than the estimated consumption amount, expand the device composition of the candidate communication domain according to the preset rules. Each candidate communication domain is assigned a unique domain identifier, and the communication protocol and data interaction rules of the devices within the domain are configured. The communication protocol and data interaction rules meet the data transmission security requirements in the hard constraint indicators. Based on the atomic capability dependencies and complementarities in the global capability resource graph, device collaboration links are planned in each communication domain, the calling order and data transmission path of each atomic capability unit are configured, and a backup link is configured for each device collaboration link, and the primary / backup switching trigger conditions are set. Analyze the atomic capability association requirements between different communication domains, plan cross-communication domain collaborative links, and configure interface specifications and routing paths for cross-domain data transmission to support the collaborative scheduling of atomic capabilities across all domains. The communication domain division results, intra-domain collaborative links, cross-domain collaborative links, communication protocols, and data interaction rules are integrated to generate a preliminary distributed networking architecture. Load a preliminary distributed networking architecture in the simulation environment, run the atomic capability collaborative execution process, collect the simulation communication latency, resource consumption, and data security parameters, compare them with hard constraint indicators, iteratively optimize the communication domain division or collaborative links that do not meet the indicators, and output the final distributed networking architecture.

3. The distributed device adaptive networking method for task collaboration according to claim 1, characterized in that, Based on the distributed networking architecture, the control device performs cross-domain task collaborative operations, while simultaneously collecting device operating status data and link communication status data. Based on the status data, the atomic capability combination method and communication domain boundary are updated to generate an updated network configuration, including: The distributed networking architecture is synchronized to all participating distributed devices, and each device parses its own corresponding communication domain identifier, collaborative link role, and data interaction rules in the architecture; Each distributed device starts its corresponding communication module based on the parsing results and establishes a communication connection with the associated devices in the collaborative link according to the intra-domain communication protocol and data interaction rules. Based on the atomic capability invocation order in the global capability resource graph, each distributed device sequentially activates the corresponding atomic capability unit, executes the predetermined functional operation, and records the running status data of the atomic capability unit, which includes execution progress, resource consumption and output results. During collaborative execution, each distributed device sends its own operational status data and atomic capability output results to the associated device in real time through the collaborative link, and at the same time receives the operational status data and output results sent by the associated device to complete information synchronization; Each distributed device has a built-in status acquisition module that continuously collects its own hardware operating parameters, software process status, and link communication parameters to generate device operating status data and link communication status data. The collected device operation status data and link communication status data are uploaded to the domain collaborative control node. The collaborative control node is elected autonomously by the devices in the domain and is only responsible for the collection and analysis of status data. The collaborative control node analyzes the received device operation status data and link communication status data according to data type to identify device operation anomalies and link communication anomalies. Among them, anomalies include resource consumption exceeding expectations, increased communication latency, and interruption of atomic capability execution. When an anomaly is detected, the collaborative control node readjusts the atomic capability combination method within the domain based on the global capability resource map. The readjustment includes replacing the atomic capability execution device, adjusting the calling order, or enabling a backup atomic capability unit. At the same time, the communication domain boundary and collaborative link are readjusted to generate a scheme to remove the abnormal device from the current communication domain or split the communication domain into multiple subdomains, and the collaborative link is replanned based on the new scheme. Collect updated device operation status data and link communication status data of the distributed networking architecture, repeat anomaly marking and readjusting the process until the cross-domain task collaborative execution is completed.

4. The task-oriented distributed device adaptive networking method according to claim 1, characterized in that, The basic functional items are extracted and broken down according to the minimum granularity standard of functional execution. Composite functional items are decomposed into indivisible atomic capability units, each corresponding to a single execution target, including: Define the minimum granularity standard for function execution. The minimum granularity standard includes: the atomic capability unit has independent input interface, processing logic and output interface, and its processing logic cannot be divided into multiple sub-logic units with complete input and output. Iterate through each extracted basic functional item, parse its execution logic, and if its logic flow contains sub-flows that can be triggered independently and produce intermediate outputs, it is determined to be divisible. For divisible composite functional items, according to the order of the core execution steps, it is divided into multiple sub-functional items, and each sub-functional item corresponds to an intermediate execution target. For each sub-function item, the execution logic is analyzed again to check whether it meets the minimum granularity standard for function execution. If it does not meet the standard, it is further broken down until all the broken-down functional units meet the minimum granularity standard. Each split atomic capability unit is assigned a unique capability identifier, which is combined with the device identifier to form a unique global capability identifier. Configure the execution target description for each atomic capability unit, analyze the execution environment requirements for each atomic capability unit, and extract the hardware support conditions and software dependency components required for its operation; Test the independent execution capability of each atomic unit. Without the help of other functional units, input the required resources to it and check whether it can independently complete the execution target and output a valid result. When an atomic capability unit that cannot be executed independently is detected, the splitting method is readjusted so that all atomic capability units have the ability to execute independently. All eligible atomic capability units are compiled to generate a device atomic capability list. Each item in the list includes an atomic capability identifier, an execution target description, execution environment requirements, and independent execution test results.

5. The distributed device adaptive networking method for task collaboration according to claim 1, characterized in that, The method compares the attribute description information of different atomic capability units under the same functional type, and establishes complementary and dependent relationships between atomic capability units based on input-output matching rules and execution target combinations. The complementary relationship refers to different atomic capability units jointly completing a composite function, and the dependent relationship refers to the execution of one atomic capability unit using the output of another atomic capability unit as input. This includes: Obtain the attribute description information of all atomic capability units under the same functional type. The attribute description information includes the input resource type, output result format, and execution target description. The output format of each atomic capability unit is matched with the input resource type of other atomic capability units. If a match is found, a potential dependency relationship is established between the two. For atomic capability unit pairs marked with potential dependencies, the execution process is simulated in a simulation environment to verify whether the output of the previous unit can drive the execution of the next unit and produce an output that meets its execution goal. Test valid dependencies, configure dependency direction and dependency conditions, and record them as formal dependencies. Dependency direction refers to the previous atomic capability unit pointing to the next atomic capability unit, and dependency conditions refer to the specific matching requirements of the input resource. Analyze the execution target descriptions of multiple atomic capability units under the same functional type, and identify combinations of atomic capabilities that can jointly complete a composite function not covered by a single atomic capability unit; The identified atomic capability combinations are subjected to collaborative execution simulation. The atomic capability units in the atomic capability combination are called in a reasonable order, and the set of output results is checked to see if they achieve the composite functional goal. The atomic capability combinations that are successfully verified by simulation are recorded as complementary relationships, and the atomic capability unit identifier list, preset calling sequence and interaction interface protocol of the atomic capability combination are stored. Formal dependencies and complementary relationships are categorized and organized according to functional type, and an atomic capability association table is established. The association table includes the association type, the identifiers of the associated parties, and the dependency conditions or collaboration methods. Traverse the dependencies in the association table, check for circular dependency paths, and if they exist, adjust the splitting granularity or input / output attribute descriptions of the atomic capability units involved in the cycle according to preset rules until the circular path is eliminated. Then, associate and store the adjusted association table with the atomic capability description information.

6. The task-oriented distributed device adaptive networking method according to claim 2, characterized in that, The process of planning device collaboration links within each communication domain and configuring the calling order and data transmission path of each atomic capability unit based on the atomic capability dependency and complementarity relationships in the global capability resource graph includes: Extract the atomic capability dependencies and complementarities within the current communication domain from the global capability resource graph, and generate an atomic capability association subgraph within the domain. Starting with the execution target of the cross-domain task, traverse the atomic capability association subgraph within the domain, select atomic capability units that can directly or indirectly contribute to the execution target, and mark them as core and associated atomic capability units; Based on the atomic capability dependencies, the core and associated atomic capability units are topologically sorted to generate a preliminary execution sequence that satisfies the dependencies, in which the preceding unit is located before the following unit; Based on the complementary relationship of atomic capabilities, the atomic capability unit groups that can be executed in parallel are marked in the preliminary execution sequence, and the data synchronization points between units within the atomic capability unit groups are configured. Based on the physical location of the execution device corresponding to each atomic capability unit and historical communication quality data, calculate the data transmission path between each atomic capability unit, and select the path with fewer hops and historical communication quality higher than a preset threshold. Assign a unique path identifier to each data transmission path, and configure the data transmission format and verification method on each data transmission path; In the planned data transmission path, configure data cache nodes to temporarily store the output results of atomic capability units; Analyze the execution time of each atomic capability unit in the execution sequence, and allocate an execution time window to each atomic capability unit. The execution window does not conflict with the data transmission time. Generate a device collaboration link model, which includes execution sequence, data transmission path, path identifier, data cache node location, and time window allocation information; Run the device collaboration link model in the simulation environment to verify whether the calling order of atomic capability units violates the definition of dependency and complementarity, detect whether the latency of the data transmission path exceeds the limit, and whether the time windows overlap. Iteratively correct the links that fail to be verified according to the preset strategy, and output the final device collaboration link.

7. The task-oriented distributed device adaptive networking method according to claim 3, characterized in that, The collaborative control node analyzes the received device operation status data and link communication status data according to data type to identify device operation anomalies and link communication anomalies. These anomalies include unexpected resource consumption, increased communication latency, and interruption of atomic capability execution. The collaborative control node receives device operation status data and link communication status data uploaded by all distributed devices in the domain, classifies them according to data source and indicator type, and adds timestamps to generate a time series of status data. Key indicators are extracted from the time series of status data. Key indicators of device operation status include CPU utilization, memory usage, atomic capability execution progress, and output result integrity. Key indicators of link communication status include communication latency, data transmission rate, packet loss rate, and link connection stability. From the collaborative constraints of cross-domain tasks and the attribute description information of atomic capability units, the preset normal operation threshold of each key indicator is extracted to generate an indicator threshold set. The key indicator values ​​in the time series of status data are compared with the corresponding indicator thresholds to identify indicator data that exceeds the normal operating range and mark them as abnormal candidate data. For abnormal candidate data, check whether the same abnormal candidate data of the same indicator appears in the same device or link within a consecutive preset number of collection periods. If so, mark the abnormal candidate data with a persistence flag. Based on the type of persistent anomaly indicator, it is classified as anomaly of resource consumption exceeding expectations, anomaly of increased communication latency or link instability, or anomaly of interruption of atomic capability execution. Based on the atomic capability association and cooperative link structure, locate and determine the device, link or atomic capability unit identifier directly associated with the anomaly; The identified anomaly type, the directly associated device, link or atomic capability unit identifier, the anomaly occurrence time, and the source analysis results are integrated to generate an anomaly analysis report.

8. A distributed device adaptive networking system for task collaboration, characterized in that, include: processor; A machine-readable storage medium for storing machine-executable instructions of the processor; The processor is configured to execute the task-oriented collaborative distributed device adaptive networking method according to any one of claims 1 to 7 by executing the machine-executable instructions.

Images