LEARNING REQUIREMENT GENERATION DEVICE, LEARNING REQUIREMENT GENERATION METHOD, AND PROGRAM

Abstract

To reduce a workload on an engineer involved in generation of a learning factor.SOLUTION: A learning factor generating device (100) according to the present disclosure includes: a storing unit (101) that accumulates a system factor group; a factor obtaining unit (102) which obtains the system factor group from the storing unit (101), and adds the obtained system factor group into an obtained factor group; and a learning factor generating unit (103) that generates a learning factor by adding or replacing a structural element to each obtainment factor that forms the obtained factor group.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present disclosure relates to an automation technology for automating evaluation of products constituting an Information Communication Technology (ICT) system. In particular, the present disclosure relates to a technology for generating learning requirements for a machine to learn design knowledge related to the design of an ICT system. [Background technology]

[0002] The processes required for building an ICT system include the design process, in which a specific system configuration is designed to meet the system requirements required for the ICT system.

[0003] Patent Document 1 describes a technology for automatically generating a system configuration from system requirements, with the aim of automating the basic design process and the detailed design process. In this technology, a storage unit stores concretization rules that define a method for concretizing abstract configuration information (system requirements), which is information indicating the configuration of a system including undetermined parts, by determining the above-mentioned undetermined parts of the abstract configuration information. Then, the abstract configuration information included in the system configuration requirements expressed in a graph format is concretized using the concretization rules stored in the storage unit. In this way, information indicating the configuration of a system that does not include undetermined parts (system configuration) is generated based on the system configuration requirements.

[0004] Non-Patent Document 1 describes an automatic design technology for ICT systems using machine learning (learning-type automatic system design technology) inspired by Patent Document 1. In this technology, when generating a specific system configuration from system requirements using the technology of Patent Document 1, a reward value is given to each of the generated system configuration and the instantiation rules applied in the generation process, and the reward values ​​for the system configuration and the instantiation rules are learned by AI (Artificial Intelligence). This allows the AI ​​to pseudo-acquire knowledge (design knowledge) related to system design by engineers. In addition, by learning system configurations and instantiation rules for a wide variety of system requirements and reward values ​​for these system configurations and instantiation rules, it is possible to speed up and increase the reliability of the design of the system configuration. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2019 / 216082 [Non-patent literature]

[0006] [Non-Patent Document 1] Takayuki Kuroda, Takuya Kuwahara, Takashi Maruyama, Yutaka Yakuwa, Kazuki Tanabe, Tatsuya Fukuda, Kozo Satoda, Takao Osaki, "Acquisition of knowledge for ICT system design using machine learning", IEICE Transactions on Electronics, Information and Communication Engineers, Vol. J104-B, No. 3, pp. 140-151, March 2021 Summary of the Invention [Problem to be solved by the invention]

[0007] However, just as there is a general problem that a large amount of data for learning is required when using AI, in the learning-type system automatic design technology according to Non-Patent Document 1, in order for AI to acquire sufficient design knowledge, it is preferable to prepare a large amount of system requirements for learning (learning requirements). Therefore, there is a concern that the labor burden on engineers who generate such a large amount of learning requirements prior to learning will become large, which may become a problem.

[0008] The reason for this is that generating requirements for learning requires preparing a large amount of information related to projects for which system design has actually been carried out (real-life project data), manually interpreting the contents of the real-life project data, and then converting it into a requirements data format that can be used as input for the learning-type automatic system design technology.

[0009] Therefore, the object of the present disclosure is to provide a training requirements generation device, a training requirements generation method, and a program that can solve the above-mentioned problems and reduce the burden on engineers involved in generating training requirements. [Means for solving the problem]

[0010] An apparatus for generating training requirements according to one aspect includes: A storage unit that accumulates a group of system requirements; a requirements acquisition unit that acquires a group of system requirements from the storage unit and adds the acquired group of system requirements to an acquired group of requirements; a training requirement generation unit that generates training requirements by adding or replacing components to each of the acquisition requirements constituting the acquisition requirement group; Includes.

[0011] A method for generating training requirements according to one aspect includes the steps of: A training requirement generation method performed by a training requirement generation device, comprising: storing the set of system requirements in a storage unit; A step of acquiring a group of system requirements from the storage unit and adding the acquired group of system requirements to an acquired group of requirements; A step of generating training requirements by adding or replacing components to each of the acquisition requirements constituting the acquisition requirements group; Includes.

[0012] A program according to one aspect comprises: On the computer, storing the system requirements in a storage unit; A step of acquiring a group of system requirements from the storage unit and adding the acquired group of system requirements to an acquired group of requirements; A step of generating training requirements by adding or replacing components to each of the acquisition requirements constituting the acquisition requirements group; Execute the command. Effect of the Invention

