Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Scope of Work Item

Persistence is about storing data permanently, to manage FLASH constraints and to manage persistency within automotive lifecycle constraints.


Finally the Persistence system architecture specification parts will be located in the GENIVI Enterprise Architecture model. The software and the design specification you can find in the implementation model section of the GENIVI model.

The Functional Scope of Persistence

In Scope

  • Persistence Management
    • Key/Value Pair Management
    • File\- and Folder Structure Management
    • User Data Management
    • Shared Data Management
  • File Systems and Storages
    • Flash storages (focus NAND)
    • Persistence plug-in for Lifecyle (Health monitoring and repair)

Not in Scope

  • Partition Management
  • File Systems and Storages
    • other storages (except NAND flash)


Which or what type of bits and bytes inside flash memory are in scope of Persistence?

Because there is not a simple answer this page gives you an introduction of Persistence Data.
... but finally we end up that also data items which are not code should be handled by Persistence. To summarize the characteristics of this data this table is created:


In the Architecture Documentation section below the answers are given, but before we go into that some additional information about Persistence is provided...

Issues about "Persistent data"


The problem with FLASH (NOR and/or NAND) devices is linked to reliability of semiconductor storage devices. In particular flash devices are sensitive to voltage drops during write cycles; reliability of flash devices heavily depends on the device driver, but also on the applications.


Managing persistent data is to avoid storing data during runtime in order to increase the lifetime of the FLASH device, because the total number of program-erase cycles per block is typically limited. Most available FLASH memory devices are guaranteed to have around 100,000 cycles, before the wear begins to deteriorate the integrity of the storage. The number of program-erase cycles can be extended by a technique which is called wear leveling. Wear leveling can be done in software or it is already integrated in the hardware of the flash storing device. The FLASH storing device must work properly at least during the lifetime of a car which is at minimum 10 years.


Mileage of a car per lifetime: 200.000km Average mileage of one lifecycle: 10km Number of lifecycles per lifetime: 20.000 Max program-erase cycles per lifecycle: 5



Because of the physical limitation of manageable size (write-able size -> page, erase-able size -> block (NAND) or sector (NOR)) defragmentation is a known issue of Persistence data. Different solutions need to be offered to avoid forcing defragmentation already from concept point of view right from the beginning.


Availability during Start-up of the node/system

Typically to grant reliability persistent data must be checked before use it; this check can be a time-consuming process. But this time cannot be accepted for IVI system. Therefore more enhanced concepts are needed. Considering that persistency storage medium may have long start-up times (e.g. Hard Disks) the applications consuming persistent data must be informed when data can be accessed.

Getting everything stored in shutdown phase

To get a consistent system snapshot, power off must be delayed until all applications have their persistent data written. After all persistent data was written, the filesystem must be unmounted to ensure that the flash device is not accessed anymore. Unmounting the filesystem may also be a time consuming process, since it may include erase and/or write operations.