General Structure

The VEC has two major key concepts: PartVersion and DocumentVersion. Both are ItemVersions and both are used to reference / identify a piece of relevant information in a PDM context unambigiously.

Whereas the PartVersion “just” represents a PDM anchor / reference for a part or component plus some Meta-Information, the DocumentVersion has different characters in the VEC (for more details see section Usages of the DocumentVersion):

1. It can serve as a plain PDM anchor / reference to a document, with no further content / information in the VEC, like the PartVersion for parts (VEC equivalent to the KBL External_reference).
2. However, more important is that the DocumentVersion is the container for any payload information contained in the VEC.

From a meta data perspective, the VEC does not differentiate between documents that are contained in the VEC itself or in some external place somewhere else. This guideline is intended to provide guidance on how these concepts should be used and how an appropriate distribution of documents can look alike.

Fundamentals

On the root level, a VEC contains mainly PartVersions and DocumentVersions and some other unversioned (and constant) information, e.g. the definition of the Units used within the VEC. This is illustrated in figure Basic Structure.

One of the core concepts of the VEC is, that there is no restriction for the type of information that can be contained in a DocumentVersion nor the valid combinations of different types of information that can be contained together. This enables the DocumentVersion to reflect the actual circumstances of the domain or process and thus represents an actual technical document with a corresponding release and versioning.

Reasonable combinations of information are driven by the use cases (with process specific variations). The description of some common use case is part of this guideline.

A document can contain any number of Specifications. The Specifications represent the information modules of the VEC and each defines a certain type or aspect of information. The Specifications in a document can be thought of like drawers, where each drawer contains a specific aspect of the vehicle network. A distinction can be made here between:

• General specifications, that are for example required for the provision of basic information or for information reuse (e.g. an InsulationSpecification), and
• PartOrUsageRelatedSpecifications that are specifically used to describe / specify the properties of one or many PartVersions.

Parts and Documents

One of the most fundamental concepts of the VEC is the separation of a part / component from its definition (specification). In this, the PartOrUsageRelatedSpecification plays a major role.

In the VEC a part (PartVersion) does not contain any information about the part, except its PDM Information (PartNumber, PartVersion, …). All the information about the technical properties of a part is expressed by a subclass of PartOrUsageRelatedSpecifications (e.g. a WireSpecification). The PartOrUsageRelatedSpecification is contained in a DocumentVersion. As mentioned above, the distribution of these specifications into different documents is driven by the process / domain (see object diagram Parts and Documents).

This approach enables the VEC to address for example the following scenarios properly:

• The description of a part is changed, but the part itself is not changed (rereleased). This can happen for example if the actual technical properties of the part stay the same, but the description is extended or corrected. In this case, a new version of the document is created. However, the PartVersion stays the same.
• A document and the contained specifications are describing more than one part (e.g. a drawing for a certain class/family of terminals, seals & plugs). In this case it can happen that the document and the specifications are changed, but not all of the described parts have to be changed (rereleased). E

Usages of the DocumentVersion

As mentioned in the introduction, the DocumentVersions VEC can be used in different ways:

• Plain PDM reference (a.k.a as external reference): In this case, the DocumentVersion in the VEC only contains meta-data and no payload-data (no Specifications). There different possibilities to resolve the original document that is referenced by the DocumentVersion:
  1. Domain Key: Per definition, a document version is unambiguously identified with its DocumentNumber, DocumentVersion and CompanyName. With context knowledge about the process, the document can be resolved in the corresponding PDM / Document Management System.
  2. FileName: If the document is packaged together with VEC (VEC Package) the filename attribute of DocumentVersion can point to location within the package.
  3. Location: Can point to a location (via a URN or URL) where the document can be resolved.
• Digital Representation of an external Document: There are use cases where existing documents can represented in the means of the VEC. In other words the VEC DocumentVersion is a digital representation of the original document. For example, the information of a component data sheet (as PDF) might be also represented in VEC in a digitally evaluable way (PartOrUsageRelatedSpecification). In this case the same mechanisms like for the plain PDM reference can be used, plus payload-data in DocumentVersion.
• Native VEC Documents: The VEC DocumentVersion itself is the source of information. This case is quite similar to the digital representation scenario. However, external links (if defined) will resolve to the VEC file itself.

Combination and Reuse of Documents

Typically, information is flowing through the process. It is created somewhere, passed on to someone else and is used there to create other information blocks. To make these information flows traceable each piece of information must be identifiable and must have a change indicator. In the VEC this is done by the DocumentVersion. In order to preserve this traceability along the process, the assignment of information pieces to its original DocumentVersion shall remain unchanged.

An illustrative example for this, is the distribution and use of component master data (compare figure on the right). As described in “Partitioning and Sizing of VEC Files” component master data is best provided with one VEC per component, containing at least one DocumentVersion with the component’s specifications (VEC A, B, C).

If a wiring harness is created with these components, the component master data (at least a portion of it) is required in the data set of the harness (VEC NEW). However, the information is not integrated into the DocumentVersion of the harness (DocumentVersion NEW), as this would lead to a loss of traceability, even if the structures of the VEC would allow such an approach. Instead, copies of the DocumentVersions containing the component’s part master data are placed beside the DocumentVersion of the harness, within the same VEC.

Types of Documents

The DocumentType is an OpenEnumeration that defines some document types that are common in the harness development process. The following sections describe typical content that can be expected in the DocumentVersions of a specific type.

However, as the DocumentVersion is primary an entity from the domain of the creating process, the content and the given Specifications may vary.

Part Master

A part master document describes the properties of a component or a group of components (a PartVersion or a set of PartVersion). It contains some general purpose specifications that provide information for any component type. Those specifications are not mandatory and only necessary if the corresponding information aspect is relevant and can be provided. Examples are:

• GeneralTechnicalPartSpecification for common properties like weight or material.
• PlaceableElementSpecification for components that have a position in the topology.
• LocalGeometrySpecification for information about the component’s geometry model, e.g. the bounding box, transformations, segment connection points.

Besides these general specifications a part master document contains a PartOrUsageRelatedSpecification corresonding to the PrimaryPartType (a ConnectorHousingSpecification in the illustration). That Specification provides the component type specific properties. If the component has a secondary component characteristics, more than one PartOrUsageRelatedSpecification can be contained.

Additionally, the document could contain auxillary specifications that are required for the complete component description (the CavitySpecification and SlotSpecification in the illustration). The emphasis here is on “could”, as this is a common case, but a process-specific interpretation. If for example 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. 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 connector (see Reuse of Documents).

Master Data Definition

In contrast to PartMaster documents MasterDataDefintions are not related to a specific component or a set of components (equivalent to part, part number, etc.). MasterDataDefintions are predefined standard information pieces in the process declared by some central organizational unit.

It is a common approach to manage certain information centrally and distribute it in the development processes. The definition of this information is usually independent of specific development projects and ensures the adherence to certain conventions and guidelines across (all) development projects. The component master data is a very specific aspect of this information as it always refers to a component (with a part number). In addition, there is a wide range of other information that is not directly related to a specific component but is nevertheless managed centrally.

Such DocumentVersions with central definition, that are not related to specific PartVersion are summarized under the DocumentType MasterDataDefinition. Examples for such centrally distributed informations are:

• Usage Node Lists (UsageNodeSpecification),
• Signal Catalogs (SignalSpecification), or
• Standardized Base Specifications (e.g. CavitySpecification, InsulationSpecification)

Extension of Master Data Definitions

A VEC that requires master data definitions of a specific type (e.g. signals, usage nodes) can obtain these from different sources (e.g. seperate signal catalogues for power & information). A special use case of this is the addition / extension of a master data definition with individual information in a specific development artifact.

Example: New signals might be required in the system schematic of a new series that are not (yet) included in the master data definition. These additions could be contained in a local signal catalog of system schematic, while the central master data catalog is used for the other signals. When the development process has progressed, these local definitions might be included in the master data definition.

The following bulletins illustrate some examples of different, process specific consistency relationships. The examples are from the context of the above mentioned “signal catalogues”.

• Different Sources for separate domains (e.g. power signals vs. information signals): In this case, there should be no overlaps between the defined entities.
• Local / project specific definitions vs. global definitions: In this case it depends on the degree of freedom allow for project specific definition. Or, viewed from the other direction, on the binding nature of the global definitions. This determines whether only new information may be added or whether existing elements may be overwritten with other information.

In any case, the order of precedence has to be defined for the different sources. However, this is mainly an issue for the business logic of an authoring use case (which elements can be defined or selected by the user in a certain context). In the data exchange use of the VEC, the elements from the different sources are explicitly referenced. So at any time it is unambiguously defined which elements have been used / selected, even though the rules why an element took precedence over another are not contained in the VEC (compare figure Master Data Extension)

Change Tracking

As described in detail in the Implementation Guideline “General Structure / Usages of the DocumentVersion” one use case of the DocumentVersion is to serve as a payload data container within the VEC, either for the digital representation of an external document or for native digital data. This Implementation Guide is about the possibilities to track changes and modifications of this payload data within the VEC. Be sure to read Parts and Documents before, as it contains important information about this topic.

Aligned with established PDM practice, the data in the VEC is organized in DocumentVersions. A fundamental principle in the VEC is, that a specific DocumentVersion is unambiguously identified by CompanyName, DocumentNumber and Version. However, this identification and versioning is primarily of a process-oriented rather than a technical nature. From a data oriented technical point of view, you can have different digital representations of the same source document in the VEC (e.g. if the same document specifies multiple parts and you want to create one VEC file per part, or if you need different levels of detail in the data for different scenarios). This is perfectly valid, as long as the overlapping content areas do not contradict each other (see Figure 1 on the right side). In such scenarios the identifying attributes, in particular also the Version will be same since the source document has not changed, although the digital representation is different.

Figure 2 below illustrates this in more a more detailed example. Let us assume, there is a technical drawing or data sheet of a component. This is the original source of information, with all PDM information like formal approvals etc. This document therefore defines the CompanyName, DocumentNumber and Version. The content of the document is then transferred into an IT-System (e.g. a component database) either by automatic import or by manual input (marked with (1)). A digital representation is created.

From this system the data can exported / provided in two flavours, one for internal use with more information and one for external use with less information (marked with (2) and (3)). Another two digital representations are created. In the next step, the provided component data might be used in another system to create a harness definition and a portion of the component data is embedded into the harness definition (marked with (4)). Yet another digital representation is created.

There are any number of conceivable ways in which a digital representation of information can change without the original document changing:

• A mistake during in the manual input in step (1) or a bug in the importer.
• A feature update of the system storing the data, allowing more information to be stored.
• Changes to the export component
• …

