XML / XSD Representation

Mapping of UML VEC Model to XML Schema Definition (XSD)

The mapping of the VEC model to an XML schema definition (XSD) described in the following defines the standardized syntax for the exchange of harness design data across process steps and supporting tools. The dedicated namespace prefix of the schema definition is vec, the namespace is http://www.prostep.org/ecad-if/2011/vec.

The XSD defines a single VecContent-element as xs:element. This is the declared root element for all VEC compliant XML-documents. A VEC compliant XML-document is limited to one instance of a VecContent.

Classes

Each VEC UML model class (see figure below for an example from the VEC), which is not stereotyped as <<enumeration>>, are mapped in the following form.

1. Each regular UML class is mapped to a xs:complexType with the same name as the VEC model class name.
2. If the VEC model class is a derived subclass the corresponding xs:complexType defines a xs:extension.
3. VEC model class attributes & associations which are defined by the class itself and not inherited, are mapped to a xs:sequence of xs:elements with the same names as the names of the corresponding class attributes (see Attributes and Associations below).

 <xs:complexType name="DocumentVersion">
      <xs:complexContent>
         <xs:extension base="vec:ItemVersion">
            <xs:sequence>
               <xs:element name="DocumentNumber" type="xs:string"/>
               <xs:element name="DocumentType" type="vec:DocumentType" minOccurs="0"/>
               ...
               <xs:element name="DocumentClassification"
                           type="vec:DocumentClassification"
                           minOccurs="0"
                           maxOccurs="unbounded"/>
               <xs:element name="ReferencedPart" type="xs:IDREFS" minOccurs="0"/>
               ...
            </xs:sequence>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>

Identifiers

id-Attributes

All xs:complexType that are not a refinement of another type (via xs:extension) define a mandatory XML attribute id with the type xs:ID. Syntax restrictions and uniqueness constraints for xs:ID are defined by the XML standard itself. xs:ID values are required to be unique within a XML document. Assocations between objects within a VEC XML document are defined with the help of xs:IDREF(S). The values in a xs:IDREF(S) must be defined xs:ID values existing in the context of the document.

The values for the id-attributes are normally generated by exporter / XML processor during the XML file generation. Exporters are expected to generate valid values for the id-attributes so that Links (instances of associations) are expressed correctly and the resulting XML file is XSD compliant.

   <xs:complexType name="ExtendableElement" abstract="true">
      <xs:sequence>
      ...
      </xs:sequence>
      <xs:attribute name="id" type="xs:ID" use="required"/>
      <xs:attribute name="immutable-global-iri" type="xs:anyURI"/>
   </xs:complexType>

immutable-global-id-Attributes

As defined in the section above, each xs:complexType defines a XML-Attribute id with the type xs:ID, either by itself or by inheritance from a superclass. By nature, those ids are volatile and have a purpose only within a specific XML file.

However, there are requirements in advanced use cases where it is necessary to be able to identify objects in the VEC globally and in a temporally stable manner. Such use cases are for example, but not limited to:

• Change Management & Synchronization
• Integration with other Standards, e.g. the Asset Administration Shell (AAS)
• Provision of VEC objects via modular APIs (e.g. REST)
• Compliance with other serialization formats like RDF.

Therefore, each xs:complexType that defines an id-attribute also defines an immutable-global-iri attribute with the type xs:anyURI. Despite its name xs:anyURI is in fact the type for an Internationalized Resource Identifier (IRI), see “W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes”.

If two VEC objects, regardless of their context or their affiliation to a specific file, have the same immutable-global-iri, they are in fact a representation of the same (real world) object (potentially in a different state). The concept of IRIs allows the definition of global unique identifiers in various ways and with different strategies. For example, using http-IRIs allows the dereferencing (finding) of objects identified by such IRIs. However, the chosen strategy has a strong influence on the circumstances under which two objects in the VEC can be identified as the same. Both effects (same & not the same) can be desired effects in a specific use case / process / scenario. Therefore, this recommendation does not define a specific strategy for minting IRIs for VEC objects. It is also beyond the scope of this recommendation to describe or define valid strategies for minting IRIs.

However, two examples shall illustrate the influence of a choosen strategy. The examples are for illustrative purposes only and their description does not claim to be complete:

• UUIDs: IRIs can be created from UUIDs. UUIDs are generated random values that guarantee universal uniqueness. To satisfy the requirement of temporal stability, a source system has to maintain (store) those UUIDs for every object. Objects that are created and distributed at the same time in different locations are hard to handle. Objects deleted from the system (and then recreated) are always handled as different objects.
• Calculated IDs: IDs could be calculated from object keys in the domain (e.g. the identifying attributes of a PartVersion). Such IDs could be calculated on the fly and do not have the requirement to be stored along with the object, as they are stored implicitly via the attributes from which they are derived. If the same object (same identifying attributes) is created in different locations, both variants can still be recognized as identical. On the downside, an ID generation algorithm has to be defined, that generates those unique IDs for every possible object type and situation. The algorithm has to guarantee that the generated IDs fulfill uniqueness requirement, which depends on the naming / identification strategy of the process. And yet, there are still cases where objects can not be recognized as the same (e.g. renaming of “key”-attributes).

Attributes & Associations

In the XML Schema represention of the VEC, attributes and compositions are handled in the same way. The containing (or orginating) class defines a xs:element. The name-attribute of the xs:elementis equivalent to the name of the attribute or the target role in the UML model. The first letter is converted to upper case. The type of the xs:element is either a primitive type (see mapping below) or a reference to corresponding VEC schema type.

All associations in the VEC model are directed and therefore have a defined source and target. An association is mapped to an xs:element which is owned by the XSD complex type that represents VEC model class that is source of the association. The name of the element is equal to the name of the association target role name (first letter upper case). The type is xs:IDREF respectively xs:IDREFS depending on the associations target cardinality.

Primitives

The UML uses sereval primitive data types that are mapped to the correspondig XSD data types:

• xs:string (corresponding to the VEC model data type definition String)
• xs:dateTime (corresponding to the VEC model data type definition Date)
• xs:integer (corresponding to the VEC model data type definition Integer)
• xs:double (corresponding to the VEC model data type definition Double)
• xs:boolean (corresponding to the VEC model data type definition Boolean)

Meta Model annotations embedded in XML Schema

Due to the nature of XML Schema and XML files it is not possible to express all specifications, restrictions and additional information of the VEC model (defined as UML model) directly in XML Schema. In particular, these are:

• Target types for IDREF / IDREFS associations,
• Uniqueness of collections (bag vs. set semantics),
• Ordering of collections,
• Assignment of model elements to packages / namespaces in the model, and
• Deprecation of model elements.

To overcome this gap, additional meta information, embedded in the XML Schema will be provided for future versions (Version > 2.0.1). The extension is done with the annotation concept provided by XSD (xs:annotation / xs:appinfo see W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures / 3.15.1 The Annotation Schema Component).

The XSD schema for the content of the xs:appinfo can be downloaded here:

model-meta-1.0.0.xsd . The XML target namespace of the meta information is: http://www.prostep.org/ecad-if/2022/model-meta .

Package

All types defined in the VEC are associated with a namespace, e.g. core, electrical_parts, schematic. This meta information is defined as follows:

    <xs:element name="package" type="meta:Package"/>

    <xs:complexType name="Package">
        <xs:attribute name="name" type="xs:string"/>
    </xs:complexType>        

Deprecation

In case a model element (class, attribute, association, enumeration, literal etc.) gets deprecated, it will be annotated with deprecated along with further information about the reason for deprecation and the VEC version since when the deprecation is in place. Normally deprecated elements will be removed with the next major release.

    <xs:element name="deprecated" type="meta:Deprecation"/>

    <xs:complexType name="Deprecation">
        <xs:attribute name="reason" type="xs:string"/>
        <xs:attribute name="since" type="xs:string"/>
    </xs:complexType>

Collections

