A multi-device cooperative control method and system

Abstract

The application discloses a kind of multi-device cooperative control method and system, belong to equipment cooperative control technical field, its method specifically includes: the ability parameter and state information of each device are collected, and device capability atlas is constructed, each device is carried out without global clock timing alignment based on reference signal and event causal chain, and the logical time sequence of cross-device is generated, and the multi-device cooperative control plan is generated based on device capability atlas and logical time sequence, the multi-device cooperative control plan is with task fragment as basic unit, and each task fragment is configured dynamic priority identifier, and the multi-device cooperative control plan is issued to each device in the form of ability token, the ability token includes device capability signature, execution time period label and revocable condition mark, each device is only executed when verifying token is valid;The application realizes the automation cooperative control of multiple reliability test equipment, improves the parallelism and scheduling flexibility of complex experiment process.

Description

TECHNICAL FIELD

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

[0002] After being manufactured, semiconductor devices need to undergo a series of reliability verifications to evaluate their failure modes and life characteristics under different working conditions. Common reliability tests include high-temperature working life, temperature cycling, high-accelerated stress testing, electromigration testing, electrostatic discharge testing, etc. These tests often need to be run for a long time and are carried out under harsh temperature, humidity, voltage, current, etc.

[0003] In a reliability laboratory, there are various 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 there are large differences in communication protocols, data interfaces and timing logic, which leads to many problems in actual cooperative use.

[0004] In the prior art, some semiconductor reliability test platforms introduce centralized monitoring software, but are often limited to single-manufacturer devices, lack compatibility with heterogeneous devices, and are 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, and 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 application provides a multi-device cooperative control method and system, which can dynamically model heterogeneous devices, align cross-device timing, cooperatively schedule and safely control.

[0006] To achieve the above-mentioned purpose, the application provides the following technical solutions:

[0007] A multi-device cooperative control method, comprising:

[0008] Collecting capability parameters and state information of each device and constructing a device capability graph, wherein the device capability graph comprises mutual exclusion relationships and dependency relationships between devices;

[0009] Aligning the timing of each device based on a reference signal and an event causal chain without a global clock, and generating a cross-device logical time sequence;

[0010] Generating a multi-device cooperative control plan based on the device capability graph and the logical time sequence, wherein the multi-device cooperative control plan takes a task segment as a basic unit, and configures a dynamic priority identifier for each task segment;

[0011] The multi-device collaborative control plan is issued 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 only executes when the token is verified to be valid.

[0012] Specifically, the capability parameters and state information of each device are collected, and a device capability map is constructed, including:

[0013] The capability parameters and state information of each device are collected, and the capability parameters and state information are mapped into a capability vector;

[0014] Based on the capability vector, a capability unit of each device is constructed, and a capability boundary point set is generated by random disturbance;

[0015] The capability boundary point set is embedded in a graph structure to generate a multi-level association graph between devices, wherein each layer corresponds to a different type of constraint relationship;

[0016] Based on the multi-level association graph between devices, a self-generated label is introduced to generate a unique semantic label for each device node, obtaining a device capability map.

[0017] Specifically, the capability parameters and state information of each device are collected, and a device capability map is constructed, including:

[0018] The reference device periodically sends a synchronization trigger signal, and each device locally records the initial event stamp at the trigger instant;

[0019] Each device annotates the local generated operation events with causal relationships to obtain a local event sequence;

[0020] 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;

[0021] 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.

[0022] Specifically, the multi-device collaborative control plan is generated based on the device capability map and the logical time sequence, including:

[0023] Based on the device capability map and the logical time sequence, each device capability is matched with a task demand to form a candidate task mapping set;

[0024] The candidate task mapping set is processed by graph partitioning to generate a task fragment set, each task fragment being limited to a single execution path and recording a trigger condition;

[0025] allocating a dynamic priority identifier to each task segment based on the set of task segments, the priority identifier being updated within the planning phase according to the device state or the task progress;

