VEC Implementation Guidelines
The VDA recommendation 4968 “Vehicle Electric Container (VEC)” defines an information model, a data dictionary, and an XML schema derived from and compliant to the model.The intention of the model was to cover a wide range of use cases and application scenarios. For this reason the specification had to be kept generic in some degree and in some aspects. However, for specific scenarios and / or use cases a more detailed description on “how the different pieces fit together” is possible.
To avoid dialects in the different VEC implementations, further guidelines or recommendations are necessary. This collection of implementation guidelines contributes to the unambiguous interpretation of the VEC standard. For various wiring harness definition or electrical system aspects and scenarios the correct instantiation is shown and specific hints for correct usage are given.
Contributing and Proposals
If you find any bugs in the implementation guidelines or if you have a request for a specific topic, or if you would like to contribute your own tutorials please drop us an issue on the PROSTEP JIRA. If you don’t have an account there yet, see here for the procedure to get one.
Latest ChangesThe following table contains lately changed pages, sorted descending by last change.
|Title||Latest Content Addition / Commit||Created||Changed|
|General Structure of VEC Files & Documents||KBLFRM-996: Integrated Review Comments for the whole page
Latest Commit: KBLFRM-1007: Change Tracking and Modifcation of DocumentVersions
|Expected Behaviour of VEC Interfaces||KBLFRM-946: Added Guideline for Import- / Export-Behaviour
Latest Commit: KBLFRM-1007: Change Tracking and Modifcation of DocumentVersions
|Change Tracking of Document Versions||KBLFRM-1007: Implementation Guideline for Modification-Tracking & Versioning
Latest Commit: KBLFRM-1007: Change Tracking and Modifcation of DocumentVersions
|Composite Parts||KBLFRM-1059: Harness & Configurations in the VEC
Latest Commit: Typo corrected
|VEC Implementation Guidelines||Latest Commit: Published VEC Version 2.0.0||2022-03-09||2022-03-09|
|Electrological Layers||KBLFRM-1134: Added overview for electrological layers
Latest Commit: Review disclaimer removed
|Usage Nodes||KBLFRM-790: Added examples for the use of sub usage nodes
Latest Commit: Review disclaimer removed
|Accessories||KBLFRM-1095: Added examples for the interpretation of the ReferenceElement association in case of multiple ReferenceElements
Latest Commit: Review disclaimer removed
|Wires||KBLFRM-953: Complete restructuring of the guideline according to comments in the review of KBLFRM-953. Clarification of the guideline for layering of wire elements in multicore. Integration of additional samples.
Latest Commit: Review disclaimer removed
|Tailoring Mechanisms||KBLFRM-1057: Included Tailoring Concept for custom XSD 1.1 Assertions
Latest Commit: KBLFRM-1057: Include ARENA2036 Dataprofile Assertions Concept
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):
- 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).
- 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.
On the root level, a VEC contains mainly PartVersions and DocumentVersions and some other unversioned (and constant) information, e.g. the definition of the Units used within the VEC. This is illustrated in figure Basic Structure.
One of the core concepts of the VEC is, that there is no restriction for the type of information that can be contained in a DocumentVersion nor the valid combinations of different types of information that can be contained together. This enables the DocumentVersion to reflect the actual circumstances of the domain or process and thus represents an actual technical document with a corresponding release and versioning.
Reasonable combinations of information are driven by the use cases (with process specific variations). The description of some common use case is part of this guideline.
A document can contain any number of Specifications. The Specifications represent the information modules of the VEC and each defines a certain type or aspect of information. The Specifications in a document can be thought of like drawers, where each drawer contains a specific aspect of the vehicle network. A distinction can be made here between:
- General specifications, that are for example required for the provision of basic information or for information reuse (e.g. an InsulationSpecification), and
- PartOrUsageRelatedSpecifications that are specifically used to describe / specify the properties of one or many PartVersions.
Parts and Documents
One of the most fundamental concepts of the VEC is the separation of a part / component from its definition (specification). In this, the PartOrUsageRelatedSpecification plays a major role.
In the VEC a part (PartVersion) does not contain any information about the part, except its PDM Information (PartNumber, PartVersion, …). All the information about the technical properties of a part is expressed by a subclass of PartOrUsageRelatedSpecifications (e.g. a WireSpecification). The PartOrUsageRelatedSpecification is contained in a DocumentVersion. As mentioned above, the distribution of these specifications into different documents is driven by the process / domain (see object diagram Parts and Documents).
This approach enables the VEC to address for example the following scenarios properly:
- The description of a part is changed, but the part itself is not changed (rereleased). This can happen for example if the actual technical properties of the part stay the same, but the description is extended or corrected. In this case, a new version of the document is created. However, the PartVersion stays the same.
- A document and the contained specifications are describing more than one part (e.g. a drawing for a certain class/family of terminals, seals & plugs). In this case it can happen that the document and the specifications are changed, but not all of the described parts have to be changed (rereleased). E
Usages of the DocumentVersion
As mentioned in the introduction, the DocumentVersions VEC can be used in different ways:
- Plain PDM reference (a.k.a as external reference): In this case, the
DocumentVersion in the VEC only contains meta-data and no
payload-data (no Specifications). There different
possibilities to resolve the original document that is referenced by the
- 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.
- FileName: If the document is packaged together with VEC (VEC Package) the filename attribute of DocumentVersion can point to location within the package.
- Location: Can point to a location (via a URN or URL) where the document can be resolved.
- Digital Representation of an external Document: There are use cases where existing documents can represented in the means of the VEC. In other words the VEC DocumentVersion is a digital representation of the original document. For example, the information of a component data sheet (as PDF) might be also represented in VEC in a digitally evaluable way (PartOrUsageRelatedSpecification). In this case the same mechanisms like for the plain PDM reference can be used, plus payload-data in DocumentVersion.
- Native VEC Documents: The VEC DocumentVersion itself is the source of information. This case is quite similar to the digital representation scenario. However, external links (if defined) will resolve to the VEC file itself.
Combination and Reuse of Documents
Typically, information is flowing through the process. It is created somewhere, passed on to someone else and is used there to create other information blocks. To make these information flows traceable each piece of information must be identifiable and must have a change indicator. In the VEC this is done by the DocumentVersion. In order to preserve this traceability along the process, the assignment of information pieces to its original DocumentVersion shall remain unchanged.
An illustrative example for this, is the distribution and use of component master data (compare figure on the right). As described in “Partitioning and Sizing of VEC Files” component master data is best provided with one VEC per component, containing at least one DocumentVersion with the component’s specifications (VEC A, B, C).
If a wiring harness is created with these components, the component master data (at least a portion of it) is required in the data set of the harness (VEC NEW). However, the information is not integrated into the DocumentVersion of the harness (DocumentVersion NEW), as this would lead to a loss of traceability, even if the structures of the VEC would allow such an approach. Instead, copies of the DocumentVersions containing the component’s part master data are placed beside the DocumentVersion of the harness, within the same VEC.
Types of Documents
The DocumentType is an OpenEnumeration that defines some document types that are common in the harness development process. The following sections describe typical content that can be expected in the DocumentVersions of a specific type.
A part master document describes the properties of a component or a group of components (a PartVersion or a set of PartVersion). It contains some general purpose specifications that provide information for any component type. Those specifications are not mandatory and only necessary if the corresponding information aspect is relevant and can be provided. Examples are:
- GeneralTechnicalPartSpecification for common properties like weight or material.
- PlaceableElementSpecification for components that have a position in the topology.
- LocalGeometrySpecification for information about the component’s geometry model, e.g. the bounding box, transformations, segment connection points.
Besides these general specifications a part master document contains a PartOrUsageRelatedSpecification corresonding to the PrimaryPartType (a ConnectorHousingSpecification in the illustration). That Specification provides the component type specific properties. If the component has a secondary component characteristics, more than one PartOrUsageRelatedSpecification can be contained.
Additionally, the document could contain auxillary specifications that are required for the complete component description (the CavitySpecification and SlotSpecification in the illustration). The emphasis here is on “could”, as this is a common case, but a process-specific interpretation. If for example the cavity system is described and released together with the connector (in the same document), it makes sense that the corresponding specification is included in the same DocumentVersion. If the cavity system is defined and released independently, i.e. in a separate document, and used by multiple connectors, it would be appropriate to place it in its own DocumentVersion and reuse the information in the document of the connector (see Reuse of Documents).
Master Data Definition
In contrast to PartMaster documents MasterDataDefintions are not related to a specific component or a set of components (equivalent to part, part number, etc.). MasterDataDefintions are predefined standard information pieces in the process declared by some central organizational unit.
It is a common approach to manage certain information centrally and distribute it in the development processes. The definition of this information is usually independent of specific development projects and ensures the adherence to certain conventions and guidelines across (all) development projects. The component master data is a very specific aspect of this information as it always refers to a component (with a part number). In addition, there is a wide range of other information that is not directly related to a specific component but is nevertheless managed centrally.
Such DocumentVersions with central definition, that are not related to specific PartVersion are summarized under the DocumentType MasterDataDefinition. Examples for such centrally distributed informations are:
- Usage Node Lists (UsageNodeSpecification),
- Signal Catalogs (SignalSpecification), or
- Standardized Base Specifications (e.g. CavitySpecification, InsulationSpecification)
Extension of Master Data Definitions
A VEC that requires master data definitions of a specific type (e.g. signals, usage nodes) can obtain these from different sources (e.g. seperate signal catalogues for power & information). A special use case of this is the addition / extension of a master data definition with individual information in a specific development artifact.
Example: New signals might be required in the system schematic of a new series that are not (yet) included in the master data definition. These additions could be contained in a local signal catalog of system schematic, while the central master data catalog is used for the other signals. When the development process has progressed, these local definitions might be included in the master data definition.
The following bulletins illustrate some examples of different, process specific consistency relationships. The examples are from the context of the above mentioned “signal catalogues”.
- Different Sources for separate domains (e.g. power signals vs. information signals): In this case, there should be no overlaps between the defined entities.
- Local / project specific definitions vs. global definitions: In this case it depends on the degree of freedom allow for project specific definition. Or, viewed from the other direction, on the binding nature of the global definitions. This determines whether only new information may be added or whether existing elements may be overwritten with other information.
In any case, the order of precedence has to be defined for the different sources. However, this is mainly an issue for the business logic of an authoring use case (which elements can be defined or selected by the user in a certain context). In the data exchange use of the VEC, the elements from the different sources are explicitly referenced. So at any time it is unambiguously defined which elements have been used / selected, even though the rules why an element took precedence over another are not contained in the VEC (compare figure Master Data Extension)
As described in detail in the Implementation Guideline “General Structure / Usages of the DocumentVersion” one use case of the DocumentVersion is to serve as a payload data container within the VEC, either for the digital representation of an external document or for native digital data. This Implementation Guide is about the possibilities to track changes and modifications of this payload data within the VEC. Be sure to read Parts and Documents before, as it contains important information about this topic.
Aligned with established PDM practice, the data in the VEC is organized in DocumentVersions. A fundamental principle in the VEC is, that a specific DocumentVersion is unambiguously identified by CompanyName, DocumentNumber and Version. However, this identification and versioning is primarily of a process-oriented rather than a technical nature. From a data oriented technical point of view, you can have different digital representations of the same source document in the VEC (e.g. if the same document specifies multiple parts and you want to create one VEC file per part, or if you need different levels of detail in the data for different scenarios). This is perfectly valid, as long as the overlapping content areas do not contradict each other (see Figure 1 on the right side). In such scenarios the identifying attributes, in particular also the Version will be same since the source document has not changed, although the digital representation is different.
Figure 2 below illustrates this in more a more detailed example. Let us assume, there is a technical drawing or data sheet of a component. This is the original source of information, with all PDM information like formal approvals etc. This document therefore defines the CompanyName, DocumentNumber and Version. The content of the document is then transferred into an IT-System (e.g. a component database) either by automatic import or by manual input (marked with (1)). A digital representation is created.
From this system the data can exported / provided in two flavours, one for internal use with more information and one for external use with less information (marked with (2) and (3)). Another two digital representations are created. In the next step, the provided component data might be used in another system to create a harness definition and a portion of the component data is embedded into the harness definition (marked with (4)). Yet another digital representation is created.
There are any number of conceivable ways in which a digital representation of information can change without the original document changing:
- A mistake during in the manual input in step (1) or a bug in the importer.
- A feature update of the system storing the data, allowing more information to be stored.
- Changes to the export component
In order to allow the content of DocumentVersion in the VEC to be marked as changed, without having the source document changed, the DigitalRepresentationIndex was introduced. If the DigitalRepresentationIndex has changed, the content of the DocumentVersion must be checked for changes, otherwise the content can be assumed unchanged (see Parts and Documents for a definition of “unchanged”).
Details of the Application of the DigitalRepresentationIndex
When to Use
The DigitalRepresentationIndex is an optional feature of the VEC that softens the requirements for the change semantic of CompanyName, DocumentNumber and Version in cases where the content of a DocumentVersion changes, without being able to at least adjust the Version-attribute.
When to Modify
If the DigitalRepresentationIndex has not changed between two VEC files, this can be taken by a reading system as an assurance that the payload content is unchanged. The DigitalRepresentationIndex shall be different, whenever the payload content of a DocumentVersion is different. If a clear statement is not possible, a change is to be assumed in case of doubt. A change of the DigitalRepresentationIndex is necessary for example in the following cases:
- A different digital representation is created due to a changed tool behavior or a changed export interface (see figure on the right ), e.g. more information, bug fixes, new features.
- The content in the source system has changed, e.g. improved data management in the process, correction of typos.
- Different views with different level of details of the same data set, e.g. export for internal and external use.
How to Create
The VEC does not define any specifications for the construction of the DigitalRepresentationIndex (e.g. syntax, order). The only requirement is, that two values can be checked of equality. If the values are equal, the payload data can be assumed unchanged, if the values are different, the payload data might be different as well.
It is up to the discretion and capabilities of the generating system to define a suitable and possible algorithm to generate the index. However, it should always be taken into account that an unnecessary change indication creates needless overhead on the side of the reading systems.
Possible approaches include:
- An internal change tracking index of the creating system (e.g. revision number)
- A checksum created over the relevant payload data
- A timestamp, either of the last change in the creating system or the time of the VEC creation.
- A UUID identifying a specific digital representation. Each time a new digital representation is created a new UUID is generated.
Expected Behaviour of VEC Interfaces
A wide range of different systems, supporting different use cases, are used in the process of wiring harness development. All of them might have a VEC-Interface for input & output, so sooner or later the question arises “What are the expectations for the behavior of those interfaces?”. This section will discuss this question.
In a document based data exchange scenario (e.g. working with a word processor) the intuitive expectation is, that a document (file) is “opened”, changes are preformed by the user and then, the document is “saved” again, with the document containing the original content plus the modifications.
However, this simple and intuitive approach is not feasible in a model based data exchange scenario like the one for the VEC. The VEC is not intended to be a file-based database that contains all information about a vehicle network, which grows continuously over the time (like a Word or ODT file of a book). The basic idea of the VEC is, to provide a consistent language (model) for data exchange in the process of wiring harness development and to allow the exchange of use case specific slices of information within the process between systems and organizations.
This fundamental concept means that there is no such thing as “the one VEC interface”. The important question is, which use cases (or slices) of the VEC data model are supported or required for a specific interface.
Let’s assume that in our system landscape one component is responsible for the synthesis of electrology and geometry, and the derivation of a wiring harness from it. Such a system would potentially have 4 interfaces requiring different sections of the VEC model:
- Topology (IN)
- System or Wiring Schematic (IN)
- Part Master / Component Data (IN)
- Harness Definition (OUT)
In addition, the scope and validity of the different information slices may vary. For example, component data could be updated daily, with only the changed components at a time, but with a global validity, while a wiring harness definition is only valid for a specific vehicle context.
Even when considering only these examples, it is already obvious that it does not make any sense to formulate requirements on cross-relationships between imported and generated VEC data, like “a system has to be able write all VEC data it has imported in an unchanged matter”.
Content of a VEC
A VEC can contain any scope, amount and combination of information that is valid, with respect to the VEC Model and the Implementation Guidelines. There shall be no requirement to create VECs with restricted content specifically for importing / receiving systems.
A receiving system shall be able to accept any valid VEC. If the VEC contains more than the required information of the system, the system is free to ignore the pieces of information irrelevant for its purpose. It does not have to store the ignored pieces for a later reexport. However, it shall not refuse the import of a VEC because of “too much” information.
On the other hand, it is up to the system to verify that a VEC contains enough information for the use case of the system. If that is not the case, the system can reject the import because of “too little” information.
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”
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>
The object diagram above illustrates the VEC representation of the following value:
$$105.23 \ \Omega /km \pm 20.0$$
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>
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>
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.
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>
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>
Motivation and Objective
The VEC provides a comprehensive model for the digital description of a wide variety of information and their relationships to each other in the context of the electrical system development process. Despite the striving for the greatest possible semantic precision, the demand for general applicability of the standard means that, at various points restrictions cannot be formulated to the same extent as it would be possible in the context of a very specific use case or a company context. This applies to the following examples, among others:
- The set of valid model elements: Probably no use case requires all 450+ classes of the VEC at the same time and the set of required model elements is highly dependant from the use case itself.
- Valid values for attributes: The allowed patterns and / or discrete values (enumerations) of attributes can depend on a specific use case or company context and can even change over time (e.g. new technologies)
- The balance between mandatory and optional information: The amount and completeness of information contained in a VEC depends on the use case and process. While it might perfectly ok the have some missing information in an early phase of the process, it might intolerable at a later stage.
This implementation guideline presents three approaches for adapting the model to address the above issues in specific application scenarios, while still maintaining compatibility with the standard:
- Custom Open Enumerations: New literals can be added to open enumerations (see Open and Closed Enumerations)
- XSD 1.1. Assertions: The schema can be enriched with assertions to be more restrictive.
- Schema Filtering: With “Schema Filtering” the schema can be made less extensive and by this also more restrictive (Less allowed classes, attributes etc.).
All these approaches have in common, that the schema of the standard is adapted / modified in a suitable form. The result is a tailored “VEC” schema that is specific for the use case, but still compatible with the regular VEC schema.
This Implementation Guideline explains how these modifications can be achieved in an efficient way based on XSLT. XSLT is a useful technology, when:
- you want to modify XML data,
- you can define the modification based on rules,
- the general structure of your result is close to the input,
- and performance is not critical.
This makes it the perfect solution for this use case, where we want to modify the XML Schema of the VEC at very specific locations while keeping the rest unchanged.
The general concept is illustrated in the figure above. The customization rules are defined in an “compiler
XSL-file”. This file defines how the extensions are made in the schema syntactically. It compiles the customizations into an existing schema. For example, in case of open enumerations, the compiler file defines at which position in
XSD new literals are to be inserted. The compiler files are universal and independent of the specific context (e.g. company, use case) of the customization. For open enumerations and assertions such compiler files are provided here.
The actual customizations are defined in an external
XML data file (Customization Definition in the figure above). For example, in case of open enumerations, the data file defines which enumerations should be extended with which literals. This information is specific to the customization context and has to be created by oneself during the customization process. The syntax of the data file depends on the compiler file, but is usually trivial.
To create a custom VEC schema, the desired schema variant (strict or not) of the underlying VEC version is passed into a XSLT transformation pipeline, with the Compiler XSL as transformation. The data file is side loaded from the Compiler XSL.
Run the Transformation
java -cp /path/to/saxon.jar net.sf.saxon.Transform \ -xsl:./path/to/compiler.xsl -s:/path/to/vec.xsd -o:/path/to/result.xsd data-file=url-to-data-file.xml
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 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 extend1 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:
- The Compiler XSL: vec-open-enum-compiler.xsl
- A definition of your enumeration extensions, an example can be found here: enum-literals.xml
Define new Enumerations
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
WireReceptionType with a description (Note that it is possible to include
tags) and a literal without a description named
MyExampleLiteral2. It also
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).
XSD 1.1 introduced a concept to define Assertions within a
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
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.
descendantnodes (see XPath Axes) of the context node can be used in the XPath expression. Functions like
idref()are not available.
What you need
The generation of such an asserted schema is done as described in section General Concept. As input, you need:
- The Compiler XSL: vec-assertions-compiler.xsl
- A definition your custom assertions, an example can be found here: data-profile.xml
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
<?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> ...
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
(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]" /> ...
IDREF attributes cannot be handled in this fashion
automatically, but have to be checked manually. The figure on the right side
occurrenceOrUsage association between
OccurrenceOrUsage. Associations are translated into
IDREFS in the XML Schema, in contrast to aggregations that are translated into
Mapping of the VEC Model to XML schema definition (XSD)).
The XML Schema representation of the association is the following:
<xs:complexType name="OccurrenceOrUsageViewItem2D"> <xs:complexContent> <xs:extension base="vec:ExtendableElement"> <xs:sequence> ... <xs:element name="OccurrenceOrUsage" type="xs:IDREFS" minOccurs="0"/> ... </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>
That means a filtering rule cannot be formulated based on the target type of the association, as this type unknown in the XSD (in contrast to contained elements). Therefore a filtering rule must be more specific by explicitly addressing each relevant association, like this:
... <xsl:template match="xs:element[@name='OccurrenceOrUsage' and ancestor::xs:complexType[@name='OccurrenceOrUsageViewItem2D']]" /> ...
Note: Make sure that the resulting schema remains compatible with the standard (XML Schema and Model Specification):
- Do not remove elements that are mandatory!
- Take extra care of usages via
IDREFassociations. These have to be checked in the model since the XML Schema is typeless for those associations.
Extension of open enumerations is perfectly valid as long as you adhere to the rules mentioned in the recommendation. ↩︎
All information actually defined in a VEC file is contained in a DocumentVersion. Additionally this DocumentVersion carries all the meta-information about the underlying document (e.g. for a system schematic), This information is normally shown in drawings as a title block.
The DocumentVersion contains the information about the unique naming, a multilingual description, the DocumentNumber and so on. It has subelements to define the change history (ChangeDescription), the creation and the different approvals.
Information from the Title Block in VEC - according to ISO 7200
The title block in drawings contains information which identifies the shown construction and documents the authorship and the responsibility. In addition to that, further information can be shown in this title block e.g. for used IT systems. General requirements for data fields in the title block are regulated in the standard ISO 7200. Due to the fact that the VEC supports the modelling of drawing contents, these requirements can also be stored in the VEC.
The ISO requirements are shown in the tables below and in the last column the mapping to the VEC model can be found.
Identifying data fields in the title block
|Field name (from ISO 7200)||Obligation||Description||Mapping to VEC|
|Legal owner||M||The name of the legal owner of the document, e.g. firm, company, enterprise. It could be the official owner’s name, an abridged trade name or a logotype for the presentation.||DocumentVersion.CompanyName|
|Identification number||M||The document identification number is used as the reference to the document. The identification number shall be unique — at least within the organization of the legal owner.||DocumentVersion.DocumentNumber|
|Revision index||O||The revision index identifies the revision status of the document. Different versions are numbered in consecutive order by means of, e.g. a letter or letter combination A to Z, then AA, AB, AC … or Figures 1, 2,3 … The letters I and O should be avoided because they are easily confused with the digits 1 and 0. Alternatively, the date of issue field only may be used.||DocumentVersion.DocumentVersion|
|Date of issue||M||The date of issue is the date on which the document is officially released for the first time, and that of every subsequent released version. It is when the document is made available for its intended use. The date of issue is important for legal reasons, e.g. patent rights, traceability.||DocumentVersion.Creation.CreationDate|
|Segment/sheet number||M||The segment/sheet number identifies the segment or sheet.||DocumentVersion.SheetOrChapter.SheetNumber|
|Number of segments/sheets||O||This is the total number of segments or sheets of which the document consists.||DocumentVersion.NumberOfSheets|
|Language code||O||The language code is used to indicate the language in which the language-dependent parts of the document are presented.||Not needed – each field value will be represented by a ‘LocalizedString’ or ‘LocalizedTypedString’|
Descriptive data fields in the title block
|Field name (from ISO 7200)||Obligation||Description||Mapping to VEC|
|Title||M||The title refers to the content of the document.||LocalizedTypedString with the type ‚Title‘ in DocumentVersion.Description (see below)|
|Supplementary title||O||The supplementary title field may be used to give further information on the object, when needed||LocalizedTypedString with the type ‚SupplementaryTitle ‘ in DocumentVersion.Description (see below)|
All Attributes in the VEC with the type AbstractLocalizedString can be realized either with an instance from the class LocalizedString or LocalizedTypedString. While the LocalizedString must be used just once for each attribute and language code the LocalizedTypedString must be used once for each attribute and language code AND each type. The OpenEnumertation LocalizedTypedStringType enables the possibility to place e.g. the title and the supplementary title for e.g. ‘En’ in the description mapping.
Administrative data fields in the title block
|Field name (from ISO 7200)||Obligation||Description||Mapping to VEC|
|Responsible department||O||The name or code for the organizational unit responsible for the contents and maintenance of the document at the date of release.||DocumentVersion.Creation –> ResponsibleDesigner.Department|
|Technical reference||O||The name of the person having sufficient knowledge of the technical contents of the document to be named as the contact person and who will answer, coordinate and act on queries.||DocumentVersion.Creation –> ResponsibleDesigner.Lastname|
|Approval person||M||The name of the person who approved the document. The document might have been checked by a number of different specialists in accordance with the local rules for that type of document, specific project etc. The names of such specialists may be indicated in the title block or in a separate document part.||DocumentVersion.Approval –> Permission.Permitter.LastName \ \ If a different number of different specialists have checked the document, an instance of Approval each can be used and the attribute levelOfApproval names the effective scope|
|Creator||M||The creator or person who has prepared or revised the document.||DocumentVersion.Creation.Creator.LastName|
|Document type||M||The document type field indicates the role of the document with respect to its content of information and representation format.||DocumentVersion.DocumentType|
|Classification/key words||O||The text or code to categorize the contents of the document used for retrieval.|
|Document status||O||The document status indicates where the document is in its life cycle. The status is indicated by means of terms such as “In preparation”, “Under approval”, “Released” and “Withdrawn”.||DocumentVersion.Approval.Status|
|Page number||O||The page number is usually generated by the presentation system.||DocumentVersion.SheetOrChapter.SheetNumber|
|Number of pages||O||The number of pages is dependent on the presentation format used, e.g. text font, paper size and character size.||DocumentVersion.NumberOfSheets|
|Paper size||O||The size of the form for the original document, e.g. A4.||DocumentVersion.SheetOrChapter.SheetFormat|
This example demonstrates how chronological relationships between PartVersion can be established. The VEC offers two types of relationships:
- Derivation: Derivation means that the successor of the relationship is a newly developed part (variant) based on an existing part.
- Sequence: Sequence means that the successor is a replacement for the predecessor.
The VEC offers three layer, each representing a level of abstraction for describing electrologic. This is illustrated in the diagram on the right side (Figure 1).
The Architectural Layer defines the connectivity / communication links (see Net) between components, without making any specifications regarding the physical realization. For example, this layer can be used to define which Bus technologies used by E/E components and the network topology to communicate with each other. To describe this layer in the VEC, the NetSpecification and its subelements are used.
The System Schematic Layer is more detailed than the Architectural Layer. The electrological realization of the Nets from the Architectural Layer are defined. Nets from Architectural Layer are realized by Connections. A connection has a defined electrical potential (see Signal). For example a “Body CAN Bus”, represented by a single Net in the Architectural Layer, has the two electrical potentials, “Body CAN High” and “Body CAN Low”. In the System Schematic Layer those are represented by two individual Connections.
However, the System Schematic Layer does not define a specific physical realization of the connectivity. A Connection with three ends (like in the diagram on the right) could be realized in many ways (e.g. a splice, a distribution component (star link), a double crimp, an IDC connection, …). To describe this layer in the VEC, the ConnectionSpecification and its subelements are used.
The Wiring Layer specifies a concrete physical realization of the layers above and narrows their degrees of freedom. It is getting more concrete (e.g. it defines the realization of the connection with three ends from the diagram on the right by a splice). Typically the Wiring Layer contains information such as wire colors, cross section areas, conductor and plating materials.
Due to its similarity, the Wiring Layer uses the same basic model elements as the definition of concrete harness. However, the flexibility of the VEC model allows the Wiring Layer to leave aspects unspecified. For example, by using PartUsages instead of PartOccurrences, partial WireSpecifications can be used instead of concrete PartVersions to describe the wiring. This makes it possible, for example, to define wire cross-sections and colors without having to specify insulation materials.
Many processes define documents that are similar to this layered structure in terms of their content, but do not correspond to it one hundred percent. This means, for example, that a process document “System Schematic” might contain many aspects of the VEC layer “System Schematic”, but can also define additional information from the VEC Layer “Wiring”.
This is perfectly valid and an intended feature of the VEC.
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>
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.
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.
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>
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).
isExternalEnd. This is due to the fact that the end, that is connected to the port of the parent node, is on the inside (
isExternal=falsefrom the perspective of the port), the end that is connected to the inner node, is on the outside (
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.
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:
- The description and instantiation of parts (e.g. connectors, wires, terminals).
- The contacting (marked with green dashed lines). It defines the relationship between terminals, wire ends and cavities.
- The coupling (marked with red dashed lines). This is for connecting connectors with E/E components or with each other, or even to connect E/E components with each other.
Description and Instantiation of Parts
In contrast to the Network Architecture and the System Schematic the Wiring Layer does not define its own level of abstraction, instead it utilizes the existing modeling concepts in the VEC to describe the physical properties of the electrologically relevant components.
It is possible to use concrete PartVersions in the Wiring Layer, but typically not all relevant properties are defined in the Wiring Layer, so mainly PartUsages will be used (detailed description can be found here).
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.
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.
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.
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.
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.
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.
In the VEC the coupling / mating can be used to connect the harness side to another harness (in the case of an inliner) or to an ECU. The figure above shows a simplified example of the connection between an ECU (highlighted in orange) and a wiring connection (highlighted in blue). The MatingPoint simply connects the two TerminalRoles on each side. This method is used for example in a wiring definition, where the concrete connector is not yet known.
For this reason this example omits the geometric aspects of a coupling (connector housing, slots, cavities).
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>
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 harness1.
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.
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.
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
Like with any self-contained piece of information in the VEC, for traceability reasons the definition of a _coupling device should be in the correct DocumentVersion. Section General Structure explains the general concept of DocumentVersion and their containments. As described there, the containment of Specifications in their DocumentVersions has a semantic meaning. The correct placement of a coupling device in a containing DocumentVersion is a perfect example for that.
Depending on the engineering process, system schematic relevant coupling device might be defined in some kind of master data process, enforcing standardized coupling devices for a specific scope. In that case, one or more of those standardized coupling devices would be managed and published together, and then reused in a specific system schematic. This is illustrated in the figure “Information Structure” below, on the left side of the figure.
On the other, it would also be perfectly valid to have no company wide management process for coupling devices. In this case, the coupling devices would be defined implicitly within a system schematic. This is illustrated on the right side of the figure.
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>
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>
Component Description & Instantiation (Basics)
Specification of Parts
Many of the classes in the VEC are used for the defintion of the general properties of a component (Part Master Data). This is done with specifications (VEC Naming Convention “XXXSpecification”). A specification defines all properties of a component that are that are independant of a specific usage of the component (e.g. the number of cavities of connector or the cross section area of a wire). The type of the component, and thereby the available properties, is defined by the classification of the specification (e.g. ConnectorHousingSpecification for a connector housing). The PDM Information of a component (e.g. the part number) is defined by a PartVersion.
Since a component can have properties of different classifications (e.g. a connector can also have properties of a fixing) it is possible in the VEC to define multiple different specifications for a single part. The attribute “primaryPartType” defines which the primary character of the component is.
Instantiation of Parts
If a component should be used in the VEC it must be instantiated. This can be done in two ways. The first way is used if a concrete part number is known. The second way is used if a part number is unknown and only requirements for a component should be defined.
The first case is illustrated in this diagram and is quite similar to the way how components have been used in the KBL. The part is identified by a PartVersion with a PartNumber, Version and the issuing Company. The general properties of the component are defined by a specification (a FixingSpecification in the example). The use of the component is expressed by a PartOccurrence. All usage specific properties of component (e.g. the length of a wire) are defined by a Role. The used role must correspond to a specification. The VEC Naming Convention is XXXRole corresponds to XXXSpecification.
In object oriented terms, one can say the PartVersion and Specification are defining the type (or classification) of a component, the PartOccurrence and the Role are defining the instance of a component.
Instantiation of Specifications without Part Number
As mentioned in the example before, there are use cases where it is necessary to define properties of component (instance), without having a concrete part number. This is quite common for example in the electrological design, where for example the cross section area of a wire is specified, but the colouring of the wire is not yet known. In these cases the requirements for component have to be defined without having a concrete PartVersion.
For these cases, the VEC offers the concept of PartUsages. A PartUsage behaves like a PartOccurrence (it has instance specific attributes and can define Roles), but it is not necessary to reference a PartVersion. Instead it is possible to directly reference the needed specifications, which represent the requirements on the concrete component, selected later in the process.
This Implementation Guideline covers the various aspects of a correct wire representation in the VEC for different scenarios and variants of wires. It covers both multi cores and single cores.
The VEC contains model elements for the representation of wires which would not be strictly necessary for the exclusive representation of single core wires. However, single core wire elements with the same specification can occur in both, single and multi-core wires. In order to achieve a consistent representation of all cases in the model and in order to allow the reuse of data elements, a uniform modelling approach was chosen for single and multicore wires. At the first glance, this may seem unnecessarily complicated in the case of single core wires, but it simplifies the mapping of wires in the VEC on the long run, when all kinds of wires and not only single-cores have to be supported.
Specifying the Elements of a Wire
In the world of the VEC, a wire is a hierarchical structure of wire elements. A wire element can be any node in the hierarchy that has to be addressed individually for the definition of specific properties. A wire element can be manifested either by physical material (e.g. a core, an insulation, a shield) or by the logical necessity for the definition of certain product properties during the production process (e.g. a grouping for twisted pairs).
The properties of wire elements are defined with a WireElementSpecification (see the figure below).
The WireElementSpecification is a generic node in the hierarchical structure of a wire. The hierarchy represents the real structure of wire from the outside to inside. For example, if an insulation is placed around two cores, the cores are sub elements of the insulation. Subordinated elements in the structure are defined by referencing subWireElementSpecifications. The actual technical properties of a wire element are defined by referencing a corresponding auxiliary specifications. For example (see the Diagram Wire in the recommendation for a complete list):
- InsulationSpecification if the wire element has insulation properties, or
- ConductorSpecification if the wire element has conducting properties.
In reality, a specified wire element can be used in different contexts. For example, a white single core can be used as individual single core wire or as part of several different multi core wires. It can even be used multiple times as part of the same multi core (compare CAT7 twisted pair cables that might contain up to 4 similar white cores). To represent this fact, the WireElementSpecification itself is also designed to be reusable.
From the individual Elements to a whole Wire
From a part master data perspective, the WireElementSpecification is sufficient to describe a wire with all its aspects, when navigating from the root wire element to its leaves. However, the ability to reuse WireElementSpecifications comes with draw back:
Referencing a WireElementSpecification does not unambiguously define the context of its usage.
The following figure shall illustrate this. The red lines are hypothetical associations for the demonstration of the problem. In the VEC those associations do not exist, because of the described problem the actual model is different.
When navigating from a part master data perspective (e.g. PartVersion A → Composite-Wire B → White-Core) the context is unambiguously defined by the navigation path. However, when referencing such wire element from somewhere else in the model, indicated with the RoutedWire rectangle, the context is not defined unambiguously. It is not clear to which white core the association from the RoutedWire refers to, indicated by the red lines.
To solve this dilemma, the VEC introduced the WireSpecification and the WireElement. The WireSpecification is the PartOrUsageRelatedSpecification of a wire and the mandatory root of any wire (element) that can be used as an individual component. It references the root WireElement and the root WireElementSpecification.
The WireElement is the context specific handle of a WireElementSpecification in a specific WireSpecification (primarily needed for multi cores, but due to a consistent modelling approach also mandatory for single cores). The WireElements are used as a target for references.
The redundant replication of the wire hierarchy within the WireElements is necessary, because without this hierarchy wires with multiple occurrences of the same WireElementSpecification within the wire could not be represented consistently (see KBLFRM-949 ).
Definition of a Single Core
The figure above illustrates the representation of a single core wire in the VEC. The WireSpecification is the PartOrUsageRelatedSpecification describing a PartVersion. Each WireSpecification has a single root WireElementSpecification that defines the actual properties and the structure of the wire, and a single root WireElement that serves as the context specific handle of the WireElementSpecification (see above).
In theory, there are two possible representations for single cores in the VEC (see the figure below). A minimal representation, where the single core is represented by one wire element with conducting and insulating properties at the same time, and a more extensive one, where the single core is represented by two hierarchical wire elements, one for the insulation and one for the actual core.
Definition of a Multicore Wire
The figure on the right illustrates a “simple” multicore wire, that will serve as an example for the following sections. It consists of two single cores of different colouring that form a twisted pair: “A”, a green one and “B” a blue one. Around the twisted pair is a shielding (braiding or foil) and an outer insulation (sheath).
The figure below displays the structural representation of the example in the terms of the VEC. On the left side is the WireSpecification with its contained WireElement.s To emphasis the hierarchical containment of the WireElements, which can also be found in the XML structure, they are represented with nested boxes. On the right side are the WireElementSpecification. Corresponding WireElements and WireElementSpecifications are highlighted in the same colours. The technical properties of the WireElementSpecification are defined in the referenced auxiliary specifications.
Notable things in this example:
- The specification of the smallest elements of the multicore, the single cores (one outlined in red), is similar to the specification of an individual single core. It could even be the same WireElementSpecification.
- Since the only difference between Core “A” & “B” is the different insulation colouring, they share the same CoreSpecification.
- The different layers around the two cores (twisting, shielding, insulation) are represented by individual WireElement / WireElementSpecification. This is in contrast to the single core where insulation and conductor are represented by a single WireElement / WireElementSpecification.
The last point requires a somewhat more detailed explanation. Why does the multicore representation differ in this aspect from the single core representation?
As discussed earlier: for single cores a minimized representation shall be used, because otherwise the model gets unnecessarily bloated. However, multicores can be inherently complex (see “Cutaway Diagram…” on the left). Using a minimized representation in multicores for others than the smallest elements ( the single cores) would create wide open space for ambiguous interpretations.
For example, having a WireElementSpecification with a ShieldSpecification and an InsulationSpecification: What is the order of layering? Which one comes first? Another example, a foil shield in combination with a braiding and an insulation. A WireElementSpecification could only carry one ConductorSpecification, so one of the two shieldings get individual wire element, whereas the other one is combined with the insulation. Isn’t that inconsistent? And these are just two problematic cases and many more are conceivable. To avoid this confusion, the following applies for multicores:
Another reason for not using a minimized representations for higher level multicore wire elements is, that most manufacturing processes require the individual identification of the different elements (e.g. shield an insulation) and those are often processed in different manufacturing steps.
The following is a XML listing of the VEC representation of the multicore example illustration. The listing is a schema valid VEC. However, for the sake of the simplicity of the example it just contains the most fundamental properties. The
Identification values for the Specifications are chosen in a way to make the example more readable. In a productive VEC the
Identification-values would be defined in an appropriate way for the creating process.
<?xml version="1.0" encoding="UTF-8"?> <vec:VecContent xmlns:vec="http://www.prostep.org/ecad-if/2011/vec" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="id_0001"> <VecVersion>1.2.0</VecVersion> <DocumentVersion id="id_1"> <CompanyName>ACME Inc.</CompanyName> <DocumentNumber>0815</DocumentNumber> <DocumentType>PartMaster</DocumentType> <DocumentVersion>a</DocumentVersion> <!-- Auxiliary specifications for the multicore --> <Specification id="id_1_1" xsi:type="vec:InsulationSpecification"> <Identification>Orange</Identification> <BaseColor id="id_1_1_0001"> <Key>#FF8000</Key> <ReferenceSystem>RGB</ReferenceSystem> </BaseColor> </Specification> <Specification id="id_1_2" xsi:type="vec:ShieldSpecification"> <Identification>Shielding</Identification> <CrossSectionArea id="id_1_2_0001"> <UnitComponent>id_unit_mm2</UnitComponent> <ValueComponent>1.5</ValueComponent> </CrossSectionArea> </Specification> <Specification id="id_1_3" xsi:type="vec:WireGroupSpecification"> <Identification>Twisting</Identification> <GroupType>Twisted</GroupType> <LengthOfTwist id="id_1_3_0001"> <UnitComponent>id_unit_mm</UnitComponent> <ValueComponent>40</ValueComponent> </LengthOfTwist> </Specification> <!-- Auxiliary specifications for the two single cores --> <Specification id="id_2_1" xsi:type="vec:CoreSpecification"> <Identification>Core</Identification> <CrossSectionArea id="id_2_1_0001"> <UnitComponent>id_unit_mm2</UnitComponent> <ValueComponent>0.35</ValueComponent> </CrossSectionArea> </Specification> <Specification id="id_2_2" xsi:type="vec:InsulationSpecification"> <Identification>Green</Identification> <BaseColor id="id_2_2_0001"> <Key>#00CC00</Key> <ReferenceSystem>RGB</ReferenceSystem> </BaseColor> </Specification> <Specification id="id_3_2" xsi:type="vec:InsulationSpecification"> <Identification>Blue</Identification> <BaseColor id="id_3_2_0001"> <Key>#0050EF</Key> <ReferenceSystem>RGB</ReferenceSystem> </BaseColor> </Specification> <!-- Buttom Up definition of the WireElementSpecification (from single cores to Multicore) --> <Specification id="id_4_1" xsi:type="vec:WireElementSpecification"> <Identification>A</Identification> <ConductorSpecification>id_2_1</ConductorSpecification> <InsulationSpecification>id_2_2</InsulationSpecification> </Specification> <Specification id="id_4_2" xsi:type="vec:WireElementSpecification"> <Identification>B</Identification> <ConductorSpecification>id_2_1</ConductorSpecification> <InsulationSpecification>id_3_2</InsulationSpecification> </Specification> <Specification id="id_4_3" xsi:type="vec:WireElementSpecification"> <Identification>Twisted-Pair</Identification> <SubWireElementSpecification>id_4_1 id_4_2</SubWireElementSpecification> <WireGroupSpecification>id_1_3</WireGroupSpecification> </Specification> <Specification id="id_4_4" xsi:type="vec:WireElementSpecification"> <Identification>Shield</Identification> <ConductorSpecification>id_1_2</ConductorSpecification> <SubWireElementSpecification>id_4_3</SubWireElementSpecification> </Specification> <Specification id="id_4_5" xsi:type="vec:WireElementSpecification"> <Identification>Insulation</Identification> <InsulationSpecification>id_1_1</InsulationSpecification> <SubWireElementSpecification>id_4_4</SubWireElementSpecification> </Specification> <!-- WireSpecification with WireElemnts --> <Specification id="id_5_0" xsi:type="vec:WireSpecification"> <Identification>Multi-Core WireSpecification</Identification> <DescribedPart>id_2</DescribedPart> <WireElementSpecification>id_4_5</WireElementSpecification> <WireElement id="id_5_1"> <Identification>Root</Identification> <WireElementSpecification>id_4_5</WireElementSpecification> <SubWireElement id="id_5_2"> <Identification>Insulation</Identification> <WireElementSpecification>id_4_5</WireElementSpecification> <SubWireElement id="id_5_3"> <Identification>Shield</Identification> <WireElementSpecification>id_4_4</WireElementSpecification> <SubWireElement id="id_5_4"> <Identification>Twisted-Pair</Identification> <WireElementSpecification>id_4_3</WireElementSpecification> <SubWireElement id="id_5_5"> <Identification>A</Identification> <WireElementSpecification>id_4_1</WireElementSpecification> </SubWireElement> <SubWireElement id="id_5_6"> <Identification>B</Identification> <WireElementSpecification>id_4_2</WireElementSpecification> </SubWireElement> </SubWireElement> </SubWireElement> </SubWireElement> </WireElement> </Specification> </DocumentVersion> <PartVersion id="id_2"> <CompanyName>ACME Inc.</CompanyName> <PartNumber>4711</PartNumber> <PartVersion>a</PartVersion> <PrimaryPartType>Wire</PrimaryPartType> </PartVersion> <Unit id="id_unit_mm2" xsi:type="vec:SIUnit"> <Exponent>2</Exponent> <SiUnitName>Metre</SiUnitName> <SiPrefix>Milli</SiPrefix> </Unit> <Unit id="id_unit_mm" xsi:type="vec:SIUnit"> <SiUnitName>Metre</SiUnitName> <SiPrefix>Milli</SiPrefix> </Unit> </vec:VecContent>
Special Cases of Wires
The figure on the left shows two variants of ribbon cables. As can be easily seen, in such a cable the same cores are present several times on the same level of the hierarchy. This is one of the cases referred to in “From the individual Elements to a whole Wire” that require the definition of individual WireElements where the WireElementSpecification alone would not be sufficient.
The figure below displays the structural representation of the example in terms of the VEC.
The illustration represents a five-core ribbon cable. On the left is the WireSpecification with its contained WireElement, on the right side the WireElementSpecifications. The ribbon cable consists of one red core and 4 identical grey cores. Therefore there are only two WireElementSpecifications for the cores, one for the red core and one for all grey cores. To define explicitly that the ribbon cable consists of 5 cores, the Root-WireElementSpecification references the single Grey-Core four times as subWireElementSpecification.
In the WireSpecification there are individual WireElements for each core (Core: 1, 2, 3, 4, 5). Since the VEC does not define the geometric arrangement of subWireElements within a WireElement the four grey cores have to be identified with their respective identification (e.g. 2 - 5).
CAT7 - S/FTP
The figures on the right side illustrate cases of more complex mulitcore wires. For example Category 7 Ethernet cables according to ISO/IEC 11801 2nd Ed. (2002). These consist of a multilayer structure of conductors with insulation, twisting and different shielding.
Remarkable is that each pair of cores consists of a primary coloured core and a primary/white coloured core (e.g. blue and blue/white). However, in reality the primary colour on the primary/white core is often omitted, as it is unambiguously identifiable due to its twisting & shielding together with the primary coloured core in the cable. So the blue/white core is often actually just a plain white core. Therefore, such a multicore cable can consist of four primary coloured cores and 4 identical white coloured cores.
The figure below displays the structural representation of the example in terms of the VEC. In order to achieve a rudimentary clear representation, the auxiliary specifications for the WireElementSpecification have been omitted. For the same reason, the twisted-pairs 3 & 4 have omitted as well.
Again, on the left side is the WireSpecification with its contained WireElement, on the right side the WireElementSpecifications. It is worth noting that the white cores are represented by a single WireElementSpecification, whereas each is represented by an individual WireElements.
This tutorial illustrates the definition / description of modular connectors. A modular connector is a connector that can be recursively assembled, so that certain fields can fitted with different other parts.
In the displayed example the PartVersion “4711” is a modular connector. The ConnectorHousingSpecification defines a regular Slot “A” with a number of cavities and a ModularSlot “B”. This ModularSlot is compatible to two different inserts (defined by individual ConnectorHousingSpecifications). The two PartVersion “4712” & “4713” define these allow inserts.
The diagram shows the instantiation of modular connector (previous example). On the left hand side of the diagram the component description of the modular connector is shown (similar to the previous example). On the right hand side the instancing of such a modular connector is shown.
Both parts of the modular connector (the housing and the insert) have their own PartOccurrence. The ModularSlotReference defines which inserts are actually used in the specific context and references their ConnectorHousingRoles to name the concrete housing instance directly.
Note: As a wiring harness is often described in a 150% scope, it is possible that a ModularSlotReference references more than one ConnectorHousingRole as usedInserts. In these cases the variant management mechanisms have to ensure, that in a concrete case only one insert is used. This can be either done explicitly with PartStructureSpecifications or implicitly with a VariantConfiguration.
Segment Connection Points
The picture above shows an example of connector with multiple segment connection points (sometimes also called bundle postion / connection points). The segment connection points are marked with red circles. Such connectors have multiple entry points for wires, that can be used alternatively or at the simultaniously. The geometric position of the segment connection points is different, that they have to be treated individually, so each segment connection point is accessed via an individual SegmentConnectionPoint
The example shows a connector that has two cavity, that are only reachable through different segment connection points. By associating these SegmentConnectionPoints with corresponding PlacementPoints the SegmentConnectionPoint become ‘placeable’ on nodes in the topology of a harness.
This example shows how add-ons for cavities in a connector could be defined. In this example, the ConnectorHousingSpecification has two different SegmentConnectionPoints. Each of them is defining it’s own CavityAddOn. So depending on the SegmentConnectionPoint used, a Cavity can have for example 50mm as well as 150mm as Add-On.
If a ConnectorHousingSpecification has ModularSlots, the Add-ons are not defined individually for all cavities for all possible inserts, but **only per ModularSlot. The Add-On defined in the ModularSlotAddOn, is the Add-On need to reach the ModularSlot from the corresponding SegmentConnectionPoint. The add-on needed to reach a certain cavity in an used insert, can be obtain from ConnectorHousingSpecification of the used insert.
Wire add-ons caused by cap’s are defined in the ConnectorHousingCapSpecification. The specified value is the add-on required to reach the SegmentConnectionPoint of the ConnectorHousing from the entry point of the cap.
Part Master Definition
Part A being an accessory for Part B means, that if Part B is used somewhere in a harness, then Part A might (or must) be used as well. These can be for example backshells, connector housing locks, clips, cable ties. In the VEC, any part classification can be an accessory to another part. A relation between PartVersion and its accessories can be established with a PartRelation in a GeneralTechnicalPartSpecification
The natural language term “accessory” sums up a vast amount of different part types that are used in a harness, but which are not further specified. Meaning that they are relevant for the bill of material (and some other general properties like weight), but their usage is not defined in detail. If a part has to be used in the VEC, that has no individual specification (like e.g. a ConnectorHousingSpecification) it is marked with the PartVersion.primaryPartType=“Other” and a PartOrUsageRelatedSpecification that can be used to define which type of “accessory” it is (via the attribute PartOrUsageRelatedSpecification.specialPartType). Common part attributes can be defined with a GeneralTechnicalPartSpecification.
The following table shows examples for the usage of a PartRelation and the corresponding semantic meanings.
|The part A has to be used exactly 3 times or exactly 6 times.||3 x A ; 6 x A|
|The part B has to be used exactly 0 times or exactly 2 times.||0 x B ; 2 x B|
|The part C has to be used exactly 3 times.||3 x C|
|The part C has to be used exactly 3 times. This is semantically equivalent with example #3.||3 x C|
|The parts D & E & F have to be used exactly 1 times or 0 times.||0..1 x (D,E,F)|
|The part G have to be used exactly 0 times or 2, 3, 5 times.||(0,2,3,5) x G|
|The part K have to be used between 3 and 6 times.||3..6 x K|
As described in the previous section, definitions can be made the part master data which accessories are required in which combination for a component. In the implementation in the wiring harness, however, there are also degrees of freedom as to which accessories are actually used. Therefore, the master data can only define valid possibilities; which variant is used must be defined at the concrete occurrence.
In the VEC the accessory occurrence → parent occurrence relationship is represented by the ReferenceElement association, where the accessory occurrence references the OccurrenceOrUsage it depends on / relates to as ReferenceElement(see Instantiation of Components)
The illustration above shows a single accessory that is associated with two reference elements. In cases where the variance control mechanisms are not yet defined1 completely, the condition of existence of the reference elements has implications for the accessory.
An example for such case are elaborately sealed grommets for improved waterproofing. Each wire passing through the grommet requires a special individual seal. In this case, each seal is an accessory for both the wire and the grommet to the same extent. In concrete variants of the harness, only if a specific wire exists the corresponding seal is required. However, the association to the grommet is equally relevant, as it defines the position of the seal on the wire and without the grommet the seal is also without purpose.
Grommets have certain points (the CableLeadThrough) that are relevant for the placement of a grommet. Since currently the CableLeadThrough only specifies relevant information on the component side and not on the instance side, there is no corresponding subelement of the GrommetRole. The ability to place a CableLeadThrough on a specific point in the topology is covered by the generic mechanism of PlacementPoint & PlacementPointReference.
CableDucts can fulfill have to relevant aspects. They can be connected with the harness (placement). This is specified with the blue classes. The CableDuctSpecification brings this aspect of use to given part. At the same time a CableDuct can have properties of a Fixing since it is often mounted to the vehicle body as well. This aspect is defined by an additional FixingSpecification.
The ability to place a Fixing on a specific point in the topology is similar to Grommets covered by generic mechanism of PlacementPoint and PlacementPointReference. Additionally the measurement of Fixing is covered by MeasurementPoint and MeasurementPointReference.
Fixings with additional Cable Ties
The diagram illustrates the definition of a Fixing with CableTies as Accessory. The upper half of the diagram is the definition of the part master data.
The Fixing is described with a PartVersion and a FixingSpecification. To describe its accessories it has GeneralTechnicalPartSpecification with PartRelations to link the accessories. In this case, one CableTie is mandatory, a second one is an optional add on. Both are referencing the PartVersion of the CableTie.
The CableTie is currently defined with a not further detailed PartOrUsageRelatedSpecification, since there is no CableTieSpecification in the VEC at the moment. That the accessory is a CableTie is defined by the value of the specialPartType attribute.
For the instancing of these components, both are created with a PartOccurrence. The Fixing is defined with a FixingRole, the CableTie with a SpecificRole (For the same reasons why a PartOrUsageRelatedSpecification has been used).
E/E components, represented in the VEC by the EEComponentSpecification and EEComponentRole, summarize all kinds of components with a more or less complex electrical function. In the VEC the description of an E/E component is a combination of the following (optional) aspects:
- Connector Interface / EE Component Header: Defines the properties and possibilities for a connection to a wiring harness or other e/e components.
- Internal Connectivity: Defines the electrical connectivity within a e/e component.
- Switching States: Add variability of a certain degree to the internal connectivity.
- Electrical Interface: Defines the electrical properties (e.g. peak currents) of a connector interface.
- Type Specific Properties: Defines properties that apply only to specific e/e component types (e.g. capacity for a battery).
E/E Components in terms of the VEC can be for example:
Connector Interface / EE Component Header
Any E/E-Component has some kind of connector interface. This can be an interface to attach a harness or another E/E component. For the variety of possible usage see the next section.
An E/E-Component is represented in the VEC by an EEComponentSpecification. The connector interface of an E/E-Component is represented by a HousingComponent. The HousingComponent separates into two aspect:
- Geometrical: It references a ConnectorHousingSpecification to describe the geometrical / mechanical properties of the connector, e.g. the shape, slot layout, number of cavities etc. As this is the same Specification that is used for harness connectors it just defines an empty housing, without pins and terminals.
- Electrical: The electrical properties of the connector, the actual pins in the housing, are represented by the PinComponent. The physical properties of the pin are represented by a TerminalSpecification.
The figure Instantiation Example shows the structure for an E/E component with a single pin. The following XML listing shows the same as xml snippet:
<Specification xsi:type=vec:EEComponentSpecification" id"id_ecomponent_spec_1498"> <Identification>DSC</Identification> <DescribedPart>...</DescribedPart> <HousingComponent id="id_housing_comp_1500"> <Identification>A1</Identification> <HousingSpecification>id_connect_hous_spec_1501</HousingSpecification> <PinComponent id="id_pin_comp_1506"> <Identification>1</Identification> <PinSpecification>id_terminal_spec_1511</PinSpecification> <ReferencedCavity>id_cavity_1504</ReferencedCavity> </PinComponent> </HousingComponent> </Specification> <Specification xsi:type="vec:ConnectorHousingSpecification" id"id_connect_hous_spec_1501"> <Identification>37548</Identification> <SpecialPartType>HarnessConnector</SpecialPartType> <Slot xsi:type="vec:Slot" id"id_slot_1502"> <SlotNumber>A</SlotNumber> <Cavity id="id_cavity_1504"> <CavityNumber>1</CavityNumber> </Cavity> </Slot> </Specification> <Specification xsi:type="vec:TerminalSpecification" id"id_terminal_spec_1511"> <Identification>Usn3B323a4a10a614881C33</Identification> ... </Specification>
Connector / Interface Types
Note: This section is in particular relevant for component boxes, as they have the greatest variance of different interface types. However, all these interface types can as well appear in other EE components. To understand the technical background and the definition of the different types, please read the article about Component Boxes
All (pluggable) electrical interfaces of a EE component to other components or the harness are represented by a HousingComponent. That means for each fuse, multi fuse or relay slot and for all pluggable harness connectors or direct contacting connectors a HousingComponent is defined.
Version < 1.2.0: The classification of the housing component (e.g. is it a fuse or relay slot) is done with the specialPartType of the associated ConnectorHousingSpecification.
Version >= 1.2.0: VEC 1.2.0 introduced a compatibleTypes attribute in the HousingComponent to define what type of components are valid counter parts for a housing component. This is considered as an additional information to the pre 1.2.0 way.
Note: Slots for multi fuses are also represented by one HousingComponent.
|Type of Slot||ConnectorHousingSpecification.SpecialPartType (V1.1.3)||HousingComponent.CompatibleTypes (V1.2.0)|
|Multi fuse slot||MultiFuseConnector||MultiFuse|
|Slot for Harness Connector||HarnessConnector||ConnectorHousing|
|Slot for Ring Terminals of a Harness||HarnessConnector||RingTerminal|
|Modular Slot for other E/E-Components||…||EEComponent|
In figure E/E-Component Interfaces the instantiation of such a structure is partially shown. The details of a connector description with Slot, Cavity and PinComponent are only implied on the left side.
The listing below shows the general xml structure for such a component box. Omitted blocks are marked with “…”.
<Specification xsi:type="vec:EEComponentSpecification" id"id_ecomponent_spec_1463"> <Identification>Dnq3202104816a236</Identification> <SpecialPartType>FuseOrRelayCarrier</SpecialPartType> <DescribedPart>id_part_ver_1419</DescribedPart> ... <HousingComponent id="id_housing_comp_1466"> <Identification>B</Identification> <HousingSpecification>id_connect_hous_spec_1430</HousingSpecification> ... </HousingComponent> <HousingComponent id="id_housing_comp_1478"> <Identification>G2</Identification> <HousingSpecification>id_connect_hous_spec_1459</HousingSpecification> ... </HousingComponent> </Specification> <Specification xsi:type="vec:ConnectorHousingSpecification" id"id_connect_hous_spec_1430"> <Identification>WIRING</Identification> <SpecialPartType>WiringConnector</SpecialPartType> <Slot xsi:type="vec:Slot" id"id_slot_1432"> ... </Slot> </Specification> <Specification xsi:type="vec:ConnectorHousingSpecification" id"id_connect_hous_spec_1459"> <Identification>FUSE</Identification> <SpecialPartType>FuseConnector</SpecialPartType> <Slot xsi:type="vec:Slot" id"id_slot_1460"> ... </Slot> </Specification>
This section applies to all kind of internal connections in E/E components. One of the major use cases for this is the representation of internal connectivity of component boxes, since this is an important information, for example for physical validation or the calculation of current flows in the network. The model elements can also be used to represent the internal connectivity of a relay or any other E/E component. However, when it comes to software enabled component states (e.g. ECUs) the feasibility is more than questionable.
In figure Component Box Schematic Illustration the internal connections are illustrated by the red and black lines (2). In terms of the VEC, an InternalComponentConnection defines a logical (conductive) connection between a number of PinComponent within a E/E component. This representation does not consider the actual realization of the conductivity. This means, when multiple pins are connected, that the representation in the model is the same whether it is realized by point to point connections, a conductor rail or direct contacting.
In figure Instancing for Internal Connections an instance diagram is shown for a power distribution connection between a supply on the left side and the individual fuse slots on the right side.
Note: The essential criteria for a InternalComponentConnection is the electrical conductivity. So even if the connection in the example would be realized by three individual conductors between the left and the right side, it would be represented by one InternalComponentConnection
In figure Switching States Illustration a simple EEComponentSpecification with SwitchingState is schematically shown. In figure Switching States the corresponding representation in VEC is shown. It is a simple switch with two states. In the example, the switch has two HousingComponent, meaning it has two connectors, one for the IN-side and one for OUT-side. The housing component for the IN-side has one PinComponent, the OUT-side has two of them. However, a real example could as well have just one HousingComponent with three PinComponent. The pin on the IN-side is connected to the pins on the OUT-side with a switchable XOR-connection.
The IN-side (highlighted in red) and the OUT-side (highlighted in green) are represented in the VEC as a connector interface of your choice, as described in Connector Interface / EE Component Header. In the VEC a InternalComponentConnection is free of variance, therefore each state of the XOR-connection of the example is represented by an individual InternalComponentConnection (A.1 -> B.1) and (A.1 -> B.2). The switch in this example has two switching states (B1 & B2), each referencing one InternalComponentConnection, meaning that if the state is active, the corresponding connections exist / have electrical conductivity. The fact, that B1 & B2 are mutally exclusive to each are other is currently not represented in the VEC.
Note: Without the additional information of the switching states, the representation with two InternalComponentConnection would be illegal, as it would semantically equivalent to representation with one InternalComponentConnection referencing three PinComponent
A single fuse is a two-terminal component that can be plugged or screwed into a compatible fuse slot. There are different types, which differ in their geometry, the type of connection, the tripping characteristics and their rated voltage.
In VEC a fuse is handled as a EE-Component and that is why the FuseSpecification extends the EEComponentSpecification and describes it’s the available connector interface also with a HousingComponent and - in this case - with two PinComponents. The FuseSpecification defines the typical component attributes, i.e. the maximum electric current information for the fuse.
In addition to that the geometrical structure is described by a ConnectorHousingSpecification with it’s Slots and their Cavities (Cavity ). The PinComponents can be described in a more detailed way by usage of the PinComponentBehavior. Special information about the signal, signal direction or voltage can be placed here.
The PinComponent can reference a TerminalSpecification to define the physical properties of the pin. To avoid the confusion by too many crossing lines, the connection t the TermnalSpecification is not explicitly drawn in the diagram above.
Instantiating fuses is like instantiating any other EE-Component. A EEComponentRole under a PartOccurrence references the FuseSpecification and all structure elements underneath will be instantiated and references their corresponding part master element, too. For more information see E/E-Components.
A mutlifuse is a special type of fuse that combines multiple fuses in a single component (see Multi Fuse Illustration). In contrast to a regular fuse, where there are only two interchangeable pins, the multi fuse has a single dedicated supplying pin and multiple protected pins.
An individual fuse component is located between each protected pin and the supplying pin. Each fuse component can have its own technical properties (e.g. max current).
As shown in figure Specification Multi Fuse a multi fuse is represented in the VEC by a MultiFuseSpecification, which is a specialization of the EEComponentSpecification. Therefore all aspects described in the general section potentially apply to multi fuses as well. This sample describes only the aspects that are specific for multi fuses.
In the VEC, a multi fuse has one HousingComponent with a PinComponent for each pin. Each integrated fuse in the multifuse is represented by a FuseComponent. The fuse component references the pin components that are connected through it and specifies the properties for this (e.g. iMax) through a FuseSpecification.
<Specification id="id_2000_0" xsi:type"vec:MultiFuseSpecification"> <Identification>MF-3x100</Identification> <DescribedPart>id_1001_0</DescribedPart> <HousingComponent id="id_2023_0"> <Identification>Hco-MF-3x100</Identification> <HousingSpecification>id_2000_1</HousingSpecification> <PinComponent id="id_2024_0"> <Identification>V</Identification> <Description id="id_1003_1" xsi:type"vec:LocalizedString"> <LanguageCode>De</LanguageCode> <Value>Versorgung</Value> </Description> <ReferencedCavity>id_2020_3</ReferencedCavity> </PinComponent> <PinComponent id="id_2024_1"> <Identification>1A</Identification> <ReferencedCavity>id_2020_0</ReferencedCavity> </PinComponent> <PinComponent id="id_2024_2"> <Identification>2A</Identification> <ReferencedCavity>id_2020_1</ReferencedCavity> </PinComponent> <PinComponent id="id_2024_3"> <Identification>3A</Identification> <ReferencedCavity>id_2020_2</ReferencedCavity> </PinComponent> </HousingComponent> <IMaxTotal id="id_2080_0"> <UnitComponent>id_1005_0</UnitComponent> <ValueComponent>300.0</ValueComponent> </IMaxTotal> <FuseComponents id="id_2046_0"> <Identification>F1</Identification> <ConnectedPins>id_2024_0 id_2024_1</ConnectedPins> <FuseSpecification>id_2000_3</FuseSpecification> </FuseComponents> <FuseComponents id="id_2046_1"> <Identification>F2</Identification> <ConnectedPins>id_2024_0 id_2024_2</ConnectedPins> <FuseSpecification>id_2000_3</FuseSpecification> </FuseComponents> <FuseComponents id="id_2046_2"> <Identification>F3</Identification> <ConnectedPins>id_2024_0 id_2024_3</ConnectedPins> <FuseSpecification>id_2000_3</FuseSpecification> </FuseComponents> </Specification>
A relay is a component for switching current loads. Unlike fuses, there are more than one input pin and one output pin (number of pins >3). Some components, referred to as relays, are in reality small controllers with up to 17 pins.
In the VEC schema a relay is a special type of an EE-Component. It also owns a HousingComponent with it’s PinComponents underneath where these HousingComponent can be defined more detailed with a ConnectorHousingSpecification and the PinComponents with a referenced TerminalSpecification. Also the InternalComponentConnection for (potentially) connected pins are defined.
Additionally to these standard EE-Component structure the RelaySpecification also can contain so called SwitchingStates. Each state describes an InternalComponentConnection as potentially existing, depending on the current switched state of the relay. In the example above the blue colored PinComponents describe the coi contact. The connection between the two pins 30 and 87 is permanently The green colored part describes the switch, whose connection can exist depending on the SwitchingState. So the InternalComponentConnection between the pins 85 and 86 is not permanently guaranteed.
For more information see Switching States.
Instantiating relays is like instantiating any other EE-Component. A EEComponentRole under a PartOccurrence references the RelaySpecification and all structure elements underneath will be instantiated and references their corresponding part master element, too. For more information see chapter E/E-Components.
Note: The following sections will cover the technical background about component boxes. The term “component box” will be used as a general term for all types of fuse and/or relay carrier, power distribution box etc. The detailed mapping of the different aspects on concepts of the VEC will be in EE-Components, as the concepts are the same for regular E/E components and component boxes.
The image on the right side shows a photo of the front side of a component box. The drawing shows a drawing of a component box. In general, a component box is a component (carrier) that can be equipped with other components (e.g. relays & fuses) and by this, provides fusing and switching functionality to the attached wiring harness.
Basically a component box can be divided into four aspects:
- Slots to plug-in E/E components like fuses and relays.
- Connectivity with the wiring harness.
- Internal connectivity.
For all of these aspects, different technical solutions and variants exist. In reality, a specific component box can virtually combine and mix up all of these solution variants. To create a concise representation of a component box in the VEC model, a combination of different concepts is necessary. Some of these concepts are not exclusively for component boxes.
Plugability of E/E components
As mentioned before, a component box provides slots to plug-in other E/E-components. The following sections give brief overview of the most relevant types.
A fuse is a component with two pins that can be plugged or screwed into a compatible fuse slot. There exists a wide range of different types that have individual triggering characteristics and currents, geometries, connection types etc.
A multi fuse is similar to a regular fuse. However, due to cost and packaging reasons multiple fuses are combined into a single component. The individual fuses share the power supply, see the multi fuse example.
A Relais is a component used for switching of loads and has more than 3 pins.
Direct and Indirect Contacting
There are two different ways to create an electrical connection between the end of a wire and a corresponding fuse or relays, direct and indirect contacting. In case of direct contacting (see direct contacting) a terminal directly attached to the wire is locked into a cavity on ones side of the component box. The cavity goes through the component box and the pins of the fuse are directly plugged into the reception of the wire terminal. In this case, the component box itself does not provide a electrical conductivity.
In case of indirect contacting the component box contains a conductor (e.g. a conductor rail) that connects multiple cavities of the component box, see #3, #4, #7 and #9 in the component box drawing. The pins of the fuse are plugged into receptions of the conductor rail. Same applies for the connection to the harness. The wire terminals are grouped together into a harness connector, which is then attached to the component box. The conductor rail is often used for implementing the power distribution on the input side of a component box. In this case, the connection to the wiring harness is often done with ring terminals attached to bolts of the component box, see #8, #13, #14 and #16 in the component box drawing.
A combination of both in one component box is possible (and likely), e.g. the supplying side is realized with a conductor rail (indirect contacting) and the protected side is realized with direct contacting.
Connectivity with the Wiring Harness
In case of direct contacting the component box itself serves as end point for the wires. Therefore the last topology segment is attached to the component box. The component box requires / provides segment connection points. From an abstract point of view and out of the perspective of the wiring harness, a component box with direct contacting behaves just like a regular harness connector, see the schematic illustration (3).
In case of indirect contacting the wires and terminals are clipped into a regular harness connector and the connector is plugged into the component box. So, again from an abstract point of view and out of the perspective of the wiring harness, the component box with indirect contacting and a harness connector behaves just like a regular E/E-Component (e.g. an ECU, an actor or a sensor), see the schematic illustration (4) & (5).
Another variant in case of indirect contacting is the usage of ring terminals. The component box provides a bolt and a wire is attached to it with a ring terminal. In this case the component box behaves like a battery or a ground bolt, see the schematic illustration (6) .
For the calculation of current paths or electrical testing, a component box needs to define an internal connectivity, see the schematic illustration (2). This is a logical connectivity and it is irrelevant, if it is realized with direct or indirect contacting.
Some component boxes support modular concepts, e.g. the one shown in the photo. That means the component box can be extended with additional carriers, sockets or smaller component boxes (in a LEGO like way). There are two concepts for modularity: with or without electrical connectivity. If you compare the photo on top with the photo on the right you can see, that the relays socket in the lower left corner is mechanically clipped to main component box, electrically it is independent.
In contrast to this, the orange fuse socket right beside the relay socket has its upper part plugged into the main component box, with electric connectivity for power supply. The lower part of it provides an independent cavity for direct contacting of the protected side.
The following section contains examples for the definition of Pinning information in the VEC. This means the specification of the electrical behavior of PinComponents.
To define the electrical behavior of a PinComponent, the class PinComponentBehavior can be used*.* Since the behavior of a pin is configuration dependent (e.g. the software deployed on an ECU) the PinComponentBehavior inherits from ConfigurableElement. Therefore a PinComponent can specify multiple PinComponentBehavior. Additionally the Behavior can contain currentInformation for a pin. In combination with its attribute ‘singnalDirection’, the PinComponentBehavior can describe power supply components (e.g. batteries or generators; signalDirection ‘out’) as well as power consumer (e.g. lamps, sensors or actors; signalDirection ‘in’).
Signal Peak Distance and Duration
This example shows how a digital signal with pulse width and pulse separation can be defined. The PinComponentBehavior of a PinComponent has PinVoltageInformation. The PinVoltageInformation can define multiple PinTiming definitions. For pulsed digital signals, two PinTimings are used. One PinTiming (Duration) describes the pulse width. The other PinTiming (Peak Distance) describes pulse separation.
Load Type Dependant Maximum Current (Relais)
Dependant on the load type (inductive, resistive, capacitive) a switching contact of a relais can have different maximum loads.
The diagram shows a PinComponent of type switch that has two PinComponentBehaviors with pinType resistive and inductive. Each PinComponentBehavior has a PinCurrentInformation with type maxCurrent and different current values.
Whereas the model description defines the general concepts of multilevel composite parts and 100% and 150% variance for those parts, this implementation guideline follows a use case oriented approach and explains the correct usage of the different aspects of a VEC implementation (e.g. BOM, document structure, variance, instantiation) for different composite part scenarios. The most common ones are defined in the PartStructureContentType open enumeration. The
PartStructureSpecification.Content attribute defines, which kind of part, that has a bill of material, is described by a PartStructureSpecification and how the described bill of material has to be interpreted in regard of variance (10%, 100%, 150%).
Assemblies are predefined components, that are typically defined in a central place (e.g. a component library), reused in multiple projects / harnesses and whose inner structure is relevant for the harness design or the development process. Therefore, they are not considered atomic and information about their structure, subcomponents, etc is required. Often, assemblies are defined within their own drawings and have individual part numbers. Examples could be multipart connectors, fixings, grommets or, more complicated, preassembled cables like USB or LVDS.
The figure above illustrates very simplified the concept of an assembly and its usage. On the left hand side you can see the library or part master data definition of the assembly, on the right hand side you can see its usage.
The level of detail for the mapped information of an assembly can range from a pure bill of material view to even a well defined “mini harness”. A pure bill of material view is often not sufficient, especially if the specific usage of the assembly in a larger wiring harness has to be defined precisely (e.g., for preassembled cables the placement of the connectors, the routing of the cable, a.s.o.).
Part Master Data
The following figure “Assembly Definition” illustrates the basic structure of a part master data definition of an assembly. The upper half of the diagram contains the actual definition of the assembly, the lower half (highlighted in blue) contains the definition and details of the utilized subcomponents.
To define an assembly a DocumentVersion is required to contain all necessary Specifications (the “Assembly Definition” highlighted in green). This DocumentVersion has the
DocumentType = "PartMaster", just the same as for any other simple component. It can contain any Specification required to describe the assembly (like a GeneralTechnicalPartSpecification).
To describe the inner structure of an assembly, instances of its subcomponents are needed. The instances of the subcomponents can be defined either with PartOccurrences or PartUsages, depending on whether the information about specific parts / part numbers of the subcomponents is required / available, or if the subcomponents are just needed as reference elements to define the concrete usage of the assembly in a harness.
To define the instances of the subcomponents a container specification is required within the DocumentVersion that defines the assembly. This is either a CompositionSpecification or a PartUsageSpecification, depending on the type of instances used for the assembly. In case of the example PartOccurrences are used, and thus a CompositionSpecification is used as container.
The content of the assembly is defined explicitly with a PartStructureSpecification that references the instances contained in the assembly as
InBillOfMaterial and referencing the PartVersion of the assembly as
DescribedPart. In other words, the PartStructureSpecification represents the bill of material (BOM) of the assembly (or any other composite part in the VEC). The PartStructureSpecification defines
Content="Assembly" and the PartVersion of the assembly has a
PrimaryPartType = "PartStructure".
If any information about the subcomponents or their relationships should be defined in a more detailed way (e.g. the contacting of a preassembled cable) appropriate Specifications can be added to the DocumentVersion of the assembly as needed (indicated in the figure with the
ContactingSpecification). An assembly can even define its own topology (TopologySpecification) or schematic (ConnectionSpecification).
<PartVersion id="id_1001_0"> <Description id="id_A1" xsi:type="vec:LocalizedString"> <LanguageCode>En</LanguageCode> <Value>Composite Part A1</Value> </Description> <CompanyName>Example Corp.</CompanyName> <PartNumber>N.1</PartNumber> <PrimaryPartType>PartStructure</PrimaryPartType> </PartVersion> ... <DocumentVersion id="id_1002_0"> <CompanyName>Example Corp.</CompanyName> <DocumentNumber>N.1</DocumentNumber> <DocumentType>PartMaster</DocumentType> <ReferencedPart>id_1001_0</ReferencedPart> <Specification id="id_2000_0" xsi:type="vec:PartStructureSpecification"> <Identification>P1</Identification> <DescribedPart>id_1001_0</DescribedPart> <Content>Assembly</Content> <InBillOfMaterial>id_2000_2 id_2000_3</InBillOfMaterial> </Specification> <Specification id="id_2000_1" xsi:type="vec:CompositionSpecification"> <Identification>C1</Identification> <Component id="id_2000_2"> <Identification>A</Identification> <Part>id_1001_1</Part> ... </Component> <Component id="id_2000_3"> <Identification>B</Identification> <Part>id_1001_2</Part> ... </Component> </Specification> </DocumentVersion>
Usage of an Assembly
An assembly is normally used in a context different from its definition, e.g., the assembly is defined in a master data library and used in a wiring harness. The following figure “Assembly Instantiation” illustrates this scenario.
The instantiation of an assembly is normally done in a separate DocumentVersion (e.g. the definition of a harness, highlighted in purple in the figure above). The assembly itself is instantiated with a PartOccurrence and a PartWithSubComponentsRole, which is the corresponding Role for a PartStructureSpecification. Additionally, all subcomponents (referenced by the PartStructureSpecification) must be instantiated in the using context as well (Component A* & Component B*). By default, those are clones of their part master data definitions. To preserve traceability between occurrences from the part master definition and the occurrences in instantiation context, each instance is referencing its corresponding part master data occurrence as
InstantiatedOccurrence. In order to identify their affiliation to a particular assembly instance the PartWithSubComponentsRole references all of them as
At a first glance, this detailed approach may seem partially redundant and superfluous. However, it offers the possibility to redefine properties of the occurrences in the usage and also allows precise definition of the actual usage. Here are some examples:
- Redefinition of identifier and descriptions and associations: Connectors and cores of a predefined cable will have generic names and identifiers in the assembly definition. When used in a vehicle, connectors will fullfil a specific function, so identifiers for connectors will be derived from UsageNodes; descriptions will be function specific (e.g., “Infotainment USB Port Center Console”) and cores will realize system schematic connections of the vehicle. Furthermore, the same cable could be used multiple times in the same vehicle for different functions.
- Redefinition of technical properties: Technical properties of an assembly might change in a specific usage. E.g., a predefined cable (contacted only on one side) comes in a specific length. During the harness assembly it might be cut down to the required length.
- Placement & routing of the assembly in the usage: To define the actual usage, e.g., placement of connectors, routing of wire, a.s.o. occurrences are required. Since an assembly could be used multiple times in different locations and usages in a harness, those occurrences could not be the same occurrences used in the CompositionSpecification of part master data definition.
The following XML snippet shows the occurrences of the example in the CompositionSpecification.
<Component id="id_2001_2"> <Identification>Assembly-Instance</Identification> <Role xsi:type="vec:PartWithSubComponentsRole" id="pwscr_1"> <PartStructureSpecification>id_2000_0</PartStructureSpecification> <SubComponent>id_2001_3 id_2001_4</SubComponent> </Role> <Part>id_1001_0</Part> </Component> <Component id="id_2001_3" xsi:type="vec:PartOccurrence"> <Identification>A*</Identification> <Role ...> ... </Role> <InstanciatedOccurrence>id_2000_2</InstanciatedOccurrence> <Part>id_1001_1</Part> </Component> <Component id="id_2001_4" xsi:type="vec:PartOccurrence"> <Identification>B*</Identification> <Role ...> ... </Role> <InstanciatedOccurrence>id_2000_3</InstanciatedOccurrence> <Part>id_1001_2</Part> </Component>
Harness & Modules
From a high level perspective, a harness is just a “very complicated” assembly. The two major differences are:
- a harness is designed with variance in mind. In most cases it is a 150% definition containing either modules for a customer specific harness or a set of predefined variants.
- It is designed for a very specific use case (e.g., a vehicle) and its reuse in the process is very limited, in contrast to an assembly.
The figure above illustrates the concept of a harness in a very simplified way. A harness definition has several layers. The base layer consists of a set of component instances and their relationships, for example connectors, wires, terminals or even assemblies. The component instances in the base layer are used to define the function / appearance of the harness (e.g., contacting and routing of wires, placement of components) in all possible variants (150%). The other layers are used to manage the variance and to achieve a configurable product. The concepts (and the names) in these layers sometimes differ slightly in the various processes. However, from a data structural point of view, those differences are marginal.
For a customer specific harness, the next level defines Modules. A module represents a handle for a specific subset of component instances in a 150% harness. The strategies for modularization of a harness are manifold and quite process specific, but they are always influenced by the variant structure and the logistic concept of the product. However, modules do have in common, that they just represent a set of components that should be controlled individually in the configurable product. In this respect, modules are logistical units rather than real parts. A module itself is normally free of variance and does not represent a functional subset on its own, in other words, it is just a 10% set of components and not 100%. This means that only the correct combination of multiple modules creates a functional harness that can be found in a actual vehicle. The harness definition itself consists of all modules (150%). For a specific vehicle configuration, a subset of all modules is picked. The combination of those modules creates a specific variant (100%).
Not all harnesses are designed as customer specific harnesses. For less complex harnesses (e.g., the doors) or for the sake of a simpler order and manufacturing logistic, a set of preconfigured harness variants1 is often used. Two approaches exist for this:
- In the first approach the variants are defined as a set of components (“Variant X” in the figure, the dashed arrow stands for the references to all components required for “Variant X”). So they are basically defined in the same way as a module, with the difference that each variant represents an actual harness (100%) by itself.
- In the second approach, the components are grouped into modules (in this context often named “options”), just as with the customer specific harness. The specific harness variants are then defined as subsets of the modules / options (“Variant Y” in the figure).
The following figure shows the basic structure of a harness definition in the VEC. It has to be read from left to right.
The harness definition starts on the left hand side with the
COMPONENTS CompositionSpecification. It contains all component occurrences that are required for the harness (or its definition). If the harness contains components without a specific PartVersion, the use of PartUsages is also valid. The illustration contains only the hierarchical structure of a harness definition. A complete definition will include a wide variety of additional Specifications that allow the detailed definition of the harness based on the occurrences (e.g. TopologySpecification, PlacementSpecification, RoutingSpecification, ContactingSpecification).
Based on these part occurrences, each module (Module A & Module B) has a PartStructureSpecification (highlighted in yellow), that describes its PartVersion. This is completely analogous to the representation of assemblies. However, a harness (or a variant) is not created with Module PartVersions but with PartOccurrences of modules. For a clear structuring of the containments in VEC document the module occurrences (highlighted in orange) are placed in a second CompositionSpecification, the
MODULES in the middle of the illustration. Each module’s PartOccurrence has a PartWithSubComponentsRole, just as described above to the assembly instancing. However, due to the special nature of modules in a harness definition, the PartWithSubComponentsRole does not reference a cloned set of PartOccurrences, but the same that are used for PartStructureSpecification. All PartOccurrences referenced by the corresponding PartStructureSpecification as
InBillOfMaterial must also be referenced as
SubComponent by the PartWithSubComponentsRole. This supposed redundancy is due to the fact that a module is in principle defined by its first (and often only) occurrence. Although redundant, it is intentionally required to fill both associations (
PartStructureSpecification -> PartOccurrence &
PartWithSubComponentsRole -> PartOccurrence). This unifies the handling of assemblies and modules for reading systems.
Finally (on the right side), the harness (150%) or a specific variant (100%) is defined as “bill of modules” with a PartStructureSpecification referencing all module occurrences that belong to the harness.
Even if this represention of a harness in the VEC appears to be somewhat more extensive at the first glance than, for example, in the KBL, it does have some advantages:
- The VEC has a general concept for a multilevel bill of material with support of variance. The number of levels (components, assemblies, modules, harness) is arbitrary. It is also possible to create an orthogonal structuring, e.g., for production BOMs vs. logistic BOMs.
- The PartOccurrence separates context specific information (e.g,. variant configurations) from part master data. If a harness is reused and a module has different context information (e.g. different variant configurations in different vehicles) then, this is possible without recreating a module.
- Reusing shared modules in different harnesses is, with slight changes for the reusing context, also supported.
Placements and Dimensions
A Placement defines the way how a component is associated to the topology. The following sections contain examples about the different types of placements.
This diagram illustrates the placement of a simple WireProtection as shown in next diagram.
The Figure above displays the placement of a simple wire protection. The PartOccurrence is placed with an OnWayPlacement via a PlaceableElementRole. This means the placed component covers a linear area of the harness topology. The start and the end of this area is defined with two Locations. In the shown situation the StartLocation is a SegmentLocation, which means the start is somewhere in the middle of a TopologySegment. It is defined to be at 120mm measured from the EndNode of the TopologySegment. The EndLocation of the WireProtection is located on a TopologyNode with a NodeLocation. It is not valid to define Locations with SegmentLocation, which could be also expressed by NodeLocations. This means for SegmentLocations an offset of 0 or equal to the segment length is illegal.
WireProtection with Dimension
This diagram shows the previous example extended with a Dimension. In the previous example, the beginning of the WireProtection was defined with a tolerance value. This method is applied, if the tolerance is applied to the next TopologyNode (Start- or End-Node of the segment).
In many cases, tolerances are defined relative to specific points (e.g. points that can be measured) somewhere in the topology. In these cases a Dimension is used to defined the tolerance.
The placement of the WireProtection is just the same as in the previous example. It is extended with the Dimension (highlighted in green). The Dimension defines the tolerance of +/- 20mm between the TopologyNode ND-III and the beginning of the WireProtection.
The fact, that the Dimension is specified between the TopologyNode and the beginning of the WireProtection is expressed, that the TopologyNode is referenced directly (with a NodeLocation contained by the Dimension). The SegmentLocation used as DimensionAnchor is the same as used for the placement of the WireProtection.
The valueCalculated=true flag of the Dimension indicates that the valueComponent (220mm) is a derived an calculated value and not a user defined value. This value can be obtained from the placement information and the lengths of the TopologySegment.
This diagram illustrates a more complex placement situation, including the usage of dimension.
The illustration shows a bracket, that is placed independently on two Segments (SEG-1 & SEG-2). The two points where the bracket is placed on the TopologySegments are identified separately (PlacementPointReference A & B). Additionally a Dimension is added, which gives a Tolerance between a geometric point (e.g. a bolt) on the bracket (MeasurementPointReference C) and a Node (ND-1) in the Topology (see TopologyNode).
The diagram illustrates the instantiation of the example in the preceding diagram. Since the PartOccurrence can be placed in the topology, it has a PlaceableElementRole (with a corresponding PlaceableElementSpecification not shown in the diagram). The points where it can be placed onto the topology are represented by the PlacementPointReferences A & B. The point which can be used as anchor for a dimension (which can be any reference point on the component), is represented by the MeasurementPointReference C.
Large Area WireProtections
In some cases it is necessary to place a wire protection over a greater area of the topology, consisting of more than one TopologySegment (e.g. Tubes with a fixed length). For these cases the OnWayPlacement defines two locations for the start and the end and a path along which the wire protection is placed. The path is an ordered list of the segments from the start to the end. If a SegmentLocation is used for the start or the end the path must contain these segments as well.
For each TopologySegment the use of Start- and End-Node has no semantik relevance. The names are just used to make it possible to identify the corresponding TopologyNodes correctly e.g. when defining the anchor for a SegmentLocation.
Fixed Components (Single Location)
Fixed components are elements that are placed on a certain point in the topology, such as Connectors, Fixings and so on. These components are placed with an OnPointPlacement as shown in the example. If the Component has to be placed on a Node (e.g. a Connector) a NodeLocation is used. If the Component has to be placed on a Segment a SegmentLocation is used. The usage and constraints for the Locations are the same like the ones for OnWayPlacements.
Fixed Components (Multiple Locations)
Some components, for example channels or a large connector with more than one segment connection point, may be placed on multiple positions in the Topology. For example a channel can have two or more reference points (e.g. the outlets) that must be associated to the different positions topology. In these cases an OnPointPlacement with more than one location is used. In order to identify which location places which point of the component (e.g. the outlets), a PlaceableElementRole can define PlacementPointReferences which are creating a relationship to the component description.
The diagram illustrates the use of a DefaultDimensionSpecification. The DefaultDimensionSpecification can be used to specify default dimensions / tolerances for certain attributes and ValueRanges. In this examples the Specification is used for the length of wires. (indicated by the dimensionType). The dimensionValueRange defines for which value’s of this type, the referenced Tolerance is applicable.
In this example for a wire length lower than 250 mm a Tolerance of +5 mm is allowed, for values between 250 mm and 500 mm a Tolerance of +10 mm is allowed and for everything above 500 mm a Tolerance of 15 mm is allowed.
The VEC offers various means for structuring or modularizing information. This concerns on the one hand the distribution of information in individual files and on the other hand the distribution of information within a single VEC file. How these concepts are applied properly is covered in the following sections.
This example explains how more than one VEC file can be packaged together with external documents, for example symbols of the specified components. In this case the VEC shall be packed within an archive together with the external documents (according to the current published VEC recommendation) and an index file has to be provided.
The upper half of the diagram illustrates the file structure within the archive. In the root there is a ‘index.vec’ file that describes the content of the archive. The simplified content of this index file is illustrated in the lower half of the diagram.
For the example, the archive consists of following files:
- index.vec: Describes the content of the archive.
- A harness with the part number 4811 specified by a VEC-File (4811_a.vec) and a 2D SVG representation of the harness (4811_a.svg).
- A component description of connector housing (part number: 4711) specified with a VEC-File (4711_a.vec) and component symbol (to be used in the 2D-drawing) defined with a SVG-Symbol (4711_a.svg).
In the VEC (especially in the index.vec) a DocumentVersion object is created for each external document (see lower half of the diagram). This DocumentVersion object references the PartVersion to which it is related. Beside all meta information about the document, the attribute dataFormat of the DocumentVersion specifies the format of the external document as a MIME-Type. The attribute fileName is a path relative to VEC-File pointing to the external document in the archive
External Installation Instructions
The usage of file-based installation instructions is quite similar to the described approach for external documents. The FileBasedInstruction defines a pointer to the file packaged together with the VEC-file in the container and is referenced by the PartOccurrence.
The same effect could be achieved if a DocumentBasedInstruction is used, pointing to an external document (defined as described in the section before).
Important: The difference between the two approaches is that for the DocumentBasedInstruction a DocumentVersion is required. This means that the external file must be an official document with a document number, an appropriate versioning and so on. The FileBasedInstruction can point to any file needed. It is not a valid approach to use the FileBasedInstruction, if the external file is a valid document.
Simple External Mapping
The Diagram shows a simple example for the usage of the external mapping mechanism. The elements highlighted in yellow represent the actual information described by this VEC instance. The elements highlighted in blue are defining the concrete mapping and the DocumentVersion highlighted in green represents the link to the mapped document (in this case a SVG-symbol).
The 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.