Meta information for associations / collections is defined as follows:

    ...
    <xs:element name="relationship" type="meta:Relationship" />
    
    <xs:simpleType name="RelationshipType">
        <xs:restriction base="xs:string">
            <xs:enumeration value="Attribute" />
            <xs:enumeration value="Association" />
            <xs:enumeration value="Composition" />
        </xs:restriction>
    </xs:simpleType>


    <xs:complexType name="Relationship">
        <xs:attribute name="element-type" type="xs:QName"/>
        <xs:attribute name="relationship-type" type="meta:RelationshipType" use="required"/>
        <xs:attribute name="unique" type="xs:boolean" default="true"/>
        <xs:attribute name="ordered" type="xs:boolean" default="false"/>
    </xs:complexType>
    ...

All elements in the model that are defined as an association, with or without composition, and all attributes receive a relationship annotation. Regarding the XML Schema alone, attributes and composite associations have a similar XSD definition. However, the modelling approach in VEC was chosen intentionally and there are subtle differences in semantics in the context of the specification.

The attribute representation is used for primitive types and structured value types (e.g. NumericalValue, Material or Color). Those elements do not have complex substructures and do not have incoming associations. On the other hand, composite associations are used for more complex substructures and elements that are relevant in a larger context (e.g. Slot, Cavity or WireElement).

• element-type: The schema type of elements referenced by the association as defined in the UML model, to preserve type info for IDREF(S), which will be lost otherwise in native XML schema. Only allowed on IDREF(S) elements.
• relationship-type: The type of the relationship as defined in the UML model.
• unique: Defines the collection semantics for elements referencing more than one element. unique=false means that the model allows duplication for this reference. In other words, the same object can be referenced multiple times (bag semantics). unique=true applies when an element should only be referenced once (set semantics). Composite associations can only be unique=true.
• ordered: Defines that the order of the collection has a semantic meaning and is not just given, because XML is an ordered format by definition.

The attributes of the relationship element are only present if the attribute has a reasonable, non-redundant meaning in the context. ordered or unique for a 0..1 association has questionable value, unique for composites can only be true and element-type is only relevant for IDREF(S) associations, because for composites the information is already contained in the regular schema definition.

Tailoring Concepts

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 XML representation of 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 XML 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 defined syntactically in the schema. 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 have 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 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. 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']]" />
    ...

Files, Partitioning, Sizing & Packaging (XML)

VEC XML Files

In general, XML data is structured in individual units of information, kown as documents. These documents can be transmitted through various machanisms, such as Web Services, enabling seamless exchange between systems. Alternatively, they can be stored within a file system for persistent storage or later retrieval.

This guideline gives best practices for the Partitioning and Sizing of such documents and explains how set of files can be exchanged together as a consistent archive (VEC-Package)

Partitioning and Sizing

In theory it is possible to export all data of a company that relates to the vehicle network in a single VEC XML file. However, this is not a very reasonable approach for several reasons. Amongst those are:

• Intellectual Property Protection: For everything that is contained in a single VEC file, the “All or Nothing Principle” applies and it is hard or impossible to enforce a “Need to Know”. A recipient of a file, who requires only a single detail, always receives the complete information.
• Partial Changes: Even if only a single content element is changed, the complete file must be created and read, because only after reading the complete file the recipient knows which elements have changed.
• Tool Support: Tools must support large areas of the VEC in their Import- / Export interfaces, even if the areas do not belong to their use case.
• Technical Feasibility: If all information is contained in a single VEC file, the file itself can become huge, which places new requirements on the creating and reading tools (e.g. required memory).

Therefore, the general recommendation is to make a VEC files as small as possible and as large as necessary. The correct scoping of a generated VEC file depends on the use case of the information and the intended interface. Scoping means in this context the process of defining which information shall be bundled together in a single file for data exchange.

The following paragraphs contain guidelines for the decision, whether some information shall be packaged together or not:

1. If the elements specified with the VEC are described, published and changed independently from each other regarding time and content, then they shall be placed in separate files (unit of publication). For example, this is the case for the description of harness components (connectors, wires etc.), represented by a part number. This rule applies only for the publication as master information from the original source of information. If the information is used to create other information, it can be embedded in a single file. For example, the description (complete or partial) of the used harness components will be embedded in the VEC describing a harness.
2. If elements specified with the VEC have no relationships between each other (except reference base on PartVersions and DocumentVersions), then they shall be placed in separate files. For example, the specifications of a connector housing and a wire have no reference.
3. If the relationship between two elements is indirectly over shared information, then this is no reason for the elements themselves to be placed in a single file (e.g. two connectors share the same CavitySpecification or two wires share the same CoreSpecification). If this piece of shared information is defined centrally, then it would have its own unit of publication, probably in its own DocumentVersion. In this case rule #1 can be applied. This means that, if the specification (e.g. a CoreSpecification) shall be exchanged, it shall be placed in its own VEC file. If the specification is used to describe another element (e.g. a wire) it shall be embedded in the VEC file of the described element. However, this is no reason to place all elements using this information in the same VEC file.

VEC Package

Background

A Vehicle Electric Container (VEC) in XML representation is a single XML file, following the structure defined in the VEC XML schema. It contains information about a harness, a set of harnesses, or other related information defined in the VEC specification. A VEC model can reference other documents via the DocumentVersion element and information contained in other files via the different “External References” concepts.

There are also good reasons for distributing information between multiple VEC files (see above Partitioning and Sizing of a VEC XML File)

However, there are use cases where one wants to exchange a VEC together with its external files and/or together with a set of somehow related VEC files. One use case for this is, for example, the exchange of a part master data library. The concept to do this, in the context of the VEC is called VEC-Package specifies how to exchange VEC files and any associated files as a single package.

Solution

A VEC-Package is an archive containing two things:

• One index file: index.vec (a VEC file)
• At least one data file (not required to be a VEC file)

The archive bundles all files together in a single file for exchange. Depending on individual technical requirements and preferences ZIP or GZIP can be used as archive formats. The compressed file can either contain the folder structure and content files of the VEC-Package directly (in case of ZIP), or it can contain a tar archive (in case of GZIP), with the folder structure and content files.

In addition, the archive can contain any number of addditional data files. There is no restriction on the type or format of these files. A VEC-Package may contain multiple VEC files and /or it may contain, for example drawings as SVG, CAD models of the harness or components as JT models.

The structure of the archive is not restricted. A VEC-Package may contain a flat set of files, but may also have a folder structure. It is recommended to use a folder structure to organize the files in the archive: e.g. to apply a grouping of all drawings or project related groupings.

There is no naming convention for files and folders inside the VEC-Package defined. It is up to the user to name a folder or a file. However, it is recommended to use the known and established file name extensions for the files in the package. I.e., .vec for a VEC file, .svg for a SVG file, or .jt for a JT file.

A VEC-Package shall contain an index file providing further information about the context of the package. The index file has the reserved name index.vec and it must be a valid VEC file, conforming to the VEC XML schema.

The elements of the index VEC file are restricted to the classes DocumentVersion and PartVersion. The index file contains a DocumentVersion for each file in the package. The attributes of the DocumentVersion are used to provide further information on the files:

• dataFormat: the format of the file in the VEC-Package (as Media Type if available).
• documentNumber: the number of the document
• documentVersion: the version of the document
• fileName: the name of the file as it appears in the package, including the folder structure. It must not point to any file location which is not part of the VEC-Package (e.g. a File on a central server file share). The fileName is relative to the VEC-Package root. It MUST NOT contain a drive or device letter, or a leading slash. All slashes MUST be forward slashes / (UNIX-style).

A DocumentVersion may reference one or more PartVersion objects via referencedPart to give further details on the usage of the file. For example, the fact, that an SVG file which represents the wiring diagram of a harness, can be expressed in the index file by a DocumentVersion pointing to a PartVersion, which represents the harness.

