JP4740731B2 - Method and system for graphically navigating between stored objects - Google Patents

Description

  The present invention relates to the field of computer programs and computer systems, and more particularly to product lifecycle solutions that include a database of data representing modeled objects.

  Several systems and programs for the design of parts, or assemblies of parts, such as those provided by DASSAULT SYSTEMS under the CATIA trademark, are commercially available. These so-called computer aided design (CAD) systems allow users to build and manipulate complex three-dimensional (3D) models of objects, or assemblies of objects. For this reason, CAD systems use edges or lines, and in some cases, surfaces to provide a representation of the modeled object. Lines or edges can be represented in various ways, for example, non-uniform rational B-splines (NURBS). These CAD systems manage a part, or assembly of parts, as a modeled object, which is basically a geometry specification. Specifically, the CAD file includes a specification, a geometry is generated from this specification, and a representation is generated from the geometry. The designation, geometry, and representation can be stored in a single CAD file or multiple CAD files. The CAD system includes a set of graphic tools for displaying modeled objects to the designer, these tools are dedicated to the display of complex objects, and the typical size of a file representing an object in the CAD system is , In the megabyte range for the part, the assembly may include thousands of parts. The CAD system manages a model of an object stored in an electronic file.

  There are also product lifecycle management solutions (PLMs), such as those offered by DASSAULT SYSTEMS under the trademarks CATIA, ENOVIA, and DELMIA, which are engineering hubs that organize product engineering knowledge A manufacturing hub that manages manufacturing engineering knowledge, and a business hub that enables enterprise integration and enterprise connection to both engineering and manufacturing hubs. Overall, these systems provide an open object model that links products, processes, and resources to drive dynamic knowledge-based product creation that promotes optimized product definition, manufacturing preparation, products, and services. (Product creation) and decision support. Such PLM solutions include a product relational database. The database includes a set of text data and relationships between the data. Data typically includes technical data associated with a product group, which is ordered as a hierarchy of data and indexed so that it can be searched. The data represents a product group, which is often a modeled object.

  One of the problems with such PLM solutions is that the user of the system may want to display the product group and may want to have a 3D graphical representation of the product group as needed. It is to have sex. DASSAULT SYSTEMS, under the name DMU Review, provides a set of CAD tools that allow users of PLM solutions to work with 3D graphic representations of products managed in the system. Those tools rely on the use of digital mock-ups pre-computed from the CAD representation of the product family. These tools further provide a limited set of graphical representations of the product family, in particular, DMU systems typically provide a 3D representation of the product family. In a system sold under the name DMU Navigator, a user can display a 3D representation of a complex product, which is a hierarchical tree representing various products or parts of the displayed product. Further included. This system provides the user with a 3D representation of the product stored in the database. However, the navigation in this system can be further improved.

  Using CAD tools such as DMU review or DMU Navigator, the user can only navigate between parts or products loaded into the system. Therefore, the range of navigation is very limited. This is because if the user wants to navigate among all available product groups or assemblies, the user must load all those products or assemblies, Because of hardware constraints and transaction problems, it is impossible.

  In fact, the DMU product family is limited with respect to the scope of navigation. Specifically, the user first opens a DMU session where a limited list of parts and assemblies is defined. This allows the system to subsequently calculate and store representations used in DMU navigation. Navigation is limited to the list of parts and assemblies that were defined when the DMU session was opened.

  In addition, the user may want to know, for example, where a given part is also used, i.e., to which other modeled objects the part is incorporated. The actual CAD tool allows the user to navigate between parts or products primarily according to a “consisting of” relationship. Databases used in product data management (PDM) systems make it possible to query for all types of relationships between parts or products, and the navigation range of the databases is the largest possible. Become. In fact, the user can gain access to all parts, products or assemblies.

  Still, the databases do not allow the user to navigate easily. This is because data does not have a graphic representation. Data is identified by file name or file type, which may not be valid enough to accurately identify the item the user is looking for.

  The problem of navigating in organized data has been extensively discussed in the literature.

  For example, US Pat. No. 6,628,304 provides a method and apparatus for presenting hierarchical data to a user via a graphical user interface. The preferred embodiment represents hierarchical data associated with a computer network and is provided to a user as part of a network management software application. In the interface, hierarchical data starts at one or more top-level nodes, displays child nodes, displays child children nodes, and so on. It is expressed by a group of nodes extending to As for the arrangement of the nodes on the graphical user interface, various hierarchical levels are expressed by reduction and enlargement, and the nodes do not interfere with each other spatially. Navigation in hierarchical data is provided by allowing the user to select any visible node, and when selected, zooms in or zooms in on the selected node as a centrally located node on the interface Out is executed. Then, the child nodes in the lower hierarchy level that were not visible before the selection are made visible up to a predetermined number of levels in the hierarchy.

  U.S. Patent No. 6,057,059 relates to an interface for an interactive display device that includes at least two levels, each having at least two objects that can be displayed on the interactive display device, the interface comprising: It further includes means for continuously displaying the entire set of objects at the same level by displaying once. The object group (s) at one level includes at least one icon set including a plurality of icons to be displayed on the interactive display device, each icon being activated to access information. Possible, including an image, preferably a legend, and more preferably a pictogram representing the nature of the information accessed when the icon is triggered.

  Non-Patent Document 1 discusses a technique for visualizing a hierarchical information structure.

  The methods, apparatus, or techniques discussed in the above references, however, can be used in a product lifecycle management system, ie, a database of systems that contain complex modeled objects stored in a database that should be displayed graphically. Does not allow you to navigate in.

  Patent Document 2 displays a source node having a connection to an included node group, and displays a linked node group peripherally inside and around the source node to which the node group is combined. To calculate and perform a focus position for each of the included nodes and linked nodes, to display the first included node at the inclusion start angle, and to the first A method is provided for displaying linked nodes at an adjacency start angle.

  US Pat. No. 6,057,031 is animated to optimize, facilitate, and simplify the display and searching of a hierarchy of information that can be accessed by an electronic device via user input. It is intended for a configurable user interface. The underlying methods are, for example, displaying multiple nodes in the viewing area, receiving user input to select one of the displayed nodes in the viewing area, selecting multiple nodes One node is positioned at the center of the display area, and the node positioned at the center includes a focus node. The plurality of nodes include nodes having a plurality of hierarchical relationships.

  Although the aforementioned interface allows navigating within organized data, the data is not appropriate for PLM requirements that represent complex modeled objects to be represented graphically. In particular, the proposed centering or focus does not allow the user to clearly remember its progress through the organized data. Moreover, such an interface is not appropriate to allow a user to distinguish between different relationships that link data.

