Multi-device cooperative control method and system based on bus communication protocol

Abstract

The embodiment of the application provides a kind of based on bus communication protocol's multi-device collaborative control method and system, belong to bus communication protocol's multi-device collaborative control field;The method includes collecting multi-modal data, and extracting event data, parsing the event metadata, get event influence radius and event type, according to the event influence radius and the event type, event is graded, based on the event list after grading, event arbitration result is obtained by dynamic arbitration mechanism;According to the event arbitration result, distributed spatiotemporal collaborative decision-making is carried out, and the collaborative group execution scheme is obtained;Based on the event list after grading, the collaborative group execution scheme is sent to corresponding device, and multi-device collaborative control is completed.The application realizes event grading by three-dimensional evaluation matrix, ensures high-priority event immediate response in combination with dynamic arbitration mechanism, adopts distributed spatiotemporal collaborative decision-making system, significantly improves the real-time performance and reliability of multi-device collaboration.

Description

Technical Field

[0001] This invention relates to the field of multi-device collaborative control based on bus communication protocols, and specifically to a multi-device collaborative control method and system based on bus communication protocols. Background Technology

[0002] In modern industrial automation, smart home, and IoT systems, multi-device collaborative control is a key technology for achieving efficient and reliable operation. Traditional control methods typically employ point-to-point communication, but as the number of devices increases, system complexity rises significantly, leading to problems such as cumbersome wiring, poor scalability, and difficult maintenance. Multi-device collaborative control methods based on bus communication protocols can effectively solve these problems. Common bus protocols such as CAN, Modbus, and EtherCAT offer advantages such as high real-time performance, strong anti-interference capabilities, and flexible topologies, making them suitable for data interaction and synchronous control between distributed devices. However, existing bus technologies still face challenges in multi-device collaboration. Existing bus protocols typically use static priority scheduling (such as ID priority in CAN), which is difficult to adapt to sudden high-priority events (such as device failures or safety alarms). When multiple devices simultaneously request bus resources, low-priority tasks may cause delays in critical operations due to congestion, or even trigger cascading failures. Traditional methods rely on centralized controllers or global clocks, but in distributed scenarios, clock drift, communication delays, and spatial conflicts can lead to decision failures. Summary of the Invention

[0003] The purpose of this invention is to provide a multi-device collaborative control method and system based on a bus communication protocol, which can realize efficient collaborative scheduling and precise timing synchronization of multiple devices in complex scenarios, and achieve high real-time performance, high reliability, distributed device collaborative scheduling, and anomaly self-recovery.

[0004] To achieve the above objectives, embodiments of the present invention provide a multi-device collaborative control method based on a bus communication protocol, comprising: collecting multimodal data and extracting event data, and encapsulating the event data into event metadata; parsing the event metadata to obtain the event influence radius and event type, classifying the events according to the event influence radius and event type to obtain a classified event list; obtaining an event arbitration result through a dynamic arbitration mechanism based on the classified event list; performing distributed spatiotemporal collaborative decision-making based on the event arbitration result to obtain a collaborative group execution plan; and sending the collaborative group execution plan to the corresponding devices based on the classified event list to complete multi-device collaborative control.

[0005] Optionally, classifying events according to their impact radius and type includes: mapping the impact radius and type to a three-dimensional assessment matrix, which consists of risk impact radius, recovery cost, and time delay tolerance; and classifying events into routine, emergency, and catastrophic events based on the three-dimensional assessment matrix.

[0006] Optionally, obtaining the event arbitration result through the dynamic arbitration mechanism includes: using a three-dimensional weight evaluation model to calculate the priority score of each event, and generating a processing queue based on the priority score; when the fatal event is triggered, skipping the arbitration process, directly preempting the bus and executing a preset emergency protocol; when the priority score of the emergency event or the regular event exceeds a preset multiple of the current processing event score, triggering a weight rebalancing mechanism.

