Cooperative control method and device among multiple devices, electronic device and storage medium

Abstract

The invention relates to the technical field of digital twinning, and discloses a cooperative control method and device among multiple devices, an electronic device and a storage medium, and the cooperative control method comprises the steps: determining a to-be-taken-over device according to the data transmission time delay between a fault device and each other device, and the residual calculation power and data processing duration of each other device; inputting a state vector representing the state information of the fault equipment, and the total data transmission time delay and the residual computing power of each piece of to-be-taken-over equipment into a prediction model, so that the prediction model determines the taken-over equipment; and issuing the control instruction packet including the verification key to the takeover device, so that the takeover device performs takeover control on the fault device under the condition of successful verification based on the verification key. According to the invention, synchronous operation of the working tasks of the fault equipment can be ensured, and the working efficiency of the equipment cluster is prevented from being influenced by the equipment fault, so that the working efficiency of the equipment cluster is improved.

Description

Technical Field

[0001] This application relates to the field of digital twin technology, specifically to a method, apparatus, electronic device, and storage medium for collaborative control among multiple devices. Background Technology

[0002] In multi-device scenarios, when a device malfunctions, it typically becomes offline and ceases operation, impacting the overall efficiency and task completion rate of the device cluster. Related technologies employ manual troubleshooting to resolve the faulty device, which then resumes its tasks after the fault is resolved. This process is time-consuming and significantly hinders the overall efficiency of the device cluster. Summary of the Invention

[0003] In view of the above problems, this application provides a collaborative control method, apparatus, electronic device and storage medium among multiple devices, for quickly identifying the takeover device of the faulty device to take over and handle the working tasks of the faulty device, thereby improving the working efficiency of the device cluster.

[0004] According to one aspect of this application, a collaborative control method for multiple devices is provided. The collaborative control method includes: determining a device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device; inputting a state vector representing the state information of the faulty device, the total data transmission delay of each device to be taken over, and the remaining computing power of each device to be taken over into a prediction model, so that the prediction model determines the device to be taken over; and sending a control instruction packet including a verification key to the device to be taken over, so that the device to be taken over controls the faulty device if the verification is successful based on the verification key.

[0005] In one optional approach, the collaborative control method further includes: determining a data acquisition time interval based on the time when the faulty device malfunctions and a preset extension duration; within the data acquisition time interval, acquiring the data stream corresponding to the faulty device based on a preset length time window, and generating a state vector based on the data stream to characterize the state information of the faulty device.

[0006] In one optional approach, the step of acquiring the data stream corresponding to the faulty device based on a preset length time window includes: starting from the beginning of the data capture time interval, sliding a preset length time window according to a preset step size to acquire raw data corresponding to multiple time windows, so as to obtain the data stream corresponding to the faulty device; the step of generating a state vector representing the state information of the faulty device based on the data stream includes: performing feature extraction on the data stream, and generating a feature matrix based on the extracted feature data; performing dimensionality compression processing on the feature matrix to obtain a state vector representing the state information of the faulty device.

[0007] In one alternative approach, the collaborative control method further includes: after the fault of the faulty device is eliminated, filtering the fault lifecycle data and using the filtered data to update the fault knowledge base; wherein the fault lifecycle data includes the data stream and a state vector representing the state information of the faulty device.

[0008] In one alternative approach, before determining the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device, the collaborative control method further includes: detecting whether the signal amplitude transition ratio of all devices is greater than a preset transition ratio; if the signal amplitude transition ratio of the target device is detected to be greater than the preset transition ratio, then the target device is designated as the faulty device.

[0009] In one optional approach, determining the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device, includes: calculating the data transmission delay between the faulty device and each other device based on the location distance between the faulty device and each other device, and the environmental signal-to-noise ratio; designating other devices whose data transmission delay is less than or equal to a preset delay, whose remaining computing power is greater than or equal to a preset multiple, and whose data processing time is less than a preset time as designated devices; and determining the device to be taken over from the designated devices based on the total data transmission delay and remaining computing power corresponding to each designated device; wherein the total data transmission delay represents the sum of the data transmission delays between the corresponding designated device and each of the other devices.

[0010] In one optional approach, determining the device to be taken over from the designated devices based on the total data transmission latency and remaining computing power of each designated device includes: multiplying the total data transmission latency of each designated device by a preset first weighting coefficient to obtain a first product for each designated device; calculating the difference between the remaining computing power of each designated device and the computing power required by the faulty device multiplied by a preset multiple, and multiplying the difference by a preset second weighting coefficient to obtain a second product for each designated device; and selecting the designated device with the smallest sum of the corresponding first product and second product as the device to be taken over.