The figure above illustrates the structure of such a VEC-Package and the corresponding index.vec. The upper half of the diagram illustrates the file structure within the archive. In the root of the archive is the mandatory index.vec file that describes the content of the package. The content of index.vec is illustrated in the lower half of the diagram.

In the the example, the package consists of the following files:

• index.vec: Describes the content of the package.
• Information about a harness with the part number 4811 specified by:
  • drawings/4811_a.vec: A VEC file, containing the definition of the harness.
  • drawings/4811_a.svg: A 2D SVG representation of the harness.
• Information about a connector housing (part number: 4711) specified by:
  • components/4711_a.vec: A VEC file containing the part master data of the connector.
  • components/4711_a.svg: A component symbol (to be used in the 2D-drawing) defined in 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.

RDF / OWL Representation

Various initiatives in the recent past have shown an increase in the importance of semantic models and the use of ontologies in industry (e.g. Catena-X). For this reason, and due to the opportunities and potential of this technology, it has been decided to also publish the VEC as an ontology in the future (starting in 2024). This should facilitate the creation of VEC-based solutions in the area of the Semantic Web / Linked Data / Knowledge Graphs and enable a simple transition between the different worlds.

The RDF variant of the VEC is intended as an additional technical representation of the underlying UML model, in addition to the XML schema variant that has existed since the beginning. This is not a replacement or discontinuation of the previous approach, but rather an extension of the toolbox for application scenarios in which the more monolithic representation as an XML structure appears less suitable (e.g. distributed development in dataspace / cloud architectures). Nevertheless, the XML variant will retain its raison d’être in the future for use cases in which a compact and complete representation is required (e.g. archiving or passing on defined development statuses).

Like the XML schema, the ontology and the associated SHACL schema are derived automatically and directly from the UML model of the VEC. This means that the model, the XML schema and the ontology should be consistent with each other at all times for a specific VEC version.

RDF Snippets

The following sections contain snippets of the transformation results. All excerpts are defined in RDF Turtle. The following namespace definitions are used:

@prefix :     <http://www.prostep.org/ontologies/ecad/2024/03/vec#> .
@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vec:  <http://www.prostep.org/ontologies/ecad/2024/03/vec#> .
@prefix xs:   <http://www.w3.org/2001/XMLSchema#> .

UML to OWL

VEC Namespace

The namespace of the VEC ontology is: http://www.prostep.org/ontologies/ecad/2024/03/vec#. The recommended namespace prefix is vec (used in the ECAD-WIKI for any example). The owl:versionIRI is http://www.prostep.org/ontologies/ecad/2024/03/vec/<version>#, e.g. http://www.prostep.org/ontologies/ecad/2024/03/vec/2.1.0# for every VEC version.

General

The following mapping rules apply to all elements:

1. If a UML model element is mapped into RDF, the documentation in the model is mapped to rdfs:comment.
2. Regardless of the pattern used to create the IRI of an element, the name of the element in the UML model is used as the rdfs:label.

Classes

Regular classes in the UML Model (see figure below for an example form the VEC) are mapped to RDF in the following form.

1. The name of the class is used as IRI (within the VEC-namespace).
2. Class names begin with an upper case letter.
3. The rdf:type is owl:Class.
4. Inheritance in the UML model is mapped to rdfs:subClassOf.

For the class ItemVersion the mapping is the following.

vec:ItemVersion  rdf:type  owl:Class;
        rdfs:comment     "Abstract super-class for physical objects ..."@en;
        rdfs:label       "ItemVersion"@en;
        rdfs:subClassOf  vec:ExtendableElement .

Since the VEC uses a object oriented design concept multiple inheritance of classes is not allowed. This is translated to owl:AllDisjointClasses statements for subclasses of a specific class.

[ rdf:type     owl:AllDisjointClasses;
  owl:members  ( vec:DocumentVersion vec:PartVersion )
] .

Enumerations

Enumerations are sets of predefined values. The VEC defines two concept for enumerations, Open and Closed enumerations (see Open and Closed Enumerations). You can find two examples in the figure below.

For the translation into RDF enumerations are treated as regular classes, in contrast to XML Schema, where an enumeration is just a xs:restriction on the xs:string datatype. To distinguish enumerations from regular VEC classes, the classes Enumeration, OpenEnumeration and ClosedEnumeration are explicitly defined in the ontology as follows (rdfs:comment and rdfs:label omitted).

vec:Enumeration rdf:type owl:Class .

vec:OpenEnumeration 
        rdf:type         owl:Class;
        rdfs:subClassOf  vec:Enumeration .

vec:ClosedEnumeration 
        rdf:type         owl:Class;
        rdfs:subClassOf  vec:Enumeration .

vec:enumLiteral 
        rdf:type            owl:DatatypeProperty;
        rdfs:domain         vec:Enumeration;
        rdfs:range          xs:string;
        rdfs:subPropertyOf  rdfs:label .

The naming conventions for enumerations are the same as for regular classes. In addition, every Enumeration has a data property enumLiteral for the actual enum string value, as defined in the model. An enumeration in the UML model is translated to RDF as a subclass of OpenEnumeration or ClosedEnumeration. The Literals are translated as owl:NamedIndividuals of the class, the IRIs of the literals are created with the pattern: “<ClassName>_<LiteralName>”

vec:SegmentCrossSectionAreaType
        rdf:type         owl:Class;
        rdfs:subClassOf  vec:OpenEnumeration .

vec:SegmentCrossSectionAreaType_Reserved
        rdf:type         vec:SegmentCrossSectionAreaType , owl:NamedIndividiual;
        vec:enumLiteral  "Reserved" .

vec:SegmentCrossSectionAreaType_Real
        rdf:type         vec:SegmentCrossSectionAreaType , owl:NamedIndividiual;
        vec:enumLiteral  "Real" .        

For OpenEnumerations the extension with new custom literals is straight forward. They can be easily defined as new individuals of the corresponding enum class. However, they should be defined in an appropriate namespace and not in VEC-namespace. The enumeration above could be extended for example like this:

acme:SegmentCrossSectionAreaType_MyCustomLiteral
        rdf:type         vec:SegmentCrossSectionAreaType , owl:NamedIndividiual;
        vec:enumLiteral  "MyCustomLiteral" .   

In contrast to OpenEnumerations, ClosedEnumerations should not be extendable. Their set of enumeration values is predefined and closed. This semantic is expressed in the ontology representation by an equivalence axiom similar to the following:

vec:ValueDetermination
        rdf:type             owl:Class;
        rdfs:subClassOf      vec:ClosedEnumeration;
        owl:equivalentClass  [ rdf:type   owl:Class;
                               owl:oneOf  ( vec:ValueDetermination_Calculated vec:ValueDetermination_Measured vec:ValueDetermination_Estimated )
                             ] .

Primitives

The UML Model uses several primitive datatypes. The mapping to XML Schema datatypes, which are also used as primitive datatypes in RDF is the following:

String=xs:string
Double=xs:double
Integer=xs:integer
Int=xs:integer
Boolean=xs:boolean
Date=xs:dateTime

Associations & Attributes

The following mapping rules apply for attributes & associations:

1. In order to have a general, context free and simple translation rule, that creates stable and reproducible IRIs for properties, the IRI is always fully qualified. It is created with the pattern: “<ClassName><RoleName>” where first letter of <ClassName> is lower case and the first letter of <RoleName> is upper case.
2. All primitive properties are mapped to owl:DataProperty, all other properties are mapped to owl:ObjectProperty.
3. rdfs:range/domain statements are created, corresponding to the declaring class and the datatype of the property.
4. All properties that represent a “containment” are mapped as rdfs:subPropertyOf vec:contains (explained further down). Containments are all attributes and all associations modelled as composite.

vec:itemVersionCompanyName
        rdf:type      owl:DatatypeProperty;
        rdfs:domain   vec:ItemVersion;
        rdfs:label    "companyName"@en;
        rdfs:range    xs:string .

