Instances of Components

This Implementation Guideline complements the Specification Chapter Instantiation of Components with concrete examples and detailed definitions for specific use cases. Component instantiation in the context of the VEC means the specific usage of a component in a defined function, location or place. Instantiation implies that there is something to be instantiated, which is the type definition. This type definition is often referred to as part master data or component specification. For example a “black connector with 12 pins” is a type definition, where as the “connector of the left head light (black with 12 pins)” is an instance.

The figure below gives a brief overview of how instantiation of components fit into the overall picture of the VEC and how this different for PartOccurrences and PartUsages.

On the left hand side is a part master definition (as described in Component Description). On the right hand side is a DocumentVersion (in this example a HarnessDescription) containing instances of components and additional information.

The two instantiation approaches of the VEC are illustrated with one representative for each. The PartUsage “A120” and the PartOccurrence “A121”. PartUsages and PartOccurrences are defined in different containers (CompositionSpecification vs. PartUsageSpecification). Both can coexist and be used at the same time in the same containing DocumentVersion.

On the far right hand side can be seen, that other areas in the VEC (indicated in orange on the right side) can use these instances regardless of the instantiation concept used.

Relationship to Part Master Data

The information related to a component instance is in the VEC always logically divided in type definition and instance specific properties. In the VEC Type definitions are contained in Specifications, instance specific properties are contained in Roles.

The one major difference between the PartOccurrence and the PartUsage is the way how both are referring to their respective type definition. The PartOccurrence references its part master data specifications indirectly via a PartVersion. It is described by PartOrUsageRelatedSpecifications) and can be reused for multiple PartOccurrences. In contrast to this, PartUsage, references the specifications directly itself without the detour over the PartVersion. The PartUsage can be interpreted as a hybrid of PartVersion and PartOccurrence in a single entity.

One notable difference is, the direction of the relationship with PartOrUsageRelatedSpecifications. The direction for the PartUsage is inverse direction compared to PartVersion. A PartVersion is described by specifications, wheres a PartUsage references the relevant specifications. This has logical reasons in the assumed information lifecycle of the corresponding entities. A PartVersion is a pointer to a “real” component. Over the time, this component can be described with more information (adding specification) without changing the component itself. On the other hand, a PartUsage is defined in place by associating appropriate specifications, those specifications can be created for this individual PartUsage or being reused for multiple PartUsage. Therefore, specification could be referenced over the time by more PartUsages without being changed.

A PartUsage shall reference all PartOrUsageRelatedSpecifications that provide relevant information about itself. This includes general component data and component characteristics that are relevant in the context (compare to “Component Description”). This does not include any specifications that are used transitively by other specifications (e.g. not the ConnectorHousingSpecification that defines the HousingComponent of an EEComponentSpecification, which is used for the PartUsage). This is illustrated in the Figure below (references between Specifications & Roles are omitted).

In the example from the beginning (figure “Comparison of PartUsages and PartOccurrences”), the PartUsage references the specifications from a PartMaster DocumentVersion. However, this approach is not mandatory and the only reason here, is to keep the example as simple as possible. Depending on the context, different approaches to provide a PartUsage with specifications are possible. Reusing existing part master data (as shown in the example) is one. Putting the specifications in an independent DocumentVersion (e.g. a company standard or a type definition) is another one and last but not least, the specifications could also be defined in the same context as the PartUsages.

Instantiation with Roles

PartOccurrences and PartUsages are containing the Roles corresponding to their PartOrUsageRelatedSpecifications (see both figures above, references between the roles & specifications are omitted in the figures for reasons of readability). Directly under PartOccurrence or PartUsage only Roles shall be used, that have PartOrUsageRelatedSpecifications defined directly in the corresponding part master data. Transitive dependencies (e.g. ConnectorHousingSpecification & Role in the figure above) are created in the appropriate subcontext, as defined by the VEC Model.

Following the principle of optionality in the VEC, it is not required to create Roles, for all the PartOrUsageRelatedSpecifications referenced in the part master data, if the corresponding aspect is not relevant in the individual context.

The contained Roles and their referenced PartOrUsageRelatedSpecification do not have to be exactly the same. They can be subset of those, but not a superset.

Shared Specifications

In the example above, the PartUsage and the PartVersion are using the same PartOrUsageRelatedSpecifications. Such a reuse (or sharing) of information pieces is perfectly valid. However, it does not implicate, that the PartUsage is an instance of the PartVersion. The precise meaning is, that in the final product a selected component, which is taking the place of the PartUsage, is required to satisfy the requirements expressed by the referenced specifications. In the example above, those requirements could be satisfied by this particular PartVersion, however, this might not be the only valid choice.

When PartUsages and PartVersions share specifications, this has no deeper meaning than that it is a reuse of a block of information. In particular, the following aspects apply:

The PartUsage is not required to reference all the specifications of the PartVersion. It can even reference contradicting specifications, for example:

• The PartUsage could reference only the ConnectorHousingSpecification, if the other properties are not a strict requirement.
• The PartUsage could reference the ConnectorHousingSpecification of the PartVersion, but a different GeneralTechnicalPartSpecification, if for example the requirements for weight, color or robustness are different.

The PartOrUsageRelatedSpecification for the PartUsage can describe a PartVersion at the same time, but they are not required to. That means, a PartUsage is free to define its own specifications, for example in its own context (DocumentVersion) or in a separate DocumentVersion.

Realization of PartUsages with PartOccurrences

Although PartUsage and PartOccurrence can coexist at the same time (shown in figure 1), they represent different levels of abstraction. The coexistence is only possible, because in reality, a product definition of a harness can contain different layers of abstraction at the same time as well (e.g. some components can be defined in 150% definitions and some are only determinable in a 100% definition).

Figure 2 presents a highly simplified situation for the sake of the concept. On the left hand side is a wiring definition with two Variants, A & B. A & B have the same logical connectivity, however, variant B has a slightly higher power output, resulting in a PartUsage (a requirement!) for variant B with a larger wire cross section area. The wiring also defines the color of the wire. However, other significant properties are left open (e.g. insulation material) for later determination. In the following design process, the other properties required for a component selection are defined (e.g. the insulation material, when the location of the wire in the vehicle is known). It is also decided, that it is more efficient to realize both variants with a single wire (satisfying both requirements at same time). Traceability is preserved in the case, with the RealizedPartUsage reference from PartOccurrence to PartUsage. The fact that a PartOccurrence can realize the requirements of multiple PartUsages at the same time is the reason that the multiplicity of this association is “0..*”.