Product configuration management and generation method and related device

Abstract

The present application discloses a product configuration management and generation method and a related device. The product configuration management and generation method comprises: acquiring first intent information, the first intent information being used for instructing to perform configuration management on a product; determining a first management object of the product, the attribute of the first management object and the value of the attribute of the first management object on the basis of the first intent information; and generating configuration information of the product on the basis of the first management object, the attribute of the first management object and the value of the attribute of the first management object. According to the embodiments of the present application, configuration information of a product can be generated on the basis of a first management object, the attribute of the first management object and the value of the attribute of the first management object which are parsed from a user intent, without the need for human to master highly complex domain knowledge, and the configuration information of the product can be formulated by means of research, discussion, etc., helping to improve the generation efficiency of configuration information.

Description

A product configuration management and generation method and related device

[0001] This application claims priority to the Chinese patent application with application number 202311706587.3 filed with the State Intellectual Property Office of China on December 12, 2023, and priority to the Chinese patent application with the invention name “A product configuration management and generation method and related devices”, all contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the technical field of network products, and in particular to a product configuration management and generation method and related devices. Background Art

[0003] The configuration parameters and feature activation of network services or products are subject to a large number of scenario constraints. For example, in a configuration scenario for wireless network equipment, Parameter 1 and Parameter 2 have a mutually exclusive constraint relationship. These constraints are compiled into rule codes using different languages ​​during the product development process for verification of subsequent configuration scenarios. Currently, the formulation, review, and issuance of product configurations are largely completed manually. For example, the configuration files for network elements, base stations, and other equipment require on-site research by business experts and then design through expert discussions. After the design is completed, the configuration files must undergo multiple verification and review processes. The entire process not only requires a high level of business knowledge, but is also time-consuming and difficult. Therefore, how to improve the efficiency of generating product configuration files is one of the current issues that need to be addressed.

[0004] Summary of the Invention

[0005] The embodiments of the present application provide a product configuration management and generation method and related devices, which can extract product management objects, object attributes and other information based on the intention information input by the user, and generate product configuration information based on this information, thereby helping to improve the efficiency of product configuration generation.

[0006] In a first aspect, an embodiment of the present application provides a product configuration management and generation method, the method comprising:

[0007] Obtaining first intent information; the first intent information is used to instruct configuration management of the product;

[0008] Determining a first management object of the product, an attribute of the first management object, and a value of the attribute of the first management object based on the first intent information;

[0009] Configuration information of the product is generated based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object.

[0010] It can be seen that in the embodiment of the present application, the electronic device can determine the first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object that the user needs to configure through semantic recognition when the user inputs the first intention information for configuring and managing the product, thereby being able to generate the configuration information of the product based on the parsed first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object, without the need for manual mastery of highly difficult domain knowledge and formulating the configuration information of the product through research, discussion, etc., which is conducive to improving the efficiency of generating configuration information.

[0011] In one possible implementation, after generating the configuration information of the product based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the method further includes:

[0012] Obtaining constraint rules associated with the first management object and attributes of the first management object;

[0013] detecting whether configuration information of the product satisfies constraint rules associated with the first management object and attributes of the first management object;

[0014] If the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

[0015] In this implementation, since the product configuration information and all constraint rules associated with the attributes of the first management object are obtained through unified compilation, there is no need to repeatedly compile the configuration information according to the compilation syntax of each constraint rule during the satisfiability check, which is beneficial to improving the efficiency of the configuration information satisfiability check, and further beneficial to improving the efficiency of configuration distribution.

[0016] In one possible implementation, the first intent information includes a first named entity of a first management object and a second named entity of an attribute of the first management object; and generating product configuration information based on the first management object, the attribute of the first management object, and a value of the attribute of the first management object includes:

[0017] Obtain a first canonical code of a first management object and a second canonical code of an attribute of the first management object;

[0018] Replacing the first named entity in the first intent information with the first canonical encoding, and replacing the second named entity in the first intent information with the second canonical encoding, to obtain second intent information;

[0019] Configuration information of the product is generated based on the second intent information.

[0020] In this implementation, the electronic device uses the first standard encoding of the first management object and the second standard encoding of the attribute of the first management object to replace the first named entity and the second named entity in the first intent information respectively, so as to obtain the second intent information that is easier for the machine to understand, thereby generating product configuration information based on the second intent information.

[0021] In a possible implementation, the method further includes:

[0022] If there is a constraint rule that cannot be satisfied by the configuration information of the product among the constraint rules associated with the first management object and the attribute of the first management object, the constraint rule that cannot be satisfied by the configuration information of the product is output.

[0023] In this implementation, if there are constraint rules in the database that cannot be satisfied by the generated configuration information, the electronic device can output the constraint rules to facilitate the user to modify the first intention information and generate configuration information that satisfies the constraint rules associated with the attributes of the first management object.

[0024] In one possible implementation, before obtaining the first intent information, the method further includes:

[0025] Obtaining third intent information; the third intent information is used to indicate constraint rules for generating products;

[0026] determining a second management object of the product, an attribute of the second management object, and an attribute constraint of the attribute of the second management object based on the third intent information;

[0027] A constraint rule for the product is generated based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object.

[0028] In this implementation, when the user inputs third intention information for generating rules for a product, the electronic device can determine the second management object, the attributes of the second management object, and the attribute constraints of the attributes of the second management object for which the user needs to generate constraint rules through semantic recognition. In this way, the constraint rules for the product can be generated based on the parsed second management object, the attributes of the second management object, and the attribute constraints, without the need for manual mastery of highly difficult domain knowledge and a large amount of coding knowledge to design the constraint rules for the product, which is conducive to improving the efficiency of generating constraint rules.

[0029] In a possible implementation, the method further includes:

[0030] Perform conflict and redundancy checks on the generated constraint rules and the existing rules of the product;

[0031] Output the detection results.

[0032] In this implementation, the electronic device can use formal technology to perform conflict detection and redundancy detection on the generated constraint rules and the existing rules of the product to ensure the accuracy of the constraint rules, which is conducive to improving the efficiency of the constraint rule formulation process.

[0033] In one possible implementation, if the generated constraint rule has a conflicting relationship with one or more first existing rules, the detection result includes one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes one or more second existing rules.

[0034] In this implementation, the electronic device can output existing rules that conflict with or are redundant with the generated constraint rules, so that designers can modify or delete these rules, or modify the constraint rules based on these rules to optimize the constraint rules of the product.

[0035] In one possible implementation, the method includes:

[0036] Use unified compilation to compile the generated constraint rules to obtain the rules to be stored in the unified programming language;

[0037] Store the rules to be stored.

[0038] In this implementation, the generated constraint rules are compiled uniformly before being stored in the database. When the configuration information is subsequently generated, it only needs to be compiled uniformly once to perform satisfiability verification with the existing rules in the database. When the rules and configurations are compiled uniformly, it is beneficial to improve the efficiency and accuracy of subsequent satisfiability verification.

