A method for generating product alternatives centered on functional data

Abstract

This application relates to the field of data processing technology, and in particular to a method for generating product alternative solutions centered on functional data. The proposed solution involves structurally modeling the functions of the product to be designed, constructing a functional data package containing functional inputs and outputs, performance indicators, resource requirements, and interface constraints, and forming a corresponding set of candidate implementation solutions based on this data. By introducing functional dependencies, the product solution generation process is organized as a controlled search process based on partially combined states. During the combination generation stage, interface consistency, resource budget, and dependency constraint checks are performed simultaneously. Furthermore, by combining extension priority and state deduplication mechanisms, invalid or duplicate combinations are pruned, thereby significantly reducing the risk of combination explosion while ensuring search coverage.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method for generating product alternatives centered on functional data. Background Technology

[0002] In existing product design processes, especially in complex scenarios involving multi-functional collaboration and multiple hardware / software implementation paths, product solutions are typically formed based on human experience or rule-based step-by-step selection methods. These methods often begin with functional decomposition, then determine the implementation form for each function, and finally integrate them manually to form a product solution. However, when the number of functions and implementation options is large, the final number of solutions highly depends on the designer's subjective judgment, resulting in limited solution coverage. It is difficult to systematically reflect all feasible combinations and is prone to overlooking potentially competitive design paths.

[0003] Meanwhile, some existing technologies attempt to generate product solutions through enumeration or exhaustive search, and then centrally screen the generated results. However, in practical applications, such methods tend to generate a large number of unworkable solution combinations, resulting in a low proportion of usable solutions and high screening costs. As functional complexity increases, the scale of solution combinations expands rapidly, generation efficiency decreases, and it becomes difficult to obtain stable output within an acceptable time or computing resource range, making it difficult to extend the solution generation process to complex product scenarios.

[0004] To address the above issues, this application proposes a product alternative generation method centered on functional data. Summary of the Invention

[0005] The technical problem this application aims to solve is to address the shortcomings of existing technologies by providing a product alternative generation method centered on functional data. This method involves structured modeling of the functions of the product to be designed, constructing a functional data package containing functional inputs and outputs, performance indicators, resource requirements, and interface constraints, and forming a corresponding set of candidate implementation schemes based on this data. By introducing functional dependencies, the product scheme generation process is organized as a controlled search process based on partially combinatorial states. During the combinatorial generation phase, interface consistency, resource budget, and dependency constraint checks are performed simultaneously. Furthermore, by combining extension priority and state deduplication mechanisms, invalid or duplicate combinations are pruned, thereby significantly reducing the risk of combinatorial explosion while ensuring search coverage.

[0006] To achieve the above objectives, this application provides the following technical solution:

[0007] A method for generating product alternatives centered on functional data, the method comprising:

[0008] Obtain the set of functions for the product to be designed, and construct a function data package based on each function in the set of functions;

[0009] A corresponding set of candidate implementation schemes is established based on the functional data package, and the set of candidate implementation schemes is summarized to obtain the implementation scheme data package;

[0010] Based on the dependencies of each function in the function set, a product candidate combination is generated and searched to select implementation schemes from the implementation scheme data package for combination, thereby obtaining a product candidate combination, and the product candidate combination is output as a product alternative scheme.

[0011] The set of functions includes multiple functions for achieving the product's target tasks, and the multiple functions include at least one of the following:

[0012] Sensing functions used to perceive the external environment;

[0013] Processing functions used for processing and making decisions based on perceived data;

[0014] Execution functions used to perform physical actions;

[0015] A power supply function to ensure the energy supply for the sensing, processing and execution functions;

[0016] The multiple functions are associated with each other through functional dependencies, which are used to characterize the order, collaboration, and constraints among the functions.

[0017] Construct a function data package based on each function in the function set, including:

[0018] Establish a corresponding function identifier for each function, and obtain the function input information and function output information associated with the function identifier;

[0019] Configure at least one functional performance indicator for the function, wherein the functional performance indicator is used to characterize the performance requirements of the function in the process of performing the product target task;

[0020] Configure functional resource requirement parameters for the function, wherein the functional resource requirement parameters include computing power requirement, storage requirement, energy requirement, time constraint and space constraint;

[0021] Establish a functional interface description for the function, wherein the functional interface description is used to characterize the data interaction method and interaction constraints between the function and other functions;

[0022] The function input information, function output information, function performance indicators, function resource requirement parameters, and function interface description are summarized to generate the function data package corresponding to the function.

[0023] Based on the aforementioned functional data package, a corresponding set of candidate implementation schemes is established, including:

[0024] For each function in the function set, based on the corresponding function data package, at least one implementation method corresponding to the function is obtained, wherein the implementation method includes a software implementation method, a hardware implementation method, and a software and hardware co-implementation method;

[0025] For each implementation method, obtain the implementation parameters required to implement the function through the corresponding implementation method, wherein the implementation parameters include at least one of the interface parameters, resource consumption parameters, and applicable condition parameters;

[0026] Based on the aforementioned implementation parameters, a corresponding implementation scheme data unit is generated for each implementation method;

[0027] The implementation scheme data units corresponding to each function in the function set are collected to generate the candidate implementation scheme set.

[0028] Based on the dependencies between the functions in the function set, a product candidate combination is generated and searched to select implementation schemes from the implementation scheme data package for combination, resulting in product candidate combinations, including:

[0029] A functional dependency graph is constructed based on the aforementioned dependency relationships, wherein the functional dependency graph is used to represent the dependency associations between various functions, and the nodes of the functional dependency graph are functions, and the edges are dependency relationships;

[0030] Initialize a combination queue to be expanded, wherein the combination queue to be expanded is used to store partial combination states that have not yet been completed, the partial combination states are used to characterize the combination results for which implementation schemes have been selected for at least some functions in the function set, the partial combination states include at least one implementation scheme, and when the combination queue to be expanded is initialized, the partial combination states are empty combination states, the empty combination states are used to characterize the initial combination for which no implementation scheme has been selected for any function in the function set;

[0031] The process involves performing an iterative operation, sorting the partial combination states according to a preset expansion priority to obtain the current partial combination state, determining the next function to be expanded corresponding to the current partial combination state based on the functional dependency graph, selecting an implementation scheme corresponding to the next function to be expanded from the implementation scheme data package to generate a combination state, and writing the combination state into the queue of combinations to be expanded to update the partial combination state, until a preset termination condition is met, and outputting the partial combination state as a product candidate combination.

[0032] The step of sorting the partial combination states according to a preset expansion priority to obtain the current partial combination state includes:

[0033] From the head of the queue to be expanded, a preset number of implementation schemes are sequentially extracted according to the first-in-first-out rule to construct a candidate expansion subset;

[0034] For each implementation scheme in the candidate expansion subset, an expansion priority value is calculated based on the parameter information corresponding to the implementation scheme. The expansion priority value is used to characterize the matching degree of the implementation scheme in generating product candidate combinations that meet the feasibility requirements in subsequent expansions. The parameter information includes interface parameters, resource consumption parameters, and applicable condition parameters.

[0035] Based on the expansion priority value, a target implementation scheme is determined in the candidate expansion subset, and used as the current partial combination state for subsequent expansion;

[0036] The remaining implementation schemes are rewritten into the queue to be expanded according to the corresponding retrieval order.

[0037] Based on the functional dependency graph, determine the next function to be expanded corresponding to the current partial combination state, including:

[0038] Obtain the set of functions corresponding to the selected implementation schemes in the current partial combination state, and use it as the set of completed functions;

[0039] Based on the functional dependency graph, a set of candidate functions to be expanded is determined, wherein the set of candidate functions to be expanded includes functions that meet the following conditions: the function is not included in the set of completed functions, and all the preceding dependent functions of the function in the functional dependency graph are included in the set of completed functions.

[0040] When the candidate set of functions to be expanded contains multiple functions, the next function to be expanded is determined from the candidate set of functions to be expanded according to a preset function selection rule, wherein the function selection rule is determined according to the topological order, dependency in-degree, resource requirements and interface constraint strength of the function dependency graph.

[0041] Selecting an implementation scheme corresponding to the next function to be expanded from the implementation scheme data package to generate a combined state includes:

[0042] Obtain a set of candidate implementation schemes corresponding to the next function to be expanded from the implementation scheme data package;

[0043] Based on the current partial combination state and the parameter information corresponding to each candidate implementation scheme in the candidate implementation scheme set, a target implementation scheme set compatible with the current partial combination state is determined.

[0044] At least one target implementation scheme is selected from the set of target implementation schemes according to a preset implementation scheme selection rule, wherein the implementation scheme selection rule is determined by calculating a matching degree index based on the parameter information and selecting the target implementation scheme with the highest matching degree from the set of target implementation schemes according to the matching degree index;

[0045] The target implementation scheme is merged with the implementation schemes already selected in the current partial combined state to obtain the combined state.

[0046] Writing the combined state to the expanded combined queue to update a portion of the combined state includes:

[0047] During the expansion process, based on the interface parameters, resource consumption parameters and dependency constraints represented by the functional dependency graph in the implementation scheme data package, the combined state is subjected to constraint consistency verification, and the combined state that fails the constraint consistency verification is pruned.

[0048] A combined state identifier is generated for the combined states that pass the constraint consistency check, and an index record is established based on the combined state identifier;

[0049] Before writing the combined state into the combined queue to be expanded, the index record is queried to determine whether there is a recorded identifier that is the same as the combined state identifier;