[0007] Optionally, the weight rebalancing mechanism includes: calculating the adjusted urgency weight and proximity weight; recalculating the priority score of each event using the adjusted urgency weight and proximity weight; and generating a new processing queue based on the recalculated priority score.

[0008] Optionally, the step of performing distributed spatiotemporal collaborative decision-making based on the event arbitration result to obtain a collaborative group execution plan includes: calculating the event's temporal security boundary and spatial security boundary based on the event metadata and the arbitration result; filtering collaborative group devices and broadcasting the temporal security boundary and spatial security boundary to the collaborative group devices; generating candidate decisions based on the collected multimodal data and attaching temporal and spatial proofs to the candidate decisions; verifying the spatiotemporal security of the candidate decisions and discarding proposals that exceed the temporal security boundary and spatial security boundary; scoring the candidate decisions on spatiotemporal security and efficiency, and selecting the one with the highest score as the execution plan.

[0009] Optionally, the step of making distributed spatiotemporal collaborative decisions based on the event arbitration result to obtain a collaborative group execution scheme further includes: implementing the execution scheme and aligning device timings through a logical clock or a precise time protocol to obtain the collaborative group execution scheme.

[0010] Optionally, sending the collaborative group execution plan to the corresponding device based on the graded event list includes: transmitting a global broadcast when the event level is critical; transmitting a regional multicast when the event level is urgent; and transmitting a unicast or on-demand request when the event level is normal.

[0011] Optionally, the step of sending the collaborative group execution plan to the corresponding device based on the hierarchical event list further includes: converting the collaborative group execution plan into device execution instructions, encapsulating the device execution instructions into event-driven frames through a bus controller, collecting multimodal real-time data, continuously comparing the real-time speed in the multimodal real-time data with the target speed of the device execution instructions, and calculating the deviation between the real-time speed and the target speed. If the deviation is greater than a set deviation threshold, it is determined to be an execution anomaly, and event re-decision is triggered.

[0012] Optionally, the event re-decision includes: setting a maximum number of re-decision attempts; if the deviation is still greater than the set value after the maximum number of re-decision attempts is reached, then switching to a backup collaborative control scheme.

[0013] On the other hand, the present invention provides a multi-device collaborative control system based on a bus communication protocol, for implementing a multi-device collaborative control method based on a bus communication protocol. The system includes a control module, the control module including a memory, a processor and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement the multi-device collaborative control method based on a bus communication protocol.

[0014] The above technical solution achieves event classification through a three-dimensional evaluation matrix (risk impact radius / recovery cost / latency tolerance), combines a dynamic arbitration mechanism to ensure immediate response to high-priority events, and adopts a distributed spatiotemporal collaborative decision-making system. Through dual constraints of time safety boundaries and spatial safety boundaries, coupled with a spatiotemporal proof verification mechanism, it effectively avoids timing errors and spatial conflicts between devices. At the same time, it has adaptive fault tolerance capabilities, achieves rapid anomaly recovery through real-time data monitoring and automatic re-decision mechanism, and optimizes bus resources by intelligently selecting communication modes based on event level, significantly improving the real-time performance and reliability of multi-device collaboration.

[0015] Other features and advantages of the embodiments of the present invention will be described in detail in the following detailed description section. Attached Figure Description

[0016] The accompanying drawings are provided to further illustrate embodiments of the present invention and form part of the specification. They are used together with the following detailed description to explain the embodiments of the present invention, but do not constitute a limitation thereof. In the drawings:

[0017] Figure 1 It is a flowchart of multi-device collaborative control based on bus communication protocol.

[0018] Figure 2 This is an arbitration flowchart. Detailed Implementation

[0019] The following is in conjunction with the appendix Figure 1 - Appendix Figure 2 The specific implementation methods of the embodiments of the present invention will be described in detail below. It should be understood that the specific implementation methods described herein are only for illustrating and explaining the embodiments of the present invention, and are not intended to limit the embodiments of the present invention.

