Design information management system having a bulk data server and a metadata server

[0002] This application claims the benefit of Japanese Application No. 9-169335 which is hereby incorporated by reference.

[0003] The present invention relates to a design information management system, a design information access device and a program memory medium. More specifically, the present invention relates to a design information management system which performs design information management as a data transmission method from a design stage to a manufacturing stage.

[0004] For manufacturing devices having various constituent components, the designer (or design group also more generically referred to as the design department) designs the individual components using 3-dimensional CAD software and the like, and delivers drawings of a designed 3-dimensional model data to a manufacturing group (manufacturing department). The manufacturing group, consulting the design information contained in the drawings, performs manufacture of the devices and their constituent components.

[0005] In such a design/manufacturing system, the principal technology is typically one of the following:

[0006] (a) In work stations loaded with a 3-dimensional modeling system, 3-dimensional model data is managed by independent data management methods.

[0007] Management is limited to the individual work stations.

[0008] (b) Drawings are prepared as manufacturing data from individual 3-dimensional model data. The manufacturing drawings are managed and intensified for distribution using a separate computer. The printed out paper drawings are then distributed to the manufacturing positions.

[0009] (c) The common component data of plurality of devices or components used in common, provides data to the design side based on common component management provision.

[0010] The technology involved with option (a) has the following problems:

[0011] #1: The same component information is scattered among various workstations, making centralized data management is impossible. This also implies the duplication of work.

[0012] #2: When designing components which resemble existing components whose model data are not in the industrial workstations, it is impossible to utilize existing model data.

[0013] #3: Because design changes are individually incorporated into the model, it is difficult to grasp the effects of the individual components which constitute the device as a whole. The problem is multiplied when the various individual components are being designed on a high number of different individual workstations.

[0014] #4: Because there is no unitary management of the device and components, the change process, etc., of model data is individually carried out.

[0015] The technology involved with option (b) has the following problems:

[0016] #1: Because the distributed manufacturing data are paper drawings, data has to be transmitted to a workstation, which performs special processing, for practical use of this raw data.

[0017] #2: Because the computer used for management of manufacturing drawings and the computer used for creation and storage of the 3-dimensional model data are different, there is no linking relationship between the drawings management information and the 3-dimensional model data.

[0018] The technology involved with option (c) has the following problems:

[0019] #1: Devices and components using common components cannot be managed.

[0020] #2: Notification of changes in common components is slow, increasing development time, hindering of component preparation.

[0021] Accordingly, it is an object of the present invention to provide unitary management of design information bulk data, making real time information transmission of device/component data possible.

[0022] It is also an object of the present invention to provide smooth data cooperation between the design and manufacturing stages.

[0023] Additional objects and advantages of the invention will be set forth in part in the description which follows, and, in part, will be obvious from the description, or may be learned by practice of the invention.

[0024] Objects of the present invention are achieved in a design information management system having a design information metadata for design information management, 3-dimensional model data which cooperates with the metadata. The metadata includes constitution management information which indicates the constitution of the device including the components of the device. The metadata, including constitutional management information, and location information, are stored in a database on a common metaserver. 3-dimensional model data, prepared during the design stage, are stored in bulk servers. The bulk servers may be divided up and assigned to various departments. A design access device used during the design or manufacturing stages, obtains the location data for each constituent component of a device from the metaserver via a network. Based on the location data the design access device extracts, as necessary, the model data from the database of a bulk server which stores the model data.

[0025] Objects of the present invention are also achieved in a system, as set forth above, using attribute information, stored in the metaserver, giving user authority information indicating the ability (i.e., propriety) of a user to make changes to a component object. The design information access device, when design information is updated, consults the user authority information.

[0026] Objects of the present invention are achieved in a system, as set forth above, using attribute information including information showing whether a component is a common component, i.e., whether the component is used in a plurality of devices or components. The design information access device, when design information is updated, checks whether the updated design information relates to common components. When the component is a common component, the change of the common component is notified to the other users or managers of the common component.

[0027] Objects of the present invention are also achieved in a design information access device in which model data is exported/transferred from a bulk server based on constitutional information relating to the device and components which the metaserver manages. An extraction process extracts, in batch form, the model data relating to the component group, i.e., those that have a parent or child relationship to the component at issue.

