Abstraction

While the IVI system is running, user configuration data and IVI service operation data are stored and maintained. 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 Persistent Data Management module must ensure that no persistent data is lost, no persistent data is corrupted and the persistent 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 Persistent 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 Persistent Data Management(the function 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 1, use cases which need the Persistent Data Management for services are described.

Table 1

#ItemUser

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 IVI system, the display settings are retained and the driver uses the information.

UC.BD.2

Utilize the persistent 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 persistent data stored in the IVI volatile or non-volatile when the battery is removed, for handling the persistent data after the battery is removed.

UC.BD.4

Data Initialization

If a user reset the system, all data is deleted.

Functional Requirements

This table includes the functional requirements of Persistent Data Management module. RQ.BD.1.1 and RQ.BD.1.2 are requirements realized by usual filesystem. Others are newly defined.

Table 2

#ItemRelated Use CaseDescription

RQ.BD.1.1

Data store in case of sudden power off

UC.BD.1

The Persistent Data Management module  shall prevent “persistent” data loss if the power supply is stopped.

RQ.BD.1.2

Data store of system lifecycle

UC.BD.1

IVI system shall preserve any "persistent" data requested by IVI services/apps through system startup/shutdown lifecycle.

RQ.BD.2.1

Storage memory requirement

UC.BD.1

The Persistent Data Management module shall minimize actual write operations to the storage device to make the lifetime as long as possible.

RQ.BD.2.2

Utilization of Persistent data

UC.BD.2

The data which needs to be read shall be readable by request from IVI services/apps.

RQ.BD.2.3

Data handling when the battery is removed.

UC.BD.3

Data shall be configurable to be kept or not when the battery is removed.

RQ.BD.2.4

Data Verification

UC.BD.2

The Persistent Data Management module shall detect the stored data corruption and provide alternative correct data.

RQ.BD.2.5

Data deletion

UC.BD.4

The data shall be deleted by request from IVI services/apps.

Persistent Data Management in Basesystem

Reference implementation in Basesystem

In the implementation of Basesystem, the function module for Persistent Data Management is Backup Manager.

As shown in the following figure 3, 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 based on the timing defined in the Configuration(ⅰ). When reading the data, Backup manager reads the data from the specified storage and sends it back to the application side(ⅱ). Backup Manager has responsible to provide those features. It will manage not only access to the persistent data for applications but also verify the underlying persistent data consistency in order to detect the data corruption so that alternative correct data can be provided. It also can delete part of the persistent data upon the requests from applications.


Figure 3

Backup manager

Reference code : https://gerrit.automotivelinux.org/gerrit/gitweb?p=staging/basesystem.git;a=tree;f=service/native/backup_manager;h=2a9382f9cbf84a8a2f3e1cb4602a693f44bd37d7;hb=refs/heads/master


  • No labels

5 Comments

  1. Riku Nomoto

    The memo that were pointed out at Virtual Workshop.

    #

    Item

    1

    Data persistency vs Backup

    • They have different requirement and functionality
    2
    • identify the location of the storage / app specific storage area
    • status of the persistent storage (wear leveling)
    3data access restriction
    4

    what kind of data?

    • Frequently used Destination
    • User specific info 
    5
    • infrastructure code
    • app property, version control
    • regional setting
    • original setting
    • Database from App
    • logging
    • GPS
      • compressed, secured form

  2. Bernard Craddock

    Hi Riku,

    Similar to system logging do you have requirements to copy essential backups off device and if so how would you achieve that, or do the backups only reside on device and if so in case of catastrophic data loss, I assume you can only reconstitute default setting using OTA update.

    99% of what we persist locally is just caching for fast access and can be lost, with the remaining 1% of data we need to retain long term and for this we additionally a-sync persist to remote cloud db using https put/post, which is incrementally backed up nightly. 

    could you elaborate on your approach

  3. Hiroyuki Ishii

    • It would be better to separate requirements into two groups firstly, ones can be mapped to usual filesystem feature and ones cannot be (and also the reason should be described clearly). For example, I think #1 could be achieved by filesystem journaling basically.
    • IMO data access restriction should be a separated item from #3 since it's quite important one.
    • Factory data reset would be added to both use-case and requirements.

  4. Naohiro Nishiguchi

    I guess https://www.autosar.org/fileadmin/user_upload/standards/adaptive/19-11/AUTOSAR_RS_Persistency.pdf would be help you to identify the requirements.

  5. Bernard Craddock

    Hi Nishiguchi-San,
    thank you for including autosar persistence link it is very thorough and helpful indeed I would suggest exactly what's required for persistence. Also please excuse my ignorance i'm new to embedded and this is 1st I've seen of Autosar, But anyway today I took a look at both their Classic and Adaptive platform specs which all appear to gel rather nicely with Nomoto-san PR spec requirements.

    I also look forward to reviewing 4.7 CAN and 4.8 GPS when available
    regards