In order to allow the content of DocumentVersion in the VEC to be marked as changed, without having the source document changed, the DigitalRepresentationIndex was introduced. If the DigitalRepresentationIndex has changed, the content of the DocumentVersion must be checked for changes, otherwise the content can be assumed unchanged (see Parts and Documents for a definition of “unchanged”).

Details of the Application of the DigitalRepresentationIndex

When to Use

The DigitalRepresentationIndex is an optional feature of the VEC that softens the requirements for the change semantic of CompanyName, DocumentNumber and Version in cases where the content of a DocumentVersion changes, without being able to at least adjust the Version-attribute.

When to Modify

If the DigitalRepresentationIndex has not changed between two VEC files, this can be taken by a reading system as an assurance that the payload content is unchanged. The DigitalRepresentationIndex shall be different, whenever the payload content of a DocumentVersion is different. If a clear statement is not possible, a change is to be assumed in case of doubt. A change of the DigitalRepresentationIndex is necessary for example in the following cases:

• A different digital representation is created due to a changed tool behavior or a changed export interface (see figure on the right ), e.g. more information, bug fixes, new features.
• The content in the source system has changed, e.g. improved data management in the process, correction of typos.
• Different views with different level of details of the same data set, e.g. export for internal and external use.

How to Create

The VEC does not define any specifications for the construction of the DigitalRepresentationIndex (e.g. syntax, order). The only requirement is, that two values can be checked of equality. If the values are equal, the payload data can be assumed unchanged, if the values are different, the payload data might be different as well.

It is up to the discretion and capabilities of the generating system to define a suitable and possible algorithm to generate the index. However, it should always be taken into account that an unnecessary change indication creates needless overhead on the side of the reading systems.

Possible approaches include:

• An internal change tracking index of the creating system (e.g. revision number)
• A checksum created over the relevant payload data
• A timestamp, either of the last change in the creating system or the time of the VEC creation.
• A UUID identifying a specific digital representation. Each time a new digital representation is created a new UUID is generated.

Expected Behaviour of VEC Interfaces

A wide range of different systems, supporting different use cases, are used in the process of wiring harness development. All of them might have a VEC-Interface for input & output, so sooner or later the question arises “What are the expectations for the behavior of those interfaces?”. This section will discuss this question.

In a document based data exchange scenario (e.g. working with a word processor) the intuitive expectation is, that a document (file) is “opened”, changes are preformed by the user and then, the document is “saved” again, with the document containing the original content plus the modifications.

However, this simple and intuitive approach is not feasible in a model based data exchange scenario like the one for the VEC. The VEC is not intended to be a file-based database that contains all information about a vehicle network, which grows continuously over the time (like a Word or ODT file of a book). The basic idea of the VEC is, to provide a consistent language (model) for data exchange in the process of wiring harness development and to allow the exchange of use case specific slices of information within the process between systems and organizations.

This fundamental concept means that there is no such thing as “the one VEC interface”. The important question is, which use cases (or slices) of the VEC data model are supported or required for a specific interface.

Let’s assume that in our system landscape one component is responsible for the synthesis of electrology and geometry, and the derivation of a wiring harness from it. Such a system would potentially have 4 interfaces requiring different sections of the VEC model:

• Topology (IN)
• System or Wiring Schematic (IN)
• Part Master / Component Data (IN)
• Harness Definition (OUT)

In addition, the scope and validity of the different information slices may vary. For example, component data could be updated daily, with only the changed components at a time, but with a global validity, while a wiring harness definition is only valid for a specific vehicle context.

Even when considering only these examples, it is already obvious that it does not make any sense to formulate requirements on cross-relationships between imported and generated VEC data, like “a system has to be able write all VEC data it has imported in an unchanged matter”.

Content of a VEC

A VEC can contain any scope, amount and combination of information that is valid, with respect to the VEC Model and the Implementation Guidelines. There shall be no requirement to create VECs with restricted content specifically for importing / receiving systems.

A receiving system shall be able to accept any valid VEC. If the VEC contains more than the required information of the system, the system is free to ignore the pieces of information irrelevant for its purpose. It does not have to store the ignored pieces for a later reexport. However, it shall not refuse the import of a VEC because of “too much” information.

On the other hand, it is up to the system to verify that a VEC contains enough information for the use case of the system. If that is not the case, the system can reject the import because of “too little” information.

Traceability Scenarios

Even though it is not possible to define general relationship requirements between imported and exported data, there are use cases in which a traceability between imported and exported data is required. In such cases, slices of imported data might be embedded into the exported data. This scenario is described in section “Combination and Reuse of Documents”

Usage Nodes

The example illustrates the use of UsageNodes. A UsageNode represents a position in an abstract vehicle. For example the Head Light Left. UsageNodes belong to the master data and they are defined on some company wide level. They can be used to enforce consistent naming over different projects and different development streams (e.g. between geometry and electrologic).

A UsageNode can be subdivided into more detailed UsageNodes. For example the Head Light can be split up into Main Beam, Low Beam and Direction Indicator.

The diagram above shows this usage of sub usage nodes. There is one main usage node “A20” with it’s sub nodes “A20*1”, “A20*2” and “A20*3”. For simplification of the following code snippet only the XML representation of the definition of the parent usage node “A20” and its child node “A20*1” is shown.

<Specification xsi:type="vec:UsageNodeSpecification" id="id_usage_node_spec_1">
  <Identification>UsageNodeList</Identification>
  <UsageNodes id="id_usage_node_1">
    <Identification>A20</Identification>
    <Description xsi:type="vec:LocalizedString" id="id_1">
      <LanguageCode>En</LanguageCode>
      <Value>Head Ligth left</Value>
    </Description>
    <SubUsageNodes>id_usage_node_2</SubUsageNodes>
  </UsageNodes>
  <UsageNodes id="id_usage_node_2">
    <Identification>A20*1</Identification>
    <Description xsi:type="vec:LocalizedString" id="id_2">
      <LanguageCode>En</LanguageCode>
      <Value>Main Beam</Value>
    </Description>
  </UsageNodes>
[...]
</Specification>

Physical Properties

Numerical Values

Many technical properties are defined as NumericalValue. Those consist of a numerical value in a defined Unit and an optional Tolerance.

The object diagram above illustrates the VEC representation of the following value:

$$105.23 \ \Omega /km \pm 20.0$$

Units

Units that are used within a VEC are defined globally within the VEC file (under the VecContent) and reused / referenced by each NumericalValue. The VEC allows a wide variety of different Units from different systems of units. The following XML snippet contains some concrete examples for Units. The first three units (id_unit_1, id_unit_2 & id_unit_3) in the snippet are the XML representation of the example above.

<vec:VecContent ...>
    [...]
    <Unit xsi:type="vec:SIUnit" id="id_unit_1">
        <SiUnitName>Ohm</SiUnitName>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_2">
        <Exponent>-1</Exponent>
        <SiUnitName>Metre</SiUnitName>
        <SiPrefix>Kilo</SiPrefix>
    </Unit>
    <Unit xsi:type="vec:CompositeUnit" id="id_unit_3">
        <Factors>id_unit_1 id_unit_2</Factors>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_6000">
        <Exponent>2</Exponent>
        <SiUnitName>Metre</SiUnitName>
        <SiPrefix>Milli</SiPrefix>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_170">
        <SiUnitName>Gram</SiUnitName>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_442">
        <SiUnitName>DegreeCelsius</SiUnitName>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_189">
        <SiUnitName>Ampere</SiUnitName>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_445">
        <SiUnitName>Volt</SiUnitName>
    </Unit>
    <Unit xsi:type="vec:SIUnit" id="id_unit_196">
        <SiUnitName>Second</SiUnitName>
    </Unit>
     [...]
</vec:VecContent>

Reference Systems

This tutorial demonstrates how values with reference systems shall be used. In many cases (e.g. Colors) there is no single correct way to express a certain literal, but many different ways.

In order to correctly express such values, the VEC gives the possibility to define not only the value, but also the reference system in which the value is defined. This means if there have three valid ways to express the Color “Red”, the VEC allows to define and differentiate all of them. If the value is defined in some standard reference system this ca be used (e.g. RGB or RAL for colors). If the value is defined in some company specific reference system, this can be defined, too (see ACME Inc.). For attributes like the “baseColor” of a wire insulation it is possible to define the single value in the representation different reference systems (in the example the color RED in RGB, RAL and a company specific “ACME Inc.” system). However all given representations shall refer to the same “real” value.

The example shown in the figure Reference Systems has the following XML representation:

<vec:VecContent ...>
    [...]
    <DocumentVersion id="id_1">
        [...]
        <Specification xsi:type="vec:InsulationSpecification" id="id_2">
            <Identification>...</Identification>
            <BaseColor id="id_3">
                <Key>#CC0605</Key>
                <ReferenceSystem>RGB</ReferenceSystem>
            </BaseColor>
            <BaseColor id="id_4">
                <Key>3020</Key>
                <ReferenceSystem>RAL</ReferenceSystem>
            </BaseColor>
            <BaseColor id="id_5">
                <Key>RD</Key>
                <ReferenceSystem>ACME Inc.</ReferenceSystem>
            </BaseColor>
        </Specification>
    </DocumentVersion>
    [...]
</vec:VecContent>

Custom Properties

This implementation guideline gives more details and examples on the usage and the correct interpretation of the VEC concept: Extensibility with Custom Properties.

CustomProperty is available in all subclasses of ExtendableElement. In the following examples the class Person is used, which intentionally is not a subclass of ExtendableElement, but for a clear and easy to understand example of custom properties it is well suited.

The left side shows the Person class as defined in the VEC. The right hand side shows an excerpt from the domain of an arbitrary Tool. As you can see in the UML model, the class on the right side contains the attributes employeeNumber and different usages of the class Address, which are both not represented in the VEC. Despite the lack of explicit modelling concepts with this specific semantic, the extension mechanisms of the VEC still allow the exchange of this information within the VEC. The VEC supports extensions of the following type:

• Additional properties (attributes), either single or multi-valued (All subclasses of CustomProperty, e.g. SimpleValueProperty or BooleanValueProperty).
• Contained structures, either single or multi-valued (the ComplexProperty, e.g. simple objects like the address).

These concepts do not support the extension of elements with additional relationships (IDREF in XML).

XML Examples / Snippets

The following XML snippets illustrate the correct usage of the concepts to support the business model shown in the UML diagram above.

Simple Property

The snippet shows the extension of a Person object by the property EmployeeNumber (String). The VEC supports a wide range of primitive property types (e.g. Boolean, Date, Numerical, see the subclasses of CustomProperty for a complete list), so keep in mind to choose the correct type for the corresponding value.