[0020] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with the relevant provisions of national laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0021] In the process of realizing this invention, the inventors of this application discovered that existing technologies for multi-device collaborative control suffer from problems such as a single event classification dimension, lack of dynamic priority scheduling, and fuzzy spatiotemporal safety boundaries; resulting in delayed emergency response and inefficient resource allocation; traditional methods lack a precise spatiotemporal coordination mechanism, which can easily trigger a chain of risks. Example

[0022] Reference Figures 1-2 This is the first embodiment of the present invention, which provides a multi-device collaborative control method based on a bus communication protocol, including:

[0023] S100: Collect multimodal data and extract event data, and encapsulate the event data into event metadata.

[0024] Specifically, each device collects sensor data in real time through sensors and periodically reports location, temperature, speed, and environmental sensor data, such as obstacle distance and electromagnetic interference intensity, via the bus. A lightweight event detection model is deployed at the edge to extract event data, where events refer to abnormal events (such as collision warnings, device overheating, and communication timeouts). The location, timestamp, and abnormal parameter values ​​from the sensor data are encapsulated into event metadata, resulting in a list of event metadata with spatiotemporal tags.

[0025] Preferably, by integrating device sensor data and environmental sensor data through a bus, the correlation monitoring between device status and external environment can be realized. At the same time, a lightweight event detection model deployed on the edge side can be used to filter multimodal data in real time, which can significantly reduce the transmission pressure on the cloud. By encapsulating the location, timestamp, and parameter values ​​of abnormal events into standardized metadata with spatiotemporal tags, a unified data format is provided for subsequent hierarchical and collaborative control, improving the accuracy and parsability of event description.

[0026] S200: Parse the event metadata to obtain the event influence radius and event type, classify the events according to the event influence radius and event type, and obtain a classified event list.

[0027] Specifically, the event metadata is parsed to obtain the event's impact radius and event type.

[0028] Furthermore, classifying events based on their impact radius and type includes: mapping the impact radius and type to a three-dimensional assessment matrix, which consists of risk impact radius, recovery cost, and time delay tolerance; and classifying events into routine, emergency, and catastrophic levels based on the three-dimensional assessment matrix. The specific event classifications are as follows:

[0029] (1) The normal level is marked with a green label. The risk impact radius is limited to the device itself or 1-2 directly related devices. The recovery cost is low. It can be repaired by automatic restart, parameter fine-tuning or redundant module switching. The latency tolerance is high, ranging from minutes to hours. It allows processing when the bus is idle.

[0030] (2) The emergency level is marked with a yellow label. The risk impact radius is a local area, affecting 3-10 pieces of equipment in the same production line or subsystem. The recovery cost is moderate, requiring manual intervention or replacement of vulnerable parts. The time delay tolerance is moderate (second level), and a response is required before the event worsens.

[0031] (3) The critical level is marked in red. The risk impact radius is global, affecting the entire factory / system. The recovery cost is high, involving production interruption, safety accidents or scrapping of key equipment. The latency tolerance is extremely low (millisecond level), and the risk spread must be stopped immediately.

[0032] Furthermore, by classifying all abnormal events, a classified list of events is obtained.

[0033] Preferably, the threat level of an event is quantified using a three-dimensional evaluation matrix (risk radius, recovery cost, and latency tolerance), classifying events into normal, emergency, and critical levels. This clarifies the bus bandwidth usage strategy for different event levels and optimizes resource pre-allocation. Fault isolation based on the radius of influence can reduce the scope of local fault handling and avoid global resource congestion. At the same time, the hierarchical strategy can achieve a dynamic balance between recovery cost and response time.

[0034] S300: Based on the hierarchical event list, the event arbitration result is obtained through a dynamic arbitration mechanism.

[0035] Specifically, the bus controller monitors in real time whether multiple events overlap in space and time, for example, by monitoring whether the distance between the coordinates of two events is less than the sum of their radii of influence. When multiple events occur simultaneously, i.e., when multiple events overlap in space and time, a dynamic arbitration mechanism determines the priority of the abnormal events.

