Abstraction
IVI system requires software that is designed to meet a variety of needs and requirements. These needs and requirements vary depending on the country where it is used. In addition, OEMs want to provide multiple models and grades of vehicle, but their requirements also vary. In order to prevent huge numbers of IVI system software branching, a configuration mechanism is needed to cover several options without changing the program. This will be accomplished with this Vehicle Parameter Configuration. The information obtained from this function will allow, for example, the IVI system to set the required language for different countries and to select the Audio AMP that the product supports. In addition, based on the vehicle parameter, it determines if the vehicle is compatible with OEM-specific or country-specific features and returns it to the service.
This chapter describes the use cases with Vehicle Parameter Configuration, the functional requirements for realizing the use cases, and the functions of the Basesystem that can be used as a sample implementation.
Use cases
In the following table, use cases which need the Vehicle Parameter Configuration module for services are described.
Table 1
| # | Item | Description |
|---|---|---|
UC.VP.1 | Vehicle parameter setting before shipment | Before the product is shipped from the factory, each OEM/Supplier writes the configuration values into the product depending on the needs and requirements of the product without changing the software. |
UC.VP.2 | Function check | When the driver presses the button for ACC-ON and the IVI system is started, the system obtains information on which functions the product supports from the vehicle parameter that has been set. For example, functions specific to communication standards, devices, applications, etc. are enabled/disabled based on the vehicle parameter. |
Functional Requirements
This table includes the functional requirements of Vehicle Parameter Configuration module.
Table 2
| # | Item | Related Use Case | Description |
|---|---|---|---|
RQ.VP.1 | Vehicle parameter setting | UC.VP.1 | This function shall provide at least the following information as vehicle parameters
|
RQ.VP.2 | Acquisition of vehicle parameter | UC.VP.1 | If a request is received from a service that requires a vehicle parameter, Vehicle Parameter Configuration module shall provide the necessary information. |
RQ.VP.3 | Function check | UC.VP.2 | Vehicle Parameter Configuration module determines information on whether the product supports various specific functions and returns whether the functions can be used or not. |
Vehicle Parameter Configuration in Basesystem
Reference implementation in Basesystem
In the implementation of Basesystem, the function module for Vehicle Parameter Support is Vehicle Parameter Library.
In the implementation of Basesystem, it is assumed that the vehicle parameter information is stored and set in the IVI system as the configuration file. A service specifies the vehicle parameter information to acquire and sends a request to Vehicle Parameter Library, and Vehicle Parameter Library reads the data from the configuration file of vehicle parameter and stores it in the specified address.If the value of the specified variable is not set in the vehicle parameter's configuration file, 0 is returned.
In addition, when the service sends a request to the Vehicle Parameter Library to obtain information on whether the product supports various functions (communication standards, devices, applications, etc.), the Vehicle Parameter Library returns the result of enabled, disabled, or function not existing.
2 Comments
Fukutarou Sekine
Sorry for late response.
Let me ask about the functional requirement RQ.VP.1 ,
which includes the parameters "Vehicle signal acquisition method (e.g. CAN or direct)" .
It seems to related to hardware configuration.
And the vehicle parameter library source-code seems to include many hardware parameters.
On the other hand, from software viewpoint, the HAL should be better to abstract the hardware difference .
What is difference between the HAL and the vehicle parameter library to handle hardware difference ?
Riku Nomoto
Thank you for your comment, Sekine-san.
I believe that there are various parameters required by each OEM. Among them, we have defined the RQ.VP.1 parameters as the minimum parameters that should be obtained. However, as you mentioned, this is a hardware-dependent requirement, and I think we need to consider whether we should include it or not in this requirements.
I think what is intended in this description is that the product needs to have the ability to get the parameters described here as a requirement for IVI. As a function to support the acquisition of parameters in the IVI system to realize the example described in the use cases, I am introducing the Vehicle Parameter Library as a sample, and I think it is right for HAL to actually acquire the data like CAN.
Please let me know if this is not the intent of your question.