Design support system and method

Abstract

To enable the determination of the feasibility of requests of a person concerned such as a designer and a customer of a product with high accuracy.SOLUTION: A design support system for supporting design of a product being a design object made up of components being one or more components includes: a storage device 20 for storing component block information D003 on components including component attributes showing attributes of the components, and function block information D002 showing performance to be performed by the product; a request conversion unit 101 for converting a request specification showing a requests to the product by persons concerned of the product into first product performance; a performance estimation unit 102 for estimating second product performance showing the performance of the product on the basis of the component attributes of the components constituting the product; and a request determination unit 103 for comparing the first product performance with the second product performance to determine feasibility showing that the request specification can be achieved by the product.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to design support for design objects such as products, devices, software, and systems, and in particular to a technique for determining the feasibility of design requirements specifications. [Background technology]

[0002] In designing design objects such as products and systems (hereinafter referred to as products), it is common to modify existing design proposals to create new design proposals, as in the so-called "reused design." When making design changes, problems may arise due to the design changes affecting existing functions, which may lead to rework and increased design man-hours. Therefore, in design work, it is important to identify the scope of impact of the design changes and determine the feasibility of the required specifications after the changes. Furthermore, it is desirable to accumulate knowledge by creating a database of changes, reasons for changes, scope of impact, etc., regarding past design changes, in order to prevent design errors and rework in similar products. In addition, the product in this specification is composed of components (hereinafter referred to as components) such as parts, assemblies, members, units, modules, etc., and includes products, systems, etc.

[0003] Regarding design, MBSE (Model-Based Systems Engineering) has been proposed as a methodology for efficiently analyzing, designing, and verifying products. MBSE aims to improve design efficiency and prevent errors by modeling the configuration and relationships of a product's part structure, required functions, design parameters, etc., and expressing them in graphs that are easy to understand visually. However, creating an MBSE model often requires a large amount of man-hours, so it is desirable to create MBSE models efficiently.

[0004] As techniques for solving the above problems, Patent Documents 1 and 2 have been proposed. Patent Document 1 describes a design support system that includes a node data storage means for storing node data for generating a functional model in which a group of function nodes that subdivide the functions to be performed by a device to be designed and a group of part nodes for realizing the functions are expressed with mutual relationships, a functional model generation means for generating a functional model by referring to the node data storage means, a node designation receiving means for receiving node designation from within the functional model, a node extraction means for extracting nodes having mutual relationships for the nodes whose designation has been received, and an extracted node presentation means for presenting the extracted nodes (see claim 1).

[0005] Patent Document 2 describes a specification decision support device that includes a design parameter input receiving unit configured to receive input of product design parameters, a feasibility determination unit configured to determine whether the design parameters are feasible, a system specification model generation unit configured to generate a system specification model by reflecting the design parameters in an acquired system metamodel of the product if the design parameters are feasible, and a document generation unit configured to generate a product specification based on the system specification model (see claim 1). [Prior art documents] [Patent documents]

[0006] [Patent Document 1] JP 2005-322211 A [Patent Document 2] JP 2023-83915 A Summary of the Invention [Problem to be solved by the invention]

[0007] The technology disclosed in Patent Document 1 makes it easy to grasp the verification target when making design changes by associating the function nodes and part nodes of the product. However, Patent Document 1 is qualitative in identifying the impact range of the design change based on the association, and is not able to quantitatively evaluate the impact of the design change. In addition, Patent Document 1 does not describe the requirement specification node of the product, so it does not take into account the association between functions and requirement specifications, and it is not possible to judge the feasibility of changes to requirement specification parameters that occur during design changes.

[0008] Furthermore, the technology disclosed in Patent Document 2 presents a technology that supports the determination of the feasibility of product design parameters. However, Patent Document 2 determines feasibility based on a simple rule of whether a design value exceeds a threshold, and does not take into account the effects of design parameters. Furthermore, Patent Document 2 does not incorporate the effects of design parameters on performance, nor the association with the product configuration. This makes it difficult for designers to grasp the scope of the effects of design changes, increasing the risk of design errors.

