Partitioning and Sizing of VEC Files
In theory it is possible to export all data of a company that relates to the vehicle network in a single VEC file. However, this is not a very reasonable approach for several reasons. Amongst those are:
- Intellectual Property Protection: For everything that is contained in a single VEC file, the "All or Nothing Principle" applies and it is hard or impossible to enforce a "Need to Know". A recipient of a file, who requires only a single detail, always receives the complete information.
- Partial Changes: Even if only a single content element is changed, the complete file must be created and read, because only after reading the complete file the recipient knows which elements have changed.
- Tool Support: Tools must support large areas of the VEC in their Import- / Export interfaces, even if the areas do not belong to their use case.
- Technical Feasibility: If all information is contained in a single VEC file, the file itself can become huge, which places new requirements on the creating and reading tools (e.g. required memory).
Therefore, the general recommendation is to make a VEC files as small as possible and as large as necessary. The correct scoping of a generated VEC file depends on the use case of the information and the intended interface. Scoping means in this context the process of defining which information shall be bundled together in a single file for data exchange.
The following paragraphs contain some guidelines if information shall be packaged together or not.
- If the elements specified with the VEC are described, published and changed independently from each other regarding time and content, then they shall be placed in separate files (unit of publication). For example, this is the case for the description of harness components (connectors, wires etc.), represented by a part number. This rule applies only for the publication as master information from the original source of information. If the information is used to create other information, it can be embedded in a single file. For example, the description (complete or partial) of the used harness components will be embedded in the VEC describing a harness.
- If elements specified with the VEC have no relationships between each other (except reference base on PartVersions and DocumentVersions), then they shall be placed in separate files. For example, the specifications of a connector housing and a wire have no reference.
- If the relationship between two elements is indirectly over shared information, then this is no reason for the elements themselves to be placed in a single file (e.g. two connectors share the same CavitySpecification or two wires share the same CoreSpecification). If this piece of shared information is defined centrally, then it would have its own unit of publication, probably in its own DocumentVersion. In this case rule #1 can be applied. This means that, if the specification (e.g. a CoreSpecification) shall be exchanged, it shall be placed in its own VEC file. If the specification is used to describe another element (e.g. a wire) it shall be embedded in the VEC file of the described element. However, this is no reason to place all elements using this information in the same VEC file.