JP7694151B2 - System design learning device, system design learning method and program - Google Patents

Description

The present invention relates to a system design learning device, a system design learning method, and a program.

Patent Document 1 discloses a system design technique that derives a concrete system configuration that does not include uncertain parts by applying concretization rules to the uncertain parts of an abstract system configuration and concretizing them.
Furthermore, Non-Patent Document 1 discloses a technique in which a process of selecting one of the applicable rules in the technique disclosed in Patent Document 1 is learned by reinforcement learning.

International Publication No. 2019/216082

Takashi Maruyama and 4 others, "Improving the efficiency of search by reinforcement learning for search-based network design derivation method," IEICE Technical Report, vol. 118, no. 483, ICM2018-71, pp. 123-128, March 2019.

When applying conversion rules to parts of a system configuration, such as the system design technology exemplified in Patent Document 1, it is conceivable that the results obtained will differ depending on which conversion rules are applied and in what order they are applied. In particular, in the system design technology exemplified in Patent Document 1, it is conceivable that the system design will fail depending on which conversion rules are applied and in what order they are applied. In other words, such system design technology is not necessarily successful in deriving a specific system configuration, and it is conceivable that, for example, there will be no applicable conversion rules even if the system configuration includes undetermined parts.

In response to this, from the viewpoint of increasing the possibility of successful system design, it is conceivable to carry out learning (machine learning) such as reinforcement learning exemplified in Non-Patent Document 1 for conversion according to the system configuration.
However, when learning about system configurations, since there are many different system configurations, it is conceivable that the system configuration targeted at the time of system design may differ from the system configuration targeted at the time of learning. Even if the system configuration targeted at the time of system design differs from the system configuration targeted at the time of learning, it is preferable to be able to carry out effective learning.

The present invention aims to provide a system design learning device, a system design learning method, and a program that can solve the above-mentioned problems.

According to a first aspect of the present invention, a system design learning device includes a conversion rule application means for performing system design by repeatedly applying conversion rules to components of a system to be designed, the components being designated as system requirements, until a design result of the system design is obtained, a design evaluation means for determining an evaluation value for the system design based on the design result, a rule application evaluation means for determining an evaluation value for the conversion of each component in the system design based on the evaluation value for the system design, and a learning means for learning about the selection of components to which the conversion rules are applied, based on learning data including the evaluation values for the conversion of the components.

According to a second aspect of the present invention, a system design learning method by a computer includes: performing system design by repeatedly applying conversion rules to components of a system to be designed, for a system to be designed, whose system requirements are given, until a design result of the system design is obtained; determining an evaluation value for the system design based on the design result; determining an evaluation value for the conversion of each component in the system design based on the evaluation value for the system design; and learning about selection of components to which the conversion rules are to be applied based on learning data including the evaluation values for the conversion of the components.

According to a third aspect of the present invention, the program causes a computer to perform the following steps: design a system by repeatedly applying conversion rules to components of a system to be designed, for which system requirements are given, until a design result of the system design is obtained; determine an evaluation value for the system design based on the design result; determine an evaluation value for the conversion of each component in the system design based on the evaluation value for the system design; and learn about the selection of components to which the conversion rules are to be applied based on learning data including the evaluation values for the conversion of the components.

This invention is expected to enable effective learning even if the system configuration targeted during system design differs from the system configuration targeted during learning.

FIG. 1 is a schematic block diagram showing a functional configuration of a system design learning apparatus according to a first embodiment. FIG. 2 is a diagram showing an example of system requirements handled by the system design learning device according to the first embodiment. FIG. 2 is a diagram showing an example of system requirements before application of a conversion rule according to the first embodiment. FIG. 11 is a diagram showing an example of system requirements after application of conversion rules according to the first embodiment. 4 is a diagram showing an example of system design history information generated by a conversion rule application unit according to the first embodiment; FIG. FIG. 4 is a diagram showing an example of integrated data according to the first embodiment; 10 is a diagram showing an example of a correspondence relationship between nodes and parts in integrated data according to the first embodiment; FIG. 1 is a flowchart showing an example of a processing procedure in which the system design learning device according to the first embodiment generates learning data and performs learning. 4 is a flowchart showing an example of a processing procedure for the system design learning device according to the first embodiment to perform system design. 11 is a flowchart showing an example of a processing procedure in which the system design learning device according to the first embodiment updates an evaluation value indicated at a node of integrated data. 11 is a flowchart showing an example of a processing procedure for generating learning data by the system design learning device according to the first embodiment. 11 is a flowchart illustrating an example of a processing procedure in which the system design learning device according to the first embodiment calculates an evaluation value of a system configuration. FIG. 11 is a schematic block diagram showing a functional configuration of a system design learning apparatus according to a second embodiment. 13 is a flowchart showing an example of a processing procedure in which the system design learning device 200 according to the second embodiment generates learning data and performs learning. 13 is a flowchart illustrating an example of a processing procedure for calculating parts to be instantiated by an instantiation part detection unit 296 according to the second embodiment. FIG. 13 is a diagram illustrating an example of the configuration of a system design learning apparatus according to a third embodiment. 13 is a flowchart showing an example of a processing procedure in a system design learning method according to the fourth embodiment. FIG. 1 is a schematic block diagram illustrating a configuration of a computer according to at least one embodiment.

The following describes embodiments of the present invention, but the following embodiments do not limit the scope of the invention. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention.

First Embodiment
Fig. 1 is a schematic block diagram showing the functional configuration of a system design learning apparatus according to the first embodiment. In the configuration shown in Fig. 1, the system design learning apparatus 100 includes a communication unit 110, a display unit 120, an operation input unit 130, a storage unit 180, and a control unit 190. The control unit 190 includes a conversion rule application unit 191, a design evaluation unit 192, a rule application evaluation unit 193, a learning data generation unit 194, and a learning unit 195.

The system design learning device 100 performs system design automatically or semi-automatically. Then, the system design learning device 100 learns the system design process based on the result of the system design. The system design learning device 100 repeats system design using the learning result and learning using the result of the system design.
The system design learning device 100 may be configured using a computer such as a personal computer (PC) or a workstation. Alternatively, the system design learning device 100 may be configured using hardware dedicated to the system design learning device 100, such as an application specific integrated circuit (ASIC).

In the system design, the system design learning device 100 acquires system requirements for the system to be designed. The system requirements here are information describing the configuration that the system should have.
The components of the system to be designed can be described abstractly in the system requirements input to the system design learning device 100. The system design learning device 100 concretizes the system requirements to a level at which the system can be deployed by repeatedly applying predetermined conversion rules to the acquired system requirements.

Specifically, the system to be designed is composed of one or more components. The system design learning device 100 selects one of the components included in the system to be designed, and applies a transformation rule that concretizes the selected component. The system design learning device 100 performs system design by repeatedly selecting components and applying transformation rules.

The components referred to here are parts that can constitute a part of a system. In the system design performed by the system design learning device 100, conversion rules are applied to the components, and the system to be designed is realized on a component-by-component basis. The components of the system indicated in the system requirements are also referred to as system requirement components.
In addition, in this disclosure, it is assumed that a "component" may represent a configuration that is specified to the maximum extent that it cannot be converted into a more specific configuration, or a configuration that is specified to a desired extent (e.g., a functional module that realizes a certain function), depending on the configuration of the system desired as a deliverable. Therefore, the degree of specification of each component is not uniquely determined. Furthermore, a "component" may be defined in units such as "server", or more precisely in units such as "CPU", "memory", "hard disk", or more coarsely in units such as "system that performs face recognition". Therefore, the unit in which each component is defined is not uniquely determined.

In the following, a case will be described in which the system targeted by the system design learning device 100 is an ICT (Information and Communication Technology) system. However, the field of the system targeted by the system design learning device 100 is not limited to a specific field.
The application of a transformation rule to a system requirement is called a transformation. When it is specified that a transformation rule may be applied multiple times to a system requirement, it is called a transformation sequence. Thus, a transformation sequence is represented by a serial connection of one or more transformations.

Fig. 2 is a diagram showing an example of system requirements handled by the system design learning device 100. Fig. 2 shows an example of system requirements to be designed when the system design learning device 100 designs a suspicious person detection system.
2, the system requirements handled by the system design learning device 100 are described in the form of a directed graph, and attribute information is added to each of the nodes and edges. Both the nodes and edges are examples of components.

For example, a node may be assigned the name or identification information of the function or device that the node represents as attribute information. In the example of FIG. 2, node N101 represents a camera function (photographing function). Nodes N102 and N109 both represent network switches. Nodes N103 and N110 both represent routers. Node N104 represents a face recognition function. Node N105 represents a cloud platform. Node N106 represents a WAN (Wide Area Network). Node N107 represents a monitor function (image display function). Node N108 represents a server device.

The node may also have its abstraction level added as attribute information. In the example of FIG. 2, nodes N101, N104, N105, and N107 are abstract nodes. Meanwhile, nodes N102, N103, N106, N108, N109, and N110 are concrete nodes. Here, an abstract node is a node that can be converted into a node that represents a more concrete configuration than the current one by referring to a predetermined conversion rule at least once. Meanwhile, a concrete node (i.e., a node that has been concretized to a deployable level) is a node that cannot be converted into a node that represents a more concrete configuration even by referring to the conversion rule.

