Multi-device cooperative control method and system

Abstract

The invention discloses a multi-device cooperative control method and system, and belongs to the technical field of device cooperative control, and the method specifically comprises the steps: collecting the capability parameters and state information of each device, constructing a device capability map, carrying out the global-clock-free time sequence alignment of each device based on a reference signal and an event causal chain, and carrying out the global clock-free time sequence alignment. A cross-device logic time sequence is generated, a multi-device cooperative control plan is generated based on the device capability atlas and the logic time sequence, the multi-device cooperative control plan takes task fragments as basic units, and a dynamic priority identifier is configured for each task fragment; the multi-device cooperative control plan is issued to each device in the form of a capability token, the capability token comprises a device capability signature, an execution period label and a revocable condition mark, and each device performs execution only when the verification token is valid; according to the invention, automatic cooperative control of a plurality of reliability test devices is realized, and the parallelism and scheduling flexibility of a complex experiment process are improved.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of device cooperative control, and in particular to a multi-device cooperative control method and system. BACKGROUND

[0002] After the semiconductor device is manufactured, it needs to go through a series of reliability verification to evaluate its failure mode and life characteristics under different working conditions. Common reliability tests include high temperature working life, temperature cycling, high acceleration stress test, electromigration test, electrostatic discharge test, etc. These tests often need to run for a long time and are carried out under harsh temperature, humidity, voltage, current and other conditions.

[0003] In the reliability laboratory, there are many types of test equipment, including temperature and humidity stress boxes, power supply stress loading devices, probe test benches, failure analysis instruments, data acquisition and monitoring platforms, etc. These devices are usually produced by different manufacturers, and the communication protocols, data interfaces and timing logic are quite different, which leads to many problems in actual cooperative use.

[0004] In the prior art, some semiconductor reliability test platforms introduce centralized monitoring software, but it is often limited to single manufacturer equipment, lacks compatibility for heterogeneous devices, and it is difficult to achieve real multi-device dynamic cooperative control. At the same time, the existing scheduling strategies are mostly based on fixed clock synchronization and static priority setting, which cannot meet the complex requirements of multi-task dynamic switching, cross-device causal logic constraints and real-time safety checking. SUMMARY

[0005] In view of the deficiencies of the prior art, the present application proposes a multi-device cooperative control method and system, which can dynamically model heterogeneous devices, align cross-device timing, and cooperatively schedule and control safety.

[0006] To achieve the above purpose, the present application provides the following technical solutions: A multi-device cooperative control method, comprising: Collecting the capability parameters and state information of each device, and constructing a device capability map, the device capability map including mutual exclusion relationships and dependency relationships between devices; Aligning the timing of each device without a global clock based on reference signals and event causal chains, and generating a cross-device logical time sequence; Generating a multi-device cooperative control plan based on the device capability map and the logical time sequence, the multi-device cooperative control plan taking task fragments as the basic unit, and configuring a dynamic priority identifier for each task fragment; Distributing the multi-device cooperative control plan to each device in the form of a capability token, the capability token including a device capability signature, an execution time period label, and a revocable condition marker, and each device only executes when the token is verified to be valid.

[0007] Specifically, the ability parameters and state information of each device are collected, and a device capability map is constructed, including: Collecting the ability parameters and state information of each device, and mapping the ability parameters and state information into an ability vector; Based on the ability vector, the ability unit of each device is constructed, and the ability boundary point set is generated by random disturbance; The ability boundary point set is embedded in the graph structure to generate a multi-level association graph between devices, wherein each layer corresponds to a different type of constraint relationship; Based on the multi-level association graph between devices, self-generated labels are introduced to generate unique semantic labels for each device node, and a device capability map is obtained.

[0008] Specifically, the time sequence of each device is aligned without global clock based on the reference signal and event causal chain, and a cross-device logical time sequence is generated, including: The reference device periodically sends a synchronization trigger signal, and each device records the initial event stamp at the trigger moment locally; Each device annotates the local generated operation events with causal relationship to obtain a local event sequence; The local event sequence is extended to a logical event chain through cross-event comparison, and the logical event chain is arranged in causal priority; Based on the logical event chain, a virtual hierarchical index is assigned to each logical event, and the virtual hierarchical index is used as a cross-device logical time sequence.

[0009] Specifically, the multi-device collaborative control plan is generated based on the device capability map and the logical time sequence, including: On the basis of the device capability map and the logical time sequence, the device capabilities are matched with the task requirements to form a candidate task mapping set; The candidate task mapping set is processed by graph partitioning to generate a task fragment set, each task fragment is limited to a single execution path and records the trigger condition; Based on the task fragment set, a dynamic priority identifier is assigned to each task fragment, and the priority identifier is updated in the planning stage according to the device state or task progress; The task fragments in the task fragment set are rearranged in time sequence to form a multi-level multi-device collaborative control plan, wherein each layer corresponds to a collaborative combination of a type of task fragment; Based on the multi-level multi-device collaborative control plan, parallel placeholders are established for task fragments at different levels, and the placeholders remain unbound before actual delivery.

[0010] Specifically, the dynamic priority identifier is assigned to each task segment based on the task segment set, including: A candidate weight set is generated for the task segment set, which is formed by the combination of the trigger condition, multi-device correlation degree, and resource consumption factor of the task segment; Based on the candidate weight set, the weight relationship between different task segments is compared by cross iteration, and the priority transition point is recorded; The priority transition points are arranged into a hierarchical sequence to form a multi-level priority structure; Based on the multi-level priority structure, a priority update mechanism is set to trigger the migration of task segments between different levels according to the device state change in the planning stage.