[0050] When a recorded identifier that is identical to the combined state identifier exists, the duplicate combined state is pruned, and the remaining combined states are written into the combined state queue to be expanded.

[0051] If there is no recorded identifier that is the same as the combined state identifier, the combined state is written into the combined queue to be expanded.

[0052] The constraint consistency check includes:

[0053] Perform interface consistency verification by matching the interface parameters of the newly added target implementation scheme in the combined state with the interface parameters of the selected implementation scheme in the current partial combined state, and determine whether one or more of the data type, protocol type, data rate, and timing constraints meet the preset interface matching rules.

[0054] After passing the interface consistency check, a resource budget consistency check is performed to accumulate the resource consumption vector based on the resource usage parameters of each selected implementation scheme in the combined state, and compare the resource consumption vector with a preset resource budget threshold to determine whether the budget is exceeded.

[0055] After passing the resource budget consistency check, a dependency constraint consistency check is performed to determine whether the combined state satisfies the coexistence constraints, mutual exclusion constraints, and sequence constraints between functions based on the dependency constraints represented by the functional dependency graph.

[0056] Among them, when any constraint consistency check fails, the combined state corresponding to pruning is determined.

[0057] Compared with the prior art, the beneficial effects of this application are:

[0058] This application restructures the product design process with functional data at its core, unifying functional modeling, implementation scheme acquisition, and product scheme generation within a controlled combinatorial search framework. This transforms the formation of alternative product schemes from experience-driven to data-driven. During the scheme generation phase, functional dependency constraints, interface consistency, and resource budget verification are introduced simultaneously. Combined with extension priority and state deduplication mechanisms, infeasible or repetitive combinations are pruned beforehand, effectively reducing the computational burden caused by combinatorial explosion and increasing the proportion of effective solutions generated. Attached Figure Description

[0059] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0060] Figure 1 A flowchart illustrating a product alternative generation method centered on functional data, provided for an embodiment of this application;

[0061] Figure 2 A schematic diagram illustrating the process of generating candidate combinations of products provided in an embodiment of this application;

[0062] Figure 3 This is a schematic diagram of the initialization structure of the combinatorial queue to be expanded, provided in an embodiment of this application.

[0063] Figure 4 This is a schematic diagram illustrating the principle of the current partial combination state provided in the embodiments of this application. Detailed Implementation

[0064] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0065] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0066] In the early conceptual design and solution demonstration phases of complex products, the requirements side typically first defines the target tasks and functional boundaries, and then the R&D side completes the architectural trade-offs and component selection within a given timeframe and resource constraints. For products with a large number of functions, multiple implementation paths, and significant cross-software / hardware coupling, those skilled in the art often encounter a common dilemma in engineering practice:

[0067] The same function can be implemented by multiple software algorithms, multiple hardware devices, or a software-hardware co-operation path. However, different functions are subject to dependencies and constraints such as interface protocols, timing links, computing power and power consumption budgets, weight and volume boundaries, and mutual exclusion / coexistence. In the absence of a unified expression and systematic deduction mechanism, solution generation usually relies on expert experience and existing templates. A main architecture is first determined, and then local replacements and repairs are made around this architecture. Although this approach is feasible in engineering, it is prone to two types of problems when facing a combination space of multiple functions, multiple implementation states, and multiple constraints: On the one hand, the exploration coverage of feasible solutions is insufficient, and it is easy to miss more competitive implementation paths under specific constraint combinations; on the other hand, solution verification is delayed, and many combinations only reveal interface incompatibility, resource overruns, or dependency conflicts during later integration or system-level verification, resulting in repeated rework and increased iteration costs.

[0068] In exemplary technologies, a common practice is to select components based on a module list or component library, or to provide candidate implementation schemes for each function after the functional framework is determined, and then gradually converge through meeting reviews, experience scoring, or offline simulation. Typically, there is a lack of a unified, structured description at the functional data level. Information such as the input / output semantics, performance indicators, resource requirements, and interface contracts of functions is scattered across multiple documents or different professional tools, making it difficult to form a computable and comparable basis for combination. Furthermore, traditional enumeration-based generation is unsustainable in the face of combinatorial explosion, while relying on manual selection makes it difficult to guarantee consistency and traceability. Therefore, those skilled in the art generally need a mechanism that is more in line with engineering processes:

[0069] It can automatically expand the implementation space after the functional design is completed, and can identify impossible combinations as early as possible during the combination generation process. It can also prioritize the allocation of computing and verification resources to directions that are more likely to form feasible product candidates, thereby realizing the systematic generation and selection of alternative solutions.

[0070] Based on the aforementioned engineering background, the product alternative generation method centered on functional data proposed in this application is not aimed at a specific industry or a fixed product structure, but rather at a common scenario:

[0071] The product consists of multiple functions, each with various implementation methods, and there are formally expressible dependencies and constraints between these functions. At the same time, the product's feasibility and competitiveness depend on its system-level performance after cross-functional integration.

[0072] To adapt to this type of scenario, this application first abstracts the product to be designed into a set of functions in its embodiments, and constructs a function data package for each function, so that the functions are transformed from natural language descriptions into computable engineering objects:

[0073] It should include at least functional input / output information, performance metrics, resource requirement parameters, and interface descriptions, thus providing a unified data basis for subsequent implementation scheme retrieval, compatibility assessment, and resource budget calculation. Based on this, a set of candidate implementation schemes is established for each function, forming an implementation scheme data package, enabling different functions and different implementation forms to be described and managed within the same data framework.

[0074] Furthermore, the core concept of this application's logic stems from an engineering understanding of the combinatorial generation process:

[0075] Product candidate combinations are not assembled all at once and then screened. Instead, constraints should be introduced synchronously during the generation process to eliminate invalid combinations as early as possible. A priority strategy should be used to guide the search order to avoid disorderly expansion in a huge combination space. To this end, in this embodiment, a functional dependency graph is constructed based on the dependencies between functions to represent the sequence, collaboration, and constraint relationships between functions. During combination generation, the combination results for which implementation schemes have been selected for some functions are maintained as partial combination states, and a queue of combinations to be expanded carries the incomplete partial combination states.

[0076] Furthermore, unlike the traditional first-in-first-out traversal of a queue, this application does not sort the entire queue. Instead, in each iteration, a subset of candidates within a preset window is taken from the front of the queue. The expansion priority value of each candidate in the subset is calculated based on the interface parameters, resource consumption parameters, and applicable condition parameters of the implementation scheme. This value represents the degree of matching of the candidate product combination that meets the feasibility requirements in subsequent expansion. The more promising current combination state is then selected for priority expansion. Candidates that are not selected are backfilled into the queue in the order they were taken out, thereby achieving controlled expansion with local priority while maintaining the semantics of the queue structure.

[0077] Understandably, when verification resources are limited, priority should be given to expanding combined paths that have easier interface matching, more abundant resource margins, higher dependency satisfaction, or more suitable conditions for the target task, in order to obtain feasible candidates as early as possible and reduce ineffective expansion.

[0078] Those skilled in the art will understand that the generation of combined states is not a simple concatenation, but rather an incremental construction centered around integrability: once the next function to be expanded is determined, a set of candidate implementation schemes corresponding to that function is obtained from the implementation scheme data package. Combined with the current partial combined states, a set of compatible target implementation schemes is selected. Then, a target implementation scheme is selected based on the matching degree index and merged with existing selected schemes to generate a new combined state. To avoid computational waste caused by repeated expansion and verification, this application can also generate combined state identifiers and establish index records for combined states that pass consistency verification. When the same identifier already exists in the index, repeated expansion is skipped, thus maintaining controllable generation efficiency even as the scale of functions and schemes expands. Finally, after meeting the preset termination conditions, candidate product combinations are output, and the process proceeds to the subsequent system-level feasibility verification and alternative scheme output stage.

[0079] Next, with reference to the accompanying drawings, a method for generating product alternatives centered on functional data, as provided in an embodiment of this application, will be further described. Figure 1 The methods shown include:

[0080] S1: Obtain the function set of the product to be designed, and construct a function data package based on each function in the function set;

[0081] In this embodiment, the product to be designed is a product form in which multiple functions work together to complete a target task. The function set is used to describe the functional capability boundaries that the product needs to possess under the target task, without pre-defining a specific structural form or implementation path. The function set can be obtained through requirements analysis, systems engineering decomposition, or abstraction of existing product functions.

[0082] Those skilled in the art will understand that the method of obtaining the function set does not affect the implementation effect of the method of this application, as long as it can cover the functional capabilities required by the target task, and this application does not make any further limitations in this regard.

[0083] For each function in the function set, a function data package is constructed to transform the functional requirements originally described in natural language or experience into calculable and composable engineering data expressions. The function data package includes at least functional input information, functional output information, functional performance indicators, functional resource requirement parameters, and functional interface descriptions.

[0084] S2: Establish a corresponding set of candidate implementation schemes based on the functional data package, and summarize the set of candidate implementation schemes to obtain the implementation scheme data package;

[0085] In this embodiment, for each functional data packet, based on the functional input / output semantics, performance indicators, and resource requirement parameters, a set of candidate implementation schemes corresponding to the function is obtained from a preset implementation method source. The implementation methods may include software implementation methods, hardware implementation methods, or software and hardware co-implementation methods.

