JP6368581B2 - Design support system, design support method, and design support program - Google Patents

Description

  The present invention relates to, for example, a design support system, a design support method, and a design support program that support design work executed by being divided into a plurality of projects.

  In product development projects that are executed in multiple projects (for example, teams divided between upper and lower design stages and departments), the upper level (outline) ) A lower level project (for example, a project for which detailed design is performed) may proceed with a lower level (detailed) level design based on the design level. Also, a method for abstracting system specification information configured in a hierarchical structure is known (see Patent Document 1 below).

JP 6-103049 A

  In the product development project as described above, the designer of the higher level project may want to confirm how the design at the higher level has been refined or changed by the design by the lower level project. In addition, the designer of the lower level project does not talk about the design contents from the lower level granularity and viewpoint in order to smoothly coordinate the design (design adjustment) with the designer of the higher level project. And you may want to talk from a perspective. This is because if it is impossible to talk about the upper level of granularity and viewpoint, it will be difficult to communicate to the designer of the higher level project about the parts that need to be changed, and it may take a long time for the arrangement.

  In the method described in Patent Document 1, detailed system specification information is abstracted, but is not abstracted in a form suitable for comparison between the design content of the upper project and the design content of the lower project. Therefore, it is desired to efficiently perform matching between projects by facilitating the comparison of design contents between projects in a design work executed by being divided into a plurality of projects.

  A design support system according to one aspect of the present invention is a design support system that supports a design of each project in a design that is configured by a computer system and is executed by being divided into a plurality of projects. The design support system is a design data acquisition unit that acquires first design data of a first project and second design data of one or more second projects different from the first project. The first and second design data includes a plurality of data sets including one or more item data indicating design items, and dependency data indicating dependency relationships between item data included in each of the plurality of data sets. A data acquisition unit, a summary target data set extraction unit that extracts a data set commonly included in the first design data and one or more second design data as a summary target data set, and one or more second design data And generating and outputting third design data that does not include a data set other than the summary target data set extracted by the summary target data set extraction unit. It includes a summary execution unit, a.

  A design support system according to an aspect of the present invention is a design support method executed by a design support system configured by a computer system and supporting the design of each project in a design executed by being divided into a plurality of projects. The design support method is a design data acquisition step of acquiring first design data of a first project and second design data of one or more second projects different from the first project, The first and second design data includes a plurality of data sets including one or more item data indicating design items, and dependency data indicating dependency relationships between item data included in each of the plurality of data sets. A data acquisition step, a summary target data set extraction step for extracting a data set commonly included in the first design data and one or more second design data as a summary target data set, and one or more second design data 3rd design which does not include data sets other than the summary target data set extracted in the summary target data set extraction step Including a summary execution step of generating and outputting an over data, the.

  A design support program according to an aspect of the present invention is a design support program that causes a computer system to function as a design support system that supports the design of each project in a design that is executed by being divided into a plurality of projects. The design support system is a design data acquisition unit that acquires first design data of a first project and second design data of one or more second projects different from the first project. The first and second design data includes a plurality of data sets including one or more item data indicating design items, and dependency data indicating dependency relationships between item data included in each of the plurality of data sets. A data acquisition unit, a summary target data set extraction unit that extracts a data set commonly included in the first design data and one or more second design data as a summary target data set, and one or more second design data And generating and outputting third design data that does not include a data set other than the summary target data set extracted by the summary target data set extraction unit. It includes a summary execution unit, a.

  In the above form, a data set common to the first design data of the first project and the second design data of the second project is extracted as a summary target data set. Then, based on the second design data, third design data that does not include a data set other than the summary target data set is generated. That is, it is possible to obtain third design data having the same data set configuration as the first design data and having a design granularity equivalent to the design granularity of the first design data. That is, the third design data suitable for comparison with the first design data can be obtained. As a result, for example, by comparing the first design data and the third design data, it becomes possible to easily grasp the difference between the design contents of the first project and the design contents of the second project. . Therefore, it is possible to efficiently perform the reconciliation between the first project and the second project.

  In the above design support system, when there is one second project, the summary execution unit is two item data included in the summary target data set for the second design data, and is not a summary target data set. One item which detects two item data connected through a plurality of dependency data associated with item data included in the data set of and indicates a dependency relationship between the two item data from the plurality of dependency data The third design data may be generated by generating dependency relationship data and deleting a data set other than the summary target data set. According to the design support system, it is possible to efficiently and appropriately generate the third design data having a data set configuration common to the first design data.

  In the design support system, the summary execution unit, when there are a plurality of second projects, outputs each of the second design data of each of the plurality of second projects based on a predetermined rule. A plurality of dependencies related to item data included in a data set other than the summary target data set, which are two item data included in the summary target data set, with respect to the fourth design data. Two item data linked through data is detected, one dependency data indicating a dependency relationship between the two item data is generated from the plurality of dependency data, and a data set other than the summary target data set is generated. The third design data may be generated by deleting.

  In the design support system, the summary execution unit may include two items included in the summary target data set for the second design data of each of the plurality of second projects when there are a plurality of second projects. Two items of data that are linked via a plurality of dependency data associated with item data included in a data set other than the summary target data set, and two items of data are detected from the plurality of dependency data By generating one dependency relationship data indicating the dependency relationship between the item data and deleting a data set other than the summary target data set, a plurality of fifth design data is generated, and the plurality of fifth design data is The third design data may be generated by converting into one third design data based on a predetermined rule.

  According to the above design support system, when there are a plurality of second projects, the third design data having a data set configuration common to the first design data and based on the design contents of the plurality of second projects is provided. , Efficiently and properly generated. As a result, for example, by comparing the first design data and the third design data, it is possible to easily grasp the difference between the design contents of the first project and the design contents of a plurality of second projects. It becomes. Therefore, it is possible to efficiently perform the matching between the first project and the plurality of second projects.

  In the design support system, the first design data and the third design data are obtained, and the first design data and the third design data are compared by comparing the first design data and the third design data. And a comparison unit that outputs comparison result data indicating differences between the item data and the dependency relationship data. According to the design support system, comparison result data indicating the difference between the design contents of the first project and the design contents of the second project is output. As a result, for example, the user of each project can easily grasp the difference in design contents between projects by referring to the comparison result data.

  The design support system may further include a reflection unit that updates the first design data to the same design data as the third design data based on the comparison result data output by the comparison unit. According to the design support system, the reflection unit can match the design content (first design data) of the first project with the design content of the second project. As a result, design matching between the first project and the second project is automated, and the efficiency of design work can be improved.

  In the design support system, the notification information indicating that the first design data is updated to the same design data as the third design data by the reflection unit is generated based on the design data of the first project. You may further provide the matching part which notifies with respect to all the projects which hold data. According to the above-described design support system, the matching unit has changed the design content of the first project to reflect the design content of the second project, that is, the design content of the first project is the second project. It is notified to all the projects that have the design data generated based on the design data of the first project that the design contents are consistent with those of the first project. As a result, the project side that has received the notification can smoothly execute the process of reflecting the latest design data of the first project in the design data of the own project.

  According to one aspect of the present invention, it is possible to efficiently perform matching between projects by facilitating comparison of design contents between projects in a design work executed by being divided into a plurality of projects. .

It is a figure which shows notionally the relationship between several projects. It is a block diagram which shows the function structure regarding the stepwise detailing of the design support system which concerns on one Embodiment. It is a figure which shows an example of design data. It is a figure which shows an example of requirement data. It is a figure which shows an example of element data. It is a figure which shows an example of dependency data. It is a figure which shows an example of the expression format of the design data shown in FIG. FIG. 4 is a diagram showing dependency relationship data between requirement data shown in FIG. 3 in a DSM format. It is a figure which shows the design data before reference edit execution of the dependency data by project PJ1. It is a figure which shows the design data after reference edit execution of the dependency data by project PJ1. It is a figure which shows the design data after reference edit execution of the element data by project PJ1. It is a figure which shows notionally an example of the reference relationship between the projects PJ0-PJ3. It is a figure which shows the flow of a reference data merge process. It is a figure which shows notionally an example of the reference relationship between the projects PJ0-PJ3. It is a figure which shows the reference relationship between 2 hierarchy projects. It is a figure which shows the design data added by normal edit in the project PJ0. FIG. 17 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 16 in a DMM format. It is a figure which shows the design data of project PJ0 after a change. FIG. 19 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 18 in a DMM format. It is a figure which shows the design data of project PJ1 after normal edit execution. FIG. 21 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 20 in a DMM format. FIG. 11 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 10 in a DMM format. FIG. 12 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 11 in a DMM format. It is a figure which shows the design data of project PJ0 after a change. FIG. 25 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 24 in a DMM format. It is a figure which shows the design data of project PJ1 after an update. FIG. 27 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 26 in a DMM format. It is a figure which shows the design data after the cancellation process of a reference edit cancellation part. FIG. 29 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 28 in a DMM format. It is a figure which shows the reference relationship between 3 hierarchy projects. It is a figure which shows the design data of the project PJ3 after reference data merge processing execution. FIG. 32 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 31 in a DMM format. It is a figure which shows the design data after edit in project PJ2. FIG. 34 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 33 in a DMM format. It is a figure which shows the design data of the project PJ3 after reference data merge processing execution. FIG. 36 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 35 in a DMM format. It is a figure which shows the design data after edit in project PJ3. FIG. 38 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 37 in a DMM format. It is a figure which shows the reference relationship between the projects in an Example. It is a figure which shows the design data designed by vehicle plan PJ. FIG. 41 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 40 in a DMM format. It is a figure which shows the design data before engine design. FIG. 43 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 42 in a DMM format. It is a figure which shows the design data after engine design. FIG. 45 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 44 in a DMM format. It is a figure which shows the design data before a fuel consumption design. FIG. 47 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 46 in a DMM format. It is a figure which shows the design data after a fuel consumption design. FIG. 49 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 48 in a DMM format. It is a figure which shows the design data before output design. FIG. 52 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 51 in a DMM format. It is a figure which shows the design data after output design. FIG. 53 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 52 in a DMM format. It is a figure which shows the design data before piston design. FIG. 55 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 54 in a DMM format. It is a figure which shows the design data after piston design. FIG. 57 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 56 in a DMM format. It is a figure which shows the design data before WP design. FIG. 59 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 58 in a DMM format. It is a figure which shows the design data after WP design. FIG. 61 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 60 in a DMM format. It is a flowchart which shows the operation | movement regarding the stepwise detailing of the design support system which concerns on one Embodiment. It is a block diagram which shows the function structure regarding the stepwise detailing of the design support program which concerns on one Embodiment. It is a block diagram which shows the function structure regarding the reference summary of the design support system which concerns on one Embodiment. It is a figure for demonstrating the summary of dependence. It is a figure for demonstrating a reference summary comparison. It is a figure which shows an example of comparison result data. It is a figure which shows an example of comparison result data. It is a flowchart which shows the operation | movement regarding the reference summary of the design support system which concerns on one Embodiment. It is a block diagram which shows the function structure regarding the reference summary of the design support program which concerns on one Embodiment.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the description of the drawings, the same or equivalent elements are denoted by the same reference numerals, and redundant description is omitted.

  The design support system according to the present embodiment is a system that supports the design of each project when the design work is performed by being divided into a plurality of projects. Specifically, the design support system provides functions of “stepwise refinement” and “reference summary”. “Stepwise refinement” is a function that allows a lower-level project to refer to and edit the design content of a higher-level project that performs high-level (summary) level design. According to the stepwise refinement, the lower level project can smoothly advance the design of its own project while referring to and editing the design content of the higher level project. The “reference summary” is a function for summarizing (summarizing) the design content of the lower project detailed by the stepwise refinement into the same granularity (for example, the overview level) as the design content of the upper project. According to the reference summary, it is possible to easily compare the design contents of the upper project and the design contents detailed in the lower project with the same granularity.

[Stepwise refinement]
First, the stepwise detailing function will be described with reference to FIGS. FIG. 1 is a diagram conceptually showing the relationship between a plurality of projects. A project is a team composed of one or more (usually multiple) personnel gathered to achieve the same goal. The project may be, for example, a team divided by upper and lower design stages, departments, persons in charge, roles, and the like. More specifically, the project may be a design team divided for each design element, such as an engine design project or a fuel consumption design project in the design of an automobile. As shown in FIG. 1, in this embodiment, it is assumed that, for example, a design related to vehicle product development is executed by being divided into a plurality of projects (projects PJ0 to PJ3 in the example of FIG. 1). For example, the upper layer project PJ0 is a project for designing an upper (summary) level. Projects PJ1 and PJ2 in the lower layer (intermediate layer) of project PJ0 are projects for designing at a lower (detail) level based on the design contents in project PJ0. A project PJ3 in a lower layer (lower layer) of the projects PJ1 and PJ2 is a project for performing a lower level design based on the design contents in the projects PJ0 to PJ2.

  In each project, for example, a technical model, a business model, a problem model, and the like are designed. In these models, design items and dependency relationships between the design items are defined. A technical model is a model that defines the dependency between requirements and elements for a product to be developed. That is, the technical model has requirements and elements as design items. The business model is a model that defines the dependency between tasks (work processes, etc.) and deliverables (for example, creation of design documents, data creation, etc.). In other words, the business model has tasks and deliverables as design items. The issue model is a model that defines the dependency between issues (worries, factors, etc.) and countermeasures (tasks (work process, etc.)). That is, the problem model has problems and countermeasures as design items. In the present embodiment, description will be given focusing on the design of the technical model. However, the design support system according to the present embodiment can be applied to any model design as long as it is a model that defines some design item and a dependency relationship between the design items, such as each model described above. Applicable.

  FIG. 2 is a block diagram showing a functional configuration related to stepwise refinement of the design support system 1 according to the present embodiment. The design support system 1 is a computer system that is provided for each project and supports the design of each project. In this embodiment, as an example, the design support system 1 includes an information processing server 10 and one or more information processing terminals 20. However, the design support system 1 is not limited to the above-described configuration, and may be configured as an integrated device having the functions of the information processing server 10 and the information processing terminal 20 described below, for example. A plurality of projects may be configured to share one design support system 1. Further, the information processing server 10 constituting the design support system 1 may not be provided for each project, and may be configured as one server device shared by a plurality of projects.

  The information processing terminal 20 of each project is, for example, a terminal for a user (designer) of the project to edit (add, update, delete, etc.) design data. The information processing terminal 20 is, for example, a personal computer, a dedicated computer terminal, or the like, and a communication for performing data communication with an auxiliary storage device such as a CPU (Central Processing Unit), a memory, an HDD (Hard Disk Drive), and other devices. It is configured with modules. The information processing terminal 20 includes an output device such as a display and an input device such as a mouse and a keyboard that accepts an input operation from a user.

  The information processing server 10 of each project is a server device capable of communicating with the information processing terminal 20 via a communication network such as a LAN (Local Area Network). Similar to the information processing terminal 20, the information processing server 10 includes an auxiliary storage device such as a CPU, a memory, and an HDD, and a communication module for performing data communication with other devices. The information processing server 10 receives an instruction to execute various instructions from the information processing terminal 20, acquires design data of another project, and generates and stores data necessary for editing the design data in the information processing terminal 20. To do. In addition, the information processing server 10 of each project can communicate with the information processing server 10 of another project via a communication network such as a LAN, and can transmit and receive data to and from each other. Thereby, the information processing server 10 of each project can mutually refer to the design data of each project.