International Patent Application Publication No. 98/22866 Specification US Patent Application Publication No. 2002/0054166 US Patent Application Publication No. 2002/0145623 G., Mackinlay, J., and Card, S., "Cone trees: animated 3D visualizations of hierarchical information", Proc. CHI'91, Human Factors in Computing Systems (1991), pp. 189-202

  For this reason, according to the limitations of the existing solutions described briefly above, among other things, the user in a database in a product lifecycle management system that stores complex modeled objects via interrelated data There is a need for an improved navigation solution that allows navigating. This solution should preferably be user friendly and allow the user to locate and display objects in an easy and intuitive manner. This solution should further allow the user to remember the chain through the organized data and, if necessary, distinguish between different types of relationships that link the data.

  In one embodiment, therefore, the present invention provides a database that stores modeled objects and relationships between the objects, and a graphical user interface suitable for displaying to a user a graphical representation of a hierarchy of stored objects. The graphical user interface is adapted to display a group of objects associated with the selected object when the displayed object is selected by the user in a hierarchy. At a given level, the displayed objects are distributed according to their weights, and the displayed object weights are displayed in the graphical representation of the objects in the hierarchy. It depends on the number of grandchildren.

In other embodiments, a product lifecycle management system according to the present invention may include one or more of the following features. That is,
The graphical user interface is adapted to display a graphical cue representing a hierarchy of displayed objects, as well as the descendants of the objects in the hierarchy displayed in the graphical representation;
The displayed objects have a rendering size that depends on their weights,
The weight of the displayed object depends on the size of the descendant of the object in the hierarchy displayed in the graphic representation,
The graphical user interface is adapted to display objects using a unique scale for all objects,
The graphical user interface is adapted to display a 3D representation of the object;
The graphical user interface is adapted to morph from the first representation of the displayed object to the representation of the group of objects associated with the displayed object when the displayed object is selected by the user. Is done.

  The present invention further proposes a method for navigating within a database of a product lifecycle management system, where the database stores modeled objects and relationships between the objects, and the PLM system stores A graphical user interface suitable for displaying to the user a graphical representation of the hierarchy of the selected objects, the method comprising: selecting a first object and a first relationship; and according to the first relationship Finding a descendant of the first object in the hierarchy, including a second group of objects associated with one object, displaying a representation of the first object including the second group of objects, and One object in the second object group and the second function Selecting a descendant of the selected second object that is a descendant including a third group of objects related to the selected second object via the second relationship; and Displaying a representation of a first object including two object groups and a third object group, wherein the displayed object groups are distributed according to their respective weights, and the object weights are determined by the graphic Depends on the number of descendants of the object in the hierarchy displayed in the representation.

In other embodiments, the method according to the invention may include one or more of the following features. That is,
The object is displayed as a 3D object,
Selecting the first object and the first relationship includes selecting a first layout, and the representation of the second group of objects is a representation in the first layout;
The step of selecting one object in the displayed group of objects and the second relationship includes selecting a second layout, wherein the representation of the third group of objects is the representation in the second layout. Yes,
The layout consists of a straight line layout, an in-place layout, and a group of objects on the disc. The perspective view is an exploded view along the line. Selected from a distributed circular layout expressed in exploded perspective, a 3D miniature 2D layout,
The layout is animated and
The relationship can be the following relationship: “is composed of”, “where used”, “in contact with”, It includes at least two of the relationship “in crash with” and the relationship “impact with”.

  The method according to the invention further comprises the step of calculating and storing a 3D representation of the object.

  The invention further relates to a computer program for carrying out the method of the invention.

  A system embodying the invention will now be described by way of non-limiting example with reference to the accompanying drawings.

  The present invention is directed to a PLM system that includes a group of objects, preferably a 3D object group, and a database that stores relationships between the objects. The PLM system provides a graphical user interface suitable for displaying to a user a graphical representation of a hierarchy of stored objects. When the displayed object is selected by the user, the graphical user interface displays a group of objects related to the selected object. At a given level in the hierarchy, the displayed objects are sorted according to their weights. The weight of the displayed object depends on the number of descendants of the displayed object in the hierarchy that are displayed in the graphic representation. The present invention, among other things, makes it possible to navigate in a database of a PLM system that stores complex modeled objects via data related to each other. Thanks to the weight-dependent principle described above, this solution further enables users to understand their progress through organized data and to understand the relationships between objects in an easy and intuitive way. enable.