[0013] According to the above-mentioned aspects, it is possible to provide a training requirements generation device, a training requirements generation method, and a program that can reduce the burden on engineers involved in generating training requirements. [Brief description of the drawings]

[0014] [Figure 1] 1 is a block diagram showing an example of the configuration of a training requirement generating device according to a first embodiment. [Diagram 2] FIG. 11 is an explanatory diagram showing an example of description of component data. [Diagram 3] FIG. 11 is an explanatory diagram illustrating an example of a description of a system requirement. [Figure 4] FIG. 2 is an explanatory diagram illustrating an example of a visual representation of system requirements. [Diagram 5] FIG. 11 is an explanatory diagram showing an example of description of relationship data. [Figure 6] FIG. 2 is an explanatory diagram showing an example of a description of a system configuration. [Figure 7] FIG. 2 is an explanatory diagram illustrating an example of a visual representation of a system configuration. [Figure 8] 10 is an explanatory diagram showing an example of a component addition process in the training requirement generation unit in the first embodiment; FIG. [Figure 9]10 is an explanatory diagram showing an example of a replacement process of components in the training requirement generating unit in the first embodiment; FIG. [Figure 10] 4 is a flowchart showing an example of an overall operational flow of the training requirement generation device in the first embodiment. [Figure 11] FIG. 11 is a block diagram showing a configuration example of a training requirement generating device according to a second embodiment. [Figure 12] FIG. 11 is an explanatory diagram showing an example of a similar requirement acquisition process in a similar requirement acquisition unit according to the second embodiment; [Figure 13] 13 is a flowchart showing an example of an overall operational flow of the training requirement generating device according to the second embodiment. [Figure 14] 13 is a flowchart showing an example of an overall operational flow of the training requirement generating device according to the second embodiment. [Figure 15] FIG. 11 is a block diagram showing a configuration example of an automatic design system according to a third embodiment. [Figure 16] FIG. 11 is an explanatory diagram showing an example of an instantiation rule used in the learning system automatic design device according to the third embodiment. [Figure 17] FIG. 11 is an explanatory diagram showing an example of a design process of a system configuration in a learning system automatic design device according to the third embodiment; [Figure 18] 13 is a flowchart showing an example of an overall operation flow of the automatic design system according to the third embodiment. [Figure 19] FIG. 13 is a block diagram showing an example of the configuration of a training requirement generating device according to a fourth embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Hereinafter, an embodiment of the present disclosure will be described with reference to the drawings. Note that the following description and drawings are omitted and simplified as appropriate for clarity of explanation. In addition, in each of the following drawings, the same elements are given the same reference numerals, and duplicate explanations are omitted as necessary.

[0016] <Embodiment 1> <Configuration of First Embodiment> Fig. 1 shows an example of the configuration of a training requirement generating device 100 according to the present embodiment 1. As shown in Fig. 1, the training requirement generating device 100 according to the present embodiment 1 includes a storage unit 101, a requirement acquiring unit 102, and a training requirement generating unit 103. The training requirement generating device 100 receives an input of component data 200 and outputs a training requirement group 300.

[0017] The component data 200 describes the definition of the types of components that make up an ICT system, such as an application, an OS (Operation System), and a server. FIG. 2 describes, as an example of component data 200, the definition of an “app-face” type component that represents a face recognition application. As shown in FIG. 2, the definition of the component data 200 may include type information regarding the type of the component, attribute value information regarding attribute values ​​of configuration information such as application and OS setting information, and information regarding other components that can be connected to the component through relationships.

[0018] In the example of FIG. 2, in the "category" that indicates the type information of the component, the value "App" is described, which indicates that the component is a type of application. In addition, in the "properties" which represents the attribute value information of the component, "fps", which represents the frame rate of the video that is input to the face recognition application, and "resolution", which represents the resolution of that video, are described as attribute values.

[0019] As information on the connection based on the relationship with other components, a "reference" that indicates a connection request from this component to other components, which is necessary for this component to operate, and a "service" that indicates a connection capability that can be provided to other components that request a connection to this component are defined. In both "reference" and "service", a pair of the port name of the port used for the connection and the number of components that can be connected to that port is described. In the example of FIG. 2, the pair "OS:1" is described as the value of "reference". This indicates that a connection is requested from the port "OS" connected to the OS required for the operation of the face recognition application to one component according to the relationship using the port "OS" defined in the relationship data described later. Similarly, the pair "camera:inf" is described as the value of "service". This indicates that the port "camera" connected to the camera to receive camera images can accept connections from multiple components according to the relationship using the port "camera" defined in the relationship data described later, and there is no upper limit to the number of components that can be connected.

[0020] The storage unit 101 stores system requirements, component data 200, and relationship data.