[About design data]
First, design data in this embodiment will be described. FIG. 3 is a diagram illustrating an example of design data generated in the design of the technical model (vehicle design). As shown in FIG. 3, the design data D is expressed in a tree format as a logical data structure. Specifically, the design data D includes item data D1 indicating design items and dependency relationship data D2 defining a dependency relationship between the item data D1. The types of item data D1 include requirement data D11 indicating requirements required for a product to be designed and element data D12 indicating design elements included in the product to be designed. The design data D is, for example, design data for a vehicle as a design object. The design data D includes requirement data D11 indicating requirements (vehicle requirements, fuel consumption, exhaust gas, vibration, output) required for the vehicle, and design elements ( Vehicle, engine, T / M, body) element data D12.

  As shown in FIG. 3, the requirements and the elements may each have a hierarchical structure. In the example shown in FIG. 3, the requirement data D11 is represented by dependency data D2 between the requirement data D11 indicating requirements (vehicle requirements) and the requirement data D11 indicating other requirements (fuel consumption, exhaust gas, vibration, output). Dependency relationship (parent-child relationship) is defined. That is, it is specified that the requirements (vehicle requirements) required for the vehicle specifically include requirements such as fuel consumption, exhaust gas, vibration, and output. Similarly, the dependency relationship between the element data D12 is determined by the dependency relationship data D2 between the element data D12 indicating the element (vehicle) and the element data D12 indicating the other elements (engine, T / M, body). (Parent-child relationship) is defined. In other words, it shows that there are concrete elements such as an engine, T / M, and body as design elements of the car.

  Further, the dependency relationship between the requirement and the element is defined by the dependency relationship data D2 between the requirement data D11 and the element data D12. A dependency between a requirement and an element indicates that one design of the requirement and element has some relationship to the other design. For example, in the example shown in FIG. 3, the dependency relationship data D2 between the requirement (fuel consumption) and the element (engine, body) is the element (engine, body) when the target value of the requirement (fuel consumption) is changed. It is shown that there is a possibility that design changes will occur. Conversely, the dependency relationship data D2 between the requirement (fuel consumption) and the element (engine, body) achieves the target value of the requirement (fuel consumption) when the design change of the element (engine, body) occurs. It shows that the result of whether or not it can be affected.

  Each item data D1 (requirement data D11 or element data D12) belongs to at least one data set DS. The data set DS is a grouping of item data D1 classified into the same category. As types of the data set DS, there are a requirement data set DS1 including one or more requirement data D11 and an element data set DS2 including one or more element data D12. In the example shown in FIG. 3, each requirement data D11 (fuel consumption, exhaust gas, vibration, output) is included in a different requirement data set DS1, and each element data D12 (engine, T / M, body) is respectively It is included in a different element data set DS2.

  4 to 6 are diagrams illustrating examples of requirement data, element data, and dependency relationship data. As shown in FIGS. 4 to 6, information (related information) indicating various attribute values is associated with the requirement data, element data, and dependency relationship data.

  As shown in FIG. 4, the requirement data is associated with related information such as specification risk and importance. The specification risk is an index indicating the degree of determination of the specification, and takes a smaller value as the degree of determination of the specification increases. For example, “0 (minimum value)” is set as the specification risk when the specification is confirmed, and “5 (maximum value)” is set as the specification risk when the specification is not yet considered. The importance is an index indicating the relative importance in the entire requirement, and takes a larger value as the importance is higher.

  As shown in FIG. 5, the element data is associated with related information such as element risk and degree of freedom. The element risk is an index indicating the definite degree of element design, and takes a smaller value as the definite degree of element design is larger. The degree of freedom is an index indicating the degree of tolerance of how much to change to another method, and takes a larger value as the degree of tolerance to change to another method increases. That is, the greater the design range in which the method can be freely changed, the larger the degree of freedom is set.

  As shown in FIG. 6, the dependency relationship data is associated with related information such as dependency and confidence. The dependency is an index indicating the strength (sensitivity) of the dependency, and takes a larger value as the sensitivity is higher. The confidence level is an index indicating the accuracy of whether or not the setting of the dependency level is appropriate, and takes a larger value as the possibility that the setting of the dependency level is appropriate is higher.

  FIG. 7 shows the dependency relationship data D2 between the requirement data D11 and the element data D12 shown in FIG. 3 in a DMM (Domain Mapping Matrix) format. The cell value in the table indicates the dependency of the dependency relationship data D2 between the requirement data D11 indicated by the vertical axis and the element data D12 indicated by the horizontal axis. FIG. 8 is a diagram showing the dependency relationship data D2 between the requirement data D11 shown in FIG. 3 in a DSM (Domain Structure Matrix) format. The value of the cell in the table indicates the dependency of the dependency relationship data D2 between the requirement data D11 indicated by the vertical axis and the requirement data D11 indicated by the horizontal axis. The dependency relationship data D2 between the element data D12 shown in FIG. 3 can also be expressed in the same DSM format as the dependency relationship data D2 between the requirement data D11 shown in FIG.

[Reference editing of dependency data]
Next, reference editing of dependency relationship data will be described. Dependency data reference editing types include dependency data reference addition, reference update, and reference deletion. The reference addition of the dependency relationship data is to add dependency relationship data directly connecting the requirement data, the element data, or the requirement data and the element data included in the data set of another referenced project. The reference update of the dependency relationship data is to update the related information of the dependency relationship data of the referenced other project. Dependency data reference deletion is to delete the dependency data of other referenced projects. In the present embodiment, reference deletion of the dependency relationship data is performed by adding a reference deletion flag indicating that the dependency relationship data is handled as deleted.

  Referring to FIG. 9 and FIG. 10, reference editing of dependency relationship data will be described. Here, a case where the project PJ1 refers to the data set designed in the project PJ0 as a reference data set will be described as an example. In the following description, when “data set” is described in the sense of “referencing (acquiring) a data set”, this “data set” is the requirement data or element data included in the data set. A data group including dependency data associated with the requirement data or element data is shown.

  FIG. 9 is a diagram showing design data before execution of reference editing of dependency data by the project PJ1. As shown in FIG. 9, the requirement data R011 to R013 included in the requirement data set RS01 designed in the project PJ0 is referred to by the project PJ1. Similarly, the element data E011 to E013 included in the element data set ES01 designed in the project PJ0 is referred to by the project PJ1. Dependency relationship data R011-E011 (data indicating the dependency relationship between the requirement data R011 and the element data E011; hereinafter, other dependency relationship data is also expressed in the same manner), R012-E011, R012-E012, R012 -E013, R013-E012 are referenced by project PJ1. In FIG. 9, the element data set ES11, element data E111, and dependency data R011-E111, R012-E111, R013-E111, E111-E012 are data added by the project PJ1 without reference editing. It is.

  FIG. 10 is a diagram showing design data after execution of reference editing of the dependency relationship data by the project PJ1. In FIG. 10, the “!” Mark indicates that the dependency relationship data R013-E011, R012-E011, R012-E012, and R013-E012 are reference edited data. The dependency relationship data R012-E012 and R013-E012 indicated by broken lines are dependency relationship data whose reference has been deleted. In this example, the reference is added to the dependency relationship data R013-E011 having a dependency degree of “3”. Further, the dependency of the dependency relationship data R012-E011 is updated from “6” to “9”. In addition, the reference data of the dependency relationship data R012-E012, R013-E012 has been deleted.

[Reference editing of requirement (element) data]
Next, reference editing of requirement (element) data will be described. Since the requirement data reference editing is the same as the element data reference editing, the following description focuses on the element data reference editing. Types of element data reference editing include element data reference addition, reference update, and reference deletion. Adding reference to element data means adding element data to a data set of another referenced project. The reference update of the element data is to update the related information of the element data of another referenced project. Deletion of element data reference is to delete element data of other referenced projects. In the present embodiment, reference deletion of element data is performed by adding a reference deletion flag indicating that the element data is treated as deleted to the element data.

  Reference editing of element data will be described with reference to FIGS. 10 and 11. FIG. 10 described above is a diagram showing the design data before the reference editing of the element data by the project PJ1 is executed. FIG. 11 is a diagram showing design data after execution of reference editing of element data by the project PJ1. In FIG. 11, the “!” Mark added to the element data E012, E013, E015 indicates that the element data E012, E013, E015 is the reference edited data. Element data E013 indicated by a broken line is element data whose reference has been deleted. In this example, element data E015 is added to the element data set ES01 by reference. The element risk of the element data E012 is updated from “5” to “1”. Further, the element data E013 has been deleted from the reference.

[Reference data merge processing]
Next, reference data merging processing that is executed when referring to a plurality of data sets having the same origin (data sets edited by reference in each of a plurality of projects) will be described with reference to FIGS. 12 and 13. . The reference data merging process refers to data that conflicts when there are conflicting data (requirement data, element data, or dependency data) in a plurality of data sets to be referenced. Is a process for determining a design value to be adopted. As an example in the present embodiment, the reference data merging process includes “merge process based on the path cost of the reference path”, “merge process based on the reference edit state”, and “merge process based on the merge rule of reference update”. Including.

  FIG. 12 is a diagram conceptually illustrating an example of the reference relationship between the projects PJ0 to PJ3. In this example, project PJ1 refers to data set X created in project PJ0. The project PJ2 refers to the data set X and the data set X1 reflecting the reference editing by the project PJ1. The project PJ3 refers to the data set X1 and the data set X2 reflecting the reference editing by the project PJ2. Here, each of the data sets X1 and X2 is a data set whose origin is the data set X. In this example, when the project PJ2 refers to the data set X and the data set X1, and when the project PJ3 refers to the data set X1 and the data set X2, a reference data merge process may be required.

  In this embodiment, as an example, the reference data merge process is executed based on the flow shown in FIG. First, merge processing (step S1) based on the route cost of the reference path is executed. Here, the reference path is a path obtained by tracing the reference relationship from the reference source (reference side) project to the reference destination (reference side) project. For example, the reference path from the project PJ2 to the project PJ0 includes a reference path PJ2-PJ0 that directly traces from the project PJ2 to the project PJ0, and a reference path PJ2-PJ1-PJ0 that traces back from the project PJ2 to the project PJ0 via the project PJ1. There are two paths. Here, the reference path PJ2-PJ1-PJ0 is a reference path for indirectly referring to the data set X of the project PJ0 by referring to the data set X1 after being edited by the project PJ1. The route cost of the reference path indicates the number of projects included in the reference path.

  In the example illustrated in FIG. 12, the path cost of the reference paths PJ2-PJ0 is “0”, and the path cost of the reference paths PJ2-PJ1-PJ0 is “1”. Further, the path cost of the reference path PJ2-PJ1 from the project PJ2 to the project PJ1 is “0”.

  In the merge processing based on the path cost of the reference path, when there are overlapping paths among the reference paths to each of the plurality of reference destination projects, the reference path with the smaller path cost among the reference paths having the overlapping paths. Priority is given to the design value of the data set of the referenced project having. For example, attention is paid to a project PJ2 that refers to the data set X of the project PJ0 and the data set X1 of the project PJ1. In this case, the reference path PJ2-PJ1-PJ0 from the project PJ2 to the project PJ0 and the reference path PJ2-PJ1 from the project PJ2 to the project PJ1 have mutually overlapping paths (reference paths PJ2-PJ1). . Therefore, the path costs of reference paths having mutually overlapping paths, that is, the reference paths PJ2-PJ1-PJ0 and the reference paths PJ2-PJ1, are compared by the merge process based on the path costs of the reference paths.

  Here, the route cost (= 0) of the reference path PJ2-PJ1 is smaller than the route cost (= 1) of the reference path PJ2-PJ1-PJ0. Therefore, in the project PJ2, the data included in the data set X1 of the project PJ1 associated with the reference path PJ2-PJ1 with the smaller path cost has priority over the data included in the data set X of the project PJ0. For example, when the importance level of the requirement data Y included in the data set X is “5” and the importance level of the requirement data Y included in the data set X1 is “3”, the requirements included in the data set X1 Data Y (importance is “3”) is adopted. Similarly, a case is considered where data that conflict with each other is included between the data set X1 of the project PJ1 and the data set X2 of the project PJ2. In this case, in the project PJ3, the data included in the data set X2 of the project PJ2 has priority over the data included in the data set X1 of the project PJ1 by the merge process based on the path cost of the reference path.

  As in the example illustrated in FIG. 12, when the merge process can be performed by the merge process based on the path cost of the reference path (when the data to be adopted can be determined), the reference data merge process is terminated (step S2: YES). On the other hand, if the merge process cannot be performed by the merge process based on the path cost of the reference path (step S2: NO), the merge process based on the reference edit state is executed (step S3). For example, consider a case where the project PJ2 does not refer to the data set X1 of the project PJ1, as in the example shown in FIG. In this case, the path costs of the reference paths from the project PJ3 to the projects PJ1 and PJ2 are all “0”. Here, consider a case where the project PJ3 refers to the data set X1 of the project PJ1 and the data set X2 of the project PJ2. When the data sets X1 and X2 include data that conflict with each other, the path costs of the reference paths to the projects PJ1 and PJ2 are equal. Therefore, in the project PJ3, merge processing based on the path costs of the reference paths is performed. It is impossible to determine which data set should be prioritized.

  In the merging process based on the reference edit state, merging is performed based on a predetermined priority order between the reference edit states. As the reference edit state, for example, “reference update state” indicating that the reference has been updated, “reference deletion state” indicating that the reference has been deleted, “reference reference” indicating that neither reference update nor reference deletion has been executed. “No editing”. Here, it is assumed that the priority order between the reference editing states is determined in advance in the order of “reference update state”, “reference editing no state”, and “reference deletion state”. Further, in the example shown in FIG. 14, it is assumed that the requirement data Y is referenced and deleted in the data set X1 of the project PJ1, and the requirement data Y is neither reference edited nor deleted in the data set X2 of the project PJ2. . In this case, the requirement data Y of the data set X2 in the state without reference editing has a higher priority than the requirement data Y of the data set X1 in the reference deletion state. Therefore, in the project PJ3, the requirement data Y of the data set X2 in the state without reference editing is adopted by the merge processing based on the reference editing state. That is, in the project PJ3, the requirement data Y is referred to as not deleted.

  If merging is possible by the merge process based on the reference edit state, the reference data merge process is terminated (step S4: YES). On the other hand, if the merge process cannot be performed by the merge process based on the reference edit state (step S4: NO), a merge process based on the merge rule for reference update is executed (step S5). Here, the case where merging cannot be performed by the merge processing based on the reference editing state, specifically, in a plurality of data sets competing with each other, the same design object (requirement data, element data, or dependency relationship data) is used. This is a case where reference update of different contents is performed.

  In the merge process based on the reference update merge rule, the merge is performed based on a predetermined merge rule. For example, it is predetermined for each reserved attribute (current value of various risks, initial start value, final prospective value, current value of freedom, initial initial value, final prospective value, importance, remarks, etc.) prepared as related information. A design value to be adopted is determined according to the determined merge rule.

  Here, the predetermined merge rule, for example, prioritizes the larger value for the current value of various risks or degrees of freedom and the initial value of the start, and sets a smaller value for the end prospective value of various risks or degrees of freedom. It is a rule that priority is given, priority is given to a large value, and remarks are summed (both described items are merged). Such a rule may be settable by a user or the like.

  In addition, related information (custom attributes) added by customization by the user or the like is also merged based on merge rules (desired, desired, desired, 0/1, non-linear, function, etc.) set by the user. May be. “Thank you” means that the design value that is as large as possible is given priority. “Small hope” indicates that priority is given to a design value that is as small as possible. The “desired” indicates that priority is given to a design value that is as close as possible to a predetermined value (target value). “0/1” indicates that a predetermined value of ON (1) and OFF (0) is given priority over a design value having a discrete value. “Nonlinear, function” indicates that, for example, a design value represented by a function (formula) or a data string gives priority to a design value approximated by a predetermined nonlinear graph, function, or the like. As for the related information for which the design rule to be adopted cannot be automatically determined because the merge rule as described above is not defined, it can be merged so that a plurality of competing design values can be both retained. Good.

