Method and system for extracting compatibility rules from black box configuration software
By combining modular approaches and reinforcement learning with inductive logic programming, compatibility rules in black-box configuration software are extracted automatically, solving the problem that extracting implicit rules in existing technologies is expensive and infeasible, and achieving efficient rule extraction.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-25
- Publication Date
- 2026-03-24
AI Technical Summary
Existing technologies struggle to efficiently extract implicit rules from black-box configuration software, making interpretation or debugging expensive and impractical.
A modular approach is adopted, in which configuration candidates are generated through a candidate generator, the interface receives responses from the black-box configuration software, the configuration database is observed and stored, and the rule base is output by the inductive logic programming engine. Compatibility rules are generated by combining reinforcement learning and inductive logic programming.
It provides an efficient and automated way to extract compatibility rules from black-box configuration software, reducing reliance on expert users and manual exploration, and solving the problem of implicit rule recovery.
Smart Images
Figure CN121729671A_ABST
Abstract
Description
BACKGROUND
[0001] Obtaining a high-quality digital representation of a real-world system, i.e. a so-called “digital twin”, is an important challenge in industry. One of the main problems is the integration of information from legacy software that contains a large amount of implicit domain knowledge. For example, device configuration software often internally maintains a large rule base against which inputs are checked. In the case of configuration software used to form a factory automation solution, a simple example of such rules would include verifying that the maximum load of a controller is not exceeded, matching voltage requirements of interconnected components, and verifying that a controller has sufficient computing power to supply all connected digital outputs.
[0002] However, such software is often only available in compiled (binary) form, with no access to the actual source code or rule base. This leads to black-box configuration software, which is still used by domain experts, but is impossible or at least very expensive to interpret or debug. In the following, the term “black-box configuration software” is to be understood in this way. SUMMARY
[0003] It is an object of the present invention to identify the problems in the prior art and to find a technical solution to this.
[0004] The objects of the present invention are solved by the independent claims. Further advantageous arrangements and embodiments of the present invention are set out in the respective dependent claims.
[0005] According to the method for extracting compatibility rules from black-box configuration software, the following operations are performed by modules, wherein the modules are hardware modules and / or software modules executed by one or more processors: - generating configuration candidates by a candidate generator, wherein each configuration candidate identifies components of an industrial automation system and their connections; - for each configuration candidate, receiving a valid or invalid response from the black-box configuration software and creating a corresponding validity label; - storing each configuration candidate and its validity label by an observed configuration database; and - outputting a rule base storing compatibility rules by an inductive logic programming engine processing the content of the observed configuration database.
[0006] The system for extracting compatibility rules from black-box configuration software comprises the following modules, wherein the modules are hardware modules and / or software modules executed by one or more processors: - a candidate generator configured for generating configuration candidates, wherein each configuration candidate identifies components of an industrial automation system and their connections; - an interface configured for receiving, for each configuration candidate, a valid or invalid response from the black-box configuration software and creating a corresponding validity label; - an observation configuration database configured for storing each configuration candidate and its validity label; and - an inductive logic programming engine configured for processing the content of the observation configuration database and outputting a rule base storing compatibility rules.
[0007] The compatibility rules are interpretable logical rules defining what makes a configuration valid, for example by specifying the minimum computational power required by a controller to supply a connection.
[0008] The interface is for example a web interface and / or an application programming interface adapted to query the black-box configuration software.
[0009] The following advantages and explanations are not necessarily the result of the subject matter of the independent claims. Rather, they can be advantages and explanations that apply only to certain embodiments or variants.
[0010] In connection with the present invention, the terms "training", "generating", "computer-aided", "computing", "determining", "reasoning", "re-training" and the like preferably relate to actions and / or processes and / or processing steps that change and / or generate data and / or transform data into other data, in particular represented as or capable of being represented as physical quantities, for example electrical impulses.
[0011] The term "computer" should be interpreted as broadly as possible, in particular covering all electronic devices with data processing properties. Thus, a computer can for example be a personal computer, a server, a client, a programmable logic controller (PLC), a handheld computer system, a palm computer device, a mobile radio device, a smartphone, a device or any other communication device capable of processing data with the aid of a computer support, a processor and other electronic devices. A computer can in particular comprise one or more processors and memory units.
[0012] In connection with the present invention, "memory", "memory unit" or "memory module" and the like can mean volatile memory, for example in the form of a random access memory (RAM), or a permanent memory such as a hard disk or a disk.
[0013] The method and system or at least some of their embodiments provide an alternative to the manual exploration of the search space - which would be infeasible due to the infinite number of possible configurations.
[0014] The method and system or at least some of their embodiments provide an alternative to performing a random exhaustive search - which would be inefficient.
[0015] The method and system or at least some of their embodiments provide an alternative to expert users interviewing the black-box configuration software - which would be expensive and time consuming.
[0016] The method and system or at least some of their embodiments provide a novel neural rule extraction system that allows for more efficient retrieval of rules from black-box configuration software than exhaustive search.
[0017] The method and system or at least some of their embodiments include a candidate discriminator that can be seen as a soft verifier that computes how likely a configuration is to be valid.
[0018] The method and system or at least some of their embodiments provide a solution for recovering a large number of implicit rules from legacy software, which is crucial for maintaining knowledge as the retiring workforce. Black-box software is an important pain point for asset digitalization.
[0019] The method and system or at least some of their embodiments free the user from having to manually create configurations or exhaustively search the space to extract knowledge from black-box configuration software.
[0020] In an embodiment of the method, the candidate generator receives as one of its inputs a domain vocabulary.
[0021] In another embodiment of the method, the candidate generator receives as one of its inputs a reward computed by the candidate discriminator. This reward in particular encourages that the configuration candidates generated by the candidate generator are diverse and substantially different from the configuration candidates already stored in the observed configuration database.
[0022] In an embodiment of the method, the reward is high if the configuration candidate currently generated by the candidate generator leads to high uncertainty in the candidate discriminator. In particular, the reward is computed as the entropy of the predictive probability distribution of the candidate discriminator.
[0023] In another embodiment of the method, the candidate discriminator has been trained using binary cross-entropy to act as a differentiable approximation of the rule base.
[0024] In an embodiment of the method, the candidate discriminator has been trained to learn which configurations in the latent constraint space are similar.
[0025] In another embodiment of the method, the candidate generator is a policy-based reinforcement learning agent that forms each configuration candidate starting from an empty configuration and adding components and connections in an iterative fashion that is in particular formulated as a Markov decision process until a terminal state is reached.
[0026] In an embodiment of the method, the candidate generator is implemented as a graph convolutional policy network.
[0027] The computer program product comprises instructions which, when the program is executed by a computer, cause the computer to carry out the method.
[0028] The supply device stores and / or provides the computer program product. BRIEF DESCRIPTION OF DRAWINGS
[0029] The foregoing and other aspects of the present application are best understood from the following detailed description when read in connection with the accompanying drawings. For the purpose of illustrating the application, there is shown in the drawings embodiments which are presently preferred. It should be understood, however, that the application is not limited to the specific arrangements and instrumentalities shown. The embodiments can be combined with each other. Furthermore, the embodiments can be combined with any of the features described above. Identical reference numerals in the figures indicate the same feature or element in the figures or elements with the same functionality. Included in the drawings are the following figures: Figure 1 shows a first embodiment, Figure 2 shows another embodiment, Figure 3 shows an example of a manual configuration workflow, Figure 4 shows an overall system architecture, Figure 5 shows an example of a potential constraint space, and Figure 6 shows a flowchart of a possible exemplary embodiment of a method for extracting compatibility rules from black-box configuration software. DETAILED DESCRIPTION
[0030] In the following description, various aspects of the application and embodiments thereof will be described. However, the skilled person will understand that embodiments can be practiced with only some or all of the aspects. For the purpose of illustration, specific numbers and configurations are set out in order to provide a thorough understanding. However, it will be apparent to the skilled person that embodiments can be practiced without these specific details.
[0031] The described modules can each be hardware modules or software modules. For example, a software module can be a software library; an individual process, subroutine, or function; or, depending on the programming paradigm, any other software code portion implementing the functionality of the software module. In particular, a combination of hardware modules and software modules can occur if some of the effects according to the application are preferably exclusively implemented by special hardware (e.g., a processor in the form of an ASIC or FPGA), while other parts are implemented by software.
[0032] Figure 1A sample structure for a computer implementation of the present invention is shown, comprising: (101) Computer system (102) Processor (103) Memory (104) Computer programs (products) (105) User Interface In this embodiment of the invention, computer program 104 includes program instructions for implementing the invention. Computer program 104 is stored in memory 103, which, among other things, makes memory 103 and / or its associated computer system 101 a supply device for computer program 104. Computer system 101 can implement the invention by executing the program instructions of computer program 104 by processor 102. The results of the invention can be presented on user interface 105. Alternatively, they can be stored in memory 103 or on another suitable means for storing data.
[0033] Figure 2 Another sample structure illustrating a computer implementation of the present invention includes: (201) Supply equipment (202) Computer program (product) (203) Computer Networks / Internet (204) Computer system (205) Mobile devices / smartphones In this embodiment, the supply device 201 stores a computer program 202, which includes program instructions for implementing the present invention. The supply device 201 provides the computer program 202 via a computer network / Internet 203. For example, a computer system 204 or a mobile device / smartphone 205 may load the computer program 202 and implement the present invention by executing the program instructions of the computer program 202.
[0034] In a variation of this embodiment, the supply device 201 is a computer-readable storage medium, such as an SD card, storing the computer program 202, and is directly connected to the computer system 204 or the mobile device / smartphone 205 so that it loads the computer program 202 and implements the invention by executing the program instructions of the computer program 202.
[0035] Preferably, Figures 3 to 6 The illustrated embodiments can be used as follows Figure 1 or Figure 2 The structure shown is used to achieve this.
[0036] The embodiments described below provide a solution for extracting information in the form of interpretable logical rules from black-box configuration software. The basic idea is to employ a reinforcement learning agent to generate inputs (configuration candidates) to the black-box configuration software, use "valid" / "invalid" responses from the black-box configuration software to obtain a set of positive and negative examples, and employ an inductive logic programming (ILP) engine to transform said set into rules (which may exist in the implicit rule base of the black-box configuration software).
[0037] The embodiments described below employ reinforcement learning to efficiently generate configuration candidates because the configuration search space grows exponentially, making manual exploration infeasible. This problem is similar to that of active learning, where the query strategy samples candidates from a pool of unlabeled data, maximizing the informativeness of these samples. The embodiments described below deal with a potentially infinite pool of unlabeled data, i.e., every possible configuration.
[0038] Figure 3 An example of a manual configuration workflow is shown. A human expert (HE) interacts with black-box configuration software (BBS) to create two device configurations: a valid configuration (VC) and an invalid configuration (IC). The black-box configuration software (BBS) then responds with a valid response (VR) or an invalid response (IR), which is collected as observation facts (OF).
[0039] Each configuration can be represented by a logical predicate involving the configuration components, such as "connected (a, b)", or a type such as "s7(a)". After obtaining the combination of valid configurations (VC) and invalid configurations (IC) as observed facts (OF), the rule learning system (here, the inductive logic programming engine ILPE) can extract (inductively summarize) rules (R) from the observations.
[0040] Some of the technical features of the embodiments described below are: a) Rule extraction system, and b) End-to-end training process.
[0041] Each of these features will be described in more detail below.
[0042] Rule extraction system Component architecture Figure 4 The overall architecture of the compatibility rule extraction system CRES according to the current embodiment is shown, which receives the domain vocabulary DV and the output of the black box configuration software BBS as input. The compatibility rule extraction system CRES outputs a rule base RB.
[0043] The compatibility rule extraction system CRES stores the inputs received from the black-box configuration software BBS (which are validity labels of configuration candidate CCs) along with the corresponding configuration candidate CCs in the observation configuration database OC.
[0044] Candidate Discriminator Within the compatibility rule extraction system CRES, the candidate discriminator CD encourages that the configuration candidates CC generated by the candidate generator CG are diverse (and substantially different from the observed configuration candidates) because classifying the observed configuration candidates is simple, and therefore the reward for the candidate generator CG will be small. Given observed configuration candidates... and its effectiveness tuple Combinations using binary cross-entropy To train the candidate discriminator CD function Therefore, the candidate discriminator (CD) acts as a differentiable approximation of the rule base (RB). The underlying idea here is that the candidate discriminator (CD) learns which configurations are similar in the latent constraint space, thus generating a hypothetical low-dimensional manifold for the original data, without needing to try every possible combination of components.
[0045] Figure 5 An example of the potential constraint space mentioned above is shown. Figure 5 In this model, the classifier is given by a hyperplane, which is the decision boundary DB that distinguishes between effective and ineffective configurations. Configurations closer to the decision boundary DB (i.e., the hyperplane) are more difficult to predict in terms of effectiveness and result in greater entropy.
[0046] Candidate Generator In the current embodiment, the candidate generator CG is a policy-based reinforcement learning agent that iteratively forms configuration candidates CC in a manner described as a Markov decision process. From the initial state space... Initially, the initial state space is an empty configuration, and actions are applied, i.e., the addition of components and connections, until the final action or final state is reached. Until then. Based on the final state. The agent receives the following: The reward given is the entropy of the predicted probability distribution of the candidate discriminator CD. In other words, the reward for the candidate generator CG is high if the generated final state candidate leads to high uncertainty in the candidate discriminator CD. Therefore, novel configuration candidate CC, associated with high uncertainty, is encouraged. Figure 5 The heuristic method described in the text, where the candidate generator CG attempts to generate candidates located in... Figure 5The configuration near the decision boundary DB is shown.
[0047] You, Jiaxuan et al., Advances in Neural Information Processing Systems, 31, 2018, disclose a Graph Convolutional Policy Network (GCPN), which is a neural architecture that can be used to implement candidate generator CG. The entire contents of this paper are incorporated herein by reference.
[0048] End-to-end training process According to this embodiment of the training process for the compatibility rule extraction system CRES, the observation configuration database OC is initially empty, and the candidate generator CG and candidate discriminator CD are randomly initialized neural networks.
[0049] Then, the training iteratively goes through the following: 1. The candidate generator (CG) samples new configuration candidate (CC) from its strategy. 2. The candidate discriminator CD rewards the candidate generator CG based on the configured candidate CC. 3. The candidate generator CG updates its strategy. 4. The black box configuration software BBS generates validity labels for configuration candidate CCs. 5. The candidate CCs and their validity labels are stored in the observation configuration database OC. 6. Every n iterations, train the candidate discriminator CD based on examples in the observation configuration database OC.
[0050] The training process ends when the weight updates of the candidate generator (CG) and the candidate discriminator (CD) disappear, based on a certain convergence criterion.
[0051] After training, the candidate generator CG can still be used to sample more candidates.
[0052] Once sufficient observation configurations are obtained, the inductive logic programming engine ILPE generates a rule base.
[0053] Quinlan, J. Ross, in his definition of learning logic from relations, Machine learning 5, 1990, 239-266, discloses an algorithm suitable for implementing the inductive logic programming engine ILPE. The entire contents of this paper are incorporated herein by reference.
[0054] Figure 6 A flowchart illustrating a possible exemplary embodiment of a method for extracting compatibility rules from black-box configuration software.
[0055] In the first operation 1, the candidate generator generates candidate configurations, where each candidate configuration identifies a component of the industrial automation system and its connections.
[0056] In the second operation 2, for each candidate configuration, a valid or invalid response is received from the black box configuration software, and a corresponding valid tag is created.
[0057] In the third operation, the observation configuration database stores each configuration candidate and its validity label.
[0058] In the fourth operation, the inductive logic programming engine processes the contents of the observation configuration database and outputs a rule base of storage compatibility rules.
[0059] Of course, at least some of these operations can be performed in parallel and / or cyclically. For example, the third operation of storing can be performed after each configuration candidate has been generated and tagged. In other words, the first three operations can be performed iteratively in a loop, where in each iteration, a new configuration candidate is generated, tagged, and stored. Preferably, the fourth operation is performed only after sufficient information has been gathered in the observation configuration database.
[0060] For example, the method can be executed by one or more processors. Examples of processors include microcontrollers or microprocessors, application-specific integrated circuits (ASICs), or neuromorphic microchips, particularly neuromorphic processor units. The processor can be part of any kind of computer, including mobile computing devices such as tablets, smartphones, or laptops, or it can be part of a server in a control room or in the cloud.
[0061] The above method can be implemented via a computer program product comprising one or more computer-readable storage media storing instructions executable by one or more processors of a computing system. Execution of the instructions causes the computing system to perform operations corresponding to the actions of the above method.
[0062] Instructions for implementing the processes or methods described herein may be provided on a non-transitory computer-readable storage medium or memory, such as cache, buffer, RAM, flash memory, removable media, hard disk drive, or other computer-readable storage medium. Computer-readable storage media include various types of volatile and non-volatile storage media. The functions, actions, or tasks illustrated in the figures or described herein may be performed in response to one or more sets of instructions stored in or on a computer-readable storage medium. Functions, actions, or tasks may be independent of a particular type of instruction set, storage medium, processor, or processing strategy, and may be executed individually or in combination by software, hardware, integrated circuits, firmware, microcode, etc. Similarly, processing strategies may include multiprocessing, multitasking, parallel processing, etc.
[0063] The invention has been described in detail with reference to embodiments and examples. However, variations and modifications can be made within the scope of the invention as covered by the claims. The alternative expression "at least one of A, B, and C" can be used to indicate that one or more of A, B, and C may be used.
Claims
1. A computer-implemented method for extracting compatibility rules from black-box configuration software, wherein, The following operations are performed by a module, wherein the module is a hardware module and / or software module executed by one or more processors: - A configuration candidate (CC) is generated by a candidate generator (CG), wherein each configuration candidate (CC) identifies a component of the industrial automation system and its connections; - For each configuration candidate (CC), receive (2) a valid response (VR) or an invalid response (IR) from the black box configuration software (BBS) and create a corresponding validity label; - The Observation Configuration Database (OC) stores (3) each configuration candidate (CC) and its validity label; and - The Inductive Logic Programming Engine (ILPE) that processes the contents of the observation configuration database (OC) outputs (4) a rule base (RB) for storing compatibility rules.
2. The method according to claim 1, -The candidate generator (CG) receives a domain vocabulary (DV) as one of its inputs.
3. The method according to any one of the preceding claims, - Wherein, the candidate generator (CG) receives the reward calculated by the candidate discriminator (CD) as one of its inputs, and -in, The reward specifically encourages configuration candidates (CCs) generated by the candidate generator (CG) to be diverse and substantially different from the configuration candidates (CCs) already stored in the observation configuration database (OC).
4. The method according to claim 3, -Wherein, if the configuration candidate (CC) currently generated by the candidate generator (CG) causes high uncertainty in the candidate discriminator (CD), then the reward is high, and -in, The reward is specifically calculated as the entropy of the predicted probability distribution of the candidate discriminator (CD).
5. The method according to any one of claims 3 and 4, -in, The candidate discriminator (CD) has been trained using binary cross-entropy to serve as a differentiable approximation of the rule base (RB).
6. The method according to any one of claims 3-5, -in, The candidate discriminator (CD) has been trained to learn which configurations are similar in the latent constraint space.
7. The method according to any one of the preceding claims, -in, The candidate generator (CG) is a policy-based reinforcement learning agent that forms each configuration candidate (CC) by starting with an empty configuration and adding components and connections in an iterative manner, particularly expressed as a Markov decision process, until a final state is reached.
8. The method according to any one of the preceding claims, -The candidate generator (CG) is implemented as a graph convolutional policy network.
9. A system (CRES) for extracting compatibility rules from black-box configuration software, comprising: - A candidate generator (CG) is configured to generate configuration candidates (CCs), where each configuration candidate (CC) identifies a component of the industrial automation system and its connections; - An interface configured to receive a valid response (VR) or invalid response (IR) from the black box configuration software (BBS) for each configuration candidate (CC) and create a corresponding validity label; - Observation Configuration Database (OC), which is configured to store each configuration candidate (CC) and its validity label; and - The Inductive Logic Programming Engine (ILPE) is configured to process the contents of the Observation Configuration Database (OC) and output a rule base (RB) for storing compatibility rules.
10. A computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method according to any one of the method claims.
11. The supply device for a computer program product according to the preceding claims, wherein, The supply equipment stores and / or provides the computer program product.