[0039] In one possible implementation, the third intent information includes a third named entity of the second management object and a fourth named entity of the attribute of the second management object; and generating a constraint rule for the product based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object includes:

[0040] Obtain a third canonical code of the second management object and a fourth canonical code of the attribute of the second management object;

[0041] Replacing the third named entity in the third intent information with a third canonical encoding, and replacing the fourth named entity in the third intent information with a fourth canonical encoding, to obtain fourth intent information;

[0042] Generate product constraint rules based on the fourth intent information.

[0043] In this implementation, the electronic device uses the third canonical encoding of the second management object and the fourth canonical encoding of the attribute of the second management object to replace the third named entity and the fourth named entity in the third intent information respectively, so as to obtain the fourth intent information that is easier for the machine to understand, thereby generating product constraint rules based on the fourth intent information.

[0044] In a second aspect, an embodiment of the present application provides a product configuration management and generation device, the device comprising an acquisition unit and a processing unit;

[0045] An acquiring unit, configured to acquire first intention information; the first intention information is used to instruct configuration management of the product;

[0046] A processing unit is used to determine the first management object of the product, the attributes of the first management object, and the values ​​of the attributes of the first management object based on the first intention information; and generate configuration information of the product based on the first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object.

[0047] In a possible implementation, the acquiring unit is further configured to acquire constraint rules associated with the first management object and the attributes of the first management object;

[0048] The processing unit is also used to detect whether the configuration information of the product meets the constraint rules associated with the first management object and the attributes of the first management object; if the configuration information of the product meets the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

[0049] In one possible implementation, the first intent information includes a first named entity of a first management object and a second named entity of an attribute of the first management object; and in generating product configuration information based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the processing unit is specifically configured to:

[0050] Obtain a first canonical code of a first management object and a second canonical code of an attribute of the first management object;

[0051] Replacing the first named entity in the first intent information with the first canonical encoding, and replacing the second named entity in the first intent information with the second canonical encoding, to obtain second intent information;

[0052] Configuration information of the product is generated based on the second intent information.

[0053] In a possible implementation, the processing unit is further configured to:

[0054] If there is a constraint rule that cannot be satisfied by the configuration information of the product among the constraint rules associated with the first management object and the attribute of the first management object, the constraint rule that cannot be satisfied by the configuration information of the product is output.

[0055] In a possible implementation, the acquiring unit is further configured to acquire third intention information; the third intention information is used to indicate constraint rules for generating a product;

[0056] The processing unit is also used to determine the second management object of the product, the attributes of the second management object, and the attribute constraints of the attributes of the second management object based on the third intention information; and generate constraint rules for the product based on the second management object of the product, the attributes of the second management object, and the attribute constraints of the attributes of the second management object.

[0057] In a possible implementation, the processing unit is further configured to:

[0058] Perform conflict and redundancy checks on the generated constraint rules and the existing rules of the product;

[0059] Output the detection results.

[0060] In one possible implementation, if the generated constraint rule has a conflicting relationship with one or more first existing rules, the detection result includes one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes one or more second existing rules.

[0061] In a possible implementation, the processing unit is further configured to:

[0062] Use unified compilation to compile the generated constraint rules to obtain the rules to be stored in the unified programming language;

[0063] Store the rules to be stored.

[0064] In one possible implementation, the third intent information includes a third named entity of the second management object and a fourth named entity of an attribute of the second management object; in terms of generating a constraint rule for the product based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object, the processing unit is specifically configured to:

[0065] Obtain a third canonical code of the second management object and a fourth canonical code of the attribute of the second management object;

[0066] Replacing the third named entity in the third intent information with a third canonical encoding, and replacing the fourth named entity in the third intent information with a fourth canonical encoding, to obtain fourth intent information;

[0067] Generate product constraint rules based on the fourth intent information.

[0068] It should be understood that since the method embodiment and the device embodiment are different presentation forms of the same technical concept, the content of the first aspect of the embodiment of the present application should be synchronously adapted to the second aspect of the embodiment of the present application, and can achieve the same or similar beneficial effects, and will not be repeated here.

[0069] In a third aspect, an embodiment of the present application provides an electronic device comprising a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to, when executed by the processor, cooperate with the communication interface to implement the method in any one of the embodiments of the first aspect above.

[0070] In a fourth aspect, an embodiment of the present application provides a chip, comprising: a processor for calling and running a computer program from a memory, so that a device equipped with the chip executes a method as in any one of the embodiments of the first aspect above.

[0071] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program for execution by a device, and when the computer program is executed, it implements the method in any one of the embodiments of the first aspect above.

[0072] In a sixth aspect, an embodiment of the present application provides a computer program product. When the computer program product is run by a device, the device executes the method in any one of the embodiments of the first aspect above. BRIEF DESCRIPTION OF THE DRAWINGS

[0073] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0074] FIG1 is a schematic diagram of the formulation, verification and storage of constraint rules in a related art;

[0075] FIG2 is a schematic diagram of the formulation, verification and issuance of a configuration in a related art;

[0076] FIG3 is a schematic diagram of a system architecture provided in an embodiment of the present application;

[0077] FIG4 is a flow chart of a product configuration management and generation method provided in an embodiment of the present application;

[0078] FIG5 is a schematic diagram of generating and managing configuration information based on a software system architecture according to an embodiment of the present application;

[0079] FIG6 is a schematic diagram of the overall process of generating, verifying, and issuing configuration information according to an embodiment of the present application;

[0080] FIG7 is a flow chart of another product configuration management and generation method provided in an embodiment of the present application;

[0081] FIG8 is a schematic diagram of generating and managing constraint rules based on a software system architecture according to an embodiment of the present application;

[0082] FIG9 is a schematic diagram of the overall process of generating, verifying, and storing a constraint rule according to an embodiment of the present application;

[0083] FIG10 is a schematic diagram of the structure of a product configuration management and generation device provided in an embodiment of the present application;

[0084] FIG11 is a schematic structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0085] The terms "first," "second," "third," and "fourth," etc., in the specification and claims of this application and the accompanying drawings are used to distinguish different objects, not to describe a specific order. In addition, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements, but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0086] References to "embodiments" herein mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0087] As used in this specification, the terms "component", "module", "system", etc. are used to represent computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program and / or a computer. By way of illustration, both an application running on a terminal device and a terminal device can be a component. One or more components can reside in a process and / or an execution thread, and a component can be located on a computer and / or distributed between two or more computers. In addition, these components can be executed from various computer-readable media having various data structures stored thereon. Components can communicate, for example, through local and / or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system and / or a network, such as the Internet interacting with other systems via signals).

