JP2002215692A - Information processor and method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To distinguish data influencing the version of an item itself from data not influencing, to manage data when there is a version change in the data related to the item. SOLUTION: Data is registered and managed for every item which is the substance of each hierarchy when expressing management objects by the configuration of many hierarchies. When the updating of the managed data is detected (S304), whether the updated data influence the history information of the items is determined (S303, S306). When the updated data are determined to influence the history information, the history information of the item to which the data belong is updated.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to an information processing apparatus and method for managing the history of data relating to a managed product such as a product.

[0002]

2. Description of the Related Art A product data management system (PDM system), which is a computer system that associates and manages various types of information constituting a product and allows the information to be referenced or changed as needed, is becoming widespread. .

In a PDM system, various CAD systems are generally used.
A plurality of types of real data (bulk data) created by individual applications, such as data, analysis data, and document data, are virtually and unifiedly managed by data (metadata) indicating their management information and location information. At the same time, the tree structure of the product is expressed by managing the parent-child relationship of the units and parts constituting the product (these are called items). Then, the various types of data are managed in association with any item.

For example, when one product is composed of one or a plurality of units, and each unit is composed of one or a plurality of parts, there are three layers: a product layer, a unit layer, and a part layer. Can be managed. Note that elements constituting each layer such as a product, a unit, and a part are referred to as an item in this specification.

Therefore, in such a PDM system,
Generally, it is common to have a data history management function for managing the history (version) of each type of data and a configuration history management function for managing the configuration of all items of a product at an arbitrary time. Here, the data (or configuration) history management function means that when data (or configuration) managed by the PDM system is changed, the data is saved as a new version of data (or configuration), and any saved version is stored. This is a function that can easily retrieve version data (or configuration).

[0006]

However, the above prior art has the following problems.

First, when there is any change in data associated with an item, it is determined whether the change leads to a change in the item, that is, whether or not the change is regarded as a version change of the item itself. There was no problem.

For example, the shape of a certain part (CAD data)
If there is a change in the part, it is considered that the part is a version change, but if the analysis data or memo document data is changed, the part is not considered a version change. could not.

Second, depending on the nature of the item, which data among the data associated with the item is changed, which data is regarded as a version change of the item itself is different. There was no problem.

For example, when a certain part is a mechanical part,
3D CAD data and 2D CA associated with parts
A change in D data is regarded as a version change of a component, but in the case of an electrical component, a change in circuit diagram data or wiring diagram data, not these data, is regarded as a version change of the component. Could not be classified.

The present invention has been made to solve these problems, and a first object of the present invention is to change the version of an item itself when a version of data associated with the item is changed. An object of the present invention is to make it possible to manage data that has no influence on data. Also, the second
It is an object of the present invention to classify and manage data that affects the version of the item itself and data that does not affect the version of the item itself according to the type of the item.

[0012]

An information processing apparatus according to the present invention for achieving the above object has the following arrangement.
That is, a management means for expressing a product by a multi-layer structure, registering and managing data for each item which is an entity of each hierarchy, and a detection means for detecting an update of data managed by the management means A first determining means for determining whether the data affects the history information of the item when the update is detected by the detecting means; and an influence on the history information by the first determining means. A first updating unit that updates history information of the item to which the data belongs when the determination is made.

According to another aspect of the present invention, there is provided an information processing method, wherein a product is represented by a multi-layer structure, and data is registered and managed for each item which is an entity of each layer. A detection step of detecting an update of data managed in the management step; and, when an update is detected by the detection step, determining whether the data affects the history information of the item. First
A determination step; and a first update step of updating the history information of the item to which the data belongs when it is determined by the first determination step that the history information is affected.

[0014]

Embodiments of the present invention will be described below in detail with reference to the drawings.

FIG. 1 is a block diagram showing a hardware configuration of a data history management device according to this embodiment. Figure 1
In the figure, reference numeral 21 denotes a central processing unit (CPU), which performs overall control and arithmetic processing of the apparatus. Reference numeral 11 denotes a keyboard for inputting characters and numerical values, and reference numeral 12 denotes various operation panels and a pointing device for instructing buttons on the panels. In this embodiment, a mouse is used. A display device 41 displays various operation panels and buttons on the panels.