[0021] The system requirements are input to a learning system automatic design device 310, which will be described later, and are abstract expressions of components and constraints required by the user for the system. Figure 3 describes the definition of system requirements using the facial recognition application "app-face" as an example of system requirements. As shown in FIG. 3, the definition of the system requirements may include information about components required for the system and information about the relationships between the components required for the system.

[0022] In the example of FIG. 3, "components" representing components required for the system describes "app1", a face recognition application that is an "app-face" type component, and "server1", a physical server that is a "server" type component. The definition of each component described in "components" includes "type", which represents the type name of the component, and "properties", which represents the attribute value of the component. The attribute value of the component "app1" describes "15" as the value of the above-mentioned "fps", and "FHD" as the value of the above-mentioned "resolution". The attribute value of the component "server1" describes "8" as the value of "cpuCore", which represents the number of cores of the CPU (Central Processing Unit) installed in the physical server, "16", which represents the value of "memCapacity", which represents the memory capacity installed in the physical server, and "300", which represents the value of "storageCapacity", which represents the storage capacity installed in the physical server, respectively.

[0023] On the other hand, the definition of the relationship between components represented in "relationships" includes a list of three pairs of the start and end points of the relationship using the component names defined in "components" and the type name of the relationship. In the example of Figure 3, the relationship [app1,server,hostedOn] indicates that the face recognition application "app1" is dependent on the physical server "server1" through the abstract relationship type "hostedOn" which indicates that the application runs on the server.

[0024] Figure 4 is a visual representation of the contents of the system requirements shown in Figure 3 using a graph structure. In a visual representation such as Figure 4, the components of the system are represented as nodes (vertices), and the relationships between the components are represented as edges (branches). For simplicity, the contents of the system requirements will be explained hereinafter in this specification using a visual representation similar to that of Figure 4. Note that the specific definition format of the system requirements is not limited to the examples shown in Figures 3 and 4.

[0025] The relationship data defines the types of relationships between the components of a system, and is used in the learning requirement generation device 100 and the learning system automatic design device 310 described later. The relationship data includes definitions of both abstract and concrete relationships. Furthermore, the definition of each relationship includes information on the types of the components of the system that can be connected by the relationship, in addition to information distinguishing between the abstractness and concreteness of the relationship.

[0026] An example of relationship data is described in Fig. 5. In the example of Fig. 5, specific relationship types "wire:OS" and "wire:Machine" and abstract relationship types "hostedOn" and "join" are defined.

[0027] The definition of each relationship includes "abstract," which is information that distinguishes between abstractness and concreteness of the relationship, and "connection," which is information about components that can be connected by the relationship. A value of "abstract" of "true" indicates an abstract relationship, and a value of "false" indicates a concrete relationship.

[0028] In a "connection", at least one pair of "src" representing the type of the component that is the start point of the connection and "dest" representing the type of the component that is the end point of the connection is defined when connecting components through a relationship. The type of component is represented by "category" in the component data 200 shown in FIG. 2. Furthermore, in a specific relationship "connection", "srcPort" representing the port name of the port used by the component that is the start point of the connection for the connection and "destPort" representing the port name of the port used by the component that is the end point of the connection for the connection are further defined.

[0029] In the example of Figure 5, the specific relationship type "wire:OS" represents the possibility of connecting two components, with the port "OS" of the component "reference" whose type is "App" as the starting point and the port "OS" of the component "service" whose type is "OS" as the end point.

[0030] On the other hand, since the abstract relationships are replaced with concrete relationships by the learning-based system automatic design device described later, the components are connected without specifying ports. Note that the specific definition format of the relationship data is not limited to the example shown in FIG.

[0031] A system configuration is a concrete representation of all of the components of a system and the relationships between the components. Figures 6 and 7 respectively show an example of a definition of a system configuration that satisfies the system requirements using the face recognition application "app-face" shown in Figures 3 and 4, and a visual representation thereof. As shown in Figure 6, the definition of the system configuration may be written in the same notation as the system requirements.

[0032] In the examples of Figs. 6 and 7, a new component "os1" of "ubuntu" type representing the Ubuntu Linux (registered trademark) OS is added to realize the system requirements shown in Figs. 3 and 4. In the attribute value of the component "os1", a value "20.04" is described in "version" representing the version of the Ubuntu Linux (registered trademark) OS. In addition, in order to realize the abstract relationship [app1, server1, hostedOn], the abstract relationship [app1, server1, hostedOn] is replaced with a concrete relationship [os1, server, wire: Machine] representing that the OS "os1" is installed on the physical server "server1", and a concrete relationship [app1, os1, wire: OS] representing that the application "app1" runs on the OS "os1". Note that the concrete definition format of the system configuration is not limited to the examples shown in Figs. 6 and 7.