The system design learning device 100 applies the conversion rule to the system requirements so as to make the abstract nodes concrete. For example, the system design learning device 100 may apply a conversion rule to the system requirements illustrated in FIG. 2, which converts node N101 indicating a camera function into a subgraph including a node for a camera (imaging device) and a node for a control device that controls the camera.

In the example of FIG. 2, the attribute information "join" of each of the edges E101, E105, and E109, and the attribute information "http" of each of the edges E103 and E107 are shown. "Join" indicates an affiliation relationship. For example, the camera function indicated by node N101 is included in the LAN (Local Area Network) formed by the network switch indicated by node N102. The face recognition function indicated by node N104 is provided on the cloud platform indicated by node N105. The monitor function indicated by node N107 is controlled using the server device indicated by node N108.

"http" indicates communication using HTTP (Hyper Text Transfer Protocol). For example, edge E103 indicates that data is transmitted by HTTP from the camera function indicated by node N101 to the face recognition function indicated by node N105. Edge E107 indicates that data is transmitted by HTTP from the face recognition function indicated by node N105 to the monitor function indicated by node N107.

The edge may also have its abstraction level added as attribute information. In the example of FIG. 2, edges E101, E103, E105, E107, and E109 are abstract edges. On the other hand, edges E102, E104, E106, E108, E110, and E111 are concrete edges. Here, an abstract edge is an edge that can be converted into an edge that represents a more concrete configuration than the current one by referring to a predetermined conversion rule at least once. On the other hand, a concrete edge is an edge that cannot be converted into an edge that represents a more concrete configuration even by referring to the conversion rule (i.e., an edge that has been concretized to a deployable level).

The conversion rules used by the system design learning device 100 may include a conversion rule for instantiating an edge.
FIG. 3 is a diagram showing an example of system requirements before the conversion rules are applied.
3, a camera function indicated by node N201 is connected to a workstation indicated by node N202. A face recognition function indicated by node N203 is executed on a workstation indicated by node N204. An edge E201 indicates that data is transmitted by HTTP from the camera function indicated by node N201 to the face recognition function indicated by node N203.

4 shows an example of system requirements after applying the conversion rules. FIG. 4 shows an example of applying the conversion rules to the system requirements shown in FIG.
In Fig. 4, an edge E211 is provided instead of the edge E201 in Fig. 3. The edge E211 indicates that data is transmitted from the workstation indicated by node N202 to the workstation indicated by node N204 using TCP (Transmission Control Protocol). That is, Fig. 4 shows that the application of the conversion rules to the system requirements in Fig. 3 has resulted in conversion from communication using HTTP to communication using TCP.

However, the system targeted by the system design learning device 100 can be various systems that include components. The method of expressing the system targeted by the system design learning device 100 can be various methods to which conversion rules can be applied by identifying the type of component.

Depending on which of the multiple predetermined conversion rules the system design learning device 100 applies to the system requirements, and further depending on the order in which the system design learning device 100 applies the multiple conversion rules to the system requirements, the content (configuration) of the converted system requirements may differ. In particular, depending on the conversion rule applied to the system requirements and further depending on the order in which the multiple conversion rules are applied to the system requirements, the system design learning device 100 may succeed or fail in system design. In other words, the purpose of the system design learning device 100 is to concretize the system requirements to a level at which the system can be deployed. However, when some of the system components remain abstractly described, and there are no more applicable conversion rules, this typically (in principle) means that the system design learning device 100 has failed in system design.

In order to increase the possibility that the system design learning device 100 will succeed in system design, it is possible to learn conversion rules to be applied to system requirements. However, since systems generally vary in scale and configuration, it is considered that effective learning cannot be performed.
For example, when learning a system design model that outputs a set of conversion rules to be applied to input system requirements, it is possible that the system configuration that is the target at the time of system design differs from the system configuration that is the target at the time of learning. As a result, it is possible that the system requirements given at the time of system design differ from the system requirements given as learning data, and it is impossible to appropriately determine the set of conversion rules to be applied.

The system design learning device 100 then determines an evaluation for the application of each conversion rule based on the results of the system design obtained by repeatedly applying the conversion rules. The system design learning device 100 then aggregates the evaluations for the application of the conversion rules for each component to which the conversion rules are applied, and determines an evaluation for the components. The system design learning device 100 uses the evaluations for the components to learn a component evaluation model that, in response to an input system requirement, outputs an evaluation for each component indicated in the system requirement.

Then, the system design learning device 100 uses the learned component evaluation model to perform system design by repeatedly applying the conversion rules to the input system requirements.
The system design learning device 100 may use the component evaluation model to evaluate system requirements obtained by applying one conversion rule to the current system requirements. The system design learning device 100 may then select and apply, from among the conversion rules applicable to the current system requirements, a conversion rule that will result in the highest evaluation of the system requirements after application of the conversion rule.

Alternatively, the system design learning device 100 may select the component with the highest evaluation among the components of the current system requirements as the component to which the conversion rule is applied.
The current system requirement here is the system requirement input to the system design learning device 100, or the system requirement obtained by applying the conversion rule to the input system requirement. The evaluation of the system requirement is calculated, for example, as the maximum evaluation value of the components included in the system requirement.
Alternatively, the system design learning device 100 may calculate, as the evaluation value of a system requirement, a value other than the maximum value, such as the sum of the evaluation values of the components included in the system requirement or a minimum value.

Even if the configurations of systems used in the field targeted by the system design learning device 100 differ from system to system, it is expected that common or similar parts will be used. By having the system design learning device 100 learn about conversion on a component-by-component basis, it is expected that the same or similar parts as those used in the target system during system design will also be used in the target system during learning. In this regard, by having the system design learning device 100 learn about conversion on a component-by-component basis, effective learning can be performed even if the system configuration targeted during system design differs from the system configuration targeted during learning.

The communication unit 110 communicates with other devices. For example, the communication unit 110 may receive system requirements to be designed from the other devices.
The display unit 120 has a display screen, such as a liquid crystal panel or an LED (Light Emitting Diode) panel, and displays various images. For example, the display unit 120 may display the results of the system design by the system design learning device 100, such as whether the system design by the system design learning device 100 has succeeded in the system design and the system requirements when the system design has been successful.
The operation input unit 130 includes input devices such as a keyboard and a mouse, and receives user operations. For example, the operation input unit 130 may receive a user operation to instruct the start of system design.

The storage unit 180 displays various data. For example, the storage unit 180 stores a component evaluation model, system requirements such as input system requirements and current system requirements, and application rules. The storage unit 180 is configured using a storage device included in the system design learning apparatus 100.
The control unit 190 performs various processes by controlling each unit of the system design learning device 100. The functions of the control unit 190 are performed by a CPU (Central Processing Unit) included in the system design learning device 100 reading and executing a program from the storage unit 180.

The conversion rule application unit 191 performs system design by repeatedly applying conversion rules to components of a system to be designed, for which system requirements are given, until a design result of the system is obtained. The conversion rule application unit 191 corresponds to an example of a conversion rule application means.
Successful system design involves getting the system requirements specified at a level where the system can be deployed.

A system design failure (failure to design a system) includes determining that system requirements cannot be specified to a level at which the system can be deployed. For example, if the system requirements are not specified to a level at which the system can be deployed and there are no conversion rules that can be applied to the system requirements, the conversion rule application unit 191 determines that the system design has failed.

In addition, depending on the conversion rule, it is possible that the application of the conversion rule to the system requirements will result in a loop. Even if there is a conversion rule that can be applied to the system requirements, if there is no conversion sequence that does not form a loop (application of the conversion rule one or more times), the conversion rule application unit 191 determines that the system design has failed.

The conversion rule application unit 191 may also determine that the system design has failed if the system design is not successful even after the application of the conversion rules in the system design is repeated a predetermined number of times. In other words, the failure of the system design may include the case where the system design is not successful even after the application of the conversion rules in the system design is repeated a predetermined number of times.

When designing a system, the conversion rule application unit 191 generates history information of the system design. The history information generated by the conversion rule application unit 191 is used to determine evaluation values of system requirements and evaluation values of components included in the system requirements, and to generate learning data.
Fig. 5 is a diagram showing an example of system design history information generated by the conversion rule application unit 191. In the example of Fig. 5, the conversion rule application unit 191 generates a configuration path and a component path as the system design history information.

The configuration path shows the system requirements in chronological order, from the initial system requirements to the final system requirements, each time the conversion rule is applied. The initial system requirements here are system requirements provided to the system design learning device 100 as system requirements to be subjected to system design. The initial system requirements may be provided from outside the system design learning device 100. Alternatively, the system design learning device 100 may generate the initial system requirements for acquiring learning data.
The final system requirements here are system requirements when the design result of the system design is obtained. The design result of the system design here can be any result that can be evaluated for the system design. In the following, an example will be described in which the design result is a success or failure of the system design, but this is not limiting.

