How many Element Definitions nesting/hierarchy levels are possible to define, to allow for independent definition of values for the lowest hierarchy element when used in several instances of the top-level element? Using the example in the manual: If we have a car ( top level hierarchy) , which has four wheels (lower level hierarchy), each wheel has a break (lower-lower level hierarchy) , and each break has a bolt (lowest level of hierarchy. Thus we have 4 nesting/hierarchy levels considering the bolt element. Looking at the level of the top-element ( car) I would like to be able to assign each of these bolts, present at the lowest (or intermediate) hierarchy ( of four levels ) an unique but different value of a specific parameter ( e.g. colour) .. Seems this is not possible, if the element hierarchy (e.g the bolt element) is e.g two or more levels down from the top level ( the car) . The Element view is also not showing details for more than one level down-hierarchy.
It seems that, for such lower hierarchy elements (e.g the 'bolt'), in their Element usage parameter set, the element definition is not unique, e.g. not linked/updated to the upper- hierarchy (e.g. the 'break', and the 'wheel' ) unique element definitions ID's but is still pointing to the 'source' element definition of the 'bolt' element. Thus, modifying the 'colour' property value of a specific low-hierarchy nested 'bolt' element , part of a specific 'break' of one of the 'wheel' elements of the car causes the same change to propagate to the 'colour' property value of all other 'bolts' , part of the other 'breaks' of the other 'wheels' ... This is not desired, we need to be able to define individual 'colours' to each 'bolts' seen in each 'wheel' element of a 'car' , for all 'cars' in a 'fleet', etc.. ( in as many hierarchy levels as desired) .
In other other words: It is very needed the usage-level parameter values at each nesting level to be possible to define completely independent, and only for that element usage, from the values of any other usages of the same element in a given model /product three
Seems there is some mismatch updating the nested elements usage names and definitions when creating (e.g using copy) multiple instances of the upper hierarchy elements to that particular nested element, for which we need to assign unique properties values .
**After a more detailed analysis of the code:
It looks like that the issue is related to the following : the element usage parameter values are linked to the 'Model Code' string of the nested element, BUT the 'Model Code' string itself is only designed to account for only two levels of element hierarchy nesting - the current level and one above,.. This breaks the link from the lowest hierarchy element to the top-level elements, and thus prevents to assign unique parameter values for elements, nested in e.g. nested nested nested .. model elements, if the nesting is more than 1 level bellow the 'surface'. ** The current solution seems to be to create unique new element for each of the elements to be nested, and keep the rule of having only one hierarchy level down for the elements for which one needs to assign unique parameter values... In the example above, this would mean that one will need to create 4 different 'brake' elements, hosting each a 'bolt' element, then create four different 'wheel' elements, hosting each one of the unique 4 'break' elements, and then to create a 'car' element made of the four unique definitions of the 'wheel ' elements.
A system designer would rather expect a different strategy: E.g. Have only one definition for the 'bolt' element , nested in one single 'break' element nested in one single 'wheel' element. The 'car element will have four copies of the 'wheel' element. And the 'bolts' parameter values for each wheel will have unique 'Model Code ' IDs .eg. carID.wheelID.breakID.boltID.colour in contrast to the current breakID.boltID.colour (the 'Model Code ' string Id keeps only two hierarchy levels described)
Please advice?
How many Element Definitions nesting/hierarchy levels are possible to define, to allow for independent definition of values for the lowest hierarchy element when used in several instances of the top-level element? Using the example in the manual: If we have a car ( top level hierarchy) , which has four wheels (lower level hierarchy), each wheel has a break (lower-lower level hierarchy) , and each break has a bolt (lowest level of hierarchy. Thus we have 4 nesting/hierarchy levels considering the bolt element. Looking at the level of the top-element ( car) I would like to be able to assign each of these bolts, present at the lowest (or intermediate) hierarchy ( of four levels ) an unique but different value of a specific parameter ( e.g. colour) .. Seems this is not possible, if the element hierarchy (e.g the bolt element) is e.g two or more levels down from the top level ( the car) . The Element view is also not showing details for more than one level down-hierarchy.
It seems that, for such lower hierarchy elements (e.g the 'bolt'), in their Element usage parameter set, the element definition is not unique, e.g. not linked/updated to the upper- hierarchy (e.g. the 'break', and the 'wheel' ) unique element definitions ID's but is still pointing to the 'source' element definition of the 'bolt' element. Thus, modifying the 'colour' property value of a specific low-hierarchy nested 'bolt' element , part of a specific 'break' of one of the 'wheel' elements of the car causes the same change to propagate to the 'colour' property value of all other 'bolts' , part of the other 'breaks' of the other 'wheels' ... This is not desired, we need to be able to define individual 'colours' to each 'bolts' seen in each 'wheel' element of a 'car' , for all 'cars' in a 'fleet', etc.. ( in as many hierarchy levels as desired) .
In other other words: It is very needed the usage-level parameter values at each nesting level to be possible to define completely independent, and only for that element usage, from the values of any other usages of the same element in a given model /product three
Seems there is some mismatch updating the nested elements usage names and definitions when creating (e.g using copy) multiple instances of the upper hierarchy elements to that particular nested element, for which we need to assign unique properties values .
**After a more detailed analysis of the code:
It looks like that the issue is related to the following : the element usage parameter values are linked to the 'Model Code' string of the nested element, BUT the 'Model Code' string itself is only designed to account for only two levels of element hierarchy nesting - the current level and one above,.. This breaks the link from the lowest hierarchy element to the top-level elements, and thus prevents to assign unique parameter values for elements, nested in e.g. nested nested nested .. model elements, if the nesting is more than 1 level bellow the 'surface'. ** The current solution seems to be to create unique new element for each of the elements to be nested, and keep the rule of having only one hierarchy level down for the elements for which one needs to assign unique parameter values... In the example above, this would mean that one will need to create 4 different 'brake' elements, hosting each a 'bolt' element, then create four different 'wheel' elements, hosting each one of the unique 4 'break' elements, and then to create a 'car' element made of the four unique definitions of the 'wheel ' elements.
A system designer would rather expect a different strategy: E.g. Have only one definition for the 'bolt' element , nested in one single 'break' element nested in one single 'wheel' element. The 'car element will have four copies of the 'wheel' element. And the 'bolts' parameter values for each wheel will have unique 'Model Code ' IDs .eg. carID.wheelID.breakID.boltID.colour in contrast to the current breakID.boltID.colour (the 'Model Code ' string Id keeps only two hierarchy levels described)
Please advice?