[0033] The requirement acquisition unit 102 acquires all the system requirements stored in the storage unit 101, and adds the acquired system requirements to a group of acquired requirements. The training requirement generating unit 103 inputs the component data 200. The training requirement generating unit 103 also generates system requirements (training requirements) by adding or replacing components to each acquisition requirement constituting the acquisition requirement group acquired by the requirement acquiring unit 102. The training requirement generating unit 103 then accumulates the generated training requirements in the memory unit 101, adds them to the training requirement group 300, and outputs the training requirement group 300.

[0034] 8 and 9 show an example of a learning requirement generation process for an acquisition requirement, which is performed by the learning requirement generating unit 103. FIG. 8 shows an example in which the acquisition requirements include components of the same form as the components (input components) represented by the input component data 200, and the input components in the acquisition requirements can be connected to new components through concrete or abstract relationships. In this case, the learning requirement generating unit 103 generates learning requirements by adding the new components to the acquisition requirements and connecting the added new components to the input components through relationships.

[0035] In the example of FIG. 8, the acquisition requirement is assumed to be an acquisition requirement in which the components "app1" and "server1" are connected by the abstract relationship "hostedOn". Also, assume that the component "server1" is an input component. Also, assume that a connection can be added from "server1" to the component "cloud1" representing a cloud network by "join", which is an abstract relationship representing a connection of a server to a network, defined in the relationship data shown in FIG. 5. In this case, the training requirement generation unit 103 adds a new component "cloud1" to the acquisition requirement, and generates a training requirement by connecting the added component "cloud1" to the component "server1" by the relationship "join".

[0036] 9 shows an example in which there is no input component in the acquisition requirement and any component in the acquisition requirement can be replaced with the input component. In this case, the learning requirement generating unit 103 generates the learning requirement by replacing the component in the acquisition requirement with the input component. In this case, the method of determining whether or not the component can be replaced may be a method of using the type information (type) of the component included in the definition of the component in the acquisition requirement and the category information (category) of the component included in the definition of the type.

[0037] In the example of FIG. 9, the acquisition requirement is assumed to be an acquisition requirement in which a component "app-secure1" representing a security application and a component "vm" representing a virtual machine are connected by an abstract relationship "hostedOn", and "vm" and a component "cloud" representing a cloud network are connected by an abstract relationship "join". In addition, the component "app-secure1" in the acquisition requirement is assumed to be an "app-secure" type component, and the "app-secure" type component has a type of "App". In addition, the input component is assumed to be an "app-face1" of an "app-face" type. In this case, the training requirement generating unit 103 replaces the component "app-secure1" of the "app-secure" type and the type of "App" with the input component "app-face1" of the "app-face" type for the acquisition requirement, and generates the training requirement.

[0038] <Operation of the First Embodiment> Next, an example of the overall operation flow of the training requirement generation device 100 according to the first embodiment will be described with reference to the flowchart of FIG.

[0039] As shown in FIG. 10, first, the learning requirement generating unit 103 inputs the component data 200 (step S101). Next, the requirement acquisition unit 102 acquires all the system requirements stored in the storage unit 101, and adds the acquired system requirements to the acquired requirement group (step S102).

[0040] Next, the learning requirement generating unit 103 determines whether the group of acquisition requirements is empty (step S103), and if the group of acquisition requirements is not empty (NO in step S103), extracts one acquisition requirement from the group of acquisition requirements (step S104).

[0041] Next, the learning requirement generating unit 103 determines whether the acquisition requirement extracted in step S104 includes the component (input component) represented by the component data 200 input in step S101 (step S105). If the acquisition requirement includes the input component (YES in step S105), the process proceeds to step S106, and if not (NO in step S105), the process proceeds to step S108.

[0042] In step S106, the learning requirement generating unit 103 judges whether the input components in the acquisition requirements can be connected to the new components through concrete or abstract relationships. If the input components can be connected (YES in step S106), the learning requirement generating unit 103 adds the new components to the acquisition requirements and connects the added components to the input components in the acquisition requirements through relationships (step S107). This generates the learning requirements. On the other hand, if the input components cannot be connected (NO in step S106), the learning requirement generating unit 103 discards the acquisition requirements and returns to step S103.

[0043] In step S108, the training requirement generating unit 103 determines whether or not there is a component in the acquisition requirement that can be replaced with the input component. If replacement with the input component is possible (YES in step S108), the training requirement generating unit 103 replaces the corresponding component in the acquisition requirement with the input component (step S109). This generates the training requirement. On the other hand, if replacement with the input component is not possible (NO in step S108), the training requirement generating unit 103 discards the acquisition requirement and returns to step S103.

[0044] After executing step S107 or S109, the training requirement generating unit 103 accumulates the training requirements generated in step S107 or S109 in the storage unit 101 and adds them to the training requirement group 300 (step S110). Then, the process returns to step S103.