[0088] First, a brief introduction to the relevant terms and related technical background in this application is given to facilitate understanding by those skilled in the art.

[0089] Object Configuration: Object Configuration;

[0090] Configuration ConstraintsRules

[0091] Managed Object Class (MOC): managed object type, such as wireless configuration management object type.

[0092] Managed Object Instance: Managed Object Instance, MOI; managed object instance, such as wireless configuration management object instance;

[0093] Intention: aim / goal; specifically refers to the goal to be achieved, and may not include the detailed steps required to achieve the goal;

[0094] Description: description; refers to a detailed description of a process, including the steps or operations in the process.

[0095] In the wireless network equipment configuration scenario, with the rapid development and application of the fifth generation mobile communication technology (5G), new wireless network equipment is constantly being launched. Combined with the existing wireless network equipment, the configuration and operation of wireless network equipment is complex, with multiple types, standards, and combinations of new and old hardware. This brings huge challenges to the formulation, verification, and distribution of configuration data, seriously affecting site operation and maintenance efficiency.

[0096] With the introduction of some large-scale language models, related research has proposed using these models to formulate configuration constraints and information for wireless network devices. While large language models possess strong language perception and logical reasoning capabilities, they are primarily trained on general-purpose corpora and lack extensive domain knowledge about wireless network device configuration, making them difficult to efficiently formulate and verify configuration constraints and information. Furthermore, they require significant time and computing power, resulting in high costs. Existing large language model tools are mostly generative, severely limited in the number and speed of inferences they can perform, making them incapable of meeting the efficiency demands of businesses.

[0097] The development and verification of existing device configuration constraint rules is largely done manually. Because different device configurations involve different domain knowledge, and constraint rules may be described using different programming syntax in different scenarios, relevant personnel must possess a high level of domain knowledge and coding knowledge. As shown in Figure 1, the process of developing, verifying, and storing constraint rules can include the following steps:

[0098] (1) Designers first need to design rules based on experience and collect test case data for rule testing and verification;

[0099] (2) Developers write rule scripts based on rule syntax and test and verify the correctness of rule scripts based on instance data;

[0100] (3) After passing the test verification, the rule script needs to be verified using software parameters and hardware constraint use cases;

[0101] (4) After passing the instance verification, the rules need to be reviewed and summarized and reported. After passing the review, the generated rules will be stored in the database.

[0102] Constraint rules are usually stored in the form of compiled scripts. The description syntax of the scripts used to compile rules in different regions and systems is inconsistent. These include natural language, eXtensible Markup Language (XML) files, Lua scripts, Object Constraint Language (OCL), and other description syntaxes. Constraint rules do not form a unified rule syntax expression. Different regional network points use different syntaxes for rule formulation and need to adapt to different compilers. When calculating rules, there may be repeated compilation of rules in different languages, which reduces the calculation efficiency. A large number of constraint rules are manually reviewed during the formulation process, making it difficult to accurately assess the legality and effectiveness of the rules. Moreover, with a large number of existing rules, manual redundancy detection and conflict detection are very time-consuming, making it difficult to efficiently and accurately detect redundant or conflicting rules and clean up or modify them.

[0103] The development, verification, and distribution of existing device configuration files are mainly completed manually. As shown in Figure 2, the process of developing, verifying, and distributing device configuration files may include the following steps:

[0104] a. Relevant personnel write configuration scripts based on experience and device configuration syntax specifications;

[0105] b. Based on the multiple compilation languages ​​used by the constraint rules (for example: rule script compilation language A, rule script compilation language B... rule script compilation language N), the generated configuration information is compiled into multiple languages, and the compiled configuration information is compared with the constraint rules in the database.

[0106] Perform satisfiability checking;

[0107] c. After verification, the configuration design plan will be approved. After approval, the configuration will be sent to the device to take effect.

[0108] Because wireless network device configuration requires high-level domain expertise, developing configuration files requires on-site research and discussion, making them challenging. Furthermore, existing rules are compiled and stored in script files of varying specifications, each containing a different syntax. To verify the match between a configuration file and the associated constraint rules, the configuration file must be compiled and verified using different syntax rules, resulting in low verification efficiency. Even after multiple verifications, the configuration plan still requires manual review and final approval, making approval and release inefficient.

[0109] In order to overcome the shortcomings and defects of the existing technology, the present application proposes a product configuration management and generation method, which can be implemented based on the system architecture shown in Figure 3. As shown in Figure 3, the system architecture mainly includes a rule design module, an operation and maintenance module, and an operator network module. Among them, the rule design module provides a rule designer, and the rule designer includes a rule design description module, an intent recognition and extraction module, and a constraint rule generation module. The rule design description module is used for the rule design user to input the three contents of the management object description, object attribute description, and attribute constraint description. The intent recognition and extraction module is used to extract the key information of the rule management object, management object attribute, and attribute constraint description based on the input of the rule design user, and then verify the management object and object attribute through the model transfer engine. After the verification is successful, it is returned to the constraint rule generation module to generate constraint rules. The model transfer engine again performs conflict and redundancy detection and simulation testing on the constraint rules generated by the C module. Users can modify or redesign the rules according to the detection and test results through the rule design module, and the model transfer engine will publish the verified constraint rules into the database. The operation and maintenance party inputs the configuration change / configuration generation information into the operation and maintenance module. The configuration generation unit extracts the key information in the configuration change / configuration generation and generates the configuration information of the device based on this key information. The unified rule verification unit performs rule query from the database and performs satisfiability verification on the generated configuration information and the constraint rules returned by the query. The configuration management unit can modify the generated configuration information or configuration change / configuration generation information based on the results of the satisfiability verification. For example, the operation and maintenance module can run in the cloud or locally. The operator network module provides networking services, and the configuration distribution unit loads the verified configuration information onto the device to take effect.

[0110] The technical solution provided in this application is introduced in detail below in conjunction with specific implementation methods.

[0111] Please refer to Figure 4, which is a flowchart of a product configuration management and generation method provided by an embodiment of the present application. The method can be implemented based on the system architecture shown in Figure 3 and can be specifically executed by an electronic device. As shown in Figure 4, the method includes steps 401-403:

[0112] 401: Obtain first intent information; the first intent information is used to instruct configuration management of the product.

[0113] In an embodiment of the present application, the product can be a hardware product (such as a wireless network device) or a software product. The first intention information may include a first named entity of the first management object of the product, a second named entity of the attribute of the first management object, and the value of the attribute of the first management object. The first intention information may be a configuration change, configuration optimization, configuration generation, etc. of the first management object of the product. For example: the user inputs "Set the positioning function of module X to 1". The first management object refers to the management object that the user currently wants to configure. Exemplarily, the first intention information can be a natural language description input by the user, such as text or voice. Exemplarily, the user can input the first intention information in the operation and maintenance module of the unified verification technology system through an electronic device.