Reference numeral 31 denotes a read-only storage device (ROM) for storing various control programs and data. A program for realizing data history management according to the present embodiment, which will be described later with reference to a flowchart, is stored in the ROM 31 and is executed by the CPU 21. In addition, ROM3
1 stores BIOS, which is software for controlling basic input / output of the apparatus, character font data necessary for displaying characters on the display device 41, and the like.

Reference numeral 32 denotes a read / write storage device (RAM) which is used by the CPU 21 during execution of the program according to the present embodiment.
Performs processing while reading and writing data to and from the RAM 32 as necessary. Reference numeral 33 denotes an external storage device such as a floppy (registered trademark) disk device (FD) or a hard disk device (HD), which is referred to or created by the program according to the present embodiment and various application programs such as a CAD system. The data to be created is stored.

Although the programs and data according to the present embodiment are stored in the ROM 31, the programs and data are stored in the external storage device 33, and the programs and data are read into the RAM 32 as necessary. May be executed. The data store program to be used is stored in the ROM 31 and stored in the ROM 31.
The PU 21 may read and use the data as needed.

FIG. 2 is a block diagram showing a network configuration of the data history management device according to the present embodiment.

In the case of constructing a large-scale information processing apparatus as in the present embodiment, a client-server model as shown in FIG. 2 is used to realize effective use of resources and high-speed processing. Sometimes.

In FIG. 2, reference numeral 51 denotes a server machine. The server machine 51 has a database managed by the program according to the present embodiment, and each client machine 52 requests the server machine 51 to refer to and update the database. The machine 51 performs this. The server machine 51 stores the processing result in the database and notifies the client machine 52 of the result. Hereinafter, the database according to the present embodiment refers to a data record group that is constructed using relational database software or the like and that is registered and referred to in executing the program according to the present embodiment.

The client machine 52 has a GUI (graphical user interface) for allowing a user to operate various programs such as the program according to the present embodiment and a CAD system.

Server machine 51 and client machine 5
There is no significant difference in the internal hardware configuration of
As shown in FIG. However, the server machine 51 is provided with the CPU 21 and the RAM 32 capable of high-speed arithmetic processing and high-speed file access according to the role. Further, in order to store a large amount of data, the external storage device 33 of the server machine 51 is usually large-scale. Data transmission and reception between each of the server machine 51 and the client machine 52 is performed via the network 24. The communication control device 23 of each machine controls the data transmission and reception.

In the example shown in FIG. 2, the number of server machines 51 is one. However, a database server, a file server for managing files created by various application programs, and a data processing process among the programs according to the present embodiment. Can be executed on the server side, and an application server provided for improving the processing efficiency and maintainability of the program can be separately provided. A configuration in which the functions of the server machine 51 and the client machine 52 are integrated into one machine is also possible.

FIG. 3 shows the management of the data history by the data history management apparatus of the present embodiment having the above configuration.
This will be described in detail with reference to FIGS.

First, referring to FIG. 4, item type, item,
The version, history, etc. will be described. FIG. 4 is a diagram illustrating an example of data to be managed by the data history management device according to the present embodiment.

As defined above, an item is an entity that represents each level of the tree that constitutes a product. In this example, the tree is hierarchized like products, units, and parts, and data created by the data history management device of the present embodiment is stored in association with any item. For example, when a tree structure as shown in FIG. 10 is obtained for the product A, the item is the entity of each of the hierarchies 1 to 3, the product A, the units A1 and A2, and the parts A11 to 1
It becomes 5.

When the characteristics of the items of the product data are classified into several types, there are item types such as mechanical, electrical, software, and optical, and the data to be created, that is, the data to be managed according to these types. Are different. Further, each item cannot always be limited to a single item type, and may be a combination of a plurality of item types.
For example, if a unit is a combined unit of mechanical and electrical components, this unit must manage both data to be managed by the mechanical unit and data to be managed by the electrical unit. . Therefore,
A combination of a plurality of item types, such as a combination of a mechanical system and an electrical system, can also be said to be one item type.

For the sake of simplicity, in the present embodiment, the description will be limited to the types of items to be managed: mechanical, electrical, and a combination of mechanical and electrical. In FIG. 4, the data with (M) at the end of each data is data to be managed with mechanical items, and the data with (E) is data to be managed with electrical items. Other data are data to be managed in common for both mechanical and electrical items.