[0011] According to another aspect of this application, a collaborative control device for multiple devices is provided. The collaborative control device includes: a device to be taken over determination module, configured to determine the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device; a takeover device determination module, configured to input a state vector representing the state information of the faulty device, the total data transmission delay of each device to be taken over, and the remaining computing power of each device to be taken over into a prediction model, so that the prediction model determines the takeover device; and a takeover control module, configured to send a control instruction packet including a verification key to the takeover device, so that the takeover device can perform takeover control of the faulty device if the verification is successful based on the verification key.

[0012] According to one aspect of this application, an electronic device is provided, comprising: a controller; and a memory for storing one or more programs, which, when executed by the controller, perform the aforementioned cooperative control method.

[0013] According to one aspect of this application, a computer-readable storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the aforementioned cooperative control method.

[0014] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned cooperative control method.

[0015] In the event of a faulty device, this application selects devices to be taken over from the other devices based on the data transmission latency between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device. The state vector of the faulty device is analyzed in conjunction with the total data transmission latency and remaining computing power of each device to be taken over, in order to determine the takeover device from the devices to be taken over. This takeover device takes over the faulty device upon successful key verification, so as to handle the work tasks of the faulty device, ensure the synchronous execution of the work tasks of the faulty device, avoid the impact of device failure on the working efficiency of the device cluster, and thus improve the working efficiency of the device cluster.

[0016] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0018] Figure 1 This is a flowchart illustrating a collaborative control method among multiple devices, as shown in an exemplary embodiment of this application.

[0019] Figure 2 Based on Figure 1 The exemplary embodiment shown illustrates a flowchart of another collaborative control method among multiple devices.

[0020] Figure 3 Based on Figure 2 The exemplary embodiment shown illustrates a flowchart of another collaborative control method among multiple devices.

[0021] Figure 4 This is a schematic diagram of a collaborative control system between multiple devices, as illustrated in an exemplary embodiment of this application.

[0022] Figure 5 Based on Figure 4 The diagram shows a flowchart of the collaborative control method in the collaborative control system.

[0023] Figure 6 This is a schematic diagram of the structure of a collaborative control device between multiple devices, as illustrated in an exemplary embodiment of this application.

[0024] Figure 7 This is a schematic diagram of the structure of a computer system of an electronic device illustrated in an exemplary embodiment of this application. Detailed Implementation

[0025] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0026] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0027] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0028] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0029] In multi-device scenarios, when a device malfunctions, it typically becomes offline and ceases operation, impacting the overall efficiency and task completion rate of the device cluster. Related technologies employ manual troubleshooting to resolve the faulty device, which then resumes its tasks after the fault is resolved. This process is time-consuming and significantly hinders the overall efficiency of the device cluster.

[0030] Therefore, one aspect of this application provides a method for collaborative control among multiple devices. Please refer to [link / reference] for details. Figure 1 , Figure 1 This is a flowchart illustrating a collaborative control method among multiple devices, as shown in an exemplary embodiment of this application. The collaborative control method includes at least steps S110 to S130, which are described in detail below: S110: Determine the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device.

[0031] Faulty equipment and other equipment are relative concepts. The two constitute a complete equipment cluster. Faulty equipment is the equipment in the equipment cluster that has failed, while other equipment is the collective term for all equipment in the scene equipment cluster except for the faulty equipment.

[0032] In some embodiments, faulty devices are identified by detecting the signal amplitude jump ratio. Specifically, the system checks whether the signal amplitude jump ratio of all devices exceeds a preset jump ratio. If the target device's signal amplitude jump ratio exceeds the preset jump ratio, the target device is identified as faulty. For example, the system collects I / O signals (including digital input / output signals or analog input / output signals) from each device in real time. If the signal amplitude jump ratio exceeds ±10% (i.e., the preset jump ratio) within a continuous time window, a fault determination mechanism is triggered, generating an event marker containing the fault occurrence time, device identification code, and initial fault level.

[0033] Data transmission latency is a relative concept, referring to the time it takes for data to be transmitted between two devices in a cluster. Remaining computing power refers to the amount of unused computing resources available on a given device. Data processing time characterizes the efficiency of a device in processing data; the longer the processing time for the same amount of data, the lower the efficiency, and vice versa.

[0034] This embodiment selects the devices to be taken over from other devices based on three different types of parameters. This is to consider parameters from different dimensions so that the identified devices to be taken over initially meet the basic conditions for taking over the faulty device. In some embodiments, these three different types of parameters can be input into a MILP (Mixed-Integer Linear Programming) model to output the devices to be taken over.