5, the number of times that the conversion rules are applied from the initial system requirements to the final system requirements is set to N, where N is a positive integer.
5, the configuration path is configured as time-series data of N+1 system requirements, and the part path is configured as time-series data of N parts.
The component to be converted the i-th time, which is indicated in the component path, is included in the i-th system requirement in chronological order in the configuration path, where i is an integer such that 1≦i≦N.

The final system requirements correspond to the system requirements after applying the conversion rules N times. The final system requirements result in the success or failure of the system design, so the design evaluation unit 192 can determine an evaluation value for each system design. For example, the design evaluation unit 192 may set the evaluation value of each system design to 1 if the system design results in a success, and set the evaluation value of each system design to 0 if the system design results in a failure.

A series of iterations of component selection and application of transformation rules from the initial system requirements to the final system requirements is called a system design round, or simply system design.
The conversion rule application unit 191 may generate, as system design history information, history information indicating the history of applied conversion rules in addition to the history of system requirements and the history of components to which conversion rules are applied.

The design evaluation unit 192 determines an evaluation value for the system design based on the design result of the system design. As described above, if the conversion rule application unit 191 succeeds in the system design, the design evaluation unit 192 may determine the evaluation value of the system design to be 1. If the conversion rule application unit 191 fails in the system design, the design evaluation unit 192 may determine the evaluation value of the system design to be 0.
The design evaluation unit 192 corresponds to an example of a design evaluation means.

The design evaluation unit 192 may determine an evaluation value for the system design based on the evaluation index value of the system obtained when the conversion rule application unit 191 succeeds in the system design, in addition to the result of the success or failure of the system design. Various types of evaluation index values can be used as the evaluation index value of the system here. For example, the design evaluation unit 192 may use, but is not limited to, an evaluation index value of the system's processing speed, an evaluation index value of reliability, an evaluation index value of construction costs, an evaluation index value of operation costs, or a combination of these.

The design evaluation unit 192 may store in advance a formula for calculating the evaluation index value of the system based on the components used in the system. Alternatively, the design evaluation unit 192 may acquire in advance through learning a model that outputs the evaluation index value of the system in response to the input of the system requirements.

The rule application evaluation unit 193 determines an evaluation value for conversion of each component in the system design based on the evaluation value for the system design. Specifically, the rule application evaluation unit 193 determines an evaluation value for conversion of a component for each component based on data obtained by integrating multiple system design histories for the same component. Data obtained by integrating multiple system design histories for the same component is referred to as integrated data.
The rule application evaluation unit 193 corresponds to an example of a rule application evaluation means.

Figure 6 is a diagram showing an example of integrated data. Figure 6 shows an example of integrated data displayed as a tree. The nodes of the tree shown in Figure 6 represent system requirements, and the edges represent transformation rules. The edges are extended from the node before the transformation rule is applied to the node after the transformation rule is applied. Multiple edges coming out of one node represent multiple transformation rules that can be applied to the same system requirement.

Node N301 is the root. Node N302 is one of the leaves. For example, one path from the root to a leaf, such as the path from node N301 to node N302, represents one system design. In this case, if the system requirements represented by the leaf are specified to a deployable level, the design evaluation unit 192 evaluates the result of the system design as a success. On the other hand, if the system requirements represented by the leaf are not specified to a deployable level, the design evaluation unit 192 evaluates the result of the system design as a failure.

The node at the start of system design is not limited to the root. For example, when system requirements that are specified to a certain extent as system requirements to be designed are input to the system design learning device 100, a node other than the root can be the node at the start of system design.
In addition, the node at the end of the system design is not limited to a leaf. For example, if one of the transformation rules includes a rule to replace an instantiated part with another instantiated part, the system design may end with the system requirements instantiated to a deployable level at a node other than a leaf.

The integrated data can be represented by various directed graphs, not limited to trees, depending on the transformation rules used in the system design. For example, if the same second system requirement can be obtained by applying different transformation sequences to a first system requirement, then in the statistical data, there will be multiple paths from the first node to the second node. In this case, the integrated data may be represented as a lattice.

In addition, if there is a conversion rule that applies the conversion rule one or more times to a certain system requirement and returns to the system requirement, the integrated data may be represented as an effective graph that includes a loop. If there is no path out of such a loop and none of the nodes included in the loop can obtain a system requirement that is specified to a deployable level, the design evaluation unit 192 may evaluate the result of the system design for the nodes included in the loop as a failure.

The integrated data may include two or more subgraphs that are independent of each other. In this case, two subgraphs are independent of each other if there is no path from the first subgraph to the second subgraph, and no path from the second subgraph to the first subgraph. For example, the integrated data may be represented as a forest.

7 is a diagram showing an example of the correspondence between nodes and parts in the integrated data. The system requirements shown in FIG. 7 are represented by nodes in the integrated data.
In the example of Fig. 7, the system requirements before application of the conversion rules include three parts P11, P12, and P13. Three conversion rules R11, R12, and R13 can be applied to the part P11. One conversion rule R14 can be applied to the part P12. Two conversion rules R15 and R16 can be applied to the part P13.

As described above, the edges of the integrated data are directed edges that indicate the conversion rules. The start end (the end on the starting point side) of the directed edge is connected to a node that indicates the system requirement before conversion, and the end end (the end on the ending point side) is connected to a node that indicates the system requirement after conversion.
In addition, edges coming out of one node are grouped for each component included in the system requirement indicated by the node, as exemplified in Fig. 7. This grouping may be indicated in the integrated data. For example, as shown in Fig. 7, components of the configuration requirements may be indicated in the nodes of the integrated data, and the starting point of an edge may be connected to one of the components to indicate the grouping.

The number of components in a system requirement and the number of conversion rules that can be applied to one component are not limited to a specific number. The number of components in a system requirement may be different before and after the application of the conversion rules. The number of conversion rules that can be applied to a component may be different for each component.

Further, the example of FIG. 7 shows that the system design learning device 100 calculates an evaluation value of the system requirement and an evaluation value for each component in the system requirement.
The evaluation values of the system requirements are written to nodes in the integrated data.
On the other hand, the evaluation value for each component in the system requirements is calculated when the learning data is generated and incorporated into the learning data.
There is no need to provide a storage area for the evaluation values of parts in the system requirements in the nodes of the integrated data.

The learning data generation unit 194 generates learning data for learning the component evaluation model. In particular, the learning data generation unit 194 generates learning data including evaluation values related to component transformation. Specifically, the learning data generation unit 194 generates learning data including a system requirement, any one of the components included in the system requirement, and an evaluation value of that component in the system requirement.

The learning unit 195 learns about the selection of parts to which the conversion rules are applied, based on the learning data including evaluation values related to the conversion of parts generated by the learning data generation unit 194. Specifically, the learning unit 195 performs learning of a part evaluation model.
The learning unit 195 corresponds to an example of a learning means.

Alternatively, when conversion rules are previously determined commonly for the system designs performed by the system design learning device 100, the learning unit 195 may learn about the selection of conversion rules to be applied to the system requirements. That is, the learning unit 195 may learn about the selection of conversion rules applicable to the components that are further subdivided from the selection of components included in the system requirements. Specifically, the learning unit 195 may learn a conversion rule evaluation model that receives an input of a system requirement and outputs an evaluation value for each of the conversion rules that can be applied to the system requirement.

FIG. 8 is a flowchart showing an example of a processing procedure in which the system design learning device 100 generates learning data and performs learning.
In the process of Fig. 8, the system design learning device 100 acquires the system requirements of the learning target (step S11). The system design learning device 100 may use the system requirements given as the system requirements of the design target as the system requirements of the learning target as well. Alternatively, the system design learning device 100 may acquire the system requirements of the learning target separately from the system requirements of the design target.

Next, the control unit 190 determines whether or not a learning termination condition is met (step S12). The learning termination condition may be based on, but is not limited to, the learning time, the number of learning iterations (the number of times the loop from step S12 to S24 has been repeated), the size of the learning error, etc.

When the control unit 190 determines that the end condition is met (step S12: YES), the system design learning device 100 ends the process of FIG.
On the other hand, if the control unit 190 determines that the termination condition is not satisfied (step S12: NO), the conversion rule application unit 191 performs system design for the system requirements of the learning target (step S21). Specifically, the conversion rule application unit 191 repeats application of the conversion rules to the system requirements of the learning target until the system design is successful or unsuccessful. During system design, the conversion rule application unit 191 generates a configuration path and a component path. Furthermore, if there is no node in the integrated data indicating the system requirement that appeared in the system design, the conversion rule application unit 191 adds a node indicating the system requirement that appeared in the system design to the integrated data.

Figure 8 shows an example in which the system design learning device 100 acquires multiple system requirements in step S11, and performs design for each system requirement in step S21. Alternatively, instead of acquiring system requirements in step S11, the system design learning device 100 may acquire one system requirement each time step S21 is executed, and perform system design for the acquired system requirements.

The system design learning device 100 may also design a system for different system requirements each time it performs the processing of step S21. Alternatively, the system design learning device 100 may design a system using a conversion sequence different from the conversion sequence used in the previous design in step S21 for the same system requirements as those used in the previous processing of step S21.