[0011] Specifically, the task segments in the task segment set are rearranged in a time sequence to form a multi-level multi-device collaborative control plan, wherein each level corresponds to a collaborative combination of a type of task segment, including: The multi-level priority structure is matched with the task segment set, the time segment window is preliminarily divided, and the task segments are assigned to the corresponding time segment window; In the divided time segment window, the task segments are sequentially sorted according to the trigger condition to form a basic time sequence; The basic time sequence is extracted in multiple layers, and the task segments with correlation are extracted into the same control layer to generate a dual structure of intra-layer sequence and inter-layer sequence; Based on the dual structure, mutual exclusion markers and dependency markers are inserted between different control layers to form a multi-level multi-device collaborative control plan.

[0012] Specifically, based on the dual structure, mutual exclusion markers and dependency markers are inserted between different control layers to form a multi-level multi-device collaborative control plan, including: The intra-layer sequence and inter-layer sequence are cross-scanned to identify pairs of task segments with conflict or dependency relationship; Mutual exclusion candidate sets and dependency candidate sets are generated between the identified task segment pairs, and each candidate set is assigned a unique logical marker; The logical markers are inserted into the dual structure to bind the logical markers with the corresponding task segments, and a cross-level marker chain is formed; Based on the marker chain, the order of task segments between control layers is rearranged to generate a multi-level multi-device collaborative control plan.

[0013] Specifically, the multi-device collaborative control plan is issued to each device in the form of a capability token, including: Based on the multi-level multi-device collaborative control plan, an ability token is generated for each task segment, the ability token is composed of a device capability signature, an execution time period label and a revocable condition label; In the generated ability token, a one-time random sequence is embedded as a token identification factor, and the identification factor is bound with a task segment index; The ability token is distributed to the corresponding device, and each device calls and verifies whether the identification factor is consistent with the ability signature in the locally stored token pool; For the ability token that passes the verification, the corresponding task segment is triggered to be executed by the device, and the ability token is automatically destroyed after the execution is completed.

[0014] A multi-device collaborative control system for implementing the multi-device collaborative control method, comprising a graph construction module, a timing alignment module, a control plan generation module and a delivery execution module; The graph construction module is used to collect the capability parameters and state information of each device, and construct a device capability graph, the device capability graph contains mutual exclusion relationship and dependency relationship among devices; The timing alignment module performs timing alignment on each device without a global clock based on a reference signal and an event causal chain, and generates a logical time sequence across devices; The control plan generation module generates a multi-device collaborative control plan based on the device capability graph and the logical time sequence, the multi-device collaborative control plan takes a task segment as a basic unit, and configures a dynamic priority identifier for each task segment; The delivery execution module is used to deliver the multi-device collaborative control plan to each device in the form of an ability token, the ability token contains a device capability signature, an execution time period label and a revocable condition label, and each device only performs execution when the token is verified to be valid.

[0015] Specifically, the control plan generation module comprises a task segment generation unit, a priority identifier allocation unit and a control plan generation unit. The task segment generation unit is used to match each device capability with a task demand to form a candidate task mapping set, and perform graph partitioning processing on the candidate task mapping set to generate a task segment set; The priority identifier allocation unit is used to allocate a dynamic priority identifier for each task segment; The control plan generation unit is used to rearrange the task segments in the task segment set in a time sequence manner to form a multi-level multi-device collaborative control plan.

[0016] Compared with the prior art, the beneficial effects of the present application are: The application provides a multi-device cooperative control method and system. The method can realize dynamic cooperative operation of heterogeneous devices in a unified framework through capability modeling, logical time sequence alignment, task fragmentation arrangement and tokenization issuing. The method can avoid the traditional mode of relying on a single global clock or fixed priority, and can ensure the ordered triggering and flexible switching of tasks in a distributed environment through the introduction of a multi-level control plan and a revocable capability token mechanism, so as to realize the automatic cooperative control of multiple reliability test devices, improve the parallelism and scheduling flexibility of complex experimental processes, and maintain the constraint consistency and operation controllability between devices during operation. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A multi-device cooperative control method flowchart is provided in the application. Figure 2 A multi-level multi-device cooperative control plan schematic diagram is provided in the application. Figure 3 A multi-device cooperative control system architecture diagram is provided in the application. DETAILED DESCRIPTION

[0018] The application will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the application. These are within the scope of protection of the application.

[0019] In order to make the purpose, technical scheme and advantages of the application clearer, the application will be further described in detail below with reference to the drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the application and do not limit the application.

[0020] It should be noted that the features in the embodiments of the application can be combined with each other without conflict, and are within the scope of protection of the application. In addition, although the functional modules are divided in the device schematic diagram, and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from the module division in the device or the order in the flowchart. In addition, the "first", "second", "third" and the like used in the application do not limit the data and execution order, but only distinguish the same items or similar items with basically the same function and effect.

[0021] Unless otherwise defined, all technical and scientific terms used in this specification shall have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the description of the application herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. All publications, patent applications, patents, and other references mentioned in this specification are incorporated by reference. As used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the content clearly dictates otherwise. Thus, for example, reference to "a" or "the" ingredient includes one or more compounds.