<vec:VecContent ...>
    [...]
    <Person id = "id_01">
      <CustomProperty id="id_01_1" xsi:type="vec:SimpleValueProperty">
          <PropertyType>EmployeeNumber</PropertyType>
          <Value>ABC123</Value>
      </CustomProperty>
      <Department>IT</department>
      <FirstName>John</firstName>
      <LastName>Doe</lastName>
    </Person>
    [...]
</vec:VecContent>

Complex Property

If a VEC object is to be extended by an attribute of a structured data type, the approach is analogous to the simple property. Only a ComplexProperty is used instead. The PropertyType defines the role of the structured data in the context of the parent object (in other words the “attribute name”, e.g. HomeAddress). The individual attributes of the structured data type in turn are then mapped as simple properties within the ComplexProperty. For deeper structured data it is perfectly valid to define ComplexPropertys that contain ComplexPropertys again.

If the same data structure (not the same data) should appear in different roles (e.g. HomeAddress, WorkAddress) another ComplexProperty with a different PropertyType is defined. A concept for sharing / reusing the data defined in such structures is not part of the VEC extension concepts.

<vec:VecContent ...>
    [...]
    <Person id = "id_01">
        <CustomProperty id="id_01_1" xsi:type="vec:ComplexProperty">
            <PropertyType>HomeAddress</PropertyType>
            <CustomProperty id ="id_01_1_1" xsi:type="vec:SimpleValueProperty">
                <PropertyType>Street</PropertyType>
                <Value>Central Street 1</Value>
            </CustomProperty>
            <CustomProperty id ="id_01_1_2" xsi:type="vec:SimpleValueProperty">
                <PropertyType>City</PropertyType>
                <Value>Anytown</Value>
            </CustomProperty>
            <CustomProperty id ="id_01_1_3" xsi:type="vec:IntegerValueProperty">
                <PropertyType>PostalCode</PropertyType>
                <Value>04325</Value>
            </CustomProperty>
        </CustomProperty>
        <CustomProperty id="id_01_2" xsi:type="vec:ComplexProperty">
            <PropertyType>WorkAddress</PropertyType>
            [...]
        </CustomProperty>
        [...]
    </Person>
    [...]
</vec:VecContent>

Multi-Valued Custom Properties

If an object shall be extended by a multi-valued property (e.g. AdditionalAddresses) multiple custom properties (either simple or complex) with the same PropertyType are defined.

<vec:VecContent ...>
    [...]
    <Person id = "id_01">
        <CustomProperty id="id_01_1" xsi:type="vec:ComplexProperty">
            <PropertyType>AdditionalAddresses</PropertyType>
            <CustomProperty id ="id_01_1_1" xsi:type="vec:SimpleValueProperty">
                <PropertyType>Street</PropertyType>
                <Value>Central Street 1</Value>
            </CustomProperty>
            <CustomProperty id ="id_01_1_2" xsi:type="vec:SimpleValueProperty">
                <PropertyType>City</PropertyType>
                <Value>Anytown</Value>
            </CustomProperty>
            <CustomProperty id ="id_01_1_3" xsi:type="vec:IntegerValueProperty">
                <PropertyType>PostalCode</PropertyType>
                <Value>04325</Value>
            </CustomProperty>
        </CustomProperty>
        <CustomProperty id="id_01_4" xsi:type="vec:ComplexProperty">
            <PropertyType>AdditionalAddresses</PropertyType>
            [...]
        </CustomProperty>
        [...]
    </Person>
    [...]
</vec:VecContent>

Tailoring Mechanisms

Motivation and Objective

The VEC provides a comprehensive model for the digital description of a wide variety of information and their relationships to each other in the context of the electrical system development process. Despite the striving for the greatest possible semantic precision, the demand for general applicability of the standard means that, at various points restrictions cannot be formulated to the same extent as it would be possible in the context of a very specific use case or a company context. This applies to the following examples, among others:

• The set of valid model elements: Probably no use case requires all 450+ classes of the VEC at the same time and the set of required model elements is highly dependant from the use case itself.
• Valid values for attributes: The allowed patterns and / or discrete values (enumerations) of attributes can depend on a specific use case or company context and can even change over time (e.g. new technologies)
• The balance between mandatory and optional information: The amount and completeness of information contained in a VEC depends on the use case and process. While it might perfectly ok the have some missing information in an early phase of the process, it might intolerable at a later stage.

This implementation guideline presents three approaches for adapting the model to address the above issues in specific application scenarios, while still maintaining compatibility with the standard:

1. Custom Open Enumerations: New literals can be added to open enumerations (see Open and Closed Enumerations)
2. XSD 1.1. Assertions: The schema can be enriched with assertions to be more restrictive.
3. Schema Filtering: With “Schema Filtering” the schema can be made less extensive and by this also more restrictive (Less allowed classes, attributes etc.).

All these approaches have in common, that the schema of the standard is adapted / modified in a suitable form. The result is a tailored “VEC” schema that is specific for the use case, but still compatible with the regular VEC schema.

This Implementation Guideline explains how these modifications can be achieved in an efficient way based on XSLT. XSLT is a useful technology, when:

• you want to modify XML data,
• you can define the modification based on rules,
• the general structure of your result is close to the input,
• and performance is not critical.

This makes it the perfect solution for this use case, where we want to modify the XML Schema of the VEC at very specific locations while keeping the rest unchanged.

General Concept

The general concept is illustrated in the figure above. The customization rules are defined in an “compiler XSL-file”. This file defines how the extensions are made in the schema syntactically. It compiles the customizations into an existing schema. For example, in case of open enumerations, the compiler file defines at which position in XSD new literals are to be inserted. The compiler files are universal and independent of the specific context (e.g. company, use case) of the customization. For open enumerations and assertions such compiler files are provided here.

The actual customizations are defined in an external XML data file (Customization Definition in the figure above). For example, in case of open enumerations, the data file defines which enumerations should be extended with which literals. This information is specific to the customization context and has to be created by oneself during the customization process. The syntax of the data file depends on the compiler file, but is usually trivial.

To create a custom VEC schema, the desired schema variant (strict or not) of the underlying VEC version is passed into a XSLT transformation pipeline, with the Compiler XSL as transformation. The data file is side loaded from the Compiler XSL.

Run the Transformation

java -cp /path/to/saxon.jar net.sf.saxon.Transform \
   -xsl:./path/to/compiler.xsl 
   -s:/path/to/vec.xsd 
   -o:/path/to/result.xsd 
   data-file=url-to-data-file.xml

If the url-to-data-file.xml is a relative path, then it is relative to the compiler.xsl. The easiest way is to place required files (including the data file) in the current working directory.

Open Enumerations

Open Enumerations are a concept in the VEC to have predefined values for attributes, whilst being open for extension (for details see the corresponding recommendation chapter Open and Closed Enumerations). Two schema variants are provided officially for the VEC: the regular and the strict schema. The regular schema can be used for pure syntax validation of VEC files. However, it makes no restrictions for the use of values in attributes with an open enumeration type. The strict schema restricts these attributes to have only values that are defined literals from the VEC standardization board in the corresponding open enumeration. The advantage of using the strict schema is that you are able to validate that only defined literals have been used.

However, if you extend¹ an open enumeration with new literals, e.g. for your process specific requirements, or new wiring harness technologies, then the strict schema validation will break. In this case it is not possible anymore to check if only defined values, either by the standard or the process, have been used. Nevertheless, it would be highly appreciable to still have such a mechanism in place. To achieve this, you need an extended strict schema, that includes the values from the standardization board and the process specific values. This implementation guideline is about creating such an extended strict schema.

What you need

The generation of such an extended strict schema is done as described in section General Concept. As input, you need:

1. The Compiler XSL: vec-open-enum-compiler.xsl
2. A definition of your enumeration extensions, an example can be found here: enum-literals.xml

Define new Enumerations

The enum-literals.xml (link above) file contains examples on how to add custom enumerations.

<?xml version="1.0" encoding="UTF-8"?>
<enum-profile>
    <enum type="WireReceptionType">
        <literal name="MyExampleLiteral">
             My example description with html elements <br/>
        </literal>
        <literal name="MyExampleLiteral2" />
    </enum>
    <enum type="WireLengthType">
        <literal name="MyExampleLiteral3">
             My second example description
        </literal>
    </enum>
</enum-profile>

This example adds a literal with the name MyExampleLiteral to WireReceptionType with a description (Note that it is possible to include html tags) and a literal without a description named MyExampleLiteral2. It also adds MyExampleLiteral3 to WireLengthType.

If a new VEC version is released, this file can be used recreate an updated company specific scheme (without having to repeat all changes manual).

Schema Assertions

XSD 1.1 introduced a concept to define Assertions within a XSD:

An assertion is a predicate associated with a type, which is checked for each instance of the type. If an element or attribute information item fails to satisfy an assertion associated with a given type, then that information item is not locally valid with respect to that type.

Assertions are defined as XPath 2.0 expressions that are evaluated to true or false. This makes it possible to express much more meaningful rules in the schema than it is possible with the pure syntax checking of XSD 1.0. In particular, it is not only possible to further restrict the multiplicities of attributes, but more complex conditions, such as dependencies between attributes, can be expressed (e.g. like “if type is ‘rectangle’ then count(sides) must be greater equal 4”).

The great benefit of this approach is, that these rules are validated during a regular schema validation with a standard XML Parser.

What you need

The generation of such an asserted schema is done as described in section General Concept. As input, you need:

1. The Compiler XSL: vec-assertions-compiler.xsl
2. A definition your custom assertions, an example can be found here: data-profile.xml

Define Assertions

The data-profile.xml (link above) file contains examples on how to add custom assertions.

<?xml version="1.0" encoding="UTF-8"?>
<data-profile>
    <context type="ConductorSpecification">
        <rule test="CrossSectionArea">
             All conductors shall specify a cross section area. The cross section area is an 
             important parameter for numerous design rules (e.g. aggregated cross section area 
             of splices). 
        </rule>
        <rule test="CrossSectionArea/ValueComponent gt 0.0">
            A conductor with cross section area not greater than 0 is non-existent.
        </rule>
    </context>
    <context type="CavityAddOn">
        <rule test="WireAddOn/ValueComponent gt 0.0"/>
    </context>
</data-profile>

context type="..." defines the VEC class to which an assertion should be added. rule test="..." defines the XPath expression of the assertion that should be added to corresponding type. The above data-profile results in the following XSD:

<?xml version="1.0" encoding="UTF-8"?>
...
<xs:complexType name="ConductorSpecification" abstract="true">
    <xs:complexContent>
        <xs:extension base="vec:Specification">
            <xs:sequence>
                ...
            </xs:sequence>
            <xs:assert test="CrossSectionArea">
                <xs:annotation>
                    <xs:documentation xml:lang="en"> All conductors shall specify a cross section
                        area. The cross section area is an important parameter for numerous design
                        rules (e.g. aggregated cross section area of splices). </xs:documentation>
                </xs:annotation>
            </xs:assert>
            <xs:assert test="CrossSectionArea/ValueComponent gt 0.0">
                <xs:annotation>
                    <xs:documentation xml:lang="en"> A conductor with cross section area not greater
                        than 0 is non-existent. </xs:documentation>
                </xs:annotation>
            </xs:assert>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
...

Schema Filtering

The VEC is a comprehensive model with a variety of classes and attributes. In very few cases all of them are needed at the same time. For this reason it may be desirable to restrict the number of valid schema elements for specific interfaces. Schema Filtering can be useful in these cases.

For example, an interface for the exchange of UsageNodes would only require a handful of VEC core classes. Another scenario might be that you want to prohibit the use of CustomProperty in your own process. Many scenarios are conceivable, in the core it always burns down to limiting the power of the VEC purposefully to achieve a better controllability for certain use cases and interfaces.

Since the scenario of Schema Filtering is more complex and less straight forward, than the Open Enumerations scenario, the following section just provides an idea for a possible approach and not a “ready-to-use” solution.

The basic idea here is, that an XSLT script simply removes all unnecessary elements and leaves the rest unchanged. You can use either a positive or negative filter approach. In our example, we use a negative filter list (all elements on the list are removed). When removing a class it is not sufficient to only remove the class itself. All usages of the class must be removed as well. A class that has mandatory usages by other classes, can not be removed unless all usages are removed recursively till an optional point is reached.

The file vec-tailor-schema.xsl contains an example on how to remove the Transformation2D from the VEC scheme. The following snippet shows the relevant parts only. The rest of the XSLT script is known known as identity transformation (copy of the source into the destination without changes).

The first line removes the class itself. The second line removes all optional attributes with the type Transformation2D. If you validate the resulting schema you can easily check if the Transformation2D has any mandatory usage that have been overlooked (it has not).

    ...
    <xsl:template match="xs:complexType[@name='Transformation2D']" />

    <xsl:template match="xs:element[@type='vec:Transformation2D' and @minOccurs=0]" />
    ...

Unfortunately IDREF attributes cannot be handled in this fashion automatically, but have to be checked manually. The figure on the right side displays the occurrenceOrUsage association between OccurrenceOrUsageViewItem2D and OccurrenceOrUsage. Associations are translated into IDREF or IDREFS in the XML Schema, in contrast to aggregations that are translated into contained xs:element (compare Mapping of the VEC Model to XML schema definition (XSD)). The XML Schema representation of the association is the following:

<xs:complexType name="OccurrenceOrUsageViewItem2D">
    <xs:complexContent>
        <xs:extension base="vec:ExtendableElement">
        <xs:sequence>
            ...
            <xs:element name="OccurrenceOrUsage" type="xs:IDREFS" minOccurs="0"/>
            ...
        </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

That means a filtering rule cannot be formulated based on the target type of the association, as this type unknown in the XSD (in contrast to contained elements). Therefore a filtering rule must be more specific by explicitly addressing each relevant association, like this:

    ...
    <xsl:template match="xs:element[@name='OccurrenceOrUsage' and
        ancestor::xs:complexType[@name='OccurrenceOrUsageViewItem2D']]" />
    ...

System Schematic

System Schematic Basics

The system schematic is used to illustrate the electrical components (e.g. ECUs, sensors or switches) in a vehicle electrical system and their connections to each other on an electrological level without physical realization details. In many companies the system schematic is specific for an individual system and not an individual vehicle variant. The example below shows such a system schematic with four components (MX1.1, MX3.1, MX3.2 and E1.1), which are connected to each other in some way. On the connection lines the potential names can be found. Furthermore the component E1.1 is connected to additional elements on another sheet / in another system, which is suggested by the arrow on the very bottom. This is explained in more details in the section Partial Systems.

To represent a system schematic in the VEC the ConnectionSpecification and its subelements are used. E/E-Components (in some ECAD Systems called Block) are represented by ComponentNodes. A ComponentNode is a node where an electrological component is located. It is a representative for an element in the electric system, e.g. an actuator, a sensor, an ECU. This diagram contains the representation as VEC classes of the system schematic shown in the example. The ComponentPort (Pins) of a ComponentNode are grouped into Connectors / Slots with the help of ComponentConnectors. In the example the connectors are only represented implicitly by the prefix “A” to the Pin-Number.

Even if the system schematic in this example only shows pins which are connected to other pins (of other components), the VEC representation of the component (ComponentNode) is explicitly allowed to contain ComponentPorts for unused pins. For example a component with 5 pins where just pin no. 1 and 5 are connected in some way may contain ComponentPorts for the pins 2 - 4 (but is not required to). This underlines that these pins do physicaly exists. There is no need of a reference from a Connection to one of the ComponentPorts via a ConnectionEnd.

The following XML listing contains the component nodes and connection from the example above.

<Specification xsi:type="vec:ConnectionSpecification" id="id_connect_spec_1">
    <Identification>ConSpec_V..58L..</Identification>
    <ComponentNode id="id_comp_node_1">
        <Identification>MX1.1</Identification>
        <ComponentConnector id="id_component_connector_1">
            <Identification>A</Identification>
            <ComponentPort id="id_comp_port_1">
                <Identification>1</Identification>
            </ComponentPort>
        </ComponentConnector>
    </ComponentNode>
    <ComponentNode id="id_comp_node_2">
        <Identification>MX3.1</Identification>
        <ComponentConnector id="id_component_connector_2">
            <Identification>A</Identification>
            <ComponentPort id="id_comp_port_2">
                <Identification>1</Identification>
            </ComponentPort>
        </ComponentConnector>
    </ComponentNode>
    <ComponentNode id="id_comp_node_3">
        <Identification>MX3.2</Identification>
        <ComponentConnector id="id_component_connector_3">
            <Identification>A</Identification>
            <ComponentPort id="id_comp_port_3">
                <Identification>1</Identification>
            </ComponentPort>
        </ComponentConnector>
    </ComponentNode>
    <ComponentNode id="id_comp_node_4">
        <Identification>E1.1</Identification>
        <ComponentConnector id="id_component_connector_4">
            <Identification>A</Identification>
            <ComponentPort id="id_comp_port_4">
                <Identification>1</Identification>
            </ComponentPort>
        </ComponentConnector>
    </ComponentNode>
    <Connection id="id_connection_1">
        <Identification>V..58L..</Identification>
        <ConnectionEnd id="id_conn_end_1">
            <Identification>MX1.1-A1</Identification>
            <ConnectedComponentPort>id_comp_port_1</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="id_conn_end_2">
            <Identification>MX3.1-A1</Identification>
            <ConnectedComponentPort>id_comp_port_2</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="id_conn_end_3">
            <Identification>MX3.2-A1</Identification>
            <ConnectedComponentPort>id_comp_port_3</ConnectedComponentPort>
        </ConnectionEnd>
    </Connection>
    [...]
</Specification>

Potential Nodes

As mentioned before, the level of abstraction of the system schematic in the VEC (represented by the ConnectionSpecification) contains only the electrological design and no physical design of the wiring harness. Therefore, the black dots (circled in red) in the graphical example have only a layouting purpose and do not represent a technical design decision (e.g. to place a splice on this spot).

The expressed engineering intention is only that the connected pins (all “A1”) have the same potential (are connected in some way). The decision about a technical realization (e.g. splice, multicrimp, single wires) can not be made is most cases at the stage of a system schematic, because a technical realization depends on concrete variant combinations and might be even different for different variants (see section Wiring) or it can be unnecessary, because in a reduced 100% variant, there might be just two of the three components left and a realization with a single wire would be possible. As the VEC does not represent the graphical layout of documents these nodes have no representation in VEC.

If the system schematic should explicitly contain the engineering intention of a specific connection topology (e.g. a star like topology with a splice or a potential distributor) this must be explicitly represented by an individual design of one ore more ComponentNodes and Connections. Such a ComponentNode should have the ComponentNodeType = 'PotentialDistributor'. The illustrations below show the example of a CAN bus system with and without explicit distribution.

As you can see in the illustration of the central distributed CAN bus, the component node of the distributor “CAN” uses internal connections to represent the short-circuited pins. More information about internal conectivity can be found in this section below.

Partial Systems

During the development of individual systems or sub systems for a vehicle the corresponding system schematic is often incomplete (partial). This situation arises from the fact, that most systems depend on some kind of infrastructure of the integrated overall vehicle system (e.g. power, ground or bus connections), which is only a available in the context of the complete vehicle. In the example at the top such a link to an unspecified infrastructure is represented by the down arrow, in the following sections this is called an open link.

To create a fully functional system, a partial system must be merged / combined with other partial systems. In this process matching open links are connected (and thus removed) in order to create complete overall system. In the extended example this is illustrated by adding a second partial system schematic (framed in red) to the original example from the top. The resulting overall system schematic of such a merge process would just contain a simple connection between E.1.1 and M31.

The mapping of this advanced schematic example into the VEC context it is the following (see this diagram).

• To maintain the logical grouping of each partial system schematic, the content of each is contained in its own DocumentVersion with a single ConnectionSpecification in the same VecContent.
• The open link is represented by a “virtual” ComponentNode. Its naming is arbitrary and shall be choosen in a way, that a merge algorithm has the required information. For the clarity of the example it is here named GROUND. Depending on the used merge algorithm the name can be irrelevant if the merge algorithm for example only requires signal information.
• The “virtual” component node shall be marked with the ComponentNodeType literal OpenLink (see on the right).

This diagram shows the extended version with the ComponentNode “GROUND”. As you can see the ComponentNode is marked with the node type “OpenLink” (red mark) to clarify that this component is NOT part of the system schematic but components from the plan DO HAVE a connection to it.

Caution: The strategy and algorithm to merge partial systems if individual for the different ECAD systems and development processes. The VEC does not define an algorithm or requires a specific strategy. The VEC only the means to store and exchange the information that is required by those algorithms. When merging the definition of these partial systems together into one vehicle system, it is mandatory to resolve these open links and replace them by determined ComponentNode elements or Connection:

• Case 1: The open link component node is replaced by a real component with the required connectivity.
• Case 2: If multiple real component nodes have connections to different open link component nodes, the open link nodes can be merged to a single connection among the real component nodes.

Note: It is possible to reference a ComponentPort from a Connection.ConnectionEnd even if they are contained in different DocumentVersions.

The following listing shows the additional ComponentNode as XML.

