A PartRelation defines additional parts (e.g. accessories) for a specific part. These parts are in some way or usage scenario required for the part itself to be used. However, they are not included with the part number and have to ordered separately. This can be used for example for caps, cable ties etc.
The associated PartRelations of a GeneralTechnicalPartSpecification represent a configurable bill of material that can/must be ordered together with the part, when it is used. Each PartRelation represents an item / line in this bill of material. The semantic by which a PartRelation is resolved to PartVersions is defined by the PartRelationType. If multiple PartRelations resolve to the same PartVersions the resulting bill of material is the sum of them.
If a PartRelation references more than one accessoryPart the PartRelationType defines the semantic to resolve this reference for a resulting bill of material. If the type is Mandatory all referenced PartVersions shall be in the resulting bill of material. If the type is Optional, the referenced PartVersions can be selected by choice into the resulting bill of material. However, the choice applies to all PartVersions of one PartRelation. For Mandatory it is semantically equivalent to have one PartRelation referencing N PartVersions or to have N PartRelations, each referencing one PartVersion. The PartRelationType OneOfAll defines, that exactly one of the referenced PartVersions shall be chosen for the resulting bill of material.
If the same PartVersion is referenced multiple times, each reference counts as its own position.
Example: To express that a PartVersion shall be used at least three times and with a maximum of 6 times, three mandatory and three optional PartRelations to this PartVersion would be created.
With these concepts, simple yes/no decisions can be represented. However, there cases where there are constraints between accessory parts (e.g. if part A, then choice of 2 x B or 1 x C). To express such logic in a static object model is not very feasible and inflexible. For such cases, the relationType 'Custom' was introduced. In this case, the relationships and constraints between all referenced accessoryPart can be expressed with some custom expression language in the customRelationExpression attribute. Even if it is custom, the expression shall only refer to elements that are contained in the accessoryPart relation and shall not influence other PartRelations of the same GeneralTechnicalPartSpecification.
Specifies the type of the relation.
Defines the relationship between the accessory parts in a proprietary expression language. This attribute shall only be used, if the relationType = ‘Custom’.
|PartVersion||accessoryPart||1..*||0..*||References the PartVersions that are related by the PartRelation.|
References the PartRelations that are valid inserts for this ModularSlot.
This reference points to PartRelations in order to allow referencing indirectly a PartVersion if the description of individual PartVersions is done with one physical VEC file per PartVersion and to allow the expression of optional inserts, choices etc. However, inserts for a ModularSlot are always ConnectorHousings by itself. Therefore, the referenced PartVersion shall have a PrimaryPartType = ConnectorHousing
References the PartRelations that are valid inserts for this ExtensionSlot.
This reference points to PartRelations in order to allow referencing indirectly a PartVersion if the description of individual PartVersions is done with one physical VEC file per PartVersion and to allow the expression of optional inserts, choices etc. However, inserts for an ExtensionSlot are always EEComponents by itself. Therefore, the referenced PartVersion shall have a PrimaryPartType = EEComponent.
|GeneralTechnicalPartSpecification||1||partRelation||0..*||Specifies possible relations (accessories) of the specified part with other PartVersion (e.g. caps, clips).|
References the PartRelations that specify supplementary parts for this slot.