[0022] Embodiment 1 Please refer to Figure 1 The application provides a multi-device cooperative control method, comprising the following specific steps: Step S1: collecting the capability parameters and state information of each device, and constructing a device capability map, wherein the device capability map comprises mutual exclusion relationships and dependency relationships between devices.

[0023] The specific steps of step S1 are: Step S101: collecting the capability parameters and state information of each device, and mapping the capability parameters and state information into a capability vector.

[0024] In this embodiment, the capability parameters of the device include power output range, accuracy level, interface type, environmental adaptability, and other dimensional information, and the state information includes current load, occupancy time, temperature state, interface occupancy, and other dynamic indicators; after the collection is completed, these data are dimensionally sorted, and the originally heterogeneous parameters are standardized into a unified feature set; the formation of the capability vector is not a simple parameter stacking, but a mapping relationship that converts the device capability and state into a coordinate point in a multi-dimensional space, for example, the power parameter is mapped into an energy dimension, the interface compatibility is mapped into an interaction dimension, and the occupancy rate and real-time load are mapped into a resource dimension, thereby forming a vector set that can be used for comparison and scheduling in the same vector space; after this mapping process, the originally scattered and not directly comparable capability parameters and state data are converted into capability vectors with mathematical structures.

[0025] Step S102: based on the capability vector, constructing a capability unit of each device, and generating a capability boundary point set through random disturbance.

[0026] In the embodiment, the capability unit not only contains the static capability parameters of the device, but also contains the constraint factors that can dynamically change with the running state, converts the heterogeneous parameters of different types of devices into the capability unit in a unified form, and makes it comparable and combinable; in order to avoid that the representation of the capability unit is too idealized, the method of introducing random disturbance is used to generate the capability boundary point set, the principle of which is to apply a disturbance offset within a controlled range to the key parameters in the capability unit, thereby deducing a set of virtual points that approximate the actual limit running conditions; for example, positive and negative fluctuations are introduced to the power output parameter, and delay factors of different amplitudes are introduced to the temperature adjustment rate, and then these disturbed data points are collected as the boundary point set; in this way, the edge performance of the device under real working conditions is included in the modeling range, and the final capability unit not only contains the ideal value, but also describes the potential running trajectory under extreme conditions through the boundary point set.

[0027] Step S103: embedding the capability boundary point set into a graph structure to generate a multi-level association graph between devices, wherein each layer corresponds to different types of constraint relationships.

[0028] In the embodiment, the capability boundary points of each device are embedded into the graph space as nodes, and the edge relationship between different nodes is established through similarity or difference calculation; then the direct mapping between devices is formed on the basis layer of the graph, such as power matching relationship, interface compatibility relationship, etc.; then the multi-level association graph is gradually generated by classifying the edge relationship; in the first layer, the edges between nodes mainly represent physical constraint relationships, such as electrical parameters or temperature interval compatibility; in the second layer, the edges represent logical dependency relationships, for example, one device action must be triggered after another device task is completed; in the third layer, it can be further extended to safety and redundancy constraint relationships, such as mutual exclusion operation or backup substitution condition; through multi-level embedding, an association graph containing three types of constraints of physics, logic and safety is finally formed.

[0029] Step S104: based on the multi-level association graph between devices, introducing self-generated labels to generate unique semantic labels for each device node to obtain the device capability graph.

[0030] In the embodiment, by analyzing the connection mode and node features of the devices in different constraint layers, the feature combinations are mapped to label elements such as power matching features, interface dependency features, and redundant fault tolerance features, and a unique label is combined for each device node by a self-generation mechanism. The label generation process is not a simple numbering or indexing, but a comprehensive deduction based on multi-level constraint relationships. For example, when a node is closely connected to multiple power nodes in the physical layer and simultaneously assumes a task precondition in the logical layer, the semantic label of the node will automatically integrate the power core and trigger source features. The device capability graph is not only a parameter set or a correlation graph, but further evolves into a device capability graph.

[0031] Step S2: Time sequence alignment of each device without global clock based on reference signal and event causal chain, and generation of cross-device logical time sequence.

[0032] The specific steps of step S2 are: Step S201: The reference device periodically sends a synchronization trigger signal, and each device records the initial event stamp at the trigger moment locally.

[0033] In the embodiment, the reference device generates a trigger pulse according to a preset period, and broadcasts the pulse signal to multiple devices to be coordinated at the same time. Each device generates an event stamp in its local timer or time management module at the moment of receiving the pulse to mark the occurrence of the synchronization point. The event stamp recording process is not only the direct sampling of the time value, but also the localized storage combined with the clock offset and delay characteristics of each device. Finally, a set of initial event stamps is obtained.

[0034] Step S202: Each device annotates the local generated operation events with causal relationships to obtain a local event sequence.

[0035] In the embodiment, each device identifies the trigger conditions between events when collecting operation events, such as the voltage rise action triggering the current monitoring action and the temperature change action preceding the fan start action, and records these dependency relationships in the form of annotations. The construction process of the local event sequence does not depend on a unified clock, but is a sequential generation driven by causal annotation. In a device, different events may exist in concurrent or delayed execution situations. By annotating the causal order, these complex relationships are abstracted into a computable local sequence, and finally a local event sequence is obtained.

[0036] Step S203: The local event sequence is extended to a logical event chain through cross-event comparison, and the logical event chain is arranged in a causal priority.