[0036] Furthermore, a three-dimensional weighted evaluation model is used to calculate the priority score of each event, and a processing queue is generated based on the priority score. When the fatal event is triggered, the arbitration process is skipped, the bus is directly preempted, and a preset emergency protocol is executed. When the priority score of the emergency event or the regular event exceeds a preset multiple of the score of the current processing event, a weight rebalancing mechanism is triggered.

[0037] Specifically, a three-dimensional weighted evaluation model is used to calculate the priority score for each event. The formula for calculating the priority score is as follows:

[0038]

[0039] in, , , All are weighting coefficients. ,and > > .

[0040] It should be noted that, The weighting is based on urgency, with lethality > emergency > normal. The spatiotemporal proximity weight represents the distance (physical / logical topology) between the event occurrence point and the affected device. The weighting of equipment health is dynamically adjusted based on the equipment's historical failure rate and remaining power.

[0041] Preferably, when setting weights, it is necessary to ensure that the weight of the critical level is large enough. A score greater than 0.65 ensures that even if the scores for spatiotemporal proximity weight and device health weight are low, it still guarantees the highest priority.

[0042] Preferably, when a fatal event is triggered, the bus is directly preempted and a preset emergency protocol (such as power failure or physical isolation) is executed, skipping the arbitration process. If the score of an emergency event or a regular event exceeds a preset multiple of 1.2 times the score of the currently processed event, a weight rebalancing mechanism is triggered. The weight rebalancing adjustment formula is as follows:

[0043]

[0044]

[0045]

[0046] in, This indicates the adjusted urgency weight. This represents the adjusted proximity weight, where 'a' represents the initial urgency weight and 'b' represents the initial proximity weight. This represents the weight adjustment amount, and k represents the sensitivity coefficient. Score the priority of new events. A score is assigned to the priority of the event currently being processed. This indicates the event type correction factor, such as 1.0 for emergency events and 0.5 for normal events.

[0047] Furthermore, if If the value is positive, keep it; otherwise, take 0.

[0048] Furthermore, when the urgency weight is increased, that is... By increasing the value of 'a', the weight of urgency in the score is strengthened, suppressing the advantage of events with high spatiotemporal proximity or high device health. Reducing the weight of proximity, i.e. This weakens the influence of spatiotemporal proximity and avoids physical / logical distance dominating decision-making.

[0049] It should be noted that the weight rebalancing mechanism only applies to emergency and normal events. Once a fatal event is triggered, it will forcibly monopolize resources (such as buses and computing units) until the closed-loop processing is completed.

[0050] Furthermore, based on the calculated priority scores, processing queues are generated from highest to lowest score. Computational / network resources are allocated according to the scores, with the highest priority event gaining bus priority. The next highest priority event enters a listening mode and transmits simplified data through a bus piggybacking mechanism, with an agreed-upon trigger threshold for piggybacking transmission, such as sending when the bus idle rate is >20%. When multiple events compete for bus resources simultaneously, the difference in their priority scores (i.e., the difference between the higher and lower scores) is compared to determine whether distributed voting needs to be initiated. If the priority score difference is 0.1, which is less than the set score difference threshold of 0.2, it indicates that the priority cannot be clearly distinguished by score. In this case, the distributed voting protocol is triggered, and the devices within the collaborative group vote to determine the arbitration result.

[0051] Preferably, a voting timeout mechanism is set, and the voting reverts to the default priority sort after the timeout.

[0052] Preferably, a three-dimensional weighted evaluation model (urgency, spatiotemporal proximity, and device health) is used to calculate event priority scores. This is combined with a weight rebalancing mechanism to dynamically correct misjudgments, ensuring that critical events can directly preempt the bus with extremely low latency. Contention conflicts are resolved through distributed voting and timeout rollback mechanisms, while bandwidth utilization is optimized using a bus piggybacking strategy, and arbitration reliability is improved.

[0053] S400: Based on the event arbitration result, perform distributed spatiotemporal collaborative decision-making to obtain the collaborative group execution plan.