[0045] In step S103, if the acquired requirement group is empty (YES in step S103), the training requirement generating unit 103 outputs the training requirement group 300 (step S111), and ends the process.

[0046] <Advantages of the First Embodiment> As described above, in the training requirement generating device 100 according to the first embodiment, the training requirements are generated by performing a component addition process or a component replacement process on the system requirements stored in the storage unit 101 using the inputted component data 200. Therefore, the AI ​​of the learning system automatic design technology can automatically generate the training requirement group 300 required for engineers to acquire design knowledge. In addition, by inputting various component data 200 into the training requirement generating device 100 and repeatedly executing the training requirement generation process, an even larger number of training requirement groups 300 can be automatically generated.

[0047] This will significantly reduce the burden on engineers who manually interpret actual project data and create requirements data. It will also improve the accuracy and speed of automated learning system design technology, and further reduce the labor required for the design and construction processes of ICT systems.

[0048] <Embodiment 2> <Configuration of the Second Embodiment> Fig. 11 shows a configuration example of a training requirement generating device 100A according to the present embodiment 2. As shown in Fig. 11, the training requirement generating device 100A according to the present embodiment 2 includes a storage unit 101, a requirement acquiring unit 111, an extended requirement generating unit 112, a similar requirement acquiring unit 113, and a training requirement generating unit 114. In the present embodiment 2, the storage unit 101 is the same as that in the above-mentioned embodiment 1, and therefore a detailed description thereof will be omitted.

[0049] The requirement acquisition unit 111 inputs the component data 200. Furthermore, the requirement acquisition unit 111 refers to the system requirement group stored in the storage unit 101, acquires all system requirements including the component (input component) represented by the input component data 200, and adds the acquired system requirements to the acquired requirement group.

[0050] The extension requirement generation unit 112 performs the same operation as in the example of FIG. 8 in the above-mentioned first embodiment for each acquired requirement constituting the acquired requirement group acquired by the requirement acquisition unit 111. That is, the extension requirement generation unit 112 judges whether or not an input component in the acquired requirement can be connected to a new component by a concrete or abstract relationship. If the input component can be connected, the extension requirement generation unit 112 adds the new component to the acquired requirement and connects the added new component to the input component by a relationship to generate a system requirement (extension requirement). Furthermore, the extension requirement generation unit 112 accumulates the generated extension requirement in the storage unit 101 and adds it to the extension requirement group.

[0051] For each extended requirement that constitutes the extended requirement group generated by the extended requirement generation unit 112, the similar requirements acquisition unit 113 acquires from the memory unit 101 system requirements (similar requirements) that are similar to the corresponding extended requirement and do not include input components, and adds the acquired similar requirements to the similar requirements group.

[0052] FIG. 12 shows an example of a process of acquiring similar requirements performed by the similar requirements acquiring unit 113. In FIG. In the example of FIG. 12, the system requirement with the highest similarity (similar requirement) among the system requirements that do not include the input components and are stored in the storage unit 101 is added to the group of similar requirements for the extended requirements generated by the extended requirements generation unit 112. In the visual representation of each system requirement in FIG. 12, nodes represented by the same symbol are components with the same type, and edges with the same character string are relationships with the same type. The Dice coefficient, which is one of the indices that express the similarity of sets, is used to determine the similarity between system requirements. For two sets A and B, the Dice coefficient DSC(A,B) is expressed by the following Equation 1.

number

[0053] When two system requirements, system requirement 1 and system requirement 2, are stored in the storage unit 101 as system requirements that do not include an input component, the similar requirement acquisition unit 113 regards the system requirements as a set of nodes and edges and uses the above formula 1. Then, the similarity between the extended requirement and system requirement 1 is 0.25 (25%), and the similarity between the extended requirement and system requirement 2 is 0.75 (75%). Therefore, the similar requirement acquisition unit 113 selects and acquires system requirement 2 as a similar requirement. Note that a specific method for acquiring similar requirements is not limited to the example shown in FIG. 12.

[0054] The training requirement generating unit 114 performs the same operation as that shown in the example of FIG. 9 in the above-mentioned first embodiment for each similar requirement constituting the group of similar requirements acquired by the similar requirement acquiring unit 113. That is, the training requirement generating unit 114 judges whether or not any of the components in the similar requirements can be replaced with the input components. If replacement with the input components is possible, the training requirement generating unit 114 replaces the corresponding component in the similar requirement with the input component to generate a training requirement. Then, the training requirement generating unit 103 accumulates the generated training requirements in the storage unit 101 and adds them to the group of training requirements 300, and outputs the group of training requirements 300.

[0055] <Operation of the Second Embodiment> Next, an example of the overall operation flow of the training requirement generation device 100A according to the second embodiment will be described with reference to the flowcharts of Fig. 13 and Fig. 14. In Fig. 13 and Fig. 14, the same operations as those in Fig. 10 according to the first embodiment are denoted by the same reference numerals, and detailed description thereof will be omitted.