[0035] For example, the data transmission delay between the faulty device and each other device is calculated based on the location distance between the faulty device and each other device, as well as the environmental signal-to-noise ratio; for instance, the data transmission delay between the faulty device and each other device is calculated using Shannon's theorem. Where i' represents the faulty device, j represents other devices, B represents the bandwidth constant, and SNR' represents the signal-to-noise ratio of data transmitted between the faulty device and other devices. It is the preceding measurement data, which is stored in the Redis database after interpolation processing for high-performance reading, so as to calculate the data transmission latency between the faulty device and other devices in the device cluster.

[0036] Other devices whose data transmission latency is less than or equal to the preset latency, whose remaining computing power is greater than or equal to the preset multiple, and whose data processing time is less than the preset time are designated as designated devices. That is, the designated devices must meet these three conditions at the same time, namely the data transmission latency, remaining computing power, and data processing time between the faulty device and other devices.

[0037] The data transmission delay between each specified device (belonging to any device in the device cluster) and all other devices (i.e., all other devices in the device cluster except the specified device itself, including faulty devices and other devices) is calculated using Shannon's theorem. Where i represents the specified device, j represents other devices, B represents the bandwidth constant, and SNR represents the signal-to-noise ratio of the data transmitted between the specified device and other devices. The total data transmission delay ∑D(i,j) for each specified device is calculated in this way.

[0038] Based on the total data transmission latency and remaining computing power of each designated device, the devices to be taken over are determined from the designated devices; where the total data transmission latency represents the sum of the data transmission latency between the corresponding designated device and all other devices.

[0039] For example, the total data transmission delay corresponding to each designated device is multiplied by a preset first weighting coefficient to obtain a first product for each designated device; the difference between the remaining computing power of each designated device and the computing power required by the faulty device multiplied by a preset multiple is calculated, and this difference is multiplied by a preset second weighting coefficient to obtain a second product for each designated device; the designated device with the smallest sum of the corresponding first and second products is selected as the device to be taken over. Specifically, the value calculated by the following function is used to determine the device to be taken over from the designated devices: ,in; and These are the first and second weighting coefficients, used to balance the importance of data transmission latency and remaining computing power in the decision-making process, and are dynamically adjusted. and The value of ensures that the selected device is optimal in terms of data transmission latency and computing power requirements; i represents the specified device, and j represents other devices. Indicates the preset multiple. Indicates the remaining computing power of the specified device. Indicates the computing power required by the faulty device; This represents the total data transmission latency for the specified device (i.e., the sum of data transmission latencies between the specified device and all other devices). A value is calculated for each specified device based on this, and the specified device with the smallest corresponding value is selected as the device to be taken over.

[0040] S120: Input the state vector representing the state information of the faulty equipment, the total data transmission delay of each equipment to be taken over, and the remaining computing power into the prediction model so that the prediction model can determine the equipment to be taken over.

[0041] The predictive model is used to determine the takeover device, and its output is the takeover device. It can be a Deep Q-Network (DQN) decision model built using the PyTorch framework, with the reward function set as follows: ;in, Indicates the duration of line outage. This represents constant terms other than zero. During training, a priority experience replay mechanism is used, with an experience sampling size of 128 (a common benchmark value that strikes a good balance between training stability and generalization ability) and a learning rate of 3e-4 (i.e., 0.0003, a classic and commonly used default value in deep learning, especially in reinforcement learning based on the Adam optimizer).

[0042] The input to the prediction model can be automatically generated by the MILP model. For example, the input set S is constructed based on the state vector of the faulty device, the data transmission latency of each device to be taken over, and the remaining computing power. t ={s t d t v t}, inputting into a deep reinforcement learning decision model DQN, to determine the takeover device; where d t v represents the data transmission delay of each device to be taken over. t Indicates the remaining computing power of each device to be taken over; s t A state vector representing the state information of a faulty device.

[0043] S130: Send a control instruction packet including the verification key to the takeover device so that the takeover device can take over control of the faulty device if the verification key is successfully verified.

[0044] In addition to the verification key, the control instruction package also includes relevant control parameters, permission parameters, and function configuration parameters to ensure that the takeover device can successfully complete the original working tasks of the faulty device after taking over the faulty device.

[0045] To enhance the security of access transfer, the takeover device can further authenticate the user based on a verification key to ensure that the control command packet is not tampered with or sent by an unauthenticated party. Only when the authentication is successful will the takeover device officially take over control of the faulty device.

[0046] In this embodiment, when a faulty device is detected, a device to be taken over is selected from the other devices based on the data transmission latency between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device. The state vector of the faulty device is combined with the total data transmission latency and remaining computing power of each device to be taken over for analysis, so as to determine the takeover device from the devices to be taken over. The takeover device takes over the faulty device when the key verification is successful, so as to handle the work tasks of the faulty device, ensure the synchronous execution of the work tasks of the faulty device, avoid the impact of device failure on the working efficiency of the device cluster, and thus improve the working efficiency of the device cluster.