Next, the design evaluation unit 192 determines an evaluation value for the system design performed by the conversion rule application unit 191 (step S22).
For example, based on whether the conversion rule application unit 191 has succeeded or failed in the system design, the design evaluation unit 192 sets the evaluation value for the system design to 1 if the system design is successful, and sets the evaluation value for the system design to 0 if the system design is unsuccessful.
Alternatively, if the conversion rule application unit 191 succeeds in the system design, the design evaluation unit 192 may determine an evaluation value for the system design based on the obtained evaluation value of the system.

Next, the rule application evaluation unit 193 updates the evaluation value of the node of the integrated data based on the evaluation value of the system design determined in step S22 (step S23). For example, the rule application evaluation unit 193 determines the evaluation value of the node of the integrated data to be the largest evaluation value (the evaluation value with the highest evaluation) among the evaluation values of the child nodes of that node.

Next, the rule application evaluation unit 193 determines evaluation values of the components included in the system requirements and each component in the component path, and the learning data generation unit 194 generates and stores learning data (step S24).
Then, the learning unit 195 learns the part evaluation model using the learning data generated by the learning data generating unit 194 (step S25). As described above, the part evaluation model is a model that outputs, in response to an input of a system requirement, an evaluation for each part indicated in the system requirement.
After step S25, the process returns to step S12.

Fig. 9 is a flowchart showing an example of a processing procedure for system design performed by the system design learning device 100. The system design learning device 100 performs the processing of Fig. 9 in step S21 of Fig. 8. As described above for step S21 of Fig. 8, the system design learning device 100 generates configuration paths and component paths during system design, and also sets nodes of integrated data.
In the process of Fig. 9, a "current configuration" variable and a "next configuration" variable are used as variables whose values are system requirements. The system requirement indicated as the value of the "current configuration" variable is referred to as the "current configuration." The system requirement indicated as the value of the "next configuration" variable is referred to as the "next configuration."

In the process of Fig. 9, the conversion rule application unit 191 stores the system requirement received in step S11 of Fig. 8 in a "current configuration" variable (step S101). That is, the conversion rule application unit 191 sets the system requirement received in step S11 of Fig. 8 as the initial value of the "current configuration" variable.
Next, the conversion rule application unit 191 determines whether the "current configuration" is registered as a node in the integrated data (step S102). For example, the conversion rule application unit 191 compares the system requirements indicated in each node in the integrated data with the "current configuration".

If it is determined that the "current configuration" is not registered as a node in the integrated data (step S102: NO), the conversion rule application unit 191 registers the "current configuration" as a node in the integrated data (step S103). Registering a system requirement as a node in the integrated data means creating a new node indicating that system requirement.
Next, the conversion rule application unit 191 determines whether or not a termination condition for the system design is satisfied (step S104). For example, the conversion rule application unit 191 may determine that the termination condition for the system design is satisfied when there is no instantiation rule that can be applied to the "current configuration" or when the "current configuration" has been instantiated to a level where it can be deployed.

If it is determined that the termination condition is not satisfied (step S104: NO), the conversion rule application unit 191 selects one component to be instantiated from the "current configuration" and applies the conversion rule to it (step S111). By applying the conversion rule, the conversion rule application unit 191 instantiates the component.
The conversion rule application unit 191 stores the system requirements after applying the conversion rules in step S111 in the "next configuration" variable (step S112).

Next, the conversion rule application unit 191 determines whether the "next configuration" is registered as a node in the integrated data (step S113). For example, the conversion rule application unit 191 compares the system requirements indicated in each node in the integrated data with the "next configuration".
If it is determined that the "next configuration" is not registered as a node in the integrated data (step S113: NO), the conversion rule application unit 191 registers the "next configuration" as a node in the integrated data (step S121). Specifically, the conversion rule application unit 191 provides a node indicating the "next configuration" in the integrated data. Then, the conversion rule application unit 191 sets an edge between the nodes in which the node indicating the "current configuration" in the integrated data is the parent node and the node indicating the "next configuration" is the child node. This edge indicates the application of the conversion rule in step S111.

Then, the conversion rule application unit 191 stores the "next configuration" in the "current configuration" variable (step S122).
After step S122, the process proceeds to step S104.
On the other hand, if the conversion rule application unit 191 determines in step S113 that the "next configuration" is registered as a node in the integrated data (step S113: YES), the process proceeds to step S122. Therefore, in this case, the conversion rule application unit 191 does not perform the process of setting a node in the integrated data in step S121.

On the other hand, if it is determined in step S104 that the termination condition is met (step S104: YES), the conversion rule application unit 191 sets the system requirements that appeared in the current process of Fig. 9 in chronological order as a configuration path (step S131). Furthermore, the conversion rule application unit 191 sets the components selected as targets for application of the conversion rules in step S111 in chronological order among the components included in the system requirements in the configuration path as a component path (step S132).
After step S132, the system design learning device 100 ends the process of FIG.

On the other hand, if the conversion rule application unit 191 determines in step S102 that the "current configuration" has already been registered as a node of the integrated data, the process transitions to step S104. Therefore, in this case, the conversion rule application unit 191 does not perform the process of setting a node of the integrated data in step S103.

10 is a flowchart showing an example of a processing procedure for updating an evaluation value indicated at a node of integrated data by the system design learning device 100. The system design learning device 100 performs the processing of FIG.
In the process of Fig. 10, an "evaluation value of update candidate" variable is used as a variable that takes as its value the evaluation value of a system requirement. Also, in the process of Fig. 10, a "configuration to be updated" variable is used as a variable that takes as its value a pointer to one of the system requirements included in the configuration path. The evaluation value indicated as the value of the "evaluation value of update candidate" variable is referred to as the "evaluation value of update candidate." The system requirement pointed to by the value of the "configuration to be updated" variable is referred to as the "configuration to be updated."

10, the rule application evaluation unit 193 sets the system requirement indicated by the last node of the configuration path as the "configuration to be updated" (step S201). That is, the rule application evaluation unit 193 sets the value of the "configuration to be updated" variable so that the value of the "configuration to be updated" variable points to the last node of the configuration path. The nodes of the configuration path are the individual system requirements included in the configuration path.
Furthermore, the rule application evaluation unit 193 sets the initial value of the "evaluation value of update candidate" variable to the evaluation value of the system design determined in step S22 of FIG. 8 (step S202).

Next, the rule application evaluation unit 193 determines an evaluation value of a node representing the "configuration to be updated" in the integrated data (step S203). The evaluation value of a node in the integrated data is the evaluation value of the system requirement indicated by that node.
Specifically, the rule application evaluation unit 193 compares the evaluation value of the node representing the "configuration to be updated" in the integrated data with the "evaluation value of the update candidate." If the "evaluation value of the update candidate" is greater, the rule application evaluation unit 193 updates the evaluation value of the node representing the "configuration to be updated" in the integrated data to the "evaluation value of the update candidate." On the other hand, if the evaluation value of the node representing the "configuration to be updated" in the integrated data is greater, the rule application evaluation unit 193 leaves the evaluation value of the node representing the "configuration to be updated" in the integrated data unchanged.
If an evaluation value for a node has not been set, the rule application evaluation unit 193 performs processing assuming that the evaluation value for that node is set to 0.

Next, the rule application evaluation unit 193 updates the value of the "evaluation value of the update candidate" (step S204). Specifically, the rule application evaluation unit 193 sets the "evaluation value of the update candidate" to the value determined in step S203 as the evaluation value of the node representing the "configuration to be updated" in the integrated data.
Next, the rule application evaluation unit 193 determines whether the "configuration to be updated" is the first system requirement in the configuration path (step S205).

When the rule application evaluation unit 193 determines that the "configuration to be updated" is the first system requirement of the configuration path (step S205: YES), the system design learning device 100 ends the processing of FIG.
On the other hand, if it is determined that the "configuration to be updated" is not the first system requirement in the configuration path (step S205: NO), the rule application evaluation unit 193 sets the system requirement immediately preceding the "configuration to be updated" on the configuration path as the "configuration to be updated" (step S211).
After step S211, the process returns to step S203.

11 is a flowchart showing an example of a processing procedure for generating learning data by the system design learning device 100. The system design learning device 100 performs the processing of FIG.
In Figure 11, a "target configuration" variable is used as a variable whose value is a pointer to one of the system requirements in the configuration path. Also, in the process of Figure 11, a "target component" variable is used as a variable whose value is a pointer to one of the components in the component path. A system requirement indicated as the value of the "target configuration" variable is referred to as a "target configuration." A component indicated as the value of the "target component" variable is referred to as a "target component."

11, the learning data generation unit 194 sets the first system requirement of the configuration path as the "target configuration" (step S301). That is, the learning data generation unit 194 sets the value of the "target configuration" variable so that the value of the "target configuration" variable indicates the first system requirement of the configuration path.
Next, the learning data generation unit 194 designates the first part in the part path as the "target part" (step S302). That is, the learning data generation unit 194 sets the value of the "target part" variable so that the value of the "target part" variable indicates the first part in the part path.
Then, the learning data generation unit 194 lists all directed edges that are grouped with the "target part" among the directed edges starting from the node representing the "target configuration" in the integrated data (step S303).