[0009] The present invention has been made in view of such problems, and an object of the present invention is to enable and realize more accurate determination of the feasibility of the requests of related parties such as designers and customers regarding a product. [Means for solving the problem]

[0010] In order to achieve the above object, in the present invention, a product performance estimated from part attributes is compared with a product performance converted based on a requirement specification indicating a requirement for a product, and the feasibility of the product performance is determined. The product performance includes, for example, a limit of the product performance estimated from a part node using a simulation or a physical law. A more specific aspect of the present invention is a design support system for supporting the design of a product, which is a design object composed of parts that are one or more components, comprising a storage device that stores part block information related to parts including part attributes indicating the attributes of the parts and function block information indicating the performance that the product should achieve, a requirement conversion unit that converts the requirement specification indicating the requirement for the product of the parties involved in the product into a first product performance of the product, a performance estimation unit that estimates a second product performance indicating the performance of the product based on the part attributes of the parts that constitute the product, a requirement determination unit that compares the first product performance with the second product performance and determines the feasibility indicating whether the requirement specification can be realized by the product, and an output unit that outputs the determination result of the requirement determination unit.

[0011] The present invention includes a design support device that constitutes a design support system, and the design support system may be constituted by a single design support device. The present invention also includes a design support method using the design support system or the design support device. Furthermore, the present invention also includes a program for causing the design support device to function as a computer and a storage medium that stores the program. Effect of the Invention

[0012] According to the present invention, the feasibility of requests for products, including design changes, can be determined with higher accuracy, thereby making design work more efficient. [Brief description of the drawings]

[0013] [Figure 1] 1 is a diagram illustrating an example of a design support system according to an embodiment of the present invention. [Diagram 2] 1 is a hardware configuration diagram of a design support device 10 according to an embodiment of the present invention. [Diagram 3] FIG. 11 is a diagram showing requested block information D001 used in one embodiment of the present invention. [Figure 4] FIG. 2 is a diagram showing functional block information D002 used in one embodiment of the present invention. [Diagram 5] FIG. 11 is a diagram showing part block information D003 used in one embodiment of the present invention. [Figure 6] FIG. 13 is a diagram showing function-part relationship information D004 used in one embodiment of the present invention. [Figure 7] FIG. 13 is a diagram showing requirement-function relationship information D005 used in one embodiment of the present invention. [Figure 8] FIG. 2 is a diagram for explaining a processing flow in one embodiment of the present invention. [Figure 9] FIG. 13 is a diagram showing the display content of a correspondence relationship in one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. Note that the drawings show specific examples according to the principles of the present invention, but these are for understanding the present invention and are not to be used to interpret the present invention in a limiting manner.

[0015] In this embodiment, support is provided for the design of a product. At this time, the feasibility of the required specifications, which indicate requests from users including design changes for a product whose design has progressed to a certain extent (including once the design has been completed), is judged. The configuration for achieving this is described below.

[0016] FIG. 1 is a diagram showing an example of a design support system in this embodiment. The design support system of this embodiment has at least a design support device 10, a storage device 20, and a terminal device 30, which are realized by a computer. These devices are connected to each other via a network 60. In this embodiment, the design device 40 and the storage device 50 that stores design information used therein are also connected via the network 60, but these may be omitted, or the design support device 10 and the storage device 20 may each have the function. Here, the design support system of this embodiment uses an intranet 60-1 within an organization such as a company and the Internet 60-2, which is a wide area network, as networks. As a result, the judgment result can be confirmed by a terminal device 30-1 within the organization and terminal devices 30-2 and 30-3 outside the organization connected by the intranet 60-1. In this way, the design support device 10 can be realized by a so-called cloud system (server). However, this is an example of the configuration, and the configuration may be within the organization, or the design support device 10 may be configured as a so-called standalone, or at least a part of the function may be provided in each terminal device 30. Each device will be described below.