[0047] In another exemplary embodiment of this application, how is described in detail, please refer to [link to relevant documentation]. Figure 2 , Figure 2 Based on Figure 1 The exemplary embodiment shown illustrates a flowchart of another collaborative control method among multiple devices. This collaborative control method, in situations such as... Figure 1 Based on S110 to S130 shown, at least S210 to S220 are also included, which are described in detail below: S210: Determine the data capture time interval based on the time when the faulty device malfunctions and the preset extension duration.

[0048] The preset extension duration is a preset duration parameter. Taking the moment of the fault as the midpoint, the preset extension duration is extended forward and backward to obtain the data capture time interval. For example, the moment when the faulty device fails is t0, and the preset extension duration is ΔΠ seconds; taking t0 as the reference, extending forward and backward by ΔΠ seconds, the data capture time interval is [t0-ΔΠ, t0+ΔΠ].

[0049] S220: Within the data capture time interval, the data stream corresponding to the faulty device is collected based on a time window of preset length, and a state vector is generated based on the data stream to characterize the state information of the faulty device.

[0050] A data stream is a coherent dataset composed of data from multiple consecutive moments linked together; it can be a collection of raw data from multiple consecutive moments. A state vector includes fault characteristics and other fault-related features, used to characterize the state information of the faulty equipment.

[0051] Within the data capture time interval, a sliding time window algorithm is used to obtain a sequence of sub-windows with overlapping regions based on a time window of preset length ζ (i.e., the length of the time window is ζ) and a sliding step size ξ (i.e., the single sliding distance of the time window, ξ<ζ), ensuring that transient fault features are captured by multiple windows.

[0052] For example, starting from the beginning of the data capture time interval, a time window of a preset length is slid along a preset step size to collect raw data corresponding to multiple time windows, so as to obtain the data stream corresponding to the faulty device; features are extracted from the data stream, and a feature matrix is ​​generated based on the extracted feature data; the feature matrix is ​​subjected to dimensionality compression processing to obtain a state vector representing the state information of the faulty device.

[0053] A window of preset length ζ is slid from the beginning of the data capture time interval (i.e., the moment of the fault) with a sliding step size ξ to obtain a sequence of sub-windows with overlapping regions (i.e., multiple time windows). The original data stream (including IO signals, process parameters, and environmental variables) within each sub-window will have its mean deviation, standard deviation, peak value, and waveform entropy time-domain statistical features calculated in parallel. Then, the first χ dominant frequency components are extracted using Fast Fourier Transform, and the amplitudes of the frequency domain dominant frequency components of χ≥3 and the correlation indicators of operating parameters (such as extreme values ​​of load current, temperature change rate, and time-series correlation of vibration signals) are obtained to obtain relevant feature data, forming a multi-dimensional fault feature matrix. Based on a preset list of key parameter priorities (e.g., current and vibration parameters are prioritized for motor faults), non-key parameters are downsampled, and dimensionality compression is performed using principal component analysis or an autoencoder to generate a low-dimensional equipment state vector s. t (s) t ∈R q , q≤20), which is the state vector representing the state information of the faulty device; where the dimension q is adapted according to the needs of the scenario.

[0054] In another exemplary embodiment of this application, how to update the fault knowledge base is described in detail; please refer to [link to relevant documentation]. Figure 3 , Figure 3 Based on Figure 2 The exemplary embodiment shown illustrates a flowchart of another collaborative control method among multiple devices. This collaborative control method further includes at least step S310, which is described in detail below: S310: When the fault of the faulty equipment is eliminated, the fault lifecycle data is filtered and processed, and the filtered data is used to update the fault knowledge base; wherein, the fault lifecycle data includes data streams and state vectors that represent the state information of the faulty equipment.

[0055] After the takeover device takes over the faulty device, this application will continuously perform fault detection on the takeover device and other devices. If a secondary fault or performance abnormality is detected, the system will re-execute the takeover device selection and control transfer process for the fault to ensure the stable operation of the device cluster.

[0056] Meanwhile, this application will continuously monitor the status of faulty equipment. Once the fault is eliminated, the entire fault lifecycle data (including original signals, fault status after dimensionality reduction, decision logs, etc.) will be timestamped and outliers removed. The processed data will be used to update the fault knowledge base, providing real-time support for dynamic resource scheduling.