[0086] Those skilled in the art will understand that the specific source of the implementation method can be a device library, algorithm library, historical solution library, or summary of engineering experience, as long as it can provide an alternative implementation path for the function. This application does not limit the acquisition method of the implementation method. For each candidate implementation scheme, an implementation scheme data unit is constructed to describe the interface parameters, resource consumption parameters, and applicable condition parameters of the implementation scheme. Multiple implementation scheme data units under the same function are collected to form a candidate implementation scheme set.

[0087] S3: Generate and search for product candidate combinations based on the dependencies of each function in the function set, select implementation schemes from the implementation scheme data package for combination, obtain product candidate combinations, and output the product candidate combinations as product alternatives;

[0088] In this embodiment, a functional dependency graph is first constructed based on the sequence, collaboration, and constraint relationships among the functions in the functional set to clarify the dependency boundaries and expansion order between functions. Based on this, a queue for expansion is introduced to maintain incomplete partial combination states. These partial combination states represent intermediate combination results for which implementation schemes have been selected for at least some functions. The queue for expansion initially contains only empty combination states as the starting point for combination generation. During the combination generation process, an iterative approach is used to expand the partial combination states. By constructing a candidate expansion subset at the front of the queue, calculating expansion priorities, and selecting more promising combination states for priority expansion, the combination search order is guided without disrupting the semantics of the queue structure.

[0089] Furthermore, during each expansion process, based on the interface parameters, resource consumption parameters, and functional dependency constraints of the implementation scheme, a consistency check is performed on the newly generated combined states. Combined states that do not meet the constraints are pruned. At the same time, combined states that pass the check are generated with combined state identifiers and index records are established to avoid repeated expansion.

[0090] Understandably, product candidate combinations are subject to multi-dimensional constraints such as functional dependencies, interface compatibility, and resource budgets during the generation phase. This can significantly reduce the number of invalid combinations, improve the efficiency of generating feasible solutions, and ultimately output a set of product alternatives that can be used for subsequent system-level feasibility analysis and competitiveness assessment.

[0091] Before detailing the specific technical aspects corresponding to the steps, this application's embodiments need to reiterate:

[0092] The objects addressed in this application are not limited to a specific industry or a particular type of product, but rather focus on a way of organizing the function-implementation relationship in the engineering design phase. Once a product concept is broken down into multiple executable functions, the question becomes not how to implement a single function, but rather the juxtaposition, comparison, and combination of different implementation paths under the same constraint system.

[0093] The same function may have multiple implementations, such as algorithm replacements, device replacements, and hardware-software co-operation replacements, and these implementations differ significantly in interface type, data semantics, resource consumption, and applicable conditions. Without a unified data carrier and constraint expression, design activities often converge gradually from empirically feasible starting points, making it difficult to form a structured set of alternatives, and even more difficult to explain why a particular combination is more competitive in the early stages. The embodiments of this application address this engineering context by transforming the functional description from a textual level to a data level, enabling this data to drive subsequent combination generation and selection, and ensuring that the process of generating alternative solutions has a reproducible and traceable logical chain.

[0094] It should be noted that the key to the embodiments of this application lies not in simply summarizing candidate implementation schemes into a list, but in introducing a computable constraint carrier for subsequent combination deduction. In engineering practice, what is most likely to cause combination failure is not the function itself, but the way the functions are connected:

[0095] Whether the data interface is compatible, whether the control link timing is valid, whether the resource budget is exceeded by superposition, and whether certain implementations are mutually exclusive or must coexist under the same operating conditions, etc.

[0096] Therefore, in this embodiment, the description criteria for parameter information are set for each implementation scheme, so that interface parameters, resource usage parameters and applicable condition parameters become structured fields that can be directly used for judgment.

[0097] Those skilled in the art will understand that the number of fields and the form of values ​​for the parameter information can be expanded or tailored according to the product type. For example, interface parameters can be refined into protocol type, data format, sampling frequency, timing constraints, etc.; resource consumption parameters can be refined into computing power, storage, power consumption, weight, volume, etc.; and applicable condition parameters can be refined into ambient temperature range, reliability level, supply availability, etc. It is sufficient to meet the minimum requirements for judging compatibility and feasibility. This application does not impose any further limitations.

[0098] It is important to emphasize that the embodiments of this application prioritize the controllability and interpretability of expansion behavior when organizing combinatorial deduction. The combinatorial states maintained during the deduction process are not merely used to record the set of selected solutions, but also to carry the state information required for incremental expansion, such as the functional coverage set corresponding to the selected implementation solutions, cumulative resource consumption statistics, and interface association information. This ensures that each new implementation solution can be consistent with existing choices within the same semantic framework. To avoid the deduction process falling into random or blind expansion, the embodiments introduce a mechanism for calculating and selecting expansion priorities. Intermediate states that are more likely to form feasible or high-quality complete combinations are prioritized, thereby concentrating computational resources on more productive expansion paths. Expansion priority is not equivalent to the final solution score, but rather a scheduling indicator used to measure the potential for subsequent expansion. It can be determined by one or more of resource sufficiency, interface matching degree, dependency satisfaction, and applicability condition satisfaction. The specific calculation method can be adjusted according to engineering goals, and those skilled in the art will understand that such adjustments will not change the basic idea of ​​the method in this application.

[0099] Next, the technical content of the method of this application regarding the functional set will be further introduced.

[0100] The set of functions includes multiple functions for achieving the product's target tasks, and the multiple functions include at least one of the following:

[0101] Sensing functions used to perceive the external environment;

[0102] Processing functions used for processing and making decisions based on perceived data;

[0103] Execution functions used to perform physical actions;

[0104] A power supply function to ensure the energy supply for the sensing, processing and execution functions;

[0105] The multiple functions are associated with each other through functional dependencies, which are used to characterize the order, collaboration, and constraints among the functions.

[0106] It is understandable that the above division of the functional set is not a limitation on the product form or system architecture, but an abstract expression based on the common functionalities that exist in engineering practice, used to provide a structured description of product capabilities without introducing specific implementation details.

[0107] Those skilled in the art will understand that the sensing, processing, execution, and safeguarding functions are not required to exist independently of each other in terms of physical structure, nor are they required to correspond one-to-one with specific components. Their essence lies in decomposing the product's target tasks from the perspective of functional responsibilities, so that each type of function has clear boundaries and semantic orientation in the subsequent construction and combination of implementation schemes.

[0108] For example, in some products, sensing and processing functions can be completed collaboratively by the same device or the same algorithm module, while in other products, they may be implemented by completely different hardware and software units; the above differences will not affect the construction of the function set, as long as the relevant functions can be logically identified and assigned the corresponding function data package.

[0109] Furthermore, the introduction of functional dependencies is not merely for describing the execution order between functions, but rather for explicitly characterizing the various constraint semantics that may exist between functions during the composition generation stage. In this embodiment, the functional dependencies are used to characterize at least the sequential relationship, collaborative relationship, and constraint relationship between functions. The sequential relationship is used to limit a function to the condition that it cannot be expanded before its preceding function is satisfied; the collaborative relationship is used to describe the situation where multiple functions need to coexist or be selected together to meet the product's target task; and the constraint relationship is used to describe engineering constraints such as mutual exclusion, binding, or resource conflicts between functions. Those skilled in the art will understand that the specific expression of functional dependencies can be a directed relationship, a set constraint, or a logical rule, as long as it can be identified and participate in the judgment during the composition generation process. This application does not further limit its specific modeling method.

[0110] Next, we will further elaborate on the technical content of the method in this application regarding the construction of functional data packages.

[0111] In one example, a feature data package is constructed based on each feature in the feature set, including:

[0112] S1.1: Establish a corresponding function identifier for each function, and obtain the function input information and function output information associated with the function identifier;

[0113] In this embodiment, the purpose of constructing the functional data package is not simply to record functional attributes, but to transform functional information, originally scattered in requirements documents, design specifications, or engineering experience, into a unified data entity that can participate in subsequent combination generation, constraint verification, and priority evaluation. To this end, a functional identifier is first established for each function to uniquely identify and associate the function throughout the entire process. The functional identifier can be a string encoding, a number, or other distinguishable form.

[0114] Those skilled in the art will understand that the specific form of the function identifier does not affect the effectiveness of the method implementation. Further, related function input and output information is obtained around this function identifier to clarify the data or signal interaction boundaries of the function within the product's target task. Function input and output information may include data type, data dimension, signal frequency, triggering conditions, etc. Their core function is to provide a basis for interface matching and data flow consistency judgment between different subsequent function implementation schemes, thereby avoiding the exposure of interface incompatibility issues only in the later stages of integration.

[0115] S1.2: Configure at least one functional performance indicator for the function, wherein the functional performance indicator is used to characterize the performance requirements of the function in the process of performing the product target task;

[0116] The functional performance indicators can be selected based on specific application scenarios, such as response time, processing accuracy, throughput, stability indicators, or reliability levels. Not all performance indicators need to be configured simultaneously; only those reflecting the core performance constraints of the function under the target task are required. This embodiment introduces performance indicators at the functional level, enabling a clear determination of whether subsequent implementation schemes meet functional requirements during selection and combination, thus avoiding the hidden problem of implementation schemes being runnable but lacking performance. Simultaneously, explicitly recording performance indicators in the functional data package provides a quantitative basis for subsequent expansion priority calculations, allowing the combination generation process to consider performance potential rather than solely focusing on structural feasibility.

