Although it certainly isn’t the only way to organize their Designs, a very common way for engineers to think of their products is in the form of a hierarchy, or tree of assemblies, sub-assemblies, and parts. An important part of kBridge is its built-in ability to represent hierarchy in this first-class way — that is, to represent products as a tree of assemblies, sub-assemblies and parts.
In kBridge, objects can be represented by any set of related Rules. The most common organization is based on the physical organization of the part. For example, the Table Top represents a physical object with a length, width, height, volume, material, color, etc. But kBridge objects can also represent more abstract concepts, like a set of financial calculations (costs), or a set of engineering calculations that don’t have a physical representation.
In order to implement such a flexible hierarchical schema, there is a special kBridge Rule called a Child Rule. In fact, a Child Rule has several components and formulas associated with it, but the underlying kBridge engine treats it just like any other Rule for dependency tracking purposes. That Rule dependency tracking is why we refer to it as the Child Rule.
When we have a hierarchy for our Design, the leaves of the resulting tree generally represent the physical parts, as when Table Top is found under the root node, Table. The root node and all the intermediate nodes generally represent the ‘assembly’ of parts that appear beneath them in the tree. So, the Table object represents the group of parts – Table Top, Legs, Stiffener – but doesn’t have a physical representation itself.
As it turns out, we often have assembly level parts that have geometric properties, like length, width, and height. This allows us, for example, to have the root Table object represent the overall size of the table – an envelope with its own Length, Width, and Height – even though the geometry of the Table object itself never actually gets drawn (only the leaves of the table assembly get drawn.)
Later, we’ll show that a box-like representation of the Table provides a kind-of reference box for us to use for positioning and orienting the subordinate parts of the table; it provides a complete local coordinate system. Because of this, if we reposition or re-orient the Table, all of the subordinate parts in the assembly will be moved along with it.
Generally, leaves appear in the graphics
Generally, the leaves of the model tree are what appear in the graphics window. This behavior can be overridden, but generally, an image of an assembly is the image of its children. All other nodes in the model tree are organizational.
It is important to note that since a Child Rule is simply another type of Rule associated with a Design, it is evaluated in the context of that Design; any formulas and their references will be evaluated in the context of the Design where the Rule is defined.
Child Rules generate a special representation in the model. Each Child Rule will have a Group level and one or more actual Child Models under the group. This makes it easy to navigate to the Child Rule that defines that group of objects that appear as children below it.
Child Rules capture the quantity of children as well as their Design
A Child Rule allows us to specify the quantity of children and the Design to use for the children. For example, for the Table Top Group, the quantity would be 1 and the Design to use might be the actual Design called TableTop. In fact, the quantity and Child Design name are defined by formulas. This means that the actual Design that will be used for the Child and how many there are can be determined based on Rules.
This is a key feature of kBridge. It allows us to have different configurations of the model depending on the calculated Rules. For example, in the table, we might want to have a Rule that chooses a square leg if the load is below 100, but a heftier round leg if it is greater than 100. Square leg and round leg are two different Designs, and in fact may have sub-assemblies of their own which in turn might be configured. Every Child Rule provides an opportunity to set the configuration of the tree below it via Rules.
A Child Rule can provide Parameters to each Child
The Child Rule can also provide Parameters for each Child. Rules can be Designated as Parameter Rules so that their formula can be overridden from above by a Child Rule. The Parameters supplied in a Child Rule will override the default formula for the Rules defined in the Child Design, provided they have the Parameter flag set. This enables us to use the same Design in different places in the model with different parametrization – without having to change the Design itself. This enables us to make generic Designs that can be used over and over, which is truly a powerful concept. We’ll discuss generic Designs in more detail in a later section.
[Add graphic to help illustrate this…]