<Specification xsi:type="vec:ConnectionSpecification" id="id_connect_spec_1">
    <Identification>ConSpec_V..58L..</Identification>
    [...]
    <ComponentNode id="id_comp_node_4">
        <Identification>E1.1</Identification>
        <ComponentConnector id="id_component_connector_4">
            <Identification>A</Identification>
            <ComponentPort id="id_comp_port_4">
                <Identification>1</Identification>
            </ComponentPort>
        </ComponentConnector>
    </ComponentNode>
    <ComponentNode id="id_comp_node_5">
        <Identification>GROUND</Identification>
        <ComponentNodeType>OpenLink</ComponentNodeType>
        <ComponentConnector id="id_component_connector_5">
            <Identification>A</Identification>
            <ComponentPort id="id_comp_port_5">
                <Identification>1</Identification>
            </ComponentPort>
        </ComponentConnector>
    </ComponentNode>
    [...]
    <Connection id="id_connection_1">
        <Identification>GROUND..SYS_055A</Identification>
        <ConnectionEnd id="id_conn_end_1">
            <Identification>E1.1-A1</Identification>
            <ConnectedComponentPort>id_comp_port_4</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="id_conn_end_2">
            <Identification>GROUND-A1</Identification>
            <ConnectedComponentPort>id_comp_port_5</ConnectedComponentPort>
        </ConnectionEnd>
    </Connection>
</Specification>

Internal Connectivity

The system schematic layer in the VEC allows not only the mapping of Connections between different ComponentNodes, but also the mapping of internal connections within a ComponentNode. Examples are fuses, relays, power and potential distributors or fuse or relay carriers.

In the VEC these connections do not differ in modelling from ‘normal’ ones in the level of abstraction of the system schematic. The only difference is the value of the flag isExternalEnd for their ConnectionEnds. The value of this flag has to be set from the ComponentPorts point of view and its relation to the Connection:

• If the Connection is attached from the outside to the ComponentPort, e.g. it is a connection between two independent ComponentNodes, then it is isExternalEnd = true.
• If the connection is attached from the inside, e.g. it is a internal connection between two ComponentPorts of the same ComponentNode, then it is isExternalEnd = false.

Inner Structure of Component Nodes

In the system schematic, components are often considered black boxes. However, there scenarios where this is not sufficient and a view on the inner structure is required. Therefore, ComponentNode can be structured hierarchically. This requirement is also the logical consequence of the concept of subdivided UsageNodes. Since ComponentNodes are representatives / realizations of UsageNodes, at least the same representation options are required here (see this implementation guideline for more details).

Sub ComponentNodes are located inside their parent node. Connections to the “outer world” are mostly realized via a ComponentConnector of the parent node and internal connectivity between the connector of the parent node and its children. The following graphic illustrates this situation. The internal connections are shown as red lines.

The “outer world” (e.g. a system schematic or a wiring harness) interacts only with the parent node (black box). However, there are use cases, e.g. after sales service, where it is relevant to know which element of the “outer world” (e.g. a wire or a pin) is connected to which sub node, e.g. “Which wire is the power supply of the direction indicator?”. The representation of this information in the VEC is explained in the following paragraphs.

Both, parent node as well as child nodes are represented as ComponentNodes (highlighted in orange in the diagram above). The child ComponentNodes (e.g. “Low Light Node”) are contained in the parent ComponentNode (“Head Light Node”). A traceability to the corresponding UsageNode (highlighted in green) can be created with the realizedUsageNode association.

The parent and the child nodes define their electrical interface with ComponentConnectors and ComponentPorts. To represent the illustration, the parent node defines one ComponentConnector with three ComponentPorts, the child node defines one ComponentConnector with one ComponentPort. The internal connectivity is represented with a Connection between the ComponentPorts of the parent and the children (highlighted in red).

Variant Management For ECUs

This example demonstrates how the variant management can be handled in the systems schematic on different levels of abstraction.

The top most element is the usage node. It defines an abstract position / function in the vehicle. In the example it is the back light on the left hand side (named “MX3”). This function can be realized by two different electrological variants (interfaces). These variants are represented by ComponentNodes. In the example there is one variant with two pins (MX3.1) and one variant with three pins (MX3.2). On a more concrete level these interfaces can be satisfied by one or more EE-components (alternatives). These EE-Components are defined by PartVersion with a EEComponentSpecification. In order to define restrictions a corresponding PartOccurrence with a VariantConfiguration can be defined.

The PartUsages in the example are needed for to reasons:

• They serve as a container to group the different possible alternatives (“realizedPartUsage”).
• It is necessary to declare one of the EEComponents as the representative of all alternatives of a variant. This is done by the reference between the PartUsage and the corresponding EEComponentSpecification.

Wiring

The Wiring Layer in the VEC provides modeling concepts to define the physical realization of electrological connections from the System Schematic Layer. In the VEC, the same modeling concepts are use for this layer as for the mapping of a concrete wiring harness in the model.

However, in Wiring Layer representation the degree of freedom and number of unspecified facts are typically greater, than in a harness definition. For example the wiring layer would make statements about the cross section area of a wire or the color of its insulation, but it would not define a specific insulation material or wire length as the wiring layer is installation space agnostic in many development process.

Basically, there are three main modeling concepts:

1. The description and instantiation of parts (e.g. connectors, wires, terminals).
2. The contacting (marked with green dashed lines). It defines the relationship between terminals, wire ends and cavities.
3. The coupling (marked with red dashed lines). This is for connecting connectors with E/E components or with each other, or even to connect E/E components with each other.

Description and Instantiation of Parts

In contrast to the Network Architecture and the System Schematic the Wiring Layer does not define its own level of abstraction, instead it utilizes the existing modeling concepts in the VEC to describe the physical properties of the electrologically relevant components.

It is possible to use concrete PartVersions in the Wiring Layer, but typically not all relevant properties are defined in the Wiring Layer, so mainly PartUsages will be used (detailed description can be found here).

Contacting

The contacting in the VEC defines the relationship between Cavities (CavityReference), WireEnds, Terminals and Seals. Since there are various types of contactings possible, the different types are not defined explicitly in the VEC. The VEC offers a quite generic structure (the Contacting), which should be able to support all the different possible types. This is necessary, because the different contacting types are driven by technical requirements and new contactings might emerge over the time. The downside of the generic structure is that the structural schema allows constellations that are not sensible from a technical point of view as well. The following sections show the different contacting types used today, and how they have to be implemented in the VEC.

Since the contacting can be used for different levels of abstraction (Product Definiton or Electrological Wiring) only the “Role-Side” of the necessary objects is shown. Necessary PartOrUsageRelatedSpecifications, PartOccurrences, PartUsages and PartVersion are omitted.

Standard Contact

A standard Contacting is the most common case in a wiring harness. For a standard contact you have one wire end that has one terminal crimped on it, which is placed in one cavity. It exists in two variants, sealed and unsealed. The example displays the sealed variant, for the unsealed variant the CavitySealRole and the CavityPlugRole have to be omitted.

The contacting is defined by a ContactPoint, contained in a ContactingSpecification. It is possible (and recommended) to define multiple ContactPoints in one ContactingSpecification. Usally there exists one ContactingSpecification per DocumentVersion in the scope. So for example if the VEC-File represents a 150%-Harness definition, then you will have on ContactingSpecification for the complete harness.

A ContactPoint is defined as a point of exactly one electrical potential, which means all conducting components related to the ContactPoint are short-circuited.

The ContactPoint defines the terminal that is used for the contacting. It is then split up into two parts, the side of the crimp of the terminal (represented by the WireMounting) and the side of the terminal, which is placed in the cavity (represented by the CavityMounting). Since the example is about a sealed standard contact, the WireMounting displayed references exactly one CavitySealRole and one WireEnd, which means these two components are crimped together onto the terminal. On the other side the CavityMounting defines the Cavity in which the terminal will be placed. For a sealed environment it is necessary, that the Cavity is plugged with a CavityPlug, in case the Cavity is not occupied by a contacting. If the Cavity is occupied, the CavityMounting defines explicitly, which CavityPlugRoles are replaced by its existence.

Multi Crimp Contact

A Multicrimp is quite similar to the standard contact, with the difference that there is more than one wire crimped onto the terminal. Therefore the displayed example is quite the same. The differences are:

• There is no CavityPlugRole or CavitySealRole, since it is not usefull / possible from a technical point of view to seal a multicrimp.
• There are two (or more) WireEnds associated with the WireMounting.

For clarification of the example the two WireElementReferences reference their Signal. It is the same, since the two WireEnds are crimped onto one Terminal and therefore they are set to one single electrical potential. This is only displayed in the example in order to make it clear, what is meant by “A ContactPoint has one single electrical potential”. This is not a restriction of the VEC, since the development processes might need (or create) different signal names for the same electrical potential.

Ringterminal - Splice

The structure displayed in the example applies to ring terminals and splices as well. On the side of the wire it is the same as a multi crimp. The difference is that no cavity mounting is used, since a ring terminal / splice has no cavities.

Bridge Terminal

A bridge terminal is a terminal that has a wire crimped on it and which occupies more than one cavity (short-circuited). On the side of the wire it is the same as a standard contact. On the side of the cavities it simply references more than one cavity.

Coax Contact

The diagram displays the proper definition of a coax contacting. In the case of coax contact one single terminal is used, but two different electrical potentials are connected to it. Therefore two ConcactPoints are required, because one ContactPoint can only be used for one electrical potential (see the definition of a ConcactPoint).

Both ContactPoints reference the same occurrence of the terminal (TerminalRole) and use the Cavity. Each ConcatPoint mounts a single WireElement to the TerminalRole. In this example the two WireElements belong to the same multi-core wire.

In order to make the example more clearly, the next figure displays the definition of such a “coax-cavity” in an EEComponent.

Coax Cavity

The HousingComponent of an EEComponent defines on one hand the pins (electrological relevant information) in this HousingComponent and on the other hand a ConnectorHousingSpecification (the layout and design of the HousingComponent). The PinComponents are then positioned in the cavities. In the case of a coax contact, two PinComponents (the different electrical potentials) are placed in one cavity.

The HousingComponent of an EEComponent defines on one hand the pins (electrological relevant information) in this HousingComponent and on the other hand a ConnectorHousingSpecification (the layout and design of the HousingComponent). The PinComponents are then positioned in the cavities. In the case of a coax contact, two PinComponents (the different electrical potentials) are placed in one cavity.

Coupling Point

In the VEC the coupling / mating can be used to connect the harness side to another harness (in the case of an inliner) or to an ECU. The figure above shows a simplified example of the connection between an ECU (highlighted in orange) and a wiring connection (highlighted in blue). The MatingPoint simply connects the two TerminalRoles on each side. This method is used for example in a wiring definition, where the concrete connector is not yet known.