[0017] First, the design support device 10 executes the main processing of this embodiment and judges the feasibility of requests for product functions from designers and customers. To this end, the design support device 10 has a request conversion unit 101, a performance estimation unit 102, a request judgment unit 103, and an interface unit 104. First, the request conversion unit 101 converts the request specifications for the product into a first product performance of the product. The performance estimation unit 102 estimates a second product performance indicating the performance of the product by using part attributes of parts constituting the product related to the request.

[0018] The request determination unit 103 compares the estimated first product performance and the second product performance to determine the feasibility of the required specifications. Note that the feasibility in this embodiment means whether it can be implemented in the product, and includes whether the product can exhibit the performance required after the change, and physical possibility. The interface unit 104 connects to other devices and exchanges instructions and information. For example, it accepts request instructions from the terminal device 30, and reads information from the storage device 20 described later. The interface unit 104 outputs the determination result in the request determination unit 103 to other devices. Furthermore, the interface unit 104 may be realized as an input unit that accepts request instructions from a user, and an output unit that outputs the determination result and information related to the design. The output unit includes a display unit that displays the determination result, etc. Note that the user in this embodiment is mainly assumed to be a designer, but may also be an administrator or a customer.

[0019] Here, the design support device 10 can be realized as a computer as described above. The hardware configuration of the computer, which is an example of this implementation, will be described below with reference to Fig. 2. Fig. 2 is a hardware configuration diagram of the design support device 10 in this embodiment. In Fig. 2, the design support device 10 has a processing device 11, a communication device 12, a memory 13, and a sub-storage device 14, which are connected to each other via a communication path.

[0020] First, the processing device 11 can be realized by a processor such as a CPU, and executes calculations according to a design support program 15 stored in a sub-storage device 14 described later. The communication device 12 corresponds to the interface unit 104 in FIG. 1, and connects to an intranet 60-1 or the like to communicate with other devices such as the terminal device 30.

[0021] The memory 13 and the secondary storage device 14 also store a design support program 15. That is, the memory 13 expands the design support program 15 stored in the secondary storage device 14 and the information stored in the storage device 20. The secondary storage device 14 can be realized by a so-called storage. The secondary storage device 14 may also store at least a part of the information stored in the storage device 20. In this case, a part of the information in the storage device 20 or the storage device 20 itself may be omitted. The secondary storage device 14 can also be realized by various storage media such as an external HDD (Hard Disk Drive), SSD (Solid State Drive), or memory card.

[0022] Here, the design support program 15 has, for each function, a requirement conversion module 16, a performance estimation module 17, and a requirement determination module 18. Each of these modules may be realized as an individual program or a partial combination. Furthermore, the design support program 15 may be realized as a function of a design program such as a CAD program.

[0023] Here, the configuration shown in FIG. 1 which performs the same functions as each module is as follows. Requirement conversion module 16: Requirement conversion unit 101 Performance Estimation Module 17: Performance Estimation Unit 102 Request determination module 18: Request determination unit 103 Therefore, the processing device 11 executes the processes of the requirement conversion unit 101, the performance estimation unit 102, and the requirement determination unit 103 according to the design support program 15. This concludes the description of the implementation example of the hardware configuration of the design support device 10, and we will return to FIG. 1 to explain other devices. The storage device 20 is composed of, for example, one or more hard disks, and stores information and data related to the processing of the design support device 10 in electronic file format or database format such as a relational database. Therefore, the storage device 20 can be realized by a database system. The storage device 20 may be installed within the design support device 10, or may be a separate device from the design support device 10 and connected via an intranet 60-1 as shown in FIG. 1.

[0024] Here, there will be described various types of information stored in the storage device 20. The storage device 20 stores requirement block information D001, function block information D002, part block information D003, function-part relationship information D004, requirement-function relationship information D005, and a performance prediction model D006.