[0026] rearranging the task segments in the set of task segments 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;

[0027] establishing parallel placeholders for task segments at different levels based on the multi-level multi-device collaborative control plan, the placeholders remaining in an unbound state before actual issuance.

[0028] Specifically, the allocating a dynamic priority identifier to each task segment based on the set of task segments comprises:

[0029] generating a set of candidate weights for the set of task segments, the set of candidate weights being formed by a combination of a trigger condition, a multi-device correlation degree, and a resource consumption factor of a task segment;

[0030] comparing the weight relationship between different task segments in pairs based on the set of candidate weights through cross iteration, and recording priority transition points;

[0031] arranging the priority transition points into a hierarchical sequence to form a multi-level priority structure;

[0032] based on the multi-level priority structure, setting a priority update mechanism to trigger the migration of task segments between different levels according to the change of the device state within the planning phase.

[0033] Specifically, the rearranging the task segments in the set of task segments 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, comprises:

[0034] matching the multi-level priority structure with the set of task segments, initially dividing the time segment window, and allocating the task segments to the corresponding time segment window;

[0035] sequentially sorting the task segments according to the trigger condition in the divided time segment window to form a basic time sequence;

[0036] extracting the basic time sequence in multiple layers to separate task segments with correlation into the same control layer, generating a dual structure of intra-layer sequence and inter-layer sequence;

[0037] based on the dual structure, inserting mutual exclusion markers and dependency markers between different control layers to form a multi-level multi-device collaborative control plan.

[0038] Specifically, based on the double structure, mutual exclusion marks and dependent marks are inserted between different control layers to form a multi-level multi-device collaborative control plan, including:

[0039] The intra-layer sequence and the inter-layer sequence are cross-scanned to identify pairs of task fragments with conflict or dependency relationships;

[0040] Mutual exclusion candidate sets and dependent candidate sets are generated between the identified pairs of task fragments, and each candidate set is assigned a unique logical mark;

[0041] The logical marks are inserted into the double structure to bind the logical marks to the corresponding task fragments and form a cross-level mark chain;

[0042] Based on the mark chain, the order of the task fragments between the control layers is rearranged to generate a multi-level multi-device collaborative control plan.

[0043] Specifically, the multi-device collaborative control plan is issued to each device in the form of a capability token, including:

[0044] 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 period label, and a revocable condition mark;

[0045] 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;

[0046] The capability token is distributed to the corresponding device, and each device calls and verifies the identification factor and the capability signature in the locally stored token pool;

[0047] For the verified capability token, the device triggers the execution of the corresponding task fragment, and automatically destroys the capability token after the execution is completed.

[0048] 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 an execution module;

[0049] 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 includes mutual exclusion relationships and dependency relationships between devices;

[0050] 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 cross-device logical time sequence;

[0051] The control plan generation module generates a multi-device cooperative control plan based on the device capability graph and the logical time sequence, the multi-device cooperative control plan taking a task segment as a basic unit and configuring a dynamic priority identifier for each task segment;

[0052] The execution issuing module issues the multi-device cooperative control plan to each device in the form of a capability token, the capability token containing a device capability signature, an execution time period label and a revocable condition label, and each device only executes when verifying that the token is valid.

[0053] Specifically, the control plan generation module comprises a task segment generation unit, a priority identifier allocation unit and a control plan generation unit.

[0054] The task segment generation unit matches each device capability with a task demand to form a candidate task mapping set, and performs graph partitioning processing on the candidate task mapping set to generate a task segment set.

[0055] The priority identifier allocation unit allocates a dynamic priority identifier to each task segment.

[0056] The control plan generation unit re-arranges the task segments in the task segment set in a time sequence manner to form a multi-level multi-device cooperative control plan.

[0057] Compared with the prior art, the present application has the following advantages:

[0058] The present application provides a multi-device cooperative control method and system, which enables heterogeneous devices to realize dynamic cooperative operation under a unified framework through capability modeling, logical time sequence alignment, task segmenting and tokenization, avoids the traditional mode of relying on a single global clock or fixed priority, and ensures the orderly 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, thereby realizing the automatic cooperative control of multiple reliability test devices, improving the parallelism and scheduling flexibility of complex experimental processes, and maintaining the constraint consistency and operation controllability between devices during operation. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1 A multi-device cooperative control method flowchart is provided in the present application.

[0060] Figure 2 A multi-level multi-device cooperative control plan schematic diagram is provided in the present application.

[0061] Figure 3 A multi-device cooperative control system architecture diagram is provided in the present application. DETAILED DESCRIPTION

[0062] The application will be described in further detail below with reference to specific embodiments. The following examples are helpful for further understanding of the application by those skilled in the art, but do not limit the application in any form. It should be noted that, for those skilled in the art, without departing from the concept of the application, a number of modifications and improvements can be made. These are all within the scope of protection of the application.

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

[0064] It should be noted that, if there is no conflict, each feature in the embodiments of the application can be combined with each other, and all 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.

[0065] Unless otherwise defined, all technical and scientific terms used in the specification are the same as those commonly understood by those skilled in the art to which the application belongs. The terms used in the specification of the application are only for the purpose of describing the specific embodiments and are not used to limit the application. The term "and / or" used in the specification includes any and all combinations of one or more related listed items.

[0066] Embodiment 1

[0067] Please refer to Figure 1 An embodiment provided by the application: a multi-device cooperative control method, comprising the following specific steps:

[0068] Step S1: collecting the capability parameters and state information of each device, and constructing a device capability map, the device capability map containing mutual exclusion relationship and dependency relationship between devices.

[0069] The specific steps of step S1 are:

[0070] Step S101: collecting the capability parameters and state information of each device, and mapping the capability parameters and state information into a capability vector.

[0071] In the embodiment, the capability parameters of the device include dimensional information such as power output range, precision level, interface type, environmental adaptability, and the state information includes dynamic indicators such as current load, occupancy time, temperature state, and interface occupancy; after the collection is completed, the data is 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 to the energy dimension, the interface compatibility is mapped to the interaction dimension, and the occupancy rate and real-time load are mapped to the resource dimension, thereby forming a vector set that can be used for comparison and scheduling in the same vector space; after the mapping process, the originally scattered and not directly comparable capability parameters and state data are converted into capability vectors with mathematical structure.

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

[0073] 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 a unified form of capability unit, and makes it comparable and combinable; in order to avoid that the representation of the capability unit is too idealized, the method of random disturbance is introduced 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 are similar to the actual limit operating 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 track under extreme conditions through the boundary point set.

[0074] 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.

[0075] In the embodiment, the capability boundary points of each device are embedded as nodes in a graph space, and the edge relationship between different nodes is established by similarity or difference calculation; then a direct mapping between devices is formed on the basis layer of the graph, such as power matching relationship, interface compatibility relationship, etc.; then through classification of the edge relationship, a multi-level association graph is gradually generated; in the first layer, the edges between nodes mainly represent physical constraint relationships, such as electrical parameter 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 physical, logical and safety constraints is finally formed.

[0076] Step S104: Based on the multi-level association graph between devices, a self-generated label is introduced, and a unique semantic label is generated for each device node to obtain a device capability graph.

[0077] In the embodiment, by analyzing the connection mode and node characteristics of devices in different constraint layers, these characteristic combinations are mapped as label elements, such as power matching characteristics, interface dependency characteristics, and redundancy fault tolerance characteristics, and a unique label is combined for each device node through a self-generation mechanism. The label has uniqueness; the generation process of the semantic label 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 fuse the power core and trigger source two types of characteristics, and the device capability graph is not only a parameter set or an association graph, but further evolves into a device capability graph.

[0078] Step S2: Based on the reference signal and the event causal chain, the timing of each device is aligned without a global clock, and a cross-device logical time sequence is generated.

[0079] The specific steps of step S2 are:

[0080] Step S201: The reference device periodically issues a synchronization trigger signal, and each device locally records the initial event stamp at the trigger instant.

[0081] In the embodiment, the reference device generates a trigger pulse according to a preset period, and simultaneously broadcasts the pulse signal to multiple devices to be coordinated; each device immediately 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 recording process of the event stamp 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, and finally a set of initial event stamps is obtained.

[0082] Step S202: Each device annotates the local generated operation events with causal relationship, and obtains a local event sequence.

[0083] In this embodiment, each device identifies the trigger conditions between events when collecting operation events, such as that a voltage rising action triggers a current monitoring action, and that a temperature change action precedes a fan start action, and records these dependencies in the form of annotations; the construction process of the local event sequence does not depend on a unified clock, but is sequentially generated by the causal annotations; within one device, different events may exist in concurrent or delayed execution, and these complex relationships are abstracted into computable local sequences by annotating the causal order, and finally the local event sequence is obtained.

[0084] Step S203: The local event sequence is extended into a logical event chain through cross-event comparison.

[0085] In this embodiment, the events in each local event sequence are feature extracted, such as event trigger conditions, resource occupation objects, and state change indications; then the causal coupling points between events of different devices are determined through cross comparison; through this cross matching method, 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 physical time sequence, but on causal priority to determine the order; if there is an explicit trigger relationship between two events, they are arranged in sequence; if two events are parallel or independent of each other, 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 one logical framework, and finally the logical event chain is obtained.

[0086] Step S204: 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.

[0087] In this embodiment, according to the explicit before-after 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 unified level index number is assigned to the events in each level, and a cross-device identifier is embedded in the index; each logical event is assigned a markable hierarchical number; the virtual level index does not depend on the physical time or the local clock of the device, but serves as a unified alignment reference across devices; for example, when a temperature regulation event and a voltage loading event are annotated as the same level index, they will be considered as parallel tasks in the cross-device plan; when a data acquisition event is annotated as a higher level index than a power-on event, the collaborative plan will logically force the order, and finally a logical time sequence across devices is obtained.

[0088] Step S3: generating a multi-device collaborative control plan based on the device capability graph 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.

[0089] The specific steps of step S3 are as follows:

[0090] Step S301: matching each device capability with a task demand based on the device capability graph and the logical time sequence to form a candidate task mapping set.

[0091] In this embodiment, the task demand is parsed and decomposed into constraint units such as a power interval, an interface form, an execution time limit, a concurrency condition, etc.; then the nodes in the device capability graph are searched, and a device set capable of meeting the task constraint units is identified according to the semantic label and the capability vector feature; on this basis, the devices with the capability condition are aligned with the corresponding task nodes in combination with the 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 by multiple low-power devices in parallel; a certain data acquisition task can be bound to a high-speed interface device or to a low-speed device but with a prolonged time sequence; in this way, the task demand is expanded and mapped to multiple device combinations to form the candidate task mapping set.

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

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

[0094] Step S303: assigning a dynamic priority identifier to each task fragment based on the task fragment set, the priority identifier being updated within the planning stage according to the device state or the task progress.

[0095] The specific steps of step S303 are:

[0096] Step S3031: generating a candidate weight set for the task fragment set, the candidate weight set being formed by the combination of trigger conditions, multi-device correlation degree, and resource consumption factor of the task fragments.

[0097] In this embodiment, the trigger condition of each task fragment is analyzed and converted into measurable elements such as time sensitivity and logical dependency degree; secondly, the correlation degree of the task fragments among devices is identified, such as 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 resource consumption factor during the execution of the task fragments is combined, including power occupation, interface bandwidth occupation, and running time consumption, and the three types of parameters are combined to generate a comprehensive candidate weight set.

[0098] Step S3032: based on the candidate weight set, the weight relationship between different task fragments is compared two by two through cross iteration, and the priority conversion point is recorded.

[0099] In this embodiment, the task fragments are combined in pairs, and each time comparison does not rely on a single index, but switches the evaluation dimension among the trigger condition sensitivity, device correlation degree, and resource consumption factor three types of parameters in turn; in each iteration, by comparing the weight of two task fragments in a certain dimension, the relative priority order of the task fragments in the dimension is determined, and the comparison result is stored in the priority relationship table, after multiple rounds of cross iteration, a set of priority order relationship covering all task fragments is gradually formed; in the process of cross iteration, some task fragments show opposite priority order in different dimensions, for example, they are prior in trigger condition but lag in resource consumption, such cases are expressed by recording the priority conversion point, that is, the critical position where the priority of the fragments switches is marked in the comparison result; the priority conversion point makes the subsequent multi-level priority structure more accurately reflect the dynamic ordering characteristics of the task fragments under different conditions; finally, a dynamic sequence containing conversion information is obtained.

[0100] Step S3033: arranging the priority conversion points into a hierarchical sequence to form a multi-level priority structure.

[0101] In the embodiment, all priority conversion points are sorted according to their appearance order and corresponding task fragments, and the conversion points are sequentially arranged to form an ordered sequence; then, the task fragments are divided into different levels according to the stable interval between adjacent conversion points with reference to the sequence; the task fragments contained in each level maintain a relatively stable priority relationship in the interval, and the different levels are connected through the conversion points to form a hierarchical priority framework structure.

[0102] 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 changes in the planning stage.

[0103] In the embodiment, a set of trigger conditions is preset for each level, which is composed of device operating state parameters such as power load rate, temperature stability, interface occupancy, etc. When the device state changes, the scheduling module compares the task fragments in the current level one by one according to the condition set, and if the execution condition of a certain fragment no longer meets the constraints of the original level, it is marked as a migration object; after the migration object is marked, the target level is found in the priority structure according to the latest state attribute of the fragment, and the fragment 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 a transition level for subsequent adjustment.

[0104] Step S304: 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 level corresponds to a collaborative combination of a type of task fragments.

[0105] The specific steps of step S304 are:

[0106] Step S3041: The multi-level priority structure is matched with the task fragment set, the time fragment window is preliminarily divided, and the task fragments are assigned to the corresponding time fragment window.

[0107] In the embodiment, according to the priority level, each fragment in the task fragment 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 carrying interval for a group of task fragments, and 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 fragment is no longer an abstract execution unit, but is placed in a specific time window to form a preliminary scheduling arrangement.

[0108] It should be noted that the division of the time segment window is not only cutting according to the order, but also taking the priority structure as a guide; for example, the task segment located at a higher level is preferentially placed in the pre-window, and the tasks with parallel characteristics in the same level can be allocated to the same window to realize parallel scheduling; for the task segments with cross-level dependencies, a sequence constraint chain is established between the windows; finally, a set of time segment windows with hierarchical logic is obtained, each window contains a plurality of task segments, and the distribution of these segments has initially met the priority and dependency conditions.

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

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

[0111] 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.

[0112] In this embodiment, the correlation characteristics between the task segments in the basic time sequence are analyzed, including resource sharing relationship, trigger dependency relationship, and execution result transmission relationship; then, according to these 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 cross-layer dependency relationship, and finally the inter-layer sequence is formed, and the originally 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 for another layer segment, a sequence constraint is established between layers.

[0113] Step S3044: 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.

[0114] In the embodiment, pairs of task segments that exist conflict between different control layers are identified, such as tasks that share the same power channel or occupy the same test interface; for such task segments, mutual exclusion marks are inserted in the inter-layer relationship, so that they cannot be executed simultaneously in the scheduling process; then, the front-back dependency chain between layers is analyzed, such as a data acquisition task of a control layer needs to be completed on the premise that the stress loading task of the previous layer is completed, and a dependency mark is inserted at the corresponding position, thereby fixing the execution sequence;

[0115] The specific steps of step S3044 are:

[0116] Step S30441: cross-scan the intra-layer sequence and the inter-layer sequence to identify pairs of task segments that exist conflict or dependency relationship.

[0117] In the embodiment, the intra-layer sequence is compared pair by pair to detect whether there is resource occupation overlap, execution condition mutual exclusion or shared interface cannot be called simultaneously; if such contradictions are detected, the task segment pairs are marked as conflict pairs; then in the inter-layer sequence, based on the logical chain between the front and back layers, the task segments are compared one by one to identify the segments that must depend on the previous results to trigger, and bind them to the previous segments as dependency pairs; it should be noted that the cross-scan process is not only a static matching, but also a dynamic judgment combined with the trigger condition, execution period and device capability label of the task segment; for example, although two task segments belong to different intra-layer sequences, if the device capability units they call exist intersection, they will still be identified as conflict pairs in the scan; for example, the trigger condition of a task segment contains the requirement of completing data acquisition as a prerequisite, which will be automatically marked as a dependency pair when scanning the inter-layer sequence; finally, a set of classified and sorted conflict segment pairs and dependency segment pairs are obtained.

[0118] Step S30442: generate mutual exclusion candidate set and dependency candidate set between the identified task segment pairs, and assign a unique logical mark to each candidate set.

[0119] In the embodiment, all conflict segment 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, dependency segment pairs that exist front-back trigger logic chain are classified into a dependency candidate set, in this way, the dispersed conflict and dependency relationship is structured and integrated into a limited number of candidate sets, each candidate set represents a specific logical constraint pattern; each candidate set will be assigned a unique logical mark when generated, which not only serves as an identifier for the set, but also carries information about the constraint type and scope; for example, the logical mark of a mutual exclusion candidate set contains the resource occupation type and the corresponding device label, and the logical mark of a dependency candidate set contains the sequence number and trigger condition of the front and back events.

[0120] Step S30443: Insert the logical markers into the dual structure, bind the logical markers with the corresponding task fragments, and form the cross-level marker chain.

[0121] In this 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 markers are directly inserted into the positions, and are combined with the trigger conditions and the execution path information of the task fragments; then, according to the front-back connection order of the task fragments in the dual structure, the multiple logical markers are sequentially connected to form the marker chain covering different levels.

[0122] Step S30444: Based on the marker chain, the order of the task fragments between the control layers is rearranged to generate the multi-level multi-device collaborative control plan.

[0123] In this embodiment, the marker chain generated in the previous step is used to rearrange the control layer relationship in the original dual structure, and the global logical consistency of the multi-device tasks is realized; specifically, first, the positions of the exclusion markers and the dependency markers in the marker chain are used to compare and adjust the order of the task fragments between the layers; if two task fragments cannot be parallel due to the exclusion markers, they are re-assigned to different time windows or different control layers; if two task fragments have a front-back connection relationship due to the dependency markers, a fixed order link is established in the structure; through this rearrangement process, the originally relatively independent intra-layer sequence and inter-layer sequence are recombined in the global range to evolve into a multi-level collaborative control framework.

[0124] It should be noted that the rearrangement is not only adjusting the task positions, but also systematically adjusting the hierarchical structure of the control layers in combination with the global coverage range of the marker chain; for example, when a marker 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 level attribution in the new structure; the final multi-level multi-device collaborative control plan not only retains the parallel characteristics of the intra-layer, but also guarantees the logical consistency through the cross-layer rearrangement.

[0125] As shown in Figure 2 , the multi-level multi-device collaborative control plan is composed of multiple control layers, each control layer is used to carry a specific category of task fragments, and is logically constrained by the expression of the dependency markers, the exclusion markers, and the parallel placeholders.