[0114] 402: Determine a first management object of the product, an attribute of the first management object, and a value of the attribute of the first management object based on the first intent information.

[0115] In an embodiment of the present application, the electronic device can perform semantic recognition on the first intent information through a language model and parse out the first management object, the attribute of the first management object, and the value of the attribute of the first management object included in the first intent information. For example, as shown in FIG5 , the configuration generation unit in the operation and maintenance module of the configuration unified verification technology system performs semantic recognition by calling the language model, and parses out the three parts of content: the first management object, the attribute of the first management object, and the value of the attribute of the first management object based on the semantic recognition result.

[0116] 403: Generate product configuration information based on the first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object.

[0117] In an embodiment of the present application, as shown in FIG5 , based on the parsed first management object, the attribute of the first management object, and the value of the attribute of the first management object, the electronic device can generate corresponding configuration information through a configuration generation unit. Exemplarily, the configuration information exists in the form of a configuration script or a configuration file. Exemplarily, the configuration information can be obtained through unified compilation, for example: compiled using a unified compilation language or a unified grammatical specification, and the compilation language or grammatical specification is the same as the compilation language or grammar of the constraint rules in the database, that is, the product configuration information and the existing rules in the database are both obtained through unified compilation.

[0118] Exemplarily, after parsing the first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object, the electronic device will also obtain the first canonical code of the first management object and the second canonical code of the attributes of the first management object. Specifically, based on the product knowledge, all associated management objects and the attributes of all associated management objects associated with the product are first queried from the database, and then it is checked whether the first management object exists in these associated management objects and whether the attributes of the first management object exist in the attributes of the associated management objects, and the verification results are returned. If the first management object and the attributes of the first management object exist, all associated first canonical codes of the first management object and all associated second canonical codes of the attributes of the first management object are returned. If the first management object does not exist, it is returned that the verification failed and the configuration information creation is invalid. When the first canonical code and the second canonical code are obtained, the electronic device uses the first canonical code to replace the first named entity in the first intent information, and uses the second canonical code to replace the second named entity in the first intent information to obtain the second intent information. The second intent information refers to the replaced intent information. For example, if the first canonical code of module X is "MOC1Cell" and the second canonical code of the positioning function is "location_func," the electronic device can use these canonical codes to replace the named entities in the first intent information and generate configuration information based on the first canonical code, the second canonical code, and the attribute values ​​in the second intent information.

[0119] In this implementation, the electronic device uses the first standard encoding of the first management object and the second standard encoding of the attribute of the first management object to replace the first named entity and the second named entity in the first intent information respectively, so as to obtain the second intent information that is easier for the machine to understand, thereby generating product configuration information based on the second intent information.

[0120] Exemplarily, after generating the configuration information of the product based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the method further includes:

[0121] Obtaining constraint rules associated with the first management object and attributes of the first management object;

[0122] detecting whether configuration information of the product satisfies constraint rules associated with the first management object and attributes of the first management object;

[0123] If the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

[0124] In an embodiment of the present application, as shown in FIG5 , the electronic device may use the parsed first management object and the attributes of the first management object to search in a database through a unified rule verification unit to obtain all constraint rules associated with the first management object and the attributes of the first management object, and then detect whether the generated configuration information satisfies these constraint rules, i.e., perform a satisfiability check. If the satisfiability check passes, i.e., the configuration information of the product satisfies all constraint rules associated with the first management object and the attributes of the first management object, the electronic device will perform configuration delivery through the configuration delivery unit, i.e., load the product configuration information onto the product.

[0125] In this implementation, since the product configuration information and all constraint rules associated with the first management object and the attributes of the first management object are obtained by unified compilation, there is no need to repeatedly compile the configuration information according to the compilation syntax of each constraint rule during the satisfiability check, which is beneficial to improving the efficiency of the configuration information satisfiability check, and further beneficial to improving the efficiency of configuration distribution.

[0126] For example, if there are constraint rules associated with the first management object and the attributes of the first management object that cannot be satisfied by the product's configuration information, the return check fails, and the constraint rules that cannot be satisfied by the product's configuration information are output, so that the user can modify the first intent information based on the constraint rules and regenerate the product's configuration information based on the modified intent information, or directly modify the generated configuration information. Optionally, the script identifier corresponding to the constraint rule that cannot be satisfied by the product's configuration information can also be output, so that the user can quickly find the script corresponding to the constraint rule based on the script identifier.

[0127] In this implementation, if there are constraint rules in the database that cannot be satisfied by the generated configuration information, the electronic device can output the constraint rules to facilitate the user to modify the first intention information and generate configuration information that satisfies the constraint rules associated with the attributes of the first management object.

[0128] It can be seen that in the embodiment of the present application, when the user inputs the first intention information for configuring and managing the product, the electronic device can determine the first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object that the user needs to configure through semantic recognition, thereby being able to generate the configuration information of the product based on the parsed first management object, the attributes of the first management object, and the values ​​of the attributes of the first management object, without the need for manual mastery of highly difficult domain knowledge, and formulating the configuration information of the product through research, discussion, etc., which is conducive to improving the efficiency of generating configuration information.

[0129] To better understand this solution, the following briefly describes the overall process of generating, verifying, and issuing product configuration information, as shown in Figure 6. The process includes the following steps:

[0130] A0. The user enters the configuration design page;

[0131] A1. The user enters the intention to change or add a new device configuration using natural language input. The intention includes the device's management object, the attributes of the management object, and the attribute values.

[0132] A2. The configuration generation unit performs semantic perception based on the user's intent and parses the intent into three parts: the management object, the attributes of the management object, and the attribute values;

[0133] A3 configuration generation unit based on the above analysis results and device knowledge, obtain all associated objects and properties;

[0134] A4 configuration generation unit sends a request to the database engine based on the rule generation engine to manage the object, the management object's attributes are checked;

[0135] A5. The database engine returns the verification result. If the verification passes, the standard encoding of the management object and its attributes is returned; otherwise, the verification fails and the configuration information creation is invalid.

[0136] A6. The configuration generation unit, based on the verification results, replaces the management objects and attributes of the management objects in the natural language using standard coding, and generates a specific configuration of the device based on the description of the attribute values;

[0137] B1. After the user confirms the generated configuration, the unified rule verification unit sends a query request to the database engine based on the attributes of the management object for the relevant constraint rules involved, and performs satisfiability verification between the configuration and the constraint rules;

[0138] B2. The unified rule verification unit returns the verification results and the generated specific configuration. If the verification fails, the specific unsatisfied rules and the script identifier of the unsatisfied rules are returned. The user modifies the configuration based on the feedback and iterates steps A1-B1. If the verification passes, C1 is executed.

[0139] C1. After the user confirms the configuration generation result, the configuration is distributed through the configuration distribution unit, and the configuration takes effect on the device.

