Component Description

Change History

Id Subject Date
Latest Commit KBLFRM-984, KBLFRM-945, KBLFRM-931, KBLFRM-994, KBLFRM-1038: Resolved multiple requests in the area of Component Description & Instances and made refactoring to the whole structure. 2022-10-21
KBLFRM-931  Clarification of the Minimum Content of DocumentVersions for Part Master Data. 2022-09-12

Disclaimer: This page or section is currently under review by the community.

The content of this page or section can be subject to change at any time. If you find any issues or if you have any review comments please drop us an issue on the PROSTEP JIRA.

This page or section resolves multiple issues, see history for the relevant issue numbers

Before reading these implementation guidelines, it is highly recommended to read the “Description of Parts” section in the VEC Online Model Description.

This section explains the concepts for the representation of part master data and component specifications in the VEC. For a general explanation of the terms, see the parent section Product Definition. If you search information about specific component types e.g. wires, connectors etc. see Component Types

Aspects of a Component Description
Aspects of a Component Description

Due to the various supported use cases, the VEC’s concept for component specifications is designed modular. The figure above contains the most relevant elements

Note: The picture is for illustration purpose only and is taken from a current VEC version at the time of writing. The classes, attributes etc. might have changed in the mean time.

The unique identification of a component is its PartVersion. It is serves as an identifier and contains only additional PDM information like Approval,Creation or ChangeDescription. The actual description of the properties of a component is done via PartOrUsageRelatedSpecifications, whereby each specification covers only a certain aspect of the component. A holistic description of a component is a combination of multiple specifications, but no more than one of a specific specification type at a time. Those specifications can be divided into two groups:

  1. General Component Data: Specifications in this group describe general properties of components that are applicable to all or at least a large group of components. For example:

  2. Component Characteristics: Specifications in this group describe properties that are very specific for a certain component type, e.g. WireSpecification for wires or ConnectorHousingSpecification for connectors. In most cases, a part can be clearly assigned to one of these categories. However, there can be cases of “hybrid” components that fall into more than one category. In this case, the PrimaryPartType defines the primary character of the components. A detailed description can be found here: “Description of Parts”.

Unclassified / Custom Component Types

The VEC natively supports a wide range of component types and attributes for them. Nevertheless, this list is probably not exhaustive when considering which component types could potentially appear in the BOM of a wire harness and could also be added by future developments.

Currently, the list of directly supported types is derived from the specific requirements of the VEC and is focused on those components that have a specific relationship with other components in the harness (e.g. wires/connectors) and whose attributes play a strong role in the selection processes during development.

However, following its principle of openness and extendability, the VEC provides a possibility to add such components, that are not specifically supported by it, in a defined way as user/process defined components. The necessary elements to do this are:

  1. The PrimaryPartType to use is Other.
  2. “General Component Data” can be added with corresponding specifications analogous to a regular component (see above).
  3. The “Component Characteristics” is expressed by an instance of PartOrUsageRelatedSpecification itself (no subclass).
  4. The concrete type of the component (for regular components expressed by the PrimaryPartType), is defined in the PartOrUsageRelatedSpecification.SpecialPartType-Attribute.
  5. Specific attributes of the “new” type (not available via “General Component Data”) can be added as CustomProperty to the PartOrUsageRelatedSpecification.
  6. Instancing is done via a SpecificRole (see chapter “Instances of undefined Components” in the Specification for Details).

An example in XML of such a custom component can be found in the XML Listings section at the end of this page.

PartMaster - DocumentVersions

Part Master Documents
Part Master Documents

A part master document describes the properties of a component or a group of components (a PartVersion or a set of PartVersions). It can be recognised with the DocumentType = PartMaster. A schematic illustration can be found in the figure on the right side. It contains some general purpose specifications (highlighted in light blue) and component characteristics (highlighted in strong green), in most cases one. Those specifications are not mandatory and only necessary if the corresponding information aspect is relevant in the use case and can be provided.

Additionally, the document could contain auxillary specifications that are required for a complete component description (in the illustration the CavitySpecification and SlotSpecification highlighted in light green).

The emphasis here is on “could”, as this is a quite common case, but a process-specific interpretation of component definitions. For example, if the cavity system is described and released together with the connector (in the same document), it makes sense that the corresponding specification is included in the same DocumentVersion. However, if the cavity system is defined and released independently, i.e. in a separate document, and used by multiple connectors, it would be appropriate to place it in its own DocumentVersion and reuse the information in the document of the connectors (see Reuse of Documents).

Content Requirements

In an omniscient view of the world, it would be possible to formulate logical constraints and minimum requirements for the content of a PartMaster-Document, such as mandatory content or a logical relationship between the PrimaryPartType and the types of descriptive specifications that have to be used. For example, it could be stated that each component should have a GeneralTechnicalPartSpecification and one PartOrUsageRelatedSpecification corresponding to its type (e.g. a ConnectorHousingSpecification when the PrimaryPartType = ConnectorHousing).

However, a given VEC file can only be a fragment of this complete picture. The availability of information in a VEC depends on the specific use case, the process, the point in the process, the degree of maturity of the tooling, “need to know” and IP-protection policies and many more. Therefore, even if there are logical constraint, they are not enforced in the VEC.

XML Listings

The listing below contains an example of the general structure of a PartMaster VEC, additionally it does not contain a regular VEC component, but also illustrates the usage of “Custom Component Types”.

<vec:VecContent id="id_00000" xmlns:vec="">
    <GeneratingSystemName>VEC Samples</GeneratingSystemName>
    <DocumentVersion id="id_00001">
        <CompanyName>prostep ivip</CompanyName>
        <Specification xsi:type="vec:GeneralTechnicalPartSpecification" id="id_00002" xmlns:xsi="">
            <ColorInformation id="id_00003">
                <ReferenceSystem>IEC 60757</ReferenceSystem>
        <Specification xsi:type="vec:PartOrUsageRelatedSpecification" id="id_00004" xmlns:xsi="">
            <CustomProperty xsi:type="vec:NumericalValueProperty" id="id_00005">
                <Value id="id_00006">
    <PartVersion id="id_00007">
        <CompanyName>prostep ivip</CompanyName>
    <Unit xsi:type="vec:SIUnit" id="id_00008" xmlns:xsi="">