[0117] S1.3: Configure functional resource requirement parameters for the function, wherein the functional resource requirement parameters include computing power requirement, storage requirement, energy requirement, time constraint and space constraint, wherein computing power requirement and storage requirement are used to characterize the function's occupation of computing and storage resources, energy requirement is used to characterize power consumption or energy consumption characteristics, time constraint is used to characterize timing or real-time requirements, and space constraint is used to characterize volume or installation space limitations.

[0118] Those skilled in the art will understand that the specific values ​​of resource requirement parameters can be estimated based on engineering experience, simulation results, or historical data. As long as they can participate in resource accumulation and budget comparison during the combination generation process, this application does not impose further limitations. By pre-introducing resource requirement descriptions at the functional level, incremental resource accounting can be performed during subsequent scheme combination, thereby eliminating invalid paths that significantly exceed the system resource budget during the combination generation stage.

[0119] S1.4: Establish a functional interface description for the function, wherein the functional interface description is used to characterize the data interaction methods and constraints between the function and other functions. The functional interface description may include interface type, communication protocol, data format, timing relationship or synchronization method, etc., with the aim of giving the connection relationship between functions verifiable engineering semantics. Through this interface description, subsequent assembly and generation processes can perform preliminary compatibility judgments on the implementation scheme based on the consistency of the functional interfaces, reducing assembly failures caused by interface incompatibility.

[0120] S1.5: Summarize the function input information, function output information, function performance indicators, function resource requirement parameters, and function interface description to generate the function data package corresponding to the function.

[0121] Next, we will further elaborate on the technical content of the method of this application regarding the set of candidate implementation schemes.

[0122] In one example, a set of candidate implementation schemes is established based on the functional data package, including:

[0123] S2.1: For each function in the function set, based on the corresponding function data package, obtain at least one implementation method corresponding to the function, wherein the implementation method includes a software implementation method, a hardware implementation method, and a software and hardware co-implementation method;

[0124] S2.2: For each implementation method, obtain the implementation parameters required to implement the function through the corresponding implementation method, wherein the implementation parameters include at least one of the interface parameters, resource consumption parameters, and applicable condition parameters;

[0125] S2.3: Generate corresponding implementation scheme data units for each implementation method based on the implementation parameters;

[0126] S2.4: Collect the implementation scheme data units corresponding to each function in the function set to generate the candidate implementation scheme set.

[0127] In this embodiment, the core purpose of constructing a set of candidate implementation schemes is to transform the process of how a function is implemented, which originally relied on engineering experience and implicit judgment, into a space of implementation schemes that can be systematically managed and compared.

[0128] Based on the functional input / output semantics, performance indicators, and resource requirement boundaries described in the aforementioned functional data package, a corresponding implementation method is obtained for each function. This implementation method is not limited to a single form but covers software implementation, hardware implementation, and software-hardware co-implementation methods to reflect the diverse implementation paths of the same function under different design stages or product constraints in engineering practice.

[0129] Those skilled in the art will understand that the implementation method can be derived from algorithm models, functional modules, device selection schemes, or combinations thereof, as long as it can independently assume the corresponding functional responsibilities in engineering.

[0130] After obtaining the implementation method, this embodiment further describes it parametrically based on whether the implementation method can be integrated in engineering. For each implementation method, the implementation parameters required to implement the function are obtained to characterize the engineering characteristics of the implementation method in terms of interface, resources, and applicable environment. The interface parameters are used to describe the interface type, data format, communication protocol, or timing constraints exposed by the implementation method; the resource consumption parameters are used to describe the resource consumption of the implementation method in terms of computing power, storage, energy, weight, or volume during operation; and the applicable condition parameters are used to describe the scope of application of the implementation method under specific environmental, operating, or configuration conditions.

[0131] Those skilled in the art will understand that the specific parameter types used can be selected based on product characteristics, as long as they can support subsequent compatibility assessments and constraint verifications; this application does not impose further limitations in this regard. Through the aforementioned parameterization process, different implementation methods are quantitatively described under the same evaluation dimension, thereby achieving comparability.

[0132] Based on this, this embodiment encapsulates each implementation method and its corresponding implementation parameters into an implementation scheme data unit, making it the smallest selectable unit in the subsequent combination and generation process. The implementation scheme data unit not only records the implementation method itself but also carries engineering constraint information associated with the functional data package, thus enabling it to be directly used in the combination and generation stage to determine interface consistency, resource budget, and applicability conditions. The implementation scheme data units corresponding to each function in the functional set are aggregated to form a candidate implementation scheme set, allowing the entire product's functional-level implementation scheme space to be organized and managed in a structured form.

[0133] Next, the technical content of the method of this application regarding the product candidate combination will be further elaborated.

[0134] It is understandable that generating product candidate combinations is not simply a matter of piecing together candidate implementations of various functions; rather, it requires maintaining an engineering logic chain that continuously determines whether the combination is still worth expanding. This embodiment introduces elements such as functional dependency graphs, partial combination states, candidate subset selection, and consistency checks at this stage. Essentially, it transforms the combination generation process from a discrete, manual selection action into an iterative constraint-satisfying process.

[0135] Each expansion is assessed based on whether the next feature to be expanded meets the expansion requirements, whether the selected implementation is compatible with existing options at the interface and resource levels, and whether the expansion still satisfies dependency constraints. This determines whether the combination should continue or be terminated in an early stage. In this way, the generation path of candidate combinations and the constraint verification path evolve synchronously, ensuring that the final output product candidate combinations naturally possess interpretable formation criteria. This avoids situations where the list of solutions is long but most are not integrable, and also ensures that the input for subsequent feasibility verification is more focused on high-value candidates.

[0136] It should be noted that the expansion priority in this embodiment is not a direct determination of the final solution's merits, but rather a guide for allocating search resources, prioritizing the limited number of expansion attempts for states more likely to form feasible combinations. The use of a front-end candidate subset approach is intended to achieve local selection while maintaining first-in-first-out semantics.

[0137] Each round prioritizes only a few partial combinations of states within the window, expanding states with higher matching degrees first, while the remaining states are backfilled in the order they were retrieved. This avoids both the additional cost of sorting the entire queue and the inefficient expansion caused by blindly pushing forward in a FIFO manner. In engineering, this corresponds to a common scenario: when multiple seemingly feasible semi-finished solutions coexist, prioritizing solutions with lower interface risk, more abundant resource margins, or higher dependency satisfaction often leads to faster availability of usable candidates and reduces invalid attempts.

[0138] refer to Figure 2 , Figure 2 This is a schematic diagram of the process for generating candidate combinations of products provided in an embodiment of this application.

[0139] In one example, a product candidate combination is generated and searched based on the dependencies between the functions in the function set, so as to select implementation schemes from the implementation scheme data package for combination, resulting in a product candidate combination, including:

[0140] S3.1: Construct a functional dependency graph based on the aforementioned dependency relationship, wherein the functional dependency graph is used to represent the dependency associations between functions, and the nodes of the functional dependency graph are functions, and the edges are dependency relationships;

[0141] Specifically, functional dependencies in engineering are not simply equivalent to execution order. They often encompass multiple semantics, including preconditions, parallel collaboration, mutual exclusion constraints, and binding constraints. Describing them solely as linear processes can easily lead to unstable expansion order, delayed constraint triggering, and difficulty in verifying dependency conditions during combinatorial expansion. Therefore, explicitly solidifying dependencies into a functional dependency graph ensures that each subsequent expansion can obtain a consistent basis for dependency determination through the graph structure. This allows for a unified understanding of when a function can be expanded and what preconditions must be met for that expansion, thus preventing inconsistent interpretations of dependencies across different expansion paths.

[0142] In this embodiment, the functional dependency graph uses functions as nodes and dependencies as directed edges. Each directed edge records edge attributes to characterize the dependency type and constraint content. Edge attributes include at least a dependency category field and a constraint parameter field. The dependency category field distinguishes between sequential dependencies, coexisting dependencies, mutually exclusive dependencies, and binding dependencies. The constraint parameter field carries necessary verification information related to the dependency, such as the required data semantic type of the preceding functions, the allowed set of interface protocols, resource ceiling conditions that must be met, or the identifiers of function groups that must be selected simultaneously. For functions with multiple preceding dependencies, their preceding node set is recorded to form preceding satisfaction conditions. These preceding satisfaction conditions can be in the logical form of satisfying all or at least one of them.

[0143] Those skilled in the art will understand that this logical form can be given in the function definition phase or determined by the dependency configuration rules, as long as it can be determined whether the function has the conditions to be extended when it is extended.

[0144] S3.2: Initialize a combination queue to be expanded, wherein the combination queue to be expanded is used to store partial combination states that have not yet been completed, the partial combination states are used to characterize the combination results for which implementation schemes have been selected for at least some functions in the function set, the partial combination states include at least one implementation scheme, when the combination queue to be expanded is initialized, the partial combination states are empty combination states, the empty combination states are used to characterize the initial combination for which no implementation scheme has been selected for any function in the function set;

[0145] Specifically, the combination generation process requires maintaining a large number of intermediate combinations that are not yet complete but have further expansion value. Without a unified method for carrying these intermediate states, the expansion process is prone to problems such as scattered intermediate results, uncontrollable expansion order, and difficulty in performing consistency checks before expansion. By using a queue of combinations to be expanded to centrally manage intermediate combinations, each expansion is based on retrieving a partial combination state from the queue, generating a new combination state, and then writing it back. This allows the expansion process to be organized as an iterative pipeline, facilitating the insertion of constraint verification, priority selection, and deduplication operations before and after expansion.

