Method for indexing a hierarchical data structure

Abstract

A computer-implemented method of indexing a hierarchical data structure or product structure is provided. For a product structure comprising a product and a plurality of items associated with the product, where each item shares a parent-child relationship with the product or at least one other item, the method comprises several steps. First, a packaged configuration-agnostic index of the product structure is generated by enumerating unconfigured item paths from the product to one of each item. Then, if one or more unconfigured item paths are identical, only one of the identical unconfigured item paths is retained. The index can also be combined with an index of spatial boundaries of the unconfigured item paths. Search requests for the product structure and spatial locations can be filtered against the combined index.

Description

TECHNICAL FIELD

[0001] The present invention relates to a method of indexing a hierarchical data structure, in particular a data structure comprising a root of data and a plurality of values associated with the root of data, wherein the plurality of values have a parent-child relationship with at least one other value or with the root of data. BACKGROUND

[0002] Computer aided design (CAD) tools are frequently used in the manufacture of complex products. Within the software, these products are often represented as a hierarchical product structure, typically displayed in the form of a product tree. This allows a user to query the product structure in a simple manner to view or edit the components and component assemblies stored within the product structure. Over time, these components and component assemblies will undergo a number of modifications, which need to be configured to result in a manufacturable product. For example, in automotive manufacture, a wheel requires a number of wheel bolts to secure it to an axle, the wheel itself can be a front wheel, a rear wheel, a left wheel or a right wheel, the axle will be mounted to a chassis, the chassis is connected to a vehicle model and so on. This represents a product tree with a relatively short path between the root (the vehicle) and the end item (the wheel bolt), but for a fully configured, manufacturable product, each wheel bolt needs to have its own branch in the product structure tree. As each branch must be configured, whether or not it is displayed to the user, the size of the resulting configured product can be quite large.

[0003] To modify, operate or make selections on a root product, in this case a vehicle, a user needs to be able to search within the product structure for components and component assemblies, individual components or events of component modifications. Depending on the amount of data involved, searching and configuring such a product structure can be slow and is often improved by using a cache of configured products and unfolding events of components and component assemblies. However, the cache approach for such configured products has several disadvantages. First, each individual configuration of a product requires a separate cache. Each cache needs to be stored and kept up to date. Second, the change management process produces change-specific, user-specific and group-specific configurations of a product. This increases the number of caches required. Finally, historical configurations also require a separate cache for each historical point, regardless of the number of modifications made. This further increases the number of caches required. Alternative approaches include techniques such as database indexing of paths in a product structure, which, while an improvement over the cache approach, is only effective for a short period of time. Modifications made to components and component assemblies can cause a path explosion over a longer period of time. This can be limited by indexing recent changes over a short time range, but this can be impractical or undesirable for a user. Therefore, there is a need to be able to index such a hierarchical product structure in such a way that searching for components and component assemblies and configuring a product can be done without data explosion, regardless of the number of modifications performed on the product or any of its components. SUMMARY

[0004] The present invention aims to solve this problem by providing, in a first aspect, a computer implemented method of indexing a hierarchical data structure comprising a root of data and a plurality of values associated with the root of data, wherein each value shares a parent-child relationship with the root of data or at least one other value, the method comprising the steps of: generating a packed configuration-agnostic index of the data structure by enumerating unconfigured value paths from the root of data to one of each value; and retaining only one of the unconfigured value paths if one or more unconfigured value paths are identical.

[0005] The use of an unconfigured index eliminates the disadvantages of a configured index, as the unconfigured index does not require each configuration of a value in the data structure to be configured and stored, but only a single unconfigured value path. By eliminating the constraints associated with configuration, the index also becomes flexible in terms of time, as individual values or data modifications do not need to be configured and stored. This therefore provides the ability to query a product structure and process, and to view revisions, over any time range without the need for excessive caching.

[0006] Preferably, the value has a spatial relationship with at least one of the root and each of the other values.

