classe ara::diag::SovdOperationExecution

L’interface sert au pilotage et à la surveillance spécifiques à l’application d’une opération SOVD en cours dans Diagnostic Management [SWS_DM_02197]. Via des méthodes protégées, elle traite les interrogations d’état ainsi que les demandes d’exécution de capacités spéciales ou d’interruption de l’opération. Tous les retours s’effectuent de manière asynchrone via des futures, les erreurs étant obligatoirement transmises sous forme de codes d’erreur SOVD standardisés selon ISO 17978-3 [SWS_DM_02384]. De plus, les implémentations doivent être sûres pour les threads et lier strictement les gestionnaires d’annulation (Cancellation-Handler) transmis à la durée de vie de l’opération.

plus ›

Contexte

La classe ara::diag::SovdOperationExecution définit l’interface de programmation pour le pilotage et la surveillance des exécutions d’opérations SOVD (Service-Oriented Vehicle Diagnostics) en cours au sein du module diag de l’AUTOSAR Adaptive Platform [SWS_DM_02197], SWS Diagnostics §8.62.5 « Class: SovdOperationExecution ». Elle agit comme lien entre le Diagnostic Management (DM) et la logique applicative d’exécution pour les routines liées au diagnostic selon ASAM SOVD et ISO 17978-3.

Lorsqu’un client SOVD externe initie le démarrage d’une opération [SWS_DM_01396] et que la validation optionnelle du Proximity Challenge a été franchie avec succès [SWS_DM_02174], le DM instancie ou lie l’exécution à un identifiant unique (execution-id) [SWS_DM_02177]. Tous les appels de méthode ultérieurs relatifs à cette opération en cours – en particulier les interrogations d’état et les ordres d’interruption – sont transmis par le DM à l’instance de ara::diag::SovdOperationExecution assignée à cet identifiant [SWS_DM_02180].

Diagramme de contexte : intégration de SovdOperationExecution entre le client SOVD, le Diagnostic Management et la logique d’opération spécifique à l’application. Sources : [SWS_DM_01396], [SWS_DM_02180], [SWS_DM_02197].

Cycle de vie

La classe possède un constructeur par défaut déclaré comme noexcept=default [SWS_DM_02198] ainsi qu’un destructeur virtuel également défini comme noexcept=default [SWS_DM_02199]. Étant donné que toutes les méthodes métier – ExecuteCapability [SWS_DM_02384], GetStatus [SWS_DM_02201] et Terminate [SWS_DM_02202] – sont purement virtuelles (= 0) et protégées (protected), la classe ne peut pas être instanciée directement. Interprétation : les développeurs d’applications dérivent leurs propres classes de SovdOperationExecution afin d’implémenter les routines spécifiques à l’application. Question Q-c1d622c7aa17382d (ouverte)

Chaque exécution d’opération active est associée dans le DM à une execution-id [SWS_DM_02177], [SWS_DM_02180]. La spécification souligne que les opérations n’autorisent souvent qu’une seule instance concurrente SWS Diagnostics §7.3.3.5.5.6 « Operations – Terminate execution of an operation ». Toutes les méthodes d’interface sont spécifiées comme sûres pour les threads (thread-safe) et sûres vis-à-vis des exceptions (exception safe) [SWS_DM_02384], [SWS_DM_02201], [SWS_DM_02202].

Concernant la gestion de la mémoire et les durées de vie, des exigences strictes s’appliquent : le paramètre sovd_content_data reste valide tant que la promesse associée n’est pas satisfaite ou que le traitement n’a pas été interrompu via le cancellation_handler [SWS_DM_02384]. L’objet cancellation_handler lui-même ne doit en aucun cas être stocké ou appelé au-delà de la durée de vie de l’opération respective [SWS_DM_02384], [SWS_DM_02201], [SWS_DM_02202].

Parcours d'utilisation

Le déroulement typique pour accompagner une opération SOVD se divise selon les étapes suivantes :

• Demander des capacités : le DM peut demander des actions telles que l’exécution, le gel ou la réinitialisation pour une opération en cours via la méthode ExecuteCapability [SWS_DM_02384].
• Interroger l’état : si le DM reçoit l’appel SOVD « Read the Status of an operation » et que la validation de proximité requise réussit [SWS_DM_02173], il appelle GetStatus de l’instance SovdOperationExecution assignée [SWS_DM_02180], [SWS_DM_02201]. Après un retour réussi, le DM répond au client avec les attributs status (issu de GetStatusResponse.status), capability (valeur execute) et parameters (déduit de GetStatusResponse.Parameters) [SWS_DM_02181].
• Terminer l’opération : si le Diagnostic Server reçoit la méthode SOVD « Terminate execution of an Operation » [SWS_DM_01392], la méthode Terminate est appelée sur l’instance en indiquant le motif (TerminateOperationExecutionReason) après validation de la réponse de proximité [SWS_DM_01391] [SWS_DM_02179], [SWS_DM_02202].

Diagramme de séquence : séquence d’interactions entre Diagnostic Management et SovdOperationExecution lors d’interrogations d’état et de terminaisons contrôlées. Sources : [SWS_DM_02180], [SWS_DM_02181], [SWS_DM_02179], [SWS_DM_02202].

Scénarios d'erreur

Toutes les méthodes à exécuter (ExecuteCapability, GetStatus, Terminate) fonctionnent de manière asynchrone et renvoient un ara::core::Future [SWS_DM_02384], [SWS_DM_02201], [SWS_DM_02202]. Si le traitement échoue au sein de l’application, le future doit être satisfait avec un code d’erreur SOVD applicable selon ISO 17978-3 ou ASAM SOVD 1.1 [SWS_DM_02384], [SWS_DM_02201], [SWS_DM_02202].

Si une requête en cours est annulée du côté du framework de diagnostic, le DM le signale via l’objet ara::diag::CancellationHandler fourni [SWS_DM_02384]. L’implémentation doit prendre en compte l’état d’annulation de ce gestionnaire et interrompre le traitement sans délai afin d’éviter les états bloquants.