[0057] In another exemplary embodiment of this application, the application scenarios of the above-mentioned multiple collaborative control methods are illustrated by way of example. Please refer to the following for details. Figure 4 , Figure 4 This is a schematic diagram of a collaborative control system between multiple devices, as illustrated in an exemplary embodiment of this application. The collaborative control system can be a system with a digital twin system as its main framework. It includes a digital twin fault reconstruction layer, a dynamic scheduling decision layer, a computing resource pool, and an edge resource pooling layer. The devices can be connected wirelessly, and this application does not limit the connection method between them. Figure 4 The flowchart of the cooperative control method in the cooperative control system shown is as follows: Figure 5 As shown.

[0058] At the edge resource pooling layer, the idle computing power of various heterogeneous devices such as AI (Artificial Intelligence) quality inspection platforms, AGV (Automated Guided Vehicle) logistics vehicles, and robot group control terminals is abstracted into a virtual computing power resource pool by utilizing edge network devices deployed in the scenario and a containerization engine. Simultaneously, a dynamic resource registry is constructed to record device IDs (Identity Documents), resource types, current load rates, and physical locations in real time to ensure real-time data transmission and computation task scheduling. For example, the containerization engine abstracts the remaining idle computing power of each device in the scenario into a virtual computing power resource pool, constructs a dynamic resource registry, and records device IDs, resource types, load rates, and physical locations in real time. The idle criterion is that when the CPU (Central Processing Unit) utilization of a device is lower than σ (a preset utilization threshold, the specific value of which is not limited in this application) for consecutive μ seconds, its computing power resources are marked as idle and encapsulated by the containerization engine as independent computing power devices, registered in the computing power resource pool, and used as backup resource devices for use in case of failure. The registration information includes the device ID, resource type, and current device load rate. Mobile devices update their current location to the containerization engine every second. It should be noted that, considering that AGVs and other workshop mobile devices often have built-in precise positioning systems, this application treats device location data as known information. The current load rate of idle computing resources is obtained by averaging the load rate data within a short-term time window, resulting in a smooth load rate value. This reduces the impact of instantaneous fluctuations and more accurately reflects the current average load status of the resources.

[0059] By using the 5G-TSN network, all devices in the scenario can communicate with each other in real time. All devices are connected to the edge resource pooling layer to build a star topology centered on the containerization engine. The Modbus-TCP stable protocol is used to realize data exchange between devices and monitoring units, and system status information is collected at frequency ρ.

[0060] The digital twin fault reconstruction layer synchronizes the device operating status in real time and collects the I / O signals (including digital input / output signals or analog input / output signals) of each device in real time. If an abnormal change in signal amplitude exceeding ±10% is detected within a continuous time window τ seconds, a fault determination mechanism is triggered, generating an event marker containing the time t0 of the fault occurrence, the device identification code, and the initial fault level. Simultaneously, a spatiotemporal compression engine is invoked to expand forward and backward from t0 as a baseline. π seconds ( π is the preset extension duration), dynamically defining the high-density data capture time interval [t0- π, t0+ [π], covering the key data streams before and after the fault occurs. Within this time interval, the engine uses a sliding time window algorithm to generate a sequence of sub-windows with overlapping regions based on the preset window length ζ and sliding step size ξ (ξ<ζ), ensuring that transient fault features are captured by multiple windows. The original data streams (including IO signals, process parameters, and environmental variables) within each sub-window will have their mean deviation, standard deviation, peak value, and waveform entropy time-domain statistical features calculated in parallel. Then, the first χ main frequency components are extracted through Fast Fourier Transform, χ≥3, and the amplitude of the frequency domain main frequency components of the correlation indicators of operating parameters (such as the extreme values ​​of load current, the rate of temperature change, and the time-series correlation of vibration signals). The calculation results are fused to form a multi-dimensional fault feature matrix. Based on a preset list of key parameter priorities (e.g., current and vibration parameters are prioritized for motor faults), non-key parameters are downsampled. Further dimensional compression is performed through principal component analysis or an autoencoder to generate a low-dimensional equipment state vector s. t (s) t ∈R q , q≤20), which is the state vector representing the state information of the faulty device; where the dimension q is adapted according to the scenario requirements. Finally, the cooperative control system will use the state vector s t The metadata (timestamp, device ID, fault level) of the data capture time interval is encapsulated into a lightweight data packet. At the same time, non-critical parameters in the original data stream are discarded or archived according to the policy, thereby reducing the transmission bandwidth and fully preserving the core characteristic information of the fault event.