[0007] Preferably, the method further comprises the steps of, for each unconfigured value path: determining a transform for each parent-child relationship in the unconfigured value path; using the geometric bounds of the value to determine a spatial bounding box for the last item in the unconfigured value path; and arranging the transforms in the unconfigured value path and the spatial bounding box of the last item in the unconfigured item path to form a spatial bounding index for the unconfigured value path.

[0008] Most preferably, the data structure is a product structure, the root is a product, and values are items in the product.

[0009] In another aspect, the invention also provides a computer-implemented method of indexing a hierarchical product structure comprising a product and a plurality of items associated with the product, wherein each item shares a parent-child relationship with the product or at least one other item, the method comprising the steps of: generating a packed configuration-agnostic index of the product structure by enumerating unconfigured item paths from the product to one of each item; and retaining only one of identical unconfigured item paths if one or more unconfigured item paths are identical.

[0010] Preferably, the item has a spatial relationship with at least one of the product and each of the other items.

[0011] Preferably, the method further comprises the steps of, for each unconfigured item path: determining a transform for each parent-child relationship in the unconfigured item path; using the geometric bounds of the item to determine a spatial bounding box for the last item in the unconfigured item path; and arranging the transforms in the unconfigured item path and the spatial bounding box of the last item in the unconfigured item path to form a spatial bounding index for the unconfigured item path.

[0012] Preferably, the item is a component or an assembly of components.

[0013] Preferably, the product has a set of three orthogonal axes, and the axes of the spatial bounding box are aligned with the axes of the product.

[0014] Preferably, similar spatial bounding boxes in unconfigured item paths are merged.

[0015] Preferably, indexing the hierarchical product structure is performed in real-time, and the index includes at least one modification to an item or the product.

[0016] In another aspect, the present application provides a method of filtering search requests in an index of a hierarchical product structure, comprising: accessing an index of a hierarchical product structure generated according to the method described above; filtering a search request for a structure content against the index of the product structure independent of configuration to identify an item path; filtering a search request for a spatial location against the index of spatial boundaries to identify a box path; and re-filtering the search request for the structure content and / or the search request for the spatial location against the configured product structure generated at the box path.

[0017] In a third aspect, the present application provides a product comprising a non-transitory computer program including instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method. BRIEF DESCRIPTION OF DRAWINGS

[0018] The present application will now be described, by way of example only, with reference to the accompanying drawings in which:

[0019] Figure 1 is a schematic diagram showing an example portion of a product structure tree;

[0020] Figure 2 is an example of an unconfigured product structure index for use with a product structure tree of Figure 1 according to an embodiment of the present application;

[0021] Figure 3 is an example of a transformed list of unconfigured product boundary spatial indexes for use with a product structure tree of Figure 1 according to an embodiment of the present application;

[0022] Figure 4 is an example of a list of spatial boundary boxes for unconfigured product boundary spatial indexes for use with a product structure tree of Figure 1 according to an embodiment of the present application; and

[0023] Figure 5 is an example of an unconfigured product boundary spatial index for use with an unconfigured product structure index of Figure 2 according to an embodiment of the present application. DETAILED DESCRIPTION

[0024] The present invention employs an alternative approach to indexing hierarchical structures in the prior art. Hierarchical structures include multiple values that share parent-child relationships and can be represented as a tree structure having parent-child relationship groupings that appear as branches of the tree. By employing the concept of indexing an unconfigured product structure, known caching methods and other methods involving configured products or tracking paths in a configured product structure are avoided. As the name implies, this neither requires storing a configured product structure nor relies on an index of a configured product structure. A computer-implemented method is used to index a hierarchical data structure including a root of data and multiple values associated with the root of data. Each value shares a parent-child relationship with at least one other value or the root of data. The root of data can be, for example, a product structure or a process, and items (parts or part assemblies) that make up the product or process steps that form the process. The method initially includes generating a packed configuration-independent data structure index by enumerating unconfigured value paths from the root of data to one of each value. This enables parent-child relationships between items or process steps to be determined and listed in the paths. Once the unconfigured value paths are determined, if two or more unconfigured item paths are the same, only one of the same unconfigured value paths is maintained. This eliminates the potential for data explosion found in indexes of configured products because there is no proliferation of potentially identical index paths.