[Description of each function of the design support system]
Next, each function of the design support system 1 shown in FIG. 2 will be described. First, each function of the information processing server 10 will be described. The information processing server 10 includes a data set reference unit 11, a reference data merge unit 12, a data synchronization unit 13, a merge result DB 14, a merge result DB 15 with reference editing, a local project DB 16, another project DB 17, and a reference setting execution unit 18. ing.

  The data set reference unit (reference data acquisition unit) 11 is a functional element that acquires a data set of another project designated as a reference destination by the data set reference instruction unit 21 of the information processing terminal 20 as a reference data set (reference data). is there. Specifically, the data set reference unit 11 acquires requirement data or element data included in a data set of another project and dependency data associated with the requirement data or element data as a reference data set. For example, the data set reference unit 11 may acquire the reference data set by accessing the information processing server 10 of another project and acquiring the data set stored in the information processing server 10 of the other project. The data set reference unit 11 also acquires information related to a reference edit permission setting (details will be described later) for the reference data set.

  The data set reference unit 11 acquires again the data set (updated reference data) of the other project when the data set of the other project is updated after the data set of the other project is acquired as the reference data set. May be. For example, when the data set reference unit 11 detects that the data set of another project acquired as a reference data set by the design in the other project of the reference destination is updated, the data set reference unit 11 selects the updated data set from the other project. You may acquire it again. Any method for detecting the update of the data set in another project may be used. For example, the data set reference unit 11 refers to the data set by tracing the reference structure between projects (for example, the reference structure shown in FIG. 12) to the original data set (the data set of the highest-level reference destination project). Generate a path. And the data set reference part 11 may detect the update of a data set by monitoring the presence or absence of the update of the data set of the other project on a reference path.

  Further, the data set reference unit 11 may detect a change in the reference data set in another project by receiving a change notification such as an email notification from another project that has executed reference editing on the reference data set. Thereby, when a reference data set is changed in another project, the reference data set after the change of the other project can be acquired and transferred to a reference data merging unit 12 and a data synchronization unit 13 described later. Then, by the processing of the reference data merging unit 12 and the data synchronization unit 13, the data reflecting the latest design contents in the other project is stored in the merge result DB 14, the merge result DB 15 with reference edit, and the other project DB 17. Become. Moreover, the data set reference part 11 may acquire the reference data after the update of another project at the timing when the update process by the update part 26 mentioned later is performed. Thereby, the data which considered the data update of the other project can be memorize | stored in various DB on the information processing server 10 at the timing which synchronizes the design data on the information processing terminal 20 with a server.

  The reference data merging unit 12 is a functional element that executes the above-described reference data merging process when a plurality of reference data sets that compete with each other are acquired by the data set reference unit 11. Specifically, the reference data merging unit 12 includes a plurality of pieces of data competing with each other for the same requirement data, element data, or dependency data among the plurality of reference data sets acquired by the data set reference unit 11. Design that is adopted for the same requirement data, element data, or dependency data based on a predetermined rule when it is determined whether or not a plurality of competing data is included. Determine the value. Here, the “predetermined rule” refers to, for example, the above-described “merge process based on the path cost of the reference path”, “merge process based on the reference edit state”, and “merge process based on the reference update merge rule” And the like in the merge process. The reference data merging unit 12 can automatically determine a design value to be adopted even when a plurality of reference data sets include data that conflict with each other.

  The reference data merging unit 12 performs, for example, the reference path route cost (predetermined for each of the other projects that are the respective owners of the plurality of data competing with each other by the above-described merge processing based on the reference path route cost. (Priority based on rule) may be calculated. Then, a design value of data held in another project in which the path cost of the reference path is minimum (priority is maximum) among a plurality of data competing with each other may be determined as a design value to be adopted. As a result, the design value to be adopted can be appropriately determined according to the path cost of the reference path calculated for each of the other projects each holding a plurality of data competing with each other.

  Also, the reference data merging unit 12 performs, for example, the reference editing state (the type of editing performed by the other project of each data holding source) for each of a plurality of data competing with each other by the merge processing based on the above-described reference editing state. Edit information to be obtained), and a design value of data corresponding to the reference edit state having a predetermined priority with respect to the reference edit state among a plurality of data is determined as a design value to be adopted. Also good. Thereby, the design value to be adopted can be appropriately determined according to the reference editing state of each of the plurality of data competing with each other.

  The reference data merging unit 12 stores data (requirement data, element data, or dependency relationship data) whose design values are determined by the above-described reference data merging process in the merge result DB 14 as a merge result. The design value may be an attribute value associated with data, or information indicating the presence or absence of the data (whether or not it is deleted).

  Further, the reference data merge unit 12 acquires a reference edit result for the reference data set from the update unit 26 described later. The reference editing result is pair information including reference edited data (requirement data, element data, or dependency relationship data) and flag information indicating the type of reference editing (reference addition, reference update, reference deletion). . When the reference data merging unit 12 acquires the reference editing result from the updating unit 26, the reference data merging unit 12 stores the merge result with reference editing in which the merge result and the reference editing result described above are combined in the merge result DB 15 with reference editing.

  The data synchronization unit 13 is a functional element that brings the own project DB 16 and the other project DB 17 to the latest state based on the data acquired from the data set reference unit 11 or the update unit 26. The own project DB 16 is a database that stores requirement data or element data included in a data set added in the own project and dependency data associated with the requirement data or element data as a self-designed data set. The other project DB 17 is a database that stores a reference data set of another project acquired by the data set reference unit 11. When acquiring the reference data set from the data set reference unit 11, the data synchronization unit 13 stores the reference data set in the other project DB 17. Further, when the data synchronization unit 13 acquires the self-designed data set from the update unit 26, the data synchronization unit 13 stores the self-designed data set in the self-project DB 16.

  The reference setting execution unit 18 is a functional element that executes settings for the reference editing permission setting and the reference mode setting. The reference editing permission setting is a setting for whether or not reference editing by another project is permitted, which is set for the self-designed data set. The reference editing permission setting is set to a “reference editing permission mode” that permits reference editing or a “reference editing permission mode” that does not allow reference editing. The reference mode setting is a setting as to whether or not to refer to the reference data set in a reference editing mode in which the reference data set can be referred to. The reference mode setting is set to a “reference edit mode” that is referred to when reference editing is possible or a “reference mode” that is referred to when reference editing is not possible (only reference is permitted). The reference setting execution unit 18 stores the setting contents of the reference edit permission setting and the reference mode setting in the own project DB 16. By storing the reference editing permission setting in the own project DB 16, for example, the reference editing permission setting of the own design data set for the information processing server 10 of another project that has accessed the own project DB 16 in an attempt to refer to the own design data set. Can communicate information about

  Subsequently, each function of the information processing terminal 20 will be described. The information processing terminal 20 includes a data set reference instruction unit 21, a pre-reference editing project DB 22, a project DB 23, a design data presentation unit 24, an editing execution unit 25, an updating unit 26, a reference editing cancellation unit 27, and a reference setting execution unit 28. I have.

  The data set reference instruction unit 21 is a functional element that receives a predetermined input operation by the user and instructs the data set reference unit 11 to acquire a data set of another project specified by the input operation as a reference data set. is there.

  The pre-reference editing project DB 22 stores reference data sets in a state in which the reference editing results in the own project (reference editing results by the editing execution unit 25) are not reflected (if there are multiple reference data sets that conflict with each other) This is a database that stores a data set after merging. The pre-editing project DB 22 acquires data (merge result) stored in the merge result DB 14 and data (reference data set) stored in the other project DB 17. The pre-reference editing project DB 22 generates and stores a reference data set in a state in which the reference editing result in the own project is not reflected based on these data. Specifically, the pre-reference editing project DB 22 replaces a data portion that needs reference data merging processing in one or more reference data sets with a merge result, so that the reference editing result in the own project is not reflected. A reference data set can be generated and stored. Data included in the reference data set stored in the pre-reference editing project DB 22 is used as data for updating the project DB 23 when a reference update canceling unit 27 described later executes a reference update canceling process. Used (details will be described later).

  The project DB 23 is a database (design data storage unit, design data storage processing unit) that stores the reference data set acquired by the data set reference unit 11 via the other project DB 17. Specifically, the project DB 23 stores design data reflecting the editing results of the own project (results of normal editing and reference editing by the editing execution unit 25). Normal editing means adding, updating, or deleting a self-designed data set. The normal editing includes updating the element data, requirement data, or dependency data referenced and added by the editing execution unit 25 of the own project by the editing execution unit 25 of the own project. When the project DB 23 synchronizes with the design data stored in the information processing server 10, the data stored in the merge result DB 15 with reference edit (merge result with reference edit) and the own project DB 16 are stored. Data (self-designed data set) and data (reference data set) stored in the other project DB 17 are acquired. Then, based on these data, design data including a reference editing result and a normal editing result (a self-designed data set added by normal editing) with respect to the reference data set reflecting the merge result is generated and stored. .

  When normal editing (addition, update, or deletion of a self-designed data set) is executed by an editing execution unit 25 described later, the self-designed data set reflecting the result of the normal editing is stored in the project DB 23. Further, when reference editing (reference addition / reference update / reference deletion with respect to the reference data set) is executed by the editing execution unit 25, the project DB 23 stores the reference editing result. That is, the design data in which the editing result by the user via the editing execution unit 25 is reflected in real time is stored in the project DB 23.

  The design data presentation unit 24 is a functional element that presents design data stored in the project DB 23 to the user. The design data presentation unit 24 displays design data on a screen such as a display in the tree format shown in FIG. 3, the DMM format and the DSM format shown in FIGS. Here, among the data stored in the project DB 23, the design data presentation unit 24 is data to which a reference deletion flag (described in detail later) is added, requirement data or element data to which a reference deletion flag is added. It is not necessary to present the dependency relationship data associated with to the user. Alternatively, the design data presentation unit 24 presents these data to the user so that it can be understood that the data is the reference-deleted data or the dependency data associated with the reference-deleted requirement data or element data. Also good.

  The editing execution unit 25 is a functional element that executes normal editing or reference editing in accordance with an input operation by the user. Specifically, the edit execution unit 25 adds, updates, or deletes the self-designed data set by normal editing, and stores the self-designed data after the normal editing in the project DB 23. The editing execution unit 25 executes reference addition, reference update, or reference deletion of the requirement data, element data, or dependency data by reference editing on the reference data set, and stores the reference editing result in the project DB 23. The editing execution unit 25 includes the requirements included in the reference data set only when the reference data set is set to the “reference editing permission mode” and the reference data set is set to the “reference editing mode”. It may be possible to perform reference editing on data or element data. In addition, with respect to dependency relationship data between two reference data sets, reference editing may be performed only when both of the two reference data sets are reference-editable.

  When executing reference addition of requirement data, element data, or dependency relationship data, the editing execution unit 25 stores the reference added data in the project DB 23. At this time, a reference addition flag indicating that the reference added data is added to the reference added data.

  When executing the reference update of the requirement data, the element data, or the dependency relationship data, the editing execution unit 25 stores the data after the reference update in the project DB 23. At this time, a reference update flag indicating that the data is updated by reference is added to the data after reference update.

  When executing the reference deletion of the requirement data, the element data, or the dependency relationship data, the editing execution unit 25 does not delete the reference deleted data from the project DB 23, and the reference deleted data is included in the data. A reference deletion flag indicating that there is present is added.

  The update unit 26 uses the design data stored in the project DB 23 as a trigger when a predetermined input operation by the user or a reference editing permission setting or a reference mode setting by a reference setting execution unit 28 described later is executed. This is a functional element that updates the database (the own project DB 16 and the merge result DB 15 with reference editing) on the processing server 10. Specifically, the update unit 26 transmits the self-designed data set stored in the project DB 23 to the data synchronization unit 13. Thereby, the own project DB 16 is updated by the data synchronization unit 13. In addition, the update unit 26 transmits the reference editing result stored in the project DB 23 to the reference data merge unit 12. As a result, the reference result merge unit 12 updates the merge result DB 15 with reference edit.

  The reference edit canceling unit 27 cancels (clears) reference editing for requirement data, element data, or dependency data (cancellation target data) specified by the user input operation, etc., with a predetermined input operation by the user as a trigger. ) A functional element that executes processing. Since the reference editing cancellation unit 27 can easily cancel the reference editing for the reference data set, the user of the own project can easily consider various design patterns. Specifically, the reference editing cancellation unit 27 refers to the project DB 23 to check the type of flag added to the cancellation target data, and executes the following processing according to the type of the flag.

  When the reference addition flag is added to the cancellation target data, the reference editing cancellation unit 27 deletes the cancellation target data from the project DB 23. Thereby, the reference addition about the cancellation target data is canceled (the reference is not added).

  When the reference update flag is added to the cancellation target data, the reference editing cancellation unit 27 acquires the cancellation target data stored in the pre-reference editing project DB 22. Then, the cancellation target data stored in the project DB 23 is updated (overwritten) with the cancellation target data. Further, the reference edit cancellation unit 27 deletes the reference update flag of the cancellation target data. As a result, the cancellation target data is updated to data to be adopted when the reference update is not performed.

  When the reference deletion flag is added to the cancellation target data, the reference edit cancellation unit 27 deletes the reference deletion flag of the cancellation target data stored in the project DB 23. When the reference deletion flag added to the cancellation target data is deleted, the design data presentation unit 24 presents the cancellation target data to the user as data that has not been deleted.

  The reference setting execution unit 28 is a functional element that executes reference edit permission setting for the self-designed data set and reference mode setting for the reference data set in accordance with an input operation by the user. The reference setting execution unit 28 stores the setting contents of the reference editing permission setting and the reference mode setting in the project DB 23. The reference setting execution unit 28 also updates the reference editing permission setting or reference to the reference setting execution unit 18 in order to update the setting contents of the reference editing permission setting and the reference mode setting in the own project DB 16 on the information processing server 10. Sends the details of mode setting.

[1.2 Reference structure between hierarchical projects]
Next, the functions executed by the design support system 1 will be specifically described with reference to FIGS. 15 to 29, taking as an example the case where reference editing is executed between two-tier projects. FIG. 15 is a diagram showing a reference relationship between two-tier projects. Here, as an example, as shown in FIG. 15, a case where the requirement data set RS01 and the element data set ES01 of the reference destination project PJ0 are referred to by the reference source project PJ1 will be described as an example.

[1-1. Creation of design data in project PJ0]
First, in the reference project PJ0, normal editing by the user (the person in charge of designing the project PJ0) is executed. FIG. 16 is a diagram showing design data newly added by normal editing in the project PJ0. FIG. 17 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 16 in a DMM format.

  The editing execution unit 25 of the project PJ0 adds the requirement data set RS01 and the element data set ES01 by normal editing. The editing execution unit 25 adds requirement data R011 and R012 to the requirement data set RS01. Here, as an example, the editing execution unit 25 sets the importance of the requirement data R011 and R012 to “5”, and sets the specification risk to “5”. Subsequently, the editing execution unit 25 adds element data E011 to E014 to the element data set ES01. Here, as an example, the editing execution unit 25 sets the degree of freedom of the element data E011 to E014 to “5” and sets the element risk to “5”. Subsequently, the editing execution unit 25 adds the dependency relationship data R011-E011, R011-E012, R012-E012, R012-E013, R012-E014. Here, as an example, the editing execution unit 25 sets the dependency of the dependency relationship data R011-E012 to “6”, and sets the other dependency relationship data R011-E011, R012-E012, R012-E013, R012-E014. The dependency is set to “9”.

  The editing execution unit 25 receives an input operation by the user, and stores the normal editing result (the result of the above-described normal editing) according to the input operation in the project DB 23. At this time, the user can execute the above-described normal editing via the editing execution unit 25 while confirming the contents of the design data displayed on the display or the like by the design data presentation unit 24.

  When the above-described normal editing is completed in the project PJ0, update processing by the update unit 26 is executed with a predetermined input operation by the user as a trigger. Specifically, the update unit 26 stores the design data (design data shown in FIG. 16) stored in the project DB 23 in the data synchronization unit 13 of the project PJ0 (information processing server 10 of the project PJ0) as its own design data set. Send. The data synchronization unit 13 stores the self-designed data set in the self-project DB 16.

[1-2. Refer to the data set of project PJ0 in project PJ1]
Subsequently, in the project PJ1, the data sets RS01 and ES01 of the project PJ0 are referred to. Specifically, the data set reference instructing unit 21 of the project PJ1 receives an input operation by the user (an input operation instructing to refer to the data sets RS01 and ES01 of the project PJ0). Then, the data set reference instruction unit 21 transmits the instruction content to the data set reference unit 11 of the project PJ1.

  Upon receiving the instruction content, the data set reference unit 11 accesses the information processing server 10 (own project DB 16) of the project PJ0. Then, the data set specified by the data set reference instructing unit 21 and dependency data between the data sets are acquired as a reference data set. Specifically, the data set reference unit 11 includes the requirement data set RS01 and the requirement data R011 and R012 included in the requirement data set RS01, the element data set ES01 and the element data E011 to E014 included in the element data set ES01. And dependency data R011-E011, R011-E012, R012-E012, R012-E013, R012-E014 are acquired as a reference data set. Here, since only the data set of one project (project PJ0) is referred to, the acquired reference data sets do not include data sets that compete with each other. Therefore, the process by the reference data merging unit 12 is not executed, and the process by the data synchronization unit 13 is executed. The data synchronization unit 13 stores the reference data set acquired by the data set reference unit 11 in the other project DB 17.

  Subsequently, the project DB 23 of the project PJ1 acquires and stores the reference data set of the project PJ0 stored in the other project DB 17. Then, the design data presentation unit 24 of the project PJ1 presents the reference data set of the project PJ0 (same as the design data of the project PJ0 shown in FIG. 16) to the user of the project PJ1. As a result, the user of the project PJ1 can proceed with the design of the project PJ1 while referring to the reference data set of the project PJ0.