[0140] Please refer to Figure 7, which is a flowchart of a product configuration management and generation method provided by an embodiment of the present application. As shown in Figure 7, the method includes steps 701-709:

[0141] 701: Obtain third intent information; the third intent information is used to indicate constraint rules for generating products.

[0142] In an embodiment of the present application, the third intent information may include a third named entity of the second management object of the product, a fourth named entity of the attribute of the second management object, and an attribute constraint of the attribute of the second management object. For example: the rule designer inputs "the scheduling function must be turned off when the positioning function in the cell xx module starts". Among them, the second management object refers to the management object involved in the configuration information of the constraint for which the product needs to generate the constraint rule, for example: the second management object can be the first management object, or it can be a management object other than the first management object. Exemplarily, the third intent information can be a natural language description input by the designer, for example: it can be text or voice, etc. Exemplarily, the designer can input the third intent information in the rule design module of the unified verification technology system through an electronic device.

[0143] 702: Determine a second management object of the product, an attribute of the second management object, and an attribute constraint of the attribute of the second management object based on the third intent information.

[0144] In the embodiment of the present application, the electronic device can perform semantic recognition of the third intent information through a language model and parse the second management object, the attributes of the second management object, and the attribute constraints of the attributes of the second management object included in the third intent information. For example:

[0145] The second management object: xx module;

[0146] Attributes of the second management object: positioning function, scheduling function;

[0147] Property constraint: The scheduling function must be turned off when the positioning function starts.

[0148] Exemplarily, as shown in FIG8 , the rule designer in the rule design module of the unified verification technology system performs semantic recognition by calling a language model, and parses out three parts of the second management object, the attributes of the second management object, and the attribute constraints of the attributes of the second management object based on the semantic recognition results.

[0149] 703: Generate a constraint rule for the product based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object.

[0150] In an embodiment of the present application, as shown in FIG8 , based on the parsed second management object, the attributes of the second management object, and the attribute constraints of the attributes of the second management object, the electronic device can generate corresponding constraint rules through a rule designer. Exemplarily, the constraint rules exist in the form of a rule script. Based on a certain compilation syntax and using certain compilation rules, the product constraint rule script is compiled.

[0151] In this implementation, when the user inputs third intention information for generating rules for a product, the electronic device can determine the second management object, the attributes of the second management object, and the attribute constraints of the attributes of the second management object for which the user needs to generate constraint rules through semantic recognition. In this way, the constraint rules for the product can be generated based on the parsed second management object, the attributes of the second management object, and the attribute constraints, without the need for manual mastery of highly difficult domain knowledge and a large amount of coding knowledge to design the constraint rules for the product, which is conducive to improving the efficiency of generating constraint rules.

[0152] Exemplarily, after parsing the second management object, the attributes of the second management object, and the attribute constraints of the attributes of the second management object, the electronic device also obtains the third canonical code of the second management object and the fourth canonical code of the attributes of the second management object through the rule designer. Specifically, based on the second management object and the attributes of the second management object, fuzzy matching is performed in the database to determine whether the second management object and the attributes of the second management object exist in the database, and the verification result is returned. If the second management object and the attributes of the second management object exist, the third canonical code of the second management object and the fourth canonical code of the attributes of the second management object are returned. For example:

[0153] Standard encoding of xx module: MOC2Cell;

[0154] Standard encoding of the positioning function of the xx module: location_func;

[0155] The standard encoding of the scheduling function of the xx module: schedule_func.

[0156] Upon obtaining the third canonical code and the fourth canonical code, the electronic device replaces the third named entity in the third intent information with the third canonical code, and replaces the fourth named entity in the third intent information with the fourth canonical code, thereby obtaining fourth intent information. The fourth intent information refers to the replaced intent information. The electronic device generates a constraint rule for the product based on the third canonical code, the fourth canonical code, and the attribute constraint of the attribute in the fourth intent information.

[0157] In this implementation, the electronic device uses the third canonical encoding of the second management object and the fourth canonical encoding of the attribute of the second management object to replace the third named entity and the fourth named entity in the third intent information respectively, so as to obtain the fourth intent information that is easier for the machine to understand, thereby generating product constraint rules based on the fourth intent information.

[0158] Exemplarily, the method further includes:

[0159] Perform conflict and redundancy checks on the generated constraint rules and the existing rules of the product;

[0160] Output the detection results.

[0161] Exemplarily, as shown in FIG8 , the electronic device may perform conflict detection and redundancy detection on the generated constraint rules and the existing rules of the product through the rule verification unit, and output the detection result through the rule verification unit.

[0162] In this implementation, the electronic device can use formal technology to perform conflict detection and redundancy detection on the generated constraint rules and the existing rules of the product to ensure the accuracy of the constraint rules, which is conducive to improving the efficiency of the constraint rule formulation process.

[0163] Exemplarily, if the generated constraint rule has a conflict relationship with one or more first existing rules, the detection result includes one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes one or more second existing rules.

[0164] In an embodiment of the present application, the electronic device outputs one or more first existing rules that conflict with the generated constraint rules and one or more second existing rules that have a redundant relationship with the generated constraint rules through a rule verification unit. For one or more first existing rules, the rule designer can modify them, or based on the one or more first existing rules and the corresponding redundant or conflicting relationships, the rule designer can modify the third intention information or directly modify the generated constraint rules. As shown in Figure 8, for one or more second existing rules, the rule verification unit provides a one-click cleanup and selective deletion function to organize and summarize the constraint rules of the product. Based on the triggering of the one-click cleanup function by the rule designer, the electronic device can delete one or more second existing rules; based on the rule designer's selection of part or all of one or more second existing rules, the electronic device can delete the part or all of the second existing rules.

[0165] In this implementation, the electronic device can output existing rules that conflict with or are redundant with the generated constraint rules, so that designers can modify or delete these rules, or modify the constraint rules based on these rules to optimize the constraint rules of the product.

[0166] Exemplarily, as shown in FIG8 , the electronic device may further perform simulation detection on the generated constraint rules through the rule verification unit, that is, detect whether the generated constraint rules have an impact on the existing rules of the product through simulation technology.

[0167] For example, as shown in Figure 8, based on the results of conflict detection, redundancy detection, and simulation detection, the electronic device can display all product constraints and the relationships between them in the form of a topology graph, thereby visualizing all constraints and the relationships between them. Nodes in the topology graph represent corresponding constraints, and edges between nodes represent relationships between the corresponding constraints.

[0168] Exemplarily, as shown in FIG8 , after the rule designer has modified the conflicting rules and cleared the redundant rules, the electronic device will use unified compilation to compile the generated constraint rules, obtain the rules to be stored in a unified grammatical expression, and store the rules to be stored. Unified compilation refers to expressing the generated constraint rules using a unified rule grammar. Exemplarily, if the generated constraint rules do not have one or more conflicting first existing rules and do not have one or more second existing rules with a redundant relationship, the electronic device directly uses unified compilation to compile the generated constraint rules, obtain the rules to be stored in a unified programming language expression, and store the rules to be stored.