The learning data generation unit 194 determines the maximum evaluation value among the evaluation values recorded in the end nodes of each directed edge listed in step S303 as the evaluation value of the "target part" (step S304).
In addition, the learning data generation unit 194 generates a pair of the “target configuration”, the “target part”, and the evaluation value of the “target part” determined in step S304 as learning data, and stores the generated learning data in the memory unit 180 (step S305).

The learning data generation unit 194 also determines whether the "target part" is the last part in the part path (step S306). That is, the learning data generation unit 194 determines whether the value of the "target part" variable indicates the last part in the part path.
If it is determined that the "target part" is not the last part in the part path (step S306: NO), the learning data generation unit 194 sets the part immediately following the "target part" on the part path as the "target part" (step S311). In other words, the learning data generation unit 194 updates the value of the "target part" variable so that it points to the immediately following part on the part path.
The learning data generation unit 194 also sets the system requirement immediately following the "target configuration" on the configuration path as the "target configuration" (step S312). That is, the learning data generation unit 194 updates the value of the "target configuration" variable so that it points to the system requirement immediately following on the configuration path.
After step S312, the process proceeds to step S303.

On the other hand, if it is determined in step S306 that the "target part" is the last part in the part path (step S306: NO), the system design learning device 100 ends the processing in Fig. 11. In this case, the processing transitions to step S25 in Fig. 8.
8, if the component path is empty at the start of step S24, the system design learning device 100 omits the process of step S24. In this case, the system design learning device 100 does not perform the process of FIG.

In step S25 of FIG. 8, the learning unit 195 uses each of the learning data generated by the learning data generating unit 194 to learn the part evaluation model.
In this learning, the learning unit 195 updates the parameter values of the part evaluation model so that, when the system requirements indicated in the learning data are input to the part evaluation model, the evaluation value output by the part evaluation model for the part indicated in the learning data approaches the evaluation value of the part indicated in the learning data.

FIG. 12 is a flowchart showing an example of a processing procedure in which the system design learning device 100 calculates the evaluation value of a system requirement.
In the process of FIG. 12, the rule application evaluation unit 193 acquires the system requirements to be evaluated (step S401).

Then, the rule application evaluation unit 193 calculates an evaluation value of each part included in the system to be evaluated using the part evaluation model trained in step S25 of FIG. 8 (step S402).
Specifically, the rule application evaluation unit 193 inputs the system requirements to be evaluated to a component evaluation model, and obtains the evaluation value of each component output by the component evaluation model.

Then, the rule application evaluation unit 193 integrates the evaluation values of the components to calculate an evaluation value of the entire system requirement (step S403). The method by which the rule application evaluation unit 193 integrates the evaluation values of the components is not limited to a specific method. For example, the rule application evaluation unit 193 may calculate the maximum, minimum, or average of the evaluation values of the components as the integrated value of the evaluation values of the components, but is not limited to these.
After step S403, the system design learning device 100 ends the process of FIG.

As described above, the conversion rule application unit 191 performs system design by repeatedly applying conversion rules to components of a system to be designed, for which system requirements are given, until a design result for the system design is obtained. The design evaluation unit 192 determines an evaluation value for the system design based on the design result. The rule application evaluation unit 193 determines an evaluation value for the conversion of each component in the system design based on the evaluation value for the system design. The learning unit 195 learns about the selection of components to which conversion rules are applied, based on learning data including evaluation values for the conversion of components.

Here, in a method of learning a system design model that outputs a set of conversion rules to be applied in response to input system requirements, it is considered that the system configuration targeted at the time of system design may differ from the system configuration targeted at the time of learning, due to the fact that systems generally vary in scale and configuration. As a result, it is considered that the system requirements given at the time of system design may differ from the system requirements given as learning data, and it may not be possible to appropriately determine the set of conversion rules to be applied. In this way, it is considered that effective learning cannot be performed with a method of learning a system design model that outputs a set of conversion rules to be applied in response to input system requirements.

On the other hand, even if the configurations of systems used in the field targeted by the system design learning device 100 differ from system to system, it is expected that common or similar parts will be used. By having the system design learning device 100 learn about conversion on a component-by-component basis, it is expected that the same or similar parts as those used in the target system during system design will also be used in the target system during learning. In this regard, by having the system design learning device 100 learn about conversion on a component-by-component basis, effective learning can be performed even if the system configuration targeted during system design differs from the system configuration targeted during learning.

Furthermore, the rule application evaluation unit 193 determines an evaluation value for component conversion for each component of the system requirement based on data obtained by integrating multiple system design histories for the same system requirement.
This allows the system design learning device 100 to learn how to select components to which conversion rules are applied, using learning data that aggregates the results of multiple system designs. In this regard, the system design learning device 100 is expected to be able to perform learning with high accuracy.

The above system design result indicates either a successful system design or a failed system design.
As a result, it is expected that the learning data generation unit 194 will generate learning data that will be highly evaluated when a transformation sequence that will result in successful system design exists, and the learning unit 195 will perform learning in a way that increases the likelihood of successful system design.

However, as described above, the system design result is not limited to indicating either a successful system design or a failed system design.
For example, the system design result may indicate that the system design has been successful, that the system design has failed, or that the success or failure of the system design is undetermined. In this case, the design evaluation unit 192 may determine the evaluation value for the system design to be the evaluation value indicating the highest evaluation in the order of success of the system design, success of the system design is undetermined, and failure of the system design.

Successful system design also includes having system requirements specified at a level that allows the system to be deployed.
As a result, it is expected that the learning data generation unit 194 will generate learning data that will be highly evaluated when there is a transformation sequence that can be concretized at a level at which the system can be deployed, and that the learning unit 195 will perform learning in a way that increases the likelihood that the system can be concretized at a level at which the system can be deployed.

Additionally, failure to design the system as described above may include determining whether or not to obtain system requirements specified at a level that allows the system to be deployed.
As a result, it is expected that the learning data generation unit 194 will generate learning data that will be evaluated low when there is no transformation sequence that can be realized at a level at which the system can be deployed, and the learning unit 195 will perform learning in a way that increases the likelihood that the system can be realized at a level at which the system can be deployed.

Furthermore, when the design result indicates that the system design is successful, the design evaluation unit 192 determines an evaluation value for the system design based on the obtained system evaluation index value.
This allows the system design learning device 100 to learn using more detailed learning data, such as learning data reflecting not only the results of successful or failed system designs, but also the performance evaluation of the resulting system, etc. In this respect, the system design learning device 100 can perform learning with high accuracy.

In this case, successful system design may include, but is not limited to, having system requirements specified at a level that allows the system to be deployed.
A successful system design may be defined as being part of an event of obtaining system requirements specified at a level at which the system can be deployed, for example, a successful system design may be obtaining system requirements specified at a level at which the system can be deployed and satisfying a predetermined condition regarding installation space.
This allows the learning unit 195 to perform learning so as to be able to deal with other conditions in addition to the conditions for realizing the system.

Second Embodiment
Fig. 13 is a schematic block diagram showing the functional configuration of a system design learning apparatus according to the second embodiment. In the configuration shown in Fig. 13, a system design learning apparatus 200 includes a communication unit 110, a display unit 120, an operation input unit 130, a storage unit 180, and a control unit 290. The control unit 290 includes a conversion rule application unit 191, a design evaluation unit 192, a rule application evaluation unit 193, a learning data generation unit 194, a learning unit 195, and an instantiation part detection unit 296.

13, parts having similar functions to those of the parts in FIG. 1 are given the same reference numerals (110, 120, 130, 180, 191 to 195) and detailed description thereof will be omitted here.
The system design learning device 200 differs from the system design learning device 100 in that the control unit 290 further includes a concrete part detection unit 296 in addition to the units included in the control unit 190. Also, in the system design learning device 200, the process performed by the conversion rule application unit 191 is concretized into a process that uses concrete part information generated by the concrete part detection unit 296.
In other respects, the system design learning device 200 is similar to the system design learning device 100, and the control unit 290 is similar to the control unit 190. The system design learning device 200 corresponds to an example of the system design learning device 100.

The instantiation part detection unit 296 generates instantiation part information indicating a part instantiated by each conversion rule that can be used in system design by the conversion rule application unit 191. The instantiation part detection unit 296 corresponds to an example of an instantiation part detection means.
The conversion rules that the conversion rule application unit 191 can use for system design may be all conversion rules prepared in advance. For example, the conversion rules that the conversion rule application unit 191 can use for system design may be all conversion rules stored in the storage unit 180.

Alternatively, some of the conversion rules prepared in advance may be conversion rules that can be used for system design by the conversion rule application unit 191. For example, the storage unit 180 may store, for each type of system, conversion rules that can be used for designing the system of that type.
Alternatively, the conversion rules that the conversion rule application unit 191 can use in system design may be implemented in a manner other than the manner in which the memory unit 180 stores the conversion rules, such as by incorporating the conversion rules into a circuit and implementing them in hardware.

