Code generation method, device, medium and product based on multiprocessor control system

Abstract

The embodiment of the application discloses a code generation method, device, medium and product based on a multi-processor control system; the method comprises the following steps: obtaining model configuration, interface configuration, constraint configuration and verification rules of a to-be-processed control system; generating a task graph according to the model configuration, generating a message flow graph according to the interface configuration, and generating a processor capability table, a bus scheduling table and a synchronization point set according to the constraint configuration; constructing the task graph, the message flow graph, the processor capability table, the bus scheduling table and the synchronization point set into a unified processing object, and the unified processing object is used to represent the associated constraints between tasks, messages, processor resources, bus resources and synchronization points; performing task segmentation, load estimation, mapping solution and interface arrangement based on the unified processing object, and determining a task mapping relationship and an interface scheduling relationship; and generating synchronization code according to the task mapping relationship, the interface scheduling relationship, the synchronization point set and the verification rules.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a code generation method, device, medium and product based on a multiprocessor control system. Background Technology

[0002] In control systems such as avionics control, satellite control, ship control, and industrial control, the control model typically includes multiple functional tasks with different periods, execution time limits, and safety levels. As the complexity of control systems increases, a single processor can hardly meet the requirements of computing power, storage, isolation, and real-time performance simultaneously. Therefore, it is necessary to deploy control tasks across multiple processors to run collaboratively.

[0003] In multiprocessor control systems, the task connections in the model translate into cross-processor message transmission, bus resource usage, and synchronization consistency requirements after deployment. If task mapping, interface scheduling, and synchronization code generation are handled by different stages, situations may arise where task placement meets processor load requirements but message transmission does not meet bus time slot requirements, or interface scheduling meets communication requirements but synchronization code fails to meet consistency constraints.

[0004] Furthermore, task graphs, message flow graphs, processor capability information, bus scheduling information, and synchronization point information are typically maintained by different configurations or tools. When there is a lack of a unified expression of the association constraints between different objects, task splitting, load estimation, mapping solution, interface orchestration, and synchronization code generation are difficult to execute in conjunction on the same processing object, and it is also not conducive to subsequent synchronous verification of the generated results.

[0005] Therefore, a code generation scheme for multiprocessor control systems is needed, which enables tasks, messages, processor resources, bus resources, and synchronization points to collaboratively participate in task mapping, interface scheduling, and synchronous code generation under a unified processing object. Summary of the Invention

[0006] One objective of this application is to provide a code generation method, device, medium, and product based on a multiprocessor control system, at least to solve the problem of difficulty in coordinating task mapping, interface scheduling, and synchronous code generation in the prior art for multiprocessor control systems.

[0007] To achieve the above objectives, some embodiments of this application provide the following aspects:

[0008] In a first aspect, some embodiments of this application provide a code generation method based on a multiprocessor control system, the method comprising:

[0009] Obtain the model configuration, interface configuration, constraint configuration, and verification rules of the control system to be processed;

[0010] A task graph is generated based on the model configuration, a message flow graph is generated based on the interface configuration, and a processor capability table, a bus scheduling table, and a set of synchronization points are generated based on the constraint configuration.

[0011] The task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set are constructed into a unified processing object, which is used to represent the association constraints between tasks, messages, processor resources, bus resources, and synchronization points.

[0012] Based on the unified processing object, task segmentation, load estimation, mapping solution and interface orchestration are performed to determine task mapping relationships and interface scheduling relationships;

[0013] Synchronization code is generated based on the task mapping relationship, interface scheduling relationship, synchronization point set, and verification rules.

[0014] Secondly, some embodiments of this application also provide an electronic device, the electronic device comprising: one or more processors; and a memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method described above.

[0015] Thirdly, some embodiments of this application also provide a computer-readable medium having computer program instructions stored thereon, which can be executed by a processor to implement the method described above.

[0016] Fourthly, some embodiments of this application also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0017] Compared with related technologies, the solution provided in this application generates task graphs, message flow graphs, processor capability tables, bus scheduling tables, and synchronization point sets based on model configuration, interface configuration, and constraint configuration, respectively, and constructs these objects into a unified processing object. This allows the associated constraints between tasks, messages, processor resources, bus resources, and synchronization points to be expressed on the same processing basis. By performing task splitting, load estimation, mapping solution, and interface orchestration on the unified processing object, task mapping relationships and interface scheduling relationships can be determined collaboratively. By combining task mapping relationships, interface scheduling relationships, synchronization point sets, and verification rules to generate synchronization code, the consistency between task deployment, interface scheduling, and synchronization implementation in a multiprocessor control system can be improved. Attached Figure Description

[0018] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0019] Figure 1 An exemplary flowchart of a code generation method based on a multiprocessor control system provided for some embodiments of this application;

[0020] Figure 2 An exemplary flowchart of another code generation method based on a multiprocessor control system provided in some embodiments of this application;

[0021] Figure 3 An exemplary structural diagram of the electronic device provided for some embodiments of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] Figure 1 The flowchart illustrates an exemplary code generation method for a multiprocessor control system, provided for some embodiments of this application. This method can be executed by a code generation tool, a model-driven development platform, a control system deployment tool, or a processing module within an integrated development environment. The multiprocessor control system can be an avionics control system, a satellite control system, a ship control system, an industrial control system, or other control systems that require deploying multiple control tasks to multiple processors and communicating collaboratively via a bus or interface.

[0024] S101. Obtain the model configuration, interface configuration, constraint configuration, and verification rules of the control system to be processed.

[0025] Specifically, model configuration can be used to describe information such as model hierarchy, functional modules, scheduling cycle, task input / output relationships, and task safety levels in the control system to be processed. Interface configuration can be used to describe information such as message transmission relationships between tasks, interface connection relationships, message size, communication frequency, triggering methods, and tolerable latency. Constraint configuration can be used to describe information such as processor resources, bus resources, processor load limits, task deadlines, safety level isolation requirements, and synchronization point requirements. Verification rules can be used to describe the data consistency, read / write order, transmission timing, or synchronization constraints that need to be met when generating synchronization code.

[0026] In one embodiment, model configuration, interface configuration, constraint configuration, and verification rules can come from the same project file, or they can come from the model design tool, interface management tool, hardware resource configuration file, and verification rule library, respectively. After reading the above configuration, the code generation tool can format the task names, interface names, resource names, and synchronization point names in the configuration, so that the subsequently generated tasks, messages, processor resources, bus resources, and synchronization points can be uniformly referenced.

[0027] S102. Generate a task graph according to the model configuration, generate a message flow graph according to the interface configuration, and generate a processor capability table, a bus scheduling table, and a synchronization point set according to the constraint configuration.

[0028] Specifically, the task graph represents the task nodes in the control system and the execution or data dependencies between them. The message flow graph represents the message edges between tasks and the corresponding communication directions, message characteristics, and interface requirements. The processor capability table represents the resource conditions of each processor, such as computing power, storage capacity, available time windows, or security domains. The bus scheduling table represents information such as the channels, time slots, bandwidth, or occupancy status of bus resources. The synchronization point set represents the locations where data synchronization or state consistency control is required.

[0029] In one embodiment, if there are multiple control function modules in the model configuration, multiple task nodes can be generated according to the scheduling cycle and input / output boundaries of the function modules; if there is an interface relationship in the interface configuration where one task sends data to another task, a message edge pointing from the source task to the destination task can be generated; if the constraint configuration includes processor resources and bus resources, a processor capability table and a bus scheduling table can be formed respectively; if the constraint configuration includes cross-processor read / write, shared state, or periodic key variables, corresponding synchronization points can be generated.

[0030] S103. The task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set are constructed into a unified processing object, which is used to represent the association constraints between tasks, messages, processor resources, bus resources, and synchronization points.

[0031] Specifically, the unified processing object can serve as a common processing foundation for subsequent task splitting, load estimation, mapping solution, interface orchestration, and synchronization code generation. Through the unified processing object, task nodes no longer exist merely as functional blocks in the model, and message edges no longer exist merely as interface descriptions, but instead establish computable associations with processor resources, bus resources, and synchronization points.

[0032] In one embodiment, the unified processing object can record data dependencies between task nodes and message edges, deployment candidate relationships between task nodes and processor resources, transmission candidate relationships between message edges and bus resources, and consistency constraints between synchronization points and related tasks. This allows the unified processing object to be used to determine the affected tasks, messages, and synchronization points when task endpoints, interface channels, or synchronization methods change, eliminating the need to search through multiple tools or configuration tables.

[0033] S104. Based on the unified processing object, perform task splitting, load estimation, mapping solution and interface orchestration to determine task mapping relationship and interface scheduling relationship.

[0034] Specifically, task partitioning can divide the control model into tasks suitable for deployment and scheduling based on factors such as model hierarchy, scheduling cycle, input / output boundaries, and security level. Load estimation can be used to assess the task's occupancy of processor execution time, storage resources, and interface bandwidth. Mapping solution can allocate tasks to corresponding processors based on the load estimation results and processor capabilities. Interface orchestration can determine the interface channels, bus resources, or transmission timing required for cross-processor messages based on task mapping relationships and message flow graphs.

[0035] In one embodiment, if two tasks are mapped to the same processor, their messages can be arranged according to the processor's internal communication method; if two tasks are mapped to different processors, the corresponding messages need to be determined by combining the bus scheduling table to determine the interface channel and transmission time slot. If a mapping result leads to an increase in the number of cross-processor messages, insufficient bus time slots, or failure to meet task deadlines, the task mapping relationship or interface scheduling relationship can be readjusted to ensure that task deployment and interface communication are determined collaboratively.

[0036] S105. Generate synchronization code based on the task mapping relationship, interface scheduling relationship, synchronization point set, and verification rules.

[0037] Specifically, after determining the task mapping and interface scheduling relationships, the set of synchronization points can be used to determine which messages, shared states, or inter-task data require the generation of synchronization code. Synchronization code can be used to implement cross-processor message passing, shared data access, periodic variable updates, or data caching in cases of inconsistent rates. Verification rules can be used to determine the read / write order, commit conditions, cache usage conditions, or consistency constraints that synchronization code must satisfy.

[0038] In one embodiment, for messages where the source and destination tasks reside on different processors, the sending-side code, receiving-side code, and necessary synchronization control code can be determined based on the interface scheduling relationship. For tasks involving shared state, corresponding data access control code can be generated based on the synchronization point set. For messages with periodic or timing constraints, synchronization code that satisfies the corresponding synchronization constraints can be generated by combining verification rules. Thus, the generated synchronization code can maintain consistency with the task mapping relationship and the interface scheduling relationship.

[0039] Furthermore, in one embodiment, the synchronization code can be generated by a synchronization generation module according to preset synchronization code generation rules. Specifically, the synchronization generation module can pre-maintain synchronization code templates or code generation rules corresponding to different synchronization implementation methods, including at least one of double-buffered synchronization, shared memory synchronization, message queue synchronization, and buffer synchronization. After determining the synchronization implementation method corresponding to the target message, the synchronization generation module can obtain the source task, destination task, source processor, and destination processor from the task mapping relationship, the interface channel, bus time slot, send offset, and receive offset from the interface scheduling relationship, and the synchronization variables, consistency requirements, and synchronization constraints from the synchronization point set and verification rules; then, it uses the above information as template parameters or generation parameters to generate the sending-side synchronization code, the receiving-side synchronization code, and the corresponding synchronization control code.

[0040] In this embodiment, by first generating a task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set based on model configuration, interface configuration, and constraint configuration, and then constructing the above objects into a unified processing object, tasks, messages, processor resources, bus resources, and synchronization points can participate in code generation on the same processing basis. By collaboratively executing task splitting, load estimation, mapping solution, and interface orchestration on the unified processing object, task mapping relationships and interface scheduling relationships can be mutually adapted. By combining task mapping relationships, interface scheduling relationships, synchronization point set, and verification rules to generate synchronization code, inconsistencies between task deployment, interface communication, and synchronization implementation in a multiprocessor control system can be reduced.

[0041] Furthermore, in one embodiment, generating a task graph based on the model configuration, generating a message flow graph based on the interface configuration, and generating a processor capability table, a bus scheduling table, and a synchronization point set based on the constraint configuration specifically includes:

[0042] A task graph is generated based on the model hierarchy, functional modules, scheduling cycle, input / output ports, security level, and deadline in the model configuration. The task graph can include multiple task nodes and dependency edges between them. Task nodes can correspond to functional modules, sub-models, scheduling units, or code generation units in the control model. Attributes of task nodes can include task identifier, model origin, scheduling cycle, worst-case execution time, input / output ports, security level, and deadline. Dependency edges between task nodes can represent execution order, data dependencies, state sharing relationships, or cross-cycle propagation relationships. Through the task graph, the functional structure in the control model can be transformed into task-level objects suitable for subsequent task partitioning, load estimation, and mapping solutions.

[0043] A message flow graph is generated based on the sending port, receiving port, interface connection relationships, message size, communication frequency, triggering method, production rate, consumption rate, tolerable latency, and consistency requirements specified in the interface configuration. The message flow graph can include multiple message edges, with each edge pointing from a source task to a destination task. If the output of one task is used as input by another task, a corresponding message edge can be generated; if the same output is used by multiple tasks, multiple message edges can be generated for each task, or message relationships with multiple destination tasks can be generated. The message flow graph helps determine data transmission requirements between tasks and provides a basis for subsequently identifying cross-processor message sets.

[0044] A processor capability table is generated based on the processor resource information in the constraint configuration. The processor capability table may include information such as processor identifier, processor type, computing budget, storage capacity, available scheduling window, load limit, security isolation domain, deployable task types, and current occupancy status. Using the processor capability table, it is possible to determine whether candidate tasks are suitable for deployment to the corresponding processor resources and to provide resource constraints for load estimation and mapping solutions.

[0045] A bus scheduling table is generated based on the bus resource information in the constraint configuration. The bus scheduling table can include information such as bus identifier, interface channel, time slot number, time slot start time, time slot end time, available bandwidth, occupancy status, security level restrictions, and transmittable message types. The bus scheduling table can be used to determine whether cross-processor messages can be transmitted within the tolerable latency and to provide optional interface channels and optional bus time slots for interface orchestration.

[0046] A set of synchronization points is generated based on constraint configuration and verification rules. Synchronization points can correspond to cross-processor messages, shared state variables, periodic critical variables, buffer read / write locations, or inter-task state commit locations. Synchronization point attributes can include synchronization point identifier, associated task, associated message, synchronization trigger condition, consistency requirements, candidate synchronization methods, and verification rule reference relationships. For cross-processor read / write operations, synchronization points can be generated to constrain writes on the sending side, reads on the receiving side, and state commits; for shared state, synchronization points can be generated to constrain mutual exclusion access, version updates, or atomic state transitions; for periodic critical variables, synchronization points can be generated to constrain consistency within the same period, version consistency, or eventual consistency.

[0047] In this embodiment, by generating task graphs, message flow graphs, processor capability tables, bus scheduling tables, and synchronization point sets respectively, the information in model configuration, interface configuration, constraint configuration, and verification rules can be converted into structured objects that can be referenced by subsequent unified processing objects, thereby providing a data foundation for task splitting, load estimation, mapping solution, interface orchestration, and synchronization code generation.

[0048] In one embodiment, the task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set are constructed into a unified processing object, including:

[0049] Assign a unified object identifier to task nodes, message edges, processor resources, bus slots, and synchronization points;

[0050] Based on the unified object identifier and the association between task nodes, message edges, processor resources, bus slots and synchronization points, data dependency constraint edges are generated to connect task nodes and message edges, deployment constraint edges are generated to connect task nodes and processor resources, transmission constraint edges are generated to connect message edges and bus slots, and synchronization consistency constraint edges are generated to connect synchronization points and task nodes.

[0051] Constraint chains are formed based on the unified object identifiers connected by the constraint edges, and the scope of objects that need to be processed in conjunction with each other during task splitting, mapping solution, interface orchestration, and synchronous code generation is determined based on the constraint chains.

[0052] Specifically, such as Figure 2As shown, the code generation tool can perform unified identification processing on the above objects after generating the task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set. Each task node in the task graph, each message edge in the message flow graph, each processor resource in the processor capability table, each bus slot in the bus scheduling table, and each synchronization point in the synchronization point set can be assigned a unified object identifier. This unified object identifier can be used to reference the corresponding object in subsequent processing, enabling configuration content from different sources to establish associations within the same processing space.

[0053] In one embodiment, a unified object identifier can be generated based on the object's source, type, and sequence number, or it can be generated based on the object's name, path, and version information. For objects within the same control system engineering project, the unified object identifier can remain unique. For objects whose engineering version has changed, the object identifier and version information can be used to determine whether they still correspond to the same task, message, resource, or synchronization point. Therefore, the unified object identifier can be used not only for object indexing but also for subsequent determination of whether the relationships between objects have changed.

[0054] Specifically, after assigning a unified object identifier, different types of constraint edges can be generated based on the relationships between task nodes, message edges, processor resources, bus slots, and synchronization points. If a message edge represents data output by one task node and received by another, a data dependency constraint edge can be generated between the message edge and the relevant task node. If a task node has a deployable range of processors, or a processor resource meets the task node's computational, storage, or security level requirements, a deployment constraint edge can be generated between the task node and the corresponding processor resource. If a message edge needs to be transmitted through bus resources, and a bus slot can meet the bandwidth or latency requirements of the corresponding message, a transmission constraint edge can be generated between the message edge and the corresponding bus slot. If a synchronization point corresponds to one or more read / write tasks, shared state, or cross-processor messages, a synchronization consistency constraint edge can be generated between the synchronization point and the corresponding task node.

[0055] Furthermore, constraint edges can carry constraint type, constraint source, constraint direction, and constraint state. The constraint type can be used to distinguish between data dependencies, deployment constraints, transport constraints, and synchronization consistency constraints. The constraint source can record where the constraint originates from model configuration, interface configuration, constraint configuration, or validation rules. The constraint direction can represent the direction of data flow, deployment candidate, transport candidate, or synchronization influence. The constraint state can indicate whether the constraint is currently available, satisfied, or needs to be recalculated.

[0056] In one embodiment, constraint chains can be formed based on a unified object identifier connected by constraint edges. A constraint chain can represent a continuous association from a task node to a message edge, from a message edge to a bus time slot, from a task node to processor resources, and from a synchronization point to a related task node. For example, when a task node sends data to another task node via a message edge, and that message edge needs to occupy a certain bus time slot, and that message edge corresponds to a synchronization point, a constraint chain containing the task node, message edge, bus time slot, and synchronization point can be formed. This constraint chain can be used to indicate that the above objects need to be considered in conjunction with each other during task partitioning, mapping solution, interface orchestration, and synchronization code generation.

[0057] Furthermore, during task partitioning, if a task node is divided into multiple subtasks, the message edges and synchronization points that need to be re-associated can be determined along the constraint chain associated with that task node. During mapping solution, if a task node is assigned to different processors, the constraint chain formed by that task node and message edges can be used to determine whether cross-processor messages are generated. During interface orchestration, if cross-processor messages require selection of bus time slots, the available interface scheduling candidates can be determined along the constraint chain between message edges and bus time slots. During synchronization code generation, if the task node or message edge associated with a synchronization point changes, the scope of synchronization code objects that need to be regenerated or adjusted can be determined along the synchronization consistency constraint edges.

[0058] In one embodiment, a unified processing object can be denoted as U={T,E,P,B,S,L,C,V}. Here, T represents the set of task nodes, E represents the set of message edges, P represents the set of processor resources, B represents the set of bus time slots, S represents the set of synchronization points, L represents the set of tags, C represents the set of constraint edges, and V represents the set of version fingerprints. This expression is used to describe the object organization relationships within the unified processing object and does not limit the storage format of the unified processing object in a specific software system. The unified processing object can be implemented in the form of a graph structure, table structure, object set, or database record.

[0059] In this embodiment, by assigning unified object identifiers to task nodes, message edges, processor resources, bus slots, and synchronization points, and generating constraint edges based on the relationships between objects, configuration objects of different sources and types can be incorporated into a unified processing object. By forming constraint chains according to the constraint edges, the scope of objects that need to be processed in conjunction with task splitting, mapping solving, interface orchestration, and synchronization code generation can be determined, so that subsequent processing can be performed around the actual relationships between objects, reducing the situation where tasks, interfaces, and synchronization processing are disconnected.

[0060] In one embodiment, performing task splitting and load estimation based on the unified processing object includes:

[0061] Initial tasks are divided according to model level, scheduling cycle, input / output boundaries, and security level;

[0062] When there are cross-period data dependencies or shared states between model blocks, candidate splitting boundaries are generated based on the cross-period data dependencies or shared states.

[0063] Calculate the load estimate for the candidate tasks corresponding to the candidate split boundary, and determine the candidate task set and candidate processor set based on the matching result between the load estimate and the processor resources in the processor capability table.

[0064] Specifically, after constructing the unified processing object, the initial tasks can be determined based on the model hierarchy and functional boundaries in the task graph. The model hierarchy reflects the organizational relationships between parent modules, child modules, and basic functional blocks in the control model; the scheduling cycle reflects the time interval at which model blocks need to be executed periodically; the input / output boundaries reflect the data input and output relationships between model blocks; and the security level reflects the task's requirements for isolated deployment, execution reliability, or synchronous consistency. Code generation tools can use all of the above information as the basis for task partitioning, ensuring that the initial tasks retain the functional boundaries of the control model while facilitating subsequent deployment to run on different processor resources.

[0065] In one embodiment, model blocks at the same model level with the same or similar scheduling cycles, close input-output relationships, and consistent security levels can be merged into a single initial task. Conversely, model blocks with significantly different scheduling cycles, clear input-output boundaries, or different security levels can be divided into different initial tasks. This avoids forcibly merging model blocks with large differences in cycles, boundaries, or security requirements into the same task, thus providing appropriately granular task objects for subsequent mapping solutions.

[0066] Furthermore, when cross-period data dependencies or shared states exist between model blocks, candidate splitting boundaries can be generated based on these dependencies or shared states. Cross-period data dependencies refer to data generated by one model block in the current period that needs to be used by another model block in a subsequent period. Shared states refer to multiple model blocks reading and writing the same state variable, cached data, or control state. For such model blocks, deploying them directly as a single task may lead to concentrated processor load or unclear synchronization relationships; arbitrarily splitting them may compromise data consistency. Therefore, the locations of cross-period data dependencies and shared states can be used as candidate splitting boundaries, ensuring that task splitting is performed while maintaining traceable data relationships.

[0067] Specifically, after generating candidate partition boundaries, one or more candidate tasks can be formed for each candidate partition boundary, and the load estimate of the candidate tasks can be calculated. The load estimate can comprehensively reflect the candidate tasks' usage of processor execution time, storage capacity, and input / output bandwidth. In one embodiment, the load estimate of candidate task i is... The following formula can be used for calculation:

[0068] ;

[0069] in, This represents the worst-case execution time of candidate task i. This represents the scheduling period of candidate task i. This indicates the storage usage of candidate task i, and MemCap indicates the storage capacity of the candidate processor. BWCap represents the input / output bandwidth usage of candidate task i, and BWCap represents the bandwidth capacity corresponding to the candidate processor or candidate communication resource. The above formula is used to estimate the computational, storage, and input / output resource usage of candidate tasks on a uniform scale. In other embodiments, the resource items in the above load estimate can also be normalized or weighted according to processor resource type, task scheduling policy, or interface resource capacity.

[0070] Furthermore, after calculating the load estimate, it can be matched with processor resources in the processor capability table. The processor capability table can record information such as the processor's computing power budget, storage capacity, available time window, security domain, or deployable task type. For a candidate task, if its load estimate does not exceed the candidate processor's load limit, and its security level, cycle requirements, and storage requirements match those of the candidate processor, then the candidate task and candidate processor can be retained as candidate combinations for subsequent mapping solutions. If the candidate task's load estimate exceeds the processor resource capacity, or the security level isolation requirements cannot be met, then the candidate processor can be excluded, or the candidate partitioning boundary can be readjusted to reduce the resource consumption of individual candidate tasks.

[0071] In one embodiment, the code generation tool can generate a candidate task set and a candidate processor set based on the matching results. The candidate task set may include tasks that can participate in the mapping solution after task partitioning and load estimation; the candidate processor set may include processors that can meet the resource requirements and constraints of the corresponding candidate tasks. For candidate tasks that do not match any processor resources, prompt messages or conflict records can be generated to facilitate subsequent adjustments to the task partitioning granularity, processor resource configuration, or constraint configuration.

[0072] In this embodiment, by dividing the initial tasks according to model hierarchy, scheduling cycle, input / output boundaries, and security level, the task objects can correspond to the functional structure and scheduling requirements of the control model. By generating candidate split boundaries when there are cross-cycle data dependencies or shared states, the task granularity can be refined while maintaining the traceability of data dependencies and shared states. By calculating the load estimates of candidate tasks and matching them with the processor capability table, task processor combinations that do not meet resource conditions or constraints can be screened out in advance, thereby improving the efficiency and feasibility of subsequent mapping solutions.

[0073] In one embodiment, performing mapping solving and interface orchestration based on the unified processing object includes:

[0074] Candidate mappings are generated based on processor load limits, task cycles, deadlines, security level isolation requirements, and the candidate processor set.

[0075] For each mapping candidate, a cross-processor message set is determined, and an interface channel and bus time slot are selected based on the communication frequency, message size, tolerable latency, and bus scheduling table of the cross-processor message set.

[0076] If the selected interface channel or bus time slot fails to meet the deadline constraint, load constraint, or security level isolation requirement, the process reverts to the mapping candidate generation process and reselects the task landing point, interface channel, or bus time slot.

[0077] Specifically, after determining the candidate task set and candidate processor set, mapping candidates can be generated based on the processor load limit, task period, deadline, security level isolation requirements, and candidate processor set. Mapping candidates can represent candidate deployment relationships between one or more tasks and one or more processors. For any candidate task, if the processor resource can meet its load estimate, period, deadline, and security level isolation requirements, then that processor resource can be used as a mapping candidate for that candidate task. If multiple candidate tasks are mapped to the same processor simultaneously, it can be further determined whether the total load of that processor within the corresponding scheduling window exceeds the processor load limit.

[0078] Furthermore, after generating mapping candidates, a cross-processor message set can be determined for each candidate. Specifically, the source and destination tasks corresponding to each message edge can be determined along the data dependency constraint edges between task nodes and message edges in the unified processing object; then, based on the task landing points in the mapping candidates, it can be determined whether the source and destination tasks are located on different processors. If the source and destination tasks are located on different processors, the corresponding message edge is added to the cross-processor message set; if the source and destination tasks are located on the same processor, the message edge can be treated as an internal communication object within the processor, rather than as a cross-processor message.

[0079] Specifically, for each message in the cross-processor message set, the interface channel and bus slot can be selected based on its communication frequency, message size, tolerable latency, and the bus scheduling table. The communication frequency determines the number of times a message is sent per unit time; the message size determines the required bandwidth; the tolerable latency determines the maximum allowable transmission delay between the source task's output and the destination task's reception; and the bus scheduling table determines the start and end times, bandwidth, and occupancy status of each interface channel or bus slot. The code generation tool can match the cross-processor message's communication frequency, message size, and tolerable latency with the available bus slots in the bus scheduling table to obtain the corresponding interface scheduling candidates.

[0080] In one embodiment, an interface scheduling candidate may include an interface channel, a bus time slot, a send offset, and a receive offset. The send offset represents the time position in which the source task sends a message within its execution cycle, and the receive offset represents the time position in which the destination task receives a message within its execution cycle. By using the send and receive offsets, it can be determined whether cross-processor messages can be transmitted within the tolerable latency and whether this will affect the deadlines of the source or destination tasks.

[0081] Furthermore, if the selected interface channel or bus time slot fails to meet deadline constraints, load constraints, or security level isolation requirements, the process can revert to the mapping candidate generation process and reselect the task landing point, interface channel, or bus time slot. For example, if a task landing point causes all its output messages to become cross-processor messages, resulting in the available bus time slots being unable to meet the tolerable latency of all messages, the processor landing point for that task or related tasks can be reselected to reduce the number of cross-processor messages. If an interface channel meets the bandwidth requirements but causes the destination task to receive too late, thus failing to meet the destination task's deadline, the bus time slot can be reselected or the transmission offset adjusted. If the task landing point meets the load requirements but not the security level isolation requirements, processor resources that meet the isolation domain requirements can be reselected.

[0082] In one embodiment, rollback control conditions can be set between mapping solution and interface orchestration. These rollback control conditions may include processor load exceeding the load limit, task deadline not being met, cross-processor messages not matching available bus time slots, security level isolation requirements not being met, or interface channel conflicts. If any rollback control condition is met, the code generation tool can determine the rollback target based on the source of the conflict; if the conflict source is processor load, the task landing point or task splitting granularity is adjusted first; if the conflict source is bus time slots, the interface channel or bus time slot is adjusted first; if the conflict source is security level isolation, the task landing point is adjusted first to processor resources that meet the security level isolation requirements. This approach avoids repeated trial and error caused by the independent operation of mapping solution and interface orchestration.

[0083] In this embodiment, by generating mapping candidates based on processor load limits, task cycles, deadlines, security level isolation requirements, and candidate processor sets, and synchronously determining cross-processor message sets for each mapping candidate, task placement selection and interface communication requirements can be correlated. By selecting interface channels and bus time slots based on the communication frequency, message size, tolerable latency, and bus scheduling table of the cross-processor message sets, interface scheduling relationships and task mapping relationships can be formed collaboratively. By backtracking and adjusting task placement, interface channels, or bus time slots when deadline constraints, load constraints, or security level isolation requirements are not met, mismatches between task mapping results and interface scheduling results can be reduced.

[0084] In one embodiment, the method further includes:

[0085] After determining the task mapping relationship and interface scheduling relationship, the mapping evaluation value is calculated based on the task mapping relationship, interface scheduling relationship and historical results;

[0086] When the mapping evaluation value does not meet the preset conditions, the task landing point, task segmentation granularity, interface time slot or synchronization implementation method are adjusted according to the evaluation sub-items that affect the mapping evaluation value.

[0087] When the task graph, message flow graph, processor capability table, or bus scheduling table changes, the affected subset is determined based on the association constraints of the changed object in the unified processing object, and mapping recalculation, interface rearrangement, and synchronization reprocessing are performed on the affected subset.

[0088] Specifically, after determining the task mapping relationship and interface scheduling relationship, a mapping evaluation value can be calculated based on the current task landing point, processor load, number of cross-processor messages, bus slot occupancy, security level isolation results, and historical mapping result reuse. This mapping evaluation value can characterize the overall availability of the current task mapping relationship and interface scheduling relationship, ensuring that the task mapping result not only meets single load conditions but also takes into account factors such as task deadlines, communication costs, security isolation, and incremental reuse.

[0089] In one embodiment, the mapping evaluation value can be expressed as:

[0090] ;

[0091] in, Indicates the mapping evaluation value. Indicates processor load balancing. This indicates whether the task deadline has been met. This represents the evaluation value of cross-processor communication overhead. Indicates the level of security isolation. This indicates the reuse of historical results. α, β, γ, δ, and ε represent the weight coefficients of the corresponding evaluation items. Each evaluation item can be normalized to between 0 and 1, and the sum of α, β, γ, δ, and ε can be 1; a larger value indicates a better evaluation. Through the above weighted calculation, the mapped evaluation value can simultaneously reflect the utilization of computing resources, the fulfillment of real-time requirements, the consumption of communication resources, the security isolation, and the reuse of historical results.

[0092] Preferably, α can be 0.30, β can be 0.25, γ can be 0.20, δ can be 0.15, and ε can be 0.10. By setting the above weights, the mapping evaluation value can be made to focus more on processor load balancing and task deadline fulfillment, while comprehensively considering load balancing, deadline fulfillment, communication overhead, security isolation, and reuse of historical results.

[0093] Furthermore, ;

[0094] MaxLoad and MinLoad represent the maximum and minimum load percentages for each processor, respectively, while LoadLimit represents the processor load limit.

[0095] ;

[0096] This indicates the number of tasks that meet the deadline. Indicates the total number of tasks;

[0097] ;

[0098] CrossCost represents the cross-processor communication overhead, and CommLimit represents the communication overhead limit;

[0099] ;

[0100] This indicates the number of critical tasks that meet the isolation requirements. Indicates the total number of critical tasks;

[0101] ;

[0102] This represents the number of objects from which historical conclusions can be reused. This represents the total number of objects. The above sub-indicators can be limited to between 0 and 1.

[0103] Furthermore, processor load balancing can be determined based on the load differences among processors. For example, it can be calculated based on the maximum processor load, minimum processor load, and load ceiling. A high processor load balancing rate indicates a small load difference between multiple processors; a low rate indicates that some processors are near their load ceiling while others are idle. Task deadline fulfillment can be determined based on the relationship between the number of tasks that meet their deadlines and the total number of tasks. Cross-processor communication overhead can be evaluated based on the number of cross-processor messages, message size, communication frequency, and bus occupancy. Security level isolation can be determined based on whether high-security-level tasks are deployed to processor domains that meet isolation requirements. Historical result reuse can be determined based on the number of objects that can reuse historical task endpoints, interface time slots, and synchronization implementation methods.

[0104] When the mapping evaluation value is lower than a preset threshold, the lowest evaluation sub-item can be further determined, and reverse adjustments can be performed based on the lowest evaluation sub-item. If the lowest evaluation sub-item is processor load balancing, the processor landing point of some tasks can be adjusted, or the task splitting granularity can be changed, allowing tasks on high-load processors to migrate to processors with candidate processing capabilities. If the lowest evaluation sub-item is task deadline satisfaction, the scheduling priority of related tasks can be increased, task execution offsets can be adjusted, or the interface time slots related to the task can be reselected to reduce waiting time. If the lowest evaluation sub-item is cross-processor communication overhead evaluation value, tasks with high-frequency message interaction can be mapped to the same processor first, or the interface channel and bus time slot can be reselected to reduce cross-processor communication overhead. If the lowest evaluation sub-item is security level isolation, the processor domain of critical tasks can be reselected so that tasks of different security levels meet isolation constraints. If the lowest evaluation sub-item is historical result reuse, the changed objects that cause historical results to be unusable can be identified, and the original task landing point, interface time slot, and synchronization implementation method of unaffected objects can be retained first.

[0105] In one embodiment, when a task graph, message flow graph, processor capability table, or bus scheduler table undergoes partial changes, version fingerprints can be generated for the task nodes, message edges, processor resources, bus slots, and synchronization points before and after the change. Version fingerprints can be determined based on at least one of object identifier, object attributes, constraint relationships, and generation time. When the version fingerprint of an object is inconsistent with a historical version fingerprint, the object can be identified as a changed object, and all changed objects can be formed into a set of changed objects.

[0106] Furthermore, the set of changing objects can be expanded along the constraint edges in the unified processing object to obtain the affected subset. For example, when the changing object is a bus time slot, the message edge occupying the bus time slot can be determined along the transmission constraint edge, the source task and destination task connected to the message edge can be determined along the data dependency constraint edge, and the synchronization point corresponding to the message edge can be determined along the synchronization consistency constraint edge. Thus, the bus time slot, message edge, source task, destination task, and synchronization point can be determined as the affected subset, while tasks, messages, processor resources, and synchronization points that are not included in the affected subset can reuse historical results.

[0107] In a specific example, if a bus time slot changes from available to unavailable, the bus time slot can be identified as the changed object first. Then, the cross-processor messages using the bus time slot can be determined along the transmission constraint edges. Subsequently, the source and destination tasks corresponding to the cross-processor messages can be determined along the data dependency constraint edges, and the corresponding synchronization points can be determined along the synchronization consistency constraint edges. For the affected subset, interface time slot selection, transmit offset calculation, receive offset calculation, and synchronization implementation method confirmation can be re-executed. For unaffected task landing points, interface scheduling relationships, and synchronization code, historical results can continue to be reused.

[0108] In this embodiment, a comprehensive evaluation of task mapping relationships and interface scheduling relationships is conducted through mapping evaluation values, which can form a unified feedback basis among task deployment, interface communication, security isolation, and historical reuse. By adjusting the task landing point, task segmentation granularity, interface time slot, or synchronization implementation method in reverse by the lowest evaluation sub-item, the adjustment direction can be made to correspond to the actual source of the problem. By determining the affected subset through version fingerprint and constraint edge expansion, it is possible to avoid reprocessing all tasks and interfaces when there are local changes, thereby improving the efficiency of mapping recalculation, interface rearrangement, and synchronization reprocessing.

[0109] In one embodiment, the unified processing object carries a set of tags for driving the linkage processing;

[0110] When a task is split, the subtask inherits the security level label and source identifier of the parent task, and the resource usage label is recalculated based on the load ratio of the subtask.

[0111] When the task mapping relationship changes, the processor domain label is remapped, and the bus slot label of the message edge connected to the task is recalculated.

[0112] When a bus time slot is unavailable, interface scheduling candidates are pruned and conflict records are generated based on the recalculated bus time slot label.

[0113] Specifically, the tag set in the unified processing object can be used to record the status and constraint relationships of task nodes, message edges, processor resources, bus slots, and synchronization points at different processing stages. The tag set can be updated during task splitting, mapping solving, interface orchestration, and synchronization code generation, enabling continuous tracking of the processing status of related objects. The tag set can include processor domain tags, bus slot tags, priority tags, resource occupancy tags, security level tags, and source identifiers, etc. These tags can serve as triggering criteria for linked processing, and are not limited to static descriptive information.

[0114] When a task is split, subtasks can inherit the security level label and source identifier from the parent task. The security level label indicates the isolation, reliability, or synchronization consistency requirements of the corresponding model block or control function in the parent task. The source identifier indicates the model source, configuration source, or object source of the corresponding parent task. By inheriting the security level label and source identifier, subtasks can maintain the correspondence with the original model object in subsequent mapping solutions and interface orchestration, and maintain a consistent security constraint basis with the parent task.

[0115] Furthermore, after a task is split, the resource usage label can be recalculated based on the load ratio of the subtasks. The resource usage label can represent the task's consumption of execution time, storage resources, and interface bandwidth. If the parent task is split into multiple subtasks, the resource usage label for each subtask can be recalculated based on its worst-case execution time, cycle time, storage consumption, and I / O bandwidth consumption, or based on the load ratio of the subtasks relative to the parent task. The recalculated resource usage label can then be used to determine whether a subtask is suitable for mapping to the corresponding processor resource.

[0116] In one embodiment, if a parent task is divided into a first subtask and a second subtask, with the first subtask retaining the main computational logic and the second subtask retaining the communication or state update logic, then the first subtask can obtain a higher computational resource usage label, and the second subtask can obtain a higher interface bandwidth or synchronization-related resource usage label. In this way, during the mapping solution, different processor resources or interface scheduling strategies can be selected based on the resource usage differences of the different subtasks, rather than simply using the resource usage results of the parent task.

[0117] Specifically, when task mapping relationships change, processor domain labels can be remapped. Processor domain labels can represent the processor domains where a task is deployable or has already been deployed. When a task changes from one processor resource to another, the code generation tool can update the processor domain label corresponding to that task to the new processor domain and determine whether this change affects the message edges connected to that task. If the change in task endpoint causes a source and destination task originally located on the same processor to become cross-processor deployed, or causes a source and destination task originally deployed across processors to become deployed on the same processor, then the bus slot labels of the message edges connected to that task can be recalculated.

[0118] Furthermore, bus slot tags can represent bus slots that a message edge can use or has already used. When the task mapping changes and causes a change in the cross-processor message set, the code generation tool can recalculate the bus slot tag for the corresponding message edge based on the source task, destination task, communication frequency, message size, tolerable latency, and bus schedule table. If a message edge no longer needs cross-processor transmission, its bus slot tag can be removed or invalidated; if a message edge changes from intra-processor communication to cross-processor communication, a new bus slot tag can be generated for it and used for interface orchestration.

[0119] When a bus time slot is unavailable, interface scheduling candidates can be trimmed and conflict records generated based on the recalculated bus time slot label. Unavailable bus time slots can include situations such as the time slot being occupied, insufficient time slot bandwidth, time slot start and end times not meeting tolerable latency, time slot mismatch with security level isolation requirements, or time slot conflict with task execution offsets. For unavailable bus time slots, the code generation tool can remove the corresponding candidate from the interface scheduling candidates and record the conflict cause, related message edges, related task nodes, corresponding bus time slot, and the processing stage that triggered the conflict.

[0120] In one embodiment, conflict records can be used for subsequent rollback adjustments. When a conflict record indicates insufficient bus slot bandwidth, the interface channel can be reselected or the message transmission offset adjusted; when a conflict record indicates that the slot start and end times cannot meet the tolerable latency, the bus slot can be reselected or the task landing point adjusted; when a conflict record indicates that the slot does not match the security level isolation requirements, a processor domain or interface channel that meets the isolation requirements can be reselected. Therefore, tag updates are not only used to record status but also to drive feedback adjustments between mapping solutions and interface orchestration.

[0121] In this embodiment, by carrying a set of tags in the unified processing object, and performing tag inheritance, tag recalculation, tag remapping, and candidate pruning respectively when task splitting, task mapping relationship changes, and bus time slots become unavailable, the association status between tasks, messages, processor resources, and bus time slots can be dynamically updated with the processing process. By generating conflict records based on tag changes, a basis can be provided for subsequent task landing point adjustment, interface channel adjustment, and bus time slot adjustment, thereby improving the linkage between task mapping, interface orchestration, and synchronous code generation.

[0122] In one embodiment, generating synchronization code based on the task mapping relationship, interface scheduling relationship, synchronization point set, and verification rules includes:

[0123] For messages in the interface scheduling relationship, the synchronization implementation method is determined based on the processor landing point of the source task and the destination task, the message triggering method, the message size, the production rate, the consumption rate, the consistency requirements of the synchronization point, and the synchronization constraints corresponding to the verification rules.

[0124] Generate the corresponding synchronization code according to the synchronization implementation method described above.

[0125] Specifically, after determining the task mapping relationship and interface scheduling relationship, the synchronization implementation method can be determined for the messages in the interface scheduling relationship. Messages in the interface scheduling relationship can include intra-processor messages and cross-processor messages. For each message, it can be determined whether it needs cross-processor synchronization based on the processor landing points of the source task and the destination task; whether it is a periodic message, event-triggered message, or burst-sent message based on the message triggering method; whether it is suitable for transmission via shared memory, message queue, or buffer based on the message size and interface channel capacity; whether there is a rate inconsistency based on the production rate and consumption rate; and the read / write order, commit conditions, cache depth, or timeout handling conditions that the synchronization code needs to satisfy based on the consistency requirements of the synchronization point and the synchronization constraints corresponding to the verification rules.

[0126] In one embodiment, when the source task and destination task reside on different processors, and the corresponding message is a periodic critical variable, the synchronization implementation method can be determined to be double-buffered synchronization. Double-buffered synchronization code may include code segments such as the sender-side write buffer, commit update flag, receiver-side read stable buffer, and switching read / write indices. Through double-buffered synchronization, the data written by the source task and the data read by the destination task can operate on different buffers, reducing data inconsistencies caused by simultaneous reading and writing of the same data area.

[0127] In one embodiment, when the source and destination tasks reside in the same shared memory domain and the message size does not exceed a shared memory threshold, the synchronization implementation can be determined to be shared memory synchronization. Shared memory synchronization code may include code segments such as shared data area writing, version number updates, mutex lock control, or atomic status bit updates. Shared memory synchronization can reduce unnecessary bus transmissions and enable tasks located in the same shared memory domain to exchange data through controlled read / write operations.

[0128] In one embodiment, when a message exhibits event-triggered or burst-sent characteristics, the synchronization implementation method can be determined to be message queue synchronization. Message queue synchronization code may include code segments for message enqueueing, queue status determination, receiver-side dequeueing, timeout handling, and queue depth control. Through message queue synchronization, event-triggered or burst-sent messages can be cached and consumed according to queue order, reducing the possibility of burst message overwriting or loss.

[0129] In one embodiment, when the message production rate and consumption rate are inconsistent, and the verification rules allow for limited latency, the synchronization implementation method can be determined to be buffer synchronization. Buffer synchronization code may include code segments such as buffer writing, buffer reading, water level determination, discarding policies, or latency control. Through buffer synchronization, messages can be temporarily stored when the production and consumption rates are inconsistent, allowing the destination task to read data according to its own execution rhythm.

[0130] Furthermore, the code generation tool can generate corresponding synchronization code based on the synchronization implementation method. For double-buffered synchronization, it can generate code related to write indexes, read indexes, and commit flags; for shared memory synchronization, it can generate code related to mutexes, version numbers, or atomic state bits; for message queue synchronization, it can generate code related to queue depth, enqueueing, dequeueing, and timeout handling; and for buffer synchronization, it can generate code related to buffer water level, buffer read / write positions, and discard policies. This synchronization code can be bound to task mapping relationships and interface scheduling relationships, enabling the generated sending-side code, receiving-side code, and synchronization control code to correspond to specific source tasks, destination tasks, interface channels, and synchronization points.

[0131] In one embodiment, the synchronization point set may include multiple synchronization points. For example, the first synchronization point may correspond to periodic key variable messages, with double buffering as a candidate synchronization method; the second synchronization point may correspond to inter-task messages within the same shared memory domain, with shared memory or double buffering as candidate synchronization methods; the third synchronization point may correspond to event-triggered messages, with message queues as a candidate synchronization method; and the fourth synchronization point may correspond to messages where the production rate and consumption rate are inconsistent, with a buffer as a candidate synchronization method. After determining the task mapping relationship and interface scheduling relationship, the code generation tool can select a synchronization implementation method that meets the verification rules from the candidate synchronization methods of the synchronization points, based on the processor landing points of the source and destination tasks.

[0132] In this embodiment, by determining the synchronization implementation method based on the processor landing point, message triggering method, message size, production rate, consumption rate, consistency requirements of synchronization points, and synchronization constraints corresponding to the verification rules of the source and destination tasks, the synchronization code is no longer generated solely based on message type, but is determined jointly by task deployment, interface scheduling, message characteristics, and synchronization constraints. By generating synchronization code such as double buffering, shared memory, message queues, or buffers according to the synchronization implementation method, cross-processor communication, shared state access, and rate-inconsistent message processing in the multiprocessor control system can have a corresponding synchronization implementation basis.

[0133] Furthermore, in one embodiment, the method further includes performing a synchronization check on the synchronization code, the synchronization check including:

[0134] Synchronization verification rules are generated based on the verification rules and the synchronization implementation method corresponding to the synchronization code.

[0135] Based on the synchronization verification rules, the task mapping relationship, interface scheduling relationship, and synchronization code are synchronously verified to generate a verification report;

[0136] The synchronization check is used to determine whether the synchronization code satisfies the synchronization constraints corresponding to the synchronization point set and the verification rule.

[0137] Specifically, during or after the generation of synchronization code, task mapping relationships, interface scheduling relationships, synchronization point sets, verification rules, and the synchronization implementation method corresponding to the synchronization code can be obtained. Corresponding synchronization verification rules are then generated based on these implementation methods. These verification rules can be used to check whether the read / write order, status commit, cache usage, queue processing, and exception handling in the synchronization code satisfy the synchronization constraints corresponding to the synchronization point set and verification rules. Therefore, the synchronization verification is not limited to a post-processing step independent of synchronization code generation; it can also be executed as a supporting verification step during the synchronization code generation process.

[0138] In one embodiment, when the synchronization implementation corresponding to the synchronization code is double-buffered synchronization, write index, read index, and commit flag verification rules can be generated. The write index verification rule can be used to check whether the buffer written by the source task is distinguished from the buffer being read by the destination task; the read index verification rule can be used to check whether the data read by the destination task comes from a committed, stable buffer; the commit flag verification rule can be used to check whether the source task exposes the updated data to the destination task through a commit flag after completing the write. Through these verification rules, it is possible to check whether the double-buffered synchronization code has situations where reads and writes point to the same buffer, uncommitted data is read, or the commit status is missing.

[0139] In one embodiment, when the synchronization implementation corresponding to the synchronization code is shared memory synchronization, mutex lock, version number, or atomic state bit verification rules can be generated. The mutex lock verification rule can be used to check whether there is a controlled entry and exit process for shared memory writes and reads; the version number verification rule can be used to check whether the version of the data read by the target task is consistent before and after; the atomic state bit verification rule can be used to check whether the shared state update has a determinable completion status. Through these verification rules, it is possible to check whether the shared memory synchronization code has read-write conflicts, version inconsistencies, or undeterminable shared state updates.

[0140] In one embodiment, when the synchronization implementation corresponding to the synchronization code is message queue synchronization, queue depth and timeout handling verification rules can be generated. The queue depth verification rules can be used to check whether the queue capacity can cover the message triggering frequency and burst sending situations in the interface scheduling relationship during message enqueueing and dequeueing. The timeout handling verification rules can be used to check whether the destination task has processing logic such as timeout return, retry, or error status recording when waiting for messages. Through the above verification rules, it is possible to check whether the message queue synchronization code has queue overflow, empty queue blocking, or message loss.

[0141] In one embodiment, when the synchronization implementation corresponding to the synchronization code is cache synchronization, water level thresholds and discard policy verification rules can be generated. The water level threshold verification rules can be used to check whether the cache has a high water level, low water level, or available capacity when the production rate and consumption rate are inconsistent; the discard policy verification rules can be used to check whether the cache performs overwrite, discard, delay, or alarm processing according to the verification rules when it reaches a predetermined water level. Through these verification rules, it is possible to check whether the cache synchronization code has cache backlog, reads expired data, or timing misalignments.

[0142] Furthermore, synchronization verification can be performed on task mapping relationships, interface scheduling relationships, and synchronization code based on synchronization verification rules. For task mapping relationships, it can be checked whether the processor landing points of the source and destination tasks correspond to the sending and receiving side codes in the synchronization code; for interface scheduling relationships, it can be checked whether the sending offset, receiving offset, interface channel, and bus time slot in the synchronization code are consistent with the interface scheduling relationship; for synchronization code, it can be checked whether the synchronization variables, status flags, cache depth, queue depth, read / write index, and exception handling logic satisfy the corresponding synchronization verification rules.

[0143] In one embodiment, the verification report can record the synchronization verification results. The verification report may include synchronization points that passed verification, synchronization points that failed verification, the reasons for failure, the corresponding tasks, the corresponding messages, the corresponding interface channels, the corresponding bus time slots, the synchronization implementation method, and suggested adjustments. If the synchronization verification finds a missing double-buffered commit flag, the corresponding synchronization point, source task, destination task, and missing commit status can be recorded in the verification report; if the synchronization verification finds that the queue depth does not meet the requirements for bursty messages, the corresponding message, interface scheduling relationship, and the queue depth or interface time slot that needs adjustment can be recorded in the verification report; if the synchronization verification finds that the buffer water level rules do not meet the verification rules, the corresponding buffer synchronization code and the discard strategy or delay control method that needs adjustment can be recorded in the verification report.

[0144] Furthermore, the verification report can be fed back to the mapping solution, interface orchestration, or synchronization code generation processes. If the verification report shows that the synchronization problem stems from a change in the task landing point, the task landing point can be reselected; if the synchronization problem stems from an interface time slot conflict, the interface channel or bus time slot can be reselected; if the synchronization problem stems from a mismatch in the synchronization implementation method, the synchronization implementation method can be reselected and the synchronization code regenerated. Thus, synchronization verification is not only used to output verification results, but also to provide a basis for subsequent adjustments.

[0145] In this embodiment, by generating synchronization verification rules based on verification rules and the synchronization implementation method corresponding to the synchronization code, different synchronization codes can adopt a verification mechanism that matches their implementation method. By performing synchronization verification on task mapping relationships, interface scheduling relationships, and synchronization codes, it can be checked whether the synchronization code is consistent with the task landing point, interface timing, and synchronization point constraints. By generating a verification report and recording the reasons for failure and suggested adjustment objects, a data foundation can be provided for feedback adjustment between task mapping, interface orchestration, and synchronization code generation.

[0146] Furthermore, in one embodiment, the multi-task joint deployment process in a dual-processor avionics controller can be used as an application example to illustrate the code generation method provided in this application. This example is used to illustrate how tasks, messages, processor resources, bus time slots, and synchronization points collaboratively participate in code generation within a unified processing object, and is not intended to limit the types of control systems to which this application applies. The embodiments of this application can also be applied to control systems with multi-processor, multi-bus, multi-cycle tasks, and synchronization consistency requirements, such as satellite control systems, ship control systems, and industrial controller clusters.

[0147] In this example, the task list corresponding to the model configuration may include attitude acquisition task T1, attitude stabilization control task T2, navigation fusion task T3, health monitoring task T4, and bus management task T5. Specifically, T1 has a period of 5ms, a worst-case execution time of 0.6ms, a deadline of 5ms, and a safety level of A; T2 has a period of 10ms, a worst-case execution time of 1.8ms, a deadline of 10ms, and a safety level of A; T3 has a period of 20ms, a worst-case execution time of 2.2ms, a deadline of 20ms, and a safety level of B; T4 has a period of 20ms, a worst-case execution time of 0.9ms, a deadline of 20ms, and a safety level of C; and T5 has a period of 10ms, a worst-case execution time of 0.7ms, a deadline of 10ms, and a safety level of B.

[0148] The message flow table corresponding to the interface configuration can include messages M1, M2, M3, and M4. M1 is sent from T1 to T2, with a message size of 32 bytes, a communication frequency of 200Hz, a tolerance latency of 1ms, and a consistency requirement of being consistent within the same period; M2 is sent from T2 to T3, with a message size of 64 bytes, a communication frequency of 100Hz, a tolerance latency of 2ms, and a consistency requirement of being version consistent; M3 is sent from T3 to T4, with a message size of 128 bytes, a communication frequency of 50Hz, a tolerance latency of 5ms, and a consistency requirement of eventual consistency; M4 is sent from T4 to T5, with a message size of 64 bytes, a communication frequency of 50Hz, and a tolerance latency of 5ms.

[0149] The processor capability table corresponding to the constraint configuration can include the main control processor P1 and the monitoring processor P2. P1 has a computing budget of 8ms within a 10ms period, a storage capacity of 512KB, and an isolation domain of D_A; P2 has a computing budget of 6ms within a 10ms period, a storage capacity of 256KB, and an isolation domain of D_B. The bus scheduling table can include multiple time slots for bus Bus1, where Slot1 is 0.5ms to 0.8ms with a bandwidth of 256 bytes; Slot2 is 2.0ms to 2.4ms with a bandwidth of 256 bytes; and Slot3 is 5.0ms to 5.5ms with a bandwidth of 512 bytes. The synchronization point set can include S1, S2, S3, and S4, where S1 corresponds to M1 with double buffering as the candidate synchronization method; S2 corresponds to M2 with shared memory or double buffering as the candidate synchronization method; S3 corresponds to M3 with message queue as the candidate synchronization method; and S4 corresponds to M4 with buffer as the candidate synchronization method.

[0150] Specifically, time slots T1 to T5, M1 to M4, P1 to P2, Bus1, and S1 to S4 can be constructed as a unified processing object. Within this unified processing object, constraint edges are generated between task nodes, message edges, processor resources, bus time slots, and synchronization points. Taking M2 as an example, M2 connects T2 and T3, thus forming data dependency constraints between T2, M2, and T3. When T2 is mapped to P1 and T3 is mapped to P2, M2 becomes a cross-processor message, further forming transmission constraints between M2 and candidate time slots in Bus1, and synchronization consistency constraints between S2 and T2 and T3.

[0151] In one embodiment, after task segmentation, load estimation, mapping solution, and interface orchestration, a task mapping table and an interface scheduling table can be obtained. The task mapping table can record information such as task identifier, processor identifier, cycle time, worst-case execution time, load percentage, priority, security level, and version fingerprint. For example, T1 can be mapped to P1, T2 to P1, T3 to P2, T4 to P2, and T5 to P1. The interface scheduling table can record information such as message identifier, source processor, destination processor, communication channel, timeslot number, send offset, receive offset, buffer depth, synchronization method, and conflict state. For example, M1 is shared within P1 and does not occupy the bus, so shared memory synchronization can be used; M2 is transmitted from P1 to P2, occupying Slot 2 of Bus1, using double-buffered synchronization; M3 is transmitted within P2, using message queue synchronization; M4 is transmitted from P2 to P1, occupying Slot 3 of Bus1, using buffer synchronization.

[0152] Furthermore, for M2, a double-buffered synchronization logic can be generated. The write side first writes to `buf[writeIndex]`, then updates the version and atomically switches `commitIndex`. The read side reads the cache corresponding to `commitIndex` and checks if the version before and after the read is consistent. If the version is inconsistent, the previous stable cache is read. This method prevents the write and read processes from accessing the same uncommitted cache, thus avoiding data tearing. For M4, a circular cache logic can be generated. The write side enqueues the cache when the cache level is below `HighWater`, and the read side dequeues it periodically. When the cache level exceeds `HighWater`, the lowest priority old telemetry frames are discarded and an alarm is recorded, thereby reducing the situation where low-priority messages crowd out critical time slots.

[0153] Furthermore, in a specific example, it can be done as described above. The calculation method evaluates the overall results of task mapping relationships, interface scheduling relationships, and synchronization code. P1 load is 0.37, P2 load is 0.155, and LoadLimit is 0.80. The value is 0.731; if all 5 tasks meet their deadlines, then... The cross-processor communication overhead (CrossCost) is 1; the cross-processor communication overhead (CrossCost) is 0.32, and the CommLimit is 1. The value is 0.68; if both critical tasks meet the isolation requirements, then... If the value is 1; and 8 out of 10 objects reuse historical conclusions, then... The value is 0.8. This is calculated based on the aforementioned preferred weights. The value is 0.835. When the preset threshold is 0.82, the current task mapping relationship and interface scheduling relationship can be output; when the preset threshold is 0.88, it can identify... and The value is too low, and suggestions are given to move T5 to P2 or adjust M4 to Slot1.

[0154] Furthermore, if Slot2 in the bus scheduling table is adjusted from 2.0ms to 2.4ms to 2.8ms to 3.2ms, the version fingerprint can be compared, and Slot2 can be marked as the changed object. Locate M2 along the bus slot constraint edge, locate T2 and T3 along the data dependency constraint edge of M2, and locate S2 along the synchronization consistency constraint edge, thus obtaining the affected subset Impact={Slot2, M2, T2, T3, S2}. T1, T4, T5, M1, M3, M4, and their corresponding verification conclusions are not included in the recalculation scope. At this point, only the transmit offset, receive offset, and double-buffered commit time of M2 can be recalculated, and the deadline of T3 can be checked; if T3 still meets the 20ms deadline, its historical task landing point is reused, and only the interface scheduling table and synchronization code version fingerprint are updated.

[0155] Furthermore, the tag propagation process can be recorded. After T2 is mapped to P1, it obtains the processor domain tag Domain=P1 / D_A, the priority tag Priority=High, and the resource occupancy tag CPU=1.8ms / 10ms. M2 connects T2 and T3. After T3 is mapped to P2, M2 inherits the version fingerprints of T2 and T3 and generates a cross-domain communication tag CrossDomain=P1->P2. At the same time, it selects Slot2 of Bus1 based on the communication frequency of 100Hz and the tolerance delay of 2ms. If Slot2 is occupied, the candidate time slot is pruned, and the transmission offset is recalculated according to the available time slots. If no available time slot meets the tolerance delay, the T3 landing point candidate adjustment is triggered in reverse, or an interface conflict record is output.

[0156] Furthermore, additional rules can be added for selecting the synchronization method. For messages within the same processor domain with a fixed read / write task scheduling order, shared memory synchronization is preferred; for periodic messages across processors where the receiving task requires reading a complete snapshot, double-buffered synchronization is preferred; for event-triggered messages that may burst continuously, message queue synchronization is preferred, with the queue depth determined based on the maximum burst count; for messages with a production rate higher than the consumption rate and where discarding low-priority historical data is permissible, circular buffer synchronization is preferred. The synchronization method selection result can be written into the interface scheduling table, with mutexes, atomic variables, version numbers, queue depths, and water level thresholds used as parameters for generating synchronization code.

[0157] Furthermore, processing records can be generated. These processing records can correspond to task splitting, tag propagation, mapping selection, interface time slot selection, synchronous code generation, and... The process includes feedback and other processing stages. Processing records may include a unified object identifier, rule number, input version fingerprint, output version fingerprint, hit constraints, pruned candidates, correction suggestions, verification status, and responsibility identifier. These processing records allow for reverse tracing from the final task mapping table back to the original task node, message flow, processor capability configuration, and bus scheduling configuration.

[0158] In this embodiment, the task list, message flow table, processor capability table, bus scheduling table, and synchronization point set are uniformly constructed into a computable object in the complete application example, and based on task mapping, interface scheduling, synchronization code generation, and synchronization verification, By coordinating evaluation and incremental reuse, the code generation process of a multiprocessor control system can be kept consistent at the object, constraint, label, and version fingerprint levels, thereby improving the coordination between task deployment, interface communication, synchronous implementation, and verification reuse.

[0159] The steps of the various methods described above are only for clarity. In practice, they can be combined into one step or some steps can be split into multiple steps. As long as they include the same logical relationship, they are all within the scope of protection of this application. Adding insignificant modifications or introducing insignificant designs to the algorithm or process, but without changing the core design of the algorithm and process, are also within the scope of protection of this application.

[0160] Furthermore, some embodiments of this application also provide an electronic device. The electronic device can be various forms of digital computer, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, etc. The electronic device can also be various forms of mobile devices, such as cellular phones, smartphones, wearable devices, and other similar computing devices.

[0161] The electronic device includes: one or more processors; and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the methods provided in any one or more of the above embodiments. Figure 3An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, a memory 1102, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components are interconnected via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the electronic device, including instructions stored in or on memory to display graphical information of a GUI on an external input / output device (such as a display device coupled to the interface). In some other embodiments, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple electronic devices can be connected, each providing some of the necessary operations. The components, their connections and relationships, and their functions shown herein are merely examples and are not intended to limit the implementation of the present application described and / or claimed herein.

[0162] The electronic device may further include an input device 1103 and an output device 1104. The processor 1101, memory 1102, input device 1103 and output device 1104 may be connected via a bus 1105 or other means, as shown in the figure, which is connected via a bus 1105.

[0163] Input device 1103 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the electronic device, such as a touch screen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 1104 may include a display device, auxiliary lighting device (e.g., LED), and haptic feedback device (e.g., vibration motor). The display device may include, but is not limited to, a liquid crystal display, a light-emitting diode display, and a plasma display. In some embodiments, the display device may be a touch screen.

[0164] To provide interaction with the user, the electronic device can be a computer. The computer has: a display device (e.g., a cathode ray tube or LCD monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0165] In this embodiment, a computer-readable medium stores a computer program / instructions that, when executed by a processor, implement the steps of the methods provided in any one or more of the above embodiments. This computer-readable medium may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into that device. The aforementioned computer-readable medium carries one or more computer-readable instructions.

[0166] The memory 1102 can serve as a non-transitory computer-readable storage medium, used to store non-transitory software programs, non-transitory computer-executable programs, and modules. The processor 1101 executes various functional applications and data processing of the server by running the non-transitory software programs, instructions, and modules stored in the memory 1102, thereby implementing the program instructions / modules corresponding to the methods provided in any one or more of the embodiments described above in this application.

[0167] The memory 1102 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the electronic device. Furthermore, the memory 1102 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 1102 may optionally include memory remotely located relative to the processor 1101, and these remote memories can be connected to the electronic device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0168] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. Computer-readable media can be, for example, but not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to, electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0169] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile optical discs or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0170] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0171] In the above embodiments, all or part of the implementation can be achieved through software, hardware, firmware, or any combination thereof. For example, it can be implemented using an application-specific integrated circuit (ASIC), a general-purpose computer, or any other similar hardware device. In some embodiments, the software program of this application can be executed by a processor to implement the above steps or functions. Similarly, the software program of this application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drives, floppy disks, and similar devices. In addition, some steps or functions of this application can be implemented in hardware, for example, as circuitry that cooperates with a processor to perform the various steps or functions.

[0172] The computer program product provided in this application includes one or more computer programs / instructions. When executed by a processor, these computer programs / instructions generate, in whole or in part, the processes or functions described in this application. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

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

[0174] The scope of this application is defined by the appended claims rather than the foregoing description, and is therefore intended to encompass all variations falling within the meaning and scope of equivalents of the claims. No reference numerals in the claims should be construed as limiting the scope of the claims. Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device in software or hardware. Terms such as "first," "second," etc., are used only for distinguishing descriptions and do not indicate any particular order, nor should they be construed as indicating or implying relative importance.

[0175] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily made by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims, and the above embodiments should be regarded as exemplary and non-limiting.

Claims

1. A code generation method based on a multiprocessor control system, characterized in that, The method includes: Obtain the model configuration, interface configuration, constraint configuration, and verification rules of the control system to be processed; A task graph is generated based on the model configuration, a message flow graph is generated based on the interface configuration, and a processor capability table, a bus scheduling table, and a set of synchronization points are generated based on the constraint configuration. The task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set are constructed into a unified processing object, which is used to represent the association constraints between tasks, messages, processor resources, bus resources, and synchronization points. Based on the unified processing object, task segmentation, load estimation, mapping solution and interface orchestration are performed to determine task mapping relationships and interface scheduling relationships; Synchronization code is generated based on the task mapping relationship, interface scheduling relationship, synchronization point set, and verification rules.

2. The code generation method according to claim 1, characterized in that, The task graph, message flow graph, processor capability table, bus scheduling table, and synchronization point set are constructed into a unified processing object, including: Assign a unified object identifier to task nodes, message edges, processor resources, bus slots, and synchronization points; Based on the unified object identifier and the association between task nodes, message edges, processor resources, bus slots and synchronization points, data dependency constraint edges are generated to connect task nodes and message edges, deployment constraint edges are generated to connect task nodes and processor resources, transmission constraint edges are generated to connect message edges and bus slots, and synchronization consistency constraint edges are generated to connect synchronization points and task nodes. Constraint chains are formed based on the unified object identifiers connected by the constraint edges, and the scope of objects that need to be processed in conjunction with each other during task splitting, mapping solution, interface orchestration, and synchronous code generation is determined based on the constraint chains.

3. The code generation method according to claim 1, characterized in that, Based on the unified processing object, task splitting and load estimation are performed, including: Initial tasks are divided according to model level, scheduling cycle, input / output boundaries, and security level; When there are cross-period data dependencies or shared states between model blocks, candidate splitting boundaries are generated based on the cross-period data dependencies or shared states. Calculate the load estimate for the candidate tasks corresponding to the candidate split boundary, and determine the candidate task set and candidate processor set based on the matching result between the load estimate and the processor resources in the processor capability table.

4. The code generation method according to claim 3, characterized in that, Based on the unified processing object, map solving and interface orchestration are performed, including: Candidate mappings are generated based on processor load limits, task cycles, deadlines, security level isolation requirements, and the candidate processor set. For each mapping candidate, a cross-processor message set is determined, and an interface channel and bus time slot are selected based on the communication frequency, message size, tolerance latency, and bus scheduling table of the cross-processor message set. If the selected interface channel or bus time slot fails to meet the deadline constraint, load constraint, or security level isolation requirement, the process reverts to the mapping candidate generation process and reselects the task landing point, interface channel, or bus time slot.

5. The code generation method according to claim 1, characterized in that, The method further includes: After determining the task mapping relationship and interface scheduling relationship, the mapping evaluation value is calculated based on the task mapping relationship, interface scheduling relationship and historical results; When the mapping evaluation value does not meet the preset conditions, the task landing point, task segmentation granularity, interface time slot or synchronization implementation method are adjusted according to the evaluation sub-items that affect the mapping evaluation value. When the task graph, message flow graph, processor capability table, or bus scheduling table changes, the affected subset is determined based on the association constraints of the changed object in the unified processing object, and mapping recalculation, interface rearrangement, and synchronization reprocessing are performed on the affected subset.

6. The code generation method according to claim 1, characterized in that, The unified processing object carries a set of tags for driving the linkage processing; When a task is split, the subtask inherits the security level label and source identifier of the parent task, and the resource usage label is recalculated based on the load ratio of the subtask. When the task mapping relationship changes, the processor domain label is remapped, and the bus slot label of the message edge connected to the task is recalculated. When bus time slots are unavailable, interface scheduling candidates are pruned and conflict records are generated based on the recalculated bus time slot labels.

7. The code generation method according to claim 1, characterized in that, Synchronization code is generated based on the task mapping relationship, interface scheduling relationship, synchronization point set, and verification rules, including: For messages in the interface scheduling relationship, the synchronization implementation method is determined based on the processor landing point of the source task and the destination task, the message triggering method, the message size, the production rate, the consumption rate, the consistency requirements of the synchronization point, and the synchronization constraints corresponding to the verification rules. Generate the corresponding synchronization code according to the synchronization implementation method described above.

8. An electronic device, characterized in that, The electronic device includes: One or more processors; and A memory storing computer program instructions, which, when executed, cause the processor to perform the steps of the method as described in any one of claims 1 to 7.

9. A computer-readable medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images