As is well known to those skilled in the art with respect to databases used in PLM solutions, such databases include a data set and the relationships between the data in that set. Relationships are often indexed to speed up searches inside the database. From a file standpoint, a relational database does not consist of a single file, but uses a complex file system to store various data and relationships. By “database storing objects”, it should be understood that a portion of the data in the database represents a modeled object group. Such an object group may be a modeled object group of a product or a part, or may be an object group such as a manufacturing process including various steps, and a resource such as a robot for performing the manufacturing step. it can. In a PLM solution, a set of data includes, for example, for a modeled object: That is,
part number,
Manufacturing or procurement information about the product or modeled object,
Reference to drawing or CAD file for product group Version setting data (design iteration history, released version history)
Configuration data (for exploring various configurations of objects)
The relationships in the PLM solution include, among other things, the “consisting of” relationship, which allows creation of a cluster or subassembly of products.

  The relationship also includes a “used in” relationship, also referred to as a “used place” relationship, which represents all subassemblies in which a given product is used. The relationship can also include a “contact” relationship that allows the user to manage contacts between various products within the database. The relationship can include a “collision” relationship where various data indicate that they overlap or collide with each other. This can help find design problems. A relationship can include a part dependency, which represents an impact graph, also known as a “relational design”, when a part is built from another part. . Finally, there can be relationships that represent various data attributes, which include the usual attributes in the PLM solution, such as the material that forms the object, the source of the object (provider, manufacturer, etc.) be able to.

  With respect to the concept of hierarchy, strictly speaking, a hierarchy is identical to a rooted tree structure, for example, all but one element has a single predecessor. However, the term is to be understood here in a looser form to include any partially ordered system, or tangled hierarchy. Intertwined hierarchies are inheritance graphs, for example, objects can belong to multiple sets or supersets. In particular, the various user-selectable relationships allow an object to belong to different sets or have multiple parents in close relationships.

  1 to 3 are examples of explanatory object group views displayed in accordance with embodiments of the present invention.

  Referring to FIG. 1, the GUI 100 is suitable for displaying to a user a graphical representation of an object group, ie, data representing such an object group stored in a database. The GUI 100 is further suitable for displaying a graphical representation of a hierarchy of stored objects.

  The present invention allows a user to navigate between data representing a group of objects via a GUI by displaying a representation of the data, preferably a 3D representation. The data to be displayed can be selected by the user, for example, according to various relationships stored in the database.

  In this regard, the user can select, for example, first data and a first relationship. This can be done thanks to the use of a tree that can be displayed within the GUI 100. Also, the user selects the first data, for example, by entering identification information about the first data, selecting the first data in the list, etc., thanks to another type of user interface It is also possible to do. The relationship can also be selected thanks to any type of user interface, such as a combo-box, icon, special command, or right click. Note that this also applies to the other types of user selections described below unless otherwise specified.

  In response to the selection of the first data and the first relationship, the system displays a representation of the object via the GUI. In this case, the displayed object group is actually the object group represented in the database by the second data related to the first data according to the first relationship. For this purpose, the system uses the relation properties of the database to select all data in the database that is related to the first object in the first relation. Once the second data is identified, the modeled object group represented by the second data is displayed.

  In the illustrative example proposed in FIG. 1, the user selects a given first object (not shown in FIG. 1) consisting of, for example, a set of cylinders and a “consisting of” relationship. can do. In that case, the PLM system searches the database for all data, that is, a group of parts or a group of products that constitute the selected first object. As a result, the PLM system displays the second objects 204 to 210 related to the first object 200 via the above-described relationship via the GUI. The first object 200, eg, the set of cylinders in the examples of FIG. 1 and FIGS. 2 and 3, are exemplary objects that are used for illustrative purposes only. This modeled object includes second objects 204-210 consisting of a superposed set of concentric cylinders.

  For example, the selection of the relationship “consisting of” can optionally be made from a toolbar provided in the GUI 100 (eg, from the toolbar 140).

  Several types of layouts that can be selected by the user can be envisaged. A layout example will be briefly described below, and will be described in detail with reference to FIGS. The layout can be an assembled, regular 3D representation of the object, which can be referred to as an “in-place” layout. The various second objects can otherwise be separated in an exploded perspective view, and the layout can be expanded along a given line (or shown in an exploded view) And the direction of the line can be selected by the user, which can be referred to as an “inline” layout or a “straight line” layout. The layout may also be shown in an exploded view from a given point, eg, along multiple directions from the center of the represented assembly or part, or from the center of the represented assembly or part. Is possible. Such a layout makes it easier for the user to identify and select various second objects. Another possible layout is a miniature layout of various objects. For example, a 2D layout of a 3D miniature representation of an object can be used.

  As in the example of FIG. 1, the second objects 204-210 can be distributed and displayed across the disc or circle 202 to obtain an “in-disc” or circular layout, Such a layout facilitates understanding of the model, helps the user understand the perspective view, and facilitates selection of additional data. A disc can be viewed as a graphical representation of the relationship between displayed objects. This disc 202 further links objects belonging to the same first level (according to a preselected relationship). This level is called “level 1”.

  The layout, in particular the disc 202, can be animated as needed. For this reason, when the user changes the layout or selects a given layout, various objects can move gradually. For example, the parts 204-210 can rotate with the disk 202 about the virtual disk axis. This is useful for understanding the position of various objects and for viewing the objects.

  The type of layout displayed to the user may be preset or selected by the user. One advantageous solution is to allow the user to set a default type of view that is used for all displays. Once a given layout is displayed, the user can be allowed to change the default type of layout to another type.

  The selection of the layout can be manipulated, for example, by first right-clicking on an object, which causes a drop-down list to appear and selecting the desired field in the list.

  Preferably, when a relationship and layout are selected by the user, the same layout is applied to the relationship by default. In selecting another type of relationship, another layout can be selected and that layout is applied to the selected new relationship.

  Furthermore, a 3D representation of each object (part or product) can be calculated as needed. Thereby, calculation time is shortened. Precomputing 3D representations is possible, at least for some of the representations that are expected to be used repeatedly in the database. This may be the actual 3D representation of the subassembly, for example. Such pre-computed representations can be calculated off the fly and stored for access by the system. When a given 3D representation is to be displayed, the representation is first searched among the already stored representations, and if there is no representation to be displayed, the representation is calculated.

  Still referring to FIG. 1, the illustrated GUI 100 can be a normal CAD-like interface with standard menu bars 110, 120 and a bottom toolbar 140 and side toolbar 150. Such menu bars and toolbars include a set of user-selectable icons, each icon associated with one or more actions or functions, as is known in the art.

  Some of these icons 150 are associated with software tools and are adapted to edit and / or represent the displayed objects. The software tools in question can be grouped into a workbench. That is, each workbench includes a different subset of software tools.

  The GUI may further indicate various types of graphic tools, such as graphic tool 130, that may be manipulated by a user to facilitate 3D orientation of object 200.

  Elements represented by reference numerals 100, 110, 120, 130, 140, 150, 200 are also shown in FIGS. 2-16, but will not be further described with reference to those figures. Please keep in mind.

  Referring now to FIG. 2, the user can select one of the displayed second objects 204, 206, 208, 210 and a second relationship. The second relationship can be the same as the first relationship, which can be a default selection, for example. Also, the second relationship can be different from the first relationship. Thus, the second user selection can be similar to the first user selection, but with the second user selection, the selection is performed directly on the representation displayed to the user. Is possible.

  In this regard, the user may select an object 210 in operation, for example, click on the object 210 using a mouse, or pass over the object 210 with a mouse pointer, or even a menu. This can be done by selecting the appropriate command from the bar or popup icon. Other selection means can obviously be implemented.

  Next, via the selected second relationship, a third object associated with the selected second object is searched and identified by the PLM system. A representation 210 of the third object is presented to the user according to the selected layout. Preferably, the layout is the same as before by default, but this can be changed by the user at any time.

  Note that reference numeral 210 in FIGS. 1 and 2 belongs to the same selected object 210, ie, a set of concentric cylinders. However, in FIG. 2, the graphical representation of the selected second object has changed to an exploded view of this object 210 compared to FIG. More specifically, the object 210 can be viewed as a superposed set of concentric cylinders in FIG. 1, but is represented in FIG. 2 as a set of concentric cylinders distributed on a disk or circle 212. ing. That is, the representation of the selected second object 210 in FIG. 2 includes descendants, ie, third objects 213, 214, 216, 218, 220.

  Thus, the disk 212 represents a second level (this level will be referred to as “level 2”) in which the selected second object 210 is shown in an exploded view. Level 2 graphically links the third objects 213, 214, 216, 218, 220 associated with the parent object 210 according to the selected second relationship, in this example “consisting of”. ing.