[1-3. Data change in project PJ0 and transmission to project PJ1]
Next, a case where the design data is changed in the reference project PJ0 after the above-described “1-2” data set reference process is executed will be described. Here, as an example, a case where the design data of the project PJ0 is changed as shown in FIGS. 18 and 19 will be described. FIG. 18 is a diagram showing design data of the project PJ0 after the change, and FIG. 19 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 18 in the DMM format.

  Here, as an example, the editing execution unit 25 of the project PJ0 makes the following changes to the design data of the project PJ0 by normal editing. That is, the editing execution unit 25 adds the requirement data R013 (the importance is “5” and the specification risk is “5”) to the requirement data set RS01, and the importance of the requirement data R012 is changed from “5” to “3”. Update. Further, the editing execution unit 25 updates the degree of freedom of the element data E011 from “5” to “1”, and deletes the element data E014 (the dependency relationship data R011 to E014 associated with the element data E014 is also deleted). . Further, the editing execution unit 25 deletes the dependency relationship data R011-E012, adds dependency relationship data R012-E011 having a dependency level of “6”, and changes the dependency level of the dependency relationship data R012-E012 from “9” to “9”. 3 ”and dependency data R013-E012 having a dependency level of“ 9 ”is added.

  In this case, the data set reference unit 11 of the project PJ1 detects the update of the data set in the project PJ0 designated as the reference destination, and the updated data set from the project PJ0 (updated reference data; design shown in FIG. 18). Data) again. Thereafter, the data set acquired again is stored in the other project DB 17 by the data synchronization unit 13. Further, the reference data set stored in the other project DB 17 is acquired and stored by the pre-reference editing project DB 22 and the project DB 23. Specifically, the pre-reference editing project DB 22 and the project DB 23 update the reference data stored in the own DB with the updated reference data.

  Thereby, the reference data set reflecting the latest design contents in the project PJ0 is stored in the project DB 23. Then, the design data presentation unit 24 of the project PJ1 presents the updated reference data set stored in the project DB 23 to the user of the project PJ1. Thereby, the user of the project PJ1 can proceed with the design while referring to the design data (reference data set) reflecting the above-described design change in the project PJ0. As a result, the user of the project PJ1 refers to the old design data of the project PJ0 and proceeds with the design, thereby suppressing the possibility of a flaw between the design contents of the project PJ1 and the design contents of the project PJ0. be able to.

[1-4. Normal editing in project PJ1]
Subsequently, as shown in FIGS. 20 and 21, normal editing is executed in the project PJ1. FIG. 20 is a diagram showing design data of the project PJ1 after execution of normal editing, and FIG. 21 is a diagram showing dependency data between requirement / element data in the design data shown in FIG. 20 in DMM format. The editing execution unit 25 of the project PJ1 adds the element data set ES11 by normal editing, adds the element data E111 to the element data set ES11, and adds dependency data R011-E111, R012-E111, R013-E111, E111. -Add E012. The editing execution unit 25 stores the data (self-designed data set) added by the normal editing in the project DB 23.

[1-5. Reference editing settings]
Subsequently, settings necessary for the project PJ1 to refer to and edit the requirement data set RS01 and the element data set ES01 of the project PJ0 are performed. Specifically, the reference setting execution unit 18 of the project PJ0 sets the requirement data set RS01 and the element data set ES01 that are self-designed data sets to the reference edit permission mode. The fact that the requirement data set RS01 and the element data set ES01 are set to the reference edit permission mode in the project PJ0 is transmitted to the project PJ1 via the data set reference unit 11 of the project PJ1. On the other hand, the reference setting execution unit 28 of the project PJ1 sets the reference data set (the requirement data set RS01 and the element data set ES01 of the project PJ0) to the reference editing mode. With the above settings, the editing execution unit 25 of the project PJ1 specifies the reference data sets (requirement data set RS01, element data set ES01, and requirement data set RS01 and element data set ES01 stored in the project DB 23. Reference dependency data) can be executed.

[1-6. Dependency data reference edit]
Subsequently, reference editing of the dependency relationship data is executed by the editing execution unit 25 of the project PJ1. FIG. 10 is a diagram illustrating the design data after the reference editing of the dependency relationship data by the project PJ1 is executed as described above. FIG. 22 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 10 in a DMM format. In FIG. 22, a “!” Mark added to a cell indicating the dependency degree (other than “*”) of the dependency relationship data indicates that the dependency degree has been referenced and updated. Further, the “!” Mark added to the square indicating the dependency “*” of the dependency relationship data indicates that the dependency relationship data has been dereferenced. Further, “*” indicates that the dependency relationship data has been deleted by reference.

  As illustrated in FIGS. 10 and 22, the editing execution unit 25 refers to and adds the dependency relationship data R013-E011 having the dependency degree “3” by reference editing with respect to the element data set ES01. Specifically, the editing execution unit 25 stores the dependency relationship data R013-E011 to which the reference addition flag is added in the project DB 23. Further, the editing execution unit 25 updates the dependency of the dependency relationship data R012-E011 from “6” to “9”. Specifically, the editing execution unit 25 stores the updated dependency relationship data R012-E011 in the project DB 23 with a reference update flag added. Further, the editing execution unit 25 references and deletes the dependency relationship data R012-E012, R013-E012. Specifically, the editing execution unit 25 adds a reference deletion flag to the dependency relationship data R012-E012, R013-E012 stored in the project DB 23.

[1-7. Element data reference edit]
Subsequently, the element data reference editing is executed by the editing execution unit 25 of the project PJ1. FIG. 11 is a diagram showing the design data after the reference editing of the element data by the project PJ1 is executed as described above. FIG. 23 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 11 in a DMM format. In FIG. 23, the “!” Mark added to the element data indicates that the element data is element data with reference added. The “!” Mark added to the element risk indicates that the element risk has been updated by reference.

  As shown in FIGS. 11 and 23, the edit execution unit 25 adds and references the element data E015 to the element data set ES01 by reference editing for the element data set ES01. Specifically, the editing execution unit 25 stores the element data E015 to which the reference addition flag is added in the project DB 23. Further, the editing execution unit 25 updates the element risk of the element data E012 from “5” to “1”. Specifically, the edit execution unit 25 stores the updated element data E012 in the project DB 23 after adding a reference update flag. Further, the edit execution unit 25 references and deletes the element data E013. Specifically, the edit execution unit 25 adds a reference deletion flag to the element data E013 stored in the project DB 23.

[1-8. Data change in project PJ0 and transmission to project PJ1]
Next, a case will be described in which the design data is changed in the reference project PJ0 after the processes up to “1-7” are executed. Here, as an example, the design data in the project PJ0 is changed from the state shown in FIGS. 18 and 19 (the state after the data change in “1-3” described above), as shown in FIGS. The case where it changed is demonstrated. FIG. 24 is a diagram showing design data of the project PJ0 after the change, and FIG. 25 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 24 in the DMM format.

  Here, as an example, the editing execution unit 25 of the project PJ0 makes the following changes to the design data of the project PJ0 by normal editing. That is, the editing execution unit 25 updates the specification risk of the requirement data R011 from “5” to “1”. The editing execution unit 25 updates the element risk of the element data E011 from “5” to “1”, and updates the degree of freedom of the element data E012 from “5” to “3”. Further, the editing execution unit 25 updates the dependency of the dependency relationship data R012-E011 from “6” to “3”, deletes the dependency relationship data R012-E012, and changes the dependency of the dependency relationship data R012-E013 to “3”. Update from “9” to “6”.

  In this case, the data set reference unit 11 of the project PJ1 detects the update of the data set in the project PJ0 designated as the reference destination, and the data set after the update from the project PJ0 (updated reference data; design shown in FIG. 24). Data) again. Thereafter, the data set acquired again is stored in the other project DB 17 by the data synchronization unit 13. Further, the contents of the updated reference data set stored in the other project DB 17 are acquired and stored by the pre-reference editing project DB 22. The contents of the updated reference data set stored in the other project DB 17 are also acquired by the project DB 23. In this example, there is only one reference destination project. However, there are a plurality of reference destination projects, and updated reference data of at least one reference destination project among the plurality of reference destination projects is acquired by the data set reference unit 11. In this case, the updated reference data of the at least one reference destination project and the reference data set already acquired by the data set reference unit 11 for the other reference destination projects are input to the reference data merging unit 12. . Then, the reference data merging unit 12 executes the above-described reference data merging process for these input data, and updates the merge result DB 14 and the merge result DB 15 with reference edit. As a result, the project DB 22 before reference editing is updated based on the data stored in the other project DB 17 and the merge result DB 14, and the project DB 23 is stored in the own project DB 16, the other project DB 17, and the merge result DB 15 with reference editing. It is updated based on the data.

  Here, if the reference data stored in the project DB 23 is updated with the updated reference data set acquired from the other project DB 17, the reference update in the project PJ1 (the above “1-6” and “1-7” is performed). There is a risk of overwriting the contents of the reference update executed in “”. This is not preferable for the user of the project PJ1 who proceeds with the design of the project PJ1. Therefore, the project DB 23 may exclude the requirement data, element data, or dependency relationship data for which reference updating has been executed by the editing execution unit 25 from being updated by the updated reference data. In other words, the project DB 23 does not need to update the data that has been referenced and updated in the project PJ1 among the updated reference data. That is, the project DB 23 may update only data that has not been updated in the project PJ1 (data that has been deleted by reference or data that has not been edited by reference) based on the updated contents in the project PJ0. As a result, it is possible to prevent the data updated and referenced by the user of the project PJ1 from being overwritten with the data updated in the project PJ0 against the intention of the user of the project PJ1. Here, the project DB 23 is based on the updated reference data of the project PJ0 if the content of the reference update does not conflict with the updated content in the reference project PJ0 even if the data is updated by reference in the project PJ1. The data of project PJ1 may be updated. That is, the project DB 23 may determine whether or not to reflect the updated contents in the reference project PJ0 in units of related information. Specifically, even if the project DB 23 is data that has been updated by reference in the project PJ1, if the related information that has been updated by reference in the project PJ1 and the related information that has been updated in the project PJ0 are different, the project PJ0 The updated contents of may be reflected. For example, in the project DB 23, the element data E012 for which the element risk reference update (“5” → “1”) was performed in the project PJ1, the degree of freedom was updated (“5” → “3”) by the project PJ0. In such a case, the update of the degree of freedom may be reflected. In the present embodiment, it is assumed that the project DB 23 determines whether or not to reflect the updated contents in the referenced project in units of related information, not in units of data (requirement data, element data, or dependency relationship data). To do. However, it goes without saying that it may be determined in data units whether or not the updated contents in the referenced project are reflected. Further, the project DB 23 stores both the updated reference data of the reference destination project PJ0 and the reference editing result in the project PJ1 so that the design data presentation unit 24 can appropriately switch and present it according to the user operation. May be.

  FIG. 26 is a diagram showing design data of the project PJ1 after being updated based on the above policy. FIG. 27 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 26 in a DMM format. As shown in FIG. 26, the project DB 23 reflects the update result by the project PJ0 for the requirement data R011 that has not been updated in the project PJ1. On the other hand, the project DB 23 does not reflect the update result by the project PJ0 with respect to the element data E012 that has been referenced and updated in the project PJ1.

[1-9. Canceling reference edit]
Next, a case will be described in which a cancel process for canceling all the reference edits executed in the above “1-6” and “1-7” is executed in the project PJ1. Specifically, the reference editing cancellation unit 27 executes a cancellation process according to the type of reference editing for each of the element data and the dependency relationship data subjected to the reference editing. FIG. 28 is a diagram showing design data after the cancellation process of the reference edit cancellation unit 27 described above. FIG. 29 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 28 in a DMM format.

  The reference edit cancellation unit 27 cancels the reference addition of the element data E015. Specifically, the reference edit cancellation unit 27 deletes the element data E015 and the dependency relationship data E111 to E015 associated with the element data E015 from the project DB 23. The reference edit cancellation unit 27 cancels the reference deletion of the element data E013. Specifically, the reference edit cancellation unit 27 deletes the reference deletion flag added to the element data E013 from the project DB 23. Thereby, the element data E013 and the dependency relationship data R012-E013 are again presented to the user by the design data presentation unit 24. Here, the dependency of the dependency relationship data R012-E013 is “6” because the design change in the project PJ0 in the above “1-8” is reflected.

  The reference edit cancellation unit 27 cancels the reference update in which the element risk of the element data E012 is updated from “5” to “1”. Specifically, the reference editing cancellation unit 27 acquires element data E012 (data whose degree of freedom has been changed to “3” in the above “1-8”) stored in the project DB 22 before reference editing. Then, the element data E012 stored in the project DB 23 is updated (overwritten) with the element data E012. Further, the reference edit canceling unit 27 deletes the reference update flag of the element data E012. As described above, the change contents in the project PJ0 for the element data E012 are not transmitted in a state where the reference edit for the element data E012 is valid, but are transmitted when the reference edit is canceled.

  The reference editing cancellation unit 27 cancels the reference update in which the dependency degree of the dependency relationship data R012-E011 is updated from “6” to “9”. Specifically, the reference editing cancellation unit 27 stores the dependency relationship data R012-E011 (data in which the dependency is changed to “3” in the above “1-8”) stored in the project DB 22 before reference editing. get. Then, the dependency relationship data R012-E011 stored in the project DB 23 is updated (overwritten) with the dependency relationship data R012-E011. Further, the reference edit cancellation unit 27 deletes the reference update flag of the dependency relationship data R012-E011. As described above, the change contents in the project PJ0 with respect to the dependency relationship data R012-E011 are not transmitted when the reference edit for the dependency relationship data R012-E011 is valid, but are transmitted when the reference edit is canceled. .

  The reference editing cancellation unit 27 cancels the reference addition of the dependency relationship data R013-E011. Specifically, the reference edit cancellation unit 27 deletes the dependency relationship data R013-E011 from the project DB 23.

[2.3 Reference structure between 3 level projects]
Next, the functions executed by the design support system 1 when reference editing is executed between three-tier projects will be specifically described with reference to FIGS. 30 to 38. FIG. 30 is a diagram illustrating a reference relationship between three-tier projects. In the example shown in FIG. 30, the intermediate layer projects PJ1 and PJ2 refer to the requirement data set RS01 and the element data set ES01 of the highest-level project PJ0. The lowest-level project PJ3 refers to the requirement data set RS01 and element data sets ES01 and ES11 of the project PJ1, and also refers to the requirement data set RS01 and element data sets ES01 and ES21 of the project PJ2.

[2-1. Reference editing in project PJ1]
First, in the project PJ1, normal editing similar to the above “1-4” is executed. Thereby, the design data of the project PJ1 is in the state shown in FIGS. Subsequently, in the project PJ1, reference editing similar to the above “1-6” and “1-7” is executed, so that the design data of the project PJ1 is in the state shown in FIGS. On the other hand, in the project PJ2, reference editing is not executed, and the design data (see FIG. 18) of the changed project PJ0 is referred to.

[2-2. Reference data merge in Project PJ3]
Subsequently, the data set reference unit 11 of the project PJ3 makes reference edit contents of the reference paths PJ3-PJ1-PJ0 (requirement data set RS01 reflecting the reference edit in the project PJ1, element data set ES01, and requirement data set RS01 Dependency relationship data with the element data set ES01) is acquired. Further, the data set reference unit 11 makes reference edit contents of the reference path PJ3-PJ2-PJ0 (requirement data set RS01, element data set ES01 reflecting the reference edit in the project PJ2, element data set RS01 and element data set) Dependency relationship data with ES01) is acquired. Subsequently, the reference data merging unit 12 of the project PJ3 executes reference data merging of the reference edit contents of the reference paths PJ3-PJ1-PJ0 and the reference edit contents of the reference paths PJ3-PJ2-PJ0.

  Here, as an example, it is assumed that the reference data merging unit 12 executes the merge processing based on the above-described reference editing state. In this case, since reference editing has not been executed in the project PJ2, priority is given to data included in the data set of the project PJ1 in which reference editing is executed for data that conflict with each other. Therefore, the merge result of the reference data merge process by the reference data merge unit 12 matches the reference edit result of the project PJ1. FIG. 31 is a diagram showing design data of the project PJ3 after execution of the reference data merging process. FIG. 32 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 31 in the DMM format. Thus, the design data similar to the project PJ1 is stored in the project DB 23 of the project PJ3, and the design data presentation unit 24 of the project PJ3 presents the design data similar to the project PJ1 to the user.