[0146] In this embodiment, an empty combination state is written during the initialization of the combination queue to be expanded. The empty combination state includes at least the following fields:

[0147] The system includes fields for the selected implementation scheme set, the covered function set, the resource accumulation field, the interface association field, and the status identifier field. The selected implementation scheme set field and the covered function set field are empty. The resource accumulation field records the initial values ​​of various resource consumption, including at least the initial occupancy of computing power, storage, energy, and space. The interface association field records the currently formed inter-function interface connection pairs and is initially empty. The status identifier field uniquely identifies the combined status. An empty combined status can use a fixed identifier or an identifier generated from an empty set.

[0148] Those skilled in the art will understand that the field provides space for subsequent incremental merging and consistency verification, avoiding repeated recalculation of the accumulated resources and interface information of the selected scheme from the outside during the expansion process.

[0149] It is important to note that the empty combinatorial state does not represent a candidate solution that can be directly output. Instead, it serves as the starting point for the combinatorial generation search, allowing all subsequent combinatorial states to be obtained through incremental expansion of this empty combinatorial state or its derived states. This avoids pre-setting specific functions or implementation schemes at the search's starting stage, ensuring the generality and consistency of the search process. During the initial iteration of combinatorial generation, the empty combinatorial state is only used to trigger the first round of expansion and does not participate in subsequent repeated enqueueing and expansion. Specifically, the implementation is as follows:

[0150] When the queue of combinations to be expanded contains only the empty combination state, it is taken as the current partial combination state. Based on the functional dependency graph, functions with empty preceding dependency function sets are selected as the starting function set. Subsequently, using the empty combination state as a benchmark, the next function to be expanded is selected from the starting function set, and each candidate implementation scheme corresponding to the function is merged with the empty combination state to generate the first batch of partial combination states containing at least one implementation scheme. The first batch of partial combination states is written into the queue of combinations to be expanded after passing consistency verification and deduplication. The empty combination state is no longer written into the queue after the first round of expansion, so that the queue of combinations to be expanded after the first round of expansion only contains non-empty partial combination states with practical engineering significance. In this way, the mechanisms such as expansion priority, constraint consistency verification, and state deduplication all apply to the real partial combination states in subsequent iterations, avoiding the interference of empty combination states with the search order and expansion logic.

[0151] refer to Figure 3 , Figure 3 This is a schematic diagram of the initialization structure of the combinatorial queue to be expanded, provided in an embodiment of this application.

[0152] like Figure 3 As shown, the queue to be expanded initially contains only one element: an empty combination state. This empty combination state is not semantically blank; rather, it represents a valid combination state where no functional selection has been made. This state possesses a complete data structure (e.g., fields such as the set of covered functions, the set of selected implementation schemes, resource accumulation, interface association, and status identifier are all established), except that the set of selected implementation schemes and the set of covered functions are null, indicating that no implementation scheme has been selected for any function at present. Therefore, Figure 3 This means that the initialization of the queue does not start from several specific implementation schemes, but from a unified, unbiased initial state, so that subsequent expansion actions can occur under the same state machine semantics, avoiding the introduction of implicit biases by pre-setting the initial function or the initial implementation method at the search starting point stage.

[0153] It is important to emphasize that the criteria for determining the next feature to be expanded do not come from what is already in the empty combination, but from which features in the feature dependency graph are eligible for expansion in the current state.

[0154] In this embodiment, the rule for determining extended eligibility is as follows:

[0155] For any function, if its set of preceding dependent functions is already included in the set of covered functions of the current partial combinatorial state, then that function can be included in the candidate set of functions to be expanded. Since the set of covered functions in an empty combinatorial state is empty, only functions with empty sets of preceding dependent functions satisfy the inclusion relationship and are thus selected as the starting function set; these functions correspond to function nodes with empty incoming edges in the dependency graph, typically including functions whose selection can be determined independently without upstream input. Subsequently, a function in the starting function set is expanded based on the empty combinatorial state:

[0156] The candidate implementation schemes corresponding to the function are retrieved from the implementation scheme data package. One of the implementation schemes is added to the selected implementation scheme set, and the covered function set is synchronously updated to include the function. The resource accumulation field and interface association field are incrementally updated according to the parameters of the implementation scheme, thus obtaining the first batch of non-empty partial combination states. These non-empty partial combination states are enqueued after passing consistency checks and deduplication. Empty combination states are not written back to the queue after the first round of derivation, so that the queue only carries the combination states with practical engineering significance. Subsequent priority expansion and consistency checks are applied to these non-empty states, thus forming a sequence from... Figure 3 The shown initialization structure to the subsequent iterative expansion structure is a coherent state evolution chain, and there are no logical breakpoints where empty combinations cannot determine dependencies.

[0157] S3.3: Perform an iterative operation to sort the partial combination states according to a preset expansion priority to obtain the current partial combination state;

[0158] Specifically, after the combinatorial generation enters the iterative stage, the combinatorial queue to be expanded typically contains multiple incomplete partial combinatorial states. These partial combinatorial states differ significantly in terms of functional coverage, resource consumption, and interface formation. If they are simply retrieved and expanded one by one according to the enqueue order, a large amount of computational resources will inevitably be invested in combinatorial paths with low expansion potential in the early stages. For example, combinations with stringent interface conditions but no exposed conflicts, or combinations whose resource consumption is close to the budget limit but has not yet triggered the threshold. Such combinations often become infeasible only in subsequent functional expansions, resulting in the expansion budget being consumed by low-value paths. To avoid this problem, this embodiment introduces a local selection mechanism based on expansion priority while maintaining the queue as an intermediate state carrying structure. This allows each round of expansion to prioritize partial combinatorial states that are more likely to form feasible complete combinations.

[0159] In one example, sorting the partial combination states according to a preset expansion priority to obtain the current partial combination state includes:

[0160] From the head of the queue to be expanded, a preset number of implementation schemes are sequentially extracted according to the first-in-first-out rule to construct a candidate expansion subset;

[0161] For each implementation scheme in the candidate expansion subset, an expansion priority value is calculated based on the parameter information corresponding to the implementation scheme. The expansion priority value is used to characterize the matching degree of the implementation scheme in generating product candidate combinations that meet the feasibility requirements in subsequent expansions. The parameter information includes interface parameters, resource consumption parameters, and applicable condition parameters.

[0162] Based on the expansion priority value, a target implementation scheme is determined in the candidate expansion subset, and used as the current partial combination state for subsequent expansion;

[0163] The remaining implementation schemes are rewritten into the queue to be expanded according to the corresponding retrieval order.

[0164] In this embodiment, the expansion priority is not an evaluation of the final solution's quality, but rather a measure of the potential of the current partial combination state to continue expanding. Its calculation is based on the engineering information accumulated within the partial combination states. Specifically, for several partial combination states taken from the head of the queue to be expanded, a candidate expansion subset is constructed. The size of this subset can be determined based on the implementation resource configuration and is used for comparison within a limited scope rather than global sorting of the entire queue. For each partial combination state in the candidate expansion subset, an expansion priority value is calculated based on the interface parameters, resource consumption parameters, and applicable condition parameters corresponding to its selected implementation scheme.

[0165] Among them, the interface parameter is used to determine the range of acceptable interface types and their flexibility when the current combination state is expanded in the future. The fewer the interface constraints and the wider the compatibility range of the combination, the higher its expansion priority. The resource occupancy parameter is used to measure the remaining margin of the current combination state in terms of resources such as computing power, storage, energy or space. The more sufficient the resource margin, the less likely it is to trigger budget conflicts in the future expansion, and the higher its expansion priority. The applicability condition parameter is used to measure the degree of adaptation of the current combination state to the target working conditions or functional boundaries. The more fully the conditions are met, the higher the possibility of it continuing to expand to form a complete solution.

[0166] Furthermore, after obtaining the expansion priority values ​​of each part of the candidate expansion subset, the target part of the combination state that meets the preset selection rules is selected as the current part of the combination state for subsequent functional expansion operations. The selection rule can be to select the state with the highest expansion priority value, or to select the state whose expansion priority value falls within a preset threshold range. Those skilled in the art will understand that the specific form of the rule can be set according to the engineering side's preference for search width and search depth, as long as it ensures that a unique or finite number of objects to be expanded can be determined in each iteration. The remaining part of the combination state that is not selected is rewritten into the queue of combinations to be expanded in the order in which it was retrieved, thereby ensuring that these states still have the opportunity to continue to expand, but will not occupy expansion resources in the current round. In this way, this embodiment achieves effective guidance of the combination expansion order without destroying the queue structure or introducing global sorting costs, making the search process controllable when the scale increases, and creating more favorable triggering conditions for subsequent consistency verification and pruning mechanisms.

[0167] refer to Figure 4 , Figure 4 This is a schematic diagram illustrating the principle of the current partial combination state provided in the embodiments of this application.

[0168] like Figure 4 As shown, a certain combinatorial queue to be expanded includes implementation scheme 1, implementation scheme 2, implementation scheme 3, implementation scheme 4, and implementation scheme 5.

[0169] In some optional implementations, Figure 4 The "Implementation Schemes 1, 2, 3, 4, and 5" shown are not single-function implementation schemes, but rather represent different partial combination states. Each partial combination state already contains several implementation schemes corresponding to several functions, along with their accumulated resources, interfaces, and dependency information. In other words, each implementation scheme can be combined with multiple implementation schemes to generate a complete implementation scheme. In this way, the queue of combinations to be expanded carries multiple intermediate states that may continue to evolve into candidates for complete products at any given time, rather than a simple linear sequence.