[0169] In this implementation, the generated constraint rules are compiled uniformly before being stored in the database. When the configuration information is subsequently generated, it only needs to be compiled uniformly once to perform satisfiability verification with the existing rules in the database. When the rules and configurations are compiled uniformly, it is beneficial to improve the efficiency and accuracy of subsequent satisfiability verification.

[0170] To better understand this solution, the following briefly describes the overall process of generating, verifying, and storing product constraint rules. As shown in Figure 9, it includes the following steps:

[0171] 0. The designer enters the rule-making page;

[0172] 1. The rule designer prompts you to enter the intended information for the constraint rules that will be used to generate the product.

[0173] 2. The designer inputs the intent of constraint rule formulation based on natural language. This intent includes a language description of the device's management objects, attributes of the management objects, and attribute constraints.

[0174] 3. The rule designer uses the user's natural language rule description and a large language model to parse the rule description into three parts: the management object, the management object's attributes, and the attribute constraints.

[0175] 4. The rule designer sends a request to the database engine to check the management object and the attributes of the management object of the device to check whether there is a standard management object and attribute matching the attribute in the database;

[0176] 5. The database engine returns the verification result. If the verification passes, the standard encoding of the management object and its attributes is returned; otherwise, the verification fails and the constraint rule creation is invalid.

[0177] 6. Based on the verification results, the rule designer replaces the management objects and their attributes in the natural language with standard codes, and generates device constraint rules based on the attribute constraints of the attributes;

[0178] 7. The rule verification unit detects conflicts and redundancies between the new rules and the existing rules, performs simulation tests, and outputs the test results in the form of a topology map;

[0179] 8. The rule verification unit returns the test results and the generated constraint rules. If there are any existing rules that conflict with the generated constraint rules or are redundant with the generated constraint rules, the test results will include the conflicting rules or redundant rules.

[0180] 9. Based on the test results, designers can selectively delete redundant rules or modify conflicting rules. Designers can also select the one-click clear function, and the rule verification unit will automatically delete all redundant rules based on the redundancy results.

[0181] 10. The designer confirms the addition of the rule;

[0182] 11. The rule designer compiles the rules uniformly through the storage function and stores them in the rule database.

[0183] 704: Obtain first intent information; the first intent information is used to instruct configuration management of the product;

[0184] 705: Determine a first management object of the product, an attribute of the first management object, and a value of the attribute of the first management object based on the first intent information;

[0185] 706: Generate product configuration information based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object;

[0186] 707: Obtain constraint rules associated with the first management object and the attributes of the first management object;

[0187] 708: Detect whether the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object;

[0188] 709: If the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

[0189] The specific implementation of steps 704-709 has been described in the embodiment shown in FIG4 and can achieve the same or similar beneficial effects, so they will not be repeated here. It should be noted that the generation and management of constraint rules and the generation and management of configuration information can be performed by the same electronic device or by different electronic devices.

[0190] Please refer to Figure 10, which is a schematic diagram of the structure of a product configuration management and generation device provided in an embodiment of the present application. As shown in Figure 10, the device may include an acquisition unit 1001 and a processing unit 1002; wherein:

[0191] The acquisition unit 1001 is configured to acquire first intention information; the first intention information is used to instruct configuration management of the product;

[0192] Processing unit 1002 is used to determine the first management object of the product, the attributes of the first management object and the values ​​of the attributes of the first management object based on the first intention information; and generate product configuration information based on the first management object, the attributes of the first management object and the values ​​of the attributes of the first management object.

[0193] It can be seen that in the device shown in Figure 10, when the user inputs the first intention information for configuration management of the product, the first management object, the attributes of the first management object and the values ​​of the attributes of the first management object that the user needs to configure can be determined through semantic recognition, so that the configuration information of the product can be generated based on the parsed first management object, the attributes of the first management object and the values ​​of the attributes of the first management object, without the need for manual mastery of highly difficult domain knowledge and the formulation of the product configuration information through research, discussion, etc., which is conducive to improving the efficiency of generating configuration information.

[0194] In a possible implementation, the acquiring unit 1001 is further configured to acquire constraint rules associated with the first management object and the attributes of the first management object;

[0195] Processing unit 1002 is also used to detect whether the configuration information of the product meets the constraint rules associated with the first management object and the attributes of the first management object; if the configuration information of the product meets the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

[0196] In one possible implementation, the first intent information includes a first named entity of a first management object and a second named entity of an attribute of the first management object. In terms of generating product configuration information based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the processing unit 1002 is specifically configured to:

[0197] Obtain a first canonical code of a first management object and a second canonical code of an attribute of the first management object;

[0198] Replacing the first named entity in the first intent information with the first canonical encoding, and replacing the second named entity in the first intent information with the second canonical encoding, to obtain second intent information;

[0199] Configuration information of the product is generated based on the second intent information.

[0200] In a possible implementation, the processing unit 1002 is further configured to:

[0201] If there is a constraint rule that cannot be satisfied by the configuration information of the product among the constraint rules associated with the first management object and the attribute of the first management object, the constraint rule that cannot be satisfied by the configuration information of the product is output.

[0202] In a possible implementation, the acquiring unit 1001 is further configured to acquire third intent information; the third intent information is used to indicate constraint rules for generating a product;

[0203] Processing unit 1002 is also used to determine the second management object of the product, the attributes of the second management object, and the attribute constraints of the attributes of the second management object based on the third intention information; and generate constraint rules for the product based on the second management object of the product, the attributes of the second management object, and the attribute constraints of the attributes of the second management object.

[0204] In a possible implementation, the processing unit 1002 is further configured to:

[0205] Perform conflict and redundancy checks on the generated constraint rules and the existing rules of the product;

[0206] Output the detection results.

[0207] In one possible implementation, if the generated constraint rule has a conflicting relationship with one or more first existing rules, the detection result includes one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes one or more second existing rules.

[0208] In a possible implementation, the processing unit 1002 is further configured to:

[0209] Use unified compilation to compile the generated constraint rules to obtain the rules to be stored in the unified programming language;

[0210] Store the rules to be stored.

[0211] In one possible implementation, the third intent information includes a third named entity of the second management object and a fourth named entity of an attribute of the second management object; in terms of generating a constraint rule for the product based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object, the processing unit 1002 is specifically configured to:

[0212] Obtain a third canonical code of the second management object and a fourth canonical code of the attribute of the second management object;

[0213] Replacing the third named entity in the third intent information with a third canonical encoding, and replacing the fourth named entity in the third intent information with a fourth canonical encoding, to obtain fourth intent information;