[0056] As shown in FIGS. 13 and 14, first, the requirement acquiring unit 111 inputs the component data 200 (step S101). Next, the requirements acquisition unit 111 acquires all system requirements stored in the memory unit 101 that include the components (input components) represented by the component data 200 input in step S101, and adds the acquired system requirements to the acquired requirements group (step S202).

[0057] Next, the extended requirement generating unit 112 determines whether the acquisition requirement group is empty (step S103), and if the acquisition requirement group is not empty (NO in step S103), extracts one acquisition requirement from the acquisition requirement group (step S104).

[0058] Next, the extension requirement generating unit 112 judges whether the input components in the acquired requirements extracted in step S104 can be connected to the new components by concrete or abstract relationships (step S106). If the input components can be connected (YES in step S106), the extension requirement generating unit 112 adds the new components to the acquired requirements and connects the added new components to the input components in the acquired requirements by relationships (step S107). The extension requirement generating unit 112 accumulates the system requirements (extension requirements) obtained in step S107 in the storage unit 101 and adds them to the extension requirement group (step S208). Then, the process returns to step S103. On the other hand, if the input components cannot be connected (NO in step S106), the extension requirement generating unit 112 discards the acquired requirements and returns to step S103.

[0059] In step S103, if the acquisition requirement group is empty (YES in step S103), the process proceeds to step S209. In step S209, the similar requirements acquisition unit 113 determines whether the extended requirements group is empty (step S209), and if the extended requirements group is not empty (NO in step S209), extracts one extended requirement from the extended requirements group (step S210).

[0060] Next, the similar requirements acquisition unit 113 acquires, from among the system requirements stored in the memory unit 101, a system requirement (similar requirement) that has the highest similarity to the extracted extended requirement and does not include the input component (step S211).

[0061] Next, the training requirement generating unit 114 judges whether or not there is a component that can be replaced with the input component in the similar requirements acquired in step S211 (step S212). If replacement with the input component is possible (YES in step S212), the training requirement generating unit 114 replaces the corresponding component in the similar requirements with the input component to generate system requirements (training requirements) (step S213). The training requirement generating unit 114 accumulates the training requirements generated in step S213 in the storage unit 101 and adds them to the training requirement group 300 (step S214). Then, the process returns to step S209. On the other hand, if replacement with the input component is not possible (NO in step S212), the training requirement generating unit 114 discards the similar requirements and returns to step S209.

[0062] In step S209, if the extended requirement group is empty (YES in step S209), the training requirement generating unit 103 outputs the training requirement group 300 (step S111), and ends the process.

[0063] <Advantages of the second embodiment> As described above, in the training requirement generating device 100A according to the second embodiment, a training requirement group 300 is generated by performing a replacement process on input components for system requirements stored in the storage unit 101 that do not include components (input components) represented by the component data 200. Therefore, a more diverse training requirement group 300 can be automatically generated at high speed for the input components. Furthermore, both the extended requirement group generated by the extended requirement generating unit 112 and the training requirement group generated by the training requirement generating unit 114 are stored in the storage unit 101. Therefore, a more diverse system requirement can be stored in the storage unit 101 at high speed. The other effects are the same as those of the first embodiment described above.

[0064] <Embodiment 3> <Configuration of the Third Embodiment> Fig. 15 shows a configuration example of an automatic design system according to the present embodiment 3. As shown in Fig. 15, the automatic design system according to the present embodiment 3 includes the learning requirement generation device 100 according to the above-mentioned embodiment 1 and a learning system automatic design device 310.

[0065] The learning-based system automatic design device 310 receives the training requirement group 300 generated by the training requirement generation device 100 and outputs a system configuration group 400.

[0066] As shown in Non-Patent Document 1, the automatic system design device 310 generates a large number of system configuration candidates in which all elements are concretized by sequentially applying concretization rules that specify a method of partially concretizing abstract elements to system requirements including abstract components and relationships. Furthermore, the automatic system design device 310 derives an evaluation value for each generated system configuration candidate by using a graph neural network (GNN), which is a type of machine learning model using a graph structure, and gives a reward value to each concretization rule so that the reward value for the concretization rule applied in the generation process of the system configuration candidate with a large evaluation value is large. This makes it possible to have the AI ​​learn the design knowledge of engineers in a pseudo-like manner.