[0025] In the following examples, a product structure is used as the data structure to facilitate the explanation of the present invention. If we consider a product that includes a large number of parts and part assemblies, the item path is a sequence of items that represents a possible bill of materials (BOM) line within the product. In other words, an item (value) is associated with a product (root) and forms a parent-child relationship with at least one other item or product. Figure 1 The sequence within a single product line is shown in the following example. Figure 1 is a diagram showing one example portion of a product structure tree. The product structure 100 starts with a product item identifier "Product 1" and is followed by first level component identifiers "Item 1", "Item 2" connected to the product item identifier by routes "Route to 1" and "Route to 2", respectively. This level is followed by second level component identifiers, "Item 1.1", "Item 1.2", connected to "Item 1" by routes "Route to 1.1" and "Route to 1.2", respectively. Figure 1 In terms of the left-hand path of, the second level component identifiers are only "Item 1.1" and "Item 1.2" connected to "Item 1" by routes "Route to 1.1" and "Route to 1.2", respectively. Third level component identifiers "Item 1.1.1", "Item 1.1.2" and so on, until the item representing the part or part assembly of interest is reached. Each item in the sequence can be a child of the previous level and a parent of the child in the next level, and thus, the parent-child relationship can be used to represent both the leaf level parts and assemblies in the same manner.

[0026] Figure 2 is an example of an index of unconfigured product structures for use in accordance with embodiments of the present application Figure 1 of product structure trees. Each unconfigured item path has a sequence: / itemn / itemn.n1 / itemn.n1.n2... where n1 denotes a first sub-item, n2 denotes a second sub-item, and so on. Item paths can also be represented by the tags of the parent items, where for a sub-item itemn m , the parent item can be itemn m－1 . Figure 1 Only a single and possible unconfigured item path is shown for each item, although in practice components will occur multiple times in component assemblies and products, for example in the example of wheel bolts above. As a simple illustration, if all four wheels of a vehicle are identical, and each wheel requires five wheel bolts, then twenty configured item paths would be required for the wheel bolts alone. It is easy to see how this would grow once the relationships between the wheels and axles, axles and chassis, etc. are taken into account.

[0027] In contrast, in accordance with embodiments of the present application, only one unconfigured item path is required, since the use of item identifiers allows multiple sub-item occurrences to be packaged together, even across modifications. No new item paths are created when modifications are made to each item. Moreover, no additional item paths are generated when items are relocated within an assembly, or the number of items is adjusted. The original product / item relationships and parent / child relationships remain unchanged, and no new parent / child relationships are created. This is not the case, however, when a new item is added to an assembly or product. The new item will create a new parent / child relationship, and therefore the item and any sub-items it can have require additional item paths. As a result, the product structure index independent of configuration needs to be updated. In contrast, if an item is removed from a product or assembly, the number of item paths can decrease due to the item and its sub-items, if the item has any. These removed paths can be kept (and will be treated as false positives during searches) or can be removed from the index to ensure that the size of the index is minimized.

[0028] The use of item paths is also beneficial compared to the use of occurrence paths, in that it is able to package multiple sub-item occurrences together. Occurrence paths are similar in nature, except that they connect item occurrences together. For example, Figure 1The occurrence path of item 1.1.1 in the above example would be written as / route to 1 / route to 1.1 / route to 1.1.1. Here, the potential for an explosion of data in the index over time is much higher than in the case of using item paths, in contrast to which the actual data exhibited by the index grows much less over time.

[0029] In addition, item paths allow for easy detection and handling of loops. A loop is where an item becomes its own parent or ancestor, and thus cannot exist in a configured product structure. The index of a configured product structure therefore needs to handle loops, but when considering the approach of item paths according to embodiments of the application, any path containing two or more of the same item represents a loop in the product structure and can be removed from the index.

