This chapter gives you an overview of different strategies for your development that can be used with the Package Based Delivery. At the beginning of the development, you should decide which approach is suitable and should be used. This highly depends on what you are intending to do and what are your plans for the future.
Each strategy is described using a graphic that shows the process with the responsible parties and packages.
The following strategies are described in the following:
- One OEM and multiple ECU Generations or SOPs on same Hardware
- One OEM and multiple ECU Generations or SOPs on different Hardware
- One ECU Hardware for multiple OEMs
- Virtual Hardware (VTT) and no OEM Dependency
- Independent Hardware Platform
Package Legend
Graphic Element | Package Type |
|---|---|
| MICROSAR Core Package (MCP) |
| MICROSAR OEM Package (MOP) |
| MICROSAR Base Package (MBP) |
| MICROSAR External Package (MEP) |
| MICROSAR Platform Package (MPP) |
You can find a description of all packages in section The Embedded Packages.
One OEM and multiple ECU Generations or SOPs on same Hardware
This is a strategy in which a custom package is build once for one OEM and one Hardware with regular updates to new MICROSAR releases. After each update a new Production Approval Delivery is used for Start of Production (SOP).
- The effort for each MICROSAR update is minimal, as no large release jumps are made.
- The effort for going in Production Approval is minimal, as OEM and hardware is pre-integrated in the platform.
- Platform and project team are just one common team which prepare the Production Approvals as snapshots of the main development stream.
- The effort for going in Production Approval is minimal, as OEM and hardware is pre-integrated in the platform.
- Individual issue reports and fixes are available for each Production Approval Delivery
- Each Production Approval delivery can be used in multiple SOPs if the license scope is not violated.
One OEM and multiple ECU Generations or SOPs on different Hardware
This is a strategy in which a custom package is built and its hardware changes during ongoing platform development.
- Prerequisite: Availability of the second hardware-dependent module (MPP)
- Configuration of the hardware-independent layers can be retained.
- Only hardware-dependent modules (MPP) need to be reconfigured.
After migration to new a hardware, only the new hardware will be supported by the platform project.
- It would be possible to branch and maintain both hardware platform projects in parallel.
- It is not possible to have different hardware-dependent modules (MPP) in one platform project.
Package Validation should be done for both hardware projects to ensure a consistent set of modules for development.
For this approach, it is recommended to update to a new hardware first and then to a new MICROSAR release if necessary. This has the following advantages:
- No additional cost for updates when using Package based Delivery.
- Causes of configuration issues are easier to identify, if updates are done step by step.
One ECU Hardware for multiple OEMs
This is a strategy in which a custom package is built for hardware without OEM specifics (OEM Vector is used as a generic AUTOSAR stack in this case). This approach is suitable if an ECU is to be supplied to various OEMs.
Production Approval is never requested for the custom package on platform level. However, it must be registered in order to receive support for the platform development team.
- The effort for OEM specific customization is to be provided by the project teams and not by the platform team.
- The effort for OEM specific customization is to be repeated if the project needs to update to a newer platform version.
Package validation should be done at platform and project level to ensure a consistent set of modules for development.
Virtual Hardware (VTT) and no OEM Dependency
This is a strategy in which a custom package is built for virtual hardware and without OEM specifics. The platform uses the vVIRTUALtarget concept and can be tested using CANoe.
Production Approval is never requested for the custom package on platform level. However, it must be registered in order to receive support for the platform development team.
The strategy can be used if there are some basic functions that are to be developed centrally for different ECUs.
- The effort for OEM and hardware specific customization is to be provided by the project teams and not by the platform team.
- The effort for OEM and hardware specific customization is to be repeated if the project needs to update to a newer platform version.
Package validation should be done at platform and project level to ensure a consistent set of modules for development.
Independent Hardware Platform
This is a strategy which can be used if there is a dedicated hardware team that wants to set up and maintain a hardware platform independently of any application-specific code. The approach can be combined with the vVIRTUALtarget (VTT) approach. Both platforms can then be merged to one specific customer project in the end.
Production Approval is never requested for the custom package on platform level. However, it must be registered in order to receive support for the platform development team.
- The effort is high, but also brings a high degree of flexibility.
- The hardware platform may be used in different products of the Tier 1.
Package validation should be done at platform and project level to ensure a consistent set of modules for development.