Depending on the use case, different Custom Packages are required per ECU project:
- Application – package that runs the host cores (single- or multi-core).
- HSM – package that runs on a separate HSM core.
- Board Support Package – optional package which just includes HW-dependent SW parts.
- only needed if customer wants to separate application development from HW setup.
The Package Name is not relevant for the communication with Vector, later during project registration and approval phase.
- Nevertheless, it would be a good practice to name the packages with the project plus subproject to have a better overview about the purpose of the package:
e.g. ECU_OEM_Modelline_Appl or ECU_OEM_Modelline_Hsm. - The use of umbrella packages is possible but not recommended. This does not save license costs later because licensing is done per project.
When updating a Custom Package, the Package Maker (see Roles) has to maintain a Version Number in the Package Manager. The numbering scheme is up to the user. Vector just proposes a scheme with three places <major>.<minor>.<bugfix>.
Rules for Package Creation
- An individual Custom Package is required for each microcontroller family and OEM program.
- A Custom Package should always be based on a single MICROSAR release. Mixing of modules from different releases is possible but should be avoided.
- A Custom Package should always be based on a stable MICROSAR version. Development releases may be used temporarily but the license for development releases expires when the next stable main release is available.
- A Custom Package should always be archived by the customer because Vector will remove its packages from the portal after 3 major releases. That means customers cannot reconstruct a package that is older than 1,5 year. So not only the manifest but the whole custom package must be kept under version control at customer side, same as production approval delivery.