[0030] In the above example, the product structure is used to illustrate the concept of value paths in a data structure according to embodiments of the application. The index of value paths can be used to determine answers to questions about the data structure. These questions include: which values can be found in a particular data's root; where in the data tree can the values be found; which values are related to a particular data's root and which values exist in a particular data's root. This means that the concept is applicable for use in processes as well as products. For example, a complex manufacturing instruction can comprise a number of processes, each process dependent on a process step, all of which can be represented in a tree structure. The same principles as for product structures apply when considering which process steps are repeated. Returning again to the example of a car, the process of mounting a wheel comprising a tyre to an axle of a car comprises placing the tyre on the wheel, then mounting the wheel on the axle and fastening it with five wheel bolts. This process will be performed four times in the assembly process, meaning that there will be twenty instructions to tighten the wheel bolts. Therefore, by generating an unconfigured step path for the step of tightening the wheel bolts, only one unconfigured step path is required in the configuration-independent index approach.

[0031] Returning to the example of the product structure of Figure 1 Although the index approach of unconfigured item paths is able to answer questions about the product structure, a user can require information about locating items within the product structure. The concept of the configuration-independent index can be extended to include spatial boundaries, and then the concept is able to answer questions about the location of items within the product and create an index of the spatial boundaries of the unconfigured product.

[0032] In general, components and component assemblies within a product structure will have geometric bounds related to the coordinate system of the product. The components themselves can be drawn in their own coordinate system, e.g., with the center of the component at the origin and the various aspects of the component extending along the x, y, and z axes. This is typically used for reusable components, where the component is designed and then positioned within the product. An alternative approach is to use a design in-place process, where the component is designed at the location where it is needed, e.g., on the chassis of an automobile. After design, the positioned component needs to be transformed to transfer the component to the coordinate space of the product. For a structure with unconfigured item paths, the geometric bounds for one item path are formed by arranging the different transformations for each item-to-item path hop and the different geometric bounds in the path in the coordinate system of the product. An item-to-item path hop is a transition from a parent item to a child item. This is illustrated in Figure 3 and described in more detail below. When the number of item events in a configured assembly is more than once, the different events will typically have different geometric positions. Thus, these will correspond to different subsets in the unconfigured geometric bounds.

[0033] It is also common to group the spatial bounds of an item path into independent geometric positions. For example, axis-aligned three-dimensional boxes can be used to represent the spatial bounds. This enables forming a set of axis-aligned three-dimensional boxes for each item in an item path in the coordinate space of the product, such that multiple boxes represent the item path. Similar boxes within each item path can be merged, which will reduce the storage capacity needed.

[0034] Figure 3 is an example of an unconfigured product structure index for a product structure tree of Figure 1 The parent list indicates the parent in each parent-child relationship, and the child list indicates the child. The transformation list indicates the transformation needed to perform an item-to-item hop between the corresponding parent and child. For parent n and child n-1, the transformation will be transformation n-1. Thus, for parent 1.1 and child 1.1.1, the item-to-item hop is determined by transformation 1.1.1.

[0035] Figure 4 is an example of a list of spatial-bounding boxes for a spatial index of unconfigured product bounds, which is used for Figure 1product structure tree. Each spatial bounding box is represented in the form of box n for item n, so that the spatial bounding box for item 1.1 is represented as box 1.1. Combining the list of transforms and the spatial bounding box for each item, an index of spatial bounds independent of the configuration can be created. If the unconfigured item path does not have a geometric position, it is not possible to construct a spatial bounding box.

[0036] Figure 5 is an example of an index of spatial bounds for unconfigured product boundaries used in accordance with embodiments of the present application. Figure 2 is an unconfigured product structure index for Figure 2 A path box is created for each unconfigured item path shown in

[0037] Item path: / product 1 / item n1 / item n2 / item n3

[0038] and

[0039] Box: transform n*transform n1*transform n2*transform n3*box n3

[0040] Thus, for item 1.1.1, these item paths and path boxes are represented as:

[0041] Item path: / product 1 / item 1 / item 1.1 / item 1.1.1,

[0042] Box: transform 1*transform 1.1*transform 1.1.1*box 1.1.1

[0043] If a further item 1.1.1 event is added under item 1.1, for example an additional bolt in the new wheel area of the wheel, an additional index entry is created:

[0044] Item path: / product 1 / item 1 / item 1.1 / item 1.1.1,

[0045] Box: transform 1*transform 1.1*transform 1.1.1a*box 1.1.1

[0046] When considering the spatial bounds, although the spatial-bound box for the item is the same, it is necessary to further introduce transform 1.1.1a because the item-to-item path jump is not replicated in the other item paths. Although boxes are used in the above example, other alternatives can be preferred depending on the product structure, for example a bounding sphere or multiple bounding boxes.

[0047] Similar to the index of the configuration independent product structure, the spatial index of the unconfigured item path is suitable for answering questions about the spatial location of the product structure. These questions can include, for example, which events of the item are located in a spatial region; which events are near a given event; which event spans a given part. Thus, by using together the index of the configuration independent product structure and the index of the spatial bounds of the unconfigured item path, a user is able to query both the content and location information of the product structure. When considering data structures, it is necessary to determine a transformation for each parent-child relationship in the unconfigured value path. Then, the spatial bounding box for the last value in the unconfigured value path is determined using the geometric bounds of the value. Finally, the transformations in the unconfigured value path and the spatial bounding box of the last item in the unconfigured value path are arranged to form the index of the spatial bounds of the unconfigured value path.

[0048] The advantages of this approach are apparent when a user wishes to work with a product structure that is indexed according to embodiments of the present application. Initially, the user is able to view a collapsed product structure tree that can be expanded to as many branches and levels as desired to view individual items within the product structure. To find an item, the user can enter a search item into a dedicated search function for the product structure. Using the above automobile example, the user can wish to find a wheel bolt. Typing "wheel bolt" into the search function will filter the search request against the configuration independent product structure and, once found, will expand the product structure tree to show the wheel bolt within the product. Typing "wheel bolt left wheel area" will filter the search request against both the configuration independent product structure index and the spatial bounds of the unconfigured item path index, causing the product tree to expand to show the wheel bolt in the left wheel area. Further searches can then also be performed against the configured product structure.

[0049] Thus, to use the indexes, a search request for structure content is filtered against the configuration-independent product structure index to identify item paths. Then a search request for spatial location is filtered against the index of spatial bounds to identify box paths. One exception is if an item does not have a geometric location, then there is no spatial bound information to arrange with the transform, so there is no search request for spatial location and no index entry for spatial bounds for that item. Finally, a search request for structure content and / or a search request for spatial location is re-filtered against the configured product structure generated from the box paths. This re-filtering enables more detailed searches when the product structure tree has been expanded at the right point of the item in question. Various filtering techniques can be used to perform such filtering processes. For example, a bounding volume hierarchy (BVH) method works well for filtering processes against the unconfigured item path index and / or the spatial bounds index for unconfigured item paths. A bounding volume hierarchy is a tree structure over a set of geometric objects that are wrapped in bounding volumes that form the leaf nodes of the tree. These nodes are then grouped into small sets and wrapped in larger bounding volumes that are in turn grouped and wrapped in larger bounding volumes, and so on, until a tree structure is created with a single bounding volume at the top of the tree. Axis-aligned bounding boxes, such as those described above for the geometric bounds of each item, can be classified as part of the bounding volume hierarchy. A typical use of a bounding volume hierarchy is for collision testing and ray tracing. Thus, the methodology of performing operations on groups of geometric objects using a bounding volume hierarchy can be applied to embodiments of the present application. In particular, collision testing is effective in embodiments of the present application in which the intersection of two or more objects is detected.

[0050] Similar to the process described above, there can be spatial items that need to be included as part of the process steps. The user can need to know where a particular process will take place, for example, whether a component needs to be moved between a workbench and a product.