[0037] In the embodiment, features of events in each local event sequence are extracted, such as event trigger condition, resource occupation object, state change indication, etc.; then, cross comparison is performed to determine the causality coupling points between events of different devices; through the cross matching manner, events scattered in different devices are connected in series to form a logical connection across devices; the arrangement of the logical event chain is not based on the physical time sequence, but the order is determined according to the causality priority; in the construction process, if there is an explicit trigger relationship between two events, they are arranged in the front and back order; if the two events belong to parallel or independent, they are classified into the same priority level; in this process, the logical event chain exhibits a hierarchical structure, which not only clearly identifies the trigger path across devices, but also integrates concurrency and series in a logical framework, and finally obtains the logical event chain.

[0038] Step S204: Based on the logical event chain, a virtual hierarchical index is assigned to each logical event, and the virtual hierarchical index is used as a logical time sequence across devices.

[0039] In the embodiment, according to the explicit front-back dependency relationship in the logical event chain, the events are divided into several levels, and the events in each level do not have a direct trigger relationship and can be executed in parallel; then, a uniform hierarchical index number is assigned to the events in each level, and a cross-device identifier is embedded in the index, and each logical event is assigned a markable hierarchical number; the virtual hierarchical index does not depend on the physical time or the device local clock, but is used as a unified alignment reference across devices; for example, when a temperature regulation event and a voltage loading event are marked as the same hierarchical index, they will be regarded as parallel tasks in the cross-device plan; when a data acquisition event is marked as a higher hierarchical index than a power-on event, the collaborative plan will forcibly specify the order at the logical level, and finally a logical time sequence across devices is obtained.

[0040] Step S3: Based on the device capability map and the logical time sequence, a multi-device collaborative control plan is generated, the multi-device collaborative control plan takes a task fragment as a basic unit, and a dynamic priority identifier is configured for each task fragment.

[0041] The specific steps of step S3 are: Step S301: Based on the device capability map and the logical time sequence, the device capabilities are matched with the task requirements to form a candidate task mapping set.

[0042] In the embodiment, the task requirement is analyzed, and the task requirement is decomposed into constraint units such as a power interval, an interface form, an execution time limit, a concurrency condition and the like; then, nodes in a device capability graph are searched, and a device set capable of meeting the constraint units of the task is identified according to semantic labels and capability vector features; on this basis, the devices with the capability conditions are aligned with corresponding task nodes in combination with a logical time sequence, to obtain a preliminary candidate matching relationship; the candidate task mapping set is not a unique solution, but a selectable set formed through multi-dimensional condition intersection, for example, a certain test task can be completed by a high-power power supply or can be completed by parallel connection of multiple low-power devices; a certain data acquisition task can be bound to a high-speed interface device or can be bound to a low-speed device but with a prolonged time sequence; in this way, the task requirement is extended and mapped to multiple device combinations, to form the candidate task mapping set.

[0043] Step S302: performing graph division processing on the candidate task mapping set to generate a task segment set, each task segment being limited to a single execution path and recording a trigger condition.

[0044] In the embodiment, the candidate task mapping set is regarded as a two-part graph structure containing task nodes and device nodes, and a corresponding relationship between a task requirement and a device capability is connected in the form of an edge; then, the edge set is decomposed in the graph structure through a division algorithm, so that each division unit only retains an effective path from a task node to a device node, and a non-overlapping execution chain is stripped out, to obtain each division unit, which constitutes a task segment; the generation of the task segment also needs to record a trigger condition to clearly define the pre-logic of execution; for example, when a task segment depends on a temperature reaching a certain threshold or a voltage reaching a stable interval, the condition is attached to the task segment as a trigger label; the originally complex candidate task mapping is deconstructed into a set of clear task segments, each segment being limited to a single execution path and being attached with a trigger condition.

[0045] Step S303: based on the task segment set, a dynamic priority identifier is allocated to each task segment, and the priority identifier is updated in a planning stage according to a device state or a task progress.

[0046] The specific steps of step S303 are as follows: Step S3031: a candidate weight set is generated for the task segment set, and the candidate weight set is formed by combination of a trigger condition of a task segment, a multi-device correlation degree and a resource consumption factor.

[0047] In the embodiment, the trigger condition of each task fragment is parsed and converted into measurable elements such as time sensitivity and logical dependency degree; secondly, the correlation degree of the task fragments between devices is identified, for example, whether multiple devices are needed to cooperate to complete the task, whether competition for critical device resources is formed, and these information is taken as the correlation dimension parameter; finally, the three types of parameters are combined to generate a comprehensive candidate weight set by combining the resource consumption factor of the task fragment during execution, including power occupation, interface bandwidth occupation, and running time consumption.

[0048] Step S3032: Based on the candidate weight set, the weight relationship between different task fragments is compared by cross iteration, and the priority transition point is recorded.

[0049] In the embodiment, the task fragments are combined in pairs, and each time the evaluation dimension is switched between the trigger condition sensitivity, device correlation degree, and resource consumption factor; in each iteration, the relative priority order of the two task fragments in a certain dimension is determined by comparing the weight of the two task fragments in the dimension, and the comparison result is stored in the priority relationship table, and after multiple cross iterations, a set of priority ordering relationships covering all task fragments is gradually formed; during the cross iteration process, some task fragments show opposite priority orders in different dimensions, for example, they are prioritized in the trigger condition but lag behind in resource consumption, and such cases are expressed by recording the priority transition point, that is, the critical position where the priority switching between fragments is marked in the comparison result; the priority transition point enables the subsequent multi-level priority structure to more accurately reflect the dynamic ordering characteristics of the task fragments under different conditions; and finally a dynamic sequence containing transition information is obtained.