More generally, I point out the following to clarify the situation: That is,
Level 1 is where the selected first object is shown broken down into second objects,
Level 2 is where the selected second object is shown broken down into a third object,
The same applies hereinafter.

  It should be appreciated that the objects 204-210 are distributed on a large disk according to their weights. Refer to FIG. 1 or FIG. 2 for this. The weight of the displayed objects 204-210 depends on the number of descendants of the objects 204-210 in the hierarchy that are displayed in the graphic representation. Specifically, in FIG. 1, since no descendants of the objects 204-210 are displayed, the same weight is attributed to these objects 204-210.

  Referring to FIG. 2, upon user selection, the object 210 is represented as a set of descendants of the object 210, and the weight attributed to the object 210 is the number of displayed descendants 213, 214, 216, 218, 220. Will be increased accordingly. Thus, the object 210 is provided with more space than the remaining objects 204, 206, 208. As a result, the remaining objects 204, 206, 208 are redistributed onto the large disk 202 according to the same weight, which is smaller than the weight of the object 210. This is because the descendants of the remaining objects 204, 206, 208 are not displayed at all in the graphic representation.

  Note that the size of the large circle 202 in FIG. 2 is preferably increased compared to the size of the circle in FIG. 1, while the scale of the cylinder remains intact. If this is considered to be a simple focus on the new representation of the object 210, there is no change in the distribution of the cylinders 204, 206, 208.

  The smaller disk 212, which will be referred to as an “intermediate disk” in view of future steps, links to the level 2 objects, and as such, it represents the selected second relationship. It is worth pointing out that the hierarchy is built between the second object and the first object by finding and displaying the third group of objects related to the selected second object. . In this regard, the intersection of the two disks 202, 212 defines a hierarchy of the object 210 to be displayed and a cue representing the displayed descendants 213, 214, 216, 218, 220 of the object 210 in this hierarchy. The The view of FIG. 2 provides the user with an immediate understanding of the various relationships between the displayed objects. The user benefits from the graphical representation of the selected relationship on the layout displayed to the user.

  Referring to FIG. 3, the user can be directed to select additional objects 220 and relationships, in this example “consisting of”. In practice, this relationship need not necessarily be selected. This is because this relationship is provided by default. Starting from FIG. 2, by selecting an object 220, the representation of that object is changed to the representation shown in FIG. 3, ie, the “in-disk” of the descendants 224, 226, 228, 230 of the object 220. Switch to view. The offspring, eg the fourth object, consists of cylinders of different sizes and colors. Again, the descendant objects 224, 226, 228, 230 are placed on the smaller disk 222, representing level 3, which provides the same advantages as described above for level 2 and level 1.

  According to the present invention, level 1 objects 204, 206, 208 and level 2 objects 213, 214, 216, 218 are reassigned according to their respective weights depending on the displayed descendants. More specifically, the object 220 is given more space than the objects 213, 214, 216, 218. This is because, unlike the objects 213, 214, 216, and 218, the object 220 displays descendants. On the other hand, the objects 213, 214, 216, 218 are preferably redistributed on the larger disk 212 (compared to the representation of the disk 212 in FIG. 2) because of the larger space provided for the entire object. .

  Similarly, in the representation of FIG. 3, more space is left in object 210 than for objects 204, 206, 208. Preferably, the disc 202 is made larger to allow redistribution of the objects 204, 206, 208.

  If necessary, the scale is kept constant for all objects at all levels.

  The present invention allows navigating between mutually related data. Thanks to the object weights depending on the displayed descendants, this solution further allows the user to understand the relationships between objects in an easy and intuitive manner. On the other hand, the user's progress during navigation is made visible while allowing the user to keep an overview of all the data visited.

  Nevertheless, if the number of displayed objects, or displayed levels, becomes important, the displayed objects can be zoomed out as needed. This can be triggered automatically upon user action or based on various possible parameters such as the level displayed or the number of objects displayed.

  It is further possible to allow the disk to be rotated independently during user action to allow a better understanding of the various relationships.

  Further, as shown in FIG. 3, the graphic index is embedded near or inside the displayed object, so that the geometric status of the object and the geometric relationship between the objects are determined. It is possible to facilitate understanding.

  In addition, the user always has the opportunity to go back by dropping the level. The user can return to the state of FIG. 2, for example, by selecting the disc 222 and selecting the “drop” option (eg, right-clicking can display several options). .

  Next, FIGS. 4 to 6 are examples of views of explanatory object groups displayed according to a linear layout. Referring to these figures, the user can alternatively select an “inline” layout to expand the layout along a given line, or have it shown in exploded view, where the line direction is Can be selected by the user. Compared to FIGS. 1 to 3, the same objects 204, 206, 208, 210 at level 1, descendant objects 213, 214, 216, 218, 220 at level 2, and sub-descendant objects at level 3 224, 226, 228, 230 are displayed sequentially according to a similar mechanism. However, unlike the “in-disc” layout, the various objects are displayed sequentially on lines or strips 202, 212, and 222 in this case.

  As presented in the examples of FIGS. 4, 5, and 6, the lines or strips 202, 212, and 222 are separated graphically and separated by level, for example, thanks to thin lines or different colors. Can be shown.

  FIGS. 7 and 8 are examples of views of descriptive objects displayed according to an “alternate in-line” layout.

  Because it is possible to allow the user to orient the strip, the user can reach an alternative “in-line” layout, illustrated below in FIGS. 7 and 8, in operation. In this way, the first level 1 is represented graphically along a first direction (eg, the direction of the strip 202 in FIG. 4), whereas the second level 2 is a second direction. Can be represented on the strip 212 in FIG. 7, for example, perpendicular to the first direction. Therefore, the user can clearly understand the relationship between the objects while increasing the compactness of the displayed object group. At the third level 3 (FIG. 8), the descendant objects are parallel to the first direction but can be moved along the third direction. Alternative inline representations allow users to better understand level separation.

  Note that alternative “in-line” layouts can also be provided as user-selectable, basic layout types where the strips alternate automatically at each level.

  Furthermore, each object at the same level stays on the strip of the object and on the strip of the ancestor of the object, as shown, to facilitate understanding of the hierarchy. For example, object 228 in FIG. 8 is placed on strips 222, 212, and 202, and it is understood that object 228 is part of object 220 and that object 220 itself is part of object 210. Making it easier to do.

  FIGS. 9 to 11 are examples of views of objects related to a flat displayed according to an “in-disk” layout as seen from above.

  Referring to FIG. 9, the user can select, for example, first data associated with a flat (first object), as well as a relationship, here “consisting of”. Note that this type of relationship is only used for understanding. Those skilled in the art will appreciate that other types of relationships can be used, such as the relationships described above. Again, the PLM system provides second data related to the first data via the selected relationship. A graphical representation of the various components is shown. In the example of FIG. 9, the second data represents a second group of objects related to the flat, shown as an exploded view on disk 202, representing the first level (ie, level 1). These objects are the wall 201, the first room 203, the hallway 204, the entrance 205, the bathroom 206, the pantry 207, the living room 209, and the kitchen 210.

  Such “objects” are preferably expressed using a little perspective to facilitate understanding of the objects, even when the layout is a view from above.

  Referring to FIG. 10, the user can select a given second object, eg, kitchen 210, which, when selected, is disassembled at level 2 on the second disk 212. Shown in the figure. The third group of objects derived from the kitchen is, for example, a refrigerator 214 or a kitchen counter 220 having a sink equipment. As in the case of FIGS. 1 to 3, the displayed object groups are distributed according to their weights, and the weights depend on the number of descendants of the objects in the displayed hierarchy. That is, more space is provided in the kitchen 210 shown in the exploded view at the same given scale compared to other level 1 objects. On the other hand, the first disk 202 is made larger and, as emphasized in the previous stage, enables redistribution of other object groups.

  Referring now to FIG. 11, the user can then select a particular third object, such as the kitchen counter 220, so that the object is disassembled and assembled on the new disk 222. Shown in the figure. For example, descendants (fourth object group) including a counter-top and a double sink 230 that can be seen in FIG. Object redistribution is performed in substantially the same manner as described above. Accordingly, the same advantages as described with reference to FIGS. 1 to 3 are also provided in this case.

  FIG. 12 is an example of a view of a group of objects related to a flat displayed according to the same layout as in FIGS. 1 to 3.

  As an alternative to “view from above”, the user can select an “in-disc” layout with a perspective similar to the layout of FIGS. This is illustrated in FIG. 12, which represents the same elements as in FIG.

  FIGS. 13 to 15 are examples of views of objects related to flats displayed according to the same layout as in FIGS. 4 to 6.

  The user can also select the “in-line” layout shown in FIGS. 13-15, which provides similar advantages as described with reference to FIGS. The example of FIGS. 13-15 differs from the selection made in front of the kitchen in FIGS. 9-11, and the subsequent exploded view shows the selection of the living room 209 shown in FIG. 14, then in FIG. Note the selection of sofa 290 shown in exploded view.

  FIG. 16 is an example of a view of a group of objects related to a flat displayed according to the same layout as in the case of FIGS.

  Referring to this figure, the user can further choose to configure or select an alternative “in-line” layout so that they can benefit from the respective advantages described with reference to FIGS. 7 and 8. can do.

  With respect to the example flat relationship objects group, it can be seen how powerful it is to query various relationships stored via data in a PLM database. The user can, for example, select a relationship “provided by” or a relationship “manufactured by”, etc., so that the user can clearly perceive where the group of objects can be procured from.

  In this regard, the present invention is structured between relationships that are not straightforward since the various possible relationships between objects make it a priori difficult for the user to understand them. Allows you to navigate in form.

  The present invention is implemented in such a way that the objects displayed by the GUI have a rendering size that depends on the respective weights of the objects, giving a perspective effect, e.g. It is further possible to substantially give a larger size compared to the object group displayed on the screen.

  According to an embodiment of the present invention, the weight of the displayed object depends on the size of the descendant of the object in the hierarchy displayed in the graphic representation.

  In another embodiment, the graphical user interface morphs from a first representation of the displayed object to a representation of the group of objects associated with the displayed object when the displayed object is selected by the user. Adapted to do.

  In yet another embodiment, the number of objects displayed at that level can be adjusted by the user, i.e. not all objects need to be displayed. This can occur, for example, when an object contains many children according to the selected relationship.

  In response, in one embodiment of the present invention, means are provided for hiding some objects within the same level. For example, a graphic object having the form of a tunnel can be displayed across a strip or disk representing a level and when the user moves the strip along a translation, or the disk When the is rotated around the axis of the disc, hidden objects can appear.

  The presence or absence of the graphic means allows the user to know whether there are more object groups at that level than the displayed object groups.

  Furthermore, the present invention can also be implemented as an add-on to an existing database system such as a PLM solution. A possible embodiment of the present invention will now be disclosed with reference to FIGS.

  FIG. 17 is a schematic diagram of a software architecture that can be used to implement the present invention, which shows a single client, a database server 560, and a vault server. The client includes a navigation engine 500 that manages user interface-control components 520, 580, and 640. The navigation engine allows the user to select objects, relationships, and the type of layout or view to display the objects, if available. Furthermore, the navigation engine can provide the usual types of queries available in the PLM system.

  FIG. 17 further illustrates a query engine 520, a database client 540, and a database server 560. The query engine 520 is controlled by the navigation engine 500 and builds a database statement depending on the user's command and sends the database statement to the database client 540. Query engine 520 also manages query results received from database client 540.

  Database client 540 is adapted to manage database server connections. Client 540 receives the query from query engine 520 and passes the query to database server 560. The client 540 receives the query result from the database server 560 and passes the result to the query engine 520.

  Database server 560 receives queries from a number of database clients, such as client 540, and responds to those queries. The database server is typically a relational database and can be implemented using a solution available from IBM under the name of DB or a solution available from Oracle. The database can also be an object or XML database, or an application server that accesses the database. The application server can also provide processing (on-the-fly or asynchronously) for advanced queries (proximity queries, spatial queries, etc.).

  Apart from the additional graphical navigation features available to the user in the navigation engine 500, the components 520, 540, and 560 need to be different from the relational databases in the art, such as the relational databases used in PLM solutions. Absent. Therefore, these components will not be described in further detail.

  FIG. 17 further illustrates a vault server 620 for storing and providing a representation of objects contained in the database. In other words, the vault server is used as a repository for expressions. The vault server 620 can be a file server where representations can be stored in various files. The vault server 620 can also be implemented using a database server that uses, for example, “blob” (binary language object) storage. The vault server 620 can also use proxy technology and / or cache technology. The representation of stored objects in the vault server can be in various formats, such as bounding box, polygon, bitmap image, vector image, subdivision surface, or more known in the art, It can exist in any common format. As described below, it is advantageous to store various formats in the vault server to allow incremental loading of representations.

  The vault server is addressed thanks to the vault client 600. A vault client allows a client to address a vault server to retrieve a representation of objects. FIG. 17 also shows an expression loader 580. The representation loader 580 queries the vault server 620 via the vault client 600 to obtain a representation of the objects to be displayed to the user. In addition, when the expression loader 580 receives an expression from the vault client 600, it manages the incremental reading of the expression.

  A visualization engine 640 manages the representation display to the user. The visualization engine 640 addresses a display driver 660 that manages the display hardware, most often a graphics card. Accelerated hardware can be used via the OpenGL driver, or using Microsoft Direct 3D, or DiretX for the purpose of displaying representations on display hardware.

  FIG. 18 is a flow diagram of a process for building a display according to the present invention. This process uses the software architecture depicted in FIG. In steps 700-800, in response to selecting the first data and the first relationship, the system displays a 3D representation of the group of objects. At step 800, the user selects objects and relationships. Next, as shown, the process of FIG. 18 loops to step 720 to build a new view to be displayed to the user.

  More specifically, at step 700, a query is constructed and a layout type is selected. This can be performed as described above. Query selection and layout type selection are made possible by the user interface of the navigation engine 500 of FIG. The layout type can be one of the various types of views illustrated in connection with FIGS.

  At step 720, the database is queried to obtain the attributes of the objects that match the query constructed at step 700. In the architecture of FIG. 17, this step is performed by the navigation engine 500, the query engine 520, the database client 540, and the database server 560. Step 720 results in an attribute set of objects that need to be displayed.

  At step 740, the vault server is queried to obtain various representations of the objects that need to be displayed. In the architecture of FIG. 17, this step is performed by the navigation engine 500, the representation loader 580, the vault client 600, and the vault server 620. As a result of step 740, a set of representations corresponding to the various objects to be displayed is provided in the selected layout.

  At step 760, the representation is laid out in 3D space according to the selected layout and according to the information obtained from the database server. In the architecture of FIG. 17, this can be performed by the navigation engine 500 and the visualization engine 640. The laid out representation is displayed to the user at step 780, thanks to the display driver 660.

  The process can then loop through steps 740, 760, and 780 to read incremental representations from a small, low quality format to a large rich format. For example, the bounding box representation of the object group can be read first, and then the polygon representation of the object group can be read. You can also stream expressions. This makes it possible to provide the user with an almost immediate representation of the group of objects, which representation may initially have a much lower quality, but improves over time. Finally, the user is provided with a more complete representation with higher quality without having to wait for such a representation for a long time. The representation can be loaded as a background task using multi-threaded or asynchronous input / output. These solutions make it possible to give higher priority to database queries, so that navigation in the database does not hinder the work of users in the database.

  The loop through steps 740, 760, and 780 can be stopped once the best richer representation has been read and displayed to the user.

  Otherwise, the loop through those steps can be stopped when the user selects one of the displayed objects and relationships, and this step is shown in FIG. It is represented by The process then loops back to step 720 to query the database server again.

  The process of FIG. 18 and the architecture of FIG. 17 use a vault server in which various pre-computed representations of data are stored.

  FIGS. 11 and 12 are schematic diagrams of a client-network hardware architecture adapted to carry out the present invention. FIG. 19 shows a client workstation. The workstation includes a central processing unit 900, a random access memory 920, and a workstation internal communication bus 940 for allowing access to the random access memory. The workstation further comprises a graphical processing unit 960 having an associated video random access memory 980. The disk controller 1000 manages access to mass memory devices such as the hard drive 1020. A network adapter 1040 manages access to the network 1060.

  In operation, the various client components of FIG. 17 are processes executed on the CPU 900. Network adapter 1040 is used by vault client 600 to access vault server 620 over network 1060 and further used by database client 540 to access database server 560 over network 1060. The disk controller 1000 can be used by the vault client to create a cache of representations on the local mass memory device 1020, which improves the performance of frequently used representations. A display driver 660 provides the layout of the representation to the video RAM 980, and the representation is displayed thanks to the GPU 960.

  Query engine 520 processes the query and stores the results in RAM 920. The expression loader 580 processes the expression working format and stores it in the RAM 920. The stored representation is used by display driver 660 and sent to display driver 660 as described in connection with step 760.

  FIG. 20 is a schematic diagram of a network architecture adapted to carry out the present invention, the architecture of FIG. 20 being a common vault server that provides a publicly accessible representational database, as well as a common database server Thanks to you, it is adapted to allow various users to navigate. In the example of FIG. 20, two local area networks 1100 and 1120 are connected to a wide area network 1140. FIG. 20 shows a database 1160 and master vault 180 shown in WAN 1140 for access from LANs 1100 and 1120. The first LAN 1100 includes two clients 1200 and 1220 and a proxy vault 1240. The second LAN 1120 also includes two clients 1260 and 1280 and a proxy vault 1300. Master vault 1180 is replicated in each proxy vault 1240, 1300 to optimize WAN bandwidth usage.

  In operation, a client group in either the LAN 1100 or the LAN 1120 accesses the database 1160 via the WAN 1140. Clients 1200 and 1220 in the first LAN 1100 access the proxy vault 1240 to obtain the representation, while clients 1260 and 1280 in the second LAN 1120 access the proxy vault 1300 to obtain the representation. to access. This exemplary operation assumes that a query against database 1160, which is almost a text query, can be answered within the WAN, as described above in connection with the PLM solution. Thus, the WAN has sufficient bandwidth to meet the demands on the database 1160. Because the database 1160 can be updated by any of the clients, the solution of FIG. 20 is simpler than managing data updates at various database proxies. The operation of FIG. 20 optimizes WAN bandwidth usage by replicating the vault server 1180 into the proxy vaults 1240 and 1300. This is advantageous. This is because the representation of the data typically has a larger size than the database information, and furthermore, the representation is precomputed and does not need to be updated unlike the database information.

  The present invention is not limited to the preferred embodiments described with reference to the drawings. In particular, the terms "first", "second" and "third" data or relationships are used for clarity of explanation and imply any actual limitation of the data and relationships. It is not a thing.

  Examples of views are provided in FIGS. Other examples of layouts can also be used. 17, 19 and 20 suggested a preferred architecture. Other software solutions or hardware solutions can also be used.