[0170] In this embodiment, to avoid the computational burden of performing a full sort on the entire queue during the iteration process, while still effectively guiding the expansion order, a method is adopted to construct a candidate expansion subset by extracting a preset number of combined states from the front of the queue. For example... Figure 4 As shown, when the preset selection quantity is three, only the first, second and third implementation schemes located at the head of the queue are taken out from the queue in first-in-first-out order, forming a candidate expansion subset; the fourth and fifth implementation schemes located after them do not participate in the priority evaluation of this round of expansion, but are kept in the queue to wait for subsequent rounds of processing.

[0171] Those skilled in the art will understand that the preset selection quantity can be configured according to the combination scale, computing resources or search strategy, for example by a preset constant, a proportional value related to the queue length or dynamically adjusted according to the running status, and this application does not limit it in this regard.

[0172] Figure 4 The process of calculating and selecting extension priorities within the candidate extension subset is further illustrated. For implementation scheme 1, implementation scheme 2, and implementation scheme 3, the interface parameters, resource consumption parameters, and applicable condition parameters carried by the selected implementation schemes in their corresponding partial combination states are read. Combined with the dependency requirements of currently uncovered functions, the degree of matching of these schemes to form feasible complete combinations in subsequent extensions is evaluated to obtain the corresponding extension priority values, namely extension priority 1, extension priority 2, and extension priority 3.

[0173] Furthermore, after determining the target partial combination state (i.e., implementation scheme two as the current partial combination state), the unselected implementation scheme one and implementation scheme three are rewritten into the combination queue to be expanded according to their original extraction order, so that they are still retained in the subsequent search space and are not directly discarded because they are not selected. In some optional specific implementations, the enqueue order can also be sorted according to the calculated expansion priority value. This application does not limit this.

[0174] S3.4: Based on the functional dependency graph, determine the next function to be expanded corresponding to the current partial combination state;

[0175] Specifically, some composite states may not cover all functionalities, and different functionalities have pre-existing dependencies, mutual exclusions, bindings, and other constraints. If it is not clear which functionality to extend next during the extension process, it is easy to extend to functionalities that do not yet meet the extension conditions, resulting in a large number of inevitable failures after the extension, or situations where dependency conditions are bypassed under different extension paths. Using a functional dependency graph to determine the next functionality to be extended ensures that the extension order is consistent with the dependency conditions, thereby guaranteeing that each new implementation solution is built on a verifiable dependency foundation.

[0176] In one example, determining the next feature to be expanded corresponding to the current partial combination state based on the functional dependency graph includes:

[0177] Obtain the set of functions corresponding to the selected implementation schemes in the current partial combination state, and use it as the set of completed functions;

[0178] Based on the functional dependency graph, a set of candidate functions to be expanded is determined, wherein the set of candidate functions to be expanded includes functions that meet the following conditions: the function is not included in the set of completed functions, and all the preceding dependent functions of the function in the functional dependency graph are included in the set of completed functions.

[0179] When the candidate set of functions to be expanded contains multiple functions, the next function to be expanded is determined from the candidate set of functions to be expanded according to a preset function selection rule, wherein the function selection rule is determined according to the topological order, dependency in-degree, resource requirements and interface constraint strength of the function dependency graph.

[0180] S3.5: Select an implementation scheme corresponding to the next function to be expanded from the implementation scheme data package to generate a combined state;

[0181] Specifically, after the combination generation enters the stage of merging specific implementation schemes, the next function to be extended already has the conditions for expansion at the dependency constraint level. However, this does not mean that all its candidate implementation schemes can coexist with the current partial combination state. In actual engineering, different implementation schemes have significant differences in interface form, resource consumption characteristics, and applicable environment assumptions. If candidate implementation schemes are merged into the current partial combination state one by one without distinction, it is very easy to form a large number of combination branches that will inevitably be rejected in subsequent steps in the early stage of combination generation, thereby increasing unnecessary state generation and verification overhead. Therefore, in this embodiment, the selection of implementation schemes is not a simple enumeration and merging, but rather a preliminary compatibility screening of candidate implementation schemes based on the engineering information carried by the current partial combination state as the constraint background, so that the implementation schemes entering the merging process have a basis for validity at the levels of interface semantics, resource budget, and applicable conditions.

[0182] In one example, selecting an implementation scheme corresponding to the next function to be extended from the implementation scheme data package to generate a combined state includes:

[0183] Obtain a set of candidate implementation schemes corresponding to the next function to be expanded from the implementation scheme data package;

[0184] Based on the current partial combination state and the parameter information corresponding to each candidate implementation scheme in the candidate implementation scheme set, a target implementation scheme set compatible with the current partial combination state is determined.

[0185] At least one target implementation scheme is selected from the set of target implementation schemes according to a preset implementation scheme selection rule, wherein the implementation scheme selection rule is determined by calculating a matching degree index based on the parameter information and selecting the target implementation scheme with the highest matching degree from the set of target implementation schemes according to the matching degree index;

[0186] The target implementation scheme is merged with the implementation schemes already selected in the current partial combined state to obtain the combined state.

[0187] In this embodiment, firstly, the set of candidate implementation schemes corresponding to the next function to be expanded is read from the implementation scheme data package, and the interface parameters, resource consumption parameters, and applicable condition parameters carried by each candidate implementation scheme are extracted one by one. Then, these parameters are compared and analyzed with the interface association fields and resource accumulation fields accumulated in the current partial combination state: at the interface level, it is checked whether the input / output interface types, data formats, and timing characteristics required by the candidate implementation scheme can be consistent with the interface constraints formed in the current combination state or can be completed through existing interfaces; at the resource level, the resource consumption parameters of the candidate implementation scheme are simulated and superimposed onto the resource accumulation field of the current combination state to determine whether they still fall within the preset resource constraint range; at the applicable condition level, it is verified whether the assumptions of the candidate implementation scheme regarding the operating environment, functional prerequisites, or configuration conditions conflict with the conditions determined in the current combination state. Only when a candidate implementation scheme does not trigger incompatibility in the above multiple dimensions is it included in the target implementation scheme set, thereby eliminating obviously infeasible branches at the implementation scheme selection stage.

[0188] Furthermore, after obtaining the set of target implementation schemes, this embodiment does not mechanically incorporate all schemes into the current partial combination state simultaneously. Instead, it selects at least one target implementation scheme to generate a new combination state through a preset implementation scheme selection rule. The implementation scheme selection rule is based on a matching degree index, and its calculation is also derived from the parameter information of the implementation scheme and the accumulated information of the current combination state, for example:

[0189] The higher the degree of interface matching, the closer the resource consumption is to the budget limit but not exceeding the budget limit, and the more relaxed the input and output constraints on subsequent expansion functions, the higher the matching degree index.

[0190] Those skilled in the art will understand that the specific composition and weighting of the matching index can be adjusted according to the specific product type and engineering focus, as long as a stable ranking can be formed among multiple compatible solutions.

[0191] Finally, the selected target implementation scheme is merged with the selected implementation schemes in the current partial combined state, and the covered function set, resource accumulation field, interface association field, and status identifier are updated synchronously to obtain a new partial combined state. In this way, the generation process of the combined state is always based on a clear engineering compatibility judgment, which makes the search space continuously converge during the expansion process, providing a reliable premise for subsequent consistency verification and candidate output.

[0192] S3.6: Write the combined state into the queue of combinations to be expanded to update the partial combined state until the preset termination condition is met, and output the partial combined state as a product candidate combination;

[0193] Specifically, writing a combination state to the queue is not a simple enqueueing action. Before writing, consistency checks and deduplication must be performed on the new combination to prevent invalid combinations from entering the queue and wasting subsequent expansions, and to avoid repeated occurrences of equivalent combinations leading to redundant expansions. Embedding consistency checks and index deduplication into the write action ensures that elements in the combination queue to be expanded always remain in an intermediate state that is meaningful for further expansion and has not been repeatedly processed, thus guaranteeing that the iteration process remains controllable as the candidate size grows.

[0194] In one example, writing the combined state to the expanded combined queue to update a portion of the combined state includes:

[0195] During the expansion process, based on the interface parameters, resource consumption parameters and dependency constraints represented by the functional dependency graph in the implementation scheme data package, the combined state is subjected to constraint consistency verification, and the combined state that fails the constraint consistency verification is pruned.

[0196] A combined state identifier is generated for the combined states that pass the constraint consistency check, and an index record is established based on the combined state identifier, wherein the constraint consistency check includes:

[0197] Perform interface consistency verification by matching the interface parameters of the newly added target implementation scheme in the combined state with the interface parameters of the selected implementation scheme in the current partial combined state, and determine whether one or more of the data type, protocol type, data rate, and timing constraints meet the preset interface matching rules.

[0198] After passing the interface consistency check, a resource budget consistency check is performed to accumulate the resource consumption vector based on the resource usage parameters of each selected implementation scheme in the combined state, and compare the resource consumption vector with a preset resource budget threshold to determine whether the budget is exceeded.

[0199] After passing the resource budget consistency check, a dependency constraint consistency check is performed to determine whether the combined state satisfies the coexistence constraints, mutual exclusion constraints, and sequence constraints between functions based on the dependency constraints represented by the functional dependency graph.

[0200] Among them, when any consistency check fails, the combined state corresponding to pruning is determined.