[0050] Step S3033: The priority transition points are arranged into a hierarchical sequence to form a multi-level priority structure.

[0051] In the embodiment, all priority transition points are sorted according to their order of appearance and corresponding task fragment pairs, and these transition points are arranged in sequence; then, with the sequence as a reference, the task fragments are divided into different levels according to the stable interval between adjacent transition points; the task fragments included in each level maintain a relatively stable priority relationship within the interval, and the transition points establish a connection relationship between different levels to form a hierarchical priority framework structure.

[0052] Step S3034: Based on the multi-level priority structure, a priority update mechanism is set to trigger the migration of task fragments between different levels according to the device state change in the planning stage.

[0053] In the embodiment, a set of trigger conditions is preset for each level, which is composed of device running state parameters such as power load rate, temperature stability, interface occupancy, etc. When the device state changes, the scheduling module compares each task segment in the current level according to the condition set. If the execution condition of a segment no longer meets the constraint of the original level, it is marked as a migration object. When the migration segment is marked, the target level is found in the priority structure according to its latest state attribute, and the segment is re-assigned to the level. If there is no completely matched condition in the target level, it is allowed to be temporarily placed in the transition level for subsequent adjustment.

[0054] Step S304: The task segments in the task segment set are rearranged in time sequence to form a multi-level multi-device collaborative control plan, wherein each level corresponds to a collaborative combination of a type of task segment.

[0055] The specific steps of step S304 are as follows: Step S3041: Match the multi-level priority structure with the task segment set, preliminarily divide the time segment window, and assign the task segment to the corresponding time segment window.

[0056] In the embodiment, according to the priority level, each segment in the task segment set is matched with the corresponding level to obtain a one-to-one correspondence between the task and the priority. Then, a plurality of windows are preliminarily divided on the time axis, each window serving as a bearing interval for a group of task segments. The division of the window is based on the time distribution of the trigger condition, the duration of the resource occupation, and the concurrency limit of the device, etc. In this way, the task segment is no longer an abstract execution unit, but is placed in a specific time window to form a preliminary scheduling arrangement.

[0057] It should be noted that the division of the time segment window is not only a sequential cutting, but also uses the priority structure as a guide. For example, task segments at higher levels are preferentially placed in the previous window, while task segments of the same level with parallel characteristics can be assigned to the same window to achieve parallel scheduling. For task segments with dependency relationships across levels, a sequential constraint chain is established between the windows. Finally, a group of time segment windows with level logic is obtained, each window containing a plurality of task segments, and the distribution of these segments preliminarily meets the priority and dependency conditions.

[0058] Step S3042: In the divided time segment window, the task segments are sequentially sorted according to the trigger condition to form a basic time sequence.

[0059] In the embodiment, trigger condition information of each task segment is extracted, including threshold type condition, state dependent condition and external event condition, and the conditions are converted into comparable logical sequence; then in the same time window, the task segments are arranged in sequence according to the strictness of the trigger condition and the order of the dependent chain, and a basic time sequence is constructed.

[0060] Step S3043: The basic time sequence is extracted in multiple layers, and the task segments with correlation are separated into the same control layer to generate a dual structure of intra-layer sequence and inter-layer sequence.

[0061] In the embodiment, the correlation characteristics between the task segments in the basic time sequence are analyzed, including resource sharing relationship, trigger dependent relationship and execution result transmission relationship; then according to the correlation characteristics, the task segments with correlation are separated and aggregated into the same control layer to form an intra-layer sequence; at the same time, the order between different control layers is defined through the cross-layer dependent relationship, and finally an inter-layer sequence is formed, and the original single-dimensional linear time sequence is expanded into a dual structure of intra-layer parallel and inter-layer connectable; the dual structure logically carries both concurrent and sequential relationships, for example, in the same control layer, if multiple task segments share the same trigger condition but have no direct dependency between them, they are arranged as an intra-layer parallel sequence; when the result of a task segment in a control layer becomes a precondition of another layer segment, a sequential constraint is established between layers.

[0062] Step S3044: Based on the dual structure, mutual exclusion markers and dependent markers are inserted between different control layers to form a multi-layer multi-device collaborative control plan.

[0063] In the embodiment, task segment pairs in conflict between different control layers are identified, such as tasks sharing the same power channel or occupying the same test interface; for such task segments, mutual exclusion markers are inserted in the inter-layer relationship, so that they cannot be executed at the same time in the scheduling process; then, the front-back dependent chain between cross-layers is analyzed, for example, the data acquisition task of a control layer needs to be completed before the stress loading task of the previous layer, and a dependent marker is inserted at the corresponding position to fix the execution order. The specific steps of step S3044 are: Step S30441: The intra-layer sequence and inter-layer sequence are cross-scanned to identify task segment pairs with conflict or dependent relationship.

[0064] In the embodiment, the pairs of task fragments in the intra-layer sequence are compared to detect whether there is resource occupation overlap, execution condition mutual exclusion or shared interface cannot be called simultaneously; if such contradiction is detected, the task fragment pairs are marked as conflict pairs; then in the inter-layer sequence, the task fragments are compared one by one based on the logical chain between the preceding and subsequent layers, the fragments that must rely on the preceding results to trigger are identified and bound to the preceding fragments as dependent pairs; it should be noted that the cross scanning process is not only static matching, but also dynamic determination combined with the trigger condition, execution period and device capability label of the task fragment; for example, although two task fragments belong to different intra-layer sequences, if the device capability units called by the two task fragments exist in cross, the two task fragments will still be identified as conflict pairs in the scanning; for another example, if the trigger condition of a task fragment contains the preceding requirement of completing data acquisition, the task fragment will be automatically marked as a dependent pair when scanning the inter-layer sequence; finally, a set of classified and sorted conflict fragment pairs and dependent fragment pairs are obtained.