[0028] Objects of the present invention may also be achieved in a program stored on a suitable information medium which a computer can read out. The program accesses constitutional information relating to the devices and components. Attribute information containing information of storage locations of model data of objects relating to these devices and components is stored in a metaserver. Based on the information of storage locations in the attribute information, new or updated model data is imported by the program. Based on the information of storage locations in the attribute information, model data is extracted by the program from the appropriate bulk server and transferred to a requesting workstation.

[0029] These and other objects and advantages of the invention will become apparent and more readily appreciated from the following description of the preferred embodiments, taken in conjunction with the accompanying drawings of which:

[0030] FIG. 1 is a block diagram of the basic concept of the present invention.

[0031] FIG. 2 is a block diagram of the present invention.

[0032] FIGS. 3A and 3B are diagrams illustrating a device and its related metadata, respectively.

[0033] FIG. 4 is a diagram showing the relationship between metadata and bulk data.

[0034] FIG. 5A is a flow chart of the operation of a component constitution information definition processor.

[0035] FIG. 5B is a diagram of a component constitution relationship.

[0036] FIG. 6A is a flow chart of the operation of an object information/attribute information definition processor.

[0037] FIG. 6B is a block diagram of a definition of a component.

[0038] FIG. 7A is a flow chart of the operation of a model data import processor.

[0039] FIG. 7B is a diagram showing the relationship between the metaserver and the bulk server.

[0040] FIG. 8 is a diagram illustrating a model data export process.

[0041] FIGS. 9A and 9B are flow charts of the operation of a model data export processor.

[0042] FIG. 10 is a flow chart of the operation of an object processor which checks whether an object change is permissible, i.e., checks the propriety of object changes.

[0043] FIG. 11 is a flow chart of the operation of a common component change notification processor.

[0044] FIGS. 12A, 12B, and 12C are illustrations of the various master tables used in the present invention.

[0045] Reference will now be made in detail to the present preferred embodiment of the present invention, examples of which are illustrated in the accompanying drawings, wherein like reference numerals refer to like elements throughout.

[0046] FIG. 1 is a block diagram of the basic concept of the present invention. A metaserver 10 unwarily manages management information regarding the model data. Model data expresses the shape of an item, while design data is a group of data, including model data, that relate to the design and manufacturing of a device (typically made up of various items). Model data when viewed as a whole forms bulk data. In general, individual model data comprises the actual data for creating/recreating a CAD drawing. A metadatabase 11 maintains the metaserver 10 including management information of the model data in, for example, a relationship database. Bulk servers 20 (arranged by department) store the individual model data. Bulk data 21 is stored on the bulk servers 20, and, as set forth above, consist of 2-dimensional or 3-dimensional model data, for example, 3-dimensional CAD data and the like.

[0047] A workstation 30 acquires the management information regarding the model data from the metaserver 10 and, based on the management information, obtains the model data, for processing, by accessing the bulk server 20. In the example shown in FIG. 1, workstations 30-1, 30-11, 30-12 form a design system (for use by the design department), while workstations 30-2, 30-21 form a manufacturing system (for use by the manufacturing department in the manufacturing plant). A printer/plotter 50 on the manufacturing system outputs the completed manufacturing drawings.