[0067] FIG. 16 shows an example of the instantiation rules used in the automatic learning system design device 310. In FIG. The instantiation rule shown in FIG. 16 shows a method for instantiating an abstract HTTP type edge that represents HTTP (Hyper Text Transfer Protocol) communication between applications. In this instantiation rule, the automatic learning system design device 310 connects the OS ports of the application type nodes "app1" and "app2", which are the two end points of the HTTP type edge, to the OS ports of the OS type nodes "os1" and "os2" with wire:OS type edges, respectively, and hosts each application type node on each OS type node. Then, the automatic learning system design device 310 connects the two OS type nodes "os1" and "os2" with an abstract TCP type edge that represents a TCP (Transmission Control Protocol) connection. Note that the method of defining the instantiation rule is not limited to the example shown in FIG. 15.

[0068] FIG. 17 shows an example of a design process of a system configuration in the learning-based system automatic design device 310. In FIG. As shown in FIG. 17, the system requirement (a) includes two abstract elements, (a1) and (a2). The concretization rules (X) and (Y) can be applied to (a1), and the concretization rule (Z) can be applied to (a2). Therefore, the automatic learning system design device 310 applies these concretization rules to (a1) and (a2) to generate three system configuration plans, (b), (c), and (d). Then, the automatic learning system design device 310 evaluates each generated system configuration plan using a GNN, and selects (d) with the highest evaluation value as the next concretization target. The only abstract element included in the system configuration plan (d) is (d1), and the concretization rules (X) and (Y) can be applied to (d1). Therefore, first, the automatic learning system design device 310 applies the concretization rule (X) to (d1), and as a result, a concrete system configuration plan (e) that does not include an abstract element is obtained. Therefore, the learning-based system automatic design device 310 completes the design and adds (e) to the system configuration group 400 as a system configuration.

[0069] <Operation of the Third Embodiment> Next, an example of the overall operation flow of the automatic design system according to the third embodiment will be described with reference to the flowchart of FIG.

[0070] 18, first, the training requirement generating device 100 inputs the component data 200 (step S301). Next, the training requirement generating device 100 generates a training requirement group 300 (step S302).

[0071] Next, the automatic learning system design device 310 inputs the learning requirement group 300 generated in step S302 (step S303). Next, for each learning requirement constituting the input learning requirement group 300, the automatic learning system design device 310 recursively applies the concretization rules to the abstract elements of the learning requirement and evaluates the system configuration plan after the application. As a result, the automatic learning system design device 310 generates a concrete system configuration corresponding to the learning requirement and adds it to the system configuration group 400 (step S304).

[0072] Thereafter, the learning system automatic design device 310 outputs the system configuration group 400 and ends the process (step S305).

[0073] <Advantages of the Third Embodiment> As described above, in the automatic design system according to the third embodiment, the learning system automatic design device 310 generates a specific system configuration corresponding to each learning requirement generated by the learning requirement generation device 100. Therefore, it becomes possible to automatically generate a specific system configuration corresponding to each learning requirement. The other effects are the same as those of the first embodiment described above.

[0074] In addition, the automatic design system according to the third embodiment may be configured to include the training requirement generation device 100A according to the second embodiment described above, instead of the training requirement generation device 100 according to the first embodiment described above.

[0075] <Fourth embodiment> 19 shows an example of the configuration of a training requirement generating device 100B according to the present embodiment 4. As shown in FIG. 19, the training requirement generating device 100B includes a processor 121 and a memory 122.

[0076] The processor 121 may be, for example, a microprocessor, a micro processing unit (MPU), or a central processing unit (CPU). The processor 121 may include multiple processors.

[0077] The memory 122 is configured by a combination of volatile memory and non-volatile memory. The memory 122 may include storage located away from the processor 121. In this case, the processor 121 may access the memory 122 via an I (Input) / O (Output) interface (not shown).

[0078] The training requirement generating device 100, 100A according to the above-mentioned first and second embodiments may have a hardware configuration shown in FIG. 19. A program is stored in the memory 122. This program includes a set of instructions (or software code) for making the computer perform one or more functions described in the above-mentioned embodiments when the program is loaded into the computer. The requirement acquiring unit 102, 111, the training requirement generating unit 103, 114, the extended requirement generating unit 112, and the similar requirement acquiring unit 113 in the training requirement generating device 100, 100A may be realized by the processor 121 reading and executing the program stored in the memory 122. Also, the storage unit 101 in the training requirement generating device 100, 100A may be realized by the memory 122.

[0079] The above-mentioned programs may also be stored on non-transitory computer-readable media or tangible storage media. By way of example and not limitation, computer-readable media or tangible storage media include random-access memory (RAM), read-only memory (ROM), flash memory, solid-state drive (SSD) or other memory technology, CD-ROM, digital versatile disc (DVD), Blu-ray® disk or other optical disk storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device. The programs may also be transmitted on a transitory computer-readable medium or communication medium. By way of example and not limitation, transitory computer-readable medium or communication medium includes electrical, optical, acoustic or other form of propagated signal.

[0080] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by a person skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure.

[0081] The above explanation makes clear the industrial applicability of the present disclosure, and the present disclosure can be applied to applications such as the design and construction of ICT systems and communication networks.