[0061] In some embodiments, the containerization engine is queried to obtain all currently marked idle devices and their computing power status, which can be calculated by the load rate when the computing power unit is registered; the fixed location and signal-to-noise ratio (SNR) of the workshop equipment are utilized, and arbitrary devices are calculated based on Shannon's theorem. With any device Data transmission delay between i≠j; the data transmission latency between every two devices in the device cluster is calculated in this way (including the data transmission latency between the faulty device and each other device, and the data transmission latency between other devices). The signal-to-noise ratio (SNR) is the preceding measurement data in the environment, which is stored in the Redis database after interpolation for high-performance reading.

[0062] In some embodiments, at the dynamic resource scheduling decision layer, a hybrid linear integer programming (MILP) model is constructed to perform a global search on all candidate resource devices in the device cluster, and to filter the set of devices that meet the following hard constraints to determine the devices to be taken over: ① The unit data transmission delay from the faulty device to the candidate device does not exceed ② The remaining computing power of the equipment must meet the computing power required by the faulty equipment. of 3 times; 4 times; 5 times; 6 times; 7 times; 8 times; 9 times; 10 The objective function of the MILP model is ;in, and These are weighting coefficients used to balance the importance of data transmission latency and remaining computing power in decision-making, and are dynamically adjusted. and The value of this ensures that the output control equipment is optimal in terms of latency and computing power requirements; Represents the remaining computing power of the corresponding specified device. This indicates the computing power required by the faulty device.

[0063] In some embodiments, at the dynamic resource scheduling decision layer, an online optimization model for control transfer decisions is constructed, using the MILP screening results as the devices to be taken over, and a set of state inputs is constructed. Where, d t v represents the data transmission delay of each device to be taken over. t Indicates the remaining computing power of each device to be taken over; s t A state vector representing the state information of a faulty device.

[0064] In some embodiments, during the model pre-training phase, a deep reinforcement learning decision model (DQN) is constructed using the PyTorch framework, and the reward function is set as follows: ,in This indicates the frequency of line outages. To prevent constant terms from being divided by zero, a priority experience replay mechanism is used during training. The experience sampling size is 128 (a common benchmark value, which strikes a good balance between training stability and generalization ability) and the learning rate is set to 3e-4 (i.e., 0.0003, which is a classic and commonly used default value in deep learning, especially in reinforcement learning based on the Adam optimizer).

[0065] In some embodiments, a deep reinforcement learning model pre-trained offline using the DQN algorithm and a pre-built MILP model are deployed to the dynamic scheduling decision layer. When the cooperative control system detects a fault alarm, the MILP model quickly determines the equipment to be taken over, and further constructs the input state. The control transfer path is further optimized through online decision-making, and the device ID of the device to be taken over is determined.

[0066] In some embodiments, the device ID of the takeover device is determined according to the DQN model, and the historical data retrieval module retrieves the historical control parameters, operating mode configuration and I / O mapping table of the faulty device, automatically constructs a full control parameter image, generates a control instruction package containing the device control parameter image and digital certificate and sends it to the takeover device.

[0067] In some embodiments, after receiving the control command packet, the takeover device establishes a two-way authentication channel with the digital twin fault reconstruction layer, exchanges session keys, completes the atomic switching of the control context, and begins to execute control logic to achieve seamless switching of the control context, ensuring that the device I / O loop is not interrupted and quickly restores the normal operation of the device.

[0068] In some embodiments, after control takeover, the collaborative control system continuously monitors the operating status of the takeover device and the managed device, and continuously listens for fault prediction alarms. If a secondary fault or performance abnormality is detected, the system will re-execute the takeover device selection and control transfer process for the fault to ensure the stable operation of the device cluster.

[0069] In some embodiments, a data cleaning pipeline is used to perform timestamp alignment and outlier removal on the full-cycle fault data (including original signals, dimensionality-reduced fault states, decision logs, etc.). The processed data is stored in the reinforcement learning experience pool and historical experience database as training data for deep reinforcement learning models, as well as for subsequent data analysis and the construction of a fault knowledge base, providing support for dynamic resource scheduling and continuously updating the data in the fault knowledge base.

[0070] Another aspect of this application provides a collaborative control device, such as... Figure 6 As shown, Figure 6 This is a schematic diagram illustrating the structure of a multi-device collaborative control device 600 according to an exemplary embodiment of this application. The collaborative control device 600 includes: The device to be taken over module 610 is used to determine the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device.

[0071] The takeover device determination module 630 is used to input the state vector representing the state information of the faulty device, the total data transmission delay of each device to be taken over, and the remaining computing power into the prediction model so that the prediction model can determine the takeover device.

[0072] The takeover control module 650 is used to send a control instruction packet including a verification key to the takeover device, so that the takeover device can take over the faulty device if the verification key is successfully verified.