[0054] Furthermore, based on the event metadata and the arbitration result, the temporal security boundary and spatial security boundary of the event are calculated; collaborative group devices are screened, and the temporal security boundary and spatial security boundary are broadcast to the collaborative group devices; candidate decisions are generated based on the collected multimodal data, and temporal and spatial proofs are added to the candidate decisions; the spatiotemporal security of the candidate decisions is verified, and proposals that exceed the temporal security boundary and spatial security boundary are discarded; the candidate decisions are scored for spatiotemporal security and efficiency, and the one with the highest score is selected as the execution plan.

[0055] Specifically, the device that triggers the event encapsulates the spatiotemporal tag, event type, and priority weight into an event broadcast frame. Based on the event coordinates and influence radius, physically nearby devices are selected (e.g., devices with a distance less than twice the influence radius are added to the coordination group). The maximum response time window is calculated using the event influence radius and event propagation speed from the event metadata, thus obtaining the time safety boundary. The formula for calculating the maximum response time window is as follows:

[0056]

[0057] in, R represents the maximum response time window, R represents the event influence radius, and V represents the event propagation speed. Indicates the safety redundancy time.

[0058] Furthermore, using the event coordinates as the center and the event influence radius R as the boundary, a spatial restricted area is generated, and a geometric model of the event influence domain is constructed to obtain the spatial safety boundary.

[0059] Preferably, the event propagation speed is dynamically configured according to the event type. For example, the event propagation speed for a collision warning is configured to be 5 m / s, and the event propagation speed for an overheating device is configured to be 0.1 m / s. The event propagation speed value is then marked in the event metadata.

[0060] Furthermore, devices within 2R of the event coordinates are selected for inclusion in the collaboration group. Based on a predefined task relationship diagram (such as the binding relationship between AGVs and target shelves), associated devices are forcibly added to the group. Time and space safety boundaries are broadcast to the devices in the collaboration group.

[0061] Furthermore, candidate decisions are generated based on local sensor data (such as current location and speed), with time-based proof (path execution time ≤ 10 ... ), and spatial proof (the path trajectory has no intersection with the spatial restricted area).

[0062] Preferably, the system checks whether the proposal execution time exceeds the time and space safety boundaries, and whether the equipment capabilities support the proposal. The PBFT improved algorithm is used to verify spatiotemporal safety, discarding proposals that exceed the time and space safety boundaries. Equipment within the collaborative group scores the proposals for spatiotemporal safety and efficiency; the proposal with the highest score becomes the execution plan.

[0063] Furthermore, the spatiotemporal safety score includes calculating the remaining safety time and spatial dimension of the proposal; the higher the proportion of remaining safety time, the higher the score. If there is a logical clock offset, a synchronization error penalty is deducted. The spatial dimension is calculated based on a trajectory prediction algorithm. The remaining safety time and spatial dimension of the proposal are combined according to weights to obtain the spatiotemporal safety score. The efficiency score includes calculating resource utilization and task timeliness. Resource utilization is the ratio of actual resource consumption to a baseline value; if actual resource consumption is higher than the baseline value, the score decreases; if it is lower than the baseline value, the score increases. Task timeliness is the ratio of execution time deviation to the fastest completion time under ideal conditions, used to measure the difference between the proposal completion time and the theoretical optimal time. The resource utilization and task timeliness are weighted and fused to obtain the efficiency score. The spatiotemporal safety score and efficiency score are weighted and fused to obtain a comprehensive score, and the one with the highest comprehensive score becomes the execution plan.

[0064] Furthermore, the scheme with the highest execution score is executed, and the device timing is aligned using a logical clock or a precise time protocol to obtain the collaborative group execution scheme.

[0065] Preferably, by calculating temporal and spatial security boundaries and dynamically configuring them in conjunction with event propagation speed, cascading risks can be effectively prevented. Candidate decisions are validated using an improved PBFT algorithm, and a collaborative group execution plan is generated, effectively balancing response timeliness and physical security. This ensures decision feasibility while reducing consensus energy consumption and shortening decision-making time. Device timing is aligned using logical clocks or precise time protocols to ensure the dual consistency of the collaborative group execution plan at both the physical and logical levels.