[0214] Generate product constraint rules based on the fourth intent information.

[0215] It should be noted that the implementation of each unit described in FIG10 can also correspond to the corresponding description of the embodiments shown in FIG4 to FIG9. In addition, the beneficial effects brought about by the communication device described in FIG10 can be referred to the corresponding description of the embodiments shown in FIG4 to FIG9, and will not be repeated here.

[0216] Based on the description of the above method embodiments and device embodiments, an embodiment of the present application also provides an electronic device. Please refer to Figure 11, which is a structural diagram of an electronic device provided in an embodiment of the present application. The electronic device includes at least a processor 1101, a memory 1102 and a communication interface 1103, and the processor 1101, the memory 1102 and the communication interface 1103 are interconnected via a bus 1104. The electronic device can be used to perform relevant steps of the product configuration management and generation method. The electronic device can be a device running a configuration unified verification technology system or a chip in the device. The processor 1101 in the electronic device is used to read the computer program code stored in the above-mentioned memory 1102 and execute the method of any one of the embodiments shown in Figures 4 to 9.

[0217] The memory 1102 includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), and is used to store relevant computer programs and data.

[0218] The processor 1101 may be one or more central processing units (CPUs). When the processor 1101 is a CPU, the CPU may be a single-core CPU or a multi-core CPU.

[0219] Exemplarily, the processor 1101 in the electronic device may be configured to read one or more programs stored in the memory 1102 and perform the following operations:

[0220] Obtaining first intent information; the first intent information is used to instruct configuration management of the product;

[0221] Determining a first management object of the product, an attribute of the first management object, and a value of the attribute of the first management object based on the first intent information;

[0222] Configuration information of the product is generated based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object.

[0223] In one possible implementation, after generating the configuration information of the product based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the processor 1101 is further configured to:

[0224] Obtaining constraint rules associated with the first management object and attributes of the first management object;

[0225] detecting whether configuration information of the product satisfies constraint rules associated with the first management object and attributes of the first management object;

[0226] If the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

[0227] In one possible implementation, the first intent information includes a first named entity of a first management object and a second named entity of an attribute of the first management object; the processor 1101 generates product configuration information based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, including:

[0228] Obtain a first canonical code of a first management object and a second canonical code of an attribute of the first management object;

[0229] Replacing the first named entity in the first intent information with the first canonical encoding, and replacing the second named entity in the first intent information with the second canonical encoding, to obtain second intent information;

[0230] Configuration information of the product is generated based on the second intent information.

[0231] In a possible implementation, the processor 1101 is further configured to:

[0232] If there is a constraint rule that cannot be satisfied by the configuration information of the product among the constraint rules associated with the first management object and the attribute of the first management object, the constraint rule that cannot be satisfied by the configuration information of the product is output.

[0233] In one possible implementation, before obtaining the first intention information, the processor 1101 is further configured to:

[0234] Obtaining third intent information; the third intent information is used to indicate constraint rules for generating products;

[0235] determining a second management object of the product, an attribute of the second management object, and an attribute constraint of the attribute of the second management object based on the third intent information;

[0236] A constraint rule for the product is generated based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object.

[0237] In a possible implementation, the processor 1101 is further configured to:

[0238] Perform conflict and redundancy checks on the generated constraint rules and the existing rules of the product;

[0239] Output the detection results.

[0240] In one possible implementation, if the generated constraint rule has a conflicting relationship with one or more first existing rules, the detection result includes one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes one or more second existing rules.

[0241] In a possible implementation, the processor 1101 is further configured to:

[0242] Use unified compilation to compile the generated constraint rules to obtain the rules to be stored in the unified programming language;

[0243] Store the rules to be stored.

[0244] In one possible implementation, the third intent information includes a third named entity of the second management object and a fourth named entity of an attribute of the second management object; the processor 1101 generates a constraint rule for the product based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object, including:

[0245] Obtain a third canonical code of the second management object and a fourth canonical code of the attribute of the second management object;

[0246] Replacing the third named entity in the third intent information with a third canonical encoding, and replacing the fourth named entity in the third intent information with a fourth canonical encoding, to obtain fourth intent information;

[0247] Generate product constraint rules based on the fourth intent information.

[0248] It should be noted that the implementation of each operation may also correspond to the corresponding description of the method in any one of the embodiments shown in FIG. 4 to FIG. 9 .

[0249] It should be noted that although the electronic device shown in FIG11 only shows the processor 1101, the memory 1102, the communication interface 1103, and the bus 1104, in the specific implementation process, those skilled in the art will understand that the electronic device also includes other components necessary for normal operation. At the same time, according to specific needs, those skilled in the art will understand that the electronic device may also include hardware components that implement other additional functions. In addition, those skilled in the art will understand that the electronic device may also include only the components necessary to implement the embodiments of the present application, and does not necessarily include all the components shown in FIG11.

[0250] The present application also provides a chip, including a processor configured to call and execute a computer program from a memory, so that a device equipped with the chip executes the method described in any one of the embodiments shown in Figures 4 to 9. The chip may be a chip in an electronic device.

[0251] The embodiment of the present application also provides a computer-readable storage medium (Memory), which stores a computer program. When the computer program is run, the method described in any one of the embodiments in Figures 4 to 9 above is implemented. It can be understood that the computer-readable storage medium here can include both built-in storage media in the device and, of course, extended storage media supported by the device. The computer-readable storage medium provides a storage space that stores the operating system of the device. In addition, one or more computer programs suitable for being loaded and executed by the processor of the device are also stored in the storage space. It should be noted that the computer-readable storage medium here can be a high-speed RAM or a non-volatile memory, such as at least one disk storage; optionally, it can also be at least one computer-readable storage medium located away from the aforementioned processor.

[0252] An embodiment of the present application further provides a computer program product, which includes: computer program code. When the computer program code is executed by an electronic device, the method flow described in any one of the embodiments in Figures 4 to 9 is implemented.

[0253] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0254] It should be understood that the processor mentioned in the embodiments of the present application may be a CPU, or may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0255] It should also be understood that the memory mentioned in the embodiments of the present application can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a ROM, a programmable read-only memory (Programmable ROM, PROM), an EPROM, an electrically erasable programmable read-only memory (Electrically EPROM, EEPROM) or a flash memory. The volatile memory can be a RAM, which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM) and direct RAM bus random access memory (DR RAM).

[0256] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, the memory (storage module) is integrated into the processor.

[0257] It should be noted that the memory described herein is intended to include, but not be limited to, these and any other suitable types of memory.

[0258] It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0259] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely exemplary. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0260] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0261] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. If the aforementioned integrated units are implemented as software functional units and sold or used as independent products, they may be stored in a computer-readable storage medium.

[0262] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between associated objects, indicating that three possible relationships exist. For example, "A and / or B" can mean: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. In the text description of this application, the character " / " generally indicates that the associated objects are in an "or" relationship.

