Expected Behaviour of VEC Interfaces

Change History

Id Subject Date
Latest Commit KBLFRM-1007: Change Tracking and Modifcation of DocumentVersions 2022-07-29
KBLFRM-946  Added Guideline for Import- / Export-Behaviour 2022-07-29

Disclaimer: This page or section is currently under review by the community.

The content of this page or section can be subject to change at any time. If you find any issues or if you have any review comments please drop us an issue on the PROSTEP JIRA.

This page or section resolves KBLFRM-946

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

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

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

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

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

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

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

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

Content of a VEC

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

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

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

Traceability Scenarios

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