[0048] The entire system is tied together via a network 40, which for example, comprises a WAN or a LAN. In other words, the workstations 30, the common metaserver 10, and the bulk servers 20 (which are located according to departments, that is, Department A (design, for example), Department B (manufacturing, for example), are connected by the network 40. The location information of the model data and constitution information regarding the model data (single stage/multi-stage component constitution, object drawing number, and the like) are stored in the metadatabase 11 on the common metaserver 10. The actual model data, prepared by the design department on the design system, is stored in the databases of the bulk server 20 (depending on the department).

[0049] In general, the design and manufacture departments, when the design data is used by a workstation 30 in one of the departments, access the bulk data 21 on the appropriate bulk server 20 using location management information extracted from the metadatabase 11.

[0050] Control of the ability of individual users to modify the model data is provided for in management information regarding common components, which the metaserver 10 manages. By modifying user authority information the system manages the propriety of any requested modification. Moreover, when a design system has modified a common component (in the design category or manufacturing category of other components) a common component modification notification is issued to other users of the common component, to draw their attention to the change. This notification may be issued using e-mail or other such system, BBS etc.

[0051] The metaserver 10 centrally manages all the model data and related design information comprising the bulk data 21. Because management is dispersed from the various categories of bulk servers 20, real time information transmission of device/component data is possible between the various departments. In comparison with centralizing the metadata and all of the bulk data onto one host processor, load dispersion is possible. Moreover, because bulk data can be located very close to the place of use, communication costs are reduced as only the management information is remotely retrieved.

[0052] FIG. 2 is a block diagram of the present invention. Component constitution information 12, stored in the metadatabase 11, indicates what other components are in a particular device and component. For example, using a tree structure, it can be seen that device A comprises components a1, a2, a3, and that component a1 comprises components all, a12, while component a2 comprises components a21, a22. The term “device” typically refers to the top level structure in any particular diagram/drawing/figure, while the term “component” typically refers to the subparts of a device or component.

[0053] A common component information master table 13 stores information relating to components used in common among various devices or components, typically referred to as “common components”. A user authority master table 14 stores information about each users'access authority to the model data. A model data storage destination master table 15 stores the storage destination, i.e., location, information of the model data in bulk data 21 on the bulk servers 20. The master tables 13, 14, and 15 are typically tables in a relational database, but are not necessarily limited to such. However, if the master tables 13, 14, and 15 are part of a relational database, a general purpose relational database management system may be located in the metaserver 10, thereby allowing easy access to the necessary data from each workstation 30 via a relational database access function.

[0054] Each workstation 30 which accesses design data has a component constitution information definition processing means 31 which defines the designed components or devices constitution information, i.e., what subparts each device or component is constructed from. An object information/attribute information definition processor 32 defines the designed object's information and associated attribute information. A model data import processor 33 imports/transfers designed model data from the workstation 30 to the bulk server 20. A model data export processor 34 which exports/transfers model data from the bulk server 20 to the workstation 30. A processor 35 checks the propriety of model changes, i.e., where a user has authority to perform a change to a device or a component. Finally, when the management information or model data of a common component has been changed, a common component change notification processor 36 notifies the appropriate users and managers that a common component was changed. The processors 31, 32, 33, 34, 35, and 36 are typically formed in software, but can comprise individual hardware components, such as microprocessors.

[0055] FIGS. 3A and 3B are diagrams of a device and its associated metadata. Looking at FIG. 3A, bulk data 21 is divided up into model data which has been prepared by a 3-dimensional CAD system or the like. In this example, the model data describes a device (called “assembly component a”) which comprises a component a1 and a component a2. Looking at FIG. 3B, the related metadata comprises management information including attribute information regarding the objects in the component or device, i.e., the components a, a1 and a2. The metadata contains, for each component, a component number, a component name, a name of the CAD software or the like program which prepared the model data describing the component, a host memory location of the model data, a directory name and a file name (or other indication of a location in the host), the name of the owner group which is the manager of the model data, and other pertinent information.

[0056] FIG. 4 is a diagram showing the relationship between metadata and bulk data. The objects formed by the model data, and the like, are simply treated as “objects”. Each component is managed using a hierarchical structure. The component numbers a, a1, a2 of respective components are linked with data (objects) having object numbers x1, x2, x3. Attribute information y1, y2, y3 are defined for, and linked to, each object. The attribute information comprises tool names drawn in reverse order, location sites of model data, ownership group names and other pertinent information. The location sites points to the appropriate set of data in the bulk data 21 for each object. As set forth above, the metadata is stored in the metaserver 10, while the bulk data 21, for example, is stored in a bulk server 20 of the appropriated department. Device and component constitution information are controlled by the link relationships between the component numbers, object numbers, their attribute information and the raw data (model data) as shown in FIG. 4.

[0057] The component constitution information definition processor 31, as shown in FIG. 2, defines the parent/child relationship of the various components in a device. In the present example, components constituted from component number a1 and component number a2 are defined in metadata and registered in the metaserver 1. Each workstation 30 can grasp the complete or partial constitution information of any design object manufacturing object, i.e., the various devices and components that from the object.

[0058] The object information/attribute information definition processor 32 defines the object number of each component. The object number is defined as metadata to maintain a cooperative relationship between the component number and the object number. The object information I attribute information definition processor 32 also defines, for each object number, attribute information including: implementation tool information, authority information, management basis information (ownership group name information), and bulk location information.

[0059] The model data import processor 33 imports/transfers bulk data (model data) to the bulk server 20 defined in the bulk location information.

[0060] FIG. 5A is a flow chart of the component constitution information definition processor 31. The component constitution information definition processor 31, defines the parent/child relationship of the constitutional components as shown, by example, in FIG. 5B.

[0061] In step S1, a device constituent parent component number is specified. For example, in the component constitutional relationship shown in FIG. 5B, the component number of device (A) is specified. Next, in a loop comprising steps S2 and S3, the child components which constitute the parent component are specified in a sequential hierarchy. In the example shown in FIG. 5B, the next unit-a and unit-b of device A are defined. Furthermore for the unit-a, component a1 and component a2 are defined, while for unit b components b1 and b2 are defined. Finally, in step S4, a request to the metaserver 10 is issued to store the definition information of the components in the metadatabase 11.

[0062] FIG. 6A is a flow chart of the operation of the object information/attribute information definition processor 32. The object information/attribute information definition processor 32, defines the object number for each component and in addition, for each defined object number, defines the data storage destination (machine name/location place), user authority information, implementation tool name and other pertinent attribute information.

[0063] In step S10, a component number is specified to link the object. Next, in step S11, a unique object number is defined. In step S12, the representative object implementation tool, design date, designer, object name and other object data attributes are specified. In step S13, bulk server host names, bulk server storage places, and user access group information are acquired from the model storage destination master table 15, and the user authority master table 14 in the metadatabase 11. Additionally, the acquired data and the newly defined data is verified. Continuing, in step S14, the metaserver 10 is requested to store the object number and associated data attributes (defined in step S12) and the location management information (acquired in step S13).

[0064] FIG. 6B is a diagram showing the definition of a component. The object number aa1 is assigned to component a1. Object data attribute including: prepared CAD software name; design date; and object location information (WS1:/usr/tmp) are defined for the object number.

[0065] FIG. 7A is a flow chart of the model data import processor 33. The model data import processor 33, based on the information defined by the object information/attribute information definition processor 32, imports/transfers the model data to the bulk server 20 from the workstation 30. As shown in FIG. 7B, the constitutional information of each component, object number and attribute info, and a series of connections (all stored on the metaserver 10) are formed with the model data file in the bulk server 20.

[0066] In step S20, a storage location is specified for the imported model data. Next, in step S21, model data in the workstation 30 is stored and a file name is specified. Finally, in step S22, the model data from a specified storage location is imported/transferred to the bulk server 20.

[0067] FIG. 8 is a diagram illustrating a model data export process. The model data export processor 34 acquires for its own workstation 30, model data (from the bulk data 21) referenced by a specified object number. In particular, in the case of 3-dimensional model data, one model datum is not sufficient, so there has to be a series of transfers of bulk data to form a complete assembly model or a component model (parts model). In accordance with the present invention, the constitution number (i.e., the component number) for a specified object number, acts as top information of a constitutional component, and indexes the required lower rank components. Based upon attribute of object numbers linked to lower rank components data groups may be extracted batchwise.

[0068] To export model data from the bulk servers 20, the workstation 30, using a specified component number or object number, acquires object location information from the metaserver 10 (arrow (a)). Next, the workstation 30, requests access from a bulk server 20 in which the required bulk data 21 is stored (arrow 8(b)). The required bulk data 21 located in the bulk server 20 is then copied into an export destination region in the workstation 30 (arrow (c)).

[0069] FIG. 9A is a flow chart of the operation of the model data export processor 34. In step S30, an export component number is specified. In step S31, an object number is specified. Next, in step S32, an export destination is specified. In step S33, using the location site of the bulk data, obtained from the metaserver 10, bulk data is copied from the bulk server 20 to the export destination, using a workstation 30.

[0070] FIG. 9B shows the process with respect to export of 3-dimensional model data, requiring a batch collection of model data describing a group of plural components. In step S40, an export component number/object number is specified. In step S41, an export destination is specified. When, in step S42, an object number was specified, the process proceeds to step S43 and a component number is found from the object number. In any event, in step S44, a constitution tree information is located on the metaserver 10 as used and a top specified component number.

[0071] In step S45, attribute information is found for the object (based on the object number) suspended in the constitution tree. In step S46, a determination is made as to whether the implementation tool of the object, based on the attribute information, is one which implements 3-dimensional model data. If the object does not implement 3-dimensional model data a return is made to step S45 and the process is repeated for the next object number.

[0072] If the implementation tool of the object implements 3-dimensional data the process proceeds to step S47 and, based on the location site of the bulk data obtained from the metaserver 10, bulk data is copied from a bulk server to the export destination. In step S48, it is determined whether the extraction has ended for the components of all the constitution trees. If the extraction has not ended, a return is made to step S45. Otherwise, the process end in step S49.

[0073] FIG. 10 is a flow chart of the operation of the processor 35 which checks whether an object change is permissible. The processor 35 which checks propriety of the object changes checks, for any object specified by the user, whether changes are approved for the user based on the attribute information in the user authority master table 14. If there is no such authority, the user is notified that editing is impossible.

[0074] In step S50, an object number of an object which may be changed is specified. In step S51, the user authority master table 14, managed by the metaserver 10, is consulted. Then, in step S52, the attribute of the specified object and the data of the user authority master table 14 is verified. A determination is made in step S53, whether the change of the object is approved, for the user, using the user authority master table 14. If the change is approved, the process proceeds to step S54 and the object editing process is performed. If the change is not approved, in step S55 the user is notified that the change is impossible, and the process ends in step S56.

[0075] FIG. 11 is a flow chart showing the process of the common component change notification processor 36. The common component change notification processor 36, when the subject object is a common component of a 3-dimensional model and when a common component manager (or user) has changed the information of this component, looks up the object number(s) which use(s) the changed component and notifies the changes to the users of the affected object(s).

[0076] In step S60, the object number, of the component which has changed, is specified. In step S61, master information of the component, designated by the object number, is acquired from the common components master table 13 on the metaserver 10. In step S62, it is determined whether the specified object number relates to a common component. If, in step S62, there are no common components, the process ends.

[0077] If, in step S62, there are common components, it is determined in step S63 whether the changer of common components is unitary management. If the changer is not unitary management, the last update information of common components is displayed in step S64, and the process ends.

[0078] If the changer is unitary management, the process proceeds to step S65, and editing the object is performed. In step S66, update information within the common components information master table 13 is updated. Continuing, in step S67, the accounting destination of the component is looked up. In step S68, the component attribute of the accounting destination found. In step S69, a mail address of the accounting destination component attribute. Subsequently, in step S70 a change notification of the common components is issued. The information is typically issued via e-mail. The e-mail recipient is notified of, and able to cope with, the changes of common components. The process ends in step S71.

[0079] FIGS. 12A, 12B and 12C show examples of the various master tables in the metadatabase 11.

[0080] The common components information master table 13, as shown in FIG. 12A, is indexed, according to common component number, and has entries for print number, designer, design date, number of management group, and the date of last update.

[0081] The user authority master table 14, as shown in FIG. 12(B), is indexed by user and stores login IDs, passwords, access groups (office) affiliated to, mail address, access groups (office) affiliated to, mail address, roles (for example, designer or approver), a role number of user, and the like. The role typically is used as access authority information, but access authority may be determined by other formalities or procedures.

[0082] The model data storage destination master table 15, as shown in FIG. 12(C) is indexed by access groups and stores machine names of access host, access volumes (directory and the like), and the ip addresses of the access host.

[0083] The attribute information shown in FIG. 4, maintains the information showing records (entries) of tables 13, 14 and 15. Furthermore, the table constitution shown in FIGS. 12A, 12B and 12C is used only by way of example, and the master tables can, of course, have various other information in various formats.

[0084] In accordance with the present invention the following effects are achieved:

[0085] (1) Because the series of relationships from constitution component number to object number and object data are maintained, data cooperation becomes a reality.

[0086] (2) It becomes possible to manage the device or components by constitution information regarding the device or components.

[0087] (3) It becomes possible to extract 3-dimensional groups from device/component constitution and object information.

[0088] (4) The management of changes of common components is easily performed and notification of changes is performed in real time.

[0089] (5) Because metadata information and the bulk data information unwarily managers, it is unnecessary to manage them individually.

[0090] Although a preferred embodiment of the present invention have been shown and described, it will be appreciated by those skilled in the art that changes may be made in this embodiments without departing from the principles and spirit of the invention, the scope of which is defined in the claims and their equivalents.