For this reason this example omits the geometric aspects of a coupling (connector housing, slots, cavities).

Direct Connectivity

As is to be expected for the design of wiring harnesses, most of the electrological connections of a system schematic are realized by wires. However, there are also cases where such connections are also realized without wires, e.g. with a direct screwing connection or simple plugging of two E/E components. The most common use case of such directly connected components are fuses which are plugged into a slot of a fuse carrier. Another example is the battery isolator (German: “Batterietrennelement”), illustrated on the right side. The battery isolator is connected directly to the battery with an integrated ring terminal, that is screwed onto the bolt of the battery. The representation of this szenario is explained in the following paragraphs.

Mapping in the Wiring Layer

Each of the E/E component instances is build up in the same way as seen in this diagram. A EEComponentRole has got one or more HousingComponentReferences with underlying PinComponentReferences for the pins. To make statements about the technical details of such a pin, a TerminalRole is used.

For the electrological connection / mapping of two pins, a MatingPoint is required, which creates the relation between the corresponding TerminalRoles. The MatingPoints are contained within a CouplingPoint in the CouplingSpecification. A CouplingPoint contains all MatingPoints for a single HousingComponentReference / ConnectorHousingRole (a detailed description can be found in the recommendation chapter Coupling Specification).

Note: In case of a terminal with multiple terminal receptions (with the possibility of separated potentials) a MatingDetail shall be used to define the mapping between specific TerminalReceptionReferences.

A detailed description of E/E components can be found in this tutorial.

Traceability to the System Schematic Layer

The system schematic layer contains no details about the physical realization. Therefore, no distinction is made in the system schematic layer between direct connections and wired connection. It is even possible to have different realizations of the same system schematic, one with a direct connection and one with a wired connection.

A detailed description to the system schamtic layer can be found in this tutorial.

To preserve traceability between the wiring layer and the system schematic, the element that realizes the the Connection has a reference to it. For a wired connection, this is the WireElementReference. In case of a direct connection, this is the MatingPoint or MatingDetail, depending on which level an unambiguous statement can be made. The following XML excerpt contains an example of traceability.

<Specification xsi:type="vec:CompositionSpecification" id="id_composition_1">
    <Component id="id_component_1">
        <Identification>Battery</Identification>
        [...]
        <Role xsi:type="vec:EEComponentRole" id="id_ee_role_1">
            <Identification>Battery</Identification>
            <EEComponentSpecification>id_ecomponent_spec_1</EEComponentSpecification>
            <HousingComponentRef id="id_housing_comp_ref_1">
                <Identification>A</Identification>
                <HousingComponent>id_housing_comp_1</HousingComponent>
                <ConnectorHousingRole id="id_conHousingRole_1">
                    <ConnectorHousingSpecification>id_connect_hous_spec_1</ConnectorHousingSpecification>
                    <SlotReference xsi:type="vec:SlotReference" id="id_slotRef_1">
                        <ReferencedSlot>id_slot_1</ReferencedSlot>
                        <CavityReference id="id_cavityRef_1">
                            <Identification>1</Identification>
                            <ReferencedCavity>id_cavity_1</ReferencedCavity>
                        </CavityReference>
                        [...]
                    </SlotReference>
                </ConnectorHousingRole>
                <PinComponentRef id="id_pin_comp_ref_1">
                    <PinComponent>id_pin_comp_1</PinComponent>
                    <TerminalRole xsi:type="vec:TerminalRole" id="id_terminalRole_1">
                        <Identification>1</Identification>
                        <TerminalSpecification>id_terminal_spec_1</TerminalSpecification>
                    </TerminalRole>
                </PinComponentRef>
                [...]
            </HousingComponentRef>
        </Role>
    </Component>
    <Component id="id_component_2">
        <Identification>Isolator</Identification>
        [...]
        <Role xsi:type="vec:EEComponentRole" id="id_ee_role_2">
            <Identification>Isolator</Identification>
            <EEComponentSpecification>id_ecomponent_spec_2</EEComponentSpecification>
            <HousingComponentRef id="id_housing_comp_ref_2">
                <Identification>A</Identification>
                <HousingComponent>id_housing_comp_2</HousingComponent>
                <ConnectorHousingRole id="id_conHousingRole_2">
                    <ConnectorHousingSpecification>id_connect_hous_spec_1</ConnectorHousingSpecification>
                    <SlotReference xsi:type="vec:SlotReference" id="id_slotRef_2">
                        <ReferencedSlot>id_slot_2</ReferencedSlot>
                        <CavityReference id="id_cavityRef_2">
                            <Identification>1</Identification>
                            <ReferencedCavity>id_cavity_2</ReferencedCavity>
                        </CavityReference>
                    </SlotReference>
                    [...]
                </ConnectorHousingRole>
                <PinComponentRef id="id_pin_comp_ref_2">
                    <PinComponent>id_pin_comp_2</PinComponent>
                    <TerminalRole xsi:type="vec:TerminalRole" id="id_terminalRole_2">
                        <Identification>1</Identification>
                        <TerminalSpecification>id_terminal_spec_2</TerminalSpecification>
                    </TerminalRole>
                </PinComponentRef>
            </HousingComponentRef>
            [...]
        </Role>
    </Component>
</Specification>
[...]
<Specification xsi:type="vec:CouplingSpecification" id="id_coupling_1">
    <CouplingPoint>
        <Identification>Battery-Isolator</Identification>
        <FirstConnector>id_conHousingRole_1</FirstConnector>
        <SecondConnector>id_conHousingRole_2</SecondConnector>
        <MatingPoint>
            <Identification>Mating-Battery-Isolator</Identification>
            <FirstTerminalRole>id_terminalRole_1</FirstTerminalRole>
            <SecondTerminalRole>id_terminalRole_2</SecondTerminalRole>
            <Connection>id_connection_1</Connection>
        </MatingPoint>
    </CouplingPoint>
</Specification>
[...]
<Specification xsi:type="vec:ConnectionSpecification" id="id_connect_spec_1">
    <Identification>ConSpec</Identification>
    <Connection id="id_connection_1">
        <Identification>PowerDistribution</Identification>
        <ConnectionEnd id="id_conn_end_1">
            <Identification>Battery</Identification>
            <ConnectedComponentPort>id_comp_port_1</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="id_conn_end_2">
            <Identification>Isolator</Identification>
            <ConnectedComponentPort>id_comp_port_2</ConnectedComponentPort>
        </ConnectionEnd>
    </Connection>
    [...]
</Specification>

Coupling Devices

In the context of the VEC, a coupling device is:

… the (virtual) device that separates / connects two or more wiring harnesses. “Virtual” because it can be interpreted as a device / interface definition between the harnesses, where one harness behaves like an E/E component form the point of view of the other harness¹.

That means, at a coupling device a larger electrical system is divided into multiple harnesses. There can be various reasons for such a division and depending on these reasons, coupling devices can be defined at different points in the development process. Often there are assembly requirements that make a subdivision necessary (e.g. between the door and main body). If an electrical connection is defined between those separate installation spaces, it crosses a coupling device and is split up at this point. Whether a connection crosses such a coupling device or not can often be only determined after the routing process in a concrete context of the packaging of a specific vehicle. Such coupling devices are often only relevant in a geometry / topology perspective and for the wiring of a specific harness and not in an architectural or system schematic layer.

However, there are also coupling devices that serve other purposes and therefore, must be defined early in the electrological branches of the development processes, i.e. in the architecture layer or the system schematic. A schematic diagram of such coupling device can be found in the figure above and will be example for the following sections.

Basic Concept

The basic idea for a mapping in the VEC for such coupling points between different harnesses is, to consider them as virtual E/E components with an internal connectivity. When looking at such a point on a real wiring harness, we will just see two or more connectors that are plugged into each other. However, the definition of a virtual component between these connectors in the product model creates multiple advantages:

• The representation in the system schematic is analogous to other E/E components. Traceability with the wiring layer can be achieved in a uniform way.
• When just looking at a single wiring harness, all connectors can be connected to an E/E component, no connectors are “hanging in thin air”.
• The virtual E/E component can be used as an interface contract and a point of separation between different development and process partners or even development lifecycles. For example, the wiring harness of a seat does not need to “know” everything about the complete electrical network of the vehicle. It just requires an interface definition of the E/E component “rest of the vehicle”.
• The virtual E/E component can be used to enforce standards for specific coupling points, for example a consistent pinning between the doors and the main body across multiple carlines.

System Schematic

The figure above illustrates minimal representation of a coupling device in the system schematic with just one connector and only one pin on each side. The coupling device itself is represented in the VEC with a ComponentNode with the ComponentNodeType ='CouplingDevice'. For each side of the coupling device it contains a ComponentConnector. These connectors include the ComponentPorts, which represent the pins of the connector.

The connectivity between the port on each side is represented with a internal Connection with two ConnectionEnds, which reference the connected ComponentPorts. The flag isExternalEnd of the Ends is set to false, because the connection represents the internal mapping of ports within the coupling device. Connections to other ComponentNodes would be represented by different Connections with ConnectionEnds where isExternal=true.

Document Structure

Like with any self-contained piece of information in the VEC, for traceability reasons the definition of a _coupling device should be in the correct DocumentVersion. Section General Structure explains the general concept of DocumentVersion and their containments. As described there, the containment of Specifications in their DocumentVersions has a semantic meaning. The correct placement of a coupling device in a containing DocumentVersion is a perfect example for that.

Depending on the engineering process, system schematic relevant coupling device might be defined in some kind of master data process, enforcing standardized coupling devices for a specific scope. In that case, one or more of those standardized coupling devices would be managed and published together, and then reused in a specific system schematic. This is illustrated in the figure “Information Structure” below, on the left side of the figure.

On the other, it would also be perfectly valid to have no company wide management process for coupling devices. In this case, the coupling devices would be defined implicitly within a system schematic. This is illustrated on the right side of the figure.

XML Example

The XML snippet below contains the portions of a coupling device definition that belong to the system schematic layer.