[0025] First, the requirement block information D001 is information describing the requirement specifications for a product. Here, the requirement specifications indicate the requests of the people involved with the product, and are, for example, based on the requests or demands of the customer and / or the specifications for the product formulated by the product designer. The requirement specifications can be classified according to the contents, such as "requirement", "sub-requirement", and "sub-sub-requirement", and described in a hierarchical structure. The requirement specifications may be the request itself. Furthermore, the requirement specifications can be hierarchically specified according to the request instructions from the user. In the example of the requirement block information D001 shown in FIG. 3, when "capable of recording" is accepted as the request instruction, No. 1 is searched for. That is, the requirement specifications are searched for as follows: "capable of recording", sub-requirements: "recording speed>30fps", "capable of recording continuously for 24 hours", and "capable of recording even in bad weather". Then, the sub-requirements can be specified according to the selection from the searched user.

[0026] Furthermore, when "recording speed>30 fps" is received as a request instruction, No. 1 is searched for, and the request: "capable of recording" and sub-request: "recording speed>30 fps" are identified as the required specifications.

[0027] Each piece of information will be explained below. Fig. 3 is a diagram showing the request block information D001 used in this embodiment. In this embodiment, a surveillance camera system is used as an example of a product. For this reason, as shown in Fig. 3, for example, in response to a request for "capability of recording", sub-requests for "recording speed of 30 fps (frames per second) or more", "capability of recording continuously for 24 hours", and "capability of recording even in bad weather" are described.

[0028] In the example shown in Figure 3, requirements and subrequirements are described using a table format, but other formats such as a tree structure may be used to describe the requirements hierarchy. When describing the requirements hierarchy using a tree structure, each requirement may be called a "requirement node."

[0029] Next, FIG. 4 is a diagram showing the function block information D002 used in this embodiment. The function block information D002 is information indicating the functions of a product defined by a function definition document or the like, and hierarchically expresses the functions to be performed by the target product to be designed, successively subdivided from the function that is the main purpose of the product. For the subdivided functions, "performance" is defined as an index for evaluating the quality of the function, and the conditions required to realize the function are defined as "constraints". For this reason, "performance" can also be expressed as an item corresponding to a requirement regarding the objective function. Also, "constraints" can also be expressed as a requirement regarding the constraints.

[0030] Figure 4 also uses a surveillance camera system as an example. For this reason, in Figure 4, "video recording function" and "power supply function" are described as sub-functions of the "video recording function." And, the "recording speed" and "resolution" of video recording are defined as the "performance" of the "video recording function." "Memory capacity," "power supply," "temperature," "humidity," and "price" are defined as the "constraints" of the "video recording function."

[0031] Also, while the example in Figure 4 uses a table format to describe the functions and subfunctions, other formats such as a tree structure may be used to describe the function hierarchy. When describing the function hierarchy in a tree structure, individual functions may be called "function nodes."

[0032] 5 is a diagram showing part block information D003 used in this embodiment. The part block information D003 is information about parts that make up a product, and hierarchically expresses the classification of parts or part units that make up the target product to be designed. Each item that makes up the part block information D003 can be acquired, for example, from CAD (Computer-Aided Design) data or BOM (Bill Of Materials) data, which are examples of design information stored in the storage device 50.

[0033] Figure 5 also uses a surveillance camera system as an example. In Figure 5, for example, the major part category "power unit" contains the minor parts categories "power supply" and "cable." Attributes and the like are defined for each minor part category. Furthermore, above the "major part category," an item for "major equipment category" can be provided that indicates the equipment that is composed of these components.

[0034] Here, in Fig. 5, for the sake of simplicity, each part and device is shown simply by the part classification name and representative attributes. However, in actual parts, each part is classified in detail by part number, attributes, characteristics, etc. Specifically, each classification item in the part classification has attribute values ​​such as dimensions and weight, and information such as the corresponding part number, and the part number is further linked to information such as drawings, supplier information, and purchase cost.

[0035] In the example of Figure 5, the parts classification (hierarchy) is described using a table format, but the parts classification can also be described using other formats such as a tree structure. When describing the parts classification in a tree structure, each part may be called a "part node."

