User Tools

Site Tools


Work on following article or section is in progress

VEC File Structure

Head Information

The VEC container contains its own sub elements to make statements about the data contained. This includes the project details with its car classification levels, copyright information, the source system, a list of belonging contracts or the compliance conformance classes.

Listing 2

<vec:VecContent ...>
    <CopyrightInformation id="id_cpy_right_2">
        <CopyrightNote id="id_cpy_right_3">
            <Value>Lorem Ipsum sit dolor et amet.</Value>
    <Project id="id_proj_10">
        <CarClassificationLevel2>Sample Project</CarClassificationLevel2>
        <Description xsi:type="vec:LocalizedString" id="id_11">
            <Value>This is a sample project</Value>


Because of the fact that units are stateless they can be referenced from every element that represents a physical characteristic of a part or a specific part usage. This global validity is the reason why units are placed directly underneath the VEC root element. The different systems to define units are represented by the subclasses of the unit class (e.g. SIUnit, ImperialUnit).

Listing 3

<Unit xsi:type="vec:SIUnit" id="id_unit_6000">
    <Unit xsi:type="vec:SIUnit" id="id_unit_170">
    <Unit xsi:type="vec:SIUnit" id="id_unit_7238">
    <Unit xsi:type="vec:SIUnit" id="id_unit_442">
    <Unit xsi:type="vec:SIUnit" id="id_unit_189">
    <Unit xsi:type="vec:SIUnit" id="id_unit_445">
    <Unit xsi:type="vec:SIUnit" id="id_unit_196">


The DocumentVersion class is the root element for all payload data in the VEC and all technical information about a PartVersion is contained in one or more documents. Furthermore, the DocumentVersion class opens up the possibility to group those data together, which came from the same approval process and are released at a same time. The payload itself is defined within specifications. Their concrete classes are used to define which type of information is included. The type of the document version can be found in the DocumentType attribute of the DocumentVersion. At the same time, a DocumentVersion is the anchor point for the unique identification of information and its status (DocumentNumber & DocumentVersion).

DocumentVersion for Harnesses

From the point of view of the VEC structure, the definition of a harness does not differ from that of a component because a harness has also a part number and is handled as a part as well (see PartVersion for Harnesses). To describe the harness with its structure and all the technical information, a DocumentVersion is needed and it is recommended to use one for each single harness. This creates a better structure of the data in the model and also a better overview within the VEC XML file structure. To identify a DocumentVersion as a container for a harness the literal ‘HanressDescription’ for the DocumentType attribute can be used. The technical description of a harnesss is made by its containing specifications. See Specifications for Harnesses

DocumentVersion for Coupling Devices

For the instantiation of the coupling devices and their coupling with the connected harnesses a DocumentVersion is inserted below the VecContent. It has the DocumentType “HarnessCoupling” and contains two types of Specifications: - A PartUsageSpecification that contains an instance (PartOccurrence) for each coupling device. - For each coupling device, a coupling specification which establishes the relationships between the slots of the coupling device and the connectors in the connected harness.

DocumentVersion for System Schematic (Sheets)

DocumentVersion for Part Master Data


Signals and Usage Nodes

The definition of signals and usage nodes is part of the part master data. Like a single point of truth all usages of signals or usage nodes in the whole vec content should be grouped each in a single DocumentVersion, depending on the established release process. In case of signals underneath their DocumentVersion a SignalSpecification can be used to define signals underneath it. For usage nodes a UsageNodeSpecification is the right container for them. Prerequisite, however, is the common approval process like for all data in a same DocumentVersion. Specific literals for the attribute DocumentType should be used to mark the DocumentVersion containing either the ‘SignalList’ or the ‘UsageNodeNodeList’.

<DocumentVersion id="id_docu_ver_1">
        <Specification xsi:type="vec:SignalSpecification" id="id_signal_spec_1">
            <Signal id="id_signal_1">
                <Description xsi:type="vec:LocalizedString" id="id_localizedString_1">
            <Signal id="id_signal_2">
                <Description xsi:type="vec:LocalizedString" id="id_localizedString_2">
            <Signal id="id_signal_3">
                <Description xsi:type="vec:LocalizedString" id="id_localizedString_3">

PartVersion for Harnesses

PartVersion for Modules

tutorials/vec/file_structure.txt · Last modified: 2019/11/22 10:31 by 4soft.fehlmann