Persistency KVS Architecture#
Persistency KVS Feature Architecture
|
status: valid
security: NO
safety: ASIL_B
|
||||
Overview#
The Key-Value-Storage (kvs) provides the capability to efficiently store, retrieve, and manage key-value pairs in a persistent storage system.
Description#
kvs organize data as pairs, where each unique key is associated with a specific value. The key acts as a unique identifier for getting the value.
The data is persisted in JSON format to the file system, providing a human-readable, and widely supported way to store and manage key-value pairs.
The JSON data persisted is according to RFC-8259.
Glossary:
User: Program code that is written by a person that initiates the given functionality call or receives a callback.
Requirements#
Title |
ID |
|---|---|
Separate data stores |
|
Asynchronous operation |
|
Signalling completion of asynchronous operation |
|
Atomic store operation |
|
Cached access |
|
Configuration |
|
Intra-Process data access |
|
Confidential storage |
|
C++ and Rust language support |
|
Provisioning of default values via external file |
|
Retrieval of default values |
|
Default values |
|
Support development mode |
|
Direct access |
|
Dynamic memory allocation during runtime |
|
Random access time |
|
Integrity check |
|
Load persistent data |
|
Access from multiple applications |
|
Multiple KVS per application |
|
Operating system agnostic implementation |
|
Support production mode |
|
Recovery from reset |
|
Reset resistant storage |
|
Reset to default values |
|
Snapshot create |
|
Snapshot remove |
|
Snapshot restore |
|
Multiple storage backends |
|
Store persistent data |
|
Supported datatypes (Keys) |
|
Supported datatypes (Values) |
|
Tooling |
|
Update Mechanism |
|
Variant management support |
|
Versioning |
|
Write amplification minimization |
Rationale Behind Architecture Decomposition#
The architecture has one component comp__persistency_kvs and it uses mod__baselibs for JSON handling and file system access.
Static Architecture#
The static view shows the feature with its logical interface and the components implementing it. The diagram is generated from the Sphinx Needs model.
Static Architecture
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Dynamic Architecture#
The dynamic views describe the interactions between the user and the components of the feature for the main use cases of the KVS.
Check if key contains default value
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Delete key from KVS instance
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Flush to permanent storage
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Read key value
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Read data from permanent storage
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Write value to key
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Restore snapshot
|
status: valid
security: YES
safety: ASIL_B
|
||||
|
|||||
Logical Interfaces#
The logical interfaces of the feature are defined in the platform documentation: Ikvs (logic_arc_int__persistency__interface).
See SCORE Features for more information.
Used Components#
The feature is realized by the following components of the module: