Microsystem construction method and device based on digital prototype

Abstract

The embodiment of the invention provides a micro-system construction method and device based on a digital prototype, and the method comprises the steps: constructing a function architecture graph model representing the functions of a micro-system based on the operation demands of a target micro-system; performing function allocation according to the design constraint of the target microsystem, and generating a logic architecture graph model; a physical architecture graph model is generated, and a chip component model is generated according to the component type selection requirement of the microsystem; instantiating the physical architecture graph model to obtain a simulation verification model; and performing simulation optimization on the simulation verification model to generate a manufacturing process data packet of the microsystem. According to the method provided by the invention, the whole process from the operation requirement of the target microsystem to the construction of the microsystem entity can be realized through different digital prototypes. Therefore, the finally constructed microsystem entity can meet the operation requirement of the target microsystem, the time spent on debugging the entity for multiple times is avoided, the product research and development cycle is shortened, and the research and development efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of integrated microsystems, and more particularly to a method and apparatus for constructing a microsystem based on a digital prototype. Background Technology

[0002] Heterogeneous integrated microsystems (HIMS) technology integrates sensing, processing, communication, and power functions into a single microscale device by fusing elements of microelectronics, microphotonics, and microelectromechanical systems (MEMS). This significantly increases the functional density of electronic systems and represents a crucial development direction for current electronic systems. However, with increasing integration density, microsystem development involves deep interdisciplinary collaboration. A single microsystem often needs to implement multiple functions, and balancing various requirements with the resources occupied within the microsystem is one of the challenges in microsystem design. Furthermore, current microsystem designs rely on manual physical verification, and the production and debugging of microsystems consume significant time. Therefore, there is an urgent need for a digital prototyping method adapted to the characteristics of microsystems, which can comprehensively consider multiple requirements and improve design efficiency in microsystem design. Summary of the Invention

[0003] This disclosure provides a method and apparatus for constructing a microsystem based on a digital prototype, which can be used to comprehensively design a microsystem according to actual needs and improve design efficiency.

[0004] In view of the above problems, firstly, embodiments of this disclosure provide a method for constructing a microsystem based on a digital prototype, including: Based on the operational requirements of the target microsystem, a functional architecture diagram model representing the functions of the microsystem is constructed according to a preset transformation logic; wherein, the transformation logic is the progressive mapping relationship between the operational requirements of the microsystem, the system capability items of the microsystem, and the functions of the microsystem. The functional architecture diagram model is assigned functions according to the design constraints of the target microsystem, and mapped to generate a logical architecture diagram model. Based on the logical architecture diagram model, a physical architecture diagram model is generated through component mapping, and a chip component model is generated according to the component selection requirements of the microsystem. The physical architecture model is instantiated based on the chip component model to obtain the simulation verification model; Based on the simulation verification model, multiphysics simulation optimization is performed, and manufacturing process data packages for the microsystem are generated based on the optimization results. The test data of the test microsystem entity is obtained, and the test data is compared with the system capability items of the target microsystem. The functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model is adjusted according to the comparison results until the test data meets the system capability items of the target microsystem, thereby obtaining the target microsystem design scheme; wherein, the test microsystem entity is a microsystem entity manufactured according to the manufacturing process data package.

[0005] In conjunction with the first aspect, in one possible implementation, the construction of a functional architecture diagram model representing the functions of the microsystem based on the operational requirements of the target microsystem and according to a preset transformation logic includes: Modeling is performed based on the operational requirements of the target microsystem, defining the interaction behavior between the main body of the target microsystem and the external environment, and generating a standardized operational model; The interactive behaviors in the standardized operation model are clustered, and system capability items that characterize the functional features of the target microsystem are extracted from the clustered interactive behaviors to obtain a list of system capability items of the target microsystem and the performance parameters of each system capability item. The system capability items are decomposed into multiple atomic requirement items and corresponding functional nodes; Based on the aforementioned requirement items, a structured requirement specification document is obtained. For each requirement item in the requirement specification document, a traceability relationship is established according to the corresponding functional nodes, system capability items, interactive behaviors, and operational requirements to construct a requirement traceability matrix. Based on the functional transfer relationships between the functional nodes, each functional node is connected into a functional chain to obtain a functional architecture diagram model representing the function of the target microsystem.

[0006] In conjunction with the first aspect, in one possible implementation, the step of allocating functions to the functional architecture diagram model according to the design constraints of the target microsystem and mapping it to generate a logical architecture diagram model includes: Based on the functions corresponding to each functional node in the functional architecture diagram model, the logical components that carry the functions through built-in logical strategies are obtained, and a component mapping relationship is established between the functional nodes and the logical components. Define the input and output ports of each logical component, and transform the functional transmission relationship between functional nodes in the functional architecture diagram model into the interaction protocol and interaction logic between logical components; The design constraints of the target microsystem are bound to each logical component, and microsystem resources are allocated to the logical components based on the design constraints; wherein, the design constraints of the target microsystem include at least one of the following: target performance parameters, target interface parameters, and target reliability parameters; the microsystem resources include at least one of the following: microsystem computing power, microsystem memory, and microsystem bandwidth; Based on the component mapping relationship and the result of microsystem resource allocation, the connection relationship between logical components is adjusted to generate a logical architecture diagram model.

[0007] In conjunction with the first aspect, in one possible implementation, the step of generating a physical architecture diagram model based on the logical architecture diagram model through component mapping, and generating a chip component model according to the component selection requirements of the microsystem, includes: Based on the mapping relationship between logical components and physical components, the logical components in the logical architecture diagram model are converted into physical components that implement the logical strategies of the logical components; Based on the design constraints bound to the logical components mapped by the physical components, a search and matching process is performed for each physical component in a preset chip component model library to select candidate components that meet the design constraints, and multiple chip component models are obtained based on combinations of different candidate components.

[0008] In conjunction with the first aspect, in one possible implementation, the step of instantiating the physical architecture diagram model based on the chip component model to obtain a simulation verification model includes: The parameter information of each component in each chip component model is updated to the corresponding physical component in the physical architecture diagram model; Based on the physical components in the updated physical architecture diagram model, a collaborative structural model containing the three-dimensional geometric features and spatial layout of the microsystem is constructed in the structural design environment. Based on the aforementioned collaborative structure model, a packaging and wiring design scheme for a microsystem is generated in an electronic design environment. Based on the aforementioned collaborative structure model and packaging and routing design scheme, multiple simulation verification models were obtained.

[0009] In conjunction with the first aspect, in one possible implementation, the step of performing multiphysics simulation optimization based on the simulation verification model and generating a microsystem manufacturing process data package based on the optimization results includes: For each simulation verification model, parameter configuration is performed, and the adjustable physical and electrical parameters in the simulation verification model are defined as design variables. Constraints in the multiphysics simulation optimization process are established based on the design constraints of the target microsystem, and the objective function of the multiphysics simulation optimization process is defined based on the predetermined target optimization direction. According to the preset multiphysics simulation optimization process, the simulation script is driven to obtain the simulation response of the simulation verification model under different design variables, and the simulation verification model is iterated under the constraints of the preset optimization algorithm until the preset optimization algorithm converges, and a Pareto optimal solution set containing the trade-off relationship of different objective functions is obtained. According to the aforementioned trade-offs, a target simulation verification model is selected from the Pareto optimal solution set, and a manufacturing process data package containing microsystem construction rules and microsystem production elements is generated based on the target simulation verification model.

[0010] In conjunction with the first aspect, in one possible implementation, the driving simulation script acquires the simulation response of the simulation verification model under different design variables, including: The simulation verification model is updated according to the values ​​of the design variables distributed by the preset optimization algorithm; The simulation solvers associated with the simulation verification model are invoked respectively to perform simulation physics field calculations on the updated simulation verification model; In the simulation physics calculation results, the performance index values ​​corresponding to the objective function are selected as the simulation response and fed back to the preset optimization algorithm.

[0011] In conjunction with the first aspect, in one possible implementation, the step of acquiring test data of the test microsystem entity, comparing the test data with the system capability items of the target microsystem, and adjusting the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model based on the comparison result includes: Obtain test data for the test microsystem entity; wherein the test data includes at least one of the following: physical characteristic data, functional response data, and operational performance data; Based on the deviation between the test data and the system capability items of the target microsystem, the source of the deviation is traced according to the correspondence between the test microsystem entities and the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model, respectively. Adjust the model elements in the physical architecture diagram, logical architecture diagram, or functional architecture diagram that caused the deviation based on the source tracing results.

[0012] In conjunction with the first aspect, in one possible implementation, the preset optimization algorithm includes at least one of the following: a genetic algorithm or a gradient optimization algorithm.

[0013] Secondly, embodiments of this disclosure provide a microsystem construction apparatus based on a digital prototype, comprising: The building module is used to construct a functional architecture diagram model representing the functions of the microsystem based on the operational requirements of the target microsystem and according to a preset transformation logic. The mapping module is used to allocate functions to the functional architecture diagram model according to the design constraints of the target microsystem and map it to generate a logical architecture diagram model. The selection module is used to generate a physical architecture model based on the logical architecture diagram model through component mapping, and to generate a chip component model according to the component selection requirements of the microsystem. The instantiation module is used to instantiate the physical architecture diagram model based on the chip component model to obtain the simulation verification model; The simulation module is used to perform multiphysics simulation optimization based on the simulation verification model and generate a manufacturing process data package for the microsystem based on the optimization results. The adjustment module is used to acquire test data of the test microsystem entity, compare the test data with the system capability items of the target microsystem, and adjust the functional architecture diagram model, logical architecture diagram model or physical architecture diagram model according to the comparison results until the test data meets the system capability items of the target microsystem, thereby obtaining the design scheme of the target microsystem.

[0014] The beneficial effects of the embodiments disclosed herein include: This disclosure provides a method and apparatus for constructing a microsystem based on a digital prototype, comprising: constructing a functional architecture diagram model representing the functions of the microsystem according to the operational requirements of the target microsystem and a preset conversion logic; wherein the conversion logic is a progressive mapping relationship between the operational requirements of the microsystem, the system capability items of the microsystem, and the functions of the microsystem; allocating functions to the functional architecture diagram model according to the design constraints of the target microsystem, and mapping it to generate a logical architecture diagram model; generating a physical architecture diagram model based on the logical architecture diagram model through component mapping, and generating a chip component model according to the component selection requirements of the microsystem; instantiating the physical architecture diagram model according to the chip component model to obtain a simulation verification model; performing multiphysics simulation optimization based on the simulation verification model, and generating a manufacturing process data package for the microsystem according to the optimization results; acquiring test data of the test microsystem entity, comparing the test data with the system capability items of the target microsystem, and adjusting the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model according to the comparison results until the test data meets the system capability items of the target microsystem, thereby obtaining a design scheme for the target microsystem; wherein the test microsystem entity is a microsystem entity manufactured according to the manufacturing process data package. The method provided in this disclosure enables end-to-end design from operational requirements to microsystem product. This method utilizes various digital prototypes to achieve the entire process from meeting the operational requirements of the target microsystem to constructing the microsystem entity. By transforming operational requirements into a functional architecture diagram model, this method provides a basis for the subsequent construction of the microsystem entity. Furthermore, a simulation verification model is built based on the functional architecture diagram model, ensuring that the final constructed microsystem entity conforms to the operational requirements of the target microsystem. This avoids the time spent on multiple physical debugging sessions, helping to shorten the product development cycle and improve development efficiency. Attached Figure Description

[0015] Figure 1 A schematic flowchart illustrating a microsystem construction method based on a digital prototype, provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of the digital prototype partitioning provided in an embodiment of the present disclosure; Figure 3 A schematic diagram of the requirements analysis phase provided for embodiments of this disclosure; Figure 4 A schematic diagram of the overall design phase provided for embodiments of this disclosure; Figure 5 Detailed design phase flowchart provided for embodiments of this disclosure; Figure 6 This is a schematic diagram of the manufacturing verification stage process provided in an embodiment of the present disclosure; Figure 7 This is a schematic diagram of a microsystem construction device based on a digital prototype, provided as an embodiment of the present disclosure. Detailed Implementation

[0016] This disclosure provides a method and apparatus for constructing a microsystem based on a digital prototype. Preferred embodiments of this disclosure are described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustrative and explanatory purposes only and are not intended to limit the scope of this disclosure. Furthermore, the embodiments and features described herein can be combined with each other unless otherwise specified.

[0017] This disclosure provides a method for constructing a microsystem based on a digital prototype, such as... Figure 1 As shown, it can be implemented as follows: S101. Based on the operational requirements of the target microsystem, construct a functional architecture diagram model representing the functions of the microsystem according to the preset transformation logic. The conversion logic is a progressive mapping relationship between the microsystem's operational requirements, the microsystem's system capabilities, and the microsystem's functions. S102. The functional architecture diagram model is assigned functions according to the design constraints of the target microsystem, and mapped to generate a logical architecture diagram model. S103. Based on the logical architecture diagram model, a physical architecture diagram model is generated through component mapping, and a chip component model is generated according to the component selection requirements of the microsystem. S104. Instantiate the physical architecture diagram model based on the chip component model to obtain the simulation verification model; S105. Perform multiphysics simulation optimization based on the simulation verification model, and generate a microsystem manufacturing process data package based on the optimization results. S106. Obtain test data of the test microsystem entity, compare the test data with the system capability items of the target microsystem, and adjust the functional architecture diagram model, logical architecture diagram model or physical architecture diagram model according to the comparison results until the test data meets the system capability items of the target microsystem, and obtain the design scheme of the target microsystem. The test microsystem entity is a microsystem entity manufactured according to the manufacturing process data package.

[0018] In this embodiment of the disclosure, the target microsystem can be a microelectronic integrated circuit based on heterogeneous integrated microsystem technology, which can integrate components of different materials, processes and functions onto a single circuit and ultimately package them into a compact microsystem.

[0019] The digital prototype in this disclosure refers to a digital model built in a computer virtual environment that realistically reflects the physical dimensions, physical properties, functional behavior, and technological characteristics of a microsystem entity. By assembling, testing, running, and optimizing the digital prototype in virtual space, the trial-and-error costs in the microsystem construction process can be reduced, and the development cycle can be shortened. Since microsystem design is an incremental process, a single digital prototype cannot simultaneously meet the verification needs of different development stages. Therefore, it is necessary to build multiple digital prototypes at different levels or with different focuses.

[0020] The construction process of the microsystem disclosed herein can be divided into four main stages: requirements analysis, overall design, detailed design, and manufacturing realization. For each stage, a separate system can be constructed as follows: Figure 2 The different digital prototypes shown.

[0021] Specifically, in the requirements analysis phase, the main focus is on building design-type digital prototypes to clarify the boundaries and design goals of the microsystem. This phase includes... Figure 3 The process can begin by constructing a standardized operational model for the microsystem. This model defines the stakeholders' needs for the microsystem and the interaction boundaries between the microsystem and the external environment. Simultaneously, a microsystem capability model, including system capability items, can be built to clarify the functional objectives and determine performance constraints of the microsystem in a black-box manner. At this stage, the target requirements can be structured through requirement items and mapped to the system capability items of the microsystem, constructing a requirement traceability matrix. This matrix is ​​used to trace back to the corresponding system capability items during further design and verification, facilitating adjustments or modifications to the microsystem's design.

[0022] In the overall design phase, such as Figure 4As shown, different capabilities can be decomposed into different functional nodes and functional chains obtained based on the interaction relationships between nodes, thereby constructing a functional architecture diagram model; then, by mapping the abstract functions in the functional architecture diagram model to specific logical components and clarifying the communication protocols and connection topologies between components, a logical architecture diagram model is obtained.

[0023] In the detailed design phase, such as Figure 5 As shown, manufacturing-like digital prototypes can be constructed to support the virtual verification and physical realization of microsystems. Through the physical architecture diagram model of the microsystem, the spatial mapping of logical components in the logical architecture diagram model to physical entities can be achieved, completing the design of 3D / 2D structures. Simultaneously, by instantiating the physical architecture diagram model using selected chip component models, and combining it with a collaborative structure model that finely defines the layout, routing, and key mechanical structures, a simulation verification model can be obtained. Based on this, multi-physics parameters such as electrical, thermal, and mechanical fields are introduced through simulation scripts to establish a co-simulation environment, allowing for the prediction and optimization of the microsystem's performance under various conditions.

[0024] During the manufacturing validation phase, such as Figure 6 As shown, digital prototypes for manufacturing and operation and maintenance support can be constructed to achieve a closed loop between the virtual environment and the real-world scenario. At the design end, manufacturing process data packages generated from simulation verification models can guide physical production. Based on the manufactured physical prototypes, test data models, hardware-in-the-loop simulation models, and real-world scenario data models can be constructed. Test results are integrated using the test data models to establish a performance baseline, and in-loop testing is conducted using the hardware-in-the-loop simulation model to simulate the microsystem's operation under different environments. The corresponding digital prototypes are then adjusted based on the test results. Furthermore, real-world deployment environment data can be collected based on the real-world scenario data models to construct a digital twin operation and maintenance model corresponding to the physical microsystem, providing data support for the continuous optimization and operation and maintenance support of the microsystem.

[0025] In summary, the method provided in this disclosure enables the entire process from meeting the operational requirements of a target microsystem to constructing the microsystem entity using different digital prototypes. This method transforms operational requirements into a functional architecture diagram model, providing a basis for the subsequent construction of the microsystem entity. Furthermore, a simulation verification model is built based on the functional architecture diagram model, ensuring that the final constructed microsystem entity conforms to the operational requirements of the target microsystem. This avoids the time spent on multiple physical debugging sessions, helping to shorten the product development cycle and improve development efficiency.

[0026] It should be noted that the executing entity of this disclosure can be a computer system with capabilities such as computing, simulation, signal transmission and reception, and data storage.

[0027] In another embodiment provided in this disclosure, the above step S101, "based on the operational requirements of the target microsystem, constructing a functional architecture diagram model representing the functions of the microsystem according to a preset conversion logic," can be implemented as follows: Step 1: Model the target microsystem according to its operational requirements, define the interaction behavior between the target microsystem and its external environment, and generate a standardized operational model. Step 2: Cluster the interactive behaviors in the standardized operation model, and extract system capability items that characterize the functional features of the target microsystem from the clustered interactive behaviors to obtain a list of system capability items of the target microsystem and the performance parameters of each system capability item. Step 3: Decompose the system capability items into multiple atomic requirement items and corresponding functional nodes; Step 4: Based on the aforementioned requirement items, obtain a structured requirement specification document. For each requirement item in the requirement specification document, establish a traceability relationship based on the corresponding functional nodes, system capability items, interactive behaviors, and operational requirements to construct a requirement traceability matrix. Step 5: Based on the functional transfer relationship between the functional nodes, connect each functional node into a functional chain to obtain a functional architecture diagram model representing the function of the target microsystem.

[0028] In this embodiment, the operational requirements of the target microsystem can be a textual description. Using a pre-defined text extraction method, the behavioral boundaries and environmental interactions of the target microsystem within the task scenario can be extracted from this text, clarifying the external participants and the core activity flow that the system needs to complete. For example, if the target microsystem is a multi-sensor analysis and processing payload microsystem applied to a UAV, it is necessary to clearly analyze the external data that needs to be collected under different working environments, the process of fusing and processing the collected external data, and the microsystem's response process to this data. This extraction process can be performed using a large language model with sentence analysis capabilities, or it can be based on the analysis of the requirement text using set keywords to obtain relevant information. This is only for illustration and is not a limitation.

[0029] Based on the extracted information, this information can be described as standardized statements that are easily recognized by computer systems, forming a standardized operating model. This modeling process can employ the logic of microsystem entities, environmental interactions, and dynamic behaviors, constructing different nodes according to construction rules and labeling each node with easily recognizable tagged statements as different elements in the standardized operating model. These construction rules are shown in Table 1 below.

[0030]

[0031] Table 1. Schematic diagram of standardized operation model construction rules As shown in Table 1, the content extracted from the operational requirements of the target microsystem can be mainly divided into three categories: microsystem subject category, microsystem-environment interaction specification category, and microsystem dynamic behavior specification category. The microsystem subject category can be further decomposed into the physical boundary definition of the microsystem to characterize its ability to operate at a specific size, the performance index quantification to characterize the realization capability of the microsystem's core performance, and the interface protocol standardization to characterize the microsystem's ability to access different signals. Furthermore, the physical boundary definition can be decomposed into nodes such as the microsystem's size constraints (e.g., the three-dimensional size range of the microsystem) and the microsystem's weight limits, serving as physical constraints of the microsystem. The weight limit of the microsystem can also be parameter-associated with the size constraints or other nodes to dynamically limit the current weight of the microsystem.

[0032] Performance metrics can be quantified and broken down into nodes such as power consumption requirements for the target microsystem (e.g., power consumption values ​​of the microsystem under different operating conditions), data processing capabilities of the microsystem (e.g., bandwidth and operating frequency of the microsystem), and reliability metrics of the microsystem (e.g., mean time between failures (MTBF) and failure rate parameters of the microsystem). Interface protocol standardization can define the electrical interfaces of the microsystem (e.g., power interface, data interface, and grounding port) and the data protocols used by these electrical interfaces.

[0033] The environmental interaction specifications of a microsystem can be decomposed into the environmental adaptability of the target microsystem and the interaction with external entities. Among them, environmental adaptability requirements can refer to the overall temperature and humidity range limitations and anti-interference capability requirements of the microsystem operation (e.g., electromagnetic compatibility protection (EMC) and electrostatic discharge protection (ESD)); external entity interaction includes the model of the participants in the interaction process (e.g., external interaction participants, the form of interaction interface, and the resources on which the interaction process depends).

[0034] The dynamic behavior specification of the target microsystem includes the temporal chain of tasks that the microsystem can perform, which may include explicit rules for task flows in response to abnormal situations.

[0035] Here is an example of a tagged statement generated based on requirements, which could be a microsystem applied to a drone payload.

[0036] «constraint»: 12×12×7mm; «param» weight = 4.2g; «mode» Active: 1.8W @25℃; ◇: 3.3V±5%; □: LVDS@14bit; «TimingConstraint»=10ms ±50μs; «reliability» MTBF=100,000hrs; «ParallelVideoProcessing»=4 channels; Sensor → Alignment («TimingConstraint» delay ≤2ms) → Fusion → Compression; Compression → «exception» Timeout → Degradation (Skip compression); «depend»Vibration Spectrum≤5g RMS; «constraint»Working Environment -20℃~65℃; In the above labels, «constraint»: 12×12×7mm means that the three-dimensional dimensions of the microsystem are limited to no more than 12 mm in length, 12 mm in width, and 7 mm in height; «constraint» is a restriction label. «param» weight = 4.2g means that the weight of the microsystem is limited to no more than 4.2 grams; «param» is a parameter label. «mode» Active: 1.8W@25℃ means that the maximum power consumption of the microsystem in operating mode is 1.8 watts at 25 degrees Celsius; ◇: 3.3V±5% means that the input voltage of the power interface is 3.3 volts, with a permissible deviation of... ◇ indicates the power interface; □: LVDS@14bit means the microsystem's data interface uses a Low-Voltage Differential Signaling (LVDS) interface with a 14-bit data width; «TimingConstraint»=10ms ±50μs means the microsystem's timing constraint is 10 milliseconds, with an allowable deviation of... 50 microseconds; «reliability» MTBF=100,000hrs means the microsystem's average MTBF time is no less than 100,000 hours, and «reliability» is a reliability label; «ParallelVideoProcessing»=4 channels means the microsystem needs to have four channels of parallel video processing capability; "Sensor → Alignment («TimingConstraint» Delay ≤2ms) → Fusion → Compression" means the microsystem needs to be able to receive sensor data and perform timing alignment, data fusion, and data compression on the received sensor data. During timing alignment, the delay needs to be less than 2 milliseconds; "Compression → «exception» Timeout → Degradation (Skip Compression)" indicates that the microsystem needs to have a compression exception handling process. When the data compression process times out, the data compression process can be skipped; «depend» Vibration Spectrum ≤5g RMS means the maximum value of the root mean square (RMS) of the overall vibration acceleration of the microsystem does not exceed 5 times the gravitational acceleration; «constraint» Working Environment The meaning of -20℃~65℃ is that the microsystem needs to be able to work normally between -20 degrees Celsius and 65 degrees Celsius.

[0037] It should be noted that these tagged statements can be set according to the actual situation of the computer system, and the language and the corresponding meaning of the tags can be adjusted according to the actual situation. There are no restrictions here.

[0038] Furthermore, different interactive behaviors in the standardized operation model can be used as elements of the standardized operation model. Based on the specific meaning of these elements, they can be clustered and transformed according to certain rules to extract system capability items that characterize the key functional features of the target microsystem, and a microsystem capability model can be obtained based on this. This transformation process can be shown in Table 2 below.

[0039]

[0040] Table 2. Schematic diagram of conversion between standardized operation model and microsystem capability model Before conversion, the elements of the standardized operating model can be clustered. Activities with similar functions and consistent goals can be clustered and then converted into a single capability item. For example, activities such as "receiving infrared sensor data," "receiving visible light sensor data," and "synchronizing data in time" can be clustered into "multi-source data synchronous acquisition capability." During the conversion to obtain system capability items, the division of system capability items should consider the coupling of the physical implementation of the microsystem entity. Activities with high cohesion and low coupling characteristics should be clustered and converted into the same capability item as much as possible to reduce the data exchange and synchronization overhead between chips and components in the subsequent physical architecture. For example, if the "image preprocessing" and "feature extraction" capabilities have extremely frequent data interaction, they should be considered for merging into a "visual information processing" capability, which may later be implemented by a single component.

[0041] Furthermore, the content of the input and output data for each system capability can be defined. When defining the interfaces between system capability items, priority should be given to the unification of communication protocols and the fusion of different data. The number of different protocols and data streams should be minimized to simplify the interfaces in subsequent physical implementations and conserve microsystem resources. For example, for data streams from multiple sensors (e.g., infrared sensors, visible light sensors, and radar sensors) obtained by the microsystem, priority should be given to fusing these data streams into a single data stream with unified timestamps and coordinate frames, rather than separate multi-channel streams.

[0042] For each system capability, the performance parameter values ​​must be determined based on the constraints of the microsystem. The formulation of performance parameters must strike a balance among multiple constraints to avoid contradictory or unattainable capability requirements. For example, when defining the capability "the microsystem's target recognition accuracy should be ≥95%", constraints imposed by other capability requirements, such as "the microsystem's power consumption for processing a single frame of image should be ≤1W" and "the microsystem's signal processing delay should be ≤50ms," must be considered simultaneously to avoid conflicts between accuracy requirements, power consumption requirements, and signal delay requirements.

[0043] When defining capabilities, focus should be placed on describing the objectives and performance parameters of the capability, avoiding details about specific algorithms, protocols, or hardware models. This prevents the microsystem architecture from being tied to a single technology path and allows for flexible selection of the optimal solution based on cost and technology maturity. For example, a capability should be defined as "providing location navigation capability" rather than "providing Global Positioning System (GPS) navigation capability," to reserve design space for using alternative navigation methods in GPS-denied environments.

[0044] After converting all elements of the standardized operating model into system capability items to obtain the system capability model, each capability item and performance parameter can be output in the form of a capability item list based on the system capability model. This allows the capability list to be read in subsequent processes to obtain each capability item and its corresponding performance parameters.

[0045] After converting each element of the standardized operating model into a corresponding system capability item and obtaining the system capability model, each system capability item can be decomposed into requirement items and functional nodes.

[0046] The system capability items are refined by detail, with each requirement item corresponding to a single, verifiable function or characteristic within that capability item. For example, the requirement item "The system should acquire Inertial Measurement Unit (IMU) data and send it to the processing module" should be broken down into two requirements: "The system should complete IMU data acquisition within 10 milliseconds" and "Send the IMU data to the processing module." Each requirement item needs to be testable, and its fulfillment can be determined through specific test cases or verification methods. For example, the requirement item "The IMU's measurement accuracy should be better than ±0.5 degrees / second" can be verified by the end-to-end delay of data packet transmission. Each requirement item can be assigned a unique, stable, and easily identifiable identifier to indicate its hierarchy within the microsystem (e.g., overall system requirement hierarchy, sensor requirement hierarchy, or processing module sub-requirement hierarchy). Attribute information, such as requirement type, priority, status, and source, can also be added to each requirement item.

[0047] Furthermore, each requirement item can be explicitly traced forward (to the system capability model and standardized operating modules) and backward to its corresponding model. This clarifies which system capability item and operational requirement the item originates from, which structures and components subsequently implemented the requirement item, and which tests validated the item, establishing traceability relationships along the way. Through these traceability relationships, the requirement items can be structured into a top-level requirement traceability matrix, which can be further expanded into a traceability network encompassing all digital prototypes as the microsystem construction process progresses.

[0048] Because system capability items in a microsystem capability model are black-box descriptions of the system-level goals of the microsystem, while functions are white-box implementation methods of different capabilities, multiple functional nodes are obtained by decomposing system capability items. During the decomposition of system capability items, the complete task flow corresponding to each system capability item can be atomically atomized into an independent, verifiable function; and the content of each functional node is testable and its relationships can be traced. Based on the logical relationships between different functional nodes, functional chains can be established between them.

[0049] Furthermore, each functional node needs to inherit attributes of the system's capabilities, such as performance constraints (e.g., latency or detection range), interface protocols, application modes, and failure modes (e.g., switching to a visible light sensor when the infrared sensor fails). Further, connections are established between different functional nodes to form functional chains, creating a functional architecture diagram model. This model includes not only the functional nodes and the functional chains between them, but also verification methods for validating the functionality of each node. An example of the construction rules for the functional architecture diagram model is shown in Table 3 below.

[0050]

[0051] Table 3. Schematic diagram of functional architecture model construction rules As shown in Table 3, the ability of a microsystem to be applied in a specific scale of space, as defined in the system capability section, can be decomposed into functional nodes representing the physical boundaries and upper limits of thermal density of the microsystem. These functional nodes can serve as constraints for selection and layout in subsequent design processes and can be verified through 3D modeling using AutoCAD software. The thermal management capability of the microsystem corresponds to the heat dissipation functional node, which can be verified by establishing a thermal resistance network model of the microsystem using ANSYS Icepak software and performing verification under different operating states. The electromagnetic compatibility capability of the microsystem corresponds to the crosstalk suppression functional node, which can be verified hierarchically through field-circuit co-simulation of the microsystem using CST Studio software. The reliability of the microsystem corresponds to the vibration tolerance functional node, which can be verified by simulating the fatigue life of the microsystem using Abaqus software. The interface capability of the microsystem is decomposed into functional nodes representing a unified multi-sensor data protocol, functional nodes maintaining consistent sampling rates, and functional nodes representing composite interactions.

[0052] In another embodiment provided in this disclosure, the above step S102, "allocating functions to the functional architecture diagram model according to the design constraints of the target microsystem, and mapping it to generate a logical architecture diagram model," can be implemented as follows: Step 1: Based on the functions corresponding to each functional node in the functional architecture diagram model, obtain the logical components that carry the functions through built-in logical strategies, and establish a component mapping relationship between functional nodes and logical components; Step 2: Define the input and output ports of each logical component, and transform the functional transmission relationship between functional nodes in the functional architecture diagram model into the interaction protocol and interaction logic between logical components; Step 3: Bind the design constraints of the target microsystem to each logical component, and allocate microsystem resources to the logical components based on the design constraints; The design constraints of the target microsystem include at least one of the following: target performance parameters, target interface parameters, and target reliability parameters; the microsystem resources include at least one of the following: microsystem computing power, microsystem memory, and microsystem bandwidth. Step 4: Based on the component mapping relationship and the result of microsystem resource allocation, adjust the connection relationship between logical components to generate a logical architecture diagram model.

[0053] In this embodiment, based on the function implemented by each functional node, a corresponding logical component can be determined for each functional node, allowing the logical component to carry the function through a built-in logical strategy. This establishes a component mapping relationship between functional nodes and logical components, enabling the replacement of functional nodes in the functional architecture diagram model with logical components based on this mapping relationship. The functional chain representing the functional transmission relationship between functional nodes can be converted into interaction protocols and interaction logic between logical components. Furthermore, branch nodes between functional nodes can be labeled to represent task flows such as abnormal task chains of redundant interfaces. Simultaneously, microsystem design constraints inherited by functional nodes from system capability items can be bound to the corresponding logical components.

[0054] By mapping functions to logical components and defining interaction protocols and redundancy mechanisms between these components, preliminary resource budgeting and allocation (e.g., computing power, memory, and bandwidth of the microsystem) can be performed, and dependencies and potential conflicts between logical components can be identified, thus completing the logical architecture diagram model of the microsystem. The construction rules for the logical architecture diagram model are shown in Table 4 below.

[0055]

[0056] Table 4. Schematic diagram of the construction rules for the logical architecture model. As shown in Table 4, logical components that implement corresponding logical strategies can be obtained for each functional node. For example, if the function of a certain functional node is "to perform data fusion processing", the corresponding logical component can be "data fusion processor component". This component can be further labeled using tagged statements, and inherited design constraints can be bound to it. Resources obtained by this logical component in the microsystem can be allocated according to the design constraints. This allocation process can be determined based on the importance of the function implemented by each functional node in the microsystem. For logical components corresponding to functional nodes with high importance, more resources can be allocated to them.

[0057] Functional chains between functional components can be defined by defining the interfaces of logical components. The functional exchange process of the corresponding functional chain components can be converted into logical inputs and outputs of the logical components, thus obtaining the interaction protocol and logic between components. For example, in the table above, MIPI-CSI2@1.5Gbps±5% jitter indicates that a high-speed serial interface (MIPI-CSI-2) is used as the interaction protocol between two logical components, and the interaction rate needs to reach 1.5Gbps with signal jitter not exceeding ±5%. Furthermore, the direction of signal transmission can be used to characterize the interaction logic.

[0058] In addition, control nodes can be set between the interfaces of logic components to correspond to abnormal task flows in the standardized operating model. As shown in the example in the table above, "if temperature > 85℃ then enable frequency reduction pin" means that if the temperature of the microsystem is greater than 85 degrees Celsius, it needs to enter the frequency reduction task flow and enable the chip's frequency reduction pin to work.

[0059] Through the above process, an architecture diagram model representing the working logic of the microsystem can be obtained based on logical components, component interaction protocols and interaction logic, redundant interface enable conditions, design constraints bound to each component, and microsystem resources allocated.

[0060] In another embodiment provided in this disclosure, step S103 above, "generating a physical architecture model based on the logical architecture diagram model through component mapping, and generating a chip component model according to the component selection requirements of the microsystem," can be implemented as follows: Step 1: Based on the mapping relationship between logical components and physical components, convert the logical components in the logical architecture diagram model into physical components that implement the logical strategies of the logical components; Step 2: Based on the design constraints bound to the logical components mapped by the physical components, search and match each physical component in the preset chip component model library, filter out candidate components that meet the design constraints, and obtain multiple chip component models based on combinations of different candidate components.

[0061] In this embodiment, based on the logic strategy carried by the logic component, a physical component implementing that logic strategy can be selected accordingly. Based on the type of the physical component, and using the bound design constraints as search elements, multiple corresponding candidate components are retrieved from a pre-defined chip component model library for each physical component. This subsequent component is then determined as a selection for the corresponding logic component. Different combinations of components can form different versions of microsystem design schemes, serving as alternative schemes for subsequent simulation testing and optimization. For each alternative method, a chip component model including a list of candidate components and the correspondence between candidate components and physical components is output.

[0062] The process of converting a logical architecture diagram model into a physical architecture diagram model can be carried out using the rules shown in Table 5 below.

[0063]

[0064] Table 5. Schematic diagram of physical architecture model construction rules Based on Table 5 above, for different physical components in the physical architecture diagram, the component selections for those physical components can be labeled accordingly. For example, for the processor component, based on the selected Jetson Orin NX component, the corresponding physical component can be labeled as "Processor Component Jetson Orin NX". Furthermore, based on the microsystem resources reserved for logic components, the resource allocation for physical components can be determined according to assembly tolerances, thermal expansion effects, and safety redundancy, and the allocated resources for the corresponding physical components can be labeled (e.g., dimension labeling). Components that can be material-selected can also be labeled with corresponding material tags. For example, in Table 5, «Material» AlSiC (CTE≤8ppm / ℃) indicates that the material of this component is silicon carbide aluminum, and the coefficient of thermal expansion (CTE) is less than 8ppm / ℃. «Material» can be a material attribute label. In addition, the mapping relationship between physical components and logic components can be labeled accordingly. For example, the mapping between logic components and physical components can be clearly defined through nested components. This method establishes an allocation relationship between the two, ensuring that each logical component has a corresponding hardware support, preventing hardware misuse or omission, and providing traceability evidence in subsequent verification processes.

[0065] Similarly, based on the component interaction protocol and interaction logic, the hardware interface standard of the physical component can be obtained, thereby completing the transformation and constraint from logical definition to physical entity in terms of connection relationship. Specifically, the interaction protocol defined in the logical component (such as MIPI-CSI2) can be marked in detail in the physical component as a specific physical interface form. For example, "FPC connector @ 0.5mm pitch" indicates that the physical interface is a flexible printed circuit (FPC), and the pitch of the metal pins of the circuit is 0.5 mm, thus clarifying the form and space occupation of the physical connection. On this basis, the electrical characteristic indicators of the interface can be further marked. For example, it can be specified that the physical interface design must meet "impedance matching ±10%" and the eye diagram of the interface must conform to a specific "eye diagram template".

[0066] The enabling conditions for redundant interfaces can be converted into fault-tolerant designs in the physical architecture diagram model. This requires annotation to associate the fault-tolerant decision logic with the specific physical components that execute it. For example, in Table 5, the logical judgment condition "temperature > 85℃" can be implemented through the specific physical component "thermistor + MOSFET cutoff circuit" (i.e., temperature is sensed by the thermistor and cut off by the metal-oxide-semiconductor field-effect transistor (MOSFET)).

[0067] Furthermore, power consumption and heat dissipation constraints bound to logic components can be converted into thermal management schemes configured for different physical components in the physical architecture diagram. The physical architecture diagram clearly defines the specific heat dissipation structure and performance of each physical component. For example, the heat dissipation structure of a physical component can be labeled with specific physical structure parameters such as "copper pillar array (diameter 0.3mm, spacing 0.5mm)" or selected as a "microchannel liquid cooling" scheme, and its "heat dissipation capacity per unit volume (W / cm³)" can be quantified. Simultaneously, the specific locations of temperature monitoring points can also be marked within the physical components.

[0068] Furthermore, the EMC constraints inherited and bound by logical components can be converted into electromagnetic protection design schemes for physical components in the physical architecture diagram, which can be marked as electromagnetic protection requirements and corresponding physical protection scheme designs.

[0069] For the process constraints bound to logic components, these can be converted into manufacturing requirements for physical components. Key manufacturing information can be output through attribute annotations: on the one hand, a Bill of Materials (BOM) table containing information such as the model number of the corresponding component, delivery cycle, and alternative solutions can be output to ensure supply chain security; on the other hand, integration process specifications can be clearly defined, such as annotating physical components with "solder joint fatigue life > 1E6 cycles" and specifying the use of "SAC305 solder," etc. This provides guidance for production and manufacturing, ensuring that the final physical product can meet the expected high reliability and manufacturing yield.

[0070] After completing the above selection and component conversion labeling process, a physical architecture model and a corresponding bill of materials, including a list of components, can be obtained to guide the subsequent design verification process.

[0071] In another embodiment provided in this disclosure, the step S104 above, "instantiating the physical architecture diagram model based on the chip component model to obtain the simulation verification model," can be implemented as follows: Step 1: Update the parameter information of each component in each chip component model to the corresponding physical component in the physical architecture diagram model; Step 2: Based on the physical components in the updated physical architecture diagram model, construct a collaborative structural model in the structural design environment that includes the three-dimensional geometric features and spatial layout of the microsystem. Step 3: Based on the aforementioned collaborative structure model, generate a microsystem packaging and wiring design scheme in the electronic design environment; Step 4: Based on the collaborative structure model and the packaging and routing design scheme, multiple simulation verification models are obtained respectively.

[0072] In this embodiment of the disclosure, various software programs can be invoked to model the microsystem, and the microsystem can be modeled according to the bill of materials corresponding to each physical architecture model.

[0073] Specifically, the parameters of the selected components can be bound and updated to the corresponding physical components. Based on the mass, center of gravity, moment of inertia, and material properties (e.g., density and thermal conductivity) of these physical components, a 3D solid model, including packaging, pins, and heat sink, is created for each component in a structural design environment using computer-aided design software (e.g., SolidWorks, NX, or Creo). According to the size and space requirements of each component (e.g., a clearance must be left around the component), no-layout zones are defined in the model using design rules (e.g., prohibiting the placement of ultra-tall components within 1mm around a Ball Grid Array (BGA) chip). Through this modeling process, all physical components in the physical architecture diagram are linked to the assemblies in the computer-aided design software, serving as the geometric reference and constraint source for all subsequent designs. Traceability can be ensured by associating physical components with component part numbers during this process.

[0074] Based on the co-structure model, functional structures with localized electromagnetic susceptibility can be modeled in an electronic design environment according to component dimensions and electrical performance requirements, ensuring subsequent simulation performance. During this process, detailed modeling of component and chip packages, bonding wires, and pins can be performed using electronic design automation software (e.g., CST Studio Suite or ANSYS HFSS). The accuracy of this modeling directly determines the accuracy of the simulation. Ports between components can also be defined, and by setting port and boundary conditions, realistic drives and loads can be simulated. Throughout this process, the microsystem's shape, keep-away areas, mounting holes, and connector positions remain consistent with the co-structure model. Furthermore, software such as ANSYS SIwave or Cadence Sigrity can be used to model traces, vias, and connectors between components based on the defined interface protocol's electrical specifications and physical structure. This allows for the construction of a complete interconnection channel model from one component pin to another, including chip packaging, traces, vias, and connectors. Through this modeling process, timing and delay constraints in the logic architecture model can be presented as routing rules to obtain the corresponding package routing design scheme.

[0075] Furthermore, computer-aided engineering software (such as ANSYS Icepak or FloTHERM) can be used to set the heat dissipation performance of each component based on its size, power consumption under various modes, thermal resistance, and material properties. During this modeling process, complex components can be simplified into models with dual thermal resistances, or their thermal characteristics can be described using compact thermal models, thereby improving simulation efficiency. Specifically, thermal resistance parameters and power consumption data can be set as simulation inputs for each component, and the heat conduction method, material, and thermal conductivity of the component's heat dissipation components can be defined.

[0076] It should be noted that during the modeling process, multiple models with different levels of precision can be built according to the needs of the simulation. For example, models built for system-level simulations (such as simulations of the heat dissipation of the entire microsystem or the overall electrical performance of the microsystem) can be modeled as compact models to improve computational efficiency. For 3D geometry and the internal structure of the microsystem, more refined models can be built to ensure the reliability of the simulation results. All models built in this process can be exported using a neutral format conforming to the product model data exchange standard to ensure data compatibility across different software tools. This allows key parameters of different models (such as size, power consumption, or thermal resistance) to be associated with design constraints in the logic architecture diagram, physical architecture diagram, and component selection, ensuring correspondence and traceability between models. For example, the model of each component in the collaborative structure model can be associated with the corresponding component in the bill of materials.

[0077] In the aforementioned modeling process, when electrical performance, heat dissipation, and mechanical layout conflict, spatial layout can be prioritized, and adaptive optimization of the drive electrical and heat dissipation designs can be performed, provided that basic performance requirements are met. Furthermore, during the modeling process, adjustments and construction of corresponding models can be carried out collaboratively and iteratively across different models, avoiding contradictions between them.

[0078] The above modeling process can yield multiple simulation verification models that integrate the physical architecture, electrical performance, and thermodynamic performance of the microsystem. These models can then be used to verify the performance of the microsystem through simulation optimization and iterative optimization.

[0079] In another embodiment provided in this disclosure, the step S105 above, "performing multiphysics simulation optimization based on the simulation verification model and generating a microsystem manufacturing process data package based on the optimization results," can be implemented as follows: Step 1: Configure parameters for each simulation verification model, define the adjustable physical and electrical parameters in the simulation verification model as design variables, establish the constraints in the multiphysics simulation optimization process according to the design constraints of the target microsystem, and define the objective function of the multiphysics simulation optimization process according to the predetermined target optimization direction. Step 2: Following the preset multiphysics simulation optimization process, drive the simulation script to obtain the simulation response of the simulation verification model under different design variables, and iterate the simulation verification model under the constraints of the preset optimization algorithm until the preset optimization algorithm converges, and obtain the Pareto optimal solution set containing the trade-off relationship of different objective functions. Step 3: Select a target simulation verification model from the Pareto optimal solution set according to the trade-off relationship, and generate a manufacturing process data package containing microsystem construction rules and microsystem production elements based on the target simulation verification model.

[0080] In this embodiment of the disclosure, multi-physics simulation optimization can achieve multi-objective collaborative optimization to ensure that the final generated microsystem achieves the optimal balance between performance, reliability and manufacturability in the manufacturing process data package.

[0081] Based on the established simulation verification model, key geometric features, material properties, and electrical parameters of the microsystem can be parameterized to form unified design variables. Simultaneously, design constraints, such as hard limits on temperature, deformation, cost, and electrical performance, can be inherited from the physical architecture diagram. Objective functions can be defined according to system-level optimization goals, such as minimizing total system weight, minimizing total power consumption, and maximizing signal-to-noise ratio.

[0082] Furthermore, simulation scripts can integrate multidisciplinary simulation optimization tools into a simulation toolchain, and automated simulation scripts can drive the processes of parameter updates, simulation submission, and result extraction. Initial sampling of simulation verification models with different design variables is performed using optimization algorithms such as design of experiments or Monte Carlo methods to analyze the sensitivity of the objective function. Subsequently, multi-objective genetic algorithms or gradient optimization algorithms are used for automatic optimization. In this process, multiple competing objectives are optimized in parallel under the condition of satisfying design constraints until convergence, generating a Pareto optimal solution set to demonstrate the trade-offs between different simulation verification models.

[0083] In the above process, the simulation script can call different simulation verification models and enter different simulation software as needed to obtain different simulation responses of the microsystem, thereby verifying different performance characteristics of the microsystem. It should be noted that... The final solution is selected from the Pareto optimal solution set based on the priority of different objective functions, and a manufacturing process data package is generated accordingly. The manufacturing process data package may include production documents such as photoplotting files and assembly drawings obtained from the target simulation verification model; process documents such as process specifications and work instructions; quality documents such as inspection procedures and test procedures; and auxiliary documents such as bill of materials.

[0084] In another embodiment provided in this disclosure, step 2 above, "the driving simulation script obtains the simulation response of the simulation verification model under different design variables," can be implemented as follows: Step 1: Update the simulation verification model according to the design variable values ​​distributed by the preset optimization algorithm; Step 2: Call the simulation solvers associated with the simulation verification model to perform simulation physics field calculations on the updated simulation verification model; Step 3: In the simulation physics calculation results, select the performance index values ​​corresponding to the objective function as the simulation response and send them back to the preset optimization algorithm.

[0085] In this embodiment, the preset optimization algorithm can be a genetic algorithm. When the genetic algorithm randomly generates and distributes a new set of design variables (i.e., a possible solution), the simulation script first automatically updates the corresponding parameters of the simulation verification model. Subsequently, a dedicated simulation solver associated with the model (such as a thermodynamic or electromagnetic solver) is invoked to perform multiphysics calculations on the updated model and obtain detailed performance data. Finally, the simulation script extracts performance indicators directly related to the optimization objective function (such as minimizing power consumption or maximizing signal-to-noise ratio) from the simulation results output by these solvers and feeds them back to the genetic algorithm as simulation responses. The genetic algorithm then calculates its fitness based on these indicators and performs the next iterative optimization.

[0086] In another embodiment provided in this disclosure, step S106 above, "obtaining test data of the test microsystem entity, comparing the test data with the system capability items of the target microsystem, and adjusting the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model according to the comparison result," can be implemented as follows: Step 1: Obtain the test data of the test microsystem entity; The test data includes at least one of the following: physical characteristic data, functional response data, and operational performance data; Step 2: Based on the deviation between the test data and the system capability items of the target microsystem, trace the source of the deviation according to the correspondence between the test microsystem entities and the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model, respectively. Step 3: Adjust the model elements in the physical architecture diagram model, logical architecture diagram model, or functional architecture diagram model that caused the deviation based on the source tracing results.

[0087] In this embodiment, after obtaining the target simulation verification model, the various data from the target simulation verification model can be integrated into a manufacturing process data package. This data package may include the bill of materials (BOM) for the microsystem components, assembly process instructions, test procedures, and manufacturing data files. The BOM may include the model numbers of the components in the simulation verification model, and the assembly process instructions may include the selected packaging method and chip manufacturing process for the microsystem. The test procedures include relevant simulation tests performed on the microsystem and the test results. The manufacturing process data package may include image data files (e.g., photoplot files) of the microsystem's printed circuit board. Through the manufacturing process data package, operational guidelines and detailed specifications and requirements can be provided for the microsystem's production process, ensuring that the manufactured microsystem product is consistent with the simulation verification model in terms of performance, functionality, and reliability.

[0088] After producing the physical entity of the target microsystem according to the manufacturing process data package, the physical microsystem can be further tested, including: basic laboratory testing, hardware-in-the-loop simulation testing, and real-world scenario testing. Finally, based on the test results, deviation analysis and iteration are performed to obtain the final microsystem product.

[0089] During basic laboratory testing, microsystem products can undergo tests on electrical performance (e.g., signal integrity, power integrity, and interface protocol compliance), power consumption metrics (e.g., power consumption in various operating states), basic performance (e.g., communication bit error rate, startup time, reset timing, and firmware loading success rate), and environmental adaptability (e.g., baseline performance of basic functions at room temperature). The purpose of testing is to verify the performance parameters of the microsystem as an independent component in a controlled laboratory environment, ensuring that its hardware implementation is consistent with the simulation verification model. This process can confirm the functional correctness of the microsystem (e.g., verifying whether the basic functions of the microsystem (such as power supply, communication, and control) work as expected), performance compliance (e.g., testing whether its performance parameters (such as signal quality, power consumption, and response speed) meet design specifications), and consistency checks (e.g., checking whether the performance of mass-produced microsystem products is consistent).

[0090] The basic laboratory testing process can be carried out in a pre-built testing environment with a testing accuracy greater than the design requirements. Based on the set test cases, various data of the microsystem product are collected by the instruments, and finally, by comparing them with the target requirements, the final physical characteristic data of the microsystem product are obtained.

[0091] In hardware-in-the-loop (HIL) simulation testing, communication with the microsystem product can be achieved through a pre-built simulation environment. This environment, centered on a real-time simulation host, runs dynamic environment models, sensor models, and scene generators to simulate various external input signals to the microsystem. The timing and delay of the external input signals must meet the real-time requirements of the microsystem, and their electrical characteristics, protocols, and data formats must conform to the microsystem product's interface specifications for external signals.

[0092] The simulation host generates and acquires physical signals through dedicated interface boards, and performs necessary signal conditioning to convert digital quantities into real physical signals that the microsystem can receive. All external interfaces of the microsystem product are connected to corresponding interface boards and placed under equivalent real electrical loads to form a complete experimental environment.

[0093] In this environment, the simulation host injects excitation signals into the microsystem, simultaneously acquiring the microsystem's output response in real time and driving the simulation scene state update, forming a dynamic real-time closed loop. This verifies the microsystem's functional logic and evaluates its real-time performance. Furthermore, by injecting boundary conditions and fault modes, the robustness and fault tolerance of the microsystem can be tested, yielding functional response data for the microsystem product.

[0094] Practical application testing allows for the testing of microsystem products in real-world environments to verify whether the product can meet the operational requirements of the target microsystem. This process involves collecting performance data of the microsystem product and the platform carrying it in real-world tasks, comparing it with target performance data to verify whether the microsystem product's capabilities meet the standards, and obtaining the actual failure intervals and degradation patterns of the microsystem under real-world environmental stresses (such as temperature, vibration, and electromagnetic interference) and workloads to assess its reliability and lifespan, ultimately obtaining operational performance data for the microsystem.

[0095] Based on the obtained test data, traceability analysis can also be performed. According to the requirement traceability matrix, multiple models in the design process can be adjusted in a coordinated manner, thereby forming a closed-loop design process from physical feedback to model, so as to improve the design accuracy of subsequent projects.

[0096] In another embodiment provided in this disclosure, the preset optimization algorithm includes at least one of the following: a genetic algorithm or a gradient optimization algorithm.

[0097] In this embodiment of the disclosure, when a genetic algorithm is used, the optimization process can first construct an initial population based on design variables, and then use a preset fitness function to verify the fitness value of each individual in the population through simulation. The next generation population is generated through selection, crossover and mutation operations, and the process is iterated until a preset stopping condition is met (e.g., reaching the maximum number of iterations or reaching the fitness threshold). The final population is then used as the output by weighing the appropriate individuals according to the objective function.

[0098] When using gradient optimization algorithms, the optimization process can first construct an objective function containing the parameters to be optimized, calculate the gradient direction of the objective function with respect to the current parameters, and update the parameters along the gradient descent (or ascent) direction according to a preset learning rate. Through multiple iterations, the objective function converges to the extreme value, thereby obtaining the optimal solution.

[0099] This disclosure also provides a microsystem construction apparatus based on a digital prototype, such as Figure 7 As shown, it includes: Module 701 is used to construct a functional architecture diagram model representing the functions of the microsystem based on the operational requirements of the target microsystem and according to a preset transformation logic. The mapping module 702 is used to allocate functions to the functional architecture diagram model according to the design constraints of the target microsystem and map it to generate a logical architecture diagram model. The selection module 703 is used to generate a physical architecture diagram model based on the logical architecture diagram model through component mapping, and to generate a chip component model according to the component selection requirements of the microsystem. Instantiation module 704 is used to instantiate the physical architecture diagram model according to the chip component model to obtain a simulation verification model; Simulation module 705 is used to perform multiphysics simulation optimization based on the simulation verification model and generate a manufacturing process data package for the microsystem based on the optimization results. The adjustment module 706 is used to acquire test data of the test microsystem entity, compare the test data with the system capability items of the target microsystem, and adjust the functional architecture diagram model, logical architecture diagram model or physical architecture diagram model according to the comparison results until the test data meets the system capability items of the target microsystem, thereby obtaining the design scheme of the target microsystem.

[0100] In another embodiment provided in this disclosure, the construction module is further configured to: model the target microsystem according to its operational requirements; define the interaction behavior between the target microsystem and its external environment; generate a standardized operational model; cluster the interaction behavior in the standardized operational model; extract system capability items representing the functional characteristics of the target microsystem from the clustered interaction behavior; obtain a list of system capability items and performance parameters of each system capability item; decompose the system capability items into multiple atomic requirement items and corresponding functional nodes; obtain a structured requirement specification document based on the requirement items; and for each requirement item in the requirement specification document, establish a traceability relationship based on the corresponding functional node, system capability item, interaction behavior, and operational requirements to construct a requirement traceability matrix; and connect the functional nodes into a functional chain based on the functional transfer relationship between the functional nodes to obtain a functional architecture diagram model representing the functions of the target microsystem.

[0101] In another embodiment provided in this disclosure, the mapping module is further configured to: obtain logical components that carry the functions according to the functions corresponding to each functional node in the functional architecture diagram model, and establish component mapping relationships between functional nodes and logical components; define input and output ports for each logical component, and transform the functional transmission relationships between functional nodes in the functional architecture diagram model into interaction protocols and interaction logic between logical components; bind the design constraints of the target microsystem to each logical component, and allocate microsystem resources to the logical components based on the design constraints; wherein the design constraints of the target microsystem include at least one of the following: target performance parameters, target interface parameters, and target reliability parameters; the microsystem resources include at least one of the following: microsystem computing power, microsystem memory, and microsystem bandwidth; and adjust the connection relationships between logical components based on the component mapping relationships and the results of microsystem resource allocation to generate a logical architecture diagram model.

[0102] In another embodiment provided in this disclosure, the selection module is further configured to convert the logical components in the logical architecture diagram model into physical components that implement the logical strategies of the logical components according to the mapping relationship between logical components and physical components; and to perform a search and matching for each physical component in a preset chip component model library according to the design constraints bound to the logical components mapped by the physical components, to filter out candidate components that meet the design constraints, and to obtain multiple chip component models based on the combination of different candidate components.

[0103] In another embodiment provided in this disclosure, the instantiation module is further configured to update the parameter information of each component in each chip component model to the corresponding physical component of the physical architecture diagram model. Based on the physical components in the updated physical architecture diagram model, a collaborative structural model containing the three-dimensional geometric features and spatial layout of the microsystem is constructed in the structural design environment; based on the collaborative structural model, a packaging and routing design scheme for the microsystem is generated in the electronic design environment; and multiple simulation verification models are obtained based on the collaborative structural model and the packaging and routing design scheme.

[0104] In another embodiment provided in this disclosure, the simulation module is further configured to perform parameterization for each simulation verification model, define adjustable physical and electrical parameters in the simulation verification model as design variables, establish constraints in the multiphysics simulation optimization process based on the design constraints of the target microsystem, and define the objective function of the multiphysics simulation optimization process based on the predetermined target optimization direction; drive the simulation script to obtain the simulation response of the simulation verification model under different design variables according to the preset multiphysics simulation optimization process, and iterate the simulation verification model under the constraints of the preset optimization algorithm until the preset optimization algorithm converges, obtaining a Pareto optimal solution set containing the trade-off relationship of different objective functions; select the target simulation verification model from the Pareto optimal solution set according to the trade-off relationship, and generate a manufacturing process data package containing microsystem construction rules and microsystem production elements based on the target simulation verification model.

[0105] In another embodiment provided in this disclosure, the simulation module is further configured to update the simulation verification model according to the design variable values ​​distributed by the preset optimization algorithm; call the simulation solver associated with the simulation verification model respectively to perform simulation physics field calculation on the updated simulation verification model; and select the performance index values ​​corresponding to the objective function from the simulation physics field calculation results and send them back to the preset optimization algorithm as simulation responses.

[0106] In another embodiment provided in this disclosure, the adjustment module is further configured to acquire test data of the test microsystem entity; wherein the test data includes at least one of the following: physical characteristic data, functional response data, and operational performance data; based on the deviation between the test data and the system capability items of the target microsystem, the deviation is traced according to the correspondence between the test microsystem entity and the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model respectively; and the model elements in the physical architecture diagram model, logical architecture diagram model, or functional architecture diagram model that caused the deviation are adjusted according to the traceability results.

[0107] Through the above description of the embodiments, those skilled in the art can clearly understand that the embodiments of this disclosure can be implemented in hardware or by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions of the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments of this disclosure.

[0108] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes in the drawings are not necessarily essential for implementing this disclosure.

[0109] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0110] The sequence numbers of the embodiments disclosed above are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0111] Obviously, those skilled in the art can make various modifications and variations to this disclosure without departing from its spirit and scope. Therefore, if such modifications and variations fall within the scope of the claims of this disclosure and their equivalents, this disclosure is also intended to include such modifications and variations.

Claims

1. A method for constructing a microsystem based on a digital prototype, characterized in that, include: Based on the operational requirements of the target microsystem, a functional architecture diagram model representing the functions of the microsystem is constructed according to a preset transformation logic; wherein, the transformation logic is the progressive mapping relationship between the operational requirements of the microsystem, the system capability items of the microsystem, and the functions of the microsystem. The functional architecture diagram model is assigned functions according to the design constraints of the target microsystem, and mapped to generate a logical architecture diagram model. Based on the logical architecture diagram model, a physical architecture diagram model is generated through component mapping, and a chip component model is generated according to the component selection requirements of the microsystem. The physical architecture model is instantiated based on the chip component model to obtain the simulation verification model; Based on the simulation verification model, multiphysics simulation optimization is performed, and manufacturing process data packages for the microsystem are generated based on the optimization results. The test data of the test microsystem entity is obtained, and the test data is compared with the system capability items of the target microsystem. The functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model is adjusted according to the comparison results until the test data meets the system capability items of the target microsystem, thereby obtaining the target microsystem design scheme; wherein, the test microsystem entity is a microsystem entity manufactured according to the manufacturing process data package.

2. The method as described in claim 1, characterized in that, Based on the operational requirements of the target microsystem, and following a preset transformation logic, a functional architecture diagram model representing the functions of the microsystem is constructed, including: Modeling is performed based on the operational requirements of the target microsystem, defining the interaction behavior between the main body of the target microsystem and the external environment, and generating a standardized operational model; The interactive behaviors in the standardized operation model are clustered, and system capability items that characterize the functional features of the target microsystem are extracted from the clustered interactive behaviors to obtain a list of system capability items of the target microsystem and the performance parameters of each system capability item. The system capability items are decomposed into multiple atomic requirement items and corresponding functional nodes; Based on the aforementioned requirement items, a structured requirement specification document is obtained. For each requirement item in the requirement specification document, a traceability relationship is established according to the corresponding functional nodes, system capability items, interactive behaviors, and operational requirements to construct a requirement traceability matrix. Based on the functional transfer relationships between the functional nodes, each functional node is connected into a functional chain to obtain a functional architecture diagram model representing the function of the target microsystem.

3. The method as described in claim 1, characterized in that, The step of allocating functions to the functional architecture diagram model according to the design constraints of the target microsystem and mapping it to generate a logical architecture diagram model includes: Based on the functions corresponding to each functional node in the functional architecture diagram model, the logical components that carry the functions through built-in logical strategies are obtained, and a component mapping relationship is established between the functional nodes and the logical components. Define the input and output ports of each logical component, and transform the functional transmission relationship between functional nodes in the functional architecture diagram model into the interaction protocol and interaction logic between logical components; The design constraints of the target microsystem are bound to each logical component, and microsystem resources are allocated to the logical components based on the design constraints; wherein, the design constraints of the target microsystem include at least one of the following: target performance parameters, target interface parameters, and target reliability parameters; the microsystem resources include at least one of the following: microsystem computing power, microsystem memory, and microsystem bandwidth; Based on the component mapping relationship and the result of microsystem resource allocation, the connection relationship between logical components is adjusted to generate a logical architecture diagram model.

4. The method as described in claim 3, characterized in that, The process of generating a physical architecture model based on the logical architecture diagram model through component mapping, and generating a chip component model according to the component selection requirements of the microsystem, includes: Based on the mapping relationship between logical components and physical components, the logical components in the logical architecture diagram model are converted into physical components that implement the logical strategies of the logical components; Based on the design constraints bound to the logical components mapped by the physical components, a search and matching process is performed for each physical component in a preset chip component model library to select candidate components that meet the design constraints, and multiple chip component models are obtained based on combinations of different candidate components.

5. The method as described in claim 1, characterized in that, The step of instantiating the physical architecture diagram model based on the chip component model to obtain the simulation verification model includes: The parameter information of each component in each chip component model is updated to the corresponding physical component in the physical architecture diagram model; Based on the physical components in the updated physical architecture diagram model, a collaborative structural model containing the three-dimensional geometric features and spatial layout of the microsystem is constructed in the structural design environment. Based on the aforementioned collaborative structure model, a packaging and wiring design scheme for a microsystem is generated in an electronic design environment. Based on the aforementioned collaborative structure model and packaging and routing design scheme, multiple simulation verification models were obtained.

6. The method as described in claim 1, characterized in that, The step of performing multiphysics simulation optimization based on the simulation verification model, and generating a manufacturing process data package for the microsystem based on the optimization results, includes: For each simulation verification model, parameter configuration is performed, and the adjustable physical and electrical parameters in the simulation verification model are defined as design variables. Constraints in the multiphysics simulation optimization process are established based on the design constraints of the target microsystem, and the objective function of the multiphysics simulation optimization process is defined based on the predetermined target optimization direction. According to the preset multiphysics simulation optimization process, the simulation script is driven to obtain the simulation response of the simulation verification model under different design variables, and the simulation verification model is iterated under the constraints of the preset optimization algorithm until the preset optimization algorithm converges, and a Pareto optimal solution set containing the trade-off relationship of different objective functions is obtained. According to the aforementioned trade-offs, a target simulation verification model is selected from the Pareto optimal solution set, and a manufacturing process data package containing microsystem construction rules and microsystem production elements is generated based on the target simulation verification model.

7. The method as described in claim 6, characterized in that, The driving simulation script obtains the simulation response of the simulation verification model under different design variables, including: The simulation verification model is updated according to the values ​​of the design variables distributed by the preset optimization algorithm; The simulation solvers associated with the simulation verification model are invoked respectively to perform simulation physics field calculations on the updated simulation verification model; In the simulation physics calculation results, the performance index values ​​corresponding to the objective function are selected as the simulation response and fed back to the preset optimization algorithm.

8. The method as described in claim 1, characterized in that, The process of acquiring test data for the test microsystem entity, comparing the test data with the system capability items of the target microsystem, and adjusting the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model based on the comparison results includes: Obtain test data for the test microsystem entity; wherein the test data includes at least one of the following: physical characteristic data, functional response data, and operational performance data; Based on the deviation between the test data and the system capability items of the target microsystem, the source of the deviation is traced according to the correspondence between the test microsystem entities and the functional architecture diagram model, logical architecture diagram model, or physical architecture diagram model, respectively. Adjust the model elements in the physical architecture diagram, logical architecture diagram, or functional architecture diagram that caused the deviation based on the source tracing results.

9. The method as described in claim 6, characterized in that, The preset optimization algorithm includes at least one of the following: genetic algorithm or gradient optimization algorithm.

10. A microsystem construction device based on a digital prototype, characterized in that, include: The building module is used to construct a functional architecture diagram model representing the functions of the microsystem based on the operational requirements of the target microsystem and according to a preset transformation logic. The mapping module is used to allocate functions to the functional architecture diagram model according to the design constraints of the target microsystem and map it to generate a logical architecture diagram model. The selection module is used to generate a physical architecture model based on the logical architecture diagram model through component mapping, and to generate a chip component model according to the component selection requirements of the microsystem. An instantiation module is used to instantiate the physical architecture diagram model based on the chip component model to obtain a simulation verification model; The simulation module is used to perform multiphysics simulation optimization based on the simulation verification model and generate a manufacturing process data package for the microsystem based on the optimization results. The adjustment module is used to acquire test data of the test microsystem entity, compare the test data with the system capability items of the target microsystem, and adjust the functional architecture diagram model, logical architecture diagram model or physical architecture diagram model according to the comparison results until the test data meets the system capability items of the target microsystem, thereby obtaining the design scheme of the target microsystem.

Images