structure ara::diag::SovdContentConcurrencyType

Le struct ara::diag::SovdContentConcurrencyType spécifie le comportement de concurrence pour les contenus SOVD liés aux ports dans AUTOSAR Adaptive [SWS_DM_02182]. Il contrôle, via trois attributs, si le Diagnostic Management est autorisé à exécuter en parallèle les opérations de lecture et d'écriture sur le port d'application ou s'il doit les sérialiser. Par défaut, tous les champs sont initialisés de manière défensive à kNotConcurrent, de sorte que les développeurs doivent autoriser explicitement la concurrence comme dans readWrite [SWS_DM_02185]. La configuration doit être achevée avant le début de la communication de diagnostic afin de garantir un traitement thread-safe.

plus ›

Contexte

La structure de données ara::diag::SovdContentConcurrencyType est déclarée dans l'en-tête ara/diag/concurrency.h et sert à spécifier le comportement de concurrence pour les ports dans le contexte de Service-Oriented Vehicle Diagnostics (SOVD) [SWS_DM_02182]. Dans les architectures basées sur l'AUTOSAR Adaptive Platform, le Diagnostic Management (DM) fait office d'instance centrale pour le traitement des requêtes de diagnostic entrantes SWS Diagnostics p. 79. Lorsque des clients de diagnostic externes initient des accès en lecture ou en écriture à des contenus de diagnostic via SOVD, le Diagnostic Management doit pouvoir déterminer si l'Adaptive Application fournisseuse ou le port correspondant est capable de traiter plusieurs requêtes de manière concurrente et thread-safe.

Pour cela, SovdContentConcurrencyType définit trois attributs de configuration pour les accès en lecture seule, les accès en écriture seule ainsi que les accès combinés en lecture et en écriture SWS Diagnostics §8.8.3 « Struct: SovdContentConcurrencyType ». La structure fait ainsi office d'interface de configuration entre l'implémentation du port côté application et le contrôle d'exécution du Diagnostic Management.

Diagramme de contexte : interaction entre le Diagnostic Management, SovdContentConcurrencyType et le port SOVD de l'Adaptive Application. Sources : [SWS_DM_02182], [SWS_DM_02185], SWS Diagnostics §8.8.3 « Struct: SovdContentConcurrencyType »

Cycle de vie

En tant que pur struct de configuration et de transfert de données, SovdContentConcurrencyType possède un cycle de vie simple, sans gestion dynamique des ressources ni contrôles d'état internes complexes [SWS_DM_02182].

L'instanciation s'effectue généralement pendant la phase de configuration et d'initialisation de l'Adaptive Application, vraisemblablement sur la pile ou en tant qu'élément d'une classe de gestion de port de niveau supérieur avant le début de la communication de diagnostic. Question Q-f78487eff58a4775 (ouverte) Toutes les variables membres sont initialisées de manière défensive par défaut lors de la création de l'objet :

• read est préaffecté par défaut à ConcurrencyType::kNotConcurrent [SWS_DM_02183].
• write est préaffecté par défaut à ConcurrencyType::kNotConcurrent [SWS_DM_02184].
• readWrite est préaffecté par défaut à ConcurrencyType::kNotConcurrent [SWS_DM_02185].

En ce qui concerne la concurrence et le multi-threading : la structure elle-même est un objet de configuration passif sans mécanismes de synchronisation propres. Les modifications apportées aux champs doivent donc être terminées avant que la structure ne soit transmise au Diagnostic Management ou lue par plusieurs threads. Après l'enregistrement auprès du port, la configuration demeure inchangée pendant toute la durée de vie du port de diagnostic concerné (interprétation : une modification dynamique lors de l'exécution de la communication de diagnostic n'est pas prévue par la spécification). Question Q-71f96ed7cd3a6f61 (ouverte) Le nettoyage de l'instance de structure s'effectue après la fin de sa portée conformément à la sémantique C++ standard, sans nécessiter de nettoyage supplémentaire.

Parcours d'utilisation

Le chemin d'utilisation typique comprend la définition des capacités du port par l'application, la mise à disposition au moment de l'exécution et l'évaluation par le Diagnostic Management :

1. Configuration des capacités : l'Adaptive Application instancie un objet de type SovdContentConcurrencyType. Si l'implémentation des méthodes du port est conçue pour être thread-safe, les attributs correspondants sont explicitement définis à ConcurrencyType::kConcurrent. Le passage de readWrite à kConcurrent signale explicitement au Diagnostic Management que les API de lecture et d'écriture peuvent être appelées simultanément [SWS_DM_02185].
2. Maintien du comportement par défaut : si une implémentation de port n'est pas réentrante ou synchronisée en interne, le développeur laisse les valeurs à kNotConcurrent [SWS_DM_02183], [SWS_DM_02184]. Interprétation : dans ce cas, le Diagnostic Management veille à ce que les requêtes survenant pour ce port soient exécutées de manière séquentielle afin d'éviter les conflits de données. Question (ouverte)
3. Contrôle du flux par le DM : pendant le fonctionnement, le Diagnostic Management reçoit des requêtes SOVD externes. À l'aide de la configuration enregistrée, le DM détermine si des appels de méthode parallèles pour les routines de lecture et d'écriture peuvent être transmis au port ou si une sérialisation est impérative SWS Diagnostics §8.8.3.1.2 « readWrite ».