<DocumentVersion id="id_docu_ver_16475">
  <Description xsi:type="vec:LocalizedString" id="id_16476">
    <LanguageCode>De</LanguageCode>
    <Value>Definition der Trennstelle TQVL</Value>
  </Description>
  <DocumentNumber>TQVL</DocumentNumber>
  <DocumentVersion>1</DocumentVersion>
  <DocumentType>MasterDataDefinition</DocumentType>
  <DataFormat>VEC</DataFormat>
  <Specification xsi:type="vec:ConnectionSpecification" id="id_connect_spec_1">
    <Identification>ConSpec_TZY5-DV12a</Identification>
    <ComponentNode id="id_comp_node_6">
      <Identification>TQVL</Identification>
      <ComponentNodeType>CouplingDevice</ComponentNodeType>
      <RealizedUsageNode>[id ref to usage node]</RealizedUsageNode>
      <ComponentConnector id="id_component_connector_1">
        <Identification>TQVL.1A</Identification>
        <ComponentPort id="id_component_port_1">
          <Identification>1</Identification>
        </ComponentPort>
      </ComponentConnector>
      <ComponentConnector id="id_component_connector_2">
        <Identification>TQVL.2A</Identification>
        <ComponentPort id="id_component_port_2">
          <Identification>1</Identification>
        </ComponentPort>
      </ComponentConnector>
    </ComponentNode>
    <Connection id="id_connection_1">
      <Identification>TQVL.A1</Identification>
      <ConnectionEnd id="id_conn_end_1">
        <Identification>TQVL.A.1</Identification>
        <IsExternalEnd>false</IsExternalEnd>
        <ConnectedComponentPort>id_component_port_1</ConnectedComponentPort>
      </ConnectionEnd>
        <ConnectionEnd id="id_conn_end_2">
        <Identification>TQVL.A.2</Identification>
        <IsExternalEnd>false</IsExternalEnd>
        <ConnectedComponentPort>id_component_port_2</ConnectedComponentPort>
      </ConnectionEnd>
    </Connection>
  </Specification>
</DocumentVersion>

Wiring

Traceability

Even without having an explicit coupling device definition (with a virtual E/E component) in the wiring layer, a traceability over a coupling device from one wiring harness to another is possible with the help of the system schematic layer.

Taking the ComponentNode Definition from above as a foundation, it is only necessary to create the traceability relations from the harness connectors to the system schematic layer, as illustrated in the figure below.

Below is the corresponding XML snippet.

<Component id="component_1">
  <Identification>TQVL.1A1</Identification>
  <Role xsi:type="vec:ConnectorHousingRole" id="connectorHousingRole_1">
    <Identification>TQVL.1A1</Identification>
    <ConnectorHousingSpecification>connectorHousingSpecification_1</ConnectorHousingSpecification>
    <ConnectedComponentConnector>id_component_connector_1</ConnectedComponentConnector>
    <SlotReference xsi:type="vec:SlotReference" id="slotRef_1">
      <Identification>A</Identification>
      <ReferencedSlot>slot_1</ReferencedSlot>
      <CavityReference id="cavityRef_1">
        <Identification>1</Identification>
        <ReferencedCavity>cavity_1</ReferencedCavity>
      </CavityReference>
    </SlotReference>
  </Role>
  [...]
</Component>
<Component id="component_2">
  <Identification>TQVL.2A1</Identification>
  <Role xsi:type="vec:ConnectorHousingRole" id="connectorHousingRole_2">
    <Identification>TQVL.2A1</Identification>
    <ConnectorHousingSpecification>connectorHousingSpecification_2</ConnectorHousingSpecification>
    <ConnectedComponentConnector>id_component_connector_2</ConnectedComponentConnector>
    <SlotReference xsi:type="vec:SlotReference" id="slotRef_2">
      <Identification>A</Identification>
      <ReferencedSlot>slot_2</ReferencedSlot>
      <CavityReference id="cavityRef_2">
        <Identification>1</Identification>
        <ReferencedCavity>cavity_2</ReferencedCavity>
        <ConnectedComponentPort>id_component_port_2</ConnectedComponentPort>
      </CavityReference>
    </SlotReference>
  </Role>
  [...]
</Component>
<Component id="component_3">
  <Identification>TQVL.2A2</Identification>
  <Role xsi:type="vec:ConnectorHousingRole" id="connectorHousingRole_3">
    <Identification>TQVL.2A2</Identification>
    <ConnectorHousingSpecification>connectorHousingSpecification_2</ConnectorHousingSpecification>
    <ConnectedComponentConnector>id_component_connector_2</ConnectedComponentConnector>
    <SlotReference xsi:type="vec:SlotReference" id="slotRef_3">
      <Identification>A</Identification>
      <ReferencedSlot>slot_2</ReferencedSlot>
      <CavityReference id="cavityRef_3">
        <Identification>1</Identification>
        <ReferencedCavity>cavity_2</ReferencedCavity>
      </CavityReference>
    </SlotReference>
  </Role>
  [...]
</Component>

Fuses

A single fuse is a two-terminal component that can be plugged or screwed into a compatible fuse slot. There are different types, which differ in their geometry, the type of connection, the tripping characteristics and their rated voltage.

In VEC a fuse is handled as a EE-Component and that is why the FuseSpecification extends the EEComponentSpecification and describes it’s the available connector interface also with a HousingComponent and - in this case - with two PinComponents. The FuseSpecification defines the typical component attributes, i.e. the maximum electric current information for the fuse.

In addition to that the geometrical structure is described by a ConnectorHousingSpecification with it’s Slots and their Cavities (Cavity ). The PinComponents can be described in a more detailed way by usage of the PinComponentBehavior. Special information about the signal, signal direction or voltage can be placed here.

The PinComponent can reference a TerminalSpecification to define the physical properties of the pin. To avoid the confusion by too many crossing lines, the connection t the TermnalSpecification is not explicitly drawn in the diagram above.

Instantiating fuses

Instantiating fuses is like instantiating any other EE-Component. A EEComponentRole under a PartOccurrence references the FuseSpecification and all structure elements underneath will be instantiated and references their corresponding part master element, too. For more information see E/E-Components.

Multi Fuses

A mutlifuse is a special type of fuse that combines multiple fuses in a single component (see Multi Fuse Illustration). In contrast to a regular fuse, where there are only two interchangeable pins, the multi fuse has a single dedicated supplying pin and multiple protected pins.

An individual fuse component is located between each protected pin and the supplying pin. Each fuse component can have its own technical properties (e.g. max current).

As shown in figure Specification Multi Fuse a multi fuse is represented in the VEC by a MultiFuseSpecification, which is a specialization of the EEComponentSpecification. Therefore all aspects described in the general section potentially apply to multi fuses as well. This sample describes only the aspects that are specific for multi fuses.

In the VEC, a multi fuse has one HousingComponent with a PinComponent for each pin. Each integrated fuse in the multifuse is represented by a FuseComponent. The fuse component references the pin components that are connected through it and specifies the properties for this (e.g. iMax) through a FuseSpecification.

The geometrical shape of the multi fuse is defined by a ConnectorHousingSpecification with Slot and Cavity. The cavities are referenced by the pin components.

<Specification id="id_2000_0" xsi:type"vec:MultiFuseSpecification">
	<Identification>MF-3x100</Identification>
	<DescribedPart>id_1001_0</DescribedPart>
	<HousingComponent id="id_2023_0">
		<Identification>Hco-MF-3x100</Identification>
		<HousingSpecification>id_2000_1</HousingSpecification>
		<PinComponent id="id_2024_0">
			<Identification>V</Identification>
			<Description id="id_1003_1" xsi:type"vec:LocalizedString">
				<LanguageCode>De</LanguageCode>
				<Value>Versorgung</Value>
			</Description>
			<ReferencedCavity>id_2020_3</ReferencedCavity>
		</PinComponent>
		<PinComponent id="id_2024_1">
			<Identification>1A</Identification>
			<ReferencedCavity>id_2020_0</ReferencedCavity>
		</PinComponent>
		<PinComponent id="id_2024_2">
			<Identification>2A</Identification>
			<ReferencedCavity>id_2020_1</ReferencedCavity>
		</PinComponent>
		<PinComponent id="id_2024_3">
			<Identification>3A</Identification>
			<ReferencedCavity>id_2020_2</ReferencedCavity>
		</PinComponent>
	</HousingComponent>
	<IMaxTotal id="id_2080_0">
		<UnitComponent>id_1005_0</UnitComponent>
		<ValueComponent>300.0</ValueComponent>
	</IMaxTotal>
	<FuseComponents id="id_2046_0">
		<Identification>F1</Identification>
		<ConnectedPins>id_2024_0 id_2024_1</ConnectedPins>
		<FuseSpecification>id_2000_3</FuseSpecification>
	</FuseComponents>
	<FuseComponents id="id_2046_1">
		<Identification>F2</Identification>
		<ConnectedPins>id_2024_0 id_2024_2</ConnectedPins>
		<FuseSpecification>id_2000_3</FuseSpecification>
	</FuseComponents>
	<FuseComponents id="id_2046_2">
		<Identification>F3</Identification>
		<ConnectedPins>id_2024_0 id_2024_3</ConnectedPins>
		<FuseSpecification>id_2000_3</FuseSpecification>
	</FuseComponents>
</Specification>

Relays

A relay is a component for switching current loads. Unlike fuses, there are more than one input pin and one output pin (number of pins >3). Some components, referred to as relays, are in reality small controllers with up to 17 pins.

In the VEC schema a relay is a special type of an EE-Component. It also owns a HousingComponent with it’s PinComponents underneath where these HousingComponent can be defined more detailed with a ConnectorHousingSpecification and the PinComponents with a referenced TerminalSpecification. Also the InternalComponentConnection for (potentially) connected pins are defined.

Additionally to these standard EE-Component structure the RelaySpecification also can contain so called SwitchingStates. Each state describes an InternalComponentConnection as potentially existing, depending on the current switched state of the relay. In the example above the blue colored PinComponents describe the coi contact. The connection between the two pins 30 and 87 is permanently The green colored part describes the switch, whose connection can exist depending on the SwitchingState. So the InternalComponentConnection between the pins 85 and 86 is not permanently guaranteed.

For more information see Switching States.

Instantiating relays

Instantiating relays is like instantiating any other EE-Component. A EEComponentRole under a PartOccurrence references the RelaySpecification and all structure elements underneath will be instantiated and references their corresponding part master element, too. For more information see chapter E/E-Components.

Component Boxes

Note: The following sections will cover the technical background about component boxes. The term “component box” will be used as a general term for all types of fuse and/or relay carrier, power distribution box etc. The detailed mapping of the different aspects on concepts of the VEC will be in EE-Components, as the concepts are the same for regular E/E components and component boxes.

Overview

The image on the right side shows a photo of the front side of a component box. The drawing shows a drawing of a component box. In general, a component box is a component (carrier) that can be equipped with other components (e.g. relays & fuses) and by this, provides fusing and switching functionality to the attached wiring harness.

Basically a component box can be divided into four aspects:

1. Slots to plug-in E/E components like fuses and relays.
2. Connectivity with the wiring harness.
3. Internal connectivity.
4. Modularity