[0051] The use of the method of embodiments of the present application also results in more indexes than the number of search scenarios supported by the configured product structure index. This reduces the load of index management and makes it less necessary for an administrator user to perform explicit index management. In addition, more pre-emptive indexes can be created by the index management tool. Because many events for the same item do not need to be filtered, fast filtering is also performed for parts of the product structure that are not of interest to the user.

[0052] A further benefit of the embodiments of the present invention is the flexibility to index modifications to the project and product structure. As projects are modified over time or moved into place, although spatial boundaries can certainly change, there is no need to create additional unconfigured project paths. Indexes of configured product structures do not have this time sensitivity and ability to track modifications. Thus, such indexes lack the ability to handle the time component unless excessive caching is employed because the index must be reconfigured every time a change is made. Thus, configured indexes are merely a snapshot of the configuration at one point in time, whereas configuration-independent indexes are a real-time representation of the product structure. Thus, indexing of hierarchical product structures is performed in real-time and includes at least one modification to the project or product. This flexibility with respect to modifications also enables the same configuration-independent index to be used by different users or at different locations and at different times because modifications to the configuration of the product need not be taken into account.

Claims

1. A computer-implemented method of indexing a hierarchical data structure, the hierarchical data structure comprising a root and a plurality of values associated with the root of data, wherein, Each value shares a parent-child relationship with the root or at least one other value of the data, the method comprising the steps of: generating a packed configuration-agnostic index of the data structure by enumerating over unconfigured value paths from the root of the data to one of each value; and if one or more unconfigured value paths are identical, then retaining only one of the identical unconfigured value paths, wherein a value has a spatial relationship with at least one of the root and each other value, wherein the method further comprises the steps of: for each unconfigured value path: determining a transformation for each parent-child relationship in the unconfigured value path; determining a spatial bounding box for the last item in the unconfigured value path using the geometric bounds of the value; and arranging the transformations in the unconfigured value path and the spatial bounding box of the last item in the unconfigured item path to form a spatial bounding index of the unconfigured value path, the geometric bounds being in a coordinate system of the root.

2. The method of claim 1, wherein, the data structure is a product structure, the root is a product, and the values are items.

3. A computer-implemented method of indexing a hierarchical product structure comprising a product and a plurality of items associated with the product, wherein each item shares a parent-child relationship with the product or at least one other item, the method comprising the steps of: generating a packed configuration-agnostic index of the product structure by enumerating over unconfigured item paths from the product to one of each item; and if one or more unconfigured item paths are identical, then retaining only one of the identical unconfigured item paths, wherein an item has a spatial relationship with at least one of the product and each other item, wherein the method further comprises the steps of: for each unconfigured item path: determining a transformation for each parent-child relationship in the unconfigured item path; determining a spatial bounding box for the last item in the unconfigured item path using the geometric bounds of the item; and arranging the transformations in the unconfigured item path and the spatial bounding box of the last item in the unconfigured item path to form a spatial bounding index of the unconfigured item path, the geometric bounds being in a coordinate system of the product. the item is a component or an assembly of components.

4. The method of claim 3, wherein, the product has a set of three orthogonal axes, and an axis of the spatial bounding box is aligned with an axis of the product.

5. The method of claim 3, wherein, similar spatial bounding boxes in unconfigured item paths are merged.

6. The method of claim 3, wherein, indexing the hierarchical product structure is performed in real-time and includes at least one modification to an item or the product.

7. The method of any one of claims 3 to 6, wherein, 8. A method of filtering a search request in an index of a hierarchical product structure, comprising: accessing an index of a hierarchical product structure generated according to the method of any one of claims 3 to 6; filtering a search request for structural content against the configuration-agnostic index of the product structure to identify an item path; ​ The search request for the spatial location is filtered against the index of spatial boundaries to identify a frame path; and The search request for the structure content and / or the search request for the spatial location is re-filtered against the configured product structure generated from the frame path.

9. A non-transitory computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of any one of claims 1 to 8.

Images