In this embodiment, the “version” is an identifier for managing the history of the contents of individual data. Usually, when a change is made to the data, a new version number is used. Is added and saved.

Assuming that version numbers are assigned in ascending order by two-digit integers, when data A is first created, a record "data A: version 01" is stored. Thereafter, when a change is made to the data A, the data A is updated to the version 0, such as “data A: version 01” or “data A: version 02”.
1 is left as it is, and a new version 02 record is created. Thereafter, every time data A is changed, version 03, version 04, etc.
The version will be up.

In this embodiment, the "history"
Is an identifier for managing the history of essential changes of each item, and when the change is considered to be a change of the item itself among the data group associated with a certain item, It is assumed that the data is subject to history management, and a new history number is added to the item every time one version of the data group is upgraded. Actually, a separate history number is added for each combination of the version numbers of the data that is subject to history management.

For example, assuming that there is history management target data C, D, and E associated with a certain item B, and history numbers are assigned in ascending order by two-digit integers, the history goes up as follows. go.

1) Create data C “Item B: History 01” “Data C: Version 01” “Data D: No data” “Data E: No data” 2) Create data D “Item B: History 02” "Data C: Version 01""Data D: Version 01""Data E: No data" 3) Create data E "Item B: History 03""Data C: Version 01""Data D: Version 01""Data E: Version 01 4) Change data C "Item B: History 04""Data C: Version 02""Data D: Version 01""Data E: Version 01" 5) Change data E "Item B: History" 05 "Data C version 02""Data D version 01""Data E version 02" As can be seen from this example Data history managed is a requirement that the data version managed simultaneously.

Next, the data to be managed handled in this embodiment will be described. However, in this embodiment, for simplicity, the data to be managed will be limited to the data shown in FIG.

The item type is, as shown in FIG. 10 or FIG. 4, the product, unit, and component layers.
Of these, a unit can have further child units. Usually, a plurality of units and parts belong to a product, and a plurality of child units and parts belong to each unit.

[Data to be History-Managed] Data to be history-managed and to be version-managed (Since the data to be history-managed is always the data to be version-managed as described above, it is simply referred to as history-managed data below) Include the following: For example, in the case of a mechanical part, a change in shape or a change in the performance or quality of the part must be considered an essential change in that part,
Data representing these, such as 3D parts, 2D parts drawings, and standard documents, is data that is subject to history management.

(1) Attribute data of each item type: information for specifying an item. The contents include the item name, creator, creation date, last change date, and the like. (2) Product and unit configuration data: Data indicating the parent-child relationship of an item, and is list information of child items belonging to the item. The child item is a unit or part for a product and a child unit or part for a unit. (3) Standard document for each item type: a document that describes the performance and quality of each item, and is created by an application program such as a word processor. (4) 3D assembly of products and units: Mainly in mechanical or product or unit units, the positional relationship and assembling status of child items are expressed in three-dimensional data, and are created by an application program such as a three-dimensional CAD system. Is done. (5) 3D part of a part: mainly a mechanical system expressing the dimensions and shape of a part in three-dimensional data, and is created by an application program such as a three-dimensional CAD system. (6) 2D assembly drawing of product and unit: A 2D C that mainly expresses the positional relationship and assembling state of child items in units of products or units of mechanical systems, and is represented by 2D data.
It is created by an application program such as an AD system. (7) 2D part drawing of parts: mainly a mechanical system, in which dimensions and shapes of parts are represented by two-dimensional data, and are created by an application program such as a two-dimensional CAD system. (8) Component image diagram: A representation of the electrical and mechanical ratings and external shapes of components, mainly in electrical systems, in image data, created by application programs such as image processing software and illustration drawing software. You. (9) Circuit diagram of product and unit: A circuit function is mainly represented by a symbol in an electric system, in a product or unit unit, and is created by an application program such as a circuit diagram CAD system. (10) Wiring diagram of unit: This mainly represents the connection state and wiring length of electric wires constituting the harness unit of the electric system, and is created by an application program such as a wiring diagram CAD system.

[Data with Version Only Management Target] The following data is not history management target and version management target data (hereinafter referred to as data only with version management target).

For example, reports and drawings used in the design study of a unit should be managed in their own histories, but any change in these contents is an essential change in the unit. Is not considered. Therefore, data such as a design report and a design study diagram are subject to version management but are not subject to history management.