For all of these aspects, different technical solutions and variants exist. In reality, a specific component box can virtually combine and mix up all of these solution variants. To create a concise representation of a component box in the VEC model, a combination of different concepts is necessary. Some of these concepts are not exclusively for component boxes.

Plugability of E/E components

As mentioned before, a component box provides slots to plug-in other E/E-components. The following sections give brief overview of the most relevant types.

Fuse

A fuse is a component with two pins that can be plugged or screwed into a compatible fuse slot. There exists a wide range of different types that have individual triggering characteristics and currents, geometries, connection types etc.

Multifuse

A multi fuse is similar to a regular fuse. However, due to cost and packaging reasons multiple fuses are combined into a single component. The individual fuses share the power supply, see the multi fuse example.

Relais

A Relais is a component used for switching of loads and has more than 3 pins.

Direct and Indirect Contacting

There are two different ways to create an electrical connection between the end of a wire and a corresponding fuse or relays, direct and indirect contacting. In case of direct contacting (see direct contacting) a terminal directly attached to the wire is locked into a cavity on ones side of the component box. The cavity goes through the component box and the pins of the fuse are directly plugged into the reception of the wire terminal. In this case, the component box itself does not provide a electrical conductivity.

In case of indirect contacting the component box contains a conductor (e.g. a conductor rail) that connects multiple cavities of the component box, see #3, #4, #7 and #9 in the component box drawing. The pins of the fuse are plugged into receptions of the conductor rail. Same applies for the connection to the harness. The wire terminals are grouped together into a harness connector, which is then attached to the component box. The conductor rail is often used for implementing the power distribution on the input side of a component box. In this case, the connection to the wiring harness is often done with ring terminals attached to bolts of the component box, see #8, #13, #14 and #16 in the component box drawing.

A combination of both in one component box is possible (and likely), e.g. the supplying side is realized with a conductor rail (indirect contacting) and the protected side is realized with direct contacting.

Connectivity with the Wiring Harness

In case of direct contacting the component box itself serves as end point for the wires. Therefore the last topology segment is attached to the component box. The component box requires / provides segment connection points. From an abstract point of view and out of the perspective of the wiring harness, a component box with direct contacting behaves just like a regular harness connector, see the schematic illustration (3).

In case of indirect contacting the wires and terminals are clipped into a regular harness connector and the connector is plugged into the component box. So, again from an abstract point of view and out of the perspective of the wiring harness, the component box with indirect contacting and a harness connector behaves just like a regular E/E-Component (e.g. an ECU, an actor or a sensor), see the schematic illustration (4) & (5).

Another variant in case of indirect contacting is the usage of ring terminals. The component box provides a bolt and a wire is attached to it with a ring terminal. In this case the component box behaves like a battery or a ground bolt, see the schematic illustration (6) .

Internal Connectivity

For the calculation of current paths or electrical testing, a component box needs to define an internal connectivity, see the schematic illustration (2). This is a logical connectivity and it is irrelevant, if it is realized with direct or indirect contacting.

Modularity

Some component boxes support modular concepts, e.g. the one shown in the photo. That means the component box can be extended with additional carriers, sockets or smaller component boxes (in a LEGO like way). There are two concepts for modularity: with or without electrical connectivity. If you compare the photo on top with the photo on the right you can see, that the relays socket in the lower left corner is mechanically clipped to main component box, electrically it is independent.

In contrast to this, the orange fuse socket right beside the relay socket has its upper part plugged into the main component box, with electric connectivity for power supply. The lower part of it provides an independent cavity for direct contacting of the protected side.

Placements and Dimensions

A Placement defines the way how a component is associated to the topology. The following sections contain examples about the different types of placements.

Simple WireProtection

This diagram illustrates the placement of a simple WireProtection as shown in next diagram.

The Figure above displays the placement of a simple wire protection. The PartOccurrence is placed with an OnWayPlacement via a PlaceableElementRole. This means the placed component covers a linear area of the harness topology. The start and the end of this area is defined with two Locations. In the shown situation the StartLocation is a SegmentLocation, which means the start is somewhere in the middle of a TopologySegment. It is defined to be at 120mm measured from the EndNode of the TopologySegment. The EndLocation of the WireProtection is located on a TopologyNode with a NodeLocation. It is not valid to define Locations with SegmentLocation, which could be also expressed by NodeLocations. This means for SegmentLocations an offset of 0 or equal to the segment length is illegal.

Since the offset is NumericalValue it can have an optional Tolerance.

WireProtection with Dimension

This diagram shows the previous example extended with a Dimension. In the previous example, the beginning of the WireProtection was defined with a tolerance value. This method is applied, if the tolerance is applied to the next TopologyNode (Start- or End-Node of the segment).

In many cases, tolerances are defined relative to specific points (e.g. points that can be measured) somewhere in the topology. In these cases a Dimension is used to defined the tolerance.

The placement of the WireProtection is just the same as in the previous example. It is extended with the Dimension (highlighted in green). The Dimension defines the tolerance of +/- 20mm between the TopologyNode ND-III and the beginning of the WireProtection.

The fact, that the Dimension is specified between the TopologyNode and the beginning of the WireProtection is expressed, that the TopologyNode is referenced directly (with a NodeLocation contained by the Dimension). The SegmentLocation used as DimensionAnchor is the same as used for the placement of the WireProtection.

The valueCalculated=true flag of the Dimension indicates that the valueComponent (220mm) is a derived an calculated value and not a user defined value. This value can be obtained from the placement information and the lengths of the TopologySegment.

Fixing Placement

This diagram illustrates a more complex placement situation, including the usage of dimension.

The illustration shows a bracket, that is placed independently on two Segments (SEG-1 & SEG-2). The two points where the bracket is placed on the TopologySegments are identified separately (PlacementPointReference A & B). Additionally a Dimension is added, which gives a Tolerance between a geometric point (e.g. a bolt) on the bracket (MeasurementPointReference C) and a Node (ND-1) in the Topology (see TopologyNode).

The diagram illustrates the instantiation of the example in the preceding diagram. Since the PartOccurrence can be placed in the topology, it has a PlaceableElementRole (with a corresponding PlaceableElementSpecification not shown in the diagram). The points where it can be placed onto the topology are represented by the PlacementPointReferences A & B. The point which can be used as anchor for a dimension (which can be any reference point on the component), is represented by the MeasurementPointReference C.

The actual placement is done with an OnPointPlacement which has two SegmentLocations. One for each PlacementPointReference.

Large Area WireProtections

In some cases it is necessary to place a wire protection over a greater area of the topology, consisting of more than one TopologySegment (e.g. Tubes with a fixed length). For these cases the OnWayPlacement defines two locations for the start and the end and a path along which the wire protection is placed. The path is an ordered list of the segments from the start to the end. If a SegmentLocation is used for the start or the end the path must contain these segments as well.

For each TopologySegment the use of Start- and End-Node has no semantik relevance. The names are just used to make it possible to identify the corresponding TopologyNodes correctly e.g. when defining the anchor for a SegmentLocation.

Fixed Components (Single Location)

Fixed components are elements that are placed on a certain point in the topology, such as Connectors, Fixings and so on. These components are placed with an OnPointPlacement as shown in the example. If the Component has to be placed on a Node (e.g. a Connector) a NodeLocation is used. If the Component has to be placed on a Segment a SegmentLocation is used. The usage and constraints for the Locations are the same like the ones for OnWayPlacements.

Fixed Components (Multiple Locations)

Some components, for example channels or a large connector with more than one segment connection point, may be placed on multiple positions in the Topology. For example a channel can have two or more reference points (e.g. the outlets) that must be associated to the different positions topology. In these cases an OnPointPlacement with more than one location is used. In order to identify which location places which point of the component (e.g. the outlets), a PlaceableElementRole can define PlacementPointReferences which are creating a relationship to the component description.

Default Dimensions

The diagram illustrates the use of a DefaultDimensionSpecification. The DefaultDimensionSpecification can be used to specify default dimensions / tolerances for certain attributes and ValueRanges. In this examples the Specification is used for the length of wires. (indicated by the dimensionType). The dimensionValueRange defines for which value’s of this type, the referenced Tolerance is applicable.

In this example for a wire length lower than 250 mm a Tolerance of +5 mm is allowed, for values between 250 mm and 500 mm a Tolerance of +10 mm is allowed and for everything above 500 mm a Tolerance of 15 mm is allowed.

VEC Package

This example explains how more than one VEC file can be packaged together with external documents, for example symbols of the specified components. In this case the VEC shall be packed within an archive together with the external documents (according to the current published VEC recommendation) and an index file has to be provided.

The upper half of the diagram illustrates the file structure within the archive. In the root there is a ‘index.vec’ file that describes the content of the archive. The simplified content of this index file is illustrated in the lower half of the diagram.

For the example, the archive consists of following files:

• index.vec: Describes the content of the archive.
• A harness with the part number 4811 specified by a VEC-File (4811_a.vec) and a 2D SVG representation of the harness (4811_a.svg).
• A component description of connector housing (part number: 4711) specified with a VEC-File (4711_a.vec) and component symbol (to be used in the 2D-drawing) defined with a SVG-Symbol (4711_a.svg).

In the VEC (especially in the index.vec) a DocumentVersion object is created for each external document (see lower half of the diagram). This DocumentVersion object references the PartVersion to which it is related. Beside all meta information about the document, the attribute dataFormat of the DocumentVersion specifies the format of the external document as a MIME-Type. The attribute fileName is a path relative to VEC-File pointing to the external document in the archive

External Installation Instructions

The usage of file-based installation instructions is quite similar to the described approach for external documents. The FileBasedInstruction defines a pointer to the file packaged together with the VEC-file in the container and is referenced by the PartOccurrence.

The same effect could be achieved if a DocumentBasedInstruction is used, pointing to an external document (defined as described in the section before).

Important: The difference between the two approaches is that for the DocumentBasedInstruction a DocumentVersion is required. This means that the external file must be an official document with a document number, an appropriate versioning and so on. The FileBasedInstruction can point to any file needed. It is not a valid approach to use the FileBasedInstruction, if the external file is a valid document.

External Mapping

Simple External Mapping

The Diagram shows a simple example for the usage of the external mapping mechanism. The elements highlighted in yellow represent the actual information described by this VEC instance. The elements highlighted in blue are defining the concrete mapping and the DocumentVersion highlighted in green represents the link to the mapped document (in this case a SVG-symbol).

The ExternalMapping element in this example defines that a representation of the referenced ConnectorHousingSpecification can be found in the SVG-symbol under the key “ID_27101123”.

The actual content data of the VEC-file (highlighted in yellow) and the mapping information is separated into two different DocumentVersion elements. This means even though both information are contained in the same VEC-file, from the perspective of a versioning mechanism they are clearly separated.