[0066] S500: Based on the hierarchical event list, the collaborative group execution plan is sent to the corresponding device to complete multi-device collaborative control.

[0067] Furthermore, based on the collaborative group's execution plan and the event level, a tiered broadcast strategy is adopted: when the event level is critical, a global broadcast is transmitted; when the event level is urgent, a regional multicast is transmitted; and when the event level is normal, a unicast or on-demand request is transmitted.

[0068] Specifically, the hierarchical broadcast strategy is adopted as follows:

[0069] When the event level is critical, the frame structure is [HEAD][EMERGENCY][COORD][ACTION], the transmission range is global broadcast, and the coordinates are from metadata.

[0070] When the event level is emergency, the frame structure is [HEAD][LOCAL][DELTA][PARAM], and the transmission range is regional multicast.

[0071] When the event level is normal, the frame structure is [HEAD][DATA], and the transmission range is unicast or on-demand request.

[0072] Furthermore, the collaborative group execution scheme is converted into device execution instructions. The device execution instructions are encapsulated into event-driven frames by the bus controller. Multimodal real-time data is collected, and the real-time speed in the multimodal real-time data is continuously compared with the target speed of the device execution instructions. The deviation between the real-time speed and the target speed is calculated. If the deviation is greater than a set deviation threshold, it is determined to be an execution anomaly, and an event re-decision is triggered.

[0073] Furthermore, the formula for calculating the deviation between the real-time speed and the target speed is as follows:

[0074]

[0075] in, This indicates the deviation between the real-time velocity and the target velocity. Indicates the target speed. Indicates real-time speed.

[0076] Preferably, core devices (such as event sources) receive complete instruction details. Edge devices receive simplified instructions (such as "decelerate to 0.5 m / s").

[0077] Preferably, the critical decision-making event is marked as urgent and inserted at the head of the arbitration queue to obtain the final device controller instruction.

[0078] Preferably, a maximum number of re-decision attempts is set. If the deviation is still greater than the set value after the maximum number of re-decision attempts is reached, the system switches to the backup plan, such as triggering a manual intervention process.

[0079] Furthermore, each device continuously reports its execution status, including event fading signals and execution status feedback. Fading detection is performed, which includes continuous monitoring of sensor data (such as temperature values). If five consecutive sampling cycles are normal, the event is marked as resolved. Bandwidth is gradually released according to the priority of devices within the collaboration group (event source device > strongly associated task devices > other devices), prioritizing non-critical devices. Log cleanup is performed, including deleting expired data and retaining summaries of abnormal events (such as event ID, processing result, and timestamp). Abnormal events retain full data (raw sensor data, arbitration process logs), with a set retention period, while regular events only retain summaries.

[0080] Preferably, a hierarchical broadcast strategy (global broadcast, regional multicast, unicast) is adopted to significantly improve bus bandwidth utilization. At the same time, closed-loop control is achieved through calculation speed deviation and re-decision mechanism to reduce the risk caused by execution anomalies. Combined with event decay detection and log hierarchical cleanup mechanism, a balance between resource release efficiency and fault traceability is ensured to meet high security standards.

[0081] The present invention also provides a multi-device collaborative control system based on a bus communication protocol, for implementing a multi-device collaborative control method based on a bus communication protocol. The system includes a control module, the control module including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement the multi-device collaborative control method based on a bus communication protocol.

[0082] This invention provides a storage medium storing a program that, when executed by a processor, implements the multi-device collaborative control method based on a bus communication protocol.

[0083] This invention provides a processor for running a program, wherein the program executes the multi-device collaborative control method based on a bus communication protocol.

[0084] This invention provides a device including a processor, a memory, and a program stored in the memory and executable on the processor. The processor executes a multi-device collaborative control method based on a bus communication protocol. The device described herein can be a server, PC, tablet, mobile phone, etc.