[0263] The steps in the method of the embodiment of the present application can be adjusted in order, combined and deleted according to actual needs.

[0264] The modules in the device of the embodiment of the present application can be merged, divided and deleted according to actual needs.

[0265] As described above, the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the above embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the above embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A product configuration management and generation method, characterized in that: The method comprises: Acquire first intent information; the first intent information is used to instruct configuration management of the product; Determine a first management object of the product, an attribute of the first management object, and a value of the attribute of the first management object based on the first intent information; Configuration information of the product is generated based on the first management object, an attribute of the first management object, and a value of the attribute of the first management object.

2. The method according to claim 1, characterized in that After generating the configuration information of the product based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the method further includes: Acquire constraint rules associated with the first management object and attributes of the first management object; Detecting whether the configuration information of the product satisfies a constraint rule associated with the first management object and an attribute of the first management object; If the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

3. The method according to claim 1 or 2, characterized in that: The first intent information includes a first named entity of the first management object and a second named entity of an attribute of the first management object; and the generating of the configuration information of the product based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object includes: Obtain a first canonical code of the first management object and a second canonical code of an attribute of the first management object; Replacing the first named entity in the first intent information with the first canonical encoding, and replacing the second named entity in the first intent information with the second canonical encoding, to obtain second intent information; Configuration information of the product is generated based on the second intent information.

4. The method according to claim 2, characterized in that: The method further comprises: If there is a constraint rule that cannot be satisfied by the configuration information of the product among the constraint rules associated with the first management object and the attribute of the first management object, the constraint rule that cannot be satisfied by the configuration information of the product is output.

5. The method according to any one of claims 1 to 4, characterized in that Before acquiring the first intention information, the method further includes: Acquire third intent information; the third intent information is used to indicate a constraint rule for generating the product; Determine, based on the third intent information, a second management object of the product, an attribute of the second management object, and an attribute constraint of the attribute of the second management object; A constraint rule for the product is generated based on a second management object of the product, an attribute of the second management object, and an attribute constraint of the attribute of the second management object.

6. The method according to claim 5, characterized in that The method further comprises: Perform conflict detection and redundancy detection on the generated constraint rules and the existing rules of the product; Output the detection results.

7. The method according to claim 6, characterized in that If the generated constraint rule has a conflicting relationship with one or more first existing rules, the detection result includes the one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes the one or more second existing rules.

8. The method according to claim 6, characterized in that The method also comprises: The generated constraint rules are compiled using unified compilation to obtain the rules to be stored in the database expressed in a unified programming language; The rules to be stored are stored.

9. The method according to any one of claims 5 to 8, characterized in that: The third intent information includes a third named entity of the second management object and a fourth named entity of the attribute of the second management object; the constraint rule of the product is generated based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object, including: Obtain a third canonical code of the second management object and a fourth canonical code of an attribute of the second management object; Replacing the third named entity in the third intent information with the third canonical code, and replacing the fourth named entity in the third intent information with the fourth canonical code, to obtain fourth intent information; A constraint rule for the product is generated based on the fourth intent information.

10. A product configuration management and generation device, characterized in that: The device comprises an acquisition unit and a processing unit; The acquisition unit is used to acquire first intention information; the first intention information is used to instruct configuration management of the product; The processing unit is used to determine the first management object of the product and the attribute of the first management object based on the first intention information. and the value of the attribute of the first management object; generating configuration information of the product based on the first management object, the attribute of the first management object and the value of the attribute of the first management object.

11. The method according to claim 10, characterized in that The acquisition unit is further configured to acquire constraint rules associated with the first management object and the attributes of the first management object; The processing unit is also used to detect whether the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object; if the configuration information of the product satisfies the constraint rules associated with the first management object and the attributes of the first management object, the configuration information of the product is loaded onto the product.

12. The device according to claim 10 or 11, characterized in that The first intent information includes a first named entity of the first management object and a second named entity of an attribute of the first management object; in terms of generating the configuration information of the product based on the first management object, the attribute of the first management object, and the value of the attribute of the first management object, the processing unit is specifically used to: Obtain a first canonical code of the first management object and a second canonical code of an attribute of the first management object; Replacing the first named entity in the first intent information with the first canonical encoding, and replacing the second named entity in the first intent information with the second canonical encoding, to obtain second intent information; Configuration information of the product is generated based on the second intent information.

13. The device according to claim 11, characterized in that The processing unit is also used for: If there is a constraint rule that cannot be satisfied by the configuration information of the product among the constraint rules associated with the first management object and the attribute of the first management object, the constraint rule that cannot be satisfied by the configuration information of the product is output.

14. The device according to any one of claims 10 to 13, characterized in that The acquisition unit is further used to acquire third intention information; the third intention information is used to indicate a constraint rule for generating the product; The processing unit is also used to determine the second management object of the product, the attributes of the second management object, and the attribute constraints of the attributes of the second management object based on the third intention information; and generate constraint rules for the product based on the second management object of the product, the attributes of the second management object, and the attribute constraints of the attributes of the second management object.

15. The device according to claim 14, characterized in that The processing unit is also used for: Perform conflict detection and redundancy detection on the generated constraint rules and the existing rules of the product; Output the detection results.

16. The device according to claim 15, characterized in that If the generated constraint rule has a conflicting relationship with one or more first existing rules, the detection result includes the one or more first existing rules; or if the generated constraint rule has a redundant relationship with one or more second existing rules, the detection result includes the one or more second existing rules.

17. The device according to claim 15, characterized in that The processing unit is also used for: The generated constraint rules are compiled using unified compilation to obtain the rules to be stored in the database expressed in a unified programming language; The rules to be stored are stored.

18. The device according to any one of claims 14 to 17, characterized in that The third intent information includes a third named entity of the second management object and a fourth named entity of the attribute of the second management object; in terms of generating a constraint rule for the product based on the second management object of the product, the attribute of the second management object, and the attribute constraint of the attribute of the second management object, the processing unit is specifically used to: Obtain a third canonical code of the second management object and a fourth canonical code of an attribute of the second management object; Replacing the third named entity in the third intent information with the third canonical code, and replacing the fourth named entity in the third intent information with the fourth canonical code, to obtain fourth intent information; A constraint rule for the product is generated based on the fourth intent information.

19. An electronic device, characterized in that: The method comprises a processor, a memory, a communication interface, and one or more programs, wherein the one or more programs are stored in the memory and configured to cooperate with the communication interface to implement the method as described in any one of claims 1 to 9 when executed by the processor.

20. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program for execution by a device, and when the computer program is executed, the method according to any one of claims 1 to 9 is implemented.

21. A computer program product, characterized in that When the computer program product is executed by a device, the device executes the method according to any one of claims 1 to 9.

Images