(11) Design report for each item type: A document for reviewing and reporting design details in the course of design, and is created by an application program such as a word processor. (12) Design study drawing for each item type: Illustrative diagrams and drawings when studying the design contents in the design process, created by application software such as illustration drawing software or a two-dimensional CAD system. .

[Data not subject to version management] Data not subject to history management and not subject to version management (hereinafter referred to as
The data that is not subject to version control includes the following.
For example, a memo or a minutes of a meeting does not need to maintain its own history, and, of course, a change in these contents is not regarded as an essential change in the associated item. However, there are cases where it is desired to save the information in association with a specific item. For such purposes, data such as memos and minutes are stored in the data history management device of the present embodiment as not being subjected to version management and history management.

(13) Memo and minutes of each item type: memos and minutes of meetings where ideas are written down, and are created by an application program such as a word processor.

FIG. 5 is a flowchart for explaining a procedure of editing registered data and selecting an item to be associated with the data history management apparatus of the present embodiment, which is performed prior to the processing of the flowchart of FIG. Also, FIG.
It is a figure showing the item hierarchy display panel 601 of the data history management device of this embodiment. In the following description, it is assumed that the program and the database according to the present embodiment exist on the server machine 51, and each application program and data (bulk data) created by the application program exist on the client machine 52. Further, it is assumed that all screens of the program according to the present embodiment are displayed on the display device 41 of the client machine 52.

First, the user selects any item in the item hierarchy display area 602 on the item hierarchy display panel 601 shown in FIG. The selection of the item is performed by pointing the line on which the item is displayed with the mouse 12, inputting the line number of the line on which the item is displayed on the keyboard 11 into the line number input area 603, or by inputting a keyword such as the item number or the like. This is performed by inputting a part of the information into the item number input area 604 or the like with the keyboard 11 (step S501).

When one item is selected, a list of data registered in association with the item is displayed on the registered data list panel 611, separately from the item hierarchy display panel 601 of the display device 41 (step S502).

The user looks at the list displayed on the registered data list panel 611 and determines whether or not the data to be registered already exists in the database (step S503). Then, the registered data list panel 61
One corresponding data type is selected from the data listed in 1. If the data to be registered already exists, the version of the registered data is upgraded. For example, if "3D assembly" is selected, version 02 data has already been registered.
The data to be created next is version 03. On the other hand, if the data to be registered does not yet exist, the data is newly registered. For example, when "standard document" is selected, the data to be created is new, that is, version 01, since the data has not been registered. After selecting one piece of data, the user confirms the selection by pointing the “select” button with the mouse 12. To stop selecting data, click the “Cancel” button
Instruct. The registered data list panel 611 displays only the data types that can be registered and that are set in advance according to the item type of the selected item (step S504).

Then, the user edits the data to be registered by using an application program such as a three-dimensional CAD system or a word processor according to the data to be registered. The file name and data number of the registered data are associated with the item according to a predetermined naming rule. For example, 3D of item number "UNT-D"
If the data is version 03 of the assembly data,
The file name and data number “UNT-D-M3D-V03” are automatically assigned (step S505).

FIG. 3 is a flowchart showing a procedure of a history management process in the data history management device according to the present embodiment. When the processing of the flowchart in FIG. 5 is completed, the item of interest and the data to be registered are determined, and the process proceeds to the processing shown in FIG. Hereinafter, the processing of each step in the flowchart of FIG. 3 will be described in detail with reference to the management target data of FIG. 4 as an example and further referring to the history and version transitions shown in FIGS. 7 to 9.

FIG. 7 is a diagram showing the version of each data associated with a unit A of a certain mechanical system and the history of the unit A. Hereinafter, the process of updating the data of the history management target and the version management target will be described using the process at the point 701 in FIG. 7 as a specific example.

First, the CPU 21 of the server machine 51
In step S301, the item type (in this example, mechanical or electrical) of the item of interest is determined. In the example of FIG. 7, the unit A is determined to be a mechanical item type. The item type is specified by the user when the item is registered in the database, and is automatically determined by the CPU 21 based on the item name and a preset “correspondence table of item name and item type (not shown)”. To do. It is also possible to change the item type later, but in this case, the data to be history-managed also changes.

Next, in step S302, the CPU 21 of the server machine 51 determines the data type of the data to be registered. Now, at the time point 701 in FIG. 7, the data type of the data to be registered is determined to be 3D assembly. The data type is specified by the user when registering the data in the database. In addition to the data file name and a preset “data file name / data type correspondence table (not shown)”, the CPU 2
1 automatically determines.

Next, the process proceeds to step S303, and in the item type determined in step S301, the process proceeds to step S3.
It is determined whether or not the data type determined in 02 is version management target (that is, either “history management target data” or “version only management target data”). This determination is made by creating a list of data types to be version-managed in advance in the database for each item type, and by referring to this. In the example at the point 701 in FIG. 7, it is determined that the 3D assembly is to be subjected to version control.

If it is determined in step S303 that the object is subject to version management, the process proceeds to step S30.
Then, it is determined whether the data to be registered has been updated, that is, whether there is a version change.
In the present embodiment, updating data includes changing existing data and registering completely new data. If it is determined in step S303 that the data is not subject to version management, the process proceeds to step S308, and the data is registered without version management. In the example at the point of 701, it is determined that the version has been changed in the 3D assembly. This update determination is performed by the CPU 21 automatically comparing the data of the current version (01 in this example) with the file contents of the data to be registered, or by referring to the last update date. Is possible. It is also possible for the user to explicitly specify the data version change. Here, if it is determined that there is no version change, the process ends.

If it is determined in step S304 that the version has been changed, the process proceeds to step S305,
This data is registered in the database with a new version. In the example at the point of 701, a record of a new version 02 of the 3D assembly is registered in association with the unit A. In this case, only the data (metadata) indicating the management information and the location information of the 3D assembly is registered in the database, and the file entity (bulk data) of the 3D assembly is stored in the external storage device 33 of the client machine 52. Is stored in

Next, it is determined whether or not the data registered in step S305 is data for history management. This determination is made, for example, by creating a list of data types to be history-managed for each item type in a database in advance, and referring to the list by the CPU 21. Specifically, for example, four tables such as (a) an item type table, (b) a data type table, (c) a management type table, and (d) a management target identification table in FIG. I just need. In the example at the time point 701, it can be seen that the data with the item type “mechanical” and the data type “3D assembly” is a history management target (version management target, history management target). Here, if it is determined that the data is not history management target data,
The process of FIG. 3 ends.

If it is determined in step S306 that the item is subject to history management, the process proceeds to step S307, and the item of interest is registered in the database with a new history. The history information is stored as a combination of all the history management target data at this time and its version number. In the example at the point of time 701, the metadata indicating the combination of the data type and the version number in which the attribute data is version 01, the configuration data is version 01, the standard document is version 01, the 3D assembly is version 02, and the 2D assembly drawing is version 01. The data and the record of the new history 06 of the unit A are registered in the database. If there is only one item type,
The processing in step S301 can be omitted.

Also, in the example of FIG.
Although an example is shown in which only one type of data is registered, a plurality of registration target data associated with the same item is created in advance by each application program.
It is also possible to specify a plurality of registration target data in one registration process. In this case, when the history is increased by one, versions of a plurality of data may be increased. For example, in the example of FIG. 7, when the 3D assembly and the 2D assembly drawing are simultaneously corrected and the two data are registered in a single registration process, the versions of the 3D assembly and the 2D assembly drawing are increased by one, and , The history of the item to which the two data are related is increased by one.

The process of registering a plurality of data at a time is the same as in a general PDM system. For example, a general PDM has a function such as “notification form creation function”,
Here, a process of combining a plurality of data to be changed or newly registered is performed. For example, "Create notification slip 0001,
AA attribute data AA-P, 3D data AA-3D, 2D data AA-2D
Take out (declare that changes will be made from now on) and after the data change is completed, request approval of the notification slip 0001 and approve it to raise the attribute data, 3D data, 2D data version and item AA version '' processing Are doing. In the present embodiment, an internal process of whether or not history management is performed is included in the part “upgrading the version of an item”.

The processing at the point 701 in FIG. 7 has been described as an example. Next, a process at the time of updating data for which only the version is to be managed will be described, taking the process at the point 702 in FIG. 7 as an example.

In step S301, it is determined that the unit A is a mechanical item type. In step S302, the data type of the data to be registered is determined to be design report 1. In step S303, it is determined that the design report 1 is subject to version management. Therefore, the process proceeds to step S304.

In step S304, it is determined that the version of the design report 1 has been changed. The example at time 702 is a case where a new design report 1 is created.
This can also be considered a version change. Therefore,
Proceed to step S305.

In step S305, a record of version 01 of the design report 1 is registered in association with the unit A. In step S306, it is determined that the design report 1 is not subject to history management, and the process ends.

As described above, at time 702 in FIG.
Since the data of the design report 1 that was subject to version management but not history management was updated (newly created), the record of version 01 of the design report 1
Although registered in the database, the history of the unit A remains at 07 and no new history record is created.

The process of registering data that is not subject to history management and not subject to version management will be described with reference to the process at the point 703 in FIG. 7 as an example. In the figure, the * mark indicates that data without a version number was created.

In step S301, it is determined that the unit A is a mechanical item type. In step S302, the data type of the data to be registered is determined to be memo 1. In step S303, it is determined that the memo 1 is not subject to version management. Step S30
If it is determined that the data is not subject to version management, the process proceeds to step S308, and this data is registered in the database without version management.

In the example at the time point 703, the record of the memo 1 is registered in association with the unit A. However, no version number is assigned. Also in this case, step S3
As with 05, what is registered in the database is memo 1
Only the data (metadata) indicating the management information and the location information of the memo 1 are stored, and the substance (bulk data) of the file of the memo 1 is stored in the external storage device 33 of the client machine 52, and the processing is terminated.

As described above, at the time of 703 in FIG.
Since the data of memo 1 that is neither the object of version management nor the object of history management was created, the record of memo 1 (no version) is registered in the database, but the history of unit A remains 08, No new history record is created.

Next, an example of an electric unit will be described.

FIG. 8 is a diagram showing the transition of each data version associated with the history of a certain electrical unit B. Hereinafter, the process of updating the data of the history management target and the version management target will be described with reference to the processing at the point 801 in FIG. 8 as an example.

In step S301, it is determined that the unit B is of an electrical item type. In step S302, the data type of the data to be registered is determined to be a circuit diagram. In step S303, the circuit diagram is determined to be subject to version management. In the example of the mechanical unit in FIG. 7, the circuit diagram is not the data to be subjected to version management, but in the example of FIG. 8 in which the item type is electrical, it is subjected to version management. Therefore, the process proceeds to step S304.

In step S304, it is determined that the version has been changed in the circuit diagram. Therefore, step S30
Go to 5. In step S305, a new version record of 02 in the circuit diagram is registered in association with the unit B. In step S306, the circuit diagram is determined to be subject to history management. In the example of the mechanical unit in FIG. 7, the circuit diagram is not history management target data, but in the example of FIG.
It is subject to history management.

Therefore, the process proceeds to step S307, and the unit B is registered in the database with a new history. The history information is a combination of all history managed data at this point and its version number.
Will be saved. In the example at the point of time 801, metadata of a combination of a data type and a version number in which the attribute data is version 01, the configuration data is version 01, the standard document is version 01, the circuit diagram is version 02, and the wiring diagram is version 01 The record of the new history 06 of the unit B is registered in the database.

As described above, data subject to version management and data subject to history management differ depending on the item type. This means that if the item type is different,
This is because the data representing the essential characteristics of the item is different.

The process of updating data that is not subject to history management and is subject to version management (2D assembly drawing 2) at time 802 in FIG. 8 is the same as the process at time 702 in FIG. Further, in this example, in the example of the mechanical system unit in FIG. 7, the 2D assembly drawing which is a history management object is excluded from the history management object in the case of an electric system unit having a different item type. ing.

The process of updating data (memo 2) that is not subject to history management and is not subject to version management at the time point 803 in FIG. 8 is the same as the process at the time point 703 in FIG.

Next, an example in the case of a combined mechanical and electrical unit will be described.

FIG. 9 is a diagram showing the transition of the version of each data associated with the history of a combined mechanical and electrical unit C. Hereinafter, 901 and 9 in FIG.
The process of updating the data of the history management target and the version management target will be described by taking the process at the time 02 as an example.

In step S301, it is determined that the unit C is a composite item type of a mechanical system and an electric system. In step S302, it is determined that the data type of the data to be registered is a 3D assembly at 901 and a wiring diagram at 902. In step S303,
At time 901, the 3D assembly is determined, and at time 902, the wiring diagram is determined to be version controlled. In the example of FIG. 9 in which the item type is a combination of mechanical and electrical,
Both assembly and wiring diagrams are subject to version control.
Next, the process proceeds to step S304.

In step S 304, it is determined that the 3D assembly has been changed at 901 and that the wiring diagram has been changed at 902. Therefore, step S305
Proceed to. In step S305, a 3D
At the time of the assembly 02 and 902, a new version record 02 of the wiring diagram is registered in association with the unit C. In step S306, it is determined that the 3D assembly is a target of history management at 901 and a wiring diagram is a target of history management at 902. In the example of FIG. 9 in which the item type is a combination of a mechanical system and an electric system, a 3D assembly,
Since the wiring diagram is also subject to history management, step S
Proceed to 307.

In step S307, unit C is registered in the database with a new history. At time 901, a record of the new history 08 is registered in the database at time 902, and a record of the new history 10 is registered at the time 902.

As described above, in the case of a compounded item type, data to be subjected to version management and data to be subjected to history management are also combined.

At time 903 in FIG. 9, data that is not subject to history management and is subject to version management (design report 3)
Is the same as the process at the point 702 in FIG. The process of updating data (memo 3) that is not subject to history management and is not subject to version management at the point of time 904 in FIG. 9 is similar to the process at the point of time 703 in FIG.

As described above, according to this embodiment, when managing the history of product data composed of a plurality of types of data, essential changes of items are distinguished from changes that are not. Since both data can be managed, it is possible to easily determine whether an item needs to be actually replaced by a certain change, which part of the item has changed, etc. There is.

Further, since the data to be managed can be classified and managed according to the type of the item, the effect described in the preceding paragraph can be easily realized even when a wide variety of items are handled at the same time. .

An object of the present invention is to supply a storage medium storing software program codes for realizing the functions of the above-described embodiments to a system or an apparatus, and to provide a computer (or CPU) of the system or the apparatus.
And MPU) by reading and executing the program code stored in the storage medium.