[0065] Step S30442: Generate mutual exclusion candidate set and dependent candidate set between the identified task fragment pairs, and assign a unique logical label to each candidate set.

[0066] In the embodiment, all conflict fragment pairs are aggregated, and conflict tasks involving the same type of resource or the same type of interface are classified into a mutual exclusion candidate set; in the same way, dependent fragment pairs with subsequent trigger logical chain are classified into a dependent candidate set; in this way, the dispersed conflict and dependent relationships are structured and integrated into a limited number of candidate sets, and each candidate set represents a specific logical constraint pattern; each candidate set is assigned a unique logical label when generated, which not only serves as an identifier of the set, but also carries information about the constraint type and scope; for example, the logical label of a mutual exclusion candidate set contains the resource occupation type and the corresponding device label, and the logical label of a dependent candidate set contains the sequence number and trigger condition of the preceding and subsequent events.

[0067] Step S30443: Insert the logical label into the double structure, bind the logical label to the corresponding task fragment, and form a cross-layer label chain.

[0068] In the embodiment, the positions of the task fragments belonging to the candidate set are located in the intra-layer sequence and the inter-layer sequence, the corresponding logical label is directly inserted into the position, and the trigger condition and execution path information of the task fragment are combined; then, according to the front and rear connection order of the task fragments in the double structure, the multiple logical labels are sequentially connected to form a label chain covering different layers.

[0069] Step S30444: Based on the label chain, the order of the task fragments between the control layers is rearranged to generate a multi-layer multi-device collaborative control plan.

[0070] In this embodiment, the control layer relationship in the original double structure is rearranged as a whole by using the generated mark chain in the previous step, so as to realize the global consistency of multi-device tasks in logic; specifically, first, the order of the task fragments between layers is compared and adjusted according to the positions of the mutual exclusion marks and the dependency marks in the mark chain; if two task fragments cannot be parallel due to mutual exclusion marks, they are re-assigned to different time windows or different control layers; if two task fragments have a front and back connection relationship due to dependency marks, a fixed order link is established in the structure; through this rearrangement process, the original relatively independent intra-layer sequence and inter-layer sequence are recombined in the global range and evolved into a multi-level cooperative control framework.

[0071] It should be noted that the rearrangement is not only adjusting the task position, but also adjusting the hierarchical structure of the control layer in combination with the global coverage range of the mark chain; for example, when a mark chain spans three different levels, the execution relationship of the three levels needs to be redefined, some task fragments are moved to a higher priority layer, or some tasks are delayed to a subsequent level, after this process, all task fragments have a clear execution order and hierarchical attribution in the new structure; the final multi-level multi-device cooperative control plan not only retains the parallel characteristics within the layer, but also guarantees the logical consistency through the rearrangement across layers.

[0072] As shown in Figure 2 , the multi-level multi-device cooperative control plan is composed of multiple control layers, each control layer is used to carry a specific category of task fragments, and the logical constraints are expressed through dependency marks, mutual exclusion marks and parallel placeholders.

[0073] In Figure 2 , the control layer L1 contains task fragment T1 and task fragment T2, which are connected by a dependency mark, indicating that the triggering of task fragment T2 must be based on the completion of task fragment T1; the control layer L2 contains task fragment T3 and task fragment T4, which are connected by a mutual exclusion mark, such as the mutual exclusion mark × in Figure 2 , indicating that they cannot be executed in parallel during scheduling, and one of them needs to be selected for execution according to the device state and planning rules, Figure 2 , the square symbol represents a parallel placeholder, and the √ symbol represents a parallel confirmation mark; among them, task fragment T4 is attached with a parallel placeholder, which is used to form a parallel scheduling relationship with other task fragments in actual delivery; the control layer L3 contains task fragment T5 and task fragment T6, which are also connected by a dependency mark, indicating that the execution of task fragment T6 can be triggered only after the completion of task fragment T5.

[0074] In addition to the above hierarchical structure, Figure 2An independent task sequence Tj is also shown, which contains task fragment T8 and task fragment T7 arranged in a dependent relationship in sequence, and is equipped with a parallel placeholder. The independent sequence is used to represent a specific task logic chain across the hierarchy, and is incorporated into the overall control plan in subsequent scheduling.

[0075] After the task fragment relationship is established, each control layer and the independent sequence are allocated time segments and globally scheduled by a unified scheduling time module. The scheduling results are then mapped to specific physical devices, including device D1, device D2, device D3, and device D4. In this way, the originally dispersed task fragments are uniformly arranged under the multi-level structure and mapped to specific devices through the control of scheduling time, forming an executable collaborative control plan.

[0076] Step S305: Based on the multi-level multi-device collaborative control plan, a parallel placeholder is established for the task fragments of different levels, and the placeholder remains unbound before actual issuance.

[0077] Step S4: The multi-device collaborative control plan is issued to each device in the form of a capability token, which contains a device capability signature, an execution time period label, and a revocable condition marker. Each device only performs verification when the token is valid.