The components that the conversion rules instantiate can be detected as components that are included in the system requirements before the conversion rules are applied, but are not included in the system requirements after the conversion rules are applied. For example, in the conversion rules that convert the system requirements shown in FIG. 3 into the system requirements shown in FIG. 4, the communication means shown by edge E201 in FIG. 3 is an example of a component that is included in the system requirements before the conversion rules are applied, but is not included in the system requirements before the conversion rules are applied. In this conversion rule, the communication means shown by edge E201 is instantiated into the communication means shown by edge E211 in FIG. 4.

The storage unit 180 stores conversion rules including the system requirements before application of the conversion rules illustrated in FIG. 3 and the system requirements after application of the conversion rules illustrated in FIG. 3. The conversion rules can be expressed as an equation with the system requirements before application of the conversion rules on the left side and the system requirements after application of the conversion rules on the right side. Hereinafter, the system requirements before application of the conversion rules are also referred to as the left side of the conversion rules, or simply the left side. The system requirements after application of the conversion rules are also referred to as the right side of the conversion rules, or simply the right side.

As described above, when a conversion rule is expressed using system requirements before the conversion rule is applied and system requirements after the conversion rule is applied, one method for detecting a conversion rule that can be applied to the system requirements to be converted is to actually attempt to apply the conversion rule. In this case, attempting to apply a conversion rule to a system requirement means performing a process of applying the conversion rule to the system requirement, regardless of whether or not the conversion is actually performed.

When an attempt is made to apply a conversion rule to the system requirements to be converted, and a component is instantiated, it can be determined that the conversion rule is applicable to the system to be converted. On the other hand, if a component is not instantiated, it can be determined that the conversion rule is not applicable to the system to be converted.

For example, the conversion rule application unit 191 according to the first embodiment may use this method to detect candidates for conversion rules in step S111 of FIG. 9, and select one of the detected candidates as the conversion rule to be applied to the system requirements to be converted.
In this case, the conversion rule application unit 191 attempts to apply each of the conversion rules available for system design to the system requirements to be converted, which are indicated as “current configuration.” The conversion rule application unit 191 then compares the system requirements before attempting to apply the conversion rules with the system requirements after attempting to apply the conversion rules, to determine whether any parts have been instantiated.

If it is determined that there is a concretized part, the conversion rule application unit 191 can determine that the conversion rule is applicable to the "current configuration". On the other hand, if it is determined that there is no concretized part, the conversion rule application unit 191 can determine that the conversion rule is not applicable to the "current configuration".

The conversion rule application unit 191 determines, as candidates, the conversion rules that it has determined to be applicable to the "current configuration," and selects one of the candidates as the conversion rule to be applied to the system requirements to be converted.
However, the method in which the conversion rule application unit 191 according to the first embodiment selects a conversion rule to be applied to a system requirement to be converted is not limited to a specific method.

The process of detecting conversion rules that can be applied to the system requirements to be converted from among the conversion rules that can be used in system design is not limited to the system design learning device 100, but is generally required for devices that perform system design by repeatedly instantiating components by applying conversion rules to the system requirements.

In a method for detecting conversion rules that can be applied to the system requirements to be converted by attempting to apply the conversion rules to the system requirements to be converted, it is necessary to attempt to apply all conversion rules that can be used in the system design to the system requirements to be converted. In this respect, this method has a high computational cost. In particular, with this method, the greater the number of conversion rules that can be used in the system design and the greater the number of times that conversion rules are applied to the system requirements, the higher the computational cost.

As described above, when a conversion rule is expressed using system requirements before the conversion rule is applied and system requirements after the conversion rule is applied, another method for detecting a conversion rule applicable to the system requirements to be converted is to determine whether the system requirements to be converted include a system requirement shown as the left-hand side of the conversion rule. Specifically, it can be determined whether any part of the system requirements to be converted matches the system requirement shown as the left-hand side of the conversion rule, for example by performing pattern matching on various parts of the system requirements to be converted.

Both the method of actually trying to apply the conversion rule and the method of determining whether the system requirement to be converted includes the system requirement shown as the left-hand side of the conversion rule result in a non-deterministic polynomial (NP) complete problem called the subgraph isomorphism determination problem, and in this respect, the computational cost is high. In particular, with both of these methods, the computational cost increases the more conversion rules available for system design, the larger the scale of the system requirement to be converted, and the more times the conversion rules are applied to the system requirements.
The computational cost of finding conversion rules applicable to the system requirements to be converted increases the time required for system design.

The concrete part detection unit 296 therefore generates concrete part information in advance for each conversion rule that the conversion rule application unit 191 can use in system design, and links the conversion rule to the concrete part information indicating the part that the conversion rule concretizes. "In advance" here may be before the conversion rule application unit 191 processes the system design. For example, "in advance" here may be before the conversion rule application unit 191 processes step S21 in FIG. 8.

The method by which the instantiation part detection unit 296 links the conversion rule with the instantiation part information is not limited to a specific method.
For example, the storage unit 180 may store one conversion rule per row in the form of a data table having items for the left side, right side, and instantiation part information. The instantiation part detection unit 296 may then write the instantiation part information generated for each conversion rule in the instantiation part information column of the row in which the conversion rule is stored.
Alternatively, the storage unit 180 may store the conversion rule and the concrete part information as separate information. Then, the concrete part detection unit 296 may link one conversion rule with the concrete part information indicating a part that the conversion rule embodies, thereby linking the conversion rule with the concrete part information.

The instantiation part detection unit 296 compares the left side and the right side of each conversion rule, and detects parts that are present on the left side and not present on the right side. The instantiation part detection unit 296 determines that the detected parts are parts that are instantiated by that conversion rule, and generates instantiation part information indicating that that conversion rule instantiates that part. The instantiation part detection unit 296 may store the instantiation part information in the storage unit 180, as described above.

By having the concrete part detection unit 296 generate concrete part information in advance, the conversion rule application unit 191 can refer to the concrete part information and narrow down the candidate conversion rules to be applied to the system requirements to be converted from among the conversion rules that can be used in system design.
Specifically, the conversion rule application unit 191 determines whether or not the part indicated in the concrete part information is included in the system requirements to be converted. If it is determined that the part indicated in the concrete part information is included in the system requirements to be converted, the conversion rule application unit 191 includes the conversion rule linked to the concrete part information in the candidates for the conversion rule to be applied to the system requirements to be converted. On the other hand, if it is determined that the part indicated in the concrete part information is not included in the system requirements to be converted, the conversion rule application unit 191 does not include the conversion rule linked to the concrete part information in the candidates for the conversion rule to be applied to the system requirements to be converted.

In this case, the candidate conversion rules to be applied to the system requirements to be converted satisfy the necessary conditions for being applicable to the system requirements to be converted. If the left-hand side of the conversion rule includes other components in addition to the component to be instantiated, it is possible that it indicates the relationship between the component to be instantiated and the other components. If the system requirements to be converted, in addition to including the component to be instantiated, also satisfy the relationship between the component to be instantiated and the other components, the candidate conversion rules to be applied to the system requirements to be converted are applicable to the system to be converted.

In general, candidates for conversion rules to be applied to the system requirements to be converted are likely to include conversion rules that are inapplicable because they do not satisfy the relationships between the parts to be instantiated and other parts.
On the other hand, if the system requirements are appropriately given and the component evaluation model is appropriately trained, it is expected that the candidates for conversion rules to be applied to the system requirements to be converted include at least one applicable conversion rule. In this case, the conversion rule application unit 191 detects a conversion rule applicable to the system requirements to be converted from among the candidates for conversion rules to be applied to the system requirements to be converted. Since the candidates for conversion rules to be judged as to whether they are applicable to the system requirements are narrowed down, it is expected that the calculation cost will be low.

Alternatively, the conversion rule application unit 191 may directly select a conversion rule to be applied to the system requirements to be converted from among the candidate conversion rules to be applied to the system requirements to be converted. Specifically, the conversion rule application unit 191 may attempt to apply one of the candidate conversion rules to the system requirements to be converted to the system requirements to be converted, and determine whether or not the candidate is applicable to the system requirements to be converted. In this case, since the candidate conversion rules to be applied to the system requirements to be converted are narrowed down, it is expected that the computational cost of the process of selecting a conversion rule to be applied to the system requirements to be converted will be low.

The concrete part information generated by the concrete part detection unit 296 can be used to detect candidates for conversion rules to be applied to various system requirements. Therefore, the concrete part detection unit 296 only needs to generate the concrete part information before the conversion rule application unit 191 performs the system design process, and does not need to generate the concrete part information each time the conversion rule application unit 191 applies a conversion rule to a system requirement. In this respect, it is expected that the increase in calculation cost will be small even if the conversion rule application unit 191 applies the conversion rules to system requirements more frequently.

14 is a flowchart showing an example of a processing procedure for generating learning data and performing learning by the system design learning device 200. The system design learning device 200 may perform the processing in FIG. 14 instead of the processing in FIG.
In the process of Fig. 14, the system design learning device 200 acquires the system requirements of the learning target (step S511). The system design learning device 200 may use the system requirements given as the system requirements of the design target as the system requirements of the learning target as well. Alternatively, the system design learning device 200 may acquire the system requirements of the learning target separately from the system requirements of the design target.