[0036] Next, FIG. 6 is a diagram showing function-part relationship information D004 used in this embodiment. The function-part relationship information D004 is information that associates subfunctions with parts for realizing the functions. As an example, for each subfunction in the function block information D002, a part required to realize the function is searched for from the part block information D003, and linked to the subfunction as a related part. FIG. 6 also uses a surveillance camera system as an example. And, to realize the "power supply function", which is a subfunction of the recording function, which is one of the functions, a part (or part unit) called a "power unit" is required. Therefore, the related part of the "power supply function" is the "power unit". Information on the child parts (subpart classification) linked to the "power unit" can be specified by referring to the part block information D003. As a result, the function-part relationship information D004 shown in FIG. 6 is configured.

[0037] Next, FIG. 7 is a diagram showing the request-function relationship information D005 used in this embodiment. The request-function relationship information D005 is information that associates sub-requests with functions related thereto. As an example, for each sub-request in the request block information D001, a product function required to realize this request or a function related to the request is searched for from the function block information D002, and linked to the sub-request. FIG. 7 also uses a surveillance camera system as an example. In FIG. 7, for the sub-request of "recording speed is 30 fps or more" of this surveillance camera system, the related sub-function is a "video recording function", and its higher-level function is a "recording function". In addition, by referring to the function block information D002, the performance and constraints of the function related to the request can also be specified.

[0038] Above, the requirement block information D001, the function block information D002, the part block information D003, the function-part relationship information D004, and the requirement-function relationship information D004 are all illustrated in the form of a table. However, at least a part of these can be realized as structured information, that is, a database. And, as a database, it is possible to describe it as an MBSE model. In this way, when described as an MBSE model, the correspondence between the requirement block information D001, the function block information D002, and the part block information D003 can be described. In particular, the correspondence between the "requirements," "functions," and "parts" that compose them can be described. As a result, it becomes possible to get an overview of the relationships of the entire product. The GUI for such an overview will be described later with reference to FIG. 9.

[0039] Next, the performance prediction model information D006 is various information used when predicting the performance of a product (or a part of a product), and includes models, data, calculation formulas, laws, and means. There are no particular limitations on these models, data, calculation formulas, laws, and means, and various information can be used. For example, physical laws related to the product, experimental results, past simulation models, past defect cases, etc. can be used.

[0040] Here, when a model for prediction is used as the performance prediction model information D006, the input can be constraint conditions such as attribute values ​​of parts constituting the product and conditions of use of the product. The output of the model for prediction is a performance value or a range of performance values ​​of the product (or a part of the product). For example, using this model, the result of a heat generation calculation that estimates the heat generation of a subunit from attributes such as dimensions and current values ​​of parts constituting the subunit of the product is output. Alternatively, an optical simulation model that estimates the maximum resolution of a camera from the type and performance of the lenses constituting the camera can be used as this model. Also, data such as product attributes, usage, external conditions such as outside temperature and air pressure, temperature rise generated by the product, and noise level at the time of the occurrence of a defect from past defect cases may be used as the performance prediction model information D006.

[0041] This concludes the explanation of the design support device 10 and the storage device 20, and other devices will now be explained with reference to Fig. 1. The terminal device 30 (terminal devices 30-1 to 30-3) is used by users for design. For this reason, the terminal device 30 receives design operations and the like, and outputs feasibility and design data in the design support device 10. To execute these functions, the terminal device 30 can be realized by a computer such as a PC or a tablet.

[0042] The terminal device 30-1 is connected to the design support device 10, the design device 40, and the like via the intranet 60-1. The terminal device 30-1 is used by related parties such as designers. Although there is only one terminal device 30-1 in FIG. 1, the number of terminal devices is not limited.