[0078] The specific steps of step S4 are as follows: Step S401: Based on the multi-level multi-device collaborative control plan, a capability token is generated for each task fragment, which is composed of a device capability signature, an execution time period label, and a revocable condition marker.

[0079] In this embodiment, for each task fragment, its corresponding device capability information is extracted, and a device capability signature is generated by hashing or unique coding, which is used to verify the legality of the token source in the execution phase. Then, according to the time sequence allocation result of the task fragment in the control plan, an execution time period label is generated, so that the token can be called in the correct time window. Finally, a revocable condition marker is embedded in the token, which is used to define whether the task is allowed to be revoked and the trigger boundary of the revocation under abnormal conditions. Through the combination of the three elements, each task fragment is encapsulated as a capability token with identity verification, time sequence constraint, and controllability boundary.

[0080] Step S402: In the generated capability token, a one-time random sequence is embedded as a token identification factor, and the identification factor is bound to the task fragment index.

[0081] In the token generation phase, the random number engine generates a random sequence valid only in the current task cycle and embeds it into the data structure of the token as an identification factor; the identification factor is called in the subsequent verification process to determine whether the token is in a legal state, avoiding confusion caused by token reuse between different task segments.

[0082] Step S403: distribute the capability token to the corresponding device, and each device calls and verifies the identification factor and the capability signature in the locally stored token pool.

[0083] Step S404: for the capability token that passes the verification, trigger the device to execute the corresponding task segment, and automatically destroy the capability token after the execution is completed.

[0084] Embodiment 2 Please refer to Figure 3 Another embodiment provided by the application: a multi-device collaborative control system, comprising: a graph construction module, a timing alignment module, a control plan generation module, and a delivery and execution module; The graph construction module is configured to collect the capability parameters and state information of each device and construct a device capability graph, wherein the device capability graph comprises mutual exclusion relationships and dependency relationships between devices. The timing alignment module performs timing alignment of each device without a global clock based on a reference signal and an event causal chain, and generates a logical time sequence across devices. The control plan generation module generates a multi-device collaborative control plan based on the device capability graph and the logical time sequence, wherein the multi-device collaborative control plan takes a task segment as a basic unit and configures a dynamic priority identifier for each task segment. The delivery and execution module is configured to deliver the multi-device collaborative control plan to each device in the form of a capability token, wherein the capability token comprises a device capability signature, an execution time period label, and a revocable condition marker, and each device performs execution only when the token is verified to be valid.

[0085] The control plan generation module comprises: a task segment generation unit, a priority identifier allocation unit, and a control plan generation unit. The task segment generation unit is configured to match each device capability with a task demand to form a candidate task mapping set, and perform graph partitioning processing on the candidate task mapping set to generate a task segment set. The priority identifier allocation unit is configured to allocate a dynamic priority identifier to each task segment. The control plan generation unit is configured to rearrange the task segments in the task segment set in a time sequence manner to form a multi-level multi-device collaborative control plan.

[0086] In addition, parts of the above technical solutions provided in the embodiments of the present application that are consistent with the implementation principles of corresponding technical solutions in the prior art are not described in detail to avoid excessive repetition.

[0087] The specific embodiments described above are further explained in connection with the purposes, technical solutions, and beneficial effects of the present application. It should be understood that the above description is only a specific embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A method of multi-device cooperative control, the method comprising: The method comprises the following steps: Collecting capability parameters and state information of each device, and constructing a device capability map, wherein the device capability map comprises mutual exclusion relationships and dependency relationships between devices; Performing timing alignment of each device without a global clock based on reference signals and event causal chains, and generating a logical time sequence across devices; Generating a multi-device collaborative control plan based on the device capability map and the logical time sequence, wherein the multi-device collaborative control plan takes a task segment as a basic unit, and a dynamic priority identifier is configured for each task segment; The multi-device collaborative control plan is issued to each device in the form of a capability token, wherein the capability token comprises a device capability signature, an execution time period label, and a revocable condition marker, and each device performs execution only when the token is verified to be valid.

2. The method of claim 1, wherein, The collecting of capability parameters and state information of each device, and the construction of a device capability map, comprises: Collecting capability parameters and state information of each device, and mapping the capability parameters and state information into capability vectors; Based on the capability vectors, constructing capability units of each device, and generating a capability boundary point set through random disturbance; Embedding the capability boundary point set into a graph structure to generate a multi-level association graph between devices, wherein each level corresponds to a different type of constraint relationship; Based on the multi-level association graph between devices, introducing a self-generated label to generate a unique semantic label for each device node, and obtaining a device capability map.

3. The method of claim 2, wherein, The timing alignment of each device without a global clock based on reference signals and event causal chains, and the generation of a logical time sequence across devices, comprises: A reference device periodically sends a synchronization trigger signal, and each device locally records an initial event timestamp at the trigger moment; Each device annotates the local generated operation events with causal relationships to obtain a local event sequence; The local event sequence is extended to a logical event chain through cross-event comparison, wherein the logical event chain is arranged in a causal priority order; Based on the logical event chain, a virtual level index is assigned to each logical event, and the virtual level index is used as a logical time sequence across devices.

