module ara::per — Persistency
Guide du moduleGÉNÉRÉ PAR IA
Sauvegarde de paires clé-valeur structurées et de fichiers de manière persistante, transactionnelle et avec abstraction matérielle.
Sauvegarde de paires clé-valeur structurées et de fichiers de manière persistante, transactionnelle et avec abstraction matérielle.
Le module Adaptive Persistency (ara::per) fournit une couche d'abstraction indépendante du matériel pour le stockage non volatil des données, qui comprend aussi bien le stockage structuré de paires clé-valeur (KeyValueStorage) que l'accès basé sur des fichiers (FileStorage) (EXP_SWArchitecture p. 43). Les modifications apportées aux paires clé-valeur sont soumises à une mise en mémoire tampon et nécessitent un appel explicite de synchronisation (SyncToStorage) pour être sauvegardées durablement ([SWS_PER_00049]). En plus des mécanismes d'intégrité et de restauration des données, le module régit également les processus de mise à jour et de migration lors des actualisations logicielles ([SWS_PER_00357]).
Le cluster fonctionnel Persistency (ara::per) fournit pour l'AUTOSAR Adaptive Platform une couche d'abstraction standardisée pour la conservation non volatile des données (EXP_SWArchitecture p. 43). Il propose deux modèles d'accès fondamentaux : le stockage basé sur des clés KeyValueStorage pour les paramètres structurés et le stockage basé sur des fichiers FileStorage pour les flux de données utiles non structurés (SWS_Persistency p. 219). Les Adaptive Applications ainsi que les démons centraux de la plateforme tels que State Management, Diagnostic Management ou Update and Configuration Management utilisent ces interfaces afin d'enregistrer leurs états de façon persistante, indépendamment des systèmes de fichiers physiques ou des pilotes flash (EXP_SWArchitecture p. 93).
Diagramme de contexte : intégration du cluster Persistency dans l'Adaptive Platform avec les consommateurs d'application et de plateforme ainsi que le système d'exploitation sous-jacent. Sources : EXP_SWArchitecture p. 93, EXP_SWArchitecture p. 43.
Les opérations d'écriture dans KeyValueStorage suivent une sémantique transactionnelle en mémoire stricte ([SWS_PER_00046]). Les modifications des paires clé-valeur restent d'abord mises en mémoire tampon de manière volatile et ne sont écrites de façon permanente sur le support de stockage que via l'appel synchrone SyncToStorage ([SWS_PER_00049]), tandis que DiscardPendingChanges annule les états non enregistrés ([SWS_PER_00365]). Dans FileStorage, l'accès s'effectue via des accesseurs spécialisés et typés (ReadAccessor, WriteAccessor, ReadWriteAccessor), qui sont gérés exclusivement via UniqueHandle ([SWS_PER_00113], [SWS_PER_00114], [SWS_PER_00115]).
Diagramme de séquence : déroulement d'écriture et de synchronisation d'un stockage clé-valeur avec mise en mémoire tampon et purge physique. Sources : [SWS_PER_00046], [SWS_PER_00049], [SWS_PER_00365], EXP_SWArchitecture p. 230.
En outre, le module intègre des mécanismes complets pour le cycle de vie et la tolérance aux pannes : les changements de configuration pendant l'exécution sont traités via CheckForManifestUpdate et ReloadPersistencyManifest ([SWS_PER_00576], [SWS_PER_00577]), tandis que les migrations de données spécifiques aux applications sont effectuées via des rappels de mise à jour ([SWS_PER_00356], [SWS_PER_00357]). Si des contrôles de redondance ou d'intégrité basés sur le manifeste échouent, des rappels informent sur l'état de corruption ([SWS_PER_00433]), à la suite de quoi les données endommagées peuvent être réparées à l'aide de RecoverKeyValueStorage, RecoverFile ou par des opérations de réinitialisation ([SWS_PER_00333], [SWS_PER_00337], [SWS_PER_00334]).
Limites du système et intégration architecturale d'ara::per
Le cluster fonctionnel Persistency (ara::per) fournit des mécanismes d'abstraction standardisés pour le stockage non volatil des données sur l'AUTOSAR Adaptive Platform (EXP_SWArchitecture p. 43). Il découple aussi bien les applications définies par l'utilisateur que les services fonctionnels de la plateforme des systèmes de fichiers spécifiques au système d'exploitation, des structures de partition ainsi que des pilotes flash ou NVRAM (EXP_SWArchitecture p. 93). La fourniture comprend deux paradigmes de stockage primaires distincts : l'accès aux données basé sur des clés via KeyValueStorage ainsi que le stockage hiérarchique de fichiers via FileStorage (SWS_Persistency p. 219). Les services de plateforme tels que Diagnostic Management (EXP_SWArchitecture p. 176), State Management (EXP_SWArchitecture p. 55), Update and Configuration Management (SWS_UpdateAndConfigurationManagement p. 18) et Remote Persistency (SWS_RemotePersistency p. 9) utilisent ces interfaces comme des interfaces de port standardisées ([SWS_PER_00052], [SWS_PER_00116]).
En plus de fournir des abstractions de stockage local, ara::per intègre des primitives cryptographiques et des contrôles de redondance directement au niveau de l'interface avec le système d'exploitation hôte (EXP_SWArchitecture p. 230). La configuration fonctionnelle d'un stockage de persistance est modélisée de manière déclarative dans le manifeste AUTOSAR et lie des quotas, des hachages d'intégrité, des procédures CRC ainsi que des chemins de chiffrement cryptographique à des instances concrètes (SWS_Persistency p. 104). Les parties de bibliothèque d'autres clusters fonctionnels intègrent la persistance directement via leurs propres configurations cibles, tandis que les processus démons accèdent aux unités de stockage via des spécificateurs d'instance, à l'instar des applications classiques (SWS_Persistency p. 35).
Diagramme de contexte : intégration du cluster Persistency dans l'Adaptive Platform avec les consommateurs d'application et de plateforme ainsi que le système d'exploitation sous-jacent. Sources : EXP_SWArchitecture p. 93, EXP_SWArchitecture p. 43.
Stockage clé-valeur : instanciation, sémantique transactionnelle et mécanismes de purge
L'accès aux paramètres structurés s'effectue via la classe ara::per::KeyValueStorage, qui est ouverte par l'appel ara::per::OpenKeyValueStorage en spécifiant un ara::core::InstanceSpecifier ([SWS_PER_00052]). Le SharedHandle<KeyValueStorage> renvoyé encapsule la zone de stockage de manière sûre au niveau du typage et empêche une duplication incontrôlée grâce aux constructeurs de déplacement et de copie supprimés des conteneurs de base ([SWS_PER_00322], [SWS_PER_00324], [SWS_PER_00367]). Les paires clé-valeur sont modifiées ou consultées via SetValue ([SWS_PER_00046]) et GetValue ([SWS_PER_00044], [SWS_PER_00332]) ; à cet égard, KeyExists ([SWS_PER_00043]) assure le contrôle de l'existence et GetAllKeys ([SWS_PER_00042]) fournit l'énumération complète de toutes les clés actives.
Les opérations d'écriture et de suppression sont soumises à une sémantique transactionnelle en mémoire stricte : les modifications apportées par SetValue, RemoveKey ([SWS_PER_00047]) ou RemoveAllKeys ([SWS_PER_00048]) restent d'abord dans la mémoire tampon volatile du processus (EXP_SWArchitecture p. 230). Seul l'appel explicite de SyncToStorage sauvegarde toutes les modifications en attente de manière atomique et durable sur le support physique de données ([SWS_PER_00049]). Si des étapes de transaction non encore écrites doivent être annulées, DiscardPendingChanges réinitialise l'état à celui de la dernière exécution de SyncToStorage ou de l'ouverture ([SWS_PER_00365]). Les besoins en stockage peuvent être surveillés via GetCurrentValueSize ([SWS_PER_00554]) pour des valeurs individuelles ainsi que de manière agrégée, métadonnées et données de redondance incluses, via GetCurrentKeyValueStorageSize ([SWS_PER_00405]) (EXP_SWArchitecture p. 231).
Diagramme de séquence : déroulement d'écriture et de synchronisation d'un stockage clé-valeur avec mise en mémoire tampon et purge physique. Sources : [SWS_PER_00046], [SWS_PER_00049], [SWS_PER_00365], EXP_SWArchitecture p. 230.
Accès au stockage basé sur des fichiers et hiérarchies d'accesseurs typés
Pour les flux de données non structurés, les blocs binaires ou les fichiers journaux, on utilise la classe ara::per::FileStorage, qui est initialisée via ara::per::OpenFileStorage ([SWS_PER_00116]). Au sein d'un conteneur FileStorage, les fichiers existants peuvent être listés via GetAllFileNames ([SWS_PER_00110]), leur existence vérifiée via FileExists ([SWS_PER_00112]) ou des fichiers supprimés via DeleteFile ([SWS_PER_00111]). Les quotas de taille sont déterminés via GetCurrentFileSize ([SWS_PER_00407]) et GetCurrentFileStorageSize ([SWS_PER_00406]) (EXP_SWArchitecture p. 231).
L'accès aux fichiers lui-même suit le principe de ségrégation des interfaces via des classes d'accesseurs spécialisées (EXP_SWArchitecture p. 88). En fonction du mode requis (OpenMode, [SWS_PER_00147], combinables via des opérateurs au niveau du bit [SWS_PER_00144], [SWS_PER_00434]), les méthodes de fabrique créent des instances UniqueHandle exclusives ([SWS_PER_00371], [SWS_PER_00569]) :
OpenFileReadOnly([SWS_PER_00114], [SWS_PER_00376], [SWS_PER_00430]) : fournit unUniqueHandle<ReadAccessor>pour des opérations de lecture telles queReadText([SWS_PER_00165], [SWS_PER_00420]),ReadLine([SWS_PER_00119]),GetChar([SWS_PER_00168]),PeekChar([SWS_PER_00167]),ReadBinary([SWS_PER_00421], [SWS_PER_00422]),GetByte([SWS_PER_00419]) etPeekByte([SWS_PER_00418]).OpenFileWriteOnly([SWS_PER_00115], [SWS_PER_00377], [SWS_PER_00431]) : fournit unUniqueHandle<WriteAccessor>pour des opérations d'écriture viaWriteText([SWS_PER_00166]),WriteBinary([SWS_PER_00423]), des opérateurs de flux pratiques ([SWS_PER_00125]), le tronquage de fichier viaSetFileSize([SWS_PER_00428]) ainsi que la vidange physique viaSyncToFile([SWS_PER_00122]).OpenFileReadWrite([SWS_PER_00113], [SWS_PER_00375], [SWS_PER_00429]) : combine les fonctionnalités de lecture et d'écriture dans unUniqueHandle<ReadWriteAccessor>.
Les opérations communes de position et de taille telles que GetPosition ([SWS_PER_00162]), SetPosition ([SWS_PER_00163]), la navigation relative au moyen de MovePosition et l'énumération Origin ([SWS_PER_00146], [SWS_PER_00164]), GetSize ([SWS_PER_00424]) ainsi que le contrôle de fin de fichier IsEof ([SWS_PER_00107]) sont ancrées dans la classe de base commune FileAccessor. Les métadonnées de fichier étendues telles que les horodatages et les causes de création sont lues via GetFileInfo et la structure FileInfo ([SWS_PER_00435], [SWS_PER_00436], [SWS_PER_00438], [SWS_PER_00441], [SWS_PER_00442], [SWS_PER_00443], [SWS_PER_00444], [SWS_PER_00445]). Interprétation : la séparation stricte en instances d'accesseurs non copiables devrait, outre la sûreté du typage, servir principalement à empêcher de manière déterministe les conflits d'écriture concurrents au niveau du système d'exploitation. Question Q-a990a7aa44326447 (ouverte)
Diagramme structurel : hiérarchie des interfaces et des classes d'accès aux fichiers et poignées d'accesseurs. Sources : [SWS_PER_00113], [SWS_PER_00114], [SWS_PER_00115], EXP_SWArchitecture p. 88.
Gestion du cycle de vie, séquences de mise à jour et synchronisation des manifestes
Pour les mises à jour logicielles et les nouvelles installations par l'Update and Configuration Management (UCM), Persistency propose des opérations de cycle de vie dédiées (EXP_SWArchitecture p. 92). Si une configuration cible mise à jour est déployée pendant l'exécution d'une application, celle-ci peut déterminer au moyen de CheckForManifestUpdate si des modifications de configuration sont présentes ([SWS_PER_00576]). Avec ReloadPersistencyManifest, ara::per relit la configuration mise à jour, après quoi les définitions de stockage modifiées deviennent actives après la fermeture et la réouverture suivantes ([SWS_PER_00577]).
Pour la migration des données d'application existantes, une fonction de rappel est enregistrée via RegisterApplicationDataUpdateCallback ; elle est déclenchée par ara::per lorsqu'une migration de données est nécessaire sur la base de versions de contrat divergentes ([SWS_PER_00356]). Les modifications ponctuelles d'éléments individuels peuvent être surveillées via RegisterDataUpdateIndication ([SWS_PER_00578]). L'ensemble du processus de mise à jour de la persistance est initié pendant la phase de vérification par UpdatePersistency ([SWS_PER_00357]). Après une mise à jour réussie, CleanUpPersistency supprime les données de sauvegarde et de migration obsolètes ([SWS_PER_00567]), tandis que ResetPersistency vide entièrement les zones de stockage, de sorte qu'elles soient recréées initialement à partir du manifeste lors de la prochaine ouverture ([SWS_PER_00358]).
Diagramme de séquence : déroulement d'une mise à jour de la persistance avec contrôle de configuration, migration par callback et nettoyage. Sources : [SWS_PER_00356], [SWS_PER_00357], [SWS_PER_00567], [SWS_PER_00576], [SWS_PER_00577], EXP_SWArchitecture p. 92.
Surveillance de l'intégrité, gestion de la redondance et restauration
Afin d'intercepter les enregistrements corrompus, les stockages clé-valeur et de fichiers prennent en charge des copies de redondance configurables et des mécanismes d'intégrité (CRC, hachage, authentification MAC et chiffrement) (SWS_Persistency p. 104, EXP_SWArchitecture p. 230). Si des contrôles de redondance internes échouent, les applications critiques pour la sécurité peuvent être informées via RegisterRecoveryReportCallback ([SWS_PER_00433]). Le callback transmet le RecoveryReportKind (par ex. kKeyValueStorageRecoveryFailed) ainsi que les instances et clés/noms de fichiers concernés ([SWS_PER_00432], EXP_SWArchitecture p. 91).
Pour la restauration ciblée de données endommagées, des méthodes granulaires de réparation et de réinitialisation sont disponibles :
- Restauration : au niveau du stockage,
RecoverKeyValueStorage([SWS_PER_00333]) etRecoverAllFiles([SWS_PER_00335]) permettent la réparation de conteneurs fermés ; au niveau des éléments,RecoverKey([SWS_PER_00427]) etRecoverFile([SWS_PER_00337]) restaurent des entrées individuelles endommagées selon une approche au mieux (best-effort). - Réinitialisation aux valeurs d'usine : via
ResetKeyValueStorage([SWS_PER_00334]) etResetAllFiles([SWS_PER_00336]), les conteneurs peuvent être réinitialisés à l'état de livraison initiale ; de manière analogue,ResetKey([SWS_PER_00426]) ouResetFile([SWS_PER_00338]) replacent des éléments individuels dans leur état initial configuré.
Diagramme d'activité : chemin de décision en cas de corruption de données, du contrôle de redondance jusqu'à la restauration ou la réinitialisation en passant par les rappels. Sources : [SWS_PER_00333], [SWS_PER_00334], [SWS_PER_00432], [SWS_PER_00433].
Comportement en cas d'erreur
Les états d'erreur ne sont pas propagés dans ara::per par des exceptions C++ incontrôlées, mais sont représentés de manière déterministe via le type de retour ara::core::Result ([SWS_PER_00044], [SWS_PER_00113]). Le module définit son propre domaine d'erreurs via GetPerDomain ([SWS_PER_00352]), implémenté par PerErrorDomain avec résolution standardisée des erreurs via Name ([SWS_PER_00314]) et Message ([SWS_PER_00315]) ainsi que l'énumération PerErrc ou l'alias de type Errc ([SWS_PER_00311], [SWS_PER_00411]). Pour les environnements avec exceptions activées, PerException ([SWS_PER_00355], [SWS_PER_00412]) et ThrowAsException ([SWS_PER_00350]) sont disponibles, tandis que MakeErrorCode encapsule la création de codes d'erreur conformes à la plateforme ([SWS_PER_00351]).
Les codes d'erreur typiques couvrent les conflits liés aux ressources et à la concurrence : des opérations telles que OpenKeyValueStorage ([SWS_PER_00052]), OpenFileStorage ([SWS_PER_00116]), DeleteFile ([SWS_PER_00111]) ou RecoverKeyValueStorage ([SWS_PER_00333]) échouent avec kResourceBusy si l'élément de stockage concerné est déjà ouvert ou s'il est modifié en parallèle par des opérations de maintenance telles que UpdatePersistency. Lors de l'affectation de types incompatibles, SetValue signale l'erreur kDataTypeMismatch ([SWS_PER_00046]). En cas d'erreurs matérielles physiques (PerErrc::kPhysical), une distinction est faite selon qu'une sémantique de rollback est présente (par exemple lors d'opérations de lecture et de positionnement telles que [SWS_PER_00167], [SWS_PER_00168], où les pointeurs restent inchangés) ou qu'une corruption de données sans garantie de rollback peut survenir (par exemple avec [SWS_PER_00122], [SWS_PER_00166], [SWS_PER_00423]).
Pour le diagnostic des erreurs de synchronisation et d'accès, le module génère des messages de journalisation DLT standardisés (SWS_Persistency p. 110). À cet égard, des messages tels que SyncToStorage (Message-ID 0x80008037), SyncToFile (0x80008036) et DiscardPendingChanges (0x80008038) consignent en détail les ensembles de clés affectés et les allocations d'espace mémoire, ce qui permet de reconstituer l'état même en cas d'arrêt incomplet (par exemple via ara::core::Deinitialize) (SWS_Persistency p. 110).
Preuves détaillées supplémentaires
L'architecture et l'interaction du cluster de persistance s'appuient sur les exigences normatives et passages de documents suivants :
- Interfaces architecturales et couplage de clusters : la mise à disposition de
KeyValueStorageetFileStorageaux démons de plateforme de niveau supérieur est ancrée dans EXP_SWArchitecture p. 90, EXP_SWArchitecture p. 87, EXP_SWArchitecture p. 55 (State Management), EXP_SWArchitecture p. 145 (VUCM), EXP_SWArchitecture p. 176 (DM) et SWS_RemotePersistency p. 9. - Calcul de mémoire et contrôle des quotas : la détermination des tailles allouées au niveau des conteneurs et des fichiers repose sur [SWS_PER_00405], [SWS_PER_00406], [SWS_PER_00407] ainsi que sur les scénarios d'interaction associés dans EXP_SWArchitecture p. 231 et EXP_SWArchitecture p. 231.
- Intégrité transactionnelle et raccordement cryptographique : le déroulement de commit en deux étapes via la gestion en mémoire et la sécurisation au moyen du Cryptography Stack reposent sur [SWS_PER_00049], [SWS_PER_00365] et EXP_SWArchitecture p. 230.
- Framework de mise à jour et de migration : la coordination des mises à jour logicielles et des rechargements de manifestes est spécifiée via [SWS_PER_00356], [SWS_PER_00357], [SWS_PER_00567], [SWS_PER_00576], [SWS_PER_00577] et EXP_SWArchitecture p. 92.
Ce guide de module est basé sur les spécifications de la version AUTOSAR Adaptive R25-11. Les déclarations reposent exclusivement sur les exigences obligatoires des SWS et sur les documents d'architecture associés.
function: 116 class: 10 enumeration: 6 variable: 5 type alias: 2 struct: 1
Carte des thèmes
ara::per
37Aucune donnée d'élément pour cette version
ara::per
FileAccessor contains a common basis for ReadAccessor and WriteAccessor
base de ReadAccessor, WriteAccessor
This structure contains additional information on a file returned by GetFileInfo.
The File Storage contains a set of files identified by their file names.
The Key-Value Storage contains a set of keys with associated values.
Defines the error domain for Persistency.
hérite de ara::core::ErrorDomain
Exception type thrown by Persistency.
hérite de ara::core::Exception
ReadWriteAccessor is used to read and write file data
hérite de ReadAccessor, WriteAccessor
Handle to a ReadAccessor or ReadWriteAccessor
Checks for updates of the Persistency Target Configuration. This method can be used to detect configuration updates that are installed by UCM while the Adaptive Application that uses Persistency is running. To re-read the updated Target Configuration, the Adaptive Application needs to call ara::per:: ReloadPersistencyManifest.
ara::core::Result< bool > CheckForManifestUpdate () noexcept;Removes backup data and other unused data of all Persistency Key-Value Storages and File Storages.
ara::core::Result< void > CleanUpPersistency () noexcept;Returns the space in bytes currently occupied by a File Storage. The returned size includes all metadata and the space used for redundancy and backups. The returned size is only guaranteed to be accurate if the File Storage is not opened and no other operation on the File Storage takes place at the same time.
ara::core::Result< std::uint64_t > GetCurrentFileStorageSize (const ara::core::InstanceSpecifier &fs) noexcept;Returns the space in bytes currently occupied by a Key-Value Storage. The returned size includes all metadata and the space used for redundancy and backups. The returned size is only guaranteed to be accurate if the Key-Value Storage is not opened and no other operation on the Key-Value Storage takes place at the same time.
ara::core::Result< std::uint64_t > GetCurrentKeyValueStorageSize (const ara::core::InstanceSpecifier &kvs) noexcept;Returns the global PerErrorDomain object.
constexpr const ara::core::ErrorDomain & GetPerDomain () noexcept;Creates an error code.
constexpr ara::core::ErrorCode MakeErrorCode (PerErrc code, ara::core::ErrorDomain::SupportDataType data) noexcept;Opens a File Storage. OpenFileStorage will fail with kResourceBusy when the File Storage is currently being modified by a call from another thread to UpdatePersistency, CleanUpPersistency, ResetPersistency, RecoverAllFiles, or ResetAllFiles. Because multiple threads can access the same File Storage concurrently, the File Storage might not be closed when the SharedHandle returned by this function goes out of scope. It will only be closed when all SharedHandles that refer to the same File Storage went out of scope.
ara::core::Result< SharedHandle< FileStorage > > OpenFileStorage (const ara::core::InstanceSpecifier &fs) noexcept;Opens a Key-Value Storage. OpenKeyValueStorage will fail with kResourceBusy when the Key-Value Storage is currently being modified by a call from another thread to UpdatePersistency, CleanUpPersistency, Reset Persistency, RecoverKeyValueStorage, or ResetKeyValueStorage. Because multiple threads can access the same Key-Value Storage concurrently, the Key-Value Storage might not be closed when the SharedHandle returned by this function goes out of scope. It will only be closed when all SharedHandles that refer to the same Key-Value Storage went out of scope.
ara::core::Result< SharedHandle< KeyValueStorage > > OpenKeyValue Storage (const ara::core::InstanceSpecifier &kvs) noexcept;Recovers a File Storage, including all files. RecoverAllFiles recovers a File Storage when the redundancy checks fail. It will fail with kResourceBusy when the File Storage is currently open, or when it is modified by a call from another thread to UpdatePersistency, CleanUpPersistency, ResetPersistency, RecoverAllFiles, or ResetAllFiles. This method does a best-effort recovery of all files. After recovery, files might show outdated or initial content, or might be lost.
ara::core::Result< void > RecoverAllFiles (const ara::core::Instance Specifier &fs) noexcept;Recovers a Key-ValueStorage. RecoverKeyValueStorage allows to recover a Key-Value Storage when the redundancy checks fail. It will fail with kResourceBusy when the Key-Value Storage is currently open, or when it is modified by a call from another thread to UpdatePersistency, CleanUpPersistency, Reset Persistency, RecoverKeyValueStorage, or ResetKeyValueStorage. This method does a best-effort recovery of all key-value pairs. After recovery, keys might show outdated or initial value, or might be lost.
ara::core::Result< void > RecoverKeyValueStorage (const ara::core::InstanceSpecifier &kvs) noexcept;Registers an application data update callback with Persistency. The provided callback function will be called by Persistency if an update of stored application data might be necessary. This decision is based on the contract versions. The contract version that last accessed Persistency is provided as an argument to the callback, as well as the ara::core::InstanceSpecifier referring to the updated Key- Value Storage or File Storage. Based on this information, the Adaptive Application can decide which updates are actually necessary, e.g. a migration from any older contract version could be supported, with different steps required for each of these. The provided function will be called from the context of ara::per::UpdatePersistency, ara::per::OpenKeyValueStorage, or ara::per::OpenFileStorage.
void RegisterApplicationDataUpdateCallback (std::function< void(const ara::core::InstanceSpecifier &storage, ara::core::String contract Version)> appDataUpdateCallback) noexcept;Registers a data update indication callback with Persistency. The provided callback function will be called by Persistency when an update of stored data happened. It will be called from the context of ara::per::UpdatePersistency, ara:: per::OpenKeyValueStorage, or ara::per::OpenFileStorage.
void RegisterDataUpdateIndication (std::function< void(const ara::core::InstanceSpecifier &updatedStorage, ara::core::StringView updatedElement)> dataUpdateIndication, ara::core::InstanceSpecifier monitoredStorage, ara::core::Vector< ara::core::String > monitored Elements) noexcept;Register a recovery reporting callback with Persistency. This callback can be used in safety-aware Adaptive Applications to detect actions of the Persistency that are related to the correctness of the persisted data and the reliability of the storage.
void RegisterRecoveryReportCallback (std::function< void(const ara::core::InstanceSpecifier &storage, ara::per::RecoveryReportKind recoveryReportKind, ara::core::Vector< ara::core::String > reported Elements, ara::core::Vector< std::uint8_t > reportedInstances)> recoveryReportCallback) noexcept;Re-reads the Target Configuration. This method can be used to prepare for updates of the Key-Value Storages and File Storages of Persistency after a new Target Configuration was installed by UCM while the Adaptive Application that uses Persistency is running. Storages are only updated after closing them, either when they are opened again or by an explicit call to ara:: per::UpdatePersistency.
ara::core::Result< void > ReloadPersistencyManifest () noexcept;Resets a File Storage, including all files. ResetAllFiles resets a File Storage to the initial state, containing only the files which were deployed from the Target Configuration, with their initial content. Afterwards, the File Storage will appear as if it was newly installed from the current Target Configuration. It will fail with kResourceBusy when the File Storage is currently open, or when it is modified by a call from another thread to UpdatePersistency, CleanUpPersistency, ResetPersistency, RecoverAllFiles, or ResetAllFiles.
ara::core::Result< void > ResetAllFiles (const ara::core::Instance Specifier &fs) noexcept;Resets a Key-Value Storage to the initial state. ResetKeyValueStorage allows to reset a Key-Value Storage to the initial state, containing only key-value pairs which were deployed from the Target Configuration, with their initial values. Afterwards, the Key-Value Storage will appear as if it was newly installed from the current Target Configuration. It will fail with kResourceBusy when the Key-Value Storage is currently open, or when it is modified by a call from another thread to UpdatePersistency, CleanUpPersistency, Reset Persistency, RecoverKeyValueStorage, or ResetKeyValueStorage.
ara::core::Result< void > ResetKeyValueStorage (const ara::core::InstanceSpecifier &kvs) noexcept;Resets all Key-Value Storages and File Storages by entirely removing their content. The Key-Value Storages and File Storages will be re-created when ara::per:: OpenFileStorage or ara::per::OpenKeyValueStorage is called next time.
ara::core::Result< void > ResetPersistency () noexcept;Updates all Persistency Key-Value Storages and File Storages after a new Target Configuration was installed. This method can be used to update the persistent data of the Adaptive Application during verification phase.
ara::core::Result< void > UpdatePersistency () noexcept;This enumeration describes how and when a file was created.
enum class FileCreationState : std::uint32_t {...};This enumeration describes how and when a file was last modified.
enum class FileModificationState : std::uint32_t {...};This enumeration defines how a file shall be opened. The values can be combined (using | and |=) as long as they do not contradict each other.
enum class OpenMode : std::uint32_t {...};Specification of origin used in MovePosition.
enum class Origin : std::uint32_t {...};Defines the errors for Persistency. The enumeration values 0 - 255 are reserved for AUTOSAR assigned errors, the stack provider is free to define additional errors starting from 256.
enum class PerErrc : ara::core::ErrorDomain::CodeType {...};Defines the reported recovery actions.
enum class RecoveryReportKind : std::uint32_t {...};Namespaces
- ara::per 11 Klassen, 20 freie Funktionen
Diagramme de classes UML du module
Abgerundete Rahmen = Namespaces; hohle Dreieckspfeile = Vererbung (zeigt zur Basisklasse); graue Boxen = modulfremde bzw. externe Basisklassen. Klicken öffnet die Klassenseite.
gemini-3.8-flash-low· 2026-10-13 · Original allemand