Abstract:
A data information management system for 2D/3D model data which unwarily manages design information in the form of bulk data. The system allows for real time information transmission of device/component data and eases data cooperation between the design side and the manufacturing side. The unitary management of the management information of model data is performed by a common metaserver. A plurality of bulk servers respectively maintain, for example according to category, the individual model data which has been designed. Workstations, which access design information, acquire management information of model data from the metaserver. Based on the management information, the workstations access the appropriate bulk server which maintains the required model data. During implementing/updating of the model data, management information is registered by the metaserver, and model data is stored in the bulk servers. The metaserver, bulk servers, and workstations perform communication via a WAN or LAN network.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of Japanese Application No. 9-169335 which is hereby incorporated by reference. 
     BACKGROUND OF THE INVENTION 
     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. 
     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. 
     In such a design/manufacturing system, the principal technology is typically one of the following: 
     (a) In work stations loaded with a 3-dimensional modeling system, 3-dimensional model data is managed by independent data management methods. 
     Management is limited to the individual work stations. 
     (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. 
     (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. 
     The technology involved with option (a) has the following problems: 
     #1: The same component information is scattered among various workstations, making centralized data management is impossible. This also implies the duplication of work. 
     #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. 
     #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. 
     #4: Because there is no unitary management of the device and components, the change process, etc., of model data is individually carried out. 
     The technology involved with option (b) has the following problems: 
     #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. 
     #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. 
     The technology involved with option (c) has the following problems: 
     #1: Devices and components using common components cannot be managed. 
     #2: Notification of changes in common components is slow, increasing development time, hindering of component preparation. 
     SUMMARY OF THE INVENTION 
     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. 
     It is also an object of the present invention to provide smooth data cooperation between the design and manufacturing stages. 
     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. 
     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. 
     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. 
     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. 
     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. 
     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. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     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: 
     FIG. 1 is a block diagram of the basic concept of the present invention. 
     FIG. 2 is a block diagram of the present invention. 
     FIGS. 3A and 3B are diagrams illustrating a device and its related metadata, respectively. 
     FIG. 4 is a diagram showing the relationship between metadata and bulk data. 
     FIG. 5A is a flow chart of the operation of a component constitution information definition processor. 
     FIG. 5B is a diagram of a component constitution relationship. 
     FIG. 6A is a flow chart of the operation of an object information/attribute information definition processor. 
     FIG. 6B is a block diagram of a definition of a component. 
     FIG. 7A is a flow chart of the operation of a model data import processor. 
     FIG. 7B is a diagram showing the relationship between the metaserver and the bulk server. 
     FIG. 8 is a diagram illustrating a model data export process. 
     FIGS. 9A and 9B are flow charts of the operation of a model data export processor. 
     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. 
     FIG. 11 is a flow chart of the operation of a common component change notification processor. 
     FIGS. 12A,  12 B, and  12 C are illustrations of the various master tables used in the present invention. 
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
     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. 
     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. 
     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. 
     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). 
     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 . 
     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. 
     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. 
     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 a 1 , a 2 , a 3 , and that component a 1  comprises components all, a 12 , while component a 2  comprises components a 21 , a 22 . 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. 
     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&#39;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. 
     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&#39;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. 
     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 a 1  and a component a 2 . 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, a 1  and a 2 . 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. 
     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, a 1 , a 2  of respective components are linked with data (objects) having object numbers x 1 , x 2 , x 3 . Attribute information y 1 , y 2 , y 3  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 . 
     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 a 1  and component number a 2  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. 
     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. 
     The model data import processor  33  imports/transfers bulk data (model data) to the bulk server  20  defined in the bulk location information. 
     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.  5 B. 
     In step S 1 , 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 S 2  and S 3 , 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 a 1  and component a 2  are defined, while for unit b components b 1  and b 2  are defined. Finally, in step S 4 , a request to the metaserver  10  is issued to store the definition information of the components in the metadatabase  11 . 
     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. 
     In step S 10 , a component number is specified to link the object. Next, in step S 11 , a unique object number is defined. In step S 12 , the representative object implementation tool, design date, designer, object name and other object data attributes are specified. In step S 13 , 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 S 14 , the metaserver  10  is requested to store the object number and associated data attributes (defined in step S 12 ) and the location management information (acquired in step S 13 ). 
     FIG. 6B is a diagram showing the definition of a component. The object number aa 1  is assigned to component a 1 . Object data attribute including: prepared CAD software name; design date; and object location information (WS 1 :/usr/tmp) are defined for the object number. 
     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 . 
     In step S 20 , a storage location is specified for the imported model data. Next, in step S 21 , model data in the workstation  30  is stored and a file name is specified. Finally, in step S 22 , the model data from a specified storage location is imported/transferred to the bulk server  20 . 
     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. 
     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)). 
     FIG. 9A is a flow chart of the operation of the model data export processor  34 . In step S 30 , an export component number is specified. In step S 31 , an object number is specified. Next, in step S 32 , an export destination is specified. In step S 33 , 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 . 
     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 S 40 , an export component number/object number is specified. In step S 41 , an export destination is specified. When, in step S 42 , an object number was specified, the process proceeds to step S 43  and a component number is found from the object number. In any event, in step S 44 , a constitution tree information is located on the metaserver  10  as used and a top specified component number. 
     In step S 45 , attribute information is found for the object (based on the object number) suspended in the constitution tree. In step S 46 , 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 S 45  and the process is repeated for the next object number. 
     If the implementation tool of the object implements 3-dimensional data the process proceeds to step S 47  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 S 48 , 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 S 45 . Otherwise, the process end in step S 49 . 
     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. 
     In step S 50 , an object number of an object which may be changed is specified. In step S 51 , the user authority master table  14 , managed by the metaserver  10 , is consulted. Then, in step S 52 , the attribute of the specified object and the data of the user authority master table  14  is verified. A determination is made in step S 53 , 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 S 54  and the object editing process is performed. If the change is not approved, in step S 55  the user is notified that the change is impossible, and the process ends in step S 56 . 
     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). 
     In step S 60 , the object number, of the component which has changed, is specified. In step S 61 , 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 S 62 , it is determined whether the specified object number relates to a common component. If, in step S 62 , there are no common components, the process ends. 
     If, in step S 62 , there are common components, it is determined in step S 63  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 S 64 , and the process ends. 
     If the changer is unitary management, the process proceeds to step S 65 , and editing the object is performed. In step S 66 , update information within the common components information master table  13  is updated. Continuing, in step S 67 , the accounting destination of the component is looked up. In step S 68 , the component attribute of the accounting destination found. In step S 69 , a mail address of the accounting destination component attribute. Subsequently, in step S 70  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 S 71 . 
     FIGS. 12A,  12 B and  12 C show examples of the various master tables in the metadatabase  11 . 
     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. 
     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. 
     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. 
     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,  12 B and  12 C is used only by way of example, and the master tables can, of course, have various other information in various formats. 
     In accordance with the present invention the following effects are achieved: 
     (1) Because the series of relationships from constitution component number to object number and object data are maintained, data cooperation becomes a reality. 
     (2) It becomes possible to manage the device or components by constitution information regarding the device or components. 
     (3) It becomes possible to extract 3-dimensional groups from device/component constitution and object information. 
     (4) The management of changes of common components is easily performed and notification of changes is performed in real time. 
     (5) Because metadata information and the bulk data information unwarily managers, it is unnecessary to manage them individually. 
     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.