[0043] The terminal devices 30-2 and 30-3 are connected to the design support device 10, the design device 40, and the like via the Internet 60-2. The terminal devices 30-2 and 30-3 are used by related parties such as designers to perform design and the like from outside. The terminal devices 30-2 and 30-3 may also be used by customers of the products. In this case, the terminal devices 30-2 and 30-3 may be allowed to access only the design support device 10 and the storage device 20, and may be restricted from accessing the design device 40 and the storage device 50. In other words, the customer is not given the authority to design itself, but is allowed to input desired information such as request changes. The number of the terminal devices 30-2 and 30-3 is not limited to that shown in FIG. 1.

[0044] Moreover, the design device 40 is a computer having CAD software, and realizes the design of the product. The storage device 50 stores the design information of the product used in the design device 40, and can be realized as a database system. The storage device 50 may be provided in the design device 40. The design device 40 and the storage device 50 may be realized as a so-called cloud system constructed on the Internet 60-2. Moreover, the functions of the design device 40 and the storage device 50 may be provided in the design support device 10 or the storage device 20.

[0045] Intranet 60-1 is a network operated by a company (organization) that designs products. Internet 60-2 is an example of a wide area network. Note that intranet 60-1 and Internet 60-2 are merely examples, and do not preclude other forms such as one network.

[0046] This concludes the explanation of the information used in this embodiment, and the processing flow will be explained with reference to Fig. 8. Fig. 8 is a diagram for explaining the processing flow in this embodiment. In Fig. 8, the requirement conversion unit 101 refers to the requirement-function relationship information D004 for any of the requirement nodes (requirement specifications) included in the requirement block information D001, identifies the associated function node, and converts it into performance or constraint conditions of the associated function node. Here, the performance includes a performance requirement value (for example, a numerical value) indicating the required performance. These are also referred to as first product performance.

[0047] Here, the request node used to identify the function node corresponds to a request change, which is an example of a request instruction input via the terminal device 30. In this case, the interface unit 104 functioning as an input unit receives the request change from the terminal device 30.

[0048] A requirement change is a requirement specification that is newly added or changed to the previous requirement specification of the product being designed or the requirement specification of a product similar to the target product. In the case of a product being designed from scratch without previous requirement specifications or similar products, the requirement specification itself is considered a requirement change.

[0049] The requirement conversion unit 101 can automatically perform conversion based on the similarity between the content of the requirement specification and the performance and constraint conditions of the function. For example, the similarity between sentences can be calculated by vectorizing sentences using a natural language processing method such as Word2Vec and calculating the cosine similarity between the vectors. If the similarity between the requirement specification and the performance statement of the function is higher than the similarity between the requirement specification and the constraint condition statement of the function, the requirement is converted into the performance of the function. Conversely, if the similarity between the requirement specification and the performance statement of the function is lower than the similarity between the requirement specification and the constraint condition statement of the function, the requirement can be converted into the constraint condition of the function.

[0050] In addition, in FIG. 8, the performance estimation unit 102 obtains the components of the product to be designed and their attributes from the component block information D003, and estimates the product's performance or range of performance by referring to the performance prediction model information D006. These are also referred to as second product performance. Here, this performance includes a performance estimation value (e.g., a numerical value) that indicates the performance that can be exhibited by the components that constitute the product. For example, in the case of a lens that is a component of a surveillance camera system, the performance estimation unit 102 can process it as follows. By inputting attributes such as the number and dimensions of lenses and referring to the optical simulation results of the lens, it is possible to estimate the second product performance, in particular the resolution of the camera's recording as an estimated performance value. Here, the optical simulation of the lens is used as the performance prediction model information D006.

[0051] The details of these processes are explained below. In the example of Fig. 8, requirement 1 and requirement 2 are received as requirement specifications. These are requirement changes from the previous requirements, and both requirements are related to function 1. The requirement conversion unit 101 calculates the degree of similarity in text between requirement 1, requirement 2, and each item of the function block information D002, and calculates a performance requirement value based on this. The requirement conversion unit 101 also converts requirement 2 into one related to the constraint condition of performance 1. In this way, the requirement conversion unit 101 converts the requirement specifications into the first product performance.