[0085] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing a multi-device collaborative control method based on a bus communication protocol.

[0086] Those skilled in the art will understand that embodiments of this application can provide methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0087] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0088] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0089] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0090] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0091] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0092] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0093] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0094] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A multi-device collaborative control method based on a bus communication protocol, characterized in that, include: Collect multimodal data and extract event data, then encapsulate the event data into event metadata; Parse the event metadata to obtain the event impact radius and event type. Classify the events according to the event impact radius and event type to obtain a classified event list, including: Map the event's influence radius and event type to a three-dimensional evaluation matrix. The three-dimensional assessment matrix consists of risk impact radius, recovery cost, and time delay tolerance. Based on the three-dimensional evaluation matrix, events are classified into routine events, emergency events, and fatal events. The impact radius of a routine-level event risk is limited to the equipment itself or 1-2 directly related equipment; the impact radius of an emergency-level event risk is a local area, affecting 3-10 equipment in the same production line or subsystem; the impact radius of a catastrophic event risk is a global impact, affecting the entire factory / system. Based on the tiered event list, an event arbitration result is obtained through a dynamic arbitration mechanism, including: A three-dimensional weighted evaluation model is used to calculate the priority score for each event, and a processing queue is generated based on the priority score. When the aforementioned fatal event is triggered, the arbitration process is skipped, the bus is directly preempted, and a preset emergency protocol is executed. When the priority score of the emergency-level event or the regular-level event exceeds a preset multiple of the score of the current event being processed, a weight rebalancing mechanism is triggered. The weight rebalancing mechanism includes: Calculate the adjusted urgency weight and proximity weight; Recalculate the priority score for each event using the adjusted urgency and proximity weights; A new processing queue is generated based on the recalculated priority score; The formula for weight rebalancing is as follows: in, This indicates the adjusted urgency weight. This represents the adjusted proximity weight, where 'a' represents the initial urgency weight and 'b' represents the initial proximity weight. This represents the weight adjustment amount, and k represents the sensitivity coefficient. Score the priority of new events. The priority score is assigned to the event currently being processed. This indicates the event type correction factor, such as 1.0 for emergency events and 0.5 for normal events. Based on the event arbitration results, a distributed spatiotemporal collaborative decision-making process is performed to obtain the collaborative group execution plan. Based on the graded event list, the collaborative group execution plan is sent to the corresponding device. When the event level is critical, a global broadcast is transmitted; when the event level is urgent, a regional multicast is transmitted; when the event level is normal, a unicast or on-demand request is transmitted; thus completing multi-device collaborative control.

2. The multi-device collaborative control method based on a bus communication protocol according to claim 1, characterized in that, The step of making distributed spatiotemporal collaborative decisions based on the event arbitration results to obtain a collaborative group execution plan also includes: implementing the execution plan and aligning device timings through a logical clock or a precise time protocol to obtain the collaborative group execution plan.

3. The multi-device collaborative control method based on a bus communication protocol according to claim 1, characterized in that, The step of sending the collaborative group execution plan to the corresponding device based on the hierarchical event list further includes: converting the collaborative group execution plan into device execution instructions, encapsulating the device execution instructions into event-driven frames through a bus controller, collecting multimodal real-time data, continuously comparing the real-time speed in the multimodal real-time data with the target speed of the device execution instructions, and calculating the deviation between the real-time speed and the target speed. If the deviation is greater than a set deviation threshold, it is determined to be an execution anomaly, and event re-decision is triggered.

4. The multi-device collaborative control method based on a bus communication protocol according to claim 3, characterized in that, The event re-decision includes setting a maximum number of re-decision attempts. If the deviation is still greater than the set value after the maximum number of re-decision attempts is reached, then the system switches to a backup collaborative control scheme.

5. A multi-device collaborative control system based on a bus communication protocol, characterized in that, The system includes a control module, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the computer program to implement the multi-device collaborative control method based on a bus communication protocol according to any one of claims 1-4.

Images