FIG. 4 is a diagram illustrating an example of a descriptive object view displayed according to an “in-disc” layout. It is a figure which shows an example of the view of explanatory object group displayed according to the "in disc" layout. It is a figure which shows an example of the view of explanatory object group displayed according to the "in disc" layout. FIG. 6 is a diagram illustrating an example of a view of a descriptive object group displayed according to an “inline” layout. FIG. 6 is a diagram illustrating an example of a view of a descriptive object group displayed according to an “inline” layout. FIG. 6 is a diagram illustrating an example of a view of a descriptive object group displayed according to an “inline” layout. FIG. 10 is a diagram illustrating an example of a view of a descriptive group of objects displayed according to an “alternative inline” layout. FIG. 10 is a diagram illustrating an example of a view of a descriptive group of objects displayed according to an “alternative inline” layout. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the "in disc" layout seen from the top. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the "in disc" layout seen from the top. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the "in disc" layout seen from the top. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the layout same as the case of FIG. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the layout same as the case of FIG. 4 thru | or FIG. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the layout same as the case of FIG. 4 thru | or FIG. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the layout same as the case of FIG. 4 thru | or FIG. It is a figure which shows an example of the view of the object group relevant to a flat displayed according to the layout same as the case of FIG. 7 thru | or FIG. FIG. 2 is a schematic diagram illustrating a software architecture that can be used to implement the present invention. 4 is a flow diagram illustrating a process for building a 3D representation to implement the present invention. FIG. 2 is a schematic diagram illustrating a client workstation architecture adapted to carry out the present invention. 1 is a schematic diagram illustrating a network architecture adapted to carry out the present invention.