[0201] Before writing the combined state into the combined queue to be expanded, the index record is queried to determine whether there is a recorded identifier that is the same as the combined state identifier;

[0202] When a recorded identifier that is identical to the combined state identifier exists, the duplicate combined state is pruned, and the remaining combined states are written into the combined state queue to be expanded.

[0203] If there is no recorded identifier that is the same as the combined state identifier, the combined state is written into the combined queue to be expanded.

[0204] Understandably, during the iterative process of combinatorial generation, new combinatorial states are continuously generated by expansion actions. If the conditions for writing these states into the queue are not constrained, the queue of combinations to be expanded can easily become filled with a large number of states that are not engineering-wise capable of further evolution. Consequently, in subsequent expansion stages, computational resources are consumed without generating effective output. Therefore, in this embodiment, a complete state confirmation process is required before writing a combinatorial state into the queue of combinations to be expanded, rather than a simple data enqueue operation. This process involves consistency checks based on three types of constraints: interface, resources, and dependencies. This ensures that only combinatorial states that are engineering-wise reasonable at the current stage are allowed to enter the queue, thus ensuring that each element in the queue represents an intermediate result that still has expansion potential under existing constraints.

[0205] In this embodiment, consistency checks are performed sequentially in the order of interface consistency, resource budget consistency, and dependency constraint consistency to reduce unnecessary computational overhead. First, in the interface consistency check phase, the interface parameters of the newly added target implementation scheme are read and compared with the interface association information already formed in the current partial combination state. The focus is on checking for conflicts or inconsistencies in interface type, data format, communication protocol, data rate, and timing requirements. If the interface conditions required by the new scheme cannot be met in the current combination state, the combination state is directly determined to be inconsistent and pruned, and will not proceed to subsequent check phases. Subsequently, provided the interface consistency check passes, a resource budget consistency check is performed. The resource consumption parameters of each selected implementation scheme in the combination state are accumulated to form the resource consumption vector corresponding to the current combination state. This vector is then compared dimension-by-dimensionally with a preset resource budget threshold. If any resource dimension exceeds the allowable range, the combination state is considered difficult to further expand in engineering and is pruned. Furthermore, after passing the resource budget consistency check, a dependency constraint consistency check is performed. Based on the functional dependency graph, it checks whether the covered function sets in the composite state meet the predefined functional coexistence constraints, mutual exclusion constraints, and sequence constraints, thereby avoiding the formation of functional combinations that are logically invalid or violate design assumptions.

[0206] After completing the consistency check, to prevent equivalent combination states from repeatedly appearing and being processed multiple times under different expansion paths, this embodiment introduces a combination state identifier and index deduplication mechanism before writing to the combination queue to be expanded. Specifically, a combination state identifier is generated for the combination states that have passed the consistency check. This identifier can be constructed based on the selected implementation scheme set, resource consumption vector, and interface association features to uniquely characterize the engineering semantics of the combination state. Before writing to the queue, the index records are checked to see if a record corresponding to the combination state identifier already exists. If it exists, it indicates that the combination state has appeared or been processed in other expansion paths, and the currently generated duplicate state is directly pruned and no longer enqueued. If it does not exist, the combination state is written to the combination queue to be expanded, and the corresponding identifier is registered in the index records. By embedding the consistency check and state deduplication into the queue writing process, the combination queue to be expanded is always maintained as a set of non-repeating, scalable intermediate states that meet engineering constraints. This ensures the stability and controllability of the iterative process even as the search space continues to expand, and lays a reliable foundation for the output of the final product candidate combinations.

[0207] It is important to emphasize that the preset termination conditions in this application are not fixed, single judgment criteria, but rather a control mechanism for the controlled convergence of the combinatorial generation search process. Those skilled in the art can flexibly configure them according to actual application needs. It is understood that the preset termination conditions at least indicate under what circumstances the currently obtained partial combinatorial states are reasonable as candidate product combinations, or that further expansion is no longer engineering meaningful, thereby preventing the unbounded expansion of the combinatorial generation process.

[0208] Specifically, the preset termination condition can be: the set of functions covered in the current partial combination state includes all functions in the set of functions, that is, the combination state has selected the corresponding implementation scheme for all target functions. At this time, the combination state is complete in terms of function and can be directly output as a product candidate combination; or, a preset number of complete product candidate combinations have been accumulated during the combination generation process to meet the needs of subsequent scheme evaluation or comparative analysis. In this case, even if there are still some incomplete combination states in the combination queue to be expanded, the iteration can be terminated and the obtained candidate results can be output.

[0209] For example, the following numerical example is provided to illustrate how to calculate the extended priority value, matching degree index and resource consumption vector within the technical framework of this application. This example is only used to explain the relationship between the operation link and the units. The selected parameters and values ​​are illustrative and do not represent the actual calibration results or engineering recommended values.

[0210] In this example, the product to be designed has four functional sets: Function F1: Sensing function; Function F2: Processing / Decision-making function; Function F3: Execution function; Function F4: Support / Power supply function. The functional dependencies are defined as follows: F2 depends on F1, F3 depends on F2; F4 is an independent function (not a prerequisite dependency, but participates in resource budget and applicable condition constraints). Based on this, a functional dependency graph is constructed: nodes are F1~F4, and edges are (F1→F2) and (F2→F3). Simultaneously, the preset system-level resource budget thresholds (resource budget vector) are: computing power budget: 10 TOPS, storage budget: 4096MB, power consumption budget: 20W, and preset interface / data constraints: the data link rate from F1 to F2 must be no less than 50 Mbps.

[0211] For demonstration purposes, candidate implementation schemes for each function are provided (each scheme includes interface parameters, resource consumption parameters, and applicable condition parameters):

[0212] The candidate implementation schemes for F1 are as follows: Scheme F1-A: Interface = Ethernet (100Mbps), computing power = 1 TOPS, storage = 256MB, power consumption = 2W, applicable conditions = no special restrictions. Scheme F1-B: Interface = CAN-FD (8Mbps), computing power = 0.5 TOPS, storage = 128MB, power consumption = 1W, applicable conditions = no special restrictions.

[0213] The candidate implementation schemes for F2 are as follows: Scheme F2-A: Input interface = Ethernet (≥50Mbps), computing power = 6 TOPS, storage = 1024MB, power consumption = 8W, applicable conditions = no special restrictions. Scheme F2-B: Input interface = CAN-FD (≤10Mbps), computing power = 3 TOPS, storage = 512MB, power consumption = 6W, applicable conditions = link rate ≥50Mbps required (this condition contradicts the typical rate of CAN-FD and is used to demonstrate pruning).

[0214] The candidate implementation scheme set for F3: Scheme F3-A: Control interface = SPI (20Mbps), computing power = 2TOPS, storage = 512MB, power consumption = 5W, applicable conditions = no special restrictions.

[0215] The candidate implementation schemes for F4 are as follows: Scheme F4-A: Power supply capacity = 15W upper limit (equivalent constraint: system power budget threshold is min(20W,15W)=15W), self-power consumption = 0W (ignored), applicable conditions = no special restrictions. Scheme F4-B: Power supply capacity = 25W upper limit (equivalent constraint: system power budget threshold is min(20W,25W)=20W), self-power consumption = 0W (ignored), applicable conditions = no special restrictions.

[0216] Initialize the queue Q to be expanded. The queue initially contains only an empty combination state S0. According to the functional dependency graph, the expandable functions in the empty combination state are the set of functions with an in-degree of 0: {F1, F4}. For example, select the next function to be expanded as F1 according to the preset function selection rules (e.g., "the one with higher interface constraint strength takes priority"). Select F1-A and F1-B from the implementation scheme data package to generate two combination states: combination state S1 = S0 + F1-A; resource consumption vector R(S1) = (1TOPS, 256MB, 2W); combination state S2 = S0 + F1-B; resource consumption vector R(S2) = (0.5TOPS, 128MB, 1W). Neither of them triggers interface consistency conflict (no cross-functional interface docking has occurred) nor exceeds the resource budget, so they are written into the queue: Q = [S1, S2]; the preset number is set to 2, that is, in each round, two partial combination states are taken from the head of the queue in a first-in-first-out manner to construct a candidate expansion subset: {S1, S2}. Further exemplification: The calculation of the extension priority value P adopts a weighted model (for illustration only; specific weights are configurable): P = 0.5 × I + 0.4 × M + 0.1 × Y, where: I is the "Interface Scalability Score" (0~100): illustratively, it is truncated and normalized based on "currently determined output link rate / subsequent minimum required rate", I = min(output rate / 50Mbps, 1) × 100. M is the "Resource Margin Score" (0~100): illustratively, the minimum value of the three-dimensional margins of computing power / storage / power consumption is taken as the bottleneck margin. For any resource dimension, the margin ratio = (budget - used) / budget, M = min(three-dimensional margin ratio) × 100. Y is the "Applicability Condition Satisfaction Score" (0~100): In this example, all applicable conditions are satisfied, so it is set to 100.

[0217] For S1: S1's F1 output rate = 100 Mbps, therefore the interface scalability score I(S1) = min(100 / 50, 1) × 100 = 100, and the resource margin ratios are: computing power margin 0.9; storage margin 0.9375; power consumption margin 0.9; resource margin score M(S1) = min(0.9, 0.9375, 0.9) × 100 = 90; applicability satisfaction score Y(S1) = 100.

[0218] Therefore, the extended priority value P(S1) = 0.5 × 100 + 0.4 × 90 + 0.1 × 100 = 96.