[0073] In another exemplary embodiment, the cooperative control device 600 further includes: The interval determination module is used to determine the data capture time interval based on the time when the faulty device fails and the preset extension duration.

[0074] The state vector generation module is used to collect the data stream corresponding to the faulty device within the data capture time interval based on a preset time window, and generate a state vector based on the data stream to represent the state information of the faulty device.

[0075] In another exemplary embodiment, the state vector generation module includes: The capture unit is used to collect raw data corresponding to multiple time windows by sliding a preset length time window according to a preset step size, starting from the beginning of the data capture time interval, so as to obtain the data stream corresponding to the faulty device.

[0076] The extraction unit is used to extract features from the data stream and generate a feature matrix based on the extracted feature data.

[0077] The compression unit is used to perform dimensionality compression on the feature matrix to obtain a state vector that represents the state information of the faulty device.

[0078] In another exemplary embodiment, the cooperative control device 600 further includes: The update module is used to filter the fault lifecycle data after the fault of the faulty equipment is eliminated, and to use the filtered data to update the fault knowledge base. The fault lifecycle data includes data streams and state vectors that represent the state information of the faulty equipment.

[0079] In another exemplary embodiment, the cooperative control device 600 further includes: The detection module is used to detect whether the signal amplitude jump ratio of all devices is greater than the preset jump ratio.

[0080] The fault determination module is used to identify the target device as a faulty device if the detected signal amplitude jump ratio of the target device is greater than the preset jump ratio.

[0081] In another exemplary embodiment, the device to be taken over determination module 610 includes: The delay determination unit is used to calculate the data transmission delay between the faulty device and each other device based on the location distance between the faulty device and each other device, as well as the environmental signal-to-noise ratio.

[0082] The designated device determination unit is used to designate other devices as designated devices, provided that the data transmission delay is less than or equal to the preset delay, the remaining computing power is greater than or equal to the preset multiple of the required computing power of the faulty device, and the data processing time is less than the preset time.

[0083] The device to be taken over determination unit is used to determine the device to be taken over from the designated devices based on the total data transmission delay and remaining computing power of each designated device; wherein, the total data transmission delay represents the sum of the data transmission delays between the corresponding designated device and all other devices.

[0084] In another exemplary embodiment, the device to be taken over determination unit includes: The first calculation module is used to multiply the total data transmission delay corresponding to each specified device by a preset first weighting coefficient to obtain the first product corresponding to each specified device.

[0085] The first calculation module is used to calculate the difference between the remaining computing power of each specified device and the computing power required by the faulty device multiplied by a preset multiple, and then multiply the difference by a preset second weighting coefficient to obtain the second product corresponding to each specified device.

[0086] The device to be taken over section is used to identify the designated device with the smallest sum of the corresponding first product and second product as the device to be taken over.

[0087] When a faulty device is detected, the collaborative control device of this application selects devices to be taken over from the other devices based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device. The state vector of the faulty device is combined with the total data transmission delay and remaining computing power of each device to be taken over for analysis, so as to determine the takeover device from the devices to be taken over. The takeover device takes over the faulty device when the key verification is successful, so as to handle the work tasks of the faulty device, ensure the synchronous execution of the work tasks of the faulty device, avoid the impact of device failure on the working efficiency of the device cluster, and thus improve the working efficiency of the device cluster.

[0088] It should be noted that the collaborative control device provided in the above embodiments and the collaborative control method provided in the foregoing embodiments belong to the same concept. The specific ways in which each module and unit performs operations have been described in detail in the method embodiments, and will not be repeated here.

[0089] Another aspect of this application provides an electronic device, including: a controller; and a memory for storing one or more programs, which, when executed by the controller, perform the aforementioned cooperative control method.

[0090] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of a computer system for an electronic device according to an exemplary embodiment of this application, illustrating a schematic diagram of the structure of a computer system suitable for implementing the embodiments of this application.

[0091] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0092] like Figure 7 As shown, the computer system 700 includes a Central Processing Unit (CPU) 701, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 702 or programs loaded from storage portion 708 into Random Access Memory (RAM) 703. The RAM 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An Input / Output (I / O) interface 705 is also connected to the bus 704.

[0093] The following components are connected to I / O interface 705: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to I / O interface 705 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 710 as needed so that computer programs read from it can be installed into storage section 708 as needed.

[0094] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit (CPU) 701, it performs various functions defined in the system of this application.

[0095] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0098] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned cooperative control method. This computer-readable storage medium may be included in the electronic device described in the above embodiments, or it may exist independently and not incorporated into the electronic device.

[0099] Another aspect of this application provides a computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the cooperative control methods provided in the various embodiments described above.