[2-3. Reference editing in project PJ2]
Subsequently, in the project PJ2, the editing execution unit 25 executes design data editing (normal editing and reference editing) as shown in FIG. FIG. 33 is a diagram showing design data after editing in the project PJ2. FIG. 34 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 33 in the DMM format.

  As shown in FIG. 33, the editing execution unit 25 of the project PJ2 adds an element data set ES21 by normal editing, and adds element data E211 to the element data set ES21. The edit execution unit 25 adds dependency relationship data R011-E211, R012-E211 and E211-E013. The edit execution unit 25 updates the element risk of the element data E013 from “5” to “1” by reference editing on the element data set ES01. The edit execution unit 25 also deletes the reference of the dependency relationship data R011-E011, R012-E013, and updates the dependency of the dependency relationship data R012-E011 from “6” to “3”.

[2-4. Reference data merge in Project PJ3]
Subsequently, the data set reference unit 11 of the project PJ3 makes reference edit contents of the reference paths PJ3-PJ1-PJ0 (requirement data set RS01 reflecting the reference edit in the project PJ1, element data set ES01, and requirement data set RS01 Dependency data with respect to the element data set ES01) is acquired (see FIGS. 11 and 23). Further, the data set reference unit 11 makes reference edit contents of the reference path PJ3-PJ2-PJ0 (requirement data set RS01, element data set ES01 reflecting the reference edit in the project PJ2, element data set RS01 and element data set) Dependency relationship data with ES01) is acquired (see FIGS. 33 and 34). Subsequently, the reference data merging unit 12 of the project PJ3 executes reference data merging of the reference edit contents of the reference paths PJ3-PJ1-PJ0 and the reference edit contents of the reference paths PJ3-PJ2-PJ0.

  The reference data merging unit 12 executes the above-described merge processing based on the reference editing state and the merge processing based on the reference update merge rule. As a result, the reference data merging unit 12 determines data to be adopted as follows for the data (element data E013, dependency data R012-E011) competing with each other between the project PJ1 and the project PJ2. That is, for the element data E013, since the reference update in the project PJ2 has priority over the reference deletion in the project PJ1, the reference data merging unit 12 displays the reference update result (element risk is “1”) in the project PJ2. adopt. For the dependency relationship data R012-E011, the reference update result (dependency “9”) of the project PJ1 is larger than the reference update result (dependency “3”) of the project PJ2, and therefore the reference data merge unit 12 Adopts the reference update result of project PJ1 based on a predetermined merge rule. FIG. 35 is a diagram showing design data of the project PJ3 after execution of the reference data merge process. FIG. 36 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 35 in a DMM format.

[2-5. Reference editing in project PJ3]
Subsequently, in the project PJ3, the editing execution unit 25 executes design data editing (normal editing and reference editing) as shown in FIG. FIG. 37 is a diagram showing design data after editing in the project PJ3. FIG. 38 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 37 in the DMM format.

  As shown in FIG. 37, the editing execution unit 25 of the project PJ3 adds an element data set ES31 by normal editing, and adds element data E311 and E312 to the element data set ES31. The edit execution unit 25 adds dependency relationship data R011-E311, R011-E312, R012-E312, R013-E311, E311-E111, and E312-E211. Also, the edit execution unit 25 updates the element risk of the element data E011 from “5” to “1” by reference editing with respect to the element data set ES01, and deletes the reference of the dependency relationship data R012-E011, R013-E011. . The edit execution unit 25 updates the element risk of the element data E111 from “5” to “1” by reference editing on the element data set ES11, and the dependency relationship data R011-E111, R012-E111, R013-E111. Delete the reference. Further, the edit execution unit 25 updates the element risk of the element data E211 from “5” to “1” by reference editing with respect to the element data set ES21, and deletes the reference of the dependency relationship data R011-E211 and R012-E211. .

  According to the design support system 1 described above, the reference data set includes the requirement data or element data included in the data set of another project and the dependency data associated with the requirement data or element data by the data set reference unit 11. Obtained as (reference data). Specifically, the reference data set is stored in the project DB 23 via the other project DB 17. Then, the edit execution unit 25 provides a reference editing (reference addition, reference update, reference deletion) function for editing the reference data set to the person in charge of design (user) of each project. As a result, the user of each project can change the design data of the other project as appropriate by reference editing when the consistency with the design of the other project is lost while proceeding with the design of the own project. It becomes possible to proceed with the design smoothly. As a result, in the design work executed by dividing into a plurality of projects, it is possible to efficiently perform matching between the projects. Each project can also be efficiently designed by referring to only the data necessary for the project among the enormous design data of the entire project.

[3. Example (stepwise refinement)]
Subsequently, an example of stepwise refinement in the case where the above-described design support system 1 is applied to the design development of an automobile will be described with reference to FIGS. 39 to 61. FIG. 39 is a diagram illustrating a reference relationship between projects in the embodiment. As shown in FIG. 39, in this embodiment, there are six projects (vehicle planning PJ, engine design PJ, fuel consumption design PJ, output design PJ, piston design PJ, and WP design PJ). Each project (PJ) includes the design support system 1 described above.

  The vehicle plan PJ designs requirement data sets RS00, RS01, RS02 and element data sets ES00, ES01, ES02. The engine design PJ refers to the requirement data sets RS01 and RS02 and the element data set ES01 from the vehicle plan PJ. The engine design PJ designs the element data set ES11 as a self-designed data set. The fuel efficiency design PJ refers to the requirement data set RS01 from the vehicle plan PJ, and refers to the element data sets ES01 and ES11 from the engine design PJ. Further, the fuel efficiency design PJ designs the requirement data set RS21 as a self-design data set. The output design PJ refers to the requirement data set RS02 from the vehicle plan PJ, and refers to the element data sets ES01 and ES11 from the engine design PJ. Further, the output design PJ designs the requirement data set RS31 as a self-designed data set.

  The piston design PJ refers to the element data sets ES01 and ES11 from the engine design PJ, refers to the requirement data sets RS01 and RS21 and the element data set ES11 from the fuel efficiency design PJ, and satisfies the requirement data sets RS02 and RS31 from the output design PJ. And the element data set ES11. The piston design PJ designs an element data set ES41 as a self-design data set. The WP design PJ refers to the element data sets ES01 and ES11 from the engine design PJ, refers to the requirement data sets RS01 and RS21 and the element data set ES11 from the fuel efficiency design PJ, and satisfies the requirement data sets RS02 and RS31 from the output design PJ. And the element data set ES11. The WP design PJ designs the element data set ES51 as a self-designed data set.

[3-1. Design by vehicle planning PJ]
First, the vehicle planning PJ executes design related to policy determination of vehicle level performance (requirements), units (elements), and which unit realizes each performance (dependency between performance and units). FIG. 40 is a diagram showing design data designed by the vehicle planning PJ. 41 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 40 in a DMM format.

  As shown in FIGS. 40 and 41, the vehicle plan PJ editing execution unit 25 receives an input operation from the user (vehicle planner) and executes the following editing. That is, the editing execution unit 25 adds the requirement data sets RS00, RS01, RS02 and the element data sets ES00, ES01, ES02 by normal editing. Then, the editing execution unit 25 adds the requirement data “vehicle request” to the requirement data set RS00, adds the requirement data “fuel consumption (importance = 5, specification risk = 4)” to the requirement data set RS01, and the requirement data The requirement data “output (importance = 3, specification risk = 4)” is added to the set RS02. The editing execution unit 25 adds the element data “vehicle” to the element data set ES00, adds the element data “engine (degree of freedom = 5, element risk = 5)” to the element data set ES01, and adds the element data set ES01. Element data “T / M (degree of freedom = 1, element risk = 5)” is added to ES02. Further, the editing execution unit 25 adds dependency data (dependency = 9) between “fuel consumption” and “engine”, between “fuel consumption” and “T / M”, and between “output” and “engine”. , Dependency data (dependency = 3) is added between “output” and “T / M”.

[3-2. Design by engine design PJ (before design)]
Subsequently, the engine design PJ receives the design result of the vehicle plan PJ and prepares for engine design. Specifically, the engine design PJ refers to a part of the design data of the vehicle plan PJ and makes preparations for adding an engine detail data set. FIG. 42 is a diagram showing design data (data set referred to from the vehicle plan PJ) before engine design. FIG. 43 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 42 in the DMM format. As shown in FIG. 42 and FIG. 43, the data set reference unit 11 of the engine design PJ has a dependency relationship associated with the requirement data sets RS01 and RS02 and the element data set ES01 of the vehicle planning PJ and the data included in the data set. Data is acquired as a reference data set.

[3-3. Design by engine design PJ (after design)]
Subsequently, the engine design PJ executes a design related to policy determination regarding details of engine parts (element identification) and which parts realize each performance (dependency between performance and engine parts). . FIG. 44 is a diagram showing design data after engine design. FIG. 45 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 44 in a DMM format.

  As shown in FIGS. 44 and 45, the engine design PJ editing execution unit 25 receives an input operation from a user (engine engineer) and executes the following editing. That is, the edit execution unit 25 adds an element data set (engine detail data set) ES11 by normal editing, and adds element data “piston”, “cylinder block”, “intake valve”, “EGR” to the element data set ES11. "," Camshaft ", and" Mecha WP "are added. Further, the editing execution unit 25 adds dependency data between the requirement data “fuel consumption” and each element data, and removes the requirement data “output”, “EGR”, and “mechanism WP”. Add dependency data between and.

  In addition, the editing execution unit 25 references and deletes the dependency relationship data between “fuel consumption” and “engine” and between “output” and “engine”. In other words, the user determines that the requirement data “fuel consumption” and the direct dependency data from “output” to “engine” are no longer necessary after the definition of the element data set ES31 that details the engine parts is completed. Then, the reference deletion is executed via the editing execution unit 25. In addition, the element risk of “engine” is updated from “5” to “4” by the editing execution unit 25. In other words, the user determines that the element risk for the “engine” has decreased due to the detailed design of the engine component, and executes the reference update via the editing execution unit 25.

[3-3. Design by fuel efficiency design PJ (before design)]
Subsequently, the fuel efficiency design PJ receives the design results of the vehicle plan PJ and the engine design PJ and prepares for the fuel efficiency design. Specifically, the fuel efficiency design PJ refers to a part of the design data of the vehicle plan PJ and the engine design PJ, and prepares to add a detailed fuel efficiency data set. FIG. 46 is a diagram showing design data (a data set referred to from the vehicle plan PJ and the engine design PJ) before the fuel efficiency design. FIG. 47 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 46 in a DMM format. As shown in FIGS. 46 and 47, the fuel efficiency design PJ data set reference unit 11 is included in the vehicle planning PJ requirement data set RS01, the engine design PJ element data sets ES01 and ES11, and these data sets. Dependency data associated with data is acquired as a reference data set.

  Subsequently, the reference data merging unit 12 of the fuel efficiency design PJ performs a reference data merging process on data competing between the reference data set referenced from the vehicle plan PJ and the reference data set referenced from the engine design PJ. Run. Specifically, dependency data between “fuel consumption” and “engine” is linked to “fuel consumption” in the requirement data set RS01 of the vehicle plan PJ. On the other hand, the dependency data between “fuel efficiency” and “engine” is not linked to “engine” in the element data set ES01 of the engine design PJ (reference is deleted). That is, the dependency data between “fuel consumption” and “engine” is competing between the reference data set referenced from the vehicle plan PJ and the reference data set referenced from the engine design PJ. Here, as an example, the reference data merging unit 12 performs the reference editing result (reference deletion) of the engine design PJ having the smaller path cost of the reference path from the fuel efficiency design PJ by the merge process based on the path cost of the reference path described above. Has priority.

[3-4. Design by fuel efficiency design PJ (after design)]
Subsequently, the fuel efficiency design PJ refines the fuel efficiency characteristics (determines the requirements), assigns the function of each characteristic (sets the target value for the requirements), and which part realizes each characteristic (characteristics and engine parts) Execute the design for policy decisions on the dependencies between the two. FIG. 48 is a diagram showing design data after the fuel efficiency design. 49 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 48 in a DMM format.

  As shown in FIGS. 48 and 49, the edit execution unit 25 of the fuel efficiency design PJ receives an input operation from the user (fuel efficiency designer) and executes the following editing. That is, the editing execution unit 25 adds a requirement data set (detailed fuel consumption data set) RS21 by normal editing, and adds requirement data “friction”, “air-fuel ratio”, “pump loss”, and “pump loss” to the requirement data set RS21. Add “cooling loss”. The editing execution unit 25 defines “wear loss: 3 [Nm]” as the target value of “friction” and “cooling loss: 5 [Nm]” as the target value of “cooling loss”. That is, the fuel efficiency is embodied as the target values of “friction” and “cooling loss”. Further, the editing execution unit 25 adds dependency relationship data between each requirement data in the requirement data set RS21 and each element data in the element data set ES11.

  In addition, the dependency execution data between “fuel consumption” and each element data in the element data set ES11 is deleted by reference by the editing execution unit 25. In other words, the user determines that the direct dependency data from “fuel consumption” to each element data in the element data set ES11 is no longer necessary after the definition of the requirement data set RS21 that details the fuel efficiency performance is completed. Then, the reference deletion is executed via the editing execution unit 25. Further, the editing execution unit 25 updates the specification risk of “fuel consumption” from “4” to “3”. In other words, the user determines that the design of the fuel efficiency performance has been refined so that the achievement of the fuel efficiency performance has been achieved, and executes the reference update via the editing execution unit 25.

  In addition, the element execution risk of “piston” is updated from “5” to “3” by the editing execution unit 25. This is due to the following reasons, for example. That is, by referring to the table in the DMM format shown in FIG. 49, the user grasps that the element having the greatest influence (high dependency) on the “friction” performance is “piston”. As a result, the user can consider a method of reducing the wear loss by reducing the weight of the piston, for example, in order to achieve the target value of “friction” (wear loss: 3 [Nm]). Then, as a result of such examination, the user determines that the piston realization policy has been materialized, and changes the element risk of “piston” from “5” to “3” via the editing execution unit 25. Update reference.

  Further, the element execution risk of “Mechanical WP” is updated from “5” to “3” by the editing execution unit 25. This is due to the following reasons, for example. That is, by referring to the table in the DMM format shown in FIG. 49, the user grasps that the element having the greatest influence (high dependency) on the “cooling loss” performance is “mechanism WP”. Accordingly, the user should consider a method of suppressing the cooling loss by adjusting the flow rate of the cooling water with, for example, the mechanical WP in order to achieve the target value of “cooling loss” (cooling loss: 5 [Nm]). Can do. Then, as a result of proceeding with such studies, the user determines that the realization policy plan of the mechanical WP has been materialized, and the element risk of “mechanical WP” is changed from “5” to “3” via the editing execution unit 25. Update reference.

[3-5. Design by output design PJ (before design)]
Subsequently, the output design PJ receives the design results of the vehicle plan PJ and the engine design PJ and prepares for the output design. Specifically, the output design PJ refers to a part of the design data of the vehicle plan PJ and the engine design PJ, and prepares to add the output detailed data set. FIG. 50 is a diagram illustrating design data (data set referred to from the vehicle plan PJ and the engine design PJ) before the output design. FIG. 51 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 50 in the DMM format. As shown in FIGS. 50 and 51, the output design PJ data set reference unit 11 is included in the vehicle planning PJ requirement data set RS02, the engine design PJ element data sets ES01 and ES11, and these data sets. Dependency data associated with data is acquired as a reference data set.

  Subsequently, the reference data merging unit 12 of the output design PJ performs a reference data merging process on data competing between the reference data set referenced from the vehicle plan PJ and the reference data set referenced from the engine design PJ. Run. Specifically, dependency data between “output” and “engine” is linked to “output” of the requirement data set RS02 of the vehicle plan PJ. On the other hand, dependency data between “output” and “engine” is not linked to “engine” of the element data set ES01 of the engine design PJ (reference is deleted). That is, with respect to the dependency relationship data between “output” and “engine”, there is a competition between the reference data set referenced from the vehicle plan PJ and the reference data set referenced from the engine design PJ. Here, as an example, the reference data merging unit 12 performs the reference editing result (reference deletion) of the engine design PJ having the smaller path cost of the reference path from the output design PJ by the merge process based on the path cost of the reference path described above. Has priority.