vec:itemVersionAbbreviation
        rdf:type            owl:ObjectProperty;
        rdfs:domain         vec:ItemVersion;
        rdfs:label          "abbreviation"@en;
        rdfs:range          vec:LocalizedString;
        rdfs:subPropertyOf  vec:contains .

To map the hierarchical structure of the VEC, two general properties are defined as follows:

vec:contains  
        rdf:type  owl:ObjectProperty;
        rdfs:comment  "This is the representation of the containment modeled in the UML. All associations that are a \"containment\" in the UML model are subproperties of this property."@en;
        rdfs:label    "contains"@en .

vec:parent  
        rdf:type   owl:ObjectProperty;
        rdfs:comment   "The inverse of 'contains'."@en;
        rdfs:label     "parent"@en;
        owl:inverseOf  vec:contains .

Ordered & Non-Unique

The VEC model allows attributes & compositions to Ordered and associations to Ordered and/or Non-Unique. See the figure below for the different cases.

Side Note: Non-Uniqueness is only possible for associations.

• Ordered means that the elements of the property / association have a specified order that has defined semantic in the domain. For example the order of the TopologySegment in a Path defines the order in which a wire is routed through the topology.
• Non-Unique means, that the same two element can be associated multiple times and that the number of associations is relevant.

Since RDF is a pure triple representation, there is no native way to represent order or non-uniqueness, in contrast to XML where all associations are ordered and non-unique per default. To represent these semantics in the VEC ontology additional model elements are introduced.

To express “order” as a general concept the class Ordered is defined as follows:

vec:Ordered  
        rdf:type  owl:Class;
        rdfs:comment  "Class of elements that are ordered within their containment."@en;
        rdfs:label    "Ordered"@en .

vec:orderedIndex  
        rdf:type  owl:DataProperty;
        rdfs:comment  "Defines the order of Ordered elements. Lower indices are further forward in a list. 0 is the lowest index, i.e. the first element."@en;
        rdfs:domain   vec:Ordered;
        rdfs:range    xs:nonNegativeInteger .

For all attributes & compositions order is defined within the context of the “container”. In consequence, there is only one order for each element, as there is only one container for each element. Therefore, the order can be “stored” in the element itself. In other words, all element that are contained in an ordered attribute or composition are also Ordered. In the ontology, this is expressed by the following triple:

vec:cavitySpecificationAngle
        rdf:type            owl:ObjectProperty;
        rdfs:domain         vec:CavitySpecification;
        rdfs:label          "angle"@en;
        rdfs:range          vec:NumericalValue , vec:Ordered;
        rdfs:subPropertyOf  vec:contains .

With associations, the same object can be referenced multiple times and receive different orders for each referencing. For example, a segment can occur in different paths and in different places. In these cases, a wrapper class is created in the ontology for the target class. The wrapper participates unambiguously in association in the context of the source object and references the actual target object. This allows the non-unique semantics to be mapped. If ordering is also required, it is applied to the wrapper class, analogous to the mapping attributes and composition. For the Path / TopologySegment the resulting partial ontology is the following:

vec:pathSegment  
        rdf:type   owl:ObjectProperty;
        rdfs:domain         vec:Path;
        rdfs:label          "segment"@en;
        rdfs:range          vec:TopologySegmentWrapper , vec:Ordered;
        rdfs:subPropertyOf  vec:contains .

vec:TopologySegmentWrapper
        rdf:type         owl:Class;
        rdfs:comment     "Container class for TopologySegment to participate in non-unique and/or ordered associations.".

vec:topologySegmentWrapperItem
        rdf:type      owl:ObjectProperty;
        rdfs:comment  "References the actual item for a Wrapper.";
        rdfs:domain   vec:TopologySegmentWrapper;
        rdfs:range    vec:TopologySegment .

UML to SHACL

In addition to the ontology, a SHACL schema is derived from the UML model to allow validation of RDF graphs similar to the classic XML schema.

Namespace

The namespace of the SHACL Shapes is http://www.prostep.org/ontologies/ecad/2024/03/vec-shacl# the recommended prefix is vecsh.

Classes

For each class a <ClassName>Shape is created, similar to the one listed below (shortened for readability). Constraints for cardinalities of associations and target types are generated.

vecsh:ItemVersionShape
        rdf:type         sh:NodeShape;
        rdfs:subClassOf  vecsh:ExtendableElementShape;
        sh:property      [ sh:class     vec:CopyrightInformation;
                           sh:maxCount  1;
                           sh:minCount  0;
                           sh:path      vec:itemVersionCopyrightInformation
                         ];
        #... more properties here ...
        sh:property      [ sh:datatype  xs:string;
                           sh:maxCount  1;
                           sh:minCount  1;
                           sh:path      vec:itemVersionCompanyName
                         ];
        sh:property      [ sh:class     vec:ChangeDescription;
                           sh:minCount  0;
                           sh:path      vec:itemVersionChangeDescription
                         ];
        sh:targetClass   vec:ItemVersion .

The constraints above ensure only the target types (objects) of the properties. Without additional constraints, a property could be used on any class as subject. To ensure that all properties are only used on the classes that declare the property in the UML model, for each class <ClassName>InverseShape is created, similar to the following one:

vecsh:ItemVersionInverseShape
        rdf:type             sh:NodeShape;
        rdfs:subClassOf      vecsh:ExtendableElementInverseShape;
        sh:class             vec:ItemVersion;
        sh:targetSubjectsOf  vec:itemVersionChangeDescription , vec:itemVersionCompanyName , vec:itemVersionCopyrightInformation 
        #... more properties here ...
        .         

Ordered / Non-Unique

For Ordered and Non-Unique attributes & associations the constraints are generated accordingly to the pattern described in the UML to OWL mapping section (see above).

vecsh:OrderedShape  
        rdf:type  sh:NodeShape;
        sh:property     [ sh:datatype  xs:nonNegativeInteger;
                          sh:maxCount  1;
                          sh:minCount  1;
                          sh:path      vec:orderedIndex
                        ];
        sh:targetClass  vec:Ordered .

vecsh:PathShape  
        rdf:type  sh:NodeShape;
        rdfs:subClassOf  vecsh:ExtendableElementShape;
        sh:property      [ sh:class     vec:Ordered , vec:TopologySegmentWrapper;
                           sh:minCount  0;
                           sh:path      vec:pathSegment
                         ];
        sh:targetClass   vec:Path .


vecsh:TopologySegmentWrapperShape
        rdf:type        sh:NodeShape;
        sh:property     [ sh:class     vec:TopologySegment;
                          sh:maxCount  1;
                          sh:minCount  1;
                          sh:path      vec:topologySegmentWrapperItem
                        ];
        sh:targetClass  vec:TopologySegmentWrapper .        

vecsh:CavitySpecificationShape
        rdf:type         sh:NodeShape;
        rdfs:subClassOf  vecsh:SpecificationShape;
        sh:property      [ sh:class     vec:Ordered , vec:NumericalValue;
                           sh:maxCount  2;
                           sh:minCount  0;
                           sh:path      vec:cavitySpecificationAngle
                         ];
        #... more properties here ...
        sh:targetClass   vec:CavitySpecification .

Enumerations

A general EnumerationShape is create to ensure that all enumerations define a vec:enumLiteral. For each enumerations an individual <ClassName>EnumShape is created to ensure that only defined literals are used. For OpenEnumerations the sh:severity of such “violations” is lowered to sh:Info since the addition of new literals is explicitly allowed, but custom literals should reported nevertheless.

vecsh:EnumerationShape
        rdf:type        sh:NodeShape;
        sh:property     [ sh:datatype  xs:string;
                          sh:maxCount  1;
                          sh:minCount  1;
                          sh:path      vec:enumLiteral
                        ];
        sh:targetClass  vec:Enumeration .