In this case, the program code itself read from the storage medium implements the functions of the above-described embodiment, and the storage medium storing the program code constitutes the present invention.

Examples of a storage medium for supplying the program code include a floppy disk, hard disk, optical disk, magneto-optical disk, CD-ROM, and C
DR, magnetic tape, nonvolatile memory card, ROM
Etc. can be used.

When the computer executes the readout program code, not only the functions of the above-described embodiment are realized, but also the OS (Operating System) running on the computer based on the instruction of the program code. ) May perform some or all of the actual processing, and the processing may realize the functions of the above-described embodiments.

Further, after the program code read from the storage medium is written into a memory provided in a function expansion board inserted into the computer or a function expansion unit connected to the computer, based on the instruction of the program code, It goes without saying that the CPU included in the function expansion board or the function expansion unit performs part or all of the actual processing, and the processing realizes the functions of the above-described embodiments.

[0091]

As described above, according to the present invention,
Of the data associated with the item, when the version is changed, data that affects the version of the item itself and data that does not affect the version can be managed separately. Further, according to the present invention, it is possible to classify and manage data that affects the version of the item itself and data that does not affect the version of the item according to the type of the item.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a hardware configuration of a data history management device according to an embodiment.

FIG. 2 is a block diagram illustrating a network configuration of the data history management device according to the embodiment.