[3-6. Design by output design PJ (after design)]
Subsequently, the output design PJ refines the output characteristics (identifies requirements), assigns the functions of each characteristic (sets target values for the requirements), and which part realizes each characteristic (characteristics and engine parts) Execute the design for policy decisions on the dependencies between the two. FIG. 52 is a diagram showing design data after output design. FIG. 53 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 52 in the DMM format.

  As shown in FIG. 52 and FIG. 53, the edit execution unit 25 of the output design PJ accepts an input operation from the user (output designer) and executes the following editing. That is, the editing execution unit 25 adds the requirement data set (output detailed data set) RS31 by normal editing, and adds the requirement data “compression ratio”, “volume efficiency”, and “ignition timing” to the requirement data set RS31. to add. The editing execution unit 25 defines “actual compression ratio: 12” as the target value of “compression ratio”. That is, the output performance is realized as a target value of the “compression ratio”. Further, the editing execution unit 25 adds dependency relationship data between each requirement data in the requirement data set RS31 and each element data in the element data set ES11.

  In addition, the edit execution unit 25 references and deletes the dependency relationship data between “output” and each element data in the element data set ES11. In other words, the user determines that the dependency data directly from the “output” to each element data in the element data set ES11 is no longer necessary because the definition of the requirement data set RS31 that details the output performance is completed. Then, the reference deletion is executed via the editing execution unit 25. Further, the editing execution unit 25 updates the reference risk of “output” from “4” to “3”. In other words, the user determines that the design of the output performance has been refined and thus the target of achieving the output performance has been achieved, and executes the reference update via the editing execution unit 25.

  In addition, the element execution risk of “camshaft” is updated from “5” to “3” by the editing execution unit 25. This is due to the following reasons, for example. That is, by referring to the table in the DMM format shown in FIG. 53, the user grasps that the element having a large influence (high dependency) on the “compression ratio” performance is “camshaft”. Thereby, in order to achieve the target value (actual compression ratio: 12) of the “compression ratio”, the user can consider a method of taking in a lot of air by increasing the working angle of the camshaft, for example. Then, as a result of such examination, the user determines that the camshaft realization policy has been materialized, and changes the element risk of “camshaft” from “5” to “3” via the editing execution unit 25. Update reference.

[3-7. Design by piston design PJ (before design)]
Subsequently, the piston design PJ receives the design results of the engine design PJ, the fuel consumption design PJ, and the output design PJ, and prepares for the piston design. Specifically, the piston design PJ refers to a part of the design data of the engine design PJ, the fuel efficiency design PJ, and the output design PJ, and prepares to add a piston detailed data set. FIG. 54 is a diagram showing design data (a data set referred to from the engine design PJ, the fuel efficiency design PJ, and the output design PJ) before the piston design. FIG. 55 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 54 in the DMM format. As shown in FIGS. 54 and 55, the data set reference unit 11 of the piston design PJ includes the element data sets ES01 and ES11 of the engine design PJ, the requirement data sets RS01 and RS21 of the fuel efficiency design PJ, and the element data set ES11. The requirement data sets RS02 and RS31 and the element data set ES11 of the output design PJ and the dependency data associated with the data included in these data sets are acquired as reference data sets.

  Subsequently, the reference data merging unit 12 of the piston design PJ performs a reference data merge process on data included in the element data set ES11 that competes between the engine design PJ, the fuel efficiency design PJ, and the output design PJ (see FIG. 54 and FIG. 55).

[3-8. Design by piston design PJ (after design)]
Next, the piston design PJ is designed to determine the specific method for the details of the piston specifications (element identification) and which part specifications to realize each characteristic (dependency between characteristics and piston specifications). Execute. FIG. 56 is a diagram showing design data after piston design. FIG. 57 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 56 in a DMM format.

  As shown in FIGS. 56 and 57, the edit execution unit 25 of the piston design PJ receives an input operation from the user (piston designer) and executes the following edit. That is, the editing execution unit 25 adds an element data set (piston detail data set) ES41 by normal editing, and adds element data “weight”, “crown shape”, “coating”, “strength” to the element data set ES41. ”,“ Surface treatment ”, and“ Material ”are added. Further, the user considers both the fuel efficiency performance (the target value of friction “wear loss: 3 [Nm]”) and the output performance (the target value of compression ratio “actual compression ratio: 12”). A design study is conducted. As a result, the editing execution unit 25 defines “weight: 270 [g]” as the design value of “weight” and defines “safety factor: 0.9” as the design value of “strength”. In other words, the fuel efficiency performance and the output performance realization method are embodied as design values of “weight” and “strength” of the piston. Further, the editing execution unit 25 adds dependency relationship data between each requirement data in the requirement data sets RS21 and RS31 and each element data in the element data set ES41.

  In addition, the dependency execution data between the requirement data in the requirement data sets RS21 and RS31 and the “piston” is deleted by reference by the editing execution unit 25. In other words, the user determines that the dependency data directly from the “piston” to the respective requirement data in the requirement data sets RS21 and RS31 is no longer necessary after the definition of the requirement data set RS41 in which the piston is detailed is completed. Then, the reference deletion is executed via the editing execution unit 25. Further, the element execution risk of “piston” is updated from “3” to “1” by the editing execution unit 25. In other words, the user determines that the detailed piston design has been completed, and executes the reference update via the editing execution unit 25.

  In addition, the editing execution unit 25 updates the specification risk of “friction” from “3” to “1”. This is due to the following reasons, for example. That is, by referring to the table in the DMM format shown in FIG. 57, the user grasps that the element having a large influence (high dependency) on the “friction” performance is “weight”. Accordingly, the user can consider a method of reducing the piston, for example, in order to achieve the target value of “friction” (friction loss: 3 [Nm]). Then, as a result of such examination, the user determines that the target of achieving the target value of friction has been achieved, and the specification risk of “friction” is changed from “3” to “1” via the editing execution unit 25. Update reference.

  Further, the edit execution unit 25 updates the target value of “compression ratio” from “12” to “10”. This is due to the following reasons, for example. As described above, by reducing the piston in order to achieve the target value of “friction”, the strength of the piston was reduced to “safety factor: 0.9”. As a result, the compression ratio target value (actual compression ratio: 12) cannot be satisfied. Therefore, as a compromise, the user updates the reference value of “compression ratio” to “actual compression ratio: 10” via the editing execution unit 25. Further, since the target value of the compression ratio is corrected downward, the editing execution unit 25 updates the specification risk of “compression ratio” from “3” to “4”.

[3-9. Design by WP design PJ (before design)]
Subsequently, the WP design PJ prepares for the WP design based on the design results of the engine design PJ, the fuel efficiency design PJ, and the output design PJ. Specifically, the WP design PJ refers to a part of design data of the engine design PJ, the fuel efficiency design PJ, and the output design PJ, and prepares to add a WP detailed data set. FIG. 58 is a diagram showing design data before WP design (data set referred to from engine design PJ, fuel consumption design PJ, and output design PJ). FIG. 59 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 58 in the DMM format. As shown in FIGS. 58 and 59, the data set reference unit 11 of the WP design PJ includes the element data sets ES01 and ES11 of the engine design PJ, the requirement data sets RS01 and RS21 of the fuel efficiency design PJ, and the element data set ES11. The requirement data sets RS02 and RS31 and the element data set ES11 of the output design PJ and the dependency data associated with the data included in these data sets are acquired as reference data sets.

  Subsequently, the reference data merging unit 12 of the WP design PJ performs a reference data merge process on data included in the element data set ES11 that competes between the engine design PJ, the fuel efficiency design PJ, and the output design PJ (see FIG. 58 and FIG. 59).

[3-10. Design by WP design PJ (after design)]
Subsequently, the WP design PJ is a design related to a specific method for determining the details of the WP specifications (element identification) and the component specifications that realize each characteristic (dependency between the characteristics and the WP specification). Execute. FIG. 60 is a diagram showing design data after WP design. 61 is a diagram showing dependency relationship data between requirement / element data in the design data shown in FIG. 60 in a DMM format.

  Here, as an example, a WP design PJ user (WP designer) performs a WP design study to achieve fuel efficiency (cooling loss: 5 [Nm]). As a result, it is determined that the WP is changed from “mechanical WP” to “electric WP”. That is, as shown in FIGS. 60 and 61, the editing execution unit 25 of the WP design PJ references and deletes the element data “mechanical WP” included in the element data set ES11 that is the reference data set, and also the element data set ES11. The new element data “electric WP” is added to the reference.

  Further, the edit execution unit 25 adds an element data set (WP detailed data set) ES51 by normal editing, and adds element data “flow rate”, “power consumption”, and “shape” to the element data set ES51. . In addition, the user considers the design of the “electric WP” in consideration of the fuel efficiency (the target value of cooling loss “cooling loss: 5 [Nm]”). As a result, the editing execution unit 25 defines “flow rate: 100 [L / min]” as the design value of “flow rate” of the electric WP. That is, the fuel efficiency performance realizing method is embodied as a design value of the “flow rate” of the electric WP. Further, the editing execution unit 25 adds dependency relationship data between each requirement data in the requirement data sets RS21 and RS31 and each element data in the element data set ES51.

  Further, the editing execution unit 25 updates the specification risk of “cooling loss” from “3” to “1”. As described above, in order to achieve the “cooling loss” target, the mechanism WP is changed to the electric WP, and the flow rate of the mechanism WP is reduced to 100 L / min to suppress heat transfer to the cooling water. It was because it was examined. In other words, as a result of such examination, the user determines that the target value of the cooling loss has been achieved, and the specification risk of “cooling loss” is changed from “3” to “1” via the editing execution unit 25. Update reference. In addition, the element risk of “electric WP” is updated from “3” to “1” by normal editing by the editing execution unit 25. In other words, the user determines that the detailed configuration of the electric WP has been completed, and executes the reference update and the update by the normal edit via the edit execution unit 25.

  Subsequently, an operation related to stepwise refinement of the design support system 1 (an operation including a design support method according to an embodiment) will be described with reference to FIG. FIG. 62 is a diagram showing a flow in a case where a reference edit is executed after a data set of another project designated as a reference destination is acquired as a reference data set, and finally a process of canceling the reference edit is executed. is there. First, the data set reference unit 11 acquires a data set of another project designated as a reference destination by the data set reference instruction unit 21 of the information processing terminal 20 as a reference data set (step S101, reference data acquisition step). .

  Subsequently, the plurality of reference data sets acquired by the data set reference unit 11 includes first data and second data that compete with each other for the same requirement data, element data, or dependency relationship data. In this case, the reference data merging unit 12 executes the above-described reference data merging process and determines a design value to be adopted (step S102, reference data merging step).

  Subsequently, the reference data set acquired by the data set reference unit 11 is stored in the project DB 23 via the other project DB 17 (step S103, design data storage processing step). Here, when the reference data merging process is executed by the reference data merging unit 12 in step S102, the project DB 23 acquires and stores the merge result with reference edit from the merge result DB 15 with reference edit. As a result, the reference data set reflecting the merge result of the reference data merging process and the reference edit in the own project is stored in the project DB 23.

  Subsequently, the reference data set stored in the project DB 23 is presented to the user by the design data presentation unit 24 (step S104, design data presentation step). Subsequently, the editing execution unit 25 executes reference editing for editing the reference data set stored in the project DB 23 in accordance with an input operation from the user (step S105, editing execution step). Subsequently, the reference editing canceling unit 27 executes a process of canceling the reference editing for the specified requirement data, element data, or dependency relationship data (cancellation target data) by using an input operation by the user as a trigger (step S106). , Reference edit undo step).

  Subsequently, a design support program according to an embodiment will be described with reference to FIG. FIG. 63 is a block diagram showing a functional configuration (module configuration) of the design support program P1. The design support program P1 is a program for causing a computer system to function as the design support system 1. In particular, the design support program P1 is a program for causing a computer system to function as the design support system 1 (see FIG. 2) having a function related to stepwise refinement. As shown in FIG. 63, the design support program P1 includes a reference data acquisition module P11, a reference data merge module P12, a design data storage module P13, a design data presentation module P14, an edit execution module P15, and a reference edit cancellation module P16. . The functions realized by executing the reference data acquisition module P11, the reference data merge module P12, the design data storage module P13, the design data presentation module P14, the edit execution module P15, and the reference edit cancellation module P16 are described above. The functions of the data set reference unit 11, the reference data merge unit 12, the project DB 23, the design data presentation unit 24, the edit execution unit 25, and the reference edit cancellation unit 27 of the design support system 1 are the same.

  The design support program P1 is stored in a recording medium such as a CD-ROM and a DVD, and is executed by a computer system used as the design support system 1. Specifically, each device (the information processing server 10 and the information processing terminal 20) configuring the computer system includes a recording medium reading unit such as a CD-ROM drive and a DVD drive. When the recording medium is set in the recording medium reading unit, each device can access the design support program P1 stored in the recording medium from the recording medium reading unit. The computer system can be operated as the design support system 1 by causing each device to execute the design support program P1. The design support program P1 may be provided via a network as a data signal superimposed on a carrier wave.

[Reference Summary]
Next, the function of the reference summary will be described. In addition, about the content which overlaps with the description content regarding the above-mentioned stepwise refinement, description is abbreviate | omitted suitably. FIG. 64 is a block diagram showing a functional configuration related to the reference summary of the design support system 1 according to the present embodiment. As shown in FIG. 64, the information processing server 10 includes a design data acquisition unit 111, a summary target data set extraction unit 112, a summary execution unit 113, a reference summary comparison unit 114, and its own project DB 16 as functional elements related to the reference summary. I have. The information processing terminal 20 includes a reference summary instruction unit 121, a reference summary comparison result DB 122, a reference summary reflection unit 123, a reference summary matching unit 124, a project DB 23, and a design data presentation unit 24 as functional elements related to the reference summary. ing.

  Hereinafter, each function regarding the reference summary of the design support system 1 will be described. For convenience of explanation, it is assumed that the information processing server 10 and the information processing terminal 20 illustrated in FIG. 64 are the information processing server 10 and the information processing terminal 20 of the project PJ0 illustrated in FIG. In the following description, a case is considered in which the design contents of projects PJ1 and PJ2, which are lower-level projects than project PJ0, are summarized to the same design granularity as project PJ0. As another case, a case where the design contents of the project PJ3 are summarized to the same design granularity as that of the project PJ0 is considered.

  Here, “design granularity” indicates a combination (number and type) of data sets included in the design data. That is, “the design granularity is the same” means that the combination of data sets included in the design data is the same. The project that is the target of the summary process is called “summary source project”. On the other hand, a project to be compared with a summary result (summary result) of a summary source project is referred to as a “summary destination project”. In the above case, project PJ0 is the summary destination project, and projects PJ1, PJ2, and PJ3 are summary source projects. Further, the design granularity of the summary destination project is the design granularity that is a target when the summary source project is summarized.

  The reference summary instruction unit 121 is a functional element that accepts a user operation for designating a summary source project by the user of the project PJ0 and notifies the design data acquisition unit 111 of the designated summary source project. Here, as an example, it is assumed that projects PJ1 and PJ2 are designated as the summary source project. Further, the reference summary instruction unit 121 acquires design data of the project PJ0 stored in the project DB 23 and transmits the design data to the design data acquisition unit 111.

  The design data acquisition unit 111 is a functional element that acquires design data (first design data) of the summary destination project PJ0 and design data (second design data) of the summary source projects PJ1 and PJ2. Specifically, the design data acquisition unit 111 acquires design data of the summary destination project PJ0 from the reference summary instruction unit 121. Further, the design data acquisition unit 111 can identify the summary source projects PJ1 and PJ2 based on the notification from the reference summary instruction unit 121. Then, the design data acquisition unit 111 acquires the design data of the summary source projects PJ1, PJ2, for example, by accessing the information processing server 10 of the summary source projects PJ1, PJ2.

  Here, the design data stored on the information processing server 10 of the summary source projects PJ1 and PJ2 may be different from the latest design data. For example, in the information processing terminal 20 of each project PJ1, PJ2, there is a possibility that the user of each project PJ1, PJ2 is editing the design data stored in the project DB 23 via the editing execution unit 25. In this case, the design data reflecting the latest editing (normal editing or reference editing) is stored only in the project DB 23, and the database (with reference editing) of the information processing server 10 is updated until the update by the updating unit 26 is executed. The merge result DB 15 and the own project DB 16) are not stored.

  Therefore, the design data acquisition unit 111 confirms that the editing at the information processing terminal 20 has been completed in the summary source projects PJ1 and PJ2, and the latest design data is stored in the database of the information processing server 10. May be. Then, the design data acquisition unit 111 suspends the design data acquisition process of the summary source projects PJ1 and PJ2 until the confirmation is completed. , PJ2 design data may be acquired. For example, the design data acquisition unit 111 may perform the above confirmation by referring to the reference mode setting stored in the own project DB 16 of the information processing server 10 of the summary source projects PJ1 and PJ2. Specifically, if the reference mode setting of the summary source projects PJ1 and PJ2 is “reference mode”, the design data acquisition unit 111 has completed reference editing by the information processing terminal 20 of the summary source projects PJ1 and PJ2. The update unit 26 may determine that the update (data synchronization) has been completed.

  The summary target data set extraction unit 112 is a functional element that extracts, as a summary target data set, a data set that is commonly included in the design data of the summary destination project PJ0 and the design data of the summary source projects PJ1 and PJ2. Here, the projects PJ1 and PJ2 both refer to the requirement data set RS01 and the element data set ES01 of the project PJ0 (see FIGS. 11 and 33). That is, the requirement data set RS01 and the element data set ES01 are data sets that are commonly included in the projects PJ0 to PJ2. Therefore, the summary target data set extraction unit 112 extracts the requirement data set RS01 and the element data set ES01 as summary target data.

  The summary execution unit 113 selects data sets other than the summary target data sets (requirement data set RS01 and element data set ES01) extracted by the summary target data set extraction unit 112 based on the design data of the summary source projects PJ1 and PJ2. This is a functional element that generates a summary result (third design data) that is not included. Here, the summary source project PJ1 includes an element data set ES11 in addition to the summary target data set (see FIG. 11). The summary source project PJ2 includes an element data set ES21 in addition to the summary target data set (see FIG. 33). Therefore, the summary execution unit 113 generates a summary result that does not include the element data sets ES11 and ES21 based on the design data of the summary source projects PJ1 and PJ2 by the process described below.