vecsh:ValueDeterminationEnumShape
        rdf:type        sh:NodeShape;
        sh:in           ( vec:ValueDetermination_Calculated vec:ValueDetermination_Measured vec:ValueDetermination_Estimated );
        sh:targetClass  vec:ValueDetermination .

vecsh:SegmentCrossSectionAreaTypeEnumShape
        rdf:type        sh:NodeShape;
        sh:in           ( vec:SegmentCrossSectionAreaType_Reserved vec:SegmentCrossSectionAreaType_Real );
        sh:severity     sh:Info;
        sh:targetClass  vec:SegmentCrossSectionAreaType .        

Handling of Identifiers

The VEC and its XML Schema offer different concepts for the identification of model elements addressing certain requirements and those shall be used accordingly.

Identification-Properties (VEC Model)

Many types defined in the VEC model have an “Identification” property (e.g. the OccurrenceOrUsage). This is meant to be a semantic identifier of the object represented by the VEC element. The following rules apply to those identifiers:

1. The expectations defined in the documentation of the VEC model of the corresponding attribute shall be ensured.
2. The identifications shall be unique for a certain element type, at least within its context element. In other words, the VEC model and its representation as XML Schema is a hierarchical data model. That means, that an identification shall be at least unique within its direct parent element (e.g. the identification of a HousingComponent shall be unique within its EEComponentSpecification.
3. Two elements of different types can have the same Identification. However, this is only recommended, when the two VEC elements represent the same domain entity from different points of view, otherwise this shall be avoided as far as possible.
4. In general, it is recommended to keep the Identifications stable over the time. This means, that if an object is exported multiple times the Identification of it should be the same. However, this is not possible in all cases, for all processes and all tools. Therefore, a process and / or tool creating VEC files should describe for all elements, under which conditions Identifications are stable or new ones are created.

AliasIdentification-Properties (VEC Model)

Certain elements have the capability to define AliasIdentifications in addition to their unique identifications. AliasIdentifications are scoped identifiers of the object. The scope can be a system, a company or or process. One use case of this kind of ids is the creation of traceability links between different sources of information. Examples for usages of the AliasIdentifications are:

• The identifier of a connector in the electrological process (with geometric variants)
• The identifier of a node or segment in a MCAD tool
• An assigned UUID of an element.

id-Attributes (XML Representation)

All xs:complexType define an id-Attribute with the type xs:ID. These are technical ids that are necessary for the referencing mechanism of the VEC within a single XML file. The semantics, constraints and requirements are defined by the XML Standard and XML Schema itself. These ids do not have any significance outside a VEC file. See the Section id-Attibutes.

immutable-global-id-Attributes (XML Repesentation)

See the Section immutable-global-id-Attributes.

IRIs (RDF Representation)

In RDF all objects (named resources in RDF) require a global unique identifiers which is an IRI. This is mandatory for resource to be “referencable”. The maturity of the IRI generation strategy decides quality & stability of links within RDF graphs. There it should be thoroughly thought through when representing VEC data in RDF. The RDF IRI is very similiar to the immutable-global-id feature in VEC XML representations. When mapping VEC data from XML to RDF and back, it should be possible to use immutable-global-id (when defined), as RDF IRI and vice versa.

However, RDF IRIs are a standard concept defined in RDF, whereas the immutable-global-id are a specific feature of the VEC XML representation.

Extension Rules

If the well-defined data structures and fields are not sufficient for the specific needs of a process or a tool, the VEC provides powerful extension mechanisms. Namely the extension mechanisms are custom properties and open enumerations (see the corresponding chapters in the model description).

However, it should be considered that information transported via these mechanisms is not standardized and is always subject to an individual agreement between interface partners. Therefore, these mechanisms shall be used with extreme caution.

It is strictly forbidden to use these mechanisms for the transfer of information that is already standardized within the VEC. In particular it is not permitted:

• To store information in custom properties where already well-defined concepts exist in the VEC to store the same information, e.g. using a custom property instead of an attribute or a more specific class in inheritance tree.
• To use self-defined OpenEnumeration-literals when well-defined literals with the same semantics already exist.

VEC-Files that do not obey to these rules are noncompliant to this data format specification.

If the extension mechanisms are used, it shall always be considered if these extensions might be a valid feature request for the VEC Standard.

Type Inheritance

The VEC uses an object-oriented class and inheritance concept. The following clarifications apply to its use:

• Only non-abstract classes can be instantiated.
• In an inheritance hierarchy, the choice of the used type represents a semantic information itself. For example, the usage of a PluggableTerminalSpecification is a more specific information than the usage of a TerminalSpecification. It is not required to use the more specific class if the information is not available or it should not be transmitted. However, it is not permitted to use the more general class and transfer the information of the more specific class in a custom property, or similar (e.g. use the TerminalSpecification with a CustomProperty type=pluggable).

Default- and Missing-Value Handling

For various reasons, there may be attributes of entities where no value can be exported, or a special semantics is required. The cases are:

• The information is not supported by the system / process. So, it is never available for this system / process.
• The information is supported by the system; however, the value is not defined by the user.
• The information is explicitly defined as “arbitrary” for the use case (e.g. the part version in a bill of material or a compatibility statement).

All cases might exist for mandatory attributes as well as for optional attributes. Due to the design, numerical values in the VEC and its high level of optionality the following definition of special values should be only relevant for xs:string-Attributes:

• /NULL & /ANY means, that the attributes with the name “tag” in the VEC receive these values.
• <tag></tag> means, that an attribute with the name “tag” and an undefined value is represented in the VEC as an existing XML element with no value (no contained text() node).
• omitted tag: means the element tag for the attribute is not present in the VEC

Instantiation of Model Structures

There are various locations in the VEC model where structures / patterns are defined and used / instantiated somewhere else (e.g. a connector with its slots and cavities). In most cases, the elements in the definition of a structure have corresponding elements in the instancing (e.g. ConnectorHousingSpecification → ConnectorHousingRole, Slot → SlotReference & Cavity → CavityReference).

Scope of Instantiation

Following the principle of optionality in the VEC, a defined structure does not have to be instantiated completely. Only the elements that are required for the definition of the respective context need to be instantiated. An element is required if the context makes a statement about it, for example a context specific identifier or description, a redefined technical property, a placement, a routing or a contacting. For example, a CavityReference is required for a Cavity that is contacted in the harness, but not for a cavity about which the harness does not state anything.

Where an instantiation element exists, it shall reference the element of the structural definition it instantiates (e.g. referencedCavity of a CavityReference, referencedWireElement of a WireElementReference or partStructureSpecification of a PartWithSubComponentsRole). For the instantiation of library parts (e.g. assemblies), each instantiated occurrence shall additionally reference its origin in the part master definition (instanciatedOccurrence / instanciatedUsage, see Composite Parts).

This applies to all instantiated structures, for example connectors, wires, E/E components and composite parts (assemblies, modules). The same principle applies to the creation of Roles (see Instantiation with Roles) and to the description of parts with specifications (see Content Requirements).

Absence of Instantiation Elements

As a consequence, the absence of an instantiation element has no meaning of its own. A missing CavityReference means “no statement about this cavity in this context”, and not “this cavity is unused”. The same applies to SlotReference, WireElementReference, HousingComponentReference and all other instantiation elements. A reading system shall not interpret the absence of an instantiation element as a statement about the product.

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.

Background

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 performed and the document is “saved” again, with the document now 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 document or an 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 this example, 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”

Navigating Information in a VEC

A receiving system shall locate the information relevant for its use case primarily via the relationships of the model, and not by searching for specific DocumentTypes or by expecting a specific structure of DocumentVersions. The reasons are:

• The documentType of a DocumentVersion is optional. A system relying on it fails for valid VECs.
• DocumentType is an open enumeration. The set of possible values cannot be enumerated.
• The cut of information into DocumentVersions is process specific (see General Structure).

The following table lists the navigation paths for common questions:

The containing DocumentVersion and its meta data (including the DocumentType, if present) can then be used to decide whether a piece of information is relevant for the use case, e.g. to distinguish information from different sources (see Content from mixed Sources).

A PartVersion can be described by several specifications of the same type, contained in different DocumentVersions, e.g. if each of them contains the view of a different process partner on the same part. In this case, a reading system has to evaluate the containing DocumentVersions and decide which specification is relevant for its use case.

Summary of the Requirements

The aforementioned results in the following general requirements for systems with VEC interface:

• A system is not required to interpret, implement or store the full extent of the VEC model, when only portion of it is required for its specific use case.
• A system must be able to extract the information relevant for its use case from VEC files that contain more information than the system itself requires or is able to process.
• A system is only required to export the information relevant to its use case. In other word, in a roundtrip scenario with a “more powerful” system it may return less than it has received.
• On the other side, a system that is able to export a very extensive VEC is not required to strip the information down for a “less powerful” system.
• A system can reject VEC files that do not contain enough or only irrelevant information for its use case.

External References

For reasons of traceability (e.g. requirements) or because certain information is better represented in other standards than in the VEC format (e.g. 3D models for components), it is necessary to be able to reference external documents from VEC elements. This guideline describes how these external documents can be addressed and what concepts exist to connect those documents with VEC model elements (and when to use which).

Referencing an external Document

As described in the Implementation Guideline “General Structure” the DocumentVersion serves several purposes, one of which is the referencing of external Documents. So, whenever a connection between a VEC element and an external document should be created, a DocumentVersion is required to address the document. Such a DocumentVersion should contain no payload data (Specification). However, it contains the same meta-data as it would, when included as a full featured document (e.g. DocumentType).

There are different possibilities to resolve such a reference and retrieve the actual document:

1. PDM reference with 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 file (VEC Package) the filename attribute of DocumentVersion can point to a location within the VEC Package. If the document is not part of the VEC Package, the FileName-Attribute shall be omitted.
3. Location: If the document can be resolved outside the VEC package, the Location-Attribute can point to a location (via an URN or URL) where the document can be resolved. For files that are stored following a specific procedure or systematics (e.g. in PDM System) the usage of URNs should be the preferred way. This decouples the referencing from a concrete physical location, which might be different in different contexts or might be changed over the time.

Connecting VEC Model Elements

After defining an external reference as DocumentVersion there are multiple approaches to create connections to VEC model elements. Some approaches have a specific semantic, some are more generic. The different possibilities are summarized below. If there are more than one possibility for a specific element, you have to choose the one with most specific semantics.

• DocumentVersion.ReferencedPart → PartVersion: The document describes the part in some way (e.g. a component drawing). See “Parts, Documents and Resources”.
• DocumentVersion.RelatedDocument: The association is an informative link which DocumentVersion are related to each other (e.g. by derivation, A Harness-Drawing is related to a 3D-Model). See “Parts, Documents and Resources”.
• RequirementsConformanceStatement.DocumentVersion: Some PartVersions are satisfying (or not) the requirements defined in the external document. See “Conformance to Requirements”.
• ExternalMappingSpecification.MappedDocument: The external document is a different view on the same content described by this specific VEC and a mapping / active linking between the same elements in both views should be created. For example a harness and its drawing in SVG. See “External Mapping”.
• DocumentBasedInstruction.ReferencedDocument: An OccurrenceOrUsage has specific installation instructions that are defined in an external document (e.g. a manual or a working specification). See “Installation Instructions”.
• ExtendableElement.ReferencedExternalDocuments: The referenced document contains additional information about the VEC element, that cannot be represented in the VEC in an appropriate way. See “Parts, Documents and Resources”.
• DocumentRelatedAssignmentGroup.RelatedDocumentVersion: A DocumentRelatedAssignmentGroup allows the creation of traceability links to elements in a DocumentVersion for a set of VEC objects. The semantic of the traceability link is defined by the DocumentRelationType, for example requirements that apply to these VEC elements. See “Assignment Group”.

External Mapping

The diagram above shows 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 mapping itself and the DocumentVersion highlighted in green represents the link to the mapped document (in this case a SVG-symbol).

The ExternalMapping in this example defines that a representation of the referenced ConnectorHousingSpecification can be found in the SVG-symbol under the key ID_27101123. This is especially useful, if one wants address specific subelements (e.g. for highlighting). In the example, the Cavitys of the connector could also be mapped to specific symbols within the SVG.

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.

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).