Next, the concrete part detection unit 296 detects parts that are concreted by the conversion rule for each conversion rule that the conversion rule application unit 191 can use in system design, and generates concrete part information (step S512). As described above, the concrete part detection unit 296 may store the concrete part information in the storage unit 180.

Next, the control unit 290 determines whether or not a learning termination condition is met (step S513). The learning termination condition may be based on, but is not limited to, the learning time, the number of learning iterations (the number of times the loop from step S513 to step S525 has been repeated), the size of the learning error, etc.

If the control unit 290 determines that the end condition is met (step S513: YES), the system design learning device 200 ends the processing of FIG.
On the other hand, if the control unit 290 determines that the end condition is not met (step S513: NO), the process proceeds to step S521.
The processing in steps S521 to S525 is the same as the processing in steps S21 to S25 in FIG. 8, except that in step S521, the conversion rule application section 191 performs system design using the instantiation component information.

The process in step S521 in Fig. 14 corresponds to an example of the process in step S21 in Fig. 8. For example, when the system design learning device 200 performs the process in Fig. 9 in step S521 in Fig. 14, the conversion rule application unit 191 refers to the instantiation part information in the process of step S111. Specifically, in the process of step S111, the conversion rule application unit 191 may select one conversion rule to be applied to the selected part from among the conversion rules linked to the instantiation part information indicating the part.
After step S525, the process returns to step S513.

In the processing of step S111 described above, the conversion rule application unit 191 may use a component evaluation model when selecting one component to be instantiated from the "current configuration". For example, the conversion rule application unit 191 may input the system requirements shown as the "current configuration" into a component evaluation model and obtain an evaluation for each component of the "current configuration". The conversion rule application unit 191 may then select the component to be instantiated based on the obtained evaluation for each component, such as selecting the part with the highest evaluation as the part to be instantiated.

As described above regarding the learning by the learning unit 195, the component evaluation model outputs a high evaluation when there is a conversion sequence that is successful in system design. It is expected that the conversion rule application unit 191 will select components that are highly evaluated by the component evaluation model, thereby increasing the possibility of successful system design.

In the process of step S111 described above, when the conversion rule application unit 191 selects a conversion rule to be applied to the selected part from among the conversion rule candidates, a part evaluation model may be used.
For example, the conversion rule application unit 191 may apply each of the conversion rule candidates to the system requirements shown as the "current configuration" to obtain system requirements after the conversion rules are applied for each conversion rule candidate. The conversion rule application unit 191 may then input each of the system requirements after the conversion rules are applied to a component evaluation model to obtain an evaluation of the system requirements after the conversion rules are applied for each conversion rule candidate.

As described above, the component evaluation model outputs an evaluation for each component indicated in the system requirements in response to the input of the system requirements. The conversion rule application unit 191 then calculates an evaluation for the entire system requirements based on the evaluation for each component. For example, as described above for the system design learning device 100, the conversion rule application unit 191 may calculate the maximum value of the evaluation values for each component as the evaluation value for the entire system requirements.

The conversion rule application unit 191 may select one of the conversion rule candidates as the conversion rule to be applied to the selected component based on the evaluation of the system requirements after the conversion rules are applied, such as by selecting the conversion rule candidate that has the highest evaluation for the system requirements after the conversion rules are applied.

The conversion rule application unit 191 uses the component evaluation model to calculate the evaluation of the system requirements after applying the conversion rules, and selects the conversion rules that give a high evaluation of the system requirements after applying the conversion rules, which is expected to increase the chances of successful system design.

15 is a flowchart showing an example of a processing procedure for calculating parts to be instantiated by the instantiation part detection unit 296. The instantiation part detection unit 296 performs the processing of FIG.
15, the embodiment part detection unit 296 checks whether there is any conversion rule that has not been selected in step S541 (step S531). If the process of step S541 has not been performed even once, the embodiment part detection unit 296 may determine that all conversion rules that can be used in system design have not been selected.
If it is determined that there is no unselected conversion rule (step S531: NO), the embodiment part detection unit 296 ends the process of FIG.

On the other hand, if it is determined in step S531 that there are unselected conversion rules (step S531: YES), the instantiation part detection unit 296 selects one conversion rule from the unselected conversion rules (step S541).
In the following description, the conversion rule selected by the embodiment part detection unit 296 in the latest execution of step S541 among the repeated executions of step S541 will also be referred to as the target conversion rule.

Next, the instantiation part detection unit 296 compares the left and right sides of the target conversion rule (step S542).
Next, the concrete part detection unit 296 detects parts that are on the left side of the target conversion rule but not on the right side, and generates concrete part information that indicates the detected parts as parts that are concreted by the target conversion rule (step S543). As described above, the concrete part detection unit 296 links the conversion rule with the concrete part information that indicates the parts that are concreted by the conversion rule. The concrete part detection unit 296 may store the concrete part information in the storage unit 180.
After step S543, the process transitions to step S531.

The instantiation part information indicates, for each conversion rule, the parts that the conversion rule instantiates. By referencing the instantiation part information both during learning and during design, the system design learning device 200 eliminates the need to detect the parts that each conversion rule instantiates each time it applies a conversion rule to a system requirement. In this respect, the system design learning device 200 can improve both the computational costs incurred during the learning process and the computational costs incurred during the design process.

One method for selecting the next state after applying conversion rules to a system requirement is to try to apply all conversion rules available for system design to the system requirement to be converted. In this method, for example, an evaluation value for the system requirement after the application of the conversion rule is attempted is calculated for each conversion rule, and the system requirement as the next state is selected based on the calculated evaluation value.
However, this method is computationally expensive since it is necessary to try to apply all the conversion rules.

On the other hand, in the system design learning device 200, the conversion rule application unit 191 can select the components to be instantiated based on the evaluation of each component obtained using the component evaluation model when selecting the next state by applying the conversion rules to the system requirements, both during learning and design. The conversion rule application unit 191 then attempts to apply only the conversion rules that instantiate the selected components to the system requirements as the current state, and can select the system requirement as the next state from among the next state candidates derived as a result.

The system design learning device 200 attempts to apply only the transformation rules that instantiate the selected components, and in this respect, the calculation cost is lower than that of the above-mentioned methods. In this respect, the system design learning device 200 is expected to require shorter learning times and shorter design times.

In the second embodiment, various methods are possible for the conversion rule application unit 191 to select a next state from among the next state candidates. For example, the conversion rule application unit 191 may select the next state based on the evaluation value of the system requirement obtained using the evaluation method shown in FIG. 12. In this case, the conversion rule application unit 191 may select the system requirement with the largest evaluation value as the next state, or may select a system requirement other than the above. Alternatively, the conversion rule application unit 191 may select the next state randomly without using the evaluation method shown in FIG. 12.

As described above, the instantiation part detection unit 296 generates instantiation part information indicating the parts instantiated by each conversion rule that the conversion rule application unit 191 can use in system design. The conversion rule application unit 191 determines the conversion rules to be used in system design based on the instantiation part information.
The conversion rule application unit 191 determines the conversion rules to be used in system design based on the concrete component information, so there is no need to find conversion rules applicable to the system requirements each time a conversion rule is determined. In this respect, according to the system design learning device 200, it is expected that both the time required for learning and the time required for design will be short.

Furthermore, the learning unit 195 learns a component evaluation model that outputs an evaluation for each component indicated in a system requirement when the system requirement is input. The conversion rule application unit 191 selects a component to which a conversion rule is to be applied based on the evaluation of the component evaluation model for each component indicated in the system requirement, selects one conversion rule from among the conversion rule candidates that are conversion rules indicated in the instantiated component information as applicable to the selected component, and applies the selected conversion rule to the selected component.
It is expected that the conversion rule application unit 191 will have a higher chance of succeeding in system design by selecting components based on evaluations using the component evaluation model.

In addition, the conversion rule application unit 191 selects one of the conversion rule candidates as the conversion rule to be applied to the selected component based on an evaluation of the component evaluation model for each conversion rule candidate against the system requirements after application of the conversion rule obtained by applying the conversion rule candidate to the system requirements.
It is expected that the conversion rule application unit 191 will be more likely to succeed in system design by selecting a conversion rule based on an evaluation of the system requirements after application of the conversion rule, obtained using a component evaluation model.

Third Embodiment
Fig. 16 is a diagram showing an example of the configuration of a system design learning apparatus according to the third embodiment. A system design learning apparatus 610 shown in Fig. 16 includes a conversion rule application unit 611, a design evaluation unit 612, a rule application evaluation unit 613, and a learning unit 614.
In this configuration, the conversion rule application unit 611 performs system design by repeatedly applying conversion rules to components of a system to be designed, for which system requirements are given, until a design result of the system design is obtained. The design evaluation unit 612 determines an evaluation value for the system design based on the design result. The rule application evaluation unit 613 determines an evaluation value for the conversion of each component in the system design based on the evaluation value for the system design. The learning unit 614 learns about the selection of components to which conversion rules are applied, based on learning data including evaluation values for component conversion.
The conversion rule application unit 611 corresponds to an example of a conversion rule application means. The design evaluation unit 612 corresponds to an example of a design evaluation means. The rule application evaluation unit 613 corresponds to an example of a rule application evaluation means. The learning unit 614 corresponds to an example of a learning means.