(First example)
When there are a plurality of summary source projects (two projects PJ1 and PJ2 as an example in this embodiment), the summary execution unit 113 may generate a summary result as follows. That is, the summary execution unit 113 converts each design data of the plurality of summary source projects PJ1 and PJ2 into one merge data (fourth design data) based on a predetermined rule. Here, the “predetermined rules” are, for example, various rules in the reference data merging process described above. That is, the “predetermined rule” here means “merge process based on path cost of reference path”, “merge process based on reference edit state”, “merge process based on merge rule of reference update”, etc. It is a rule in the merge process. By the above conversion process, merge data having a data structure as shown in FIG. 35 is obtained.

  Then, the summary execution unit 113 detects two item data (requirement data or element data) included in the summary target data sets RS01 and ES01 for the obtained merge data. Specifically, the summary execution unit 113 includes a plurality of pieces of dependency data R011 associated with item data (element data E111 as an example) included in the data sets ES11 and ES21 other than the summary target data sets RS01 and ES01. -Two item data linked through E111 and E111-E012 (here, as an example, requirement data R011 and element data E012) are detected. Then, the summary execution unit 113 generates one dependency relationship data R011-E012 indicating the dependency relationship between the requirement data R011 and the element data E012 from the plurality of dependency relationship data R011-E111, E111-E012. The summary executing unit 113 executes such processing (summary of dependency relationship data) for all combinations of two detected item data. Then, the summary execution unit 113 may generate a summary result by deleting the data sets ES11 and ES21 other than the summary target data set. Here, the element data included in the data sets ES11 and ES21 and the dependency relationship data associated with the element data are deleted along with the deletion of the data sets ES11 and ES21.

  FIG. 65 is a diagram for explaining the summary of the dependency relationship data. Fig.65 (a) is a figure which shows the example in the case of summarizing serial dependence data. In FIG. 65A, requirement data A and element data X are item data included in the summary target data set. On the other hand, the requirement data a and the element data x are item data included in a data set other than the summary target data set. In this case, the summary execution unit 113 performs one dependency from a plurality of (here, three as an example) dependency data Aa, ax, and XX by the above-described processing (summary of dependency relationship data). The relation data AX is generated.

The related information (dependency, etc.) of the newly generated dependency relationship data AX is set according to a predetermined rule. For example, when serial dependency data is summarized, the dependency of the dependency data A-X is any of the dependency data A-a, a-x, and XX according to the following priorities. The degree of dependency is set. Here, the priority is assumed to be higher in the order of priority 1, priority 2, and priority 3. In other words, if any of the dependency data Aa, ax, and XX cannot be determined by the priority 1 rule, the priority 2 rule is applied. The If the dependency cannot be determined even with the priority 2 rule, the priority 3 rule is applied.
Priority 1: Dependency data of dependency data having the smallest degree of dependency taking into consideration confidence level Priority 2: Dependency data of dependency data having the smallest degree of dependency priority 3: Dependency data having the highest degree of confidence Dependency of

  The “degree of dependency taking into consideration the degree of confidence” is a value obtained by a predetermined calculation based on the degree of dependence and the degree of confidence. For example, it is a value calculated so that the dependency degree of the dependency relationship data having a relatively high confidence level can be easily adopted. Here, it is assumed that the confidence levels of the dependency relationship data Aa, ax, and xX shown in FIG. In this case, since the relative magnitude of the confidence level is the same among the dependency relationship data A-a, a-x, and XX, the rule of priority 1 is the same as the rule of priority 2. Then, according to the priority level 1 rule, the dependency level of the dependency relationship data A-X is set to the dependency level “3” of the dependency relationship data A-a having the minimum dependency level. However, the above-mentioned rule is only an example, and other values may be set as the dependency degree of the dependency relationship data AX. For example, an average value of all the dependency relationship data Aa, ax, and XX may be set as the dependency degree of the dependency relationship data AX.

  FIG. 65B is a diagram showing an example in the case of summarizing parallel dependency data. As shown in FIG. 65B, when there are a plurality of parallel paths between the requirement data A and the element data X, first, the above-described serial dependency data summary rule is applied to each path. Is done. In this example, between the requirement data A and the requirement data X, a path formed by the dependency relationship data A-a, a-x, x-X, and the dependency relationship data A-b, by, y-X. And a path formed by. Here, it is assumed that the confidence levels of the dependency relationship data A-a, a-x, xx, Ab, yy, and y-X are the same. In this case, from the dependency relationship data A-a, a-x, and XX, the dependency rate of the dependency relationship data A-a having the minimum dependency level is adopted, and the dependency relationship data A- having the dependency level “3” is adopted. X is generated. Further, from the dependency relationship data A-b, by, y-X, the dependency rate of the dependency relationship data by having the minimum dependency level is adopted, and the dependency relationship data AX having the dependency level “6” is adopted. Is generated. With the above processing, two pieces of parallel dependency data AX are generated.

Subsequently, a summary of the two parallel dependency data AX is executed. For example, when summarizing parallel dependency data, the dependency of the dependency data AX is set to one of the two dependency data AX according to the following priorities. Is done.
Priority 1: Dependency data of dependency data having the highest degree of dependency taking into consideration confidence level Priority 2: Dependency data of dependency data having the highest degree of dependency priority 3: Dependency data having the lowest degree of confidence Dependency of

  In the example shown in FIG. 65 (b), since there is no difference in the degree of confidence between the two parallel dependency data AX, the rule of priority 1 is the same as the rule of priority 2. Then, according to the rule of priority 1, the dependency of the dependency relationship data AX is the dependency of the dependency relationship data AX (the dependency data on the lower side of FIG. 65B) having the maximum dependency. Set to “6”. However, the above-mentioned rule is only an example, and other values may be set as the dependency degree of the dependency relationship data AX. For example, the average value of the two dependency relationship data AX in parallel may be set as the dependency degree of the dependency relationship data AX. For example, a summary rule for an attribute other than the dependency degree may be separately determined according to the attribute. In addition, for attributes for which no summary rule is defined as described above, all the values of the dependency relationship data as a summary source may be summarized so as to be referable.

(Second example)
Further, when there are a plurality of summary source projects (in this embodiment, two of PJ1 and PJ2 as an example), the summary execution unit 113 may perform processing opposite to that in the first example. That is, the summary execution unit 113 first depends on the combinations of all the detected two item data for each of the summary source projects PJ1 and PJ2, as in the method shown in the first example. Perform a summary of relational data. Then, the summary execution unit 113 generates a plurality of design data (fifth design data) obtained by the summary of the dependency relationship data for each of the summary source projects PJ1 and PJ2, based on the various rules in the reference data merge process described above. A summary result may be generated by converting into one merge data (summary result).

  As shown in the first example and the second example, the design support system 1 includes the summary execution unit 113, so that there are a plurality of summary source projects (PJ1 and PJ2 as an example in the present embodiment). Therefore, the summary result based on the design contents of the plurality of summary source projects PJ1 and PJ2 having a common data set configuration with the design data of the summary destination project PJ0 is generated efficiently and appropriately. As a result, for example, by comparing the design data of the summary destination project PJ0 and the summary result, it is possible to easily grasp the difference between the design contents of the summary destination project PJ0 and the design contents of the plurality of summary source projects PJ1 and PJ2. It becomes possible. Therefore, it is possible to efficiently perform the reconciliation between the summary destination project PJ0 and the plurality of summary source projects PJ1 and PJ2.

(Third example)
Further, if there is only one summary source project (for example, project PJ3 shown in FIG. 30), the summary execution unit 113 shows the design data of the summary source project PJ3 in the above first example. Similar to the above-described method, a summary result can be generated by executing a summary of the dependency relationship data for the combination of all the detected two item data. This makes it possible to efficiently and appropriately generate design data for the summary source project PJ3 having a common data set configuration with the design data for the summary destination project PJ0.

  The first to third examples are merely examples of processing for generating a summary result by the summary execution unit 113. For example, when there are a plurality of summary source projects, the summary execution unit 113 executes the reference data merging process after executing the above-described summary of the dependency relationship data on a part of the design data, and again performs these processes. The summary result may be generated by an iterative (trial and error) technique such as repeatedly executing. When the summary execution unit 113 generates a summary result by the procedure shown in the first to third examples described above or other procedures, the reference summary comparison unit 114 stores the design data of the summary destination project PJ0 and the summary result. Output to.

  The reference summary comparison unit (comparison unit) 114 is a functional element that outputs a result (comparison result data) of comparing the design data of the summary destination project PJ0 and the summary result (here, the summary result of the project PJ3). Specifically, the reference summary comparison unit 114 acquires the design data and summary result of the summary destination project PJ0 input from the summary execution unit 113. Then, as shown in FIG. 66, the reference summary comparison unit 114 compares each design data of the summary destination project PJ0 with the summary result by comparing the design data of the summary destination project PJ0 with the summary result ( Comparison result data indicating a difference between requirement data, element data, and dependency relationship data) is generated.

  More specifically, the reference summary comparison unit 114 includes the presence / absence of data included only in one of the design data and the summary result of the summary destination project PJ0, and the design values of the data included in common (for example, specification risk, element The presence / absence of a difference in risk and dependency level attribute values is determined. As a result, the reference summary comparison unit 114 uses, as difference result data, data that is laid out so that the difference portion is conspicuous, for example, as shown in FIGS. May be generated as Further, the reference summary comparison unit 114 may simply generate, as difference result data, text data or the like in which information on the difference portion is described in a list format.

  The reference summary comparison unit 114 outputs the generated comparison result data to the own project DB 16 and the reference summary comparison result DB 122. The own project DB 16 stores the revision number of the design data of the project PJ0 when the comparison by the reference summary comparison unit 114 is executed together with the comparison result data. As a result, the comparison result for each revision of the design data of the project PJ0 is stored in the history format in the own project DB 16, and the user of the project PJ0 can later confirm the comparison result.

  The reference summary comparison result DB 122 is a functional element that temporarily stores comparison result data. The comparison result data stored in the reference summary comparison result DB 122 is referred to when the design data presentation unit 24 presents the comparison result data to the user, or when the reference summary reflection unit 123 executes processing to be described later.

  The reference summary reflecting unit (reflecting unit) 123 is a functional element that updates (reflects) the design data stored in the project DB 23 of the summary destination project PJ0 to the same design data as the summary result based on the comparison result data. is there. According to the above-described processing by the reference summary reflection unit 123, the design content of the summary destination project PJ0 can be matched with the design content of the summary source project. As a result, design matching between the summary destination project PJ0 and the summary source project is automated, and the efficiency of design work can be improved. Further, the reference summary reflecting unit 123 may reflect only a part of the data (requirement data, element data, or dependency data) designated by the user among the summary results in the design data of the project PJ0. For example, the user of the project PJ0 refers to the comparison result data presented by the design data presentation unit 24, and selects the part to be changed to the same data as the summary result. Then, the reference summary reflection unit 123 changes only the data selected by the user to the same design data as the summary result.

  The reference summary matching unit (matching unit) 124 sends notification information indicating that the design data of the summary destination project PJ0 has been updated to the same design data as the summary result by the reference summary reflection unit 123, and the design data of the summary destination project PJ0. It is a functional element that notifies all projects that have design data generated based on Specifically, the reference summary matching unit 124 refers to a project (in the example illustrated in FIG. 30, projects PJ1 to PJ1) that refer to design data of the summary destination project PJ0 (or design data generated by referring to and editing the design data). PJ3) is notified.

  More specifically, the reference summary matching unit 124, for each project PJ1 to PJ3, has been changed to the same design data as the summary result by the reference summary reflecting unit 123 (requirement data, element data, or dependency relationship). With respect to (data), it may be instructed to execute a reference data merge process for a reference data set after executing a cancel process for canceling reference editing. Thereby, in each project PJ1 to PJ3 of the notification destination, the cancellation process by the reference edit cancellation unit 27 is executed, and the processes by the data set reference unit 11, the reference data merge unit 12, and the data synchronization unit 13 are executed. As a result, the latest design data in which the reflection by the reference summary reflection unit 123 in the summary destination project PJ0 is considered is stored in the project DB 23 of each of the notification destination projects PJ1 to PJ3.

  By such processing of the reference summary matching unit 124, the notified project PJ1 to PJ3 side reflects the latest design data of the summary destination project PJ0 in the design data of the own project (cancellation of the reference editing described above) Processing and reference data merge processing) can be executed smoothly. As a result, the users of the projects PJ1 to PJ3 can grasp that the design data (parts changed by reference editing) of the lower project is reflected (approved) in the upper project PJ0.

  According to the design support system 1 described above, a common data set is extracted as a summary target data set between the design data of the summary destination project PJ0 and the design data of the summary source project (for example, projects PJ1 and PJ2). Then, based on the design data of the summary source project, a summary result that does not include a data set other than the summary target data set is generated. That is, it is possible to obtain a summary result in which the data set configuration is the same as the design data of the summary destination project PJ0 and the design granularity is equal to the design granularity of the design data of the summary destination project PJ0. That is, a summary result suitable for comparison with the design data of the summary destination project PJ0 can be obtained. As a result, for example, by comparing the design data of the summary destination project PJ0 and the summary result, it is possible to easily grasp the difference between the design contents of the summary destination project PJ0 and the design contents of the summary source project. Therefore, it is possible to efficiently perform the reconciliation between the summary destination project PJ0 and the summary source project.

[4. Example (reference summary)]
Next, an example of design verification using a reference summary when the above-described design support system 1 is applied to the design development of an automobile will be described. Here, the design verification using the reference summary between the projects (vehicle planning PJ, engine design PJ, fuel consumption design PJ, output design PJ, piston design PJ, WP design PJ) shown in FIG. 39 will be described.