General Structure of VEC Files & Documents

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). This is described in detail here.
• 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.

However, regardless of the use of the DocumentVersion, it always represents the meta-data of the entity in the process, which does not change depending on its VEC representation. Meaning, if for example a system schematic is referenced as external document in one place (VEC file) and is used as a native document / digital representation in another place, it is still a system schematic (DocumentType) with the same DocumentNumber & Version.

DocumentVersions as Building Blocks of the Information Exchange

A VEC (e.g. a file or the response of a REST interface) always represents a snapshot of information in a specific, fixed state. The VEC is a means of data exchange, not of data management (see Expected Behaviour of VEC Interfaces).

The cut of information into DocumentVersions is process specific. It reflects the responsibilities and approvals in the process: the content of a DocumentVersion is the scope of information that the process tracks and annotates with meta data. DocumentVersions are therefore the building blocks of an interface architecture — units of information exchanged between process partners, with a scope agreed within the process. There are typical scopes for typical processes (e.g. what a system schematic or a harness description contains), but significant deviations are valid as well.

In contrast to Specifications, DocumentVersions do not represent structural boundaries of the model. Even if two DocumentVersions are contained in the same VEC file, they are clearly separated from the perspective of versioning (see External References), but not from the perspective of the model. In particular, they are no boundary for references:

• Within one VEC file, references between elements in different DocumentVersions (e.g. from an occurrence in a harness description to a PartVersion and its part master data, or from a wire to a connection of a system schematic) are ordinary XML IDREFs.
• Across VEC files, an IDREF cannot span the file boundary. The relationship is established via the PDM identity of the referenced items (PartVersion and DocumentVersion numbers and versions), as assumed by the partitioning rules (rule 2). A VEC whose references can be resolved requires that the creating system includes the referenced information with the appropriate scope.

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 XML / XSD Representation 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.

The same applies whenever content from several VEC files is combined into one VEC, e.g. to embed information for traceability or to bundle the harnesses of a vehicle network: the assignment of the information to its original DocumentVersions shall be preserved (see also Content from mixed Sources).

This rule applies to the aggregation of information, where the combined information itself remains unchanged. It does not apply to a semantic merge, where the combination creates new content. An example are partial system schematics: when partial systems are merged into an overall system, matching open links are resolved and the ComponentNodes of type OpenLink are removed (see System Schematic – Partial Systems). The result is new information, contained in a new DocumentVersion.

The combination of wiring harnesses into a vehicle network is normally not a semantic merge: a harness does not change or behave differently when it is put into a vehicle. Therefore, the harness descriptions of a vehicle network remain separate DocumentVersions, and information concerning the vehicle network as a whole is added in additional DocumentVersions (see Product Definition – Vehicle Network). Merging the harness descriptions into a single DocumentVersion is possible, but not recommended.

Content from mixed Sources

It is a common scenario that a VEC model contains information from different sources. In some cases it is pretty obvious that the information comes from different sources, e.g. part master data from a component database, a system schematic from an ECAD tool, and a geometry model from a 3D CAD system.

However, there are also use cases where the information from different sources is not so clearly distinguishable by its type. It is even possible, that the same type of information is obtained from different sources. Some examples for such scenarios are:

• Occurrences of components are defined in different places / process steps, e.g. in the electrologic, DMU or in the actual harness design.
• Additional information like placements and routing might come from different tools or process steps as well.

There are two apporoaches to handle such scenarios in the VEC, while keeping the traceability of the information to its source:

• Separate DocumentVersions per Source: In this approach, the information from each source is contained in a separate DocumentVersion. This is the preferred approach, as it clearly separates the information from different sources and preserves traceability in the change management. Each DocumentVersion can be clearly associated with its source, e.g. by using appropriate meta-data like document type, document number, version, etc.
• Single DocumentVersion with individual Specifications: This is approach is used, if all information must be combined into a single DocumentVersion. The information from different sources is kept separated by using individual Specifications for each source. However, this approach lacks the clear representation of source metadata on the DocumentVersion level (e.g. document number & version), which might impact traceability for example in the change management.

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, if the content is represented in the VEC.

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. A detailed description can be found in the “Component Description” Guideline.

Harness Description

A harness description describes a wiring harness as a physical product, regardless of its informational completeness. Its typical content and the scope of a harness description are described in Product Definition of a Harness.

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 of Document Versions

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, Documents and Resources before, as it also contains important information about this topic.

In the VEC, data is organized in DocumentVersions and those are unambiguously identified by CompanyName, DocumentNumber and Version. Those attributes are identifying an entity relevant for the process as the single source of truth for this information, for example a drawing, a data sheet or even an entity in a database. The handling of those attributes and the corresponding change procedures are driven by the process and not by technical requirements. In many cases the VEC only contains a digitally readable representation (an export) of that information.

Consequently, the identifying attributes and in particular the Version are only changed, when the relevant process entity has changed, according to rules applied by the process (e.g. a new version of a drawing has been created and approved). However, there are numerous scenarios (described in detail below) where the payload content in a VEC DocumentVersion can change, without a change of the underlying process entity. To allow the content of a DocumentVersion to be marked as changed in such scenarios, 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, Documents and Resources for a definition of “unchanged”).

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 in the VEC changes, without being able to at least adjust / increment the Version-attribute.

When to Modify

A reading system can assume the payload content of a DocumentVersion unchanged, when the DigitalRepresentationIndex has not changed between two VEC files. The DigitalRepresentationIndex shall be different, whenever the payload content of a DocumentVersion with the same CompanyName, DocumentNumber and Version is different. If a clear statement is not possible, a change is to be assumed in case of doubt. As mentioned before, there are multiple scenarios where such a situation might occur. The illustration below is intended to explain some examples of such scenarios.

In all scenarios, the content of the DocumentVersion in a VEC files might be different, resulting in a modified digital representation index, for the same (unchanged) source document. For the example, assume the document entity in the process is an approved component drawing as PDF (highlighted in blue on the left hand side of the figure). This is the document identified by CompanyName, DocumentNumber and Version. The following situations might occur that result in different digital representations without changed source document:

• In a first step (marked with (1)), the information from the drawing is transferred manually into an IT-System (e.g. a component database). A first digital representation is created. However, this representation might be changed at a later point for multiple reasons:
  • A mistake / typo occurred during the manual data transfer and is corrected.
  • Data management guidelines or the underlying IT-System changed and more information from the original document has to be transferred.
• This data is exported into a Component Data VEC (marked with (2)). If this is done multiple times, different digital representation might be created due to:
  • Added features of the exporter resulting in more information in the export.
  • A bug fix for the exporter component or the exporting system.
  • An update of the underlying VEC version.
• The component data is used to create other artifacts in the development process (marked with (4)). For this, at least parts of the original information might be embedded in the new artifact for traceability reasons. Another digital representation is created.
• A system might provide different export flavours with different content levels depending on the recipient. For example a VEC for external partners might contain less information as a VEC for internal use.
• The source document might contain various information. E.g. a single component drawing can define a complete family of components (e.g. a family of terminals). When creating a VEC file per component (recommended approach for a component database), the resulting VEC file should only contain the information relevant to exported component and not all components defined in the drawing. Therefore, you might have different DocumentVersions containing different information slices of the same source document (illustrated in the figure below).

Contributions to a Target Dataset

The scenarios above start from one source document with several digital representations. The inverse scenario is possible as well: a DocumentVersion with a known target identity (CompanyName, DocumentNumber and Version) exists, and several processes or tools each contribute a part of its content. For example, a harness description is created by a 3D design tool (topology, geometry and placements), while electrical information and variants are contributed by another discipline (compare Product Definition of a Harness).

Each contribution is a digital representation of the target DocumentVersion with partial content. The DigitalRepresentationIndex indicates which state of a contribution has been delivered, according to the rule in When to Modify.

Merging the contributions is the responsibility of a system, not of the exchange format:

• Before the merge, the contributions are independent from each other. They are exchanged in separate VEC files; there is no reason to put them into a single VEC file (a VEC containing several DocumentVersions with the same DocumentNumber is suspicious, see Compliance Tests, TC-0005).
• After the merge, there is logically one DocumentVersion with the merged content and a new DigitalRepresentationIndex.

If several contributions describe the same PartVersion (e.g. the PartVersion of a harness), only one of them — the one responsible for the bill of material — contains the PartStructureSpecification of this PartVersion (compare TC-0003).

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.

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>

Architectural Layer

Basic Architectural Layer

The Architectural Layer is the highest abstraction layer for describing electrological aspects in the VEC. It focuses on defining the connectivity between components without specifying the physical realization of that connectivity. This layer is particularly useful for early design phases, where the overall system architecture needs to be established without delving into implementation details.

The figure above illustrates a simple sketch of a “Power Window (Driver Side)” system in the architectural layer. It shows the main components involved (Body Controller, Door Module Driver, and Power Window Engine Driver) and the communication links between them. However, it does not specify how these connections are physically realized (e.g., electrical potentials, wire types, connectors). The instantiation of this sketch in the VEC is shown in the figure below.

The VEC instantiation in this example contains slightly more detail than the sketch, but still refrains from defining physical realization aspects. The VEC elements used to describe the Architectural Layer are contained in the NetSpecification. Each E/E Component is represented by a NetworkNode. The communication links between the components are represented by three Nets. A Net is the usage of a NetType, e.g., “CAN Bus” or “HALL”, defining the technology used for communication. The Net defines a specific instance of this technology in the system, e.g., “Body-CAN Bus” or “HALL for Power Window Driver Side”.

The XML representation of the above example within the NetSpecification is shown below:

<?xml version="1.0" ?>
<vec:VecContent xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:vec="http://www.prostep.org/ecad-if/2011/vec" id="Content_00000" xsi:schemaLocation="">
  <VecVersion>2.2.0</VecVersion>
  <GeneratingSystemName>VEC Samples</GeneratingSystemName>
  <DateOfCreation>2025-11-03T14:05:24.068903900Z</DateOfCreation>
  <GeneratingSystemVersion>0.0.1</GeneratingSystemVersion>
  <DocumentVersion id="DocumentVersion_00001">
    <CompanyName>Acme Inc.</CompanyName>
    <DocumentNumber>1234567</DocumentNumber>
    <DocumentType>NetworkArchitecture</DocumentType>
    <DocumentVersion>a</DocumentVersion>
    <Specification xsi:type="vec:NetSpecification" id="NetSpecification_00002">
      <Identification>NETWORK</Identification>
      <Net id="Net_00003">
        <Identification>PWED-Engine</Identification>
        <NetType>NetType_00006</NetType>
        <NetworkPort>NetworkPort_00017 NetworkPort_00014</NetworkPort>
      </Net>
      <Net id="Net_00004">
        <Identification>HALL</Identification>
        <NetType>NetType_00007</NetType>
        <NetworkPort>NetworkPort_00016 NetworkPort_00013</NetworkPort>
      </Net>
      <Net id="Net_00005">
        <Identification>Body-CAN</Identification>
        <NetType>NetType_00008</NetType>
        <NetworkPort>NetworkPort_00010 NetworkPort_00012</NetworkPort>
      </Net>
      <NetType id="NetType_00006">
        <Identification>12V-Power</Identification>
        <SignalType>Energy</SignalType>
      </NetType>
      <NetType id="NetType_00007">
        <Identification>HALL</Identification>
        <SignalType>Information</SignalType>
        <SignalInformationType>Analog</SignalInformationType>
      </NetType>
      <NetType id="NetType_00008">
        <Identification>CAN</Identification>
        <SignalType>Information</SignalType>
        <SignalSubType>CAN</SignalSubType>
        <SignalInformationType>Digital</SignalInformationType>
      </NetType>
      <NetworkNode id="NetworkNode_00009">
        <Identification>BCM</Identification>
        <Port id="NetworkPort_00010">
          <Identification>CAN1</Identification>
          <NetType>NetType_00008</NetType>
        </Port>
      </NetworkNode>
      <NetworkNode id="NetworkNode_00011">
        <Identification>DMD</Identification>
        <Port id="NetworkPort_00012">
          <Identification>CAN</Identification>
          <NetType>NetType_00008</NetType>
        </Port>
        <Port id="NetworkPort_00013">
          <Identification>PWED-HALL</Identification>
          <NetType>NetType_00007</NetType>
        </Port>
        <Port id="NetworkPort_00014">
          <Identification>PWED-Engine</Identification>
          <NetType>NetType_00006</NetType>
        </Port>
      </NetworkNode>
      <NetworkNode id="NetworkNode_00015">
        <Identification>PWED</Identification>
        <Port id="NetworkPort_00016">
          <Identification>HALL</Identification>
          <NetType>NetType_00007</NetType>
        </Port>
        <Port id="NetworkPort_00017">
          <Identification>Engine</Identification>
          <NetType>NetType_00006</NetType>
        </Port>
      </NetworkNode>
    </Specification>
  </DocumentVersion>