[0126] In Figure 2In the control layer L1, the task segment T1 and the task segment T2 are connected by a dependency mark, indicating that the triggering of the task segment T2 must be based on the completion of the execution of the task segment T1. Figure 2 In the control layer L2, the task segment T3 and the task segment T4 are connected by a mutual exclusion mark, such as the mutual exclusion mark x in the control layer L2, indicating that the two cannot be executed in parallel in the scheduling process and one of them needs to be selected for execution according to the device state and planning rules. Figure 2 In the control layer L3, the task segment T5 and the task segment T6 are connected by a dependency mark, indicating that the execution of the task segment T6 needs to be triggered after the completion of the task segment T5.

[0127] In addition to the above hierarchical structure, Figure 2 an independent task sequence Tj is also shown, which includes the task segment T8 and the task segment T7, which are sequentially arranged in a dependency relationship and are 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.

[0128] After the task segment relationship is established, the control layers and the independent sequence are allocated time segments by a unified scheduling time module and globally scheduled; the scheduling result is then mapped to specific physical devices, including the device D1, the device D2, the device D3, and the device D4. In this way, the originally dispersed task segments are uniformly arranged under the multi-level structure and are mapped to specific devices through the control of the scheduling time to form an executable collaborative control plan.

[0129] Step S305: Based on the multi-level multi-device collaborative control plan, a parallel placeholder is established for the task segments of different levels, and the placeholder remains in an unbound state before actual delivery.

[0130] Step S4: The multi-device collaborative control plan is delivered to each device in the form of a capability token, which includes a device capability signature, an execution time period label, and a revocable condition mark. Each device only performs execution when the token is verified to be valid.

[0131] The specific steps of step S4 are as follows:

[0132] Step S401: Based on the multi-level multi-device collaborative control plan, a capability token is generated for each task segment, which is composed of a device capability signature, an execution time period label, and a revocable condition mark.

[0133] In the 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 stage; 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 label is embedded in the token, which is used to define whether the task is allowed to be revoked and the trigger boundary of revocation under abnormal conditions; through the combination of the three types of elements, each task fragment is encapsulated as a capability token with identity verification, time sequence constraint and controllability boundary.

[0134] 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 with the task fragment index.

[0135] In the embodiment, in the token generation stage, the random number engine generates a random sequence valid only in the current task period, 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 between different task fragments due to token reuse.

[0136] Step S403: Distribute the capability token to the corresponding device, and call and verify the identification factor and the capability signature in the locally stored token pool of each device.

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

[0138] Embodiment 2

[0139] Please refer to Figure 3 Another embodiment provided by the application: a multi-device cooperative control system, comprising: a graph construction module, a time sequence alignment module, a control plan generation module and a delivery and execution module;

[0140] The graph construction module is used to collect the capability parameters and state information of each device, and construct a device capability graph, wherein the device capability graph contains the mutual exclusion relationship and the dependency relationship between devices;

[0141] The time sequence alignment module performs time sequence 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;

[0142] The control plan generation module generates a multi-device cooperative control plan based on the device capability graph and the logical time sequence, wherein the multi-device cooperative control plan takes a task fragment as a basic unit, and configures a dynamic priority identifier for each task fragment;

[0143] The execution issuing module is configured to issue the multi-device cooperative control plan to each device in the form of a capability token, and the capability token comprises a device capability signature, an execution time period label, and a revocable condition label. Each device only executes when the token is verified to be valid.

[0144] The control plan generation module comprises a task segment generation unit, a priority identification allocation unit, and a control plan generation unit.

[0145] 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.

[0146] The priority identification allocation unit is configured to allocate a dynamic priority identification to each task segment.

[0147] The control plan generation unit is configured to rearrange the task segments in the task segment set in a time sequence to form a multi-layer multi-device cooperative control plan.

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

[0149] The specific embodiments described above further detail 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 principles of the present application should 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