Requirements#
Persistency Requirements
|
status: valid
security: YES
safety: ASIL_B
|
||||
C++ and Rust language support
|
status: valid
security: NO
safety: QM
|
||||
The Persistency shall provide native API support for both C++ and Rust programming languages. |
|||||
Operating system agnostic implementation
|
status: valid
security: NO
safety: QM
|
||||
The Persistency shall be operating system agnostic. |
|||||
Variant management support
|
status: valid
security: NO
safety: QM
|
||||
The Persistency shall ensure compatibility across different SW versions. |
|||||
Dynamic memory allocation during runtime
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall not allocate dynamic memory during runtime. All required dynamic memory shall be allocated during initialization. Note Dynamic memory allocation violates freedom from interference as the HEAP is a shared resource on OS process level. Additionally, fragmentation of the HEAP can lead to non-deterministic behavior of the application. |
|||||
Multiple KVS per application
|
status: valid
security: NO
safety: QM
|
||||
The Persistency shall support multiple independent storages per application. |
|||||
Access from multiple applications
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall prevent access to a single KVS instance from multiple OS processes. Note Access from multiple OS processes violates freedom from interference, as applications can modify the same data concurrently. |
|||||
Separate data stores
|
status: valid
security: YES
safety: ASIL_B
|
||||
The Persistency shall ensure that only authorized applications can access individual data stores. Note Access control is essential to prevent unauthorized access and modification of sensitive data. The Persistency shall implement mechanisms to enforce access control policies based on user roles and permissions. |
|||||
Configuration
|
status: valid
security: YES
safety: ASIL_B
|
||||
The Persistency shall support configuration via a configuration file. The configuration shall include:
Configuration file shall be optional and all configuration attributes shall have sensible default values defined at compile time. Note To improve the user experience during rapid prototyping, the Persistency shall also be able to operate without a configuration file. |
|||||
Supported datatypes (Keys)
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support UTF-8 encoded strings as valid key types. |
|||||
Supported datatypes (Values)
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support storing both primitive and non-primitive (composite) datatypes as values. |
|||||
Default values
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support predefined default values for keys. |
|||||
Provisioning of default values via external file
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support import of default values using an external file. Note Default values are read-only and cannot be modified at runtime. This requirement addresses the provisioning of default values during initial deployment. See Tooling (feat_req__persistency__tooling). |
|||||
Retrieval of default values
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support retrieval of the default value associated with a key. |
|||||
Reset to default values
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support reset of individual key or all keys to their default values. This is only applicable for existing keys that have a predefined default value. |
|||||
Store persistent data
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support storing of key-value pairs to persistent storage. |
|||||
Reset resistant storage
|
status: valid
security: YES
safety: ASIL_B
|
||||
The Persistency shall ensure that write operations are reset resistant to prevent data corruption in case of expected or unexpected interruption. Note As the constant power supply can not be guaranteed in embedded systems, it is essential to ensure that write operations are completed successfully, or rolled back to the previous state in case of any kind of interruption. |
|||||
Recovery from reset
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall recover to a consistent state after reset. Note After a reset, the Persistency shall ensure that all key-value pairs are in a consistent state, reflecting either the last successful write operation or the previous consistent state. |
|||||
Atomic store operation
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support atomic write operation for entire storage to ensure data consistency. Note Atomic write operation guarantee that either all key-value pairs are written, or no changes are made at all. This is required to prevent malfunctions when individual key-value pairs are dependent on each other. |
|||||
Write amplification minimization
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall minimize the write amplification during data storage operations to enhance performance and prolong the lifespan of the underlying storage medium. Note Write amplification refers to the phenomenon where the amount of data written to the storage medium exceeds the amount of user data intended to be written. Minimizing write amplification is crucial for optimizing performance and reducing wear on storage devices, especially in embedded systems with limited number of program-erase cycles. |
|||||
Load persistent data
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support loading of key-value pairs from persistent storage. |
|||||
Cached access
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support caching mechanisms to improve access times for frequently accessed key-value pairs. |
|||||
Direct access
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support direct access to key-value pairs without the necessity to load the entire storage to RAM in advance. Note Direct access improves availability of data and reduces memory consumption for large data sets. |
|||||
Integrity check
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall detect and report data integrity issues. |
|||||
Confidential storage
|
status: valid
security: YES
safety: QM
|
||||
The Persistency shall support confidential storage of key-value pairs using encryption mechanisms. Note Confidential storage is essential to protect sensitive data from unauthorized access, especially in scenarios where the storage medium may be exposed to potential threats. |
|||||
Multiple storage backends
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support multiple storage backends. More than one storage backend of the same type shall be optionally supported for the sake of redundancy. The storage backends shall be compile time configurable for each KVS instance. Note Storage backend represents an abstraction for the underlying storage format and mechanism. Configurable storage backends allow the user to select the most suitable solution for their specific use case (Performance, easy of use, resource consumption, …). |
|||||
Asynchronous operation
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall provide an asynchronous API for time consuming operations like loading and storing of data. |
|||||
Signalling completion of asynchronous operation
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall provide a mechanism to signal the completion of an asynchronous operations to the application. |
|||||
Snapshot create
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support explicit creation of snapshots. Snapshots are identified by unique IDs. Snapshots shall also include the version of the data layout. See Versioning (feat_req__persistency__versioning). Note Snapshots are point-in-time, read-only view on all key-value pairs at moment of snapshot creation. They are typically used for backup and rollback purposes. Implicit snapshots (e.g. created during store operation) shall be prevented to reduce storage consumption. |
|||||
Snapshot restore
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support explicit restoration of snapshots. |
|||||
Snapshot remove
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support explicit removal of snapshots. |
|||||
Intra-Process data access
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support concurrent access to key-value pairs from multiple threads within the same process. |
|||||
Versioning
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall support versioning for different data representation of KVS. Note Versioning is essential to ensure compatibility between different versions of the Persistency and the stored data. Each version shall be uniquely identifiable and include information of the data layout and structure. |
|||||
Update Mechanism
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall implement mechanisms to upgrade from one version to another, including multi-version jumps. |
|||||
Random access time
|
status: valid
security: NO
safety: QM
|
||||
The Persistency shall ensure that random read access for key-value pair is completed with constant or logarithmic time complexity relative to the number of stored key-value pairs. |
|||||
Tooling
|
status: valid
security: NO
safety: ASIL_B
|
||||
The Persistency shall provide tooling support for:
|
|||||
Support development mode
|
status: valid
security: YES
safety: ASIL_B
|
||||
The Persistency shall support the development mode. The development mode shall allow unrestricted data access and bypass security policies. |
|||||
Support production mode
|
status: valid
security: YES
safety: ASIL_B
|
||||
The Persistency shall support the production mode. The production mode should enforce the most restrictive data access controls feasible. |
|||||
AoU Requirements#
Persistency Error handling
|
status: valid
security: NO
safety: ASIL_B
|
||||
The application shall handle if the feature persistency is not available. |
|||||
Application deadlock
|
status: valid
security: NO
safety: ASIL_B
|
||||
The application shall be designed in a way that deadlocks are avoided. |
|||||
Application execution
|
status: valid
security: NO
safety: ASIL_B
|
||||
The execution of persistency shall not be blocked by the application. |
|||||