[0100] According to one aspect of the embodiments of this application, a computer system is also provided, including a Central Processing Unit (CPU), which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from storage into random access memory (RAM), such as performing the methods described above. Various programs and data required for system operation are also stored in the RAM. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0101] The following components are connected to the I / O interface: input components including keyboards, mice, etc.; output components including cathode ray tubes (CRTs), liquid crystal displays (LCDs), and speakers; storage components including hard drives; and communication components including network interface cards such as LAN (Local Area Network) cards and modems. The communication components perform communication processing via networks such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical discs, magneto-optical discs, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage components as required.

[0102] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

Claims

1. A method for collaborative control among multiple devices, characterized in that, The collaborative control method includes: The equipment to be taken over is determined based on the data transmission latency between the faulty equipment and each other equipment, as well as the remaining computing power and data processing time of each other equipment. The state vector representing the state information of the faulty device, the total data transmission delay of each device to be taken over, and the remaining computing power are input into the prediction model so that the prediction model can determine the device to be taken over. A control instruction packet including a verification key is sent to the takeover device so that the takeover device can take over control of the faulty device if the verification key is successfully verified.

2. The cooperative control method according to claim 1, characterized in that, The collaborative control method further includes: The data capture time interval is determined based on the time when the faulty device malfunctions and the preset extension duration. Within the data capture time interval, data streams corresponding to the faulty device are collected based on a time window of preset length, and a state vector is generated based on the data streams to characterize the state information of the faulty device.

3. The cooperative control method according to claim 2, characterized in that, The process of collecting the data stream corresponding to the faulty device based on a preset time window includes: Starting from the beginning of the data capture time interval, a time window of a preset length is slid along a preset step size to collect raw data corresponding to multiple time windows, so as to obtain the data stream corresponding to the faulty device; The step of generating a state vector representing the state information of the faulty device based on the data stream includes: Feature extraction is performed on the data stream, and a feature matrix is ​​generated based on the extracted feature data; The feature matrix is ​​subjected to dimensionality compression to obtain a state vector representing the state information of the faulty device.

4. The cooperative control method according to claim 3, characterized in that, The collaborative control method further includes: When the fault of the faulty device is eliminated, the fault lifecycle data is filtered and the filtered data is used to update the fault knowledge base; wherein, the fault lifecycle data includes the data stream and the state vector representing the state information of the faulty device.

5. The cooperative control method according to claim 1, characterized in that, Before determining the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device, the cooperative control method further includes: Check whether the signal amplitude transition ratio of all devices is greater than the preset transition ratio; If the detected signal amplitude jump ratio of the target device is greater than the preset jump ratio, then the target device is identified as the faulty device.

6. The cooperative control method according to any one of claims 1 to 5, characterized in that, The process of determining the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device, includes: The data transmission delay between the faulty device and each other device is calculated based on the location distance between the faulty device and each other device, and the environmental signal-to-noise ratio. Other devices whose data transmission latency is less than or equal to a preset latency, whose remaining computing power is greater than or equal to a preset multiple, and whose data processing time is less than a preset time are designated as the specified devices. Based on the total data transmission latency and remaining computing power of each designated device, the device to be taken over is determined from the designated devices; wherein, the total data transmission latency represents the sum of the data transmission latency between the corresponding designated device and all other devices.

7. The cooperative control method according to claim 6, characterized in that, The step of determining the device to be taken over from the designated devices based on the total data transmission latency and remaining computing power corresponding to each designated device includes: Multiply the total data transmission delay corresponding to each specified device by a preset first weighting coefficient to obtain the first product corresponding to each specified device; Calculate the difference between the remaining computing power of each specified device and the computing power required by the faulty device multiplied by a preset multiple, and multiply the difference by a preset second weighting coefficient to obtain the second product corresponding to each specified device; The designated device with the smallest sum of the corresponding first and second products is selected as the device to be taken over.

8. A collaborative control device for multiple devices, characterized in that, The collaborative control device includes: The device to be taken over module is used to determine the device to be taken over based on the data transmission delay between the faulty device and each other device, as well as the remaining computing power and data processing time of each other device. The takeover device determination module is used to input the state vector representing the state information of the faulty device, the total data transmission delay of each device to be taken over, and the remaining computing power into the prediction model so that the prediction model can determine the takeover device. The takeover control module is used to send a control instruction packet including a verification key to the takeover device, so that the takeover device can take over the faulty device if the verification key is successfully verified.

9. An electronic device, characterized in that, include: Controller; A memory for storing one or more programs that, when executed by a controller, cause the controller to implement the cooperative control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores computer-readable instructions that, when executed by the computer's processor, cause the computer to perform the cooperative control method described in any one of claims 1 to 7.

Images