[0052] Furthermore, the performance estimation unit 102 refers to function-part relationship information D005 to identify parts 1 and 2 as parts related to function 1 converted by the requirement conversion unit 101. Next, the performance estimation unit 102 refers to part block information D003 to identify the attributes of each of parts 1 and 2. Then, the performance estimation unit 102 refers to performance prediction model information D006 to estimate performance including performance estimated values ​​according to the attributes of part 1 and part 2, that is, the second product performance.

[0053] Here, requirement 2 converted into a constraint condition by requirement conversion unit 101 is used as a constraint condition of performance prediction model information D006 by performance estimation unit 102, and the result is reflected in the estimation of the performance of function 1 (second product performance). For this reason, requirement conversion unit 101 registers the converted constraint condition in storage device 20 as performance prediction model information D006.

[0054] 8 compares the performance estimated values ​​estimated by the performance estimation unit 102 with the performance requirement values ​​converted by the requirement conversion unit 101 to determine the feasibility of the requirement change. If all of the performance requirement values ​​fall within the range of the performance estimation values, the requirement determination unit 103 determines that the requirement change is feasible. Conversely, if at least a part of the performance requirement values ​​is outside the range of the performance estimation values, the requirement determination unit 103 determines that the requirement change is not feasible. For example, if the performance requirement value is "recording speed of 60 fps or more" and the performance estimated value of the recording function is "recording speed of 40 fps or more and 80 fps or less," the performance estimated value does not achieve all of the performance requirement values, and the requirement determination unit 103 determines that the requirement change is "not feasible."

[0055] Then, the interface unit 104 outputs the feasibility of the request change determined by the request determination unit 103. This feasibility can be expressed in the form of text data, a table, an image, or the like. This interface unit 104 can be realized by the communication device 12 in FIG. 2 or the display device of the terminal device 30. In this case, the feasibility transmitted from the communication device 12 is transmitted to the terminal device 30 and displayed on the display device. As a result, the feasibility can be presented to the user. Alternatively, the communication device 12 may notify the storage device 20 of the feasibility and store it in the storage device 20 as a file. In this case, the feasibility can be shared by each terminal device 30 by accessing the storage device 20.

[0056] Furthermore, the interface unit 104 may output the correspondence between the above-mentioned required block information D001, functional block information D002, and component block information D003. This association can also be displayed on the terminal device 30, etc., in the same way as the feasibility.

[0057] Here, the display (GUI) of the correspondence in this embodiment will be described. This display is executed by any of the terminal devices 30 or a display device provided in the design support device 10. FIG. 9 is a diagram showing the display contents of the correspondence in this embodiment. FIG. 9 shows how requirements, functions, and structures (parts) are associated with each other. Specifically, requirement 1, which is input as a requirement change, is associated with function 1 and part 2.2. Similarly, requirement 2 is associated with function 3 and assembly 2. As a result, the user can intuitively grasp the relationship between requirements (specifications), functions, and parts. At this time, it is possible to display the requirements that are the input target of the user in a manner that distinguishes them from others. For example, as shown in FIG. 9, a frame is added to the requirement. As a result, the user can grasp the input target.

[0058] Furthermore, by displaying feasibility on a display device or the like, which is an example of the interface unit 104, the user can consider factors for determining feasibility and how to deal with it. For example, if feasibility is negative, the requirements, functions, and structures that correspond to each other can be candidates for the contents of changes. In order to perform such a display, it is desirable to configure each piece of information using an MBSE model. Including this case, the requirement block information D001, the function block information D002, and the part block information D003 are associated with each other.

[0059] As described above, according to one embodiment of the present invention, it is possible to create an MBSE model including design changes and the reasons for the changes, and by presenting the model to the user in a visually easy-to-understand format, it is possible to expect various effects such as improved design efficiency, prevention of design errors, and shortening of the design process time. It goes without saying that the present invention is not limited to the above embodiment. For example, the present invention can be applied to products other than surveillance camera systems. [Explanation of symbols]