</vec:VecContent>

Transition to System Schematic Layer

The system schematic layer is one abstraction level below the architectural layer. It adds more detail to the connectivity defined in the architectural layer by differentiating the electrical potentials and connections between components, while still not delving into physical realization details, e.g. wire colors or cross sections. More details regarding the system schematic layer can be found in the System Schematic Layer guideline. This transition is illustrated in the figure below.

To maintain clarity, we build upon the previous example of the architectural layer, but with a focus on just the HALL network and its two participants, the DMD and PWED. A HALL-sensor signal typically consists of three electrical potentials: a power supply voltage, a ground reference, and the actual signal output. In the architectural layer, this entire communication link is represented by a single Net named “PWED-HALL”. However, in the system schematic layer, this link is broken down into three distinct Connections, each representing one of the electrical potentials involved in the HALL communication. Also note, that the ComponentNode has a ComponentPort for each electrical potential. These ports are grouped under a ComponentConnector.

The figure belows shows the VEC instantiation of the system schematic layer and the tracability into the network layer, but only for the PWED side and a single connection in order to avoid cluttering of the diagram. Also note that the figure contains Signals as the pyhsical pendants of the NetType.

The XML representation of the above example within the ConnectionSpecification is shown below. This is a partial extract focusing on the connections related to the HALL network and extends the previous XML example for the architectural layer:

[...]
    <Specification xsi:type="vec:SignalSpecification" id="SignalSpecification_00018">
      <Identification>SIGNALS</Identification>
      <Signal id="Signal_00019">
        <Identification>PWED_HALL_GROUND</Identification>
        <SignalType>Ground</SignalType>
        <NetType>NetType_00007</NetType>
      </Signal>
      <Signal id="Signal_00020">
        <Identification>PWED_HALL_IN</Identification>
        <SignalType>Energy</SignalType>
        <NetType>NetType_00007</NetType>
      </Signal>
      <Signal id="Signal_00021">
        <Identification>PWED_HALL_OUT</Identification>
        <SignalInformationType>Analog</SignalInformationType>
        <SignalType>Information</SignalType>
        <NetType>NetType_00007</NetType>
      </Signal>
    </Specification>
    <Specification xsi:type="vec:ConnectionSpecification" id="ConnectionSpecification_00022">
      <Identification>SCHEMATIC</Identification>
      <ComponentNode id="ComponentNode_00023">
        <Identification>DMD</Identification>
        <NetworkNode>NetworkNode_00011</NetworkNode>
        <ComponentConnector id="ComponentConnector_00024">
          <Identification>A</Identification>
          <ComponentPort id="ComponentPort_00025">
            <Identification>1</Identification>
            <NetworkPort>NetworkPort_00013</NetworkPort>
          </ComponentPort>
          <ComponentPort id="ComponentPort_00026">
            <Identification>2</Identification>
            <NetworkPort>NetworkPort_00013</NetworkPort>
          </ComponentPort>
          <ComponentPort id="ComponentPort_00027">
            <Identification>3</Identification>
            <NetworkPort>NetworkPort_00013</NetworkPort>
          </ComponentPort>
        </ComponentConnector>
      </ComponentNode>
      <ComponentNode id="ComponentNode_00028">
        <Identification>PWED</Identification>
        <NetworkNode>NetworkNode_00015</NetworkNode>
        <ComponentConnector id="ComponentConnector_00029">
          <Identification>A</Identification>
          <ComponentPort id="ComponentPort_00030">
            <Identification>1</Identification>
            <NetworkPort>NetworkPort_00016</NetworkPort>
            <Signal>Signal_00019</Signal>
          </ComponentPort>
          <ComponentPort id="ComponentPort_00031">
            <Identification>2</Identification>
            <NetworkPort>NetworkPort_00016</NetworkPort>
            <Signal>Signal_00020</Signal>
          </ComponentPort>
          <ComponentPort id="ComponentPort_00032">
            <Identification>3</Identification>
            <NetworkPort>NetworkPort_00016</NetworkPort>
            <Signal>Signal_00021</Signal>
          </ComponentPort>
        </ComponentConnector>
      </ComponentNode>
      <Connection id="Connection_00033">
        <Identification>PWED_HALL_GROUND</Identification>
        <Net>Net_00004</Net>
        <Signal>Signal_00019</Signal>
        <ConnectionEnd id="ConnectionEnd_00034">
          <Identification>PWED.A.1</Identification>
          <IsExternalEnd>true</IsExternalEnd>
          <ConnectedComponentPort>ComponentPort_00030</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="ConnectionEnd_00035">
          <Identification>DMD.A.1</Identification>
          <IsExternalEnd>true</IsExternalEnd>
          <ConnectedComponentPort>ComponentPort_00025</ConnectedComponentPort>
        </ConnectionEnd>
      </Connection>
      <Connection id="Connection_00036">
        <Identification>PWED_HALL_IN</Identification>
        <Net>Net_00004</Net>
        <Signal>Signal_00020</Signal>
        <ConnectionEnd id="ConnectionEnd_00037">
          <Identification>PWED.A.2</Identification>
          <IsExternalEnd>true</IsExternalEnd>
          <ConnectedComponentPort>ComponentPort_00031</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="ConnectionEnd_00038">
          <Identification>DMD.A.2</Identification>
          <IsExternalEnd>true</IsExternalEnd>
          <ConnectedComponentPort>ComponentPort_00026</ConnectedComponentPort>
        </ConnectionEnd>
      </Connection>
      <Connection id="Connection_00039">
        <Identification>PWED_HALL_OUT</Identification>
        <Net>Net_00004</Net>
        <Signal>Signal_00021</Signal>
        <ConnectionEnd id="ConnectionEnd_00040">
          <Identification>PWED.A.3</Identification>
          <IsExternalEnd>true</IsExternalEnd>
          <ConnectedComponentPort>ComponentPort_00032</ConnectedComponentPort>
        </ConnectionEnd>
        <ConnectionEnd id="ConnectionEnd_00041">
          <Identification>DMD.A.3</Identification>
          <IsExternalEnd>true</IsExternalEnd>
          <ConnectedComponentPort>ComponentPort_00027</ConnectedComponentPort>
        </ConnectionEnd>
      </Connection>
    </Specification>
[...]

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. It is explained in more detail in the guideline ““Coupling””

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.

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 reflects the responsibilities and the release of information in the process. 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>