4. The method of claim 3, wherein, The generation of a multi-device collaborative control plan based on the device capability map and the logical time sequence, comprises: Based on the device capability map and the logical time sequence, matching each device capability with task requirements to form a candidate task mapping set; Performing graph partitioning processing on the candidate task mapping set to generate a task segment set, wherein each task segment is limited to a single execution path and records a trigger condition; Based on the task segment set, a dynamic priority identifier is assigned to each task segment, and the priority identifier is updated during the planning stage according to the device state or task progress; The task segments in the task segment set are rearranged in a time sequence to form a multi-level multi-device collaborative control plan, wherein each level corresponds to a collaborative combination of a type of task segment; Based on the multi-level multi-device collaborative control plan, parallel placeholders are established for task segments at different levels, and the placeholders remain in an unbound state before actual issuance.

5. The method of claim 4, wherein, The assigning of a dynamic priority identifier to each task segment based on the task segment set, comprises: generating a candidate weight set for the task segment set, the candidate weight set being formed by a combination of trigger conditions, multi-device correlation degrees, and resource consumption factors of the task segments; comparing the weight relationships between different task segments through cross iteration based on the candidate weight set, and recording priority transition points; arranging the priority transition points into a hierarchical sequence to form a multi-level priority structure; setting a priority update mechanism based on the multi-level priority structure to trigger the migration of task segments between different levels according to the device state changes in the planning stage.

6. The method of claim 5, wherein, rearranging the task segments in the task segment set in a time sequence to form a multi-level multi-device collaborative control plan, wherein each level corresponds to a collaborative combination of a type of task segments, including: matching the multi-level priority structure with the task segment set, preliminarily dividing time segment windows, and distributing the task segments into the corresponding time segment windows; sequentially sorting the task segments according to the trigger conditions in the divided time segment windows to form a basic time sequence; extracting the task segments with correlation into the same control layer through multi-level extraction of the basic time sequence to generate a dual structure of intra-level sequences and inter-level sequences; inserting mutual exclusion markers and dependency markers between different control layers based on the dual structure to form a multi-level multi-device collaborative control plan.

7. The method of claim 6, wherein, inserting mutual exclusion markers and dependency markers between different control layers based on the dual structure to form a multi-level multi-device collaborative control plan, including: cross-scanning the intra-level sequences and inter-level sequences to identify pairs of task segments with conflict or dependency relationships; generating mutual exclusion candidate sets and dependency candidate sets between the identified pairs of task segments, and assigning unique logical markers to each candidate set; inserting the logical markers into the dual structure to bind the logical markers with the corresponding task segments, and forming a cross-level marker chain; based on the marker chain, rearranging the order of task segments between control layers to generate a multi-level multi-device collaborative control plan.

8. The method of claim 7, wherein, issuing the multi-device collaborative control plan to each device in the form of a capability token, including: generating a capability token for each task segment based on the multi-level multi-device collaborative control plan, the capability token being composed of a combination of device capability signatures, execution period labels, and revocable condition markers; embedding a one-time random sequence as a token identification factor in the generated capability token, and binding the identification factor with the task segment index; distributing the capability token to the corresponding device, and each device calling and verifying the identification factor and the capability signature in the locally stored token pool; triggering the device to execute the corresponding task segment for the capability token that passes the verification, and automatically destroying the capability token after the execution is completed.

9. A multi-device cooperative control system for implementing a multi-device cooperative control method according to any one of claims 1-8, characterized by including: a graph construction module, a time sequence alignment module, a control plan generation module, and an issuance and execution module; the graph construction module is configured to collect capability parameters and state information of each device, and construct a device capability graph, the device capability graph including mutual exclusion relationships and dependency relationships between devices; the time sequence alignment module is configured to match the device capability graph with a task segment set, preliminarily divide time segment windows, and distribute the task segments into the corresponding time segment windows; the control plan generation module is configured to sequentially sort the task segments according to the trigger conditions in the divided time segment windows to form a basic time sequence, extract the task segments with correlation into the same control layer through multi-level extraction of the basic time sequence to generate a dual structure of intra-level sequences and inter-level sequences, and insert mutual exclusion markers and dependency markers between different control layers based on the dual structure to form a multi-level multi-device collaborative control plan; the issuance and execution module is configured to generate a capability token for each task segment based on the multi-level multi-device collaborative control plan, the capability token being composed of a combination of device capability signatures, execution period labels, and revocable condition markers, embed a one-time random sequence as a token identification factor in the generated capability token, and bind the identification factor with the task segment index, distribute the capability token to the corresponding device, each device calling and verifying the identification factor and the capability signature in the locally stored token pool, trigger the device to execute the corresponding task segment for the capability token that passes the verification, and automatically destroy the capability token after the execution is completed. The time alignment module performs time alignment without a global clock for each device based on a reference signal and an event causal chain, and generates a logical time sequence across devices; The control plan generation module generates a multi-device collaborative control plan based on a device capability map and the logical time sequence, the multi-device collaborative control plan taking a task fragment as a basic unit and configuring a dynamic priority identifier for each task fragment; The execution module is configured to issue the multi-device collaborative control plan to each device in the form of a capability token, the capability token including a device capability signature, an execution time period label, and a revocable condition label, and each device performs execution only when the token is verified to be valid.

10. A multiple device cooperative control system as in claim 9, wherein, The control plan generation module includes a task fragment generation unit, a priority identifier allocation unit, and a control plan generation unit. The task fragment generation unit is configured to match each device capability with a task demand to form a candidate task mapping set, perform graph partitioning processing on the candidate task mapping set, and generate a task fragment set; The priority identifier allocation unit is configured to allocate a dynamic priority identifier to each task fragment; The control plan generation unit is configured to rearrange the task fragments in the task fragment set in a time sequence manner to form a multi-level multi-device collaborative control plan.

Images