[0219] For S2: S2's F1 output rate = 8 Mbps, therefore the interface scalability score I(S2) = min(8 / 50,1)×100 = 16; the resource margin ratios are: computing power margin 0.95; storage margin 0.96875; power consumption margin 0.95; that is, the resource margin score M(S2) = min(0.95,0.96875,0.95)×100 = 95; the applicability condition satisfaction score Y(S2) = 100.

[0220] Therefore, the extended priority value P(S2) = 0.5 × 16 + 0.4 × 95 + 0.1 × 100 = 56.

[0221] Accordingly, the candidate with the higher P value is selected as the current partial combination state from the candidate extended subset, that is, S1 is selected as the current partial combination state; the remaining states S2 are backfilled to the tail of the queue in the order of extraction.

[0222] In the current partial combination state S1, the set of completed functions is {F1}.

[0223] In the functional dependency graph, the set of candidate functions to be expanded that satisfy "not completed and all its predecessors have been completed" is: F2: its predecessor is F1, which has been satisfied; F4: it has no predecessors, which has been satisfied.

[0224] When the candidate set contains multiple functions, the next function to be expanded is determined as F2 according to the rule of "topological order first and the one with greater in-degree dependency first" (because F2 takes over the main link F1→F2→F3, and the interface constraints are exposed earlier, which is more conducive to pruning).

[0225] Obtain the candidate implementation scheme set {F2-A, F2-B} of F2 from the implementation scheme data package, and filter the set of compatible target implementation schemes based on the current partial combination state S1.

[0226] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A method for generating product alternatives centered on functional data, characterized in that, The method includes: Obtain the set of functions for the product to be designed, and construct a function data package based on each function in the set of functions; A corresponding set of candidate implementation schemes is established based on the functional data package, and the set of candidate implementation schemes is summarized to obtain the implementation scheme data package; Based on the dependencies of each function in the function set, a product candidate combination is generated and searched to select implementation schemes from the implementation scheme data package for combination, thereby obtaining a product candidate combination, and the product candidate combination is output as a product alternative scheme. Based on the dependencies between the functions in the function set, a product candidate combination is generated and searched to select implementation schemes from the implementation scheme data package for combination, resulting in a product candidate combination, including: A functional dependency graph is constructed based on the aforementioned dependency relationships, wherein the functional dependency graph is used to represent the dependency associations between various functions, and the nodes of the functional dependency graph are functions, and the edges are dependency relationships; Initialize a combination queue to be expanded, wherein the combination queue to be expanded is used to store partial combination states that have not yet been completed, the partial combination states are used to characterize the combination results for which implementation schemes have been selected for at least some functions in the function set, the partial combination states include at least one implementation scheme, and when the combination queue to be expanded is initialized, the partial combination states are empty combination states, the empty combination states are used to characterize the initial combination for which no implementation scheme has been selected for any function in the function set; Perform iterative operations, sort the partial combination states according to the preset expansion priority to obtain the current partial combination state, determine the next function to be expanded corresponding to the current partial combination state based on the functional dependency graph, select the implementation scheme corresponding to the next function to be expanded from the implementation scheme data package to generate a combination state, and write the combination state into the combination queue to be expanded to update the partial combination state until the preset termination condition is met, and output the partial combination state as a product candidate combination; Writing the combined state to the expanded combined queue to update a portion of the combined state includes: During the expansion process, based on the interface parameters, resource consumption parameters and dependency constraints represented by the functional dependency graph in the implementation scheme data package, the combined state is subjected to constraint consistency verification, and the combined state that fails the constraint consistency verification is pruned. A combined state identifier is generated for the combined states that pass the constraint consistency check, and an index record is established based on the combined state identifier; Before writing the combined state into the combined queue to be expanded, the index record is queried to determine whether there is a recorded identifier that is the same as the combined state identifier; When a recorded identifier that is identical to the combined state identifier exists, the duplicate combined state is pruned, and the remaining combined states are written into the combined state queue to be expanded. If there is no recorded identifier that is the same as the combined state identifier, the combined state is written into the combined queue to be expanded.

2. The product alternative generation method centered on functional data according to claim 1, characterized in that, The set of functions includes multiple functions for achieving the product's target tasks, and the multiple functions include at least one of the following: Sensing functions used to perceive the external environment; Processing functions used for processing and making decisions based on perceived data; Execution functions used to perform physical actions; A power supply function to ensure the energy supply for the sensing, processing and execution functions; The multiple functions are associated with each other through functional dependencies, which are used to characterize the order, collaboration, and constraints among the functions.

3. The product alternative generation method centered on functional data according to claim 2, characterized in that, Construct a function data package based on each function in the function set, including: Establish a corresponding function identifier for each function, and obtain the function input information and function output information associated with the function identifier; Configure at least one functional performance indicator for the function, wherein the functional performance indicator is used to characterize the performance requirements of the function in the process of performing the product target task; Configure functional resource requirement parameters for the function, wherein the functional resource requirement parameters include computing power requirement, storage requirement, energy requirement, time constraint and space constraint; Establish a functional interface description for the function, wherein the functional interface description is used to characterize the data interaction method and interaction constraints between the function and other functions; The function input information, function output information, function performance indicators, function resource requirement parameters, and function interface description are summarized to generate the function data package corresponding to the function.

4. The product alternative generation method centered on functional data according to claim 1, characterized in that, Based on the aforementioned functional data package, a corresponding set of candidate implementation schemes is established, including: For each function in the function set, based on the corresponding function data package, at least one implementation method corresponding to the function is obtained, wherein the implementation method includes a software implementation method, a hardware implementation method, and a software and hardware co-implementation method; For each implementation method, obtain the implementation parameters required to implement the function through the corresponding implementation method, wherein the implementation parameters include at least one of the interface parameters, resource consumption parameters, and applicable condition parameters; Based on the aforementioned implementation parameters, a corresponding implementation scheme data unit is generated for each implementation method; The implementation scheme data units corresponding to each function in the function set are collected to generate the candidate implementation scheme set.

5. The product alternative generation method centered on functional data according to claim 1, characterized in that, The step of sorting the partial combination states according to a preset expansion priority to obtain the current partial combination state includes: From the head of the queue to be expanded, a preset number of implementation schemes are sequentially extracted according to the first-in-first-out rule to construct a candidate expansion subset; For each implementation scheme in the candidate expansion subset, an expansion priority value is calculated based on the parameter information corresponding to the implementation scheme. The expansion priority value is used to characterize the matching degree of the implementation scheme in generating product candidate combinations that meet the feasibility requirements in subsequent expansions. The parameter information includes interface parameters, resource consumption parameters, and applicable condition parameters. Based on the expansion priority value, a target implementation scheme is determined in the candidate expansion subset, and used as the current partial combination state for subsequent expansion; The remaining implementation schemes are rewritten into the queue to be expanded according to the corresponding retrieval order.

6. The product alternative generation method centered on functional data according to claim 5, characterized in that, Based on the functional dependency graph, determine the next function to be expanded corresponding to the current partial combination state, including: Obtain the set of functions corresponding to the selected implementation schemes in the current partial combination state, and use it as the set of completed functions; Based on the functional dependency graph, a set of candidate functions to be expanded is determined, wherein the set of candidate functions to be expanded includes functions that meet the following conditions: the function is not included in the set of completed functions, and all the preceding dependent functions of the function in the functional dependency graph are included in the set of completed functions. When the candidate set of functions to be expanded contains multiple functions, the next function to be expanded is determined from the candidate set of functions to be expanded according to a preset function selection rule, wherein the function selection rule is determined according to the topological order, dependency in-degree, resource requirements and interface constraint strength of the function dependency graph.

7. The method for generating product alternatives centered on functional data according to claim 1, characterized in that, Selecting an implementation scheme corresponding to the next function to be expanded from the implementation scheme data package to generate a combined state includes: Obtain a set of candidate implementation schemes corresponding to the next function to be expanded from the implementation scheme data package; Based on the current partial combination state and the parameter information corresponding to each candidate implementation scheme in the candidate implementation scheme set, a target implementation scheme set compatible with the current partial combination state is determined. At least one target implementation scheme is selected from the set of target implementation schemes according to a preset implementation scheme selection rule, wherein the implementation scheme selection rule is determined by calculating a matching degree index based on the parameter information and selecting the target implementation scheme with the highest matching degree from the set of target implementation schemes according to the matching degree index; The target implementation scheme is merged with the implementation schemes already selected in the current partial combined state to obtain the combined state.

8. The product alternative generation method centered on functional data according to claim 1, characterized in that, The constraint consistency check includes: Perform interface consistency verification by matching the interface parameters of the newly added target implementation scheme in the combined state with the interface parameters of the selected implementation scheme in the current partial combined state, and determine whether one or more of the data type, protocol type, data rate, and timing constraints meet the preset interface matching rules. After passing the interface consistency check, a resource budget consistency check is performed to accumulate the resource consumption vector based on the resource usage parameters of each selected implementation scheme in the combined state, and compare the resource consumption vector with a preset resource budget threshold to determine whether the budget is exceeded. After passing the resource budget consistency check, a dependency constraint consistency check is performed to determine whether the combined state satisfies the coexistence constraints, mutual exclusion constraints, and sequence constraints between functions based on the dependency constraints represented by the functional dependency graph. Among them, when any constraint consistency check fails, the combined state corresponding to pruning is determined.

Images