Explanation of symbols

100 GUI
110, 120 Standard menu bar 130 Graphic tool 140 Bottom toolbar 150 Icon 500 Navigation engine 520 Query engine 540 Database client 560 Database server 580 Expression loader 600 Vault client 620 Vault server 640 Visualization engine 660 Display driver 900 CPU
920 RAM
940 Workstation internal communication bus 960 GPU
980 video RAM
1000 Disk controller 1020 Hard drive 1040 Network adapter 1060 Network 1160 Database 1180 Master vault 1200, 1220, 1260, 1280 Client 1240, 1300 Proxy vault

Claims (13)

A database that stores a plurality of modeled objects and relationships between the plurality of objects;
A product lifecycle management system comprising a graphical user interface suitable for displaying to a user a graphical representation of a hierarchy of a plurality of stored objects;
Said graphical user interface, the user, when the displayed object is selected, a plurality of objects related to the selected object, is adapted to display in accordance with one of a plurality of layouts, the plurality The layout is a linear layout having a plurality of objects represented by a perspective view exploded along a line, a fixed position layout, and a circular layout having a plurality of objects represented by a perspective view distributed on a disk And 2D layout of 3D miniature expression,
At a given level of the hierarchy, the displayed objects are sorted according to their weights,
The system wherein the weight of an object to be displayed depends on the number of descendants of the object in the hierarchy that are displayed in the graphical representation.   The graphical user interface is adapted to display a graphical cue representing a hierarchy of displayed objects and the descendants of the object in the hierarchy displayed in the graphical representation. Item 4. The system according to Item 1.   The system according to claim 1 or 2, wherein the plurality of displayed objects have a rendering size depending on their weights.   4. A system according to claim 1, 2 or 3, wherein the weight of the displayed object depends on the size of the descendant of the object in the hierarchy displayed in the graphical representation.   5. A system according to any preceding claim, wherein the graphical user interface is adapted to display the plurality of objects using a unique scale for all objects.   6. A system according to any preceding claim, wherein the graphical user interface is adapted to display a 3D representation of a plurality of objects.   The graphical user interface is configured to morph from a first representation of the displayed object to a representation of a plurality of objects related to the displayed object when a displayed object is selected by a user. 7. System according to any of claims 1 to 6, characterized in that it is adapted. A method for navigating in a database of a product lifecycle management system, wherein the database stores a plurality of modeled objects and relationships between the plurality of objects, the product lifecycle management system Comprises a graphical user interface suitable for displaying to a user a graphical representation of a hierarchy of stored objects, said method comprising:
Selecting a first object , a first relationship , and a first layout ;
Finding descendants of the first object in the hierarchy including a second plurality of objects related to the first object according to the first relationship;
Displaying a representation of the first object including the second plurality of objects according to the first layout ;
Selecting one of the displayed second plurality of objects, a second relationship , and a second layout ;
Finding a descendant of the selected second object including a third plurality of objects related to the selected second object via the second relationship;
Displaying a representation of the first object according to the second layout, including the second plurality of objects and the third plurality of objects;
The displayed objects are sorted according to their respective weights, and the weights of the objects depend on the number of descendants of the objects in the hierarchy displayed in the graphical representation, and the first layout and The second layout includes a straight line layout having a plurality of objects represented by a perspective view disassembled along a line, a fixed position layout, and a plurality of objects represented by a perspective view distributed on a disk. The method is selected from a circular layout having a 2D layout of a 3D miniature representation .   The method of claim 8, wherein the plurality of objects are displayed as a plurality of 3D objects. 10. A method according to claim 8 or 9 , wherein the layout is animated. The relationship is
The relationship of “consisting of”
The relationship “where used”,
The relationship of being in contact,
The relationship of “crash”
11. A method according to one of claims 8 to 10 , comprising at least two of the relationships "influencing". The method according to one of claims 8 to 11 , further comprising calculating and storing a 3D representation of the plurality of objects. Computer program characterized by implementing the method according to claims 8 to one of 12.

Images