[0082] Although the present disclosure has been described above with reference to the embodiments, the present disclosure is not limited to the above-described embodiments. Various modifications that can be understood by a person skilled in the art can be made to the configuration and details of the present disclosure within the scope of the present disclosure. [Explanation of symbols]

[0083] 100, 100A, 100B Learning requirement generation device 101 Storage section 102,111 Requirements acquisition department 103,114 Learning requirement generation unit 112 Extended requirements generation unit 113 Similar requirements acquisition department 121 processors 122 Memory 200 Component Data 300 Learning Requirements 310 Automatic Design of Learning Systems 400 System Configuration Group

Claims

1. A storage unit that accumulates a group of system requirements; a requirements acquisition unit that acquires a group of system requirements from the storage unit and adds the acquired group of system requirements to an acquired group of requirements; a training requirement generation unit that generates training requirements by adding or replacing components to each of the acquisition requirements constituting the acquisition requirement group; Including, The learning requirement generation unit includes: inputting component data representing the input component; For each acquisition requirement constituting the acquisition requirement group, if the acquisition requirement includes an input component and the input component can be connected to a new component, the new component is added to the acquisition requirement and the added new component is connected to the input component to generate a training requirement; For each acquisition requirement constituting the acquisition requirement group, if the acquisition requirement does not include an input component and includes a component that can be replaced with the input component, the component included in the acquisition requirement is replaced with the input component to generate a training requirement. A learning requirements generator.

2. The learning requirement generation unit includes: The generated training requirements are stored in the storage unit and added to a group of training requirements; Output a set of training requirements. The training requirement generating device according to claim 1 .

3. The requirement acquisition unit, inputting component data representing the input component; Acquire a group of system requirements including the input configuration element from the storage unit, and add the acquired group of system requirements to an acquired group of requirements; The training requirement generation device comprises: an extension requirement generating unit that, for each acquisition requirement constituting the acquisition requirement group, generates an extension requirement by adding the new component to the acquisition requirement and connecting the added new component to the input component when the acquisition requirement includes an input component and the input component is connectable to a new component, and adds the generated extension requirement to the extension requirement group; a similar requirement acquisition unit that acquires, for each extension requirement constituting the extension requirement group, a system requirement that is similar to the extension requirement and does not include an input component from the storage unit, and adds the acquired system requirement to the similar requirement group; Further comprising: The learning requirement generation unit includes: For each similar requirement constituting the group of similar requirements, if the similar requirement contains a component that can be replaced with the input component, the component contained in the similar requirement is replaced with the input component to generate a training requirement. The training requirement generating device according to claim 1 .

4. The extension requirement generation unit Storing the generated extension requirements in the storage unit; The learning requirement generation unit includes: The generated training requirements are stored in the storage unit and added to a group of training requirements; Output a set of training requirements. The training requirement generating device according to claim 3 .

5. The similar requirements acquisition unit determining a similarity between each system requirement not including an input component and an extended requirement, the similarity being determined using a Dice coefficient; acquiring from the storage unit a system requirement having the highest similarity, and adding the acquired system requirement to a group of similar requirements; 5. The training requirement generating device according to claim 3.

6. A training requirement generation method performed by a training requirement generation device, comprising: storing the set of system requirements in a storage unit; A step of acquiring a group of system requirements from the storage unit and adding the acquired group of system requirements to an acquired group of requirements; A step of generating training requirements by adding or replacing components to each of the acquisition requirements constituting the acquisition requirements group; Including, In the step of generating training requirements, inputting component data representing the input component; For each acquisition requirement constituting the acquisition requirement group, if the acquisition requirement includes an input component and the input component can be connected to a new component, the new component is added to the acquisition requirement and the added new component is connected to the input component to generate a training requirement; For each acquisition requirement constituting the acquisition requirement group, if the acquisition requirement does not include an input component and includes a component that can be replaced with the input component, the component included in the acquisition requirement is replaced with the input component to generate a training requirement. A method for generating requirements for training.

7. On the computer, storing the system requirements in a storage unit; A step of acquiring a group of system requirements from the storage unit and adding the acquired group of system requirements to an acquired group of requirements; A step of generating training requirements by adding or replacing components to each of the acquisition requirements constituting the acquisition requirements group; Run the command, In the step of generating training requirements, inputting component data representing the input component; For each acquisition requirement constituting the acquisition requirement group, if the acquisition requirement includes an input component and the input component can be connected to a new component, the new component is added to the acquisition requirement and the added new component is connected to the input component to generate a training requirement; For each acquisition requirement constituting the acquisition requirement group, if the acquisition requirement does not include an input component and includes a component that can be replaced with the input component, the component included in the acquisition requirement is replaced with the input component to generate a training requirement. program.

Images