As described above, the method of learning a system design model that outputs a set of conversion rules to be applied in response to input system requirements may not be able to provide effective learning, due to the fact that systems generally vary in size and configuration.
On the other hand, even if the configurations of systems used in the field targeted by the system design learning device 610 are different for each system, it is expected that common parts or similar parts will be used. By having the system design learning device 610 learn about conversion on a part-by-part basis, it is expected that the same parts or similar parts as those used in the target system during system design will also be used in the target system during learning. In this regard, by having the system design learning device 610 learn about conversion on a part-by-part basis, effective learning can be performed even if the system configuration targeted during system design is different from the system configuration targeted during learning.

Fourth Embodiment
FIG. 17 is a flowchart showing an example of a processing procedure in the system design learning method according to the fourth embodiment.
The process shown in FIG. 17 includes applying transformation rules (step S611), evaluating the design (step S612), evaluating the rule application (step S613), and learning (step S614).

In applying the conversion rules (step S611), a system is designed by repeatedly applying the conversion rules to the components of the system to be designed, for which system requirements are given, until a design result of the system design is obtained. In evaluating the design (step S612), an evaluation value for the system design is determined based on the design result. In evaluating the rule application (step S613), an evaluation value for the conversion of each component in the system design is determined based on the evaluation value for the system design. In learning (step S614), learning is performed on the selection of components to which the conversion rules are applied, based on learning data including evaluation values for the conversion of components.

As described above, the method of learning a system design model that outputs a set of conversion rules to be applied in response to input system requirements may not be able to provide effective learning, due to the fact that systems generally vary in size and configuration.
On the other hand, even if the configurations of systems used in the field targeted by the process shown in Fig. 17 are different for each system, it is expected that common parts or similar parts will be used. By performing learning about conversion on a part-by-part basis in the process shown in Fig. 17, it is expected that the same parts or similar parts as those used in the target system at the time of system design will also be used in the target system at the time of learning. In this respect, by performing learning about conversion on a part-by-part basis in the process shown in Fig. 17, effective learning can be performed even if the system configuration targeted at the time of system design is different from the system configuration targeted at the time of learning.

FIG. 18 is a schematic block diagram illustrating a configuration of a computer according to at least one embodiment.
In the configuration shown in FIG. 18, a computer 700 includes a CPU 710 , a main memory device 720 , an auxiliary memory device 730 , and an interface 740 .

Any one or more of the above-mentioned system design learning device 100, system design learning device 200, and system design learning device 610 may be implemented in the computer 700. In this case, the operation of each of the above-mentioned processing units is stored in the auxiliary storage device 730 in the form of a program. The CPU 710 reads the program from the auxiliary storage device 730, expands it in the main storage device 720, and executes the above-mentioned processing according to the program. The CPU 710 also secures memory areas in the main storage device 720 corresponding to each of the above-mentioned memory units according to the program.

When the system design learning device 100 is implemented in the computer 700, the operations of the control unit 190 and each of its units are stored in the form of a program in the auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-mentioned processing according to the program.
Furthermore, the CPU 710 reserves a memory area corresponding to the memory unit 180 in the main memory device 720 in accordance with the program.
The communication by the communication unit 110 is executed by the interface 740 having a communication function and performing communication under the control of the CPU 710 .
Display by the display unit 120 is performed by the interface 740 having a display screen and displaying various images under the control of the CPU 710. Reception of a user operation by the operation input unit 130 is performed by the interface 740 having an input device, receiving the user operation, and outputting a signal indicating the received user operation to the CPU 710.

When the system design learning device 200 is implemented in the computer 700, the operation of the control unit 290 and each of its units is stored in the form of a program in the auxiliary storage device 730. The CPU 710 reads the program from the auxiliary storage device 730, loads it into the main storage device 720, and executes the above-mentioned processing according to the program.
Furthermore, the CPU 710 reserves a memory area corresponding to the memory unit 180 in the main memory device 720 in accordance with the program.
The communication by the communication unit 110 is executed by the interface 740 having a communication function and performing communication under the control of the CPU 710 .
Display by the display unit 120 is performed by the interface 740 having a display screen and displaying various images under the control of the CPU 710. Reception of a user operation by the operation input unit 130 is performed by the interface 740 having an input device, receiving the user operation, and outputting a signal indicating the received user operation to the CPU 710.

When the system design learning device 610 is implemented in the computer 700, the operations of the conversion rule application unit 611, the design evaluation unit 612, the rule application evaluation unit 613, and the learning unit 614 are stored in the auxiliary storage device 730 in the form of a program. The CPU 710 reads the program from the auxiliary storage device 730, expands it in the main storage device 720, and executes the above processing according to the program.

In addition, a program for realizing all or part of the functions of system design learning device 100, system design learning device 200, and system design learning device 610 may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read into a computer system and executed to process each part. The "computer system" here includes hardware such as an OS (operating system) and peripheral devices.
"Computer-readable recording medium" refers to portable media such as flexible disks, optical magnetic disks, ROMs (Read Only Memory), and CD-ROMs (Compact Disc Read Only Memory), as well as storage devices such as hard disks built into computer systems. The above-mentioned program may be one that realizes part of the above-mentioned functions, or may realize the above-mentioned functions in combination with a program already recorded in the computer system.

The above describes an embodiment of the present invention in detail with reference to the drawings, but the specific configuration is not limited to this embodiment, and design changes and the like that do not deviate from the gist of the present invention are also included.

100, 200, 610 System design learning device 110 Communication unit 120 Display unit 130 Operation input unit 180 Memory unit 190, 290 Control unit 191, 611 Conversion rule application unit 192, 612 Design evaluation unit 193, 613 Rule application evaluation unit 194 Learning data generation unit 195, 614 Learning unit 296 Instantiation part detection unit

Claims (11)

a conversion rule application means for repeatedly applying conversion rules to components of a system to be designed, the components being designated as system requirements, to perform system design until a design result of the system design is obtained;
a design evaluation means for determining an evaluation value for the system design based on the design result;
a rule application evaluation means for determining an evaluation value for each transformation of an individual component in the system design based on the evaluation value for the system design;
a learning means for learning about selection of a part to which the conversion rule is applied based on learning data including an evaluation value related to the conversion of the part;
A system design learning device comprising: the rule application evaluation means determines an evaluation value regarding the conversion of the component for each component of the system requirement based on data obtained by integrating a plurality of system design histories for the same system requirement;
2. The system design learning device according to claim 1. The design result indicates either a success or a failure of the system design.
3. The system design learning device according to claim 1 or 2. Successful system design includes obtaining system requirements specified at a level that allows the system to be deployed;
4. The system design learning device according to claim 3. The system design failure includes determining that the system requirements cannot be specified at a level that allows the system to be deployed.
5. The system design learning device according to claim 3 or 4. the design evaluation means determines an evaluation value for the system design based on the obtained system evaluation index value when the design result indicates that the system design is successful;
The system design learning device according to any one of claims 1 to 5. The conversion rule application means further comprises an instantiation component detection means for generating instantiation component information indicating a component instantiated by each conversion rule usable for the system design, the conversion rule application means determining the conversion rule to be used for the system design based on the instantiation component information.
The system design learning device according to any one of claims 1 to 6. the learning means learns a component evaluation model that outputs an evaluation for each component indicated in a system requirement in response to the input of the system requirement;
the conversion rule application means selects the part to which the conversion rule is to be applied based on an evaluation of the part evaluation model for each part indicated in the system requirements, selects one conversion rule from among conversion rule candidates which are indicated in the instantiated part information as being applicable to the selected part, and applies the selected conversion rule to the selected part.
The system design learning device according to claim 7. the conversion rule application means selects, for each of the conversion rule candidates, one of the conversion rule candidates as a conversion rule to be applied to the selected component, based on an evaluation of the component evaluation model with respect to the system requirements after application of the conversion rule obtained by applying the conversion rule candidate to the system requirements.
The system design learning apparatus according to claim 8. The computer
performing a system design by repeatedly applying transformation rules to components of a system to be designed, for which system requirements are given, until a design result of the system design is obtained;
determining an evaluation value for the system design based on the design result;
determining estimates for transformations of individual components in the system design based on the estimates for the system design;
learning a selection of a part to which the conversion rule is applied based on learning data including an evaluation value related to the conversion of the part;
A method for learning systems design, including: On the computer,
performing a system design by repeatedly applying transformation rules to components of a system to be designed, for which system requirements are given, until a design result of the system design is obtained;
determining an evaluation value for the system design based on the design result;
determining estimates for transformations of individual components in the system design based on the estimates for the system design;
learning a selection of a part to which the conversion rule is applied based on learning data including an evaluation value related to the conversion of the part;
A program for executing.

Images