[0060] 10 Design support device, 101 Requirement conversion unit, 102 Performance estimation unit, 103 Requirement judgment unit, 104 Interface unit, 20 Storage device, D001 Requirement block information, D002 Function block information, D003 Part block information, D004 Function-part relationship information, D005 Requirement-function relationship information, D006 Performance prediction model information, 20 Storage device, 30 Terminal device, 40 Design device, 50 Storage device, 60 Network

Claims

1. A design support system for supporting the design of a product that is a design object composed of one or more components, a storage device that stores part block information relating to the part including part attributes that indicate attributes of the part, and function block information that indicates performance that the product should achieve; a requirement conversion unit that converts requirement specifications indicating requirements for the product from parties involved in the product into a first product performance of the product; a performance estimation unit that estimates a second product performance indicating a performance of the product based on a part attribute of a part that constitutes the product; a requirement determination unit that compares the first product performance with the second product performance and determines feasibility indicating whether the requirement specification can be realized by the product; The design support system further comprises an output unit that outputs a result of the determination by the request determination unit.

2. 2. The design support system according to claim 1, The storage device is a design support system that stores the function block information in which the performance is hierarchically expressed and the part block information in which the parts are hierarchically expressed.

3. 2. The design support system according to claim 1, the storage device stores performance prediction model information used in predicting the performance of the product; The performance estimation unit further uses the performance prediction model information to predict the performance.

4. 2. The design support system according to claim 1, the requirement conversion unit identifies the first product performance including a performance requirement value calculated based on a sentence similarity between the requirement specification and the functional block information; the performance estimation unit estimates the second product performance including a performance estimation value indicating a performance that a part having the part attribute can exhibit; The requirement determination unit is a design support system that determines the feasibility based on a result of comparing the performance requirement value with the performance estimated value.

5. 5. The design support system according to claim 4, The requirement determination unit determines that a requirement change is feasible when all of the performance requirement values ​​are within the range of the performance estimate values.

6. 2. The design support system according to claim 1, The requirement conversion unit converts the requirement specifications into constraints on functions and performance; The performance estimation unit is a design support system that estimates the second product performance using the constraint conditions.

7. A design support method using a design support system for supporting the design of a product that is a design object composed of one or more components, comprising: a storage device stores part block information relating to the part, the part block information including part attributes indicating attributes of the part, and function block information indicating performance that the product should achieve; A requirement conversion unit converts requirement specifications indicating requirements for the product from stakeholders of the product into a first product performance of the product; a performance estimation unit estimates a second product performance indicating a performance of the product based on part attributes of parts constituting the product; a requirement determination unit that compares the first product performance and the second product performance and determines feasibility indicating whether the requirement specifications can be realized by the product; The design support method further comprises: outputting a determination result of the request determination section by an output section.

8. The design support method according to claim 7, The storage device stores the function block information in which the performance is expressed hierarchically and the part block information in which the parts are expressed hierarchically.

9. The design support method according to claim 7, the storage device stores performance prediction model information used in predicting the performance of the product; The design support method further comprises: predicting the performance by the performance estimation unit using the performance prediction model information.

10. The design support method according to claim 7, The requirement conversion unit identifies the first product performance including a performance requirement value calculated based on a sentence similarity between the requirement specification and the functional block information; The performance estimation unit estimates the second product performance including a performance estimation value indicating a performance that a part having the part attribute can exhibit; The design support method further comprises: determining the feasibility based on a result of a comparison between the performance requirement value and the performance estimated value by the requirement determination unit.

11. The design support method according to claim 10, The design support method further comprises determining, by the requirement determination unit, that a requirement change is feasible if all of the performance requirement values ​​are within the range of the performance estimate values.

12. The design support method according to claim 7, The requirement conversion unit converts the requirement specifications into constraints on functions and performance; The design support method further comprises estimating a second product performance using the constraint conditions by the performance estimation unit.

Images