Abstraction
This chapter provides requirements for backup management functions.
In order to prevent data corruption due to malfunction, it is necessary to take measures such as securing the data safety within the product. Backing up the necessary data on a regular basis will help maintain the reliability of the product.
In this way, we focus on the function of performing data backup on the product and describe the use case requirements“Backup” means “persistent” data in the IVI system where user configuration data and IVI service operational data are stored and preserved while the IVI system works. Even though IVI is battery-powered which looks similar to smartphones, electronic consumer devices, the power supply in IVI system can be unstable at ACC-ON and ACC-OFF for the system startup/shutdown. Therefore, the Backup Data Management module must ensure that no backup data is lost, no backup data is corrupted and the backup data is consistent while the system startup/shutdown lifecycle.
Another aspect on IVI system which is special rather than smartphone, electronic consumer devices is a much longer product lifetime, and that means the storage device must be available for a much longer time. So, in order to make the storage device lifetime longer, data write operation shall not happen every time when applications request. The Backup Data Management module needs to handle the read/write operation to the storage device at any given time.
This chapter describes the use cases with Backup Data Management(the function of backup as described above), the functional requirements for realizing the use cases, and the functions of the Basesystem that can be used as a sample implementation.
Use case
In the following table, use cases which need the backup management for services are described.
Table 1
Functional Requirements
This table includes the functional requirements of Persistent notification and backup management module.
...
1
...
IVI needs the ability to back up the data it needs, when it needs it.
...
2
...
The required data in #1 includes, for example, the following, but each data is specified by each OEM.
(e.g., time display method, Bluetooth pairing information, IVI screen theme color settings, etc.)
...
3
...
The following are examples of required timing for #1, but each data shall be specified by each OEM.
(e.g., when IVI is turned off, periodic backups, etc.)
Backup management in Basesystem
Reference implementation in Basesystem
...
| # | Item | User |
|---|---|---|
1 | A user changes the language display of the IVI from English to Japanese. By backing up the configuration data in the system, the user does not have to set the language display to Japanese every time the user uses IVI. | Driver |
2 | If a user wants to delete the data backed up in the IVI, the user uses the system reset function. | Driver |
3 | Developers check during development if the backup data can be saved correctly. | OEM/Developer(Before product shipment) |
Discussion Space for additional use cases(Freely write please) ~
...
#
...
Item
...
Data persistency vs Backup
- They have different requirement and functionality
...
- identify the location of the storage / app specific storage area
- status of the persistent storage (wear leveling)
...
what kind of data?
- Frequently used Destination
- User specific info
...
- infrastructure code
- app property, version control
- regional setting
- original setting
- Database from App
- logging
- GPS
- compressed, secured form
UC.BD.1 | Data protection in case of ACC-OFF or sudden power failure | Even when the driver presses the button for ACC-OFF or a sudden power failure occurs after changing the display settings of the navigation system, the display settings are retained and the driver uses the information. |
UC.BD.2 | Utilize the backup data | The driver searches for a destination using the search history stored in the navigation application. |
UC.BD.3 | Data attribute when the system battery is removed | Each OEM chooses whether to make each backup data stored in the IVI volatile or non-volatile when the battery is removed, for handling the backup data after the battery is removed. |
Functional Requirements
This table includes the functional requirements of Backup Data Management module.
Table 2
| # | Item | Related Use Case | Description |
|---|---|---|---|
RQ.BD.1 | Backup in case of sudden power off | UC.BD.1 | The Backup Data Management module shall prevent “backup” data loss if the power supply is stopped. |
RQ.BD.2 | Backup of system lifecycle | UC.BD.1 | IVI system shall preserve any "backup" data requested by IVI services/apps through system startup/shutdown lifecycle. |
RQ.BD.3 | Utilization of Backup data | UC.BD.2 | The data which needs to be read shall be readable by request from IVI services/apps. |
RQ.BD.4 | Data backup to non-volatile area | UC.BD.3 | The type of "backup" data shall be configurable, i.e. it can be configured to be either volatile or non-volatile when the system battery is removed. |
RQ.BD.5 | Storage memory requirement | UC.BD.1 | The Backup Data Management module shall minimize actual write operations to the storage device to make the lifetime as long as possible. |
Backup management in Basesystem
Reference implementation in Basesystem
In the implementation of Basesystem, the function module for Backup Data Management is Backup Manager.
As shown in the following figure 27, for example when a driver uses an application and a data backup request occurs, on receiving the request, Backup Manager writes the data to the specified storage with the specified offset and data size(ⅰ). When reading the data, Backup manager reads the data from the specified storage and sends it back to the application side(ⅱ). The above two functions are the roles of Backup Manager.
Figure 3