[4-1. Verification in vehicle planning PJ]
In the vehicle plan PJ, the result of the performance design (fuel consumption design and output design) is verified with the design granularity of the vehicle plan. Specifically, the above-described reference summary is executed with the vehicle planning PJ as the summary destination project and the fuel efficiency design PJ and the output design PJ as the summary source project. Specifically, in the design support system 1 for the vehicle planning PJ, the design data acquisition unit 111, the summary, and the design data for the fuel efficiency design PJ (see FIG. 48) and the design data for the output design PJ (see FIG. 52). Processing by the target data set extraction unit 112 and the summary execution unit 113 is executed. As a result, a summary result of the same design granularity as the design data of the vehicle planning PJ (see FIG. 40), that is, the requirement data sets RS00, RS01, RS02, the element data sets ES00, ES01, ES02, and these data sets The summary execution unit 113 outputs a summary result including dependency relationship data between included item data (requirement data or element data).

  Subsequently, the reference summary comparison unit 114 compares the design data of the vehicle plan PJ with the above-described summary result, and outputs the comparison result data to the reference summary comparison result DB 122. The user of the vehicle plan PJ can determine whether or not the design difference may be reflected in the design data of the vehicle plan PJ by checking the comparison result data with the design data presentation unit 24 or the like. That is, the user of the vehicle plan PJ can determine whether or not to change the policy of the vehicle plan based on the result of the performance design (fuel consumption design and output design).

  When the user of the vehicle plan PJ determines that the design difference may be reflected in the design data of the vehicle plan PJ, for example, by executing a predetermined user operation on the reference summary reflecting unit 123, the reference summary is obtained. The reflecting unit 123 can update the design data of the vehicle plan PJ to the same design data as the above summary result. Thereafter, the reference summary matching unit 124 executes notification for each project that refers to the design data of the vehicle plan PJ (or design data generated by referring to and editing the design data). As a result, the design data in each project is the latest design data that takes into account the change (reflection) of the design data in the vehicle planning PJ.

[4-2. Verification in engine design PJ]
In the engine design PJ, the result of the engine detailed design (piston design and WP design) is verified at the design granularity of the engine design. Specifically, the above-described reference summary is executed with the engine design PJ as the summary destination project and the piston design PJ and the WP design PJ as the summary source project. Specifically, in the design support system 1 for the engine design PJ, the design data acquisition unit 111 and the summary described above are used for the design data for the piston design PJ (see FIG. 56) and the design data for the WP design PJ (see FIG. 60). Processing by the target data set extraction unit 112 and the summary execution unit 113 is executed. As a result, the summary result of the same design granularity as the design data of the engine design PJ (see FIG. 44), that is, the requirement data sets RS01 and RS02, the element data sets ES01 and ES11, and the item data included in these data sets A summary result including dependency relationship data between (requirement data or element data) is output by the summary execution unit 113.

  Subsequently, the reference summary comparison unit 114 compares the design data of the engine design PJ with the above-described summary result, and outputs the comparison result data to the reference summary comparison result DB 122. The user of the engine design PJ can determine whether or not the design difference may be reflected in the design data of the engine design PJ by checking the comparison result data with the design data presentation unit 24 or the like. That is, the user of the engine design PJ can determine whether or not to change the engine design policy based on the result of the detailed engine design (piston design and WP design).

  If the user of the engine design PJ determines that the design difference may be reflected in the design data of the engine design PJ, for example, by executing a predetermined user operation on the reference summary reflection unit 123, the reference summary is obtained. The reflecting unit 123 can update the design data of the engine design PJ to the same design data as the above summary result. After that, the reference summary matching unit 124 executes notification for each project that references design data of the engine design PJ (or design data generated by referring to and editing the design data). As a result, the design data in each project is the latest design data in consideration of the change (reflection) of the design data in the engine design PJ.

[4-3. Verification in fuel efficiency design PJ]
In the fuel efficiency design PJ, the result of the engine detailed design (piston design and WP design) is verified with the design granularity of the fuel efficiency design. Specifically, the above-described reference summary is executed with the fuel efficiency design PJ as the summary destination project and the piston design PJ and the WP design PJ as the summary source project. Specifically, in the design support system 1 for the fuel efficiency design PJ, the design data acquisition unit 111 and the summary described above for the design data of the piston design PJ (see FIG. 56) and the design data of the WP design PJ (see FIG. 60). Processing by the target data set extraction unit 112 and the summary execution unit 113 is executed. Thereby, a summary result of the same design granularity as the design data of the fuel efficiency design PJ (see FIG. 48), that is, the requirement data sets RS01 and RS21, the element data sets ES01 and ES11, and the item data included in these data sets A summary result including dependency relationship data between (requirement data or element data) is output by the summary execution unit 113.

  Subsequently, the reference summary comparison unit 114 compares the design data of the fuel efficiency design PJ with the above-described summary result, and the comparison result data is output to the reference summary comparison result DB 122. The user of the fuel efficiency design PJ can determine whether or not the design difference may be reflected in the design data of the fuel efficiency design PJ by checking the comparison result data with the design data presentation unit 24 or the like. That is, the user of the fuel efficiency design PJ can determine whether to change the policy of the fuel efficiency design based on the result of the detailed engine design (piston design and WP design).

  When the user of the fuel efficiency design PJ determines that the design difference may be reflected in the design data of the fuel efficiency design PJ, for example, by executing a predetermined user operation on the reference summary reflection unit 123, the reference summary is obtained. The reflecting unit 123 can update the design data of the fuel efficiency design PJ to the same design data as the above-described summary result. Thereafter, the reference summary matching unit 124 executes notification for each project that refers to design data of the fuel efficiency design PJ (or design data generated by referring to and editing the design data). As a result, the design data in each project is the latest design data that takes into account the change (reflection) of the design data in the fuel efficiency design PJ.

[4-4. Verification in output design PJ]
In the output design PJ, the result of the engine detailed design (piston design and WP design) is verified with the design granularity of the output design. Specifically, the above-described reference summary is executed with the output design PJ as the summary destination project and the piston design PJ and the WP design PJ as the summary source project. Specifically, in the design support system 1 for the output design PJ, the design data acquisition unit 111 and the summary for the design data for the piston design PJ (see FIG. 56) and the design data for the WP design PJ (see FIG. 60). Processing by the target data set extraction unit 112 and the summary execution unit 113 is executed. Thereby, a summary result of the same design granularity as the design data of the output design PJ (see FIG. 52), that is, the requirement data sets RS02 and RS31, the element data sets ES01 and ES11, and the item data included in these data sets A summary result including dependency relationship data between (requirement data or element data) is output by the summary execution unit 113.

  Subsequently, the reference summary comparison unit 114 compares the design data of the output design PJ with the above-described summary result, and outputs the comparison result data to the reference summary comparison result DB 122. The user of the output design PJ can determine whether or not the design difference may be reflected in the design data of the output design PJ by checking the comparison result data with the design data presentation unit 24 or the like. That is, the user of the output design PJ can determine whether or not to change the policy of the output design based on the result of the detailed engine design (piston design and WP design).

  When the user of the output design PJ determines that the design difference may be reflected in the design data of the output design PJ, for example, by executing a predetermined user operation on the reference summary reflection unit 123, the reference summary is obtained. The reflecting unit 123 can update the design data of the output design PJ to the same design data as the above summary result. Thereafter, the reference summary matching unit 124 executes notification for each project that references the design data of the output design PJ (or design data generated by referring to and editing the design data). As a result, the design data in each project is the latest design data in consideration of the change (reflection) of the design data in the output design PJ.

  Subsequently, the operation related to the reference summary of the design support system 1 (the operation including the design support method according to the embodiment) will be described with reference to FIG. FIG. 69 is a diagram showing a flow when processing related to the reference summary for the designated reference source project is executed in the summary destination project PJ0. First, the design data acquisition unit 111 acquires design data of other projects (in this case, projects PJ1 and PJ2) designated as the summary source project (step S201, design data acquisition step).

  Subsequently, the data set included in the design data of the summary destination project PJ0 and the design data of the summary source projects PJ1 and PJ2 is extracted as a summary target data set by the summary target data set extraction unit 112 (step S202, summary). Target data set extraction step).

  Subsequently, the summary execution unit 113 generates and outputs a summary result that does not include a data set other than the summary target data set extracted by the summary target data set extraction unit 112 based on the design data of the summary source projects PJ1 and PJ2. (Step S203, summary execution step). Specifically, the summary execution unit 113 outputs the design data of the summary destination project PJ0 and the summary result to the reference summary comparison unit 114. The generation of the summary result is executed according to the procedure shown in the first to third examples described above.

  Subsequently, the reference summary comparison unit 114 acquires the design data and summary result of the summary destination project PJ0 output from the summary execution unit 113. Then, the reference summary comparison unit 114 compares the design data of the summary destination project PJ0 with the summary result, and item data (requirement data or element data) and dependency between the design data of the summary destination project PJ0 and the summary result. Comparison result data indicating the difference for each of the data is output (step S204, comparison step).

  Subsequently, the reference summary reflecting unit 123 updates (reflects) the design data stored in the project DB 23 of the summary destination project PJ0 to the same design data as the summary result based on the comparison result data (step S205, Reflection step). Subsequently, notification information indicating that the design data of the summary destination project PJ0 has been updated to the same design data as the summary result by the reference summary matching unit 124 is referred to the design data of the summary destination project PJ0 (or the design data). The project (design data generated by editing) is referred to (in the example shown in FIG. 30, projects PJ1 to PJ3) (step S206, matching step).

  Subsequently, a design support program according to an embodiment will be described with reference to FIG. FIG. 70 is a block diagram showing a functional configuration (module configuration) of the design support program P2. The design support program P2 is a program for causing a computer system to function as the design support system 1. In particular, the design support program P2 is a program for causing a computer system to function as the design support system 1 (see FIG. 64) having a function related to the reference summary. As shown in FIG. 70, the design support program P2 includes a design data acquisition module P21, a summary target data set extraction module P22, a summary execution module P23, a reference summary comparison module P24, a reference summary reflection module P25, and a reference summary matching module P26. Is provided. The functions realized by executing the design data acquisition module P21, the summary target data set extraction module P22, the summary execution module P23, the reference summary comparison module P24, the reference summary reflection module P25, and the reference summary matching module P26, respectively. The functions of the design data acquisition unit 111, the summary target data set extraction unit 112, the summary execution unit 113, the reference summary comparison unit 114, the reference summary reflection unit 123, and the reference summary matching unit 124 of the design support system 1 described above are the same. .

  The design support program P2 is stored in a recording medium such as a CD-ROM and a DVD, and is executed by a computer system used as the design support system 1. Specifically, each device (the information processing server 10 and the information processing terminal 20) configuring the computer system includes a recording medium reading unit such as a CD-ROM drive and a DVD drive. When the recording medium is set in the recording medium reading unit, each device can access the design support program P2 stored in the recording medium from the recording medium reading unit. The computer system can be operated as the design support system 1 by causing each device to execute the design support program P2. The design support program P2 may be provided as a data signal superimposed on a carrier wave via a network.

DESCRIPTION OF SYMBOLS 1 ... Design support system, 10 ... Information processing server, 11 ... Data set reference part (reference data acquisition part), 12 ... Reference data merge part, 13 ... Data synchronization part, 14 ... Merge result DB, 15 ... Merge with reference edit Result DB, 16 ... own project DB, 17 ... other project DB, 18 ... reference setting execution unit, 20 ... information processing terminal, 21 ... data set reference instruction unit, 22 ... project DB before reference editing, 23 ... project DB, 24 Design data presenting unit 25 ... Edit execution unit 26 ... Update unit 27 ... Reference edit cancel unit 28 ... Reference setting execution unit 111 ... Design data acquisition unit 112 ... Summary target data set extraction unit 113 ... Summary Execution unit, 114 ... reference summary comparison unit (comparison unit), 121 ... reference summary instruction unit, 122 ... reference summary comparison result DB, 123 ... reference Mali reflection unit (reflection unit), 124 ... reference summary matching unit (matching unit), P1, P2 ... design support program, P11 ... reference data acquisition module, P12 ... reference data merge module, P13 ... design data storage module, P14 ... Design data presentation module, P15 ... edit execution module, P16 ... reference edit cancellation module, P21 ... design data acquisition module, P22 ... summary target data set extraction module, P23 ... summary execution module, P24 ... reference summary comparison module, P25 ... reference Summary reflection module, P26 ... reference summary matching module.

Claims (9)

A design support system that supports a design of each project in a design that is configured by a computer system and is executed by being divided into a plurality of projects,
A design data acquisition unit that acquires first design data of a first project and second design data of one or more second projects different from the first project, wherein the first and first The design data of 2 includes design data acquisition including a plurality of data sets including one or more item data indicating design items and dependency data indicating dependency relationships between the item data included in each of the plurality of data sets. And
A summary target data set extraction unit that extracts a data set commonly included in the first design data and the one or more second design data as a summary target data set;
A summary execution unit that generates and outputs third design data that does not include a data set other than the summary target data set extracted by the summary target data set extraction unit based on the one or more second design data; equipped with a,
The second project is a project lower than the first project, and is a project that refers to and details the design contents of the first project .
Design support system. The summary execution unit, when the second project is one,
With respect to the second design data, two pieces of item data included in the summary target data set, and a plurality of dependency data associated with item data included in a data set other than the summary target data set Two linked item data are detected, one dependency data indicating a dependency relationship between the two item data is generated from the plurality of dependency data, and a data set other than the summary target data set is deleted. Thus, the third design data is generated.
The design support system according to claim 1. The summary execution unit, when there are a plurality of the second project,
Converting the second design data of each of the plurality of second projects into one fourth design data based on a predetermined rule;
For the fourth design data, two items of data included in the summary target data set, and a plurality of pieces of dependency data associated with item data included in a data set other than the summary target data set Two linked item data are detected, one dependency data indicating a dependency relationship between the two item data is generated from the plurality of dependency data, and a data set other than the summary target data set is deleted. Thus, the third design data is generated.
The design support system according to claim 1. The summary execution unit, when there are a plurality of the second project,
Regarding the second design data of each of the plurality of second projects, two item data included in the summary target data set and associated with item data included in a data set other than the summary target data set Detecting two item data linked through the plurality of dependency relationship data, generating one dependency relationship data indicating a dependency relationship between the two item data from the plurality of dependency relationship data, and the summary By deleting data sets other than the target data set, a plurality of fifth design data is generated,
The design support system according to claim 1, wherein the third design data is generated by converting the plurality of fifth design data into one third design data based on a predetermined rule. The first design data and the third design data are acquired, and the first design data and the third design data are compared with each other by comparing the first design data and the third design data. A comparison unit that outputs comparison result data indicating a difference for each of the item data and the dependency relationship data between
The design support system according to any one of claims 1 to 4. Based on the comparison result data output by the comparison unit, further includes a reflection unit that updates the first design data to the same design data as the third design data.
The design support system according to claim 5. Notification information indicating that the first design data has been updated to the same design data as the third design data by the reflection unit, design data generated based on the design data of the first project It further includes a matching unit that notifies all of the projects it owns.
The design support system according to claim 6. A design support method executed by a design support system configured by a computer system and supporting design of each project in a design executed by dividing into a plurality of projects,
A design data acquisition step of acquiring first design data of a first project and second design data of one or more second projects different from the first project, wherein the first and first The design data of 2 includes design data acquisition including a plurality of data sets including one or more item data indicating design items and dependency data indicating dependency relationships between the item data included in each of the plurality of data sets. Steps,
A summary target data set extraction step for extracting a data set commonly included in the first design data and the one or more second design data as a summary target data set;
A summary execution step of generating and outputting third design data that does not include a data set other than the summary target data set extracted in the summary target data set extraction step based on the one or more second design data; only including,
The second project is a project lower than the first project, and is a project that refers to and details the design contents of the first project .
Design support method. A design support program that allows a computer system to function as a design support system that supports the design of each project in a design that is executed by being divided into a plurality of projects,
The design support system includes:
A design data acquisition unit that acquires first design data of a first project and second design data of one or more second projects different from the first project, wherein the first and first The design data of 2 includes design data acquisition including a plurality of data sets including one or more item data indicating design items and dependency data indicating dependency relationships between the item data included in each of the plurality of data sets. And
A summary target data set extraction unit that extracts a data set commonly included in the first design data and the one or more second design data as a summary target data set;
A summary execution unit that generates and outputs third design data that does not include a data set other than the summary target data set extracted by the summary target data set extraction unit based on the one or more second design data; equipped with a,
The second project is a project lower than the first project, and is a project that refers to and details the design contents of the first project .
Design support program.

Images