FIG. 3 is a flowchart illustrating a processing procedure in the data history management device according to the embodiment.

FIG. 4 is a diagram showing an example of data to be managed by the data history management device of the embodiment.

FIG. 5 is a flowchart illustrating a procedure for editing registration data and selecting an item to be associated with the data history management device of the embodiment.

FIG. 6 is a diagram showing an item hierarchy display panel of the data history management device of the present embodiment.

FIG. 7 is a diagram showing a change in the version of each data associated with the history of the unit A of the mechanical system.

FIG. 8 is a diagram showing a change in the version of each data associated with the history of the electric system unit B.

FIG. 9 is a diagram showing a change in the version of each data associated with the history of the combined unit C of the mechanical system and the electric system.

FIG. 10 is a diagram showing a tree structure of an item according to the embodiment.

FIG. 11 is a diagram illustrating a table referred to in determining whether or not the data is history management target data.

[Explanation of symbols]

 Reference Signs List 11 keyboard 12 mouse 21 central processing unit (CPU) 23 communication control device 24 network 31 read-only storage device (ROM) 32 read-write storage device (RAM) 33 external storage device 41 display device 51 client machine 52 server machine

Claims (18)

[Claims] 1. A management means for expressing a management target product in a multi-layer structure, registering and managing data for each item which is an entity of each hierarchy, and updating data managed by the management means. Detecting means for detecting, when an update is detected by the detecting means, a first determining means for determining whether the data affects the history information of the item, and a first determining means, An information processing apparatus, comprising: first update means for updating history information of an item to which the data belongs when it is determined that the history information is affected. 2. The information processing apparatus according to claim 1, wherein the update of the data detected by the detection unit includes a change in the content of existing data and a registration of new data. 3. A second judging unit for judging whether the data detected by the detecting unit to be updated is data to be subjected to history management, and the second judging unit judges that the history management is performed. 2. The information processing apparatus according to claim 1, further comprising a second updating unit that updates a history of the data in the case. 4. The method according to claim 1, wherein the first determining unit stores a table indicating whether or not the history information of the item is affected for each type of data. The information processing apparatus according to claim 1, wherein it is determined whether or not the information is affected. 5. The method according to claim 1, wherein the first determining unit determines, based on a type of the data and a type of an item to which the data belongs, whether the data affects history information of the item. The information processing apparatus according to claim 1, wherein: 6. The method according to claim 1, wherein the first determination unit has a table for each item of data indicating whether the history information of the item is affected or not, and performs the determination with reference to the table. The information processing apparatus according to claim 5, wherein: 7. A management step in which a management target product is represented by a multi-layer structure, and data is registered and managed for each item which is an entity of each hierarchy, and updating of the data managed in the management step is performed. A first detecting step of determining whether or not the data affects the history information of the item when an update is detected by the detecting step; and A first updating step of updating the history information of the item to which the data belongs when it is determined that the history information is affected. 8. The information processing method according to claim 7, wherein the update of the data detected in the detection step includes a change in the content of existing data and a registration of new data. 9. A second determining step of determining whether data updated in the detecting step is data to be subjected to history management, and it is determined in the second determining step that history management is performed. 8. The information processing method according to claim 7, further comprising a second updating step of updating a history of the data in the case. 10. A table which indicates, for each type of data, whether or not it affects the history information of an item, wherein the first determining step refers to the table to determine whether the data affects the history information of the item. 8. The information processing method according to claim 7, wherein it is determined whether or not the information is to be processed. 11. The first determining step determines, based on a type of the data and a type of an item to which the data belongs, whether the data affects the history information of the item. The information processing method according to claim 7, wherein: 12. A table indicating, for each type of data, whether or not the history information of an item is affected for each type of data, wherein the first determining step performs the determination with reference to the table. The information processing method according to claim 11, wherein: 13. A program for realizing a data history management process by a computer, wherein a management target item is represented by a multi-layer structure, and data is registered for each item which is an entity of each layer. A code for a management step for managing, a code for a detection step for detecting an update of data managed in the management step, and when the update is detected by the detection step, the data affects the history information of the item. A code of a first determination step of determining whether or not the data is an item, and a first update step of updating history information of an item to which the data belongs when the first determination step determines that the history information is affected. A program characterized by comprising: 14. The program according to claim 13, wherein the updating of the data detected in the detecting step includes a change in the content of existing data and a registration of new data. 15. A second method for determining whether or not data whose update has been detected in the detection step is data for which history management is performed.
14. The method according to claim 13, further comprising: a code of a determination step; and a code of a second update step of updating the history of the data when it is determined that history management is performed in the second determination step. The program described. 16. A program code for providing a table indicating whether or not the history information of an item is affected for each type of data, wherein the first determination step refers to the table, 14. The program according to claim 13, wherein it is determined whether or not the data affects the history information of the item. 17. The first determining step determines whether or not the data affects history information of an item based on a type of the data and a type of an item to which the data belongs. The program according to claim 13, wherein: 18. A program code for providing, for each type of data, a table indicating whether or not the history information of the item is affected for each type of data, wherein the first determination step includes: The program according to claim 11, wherein the determination is performed with reference to the program.