classe ara::diag::DataTransferReadByPushHandler

La classe ara::diag::DataTransferReadByPushHandler sert d'interface de base pour les transferts de lecture UDS, dans lesquels l'application partitionne et met à disposition activement les contenus de fichiers [SWS_DM_01515]. Les blocs de données sont transmis séquentiellement via Read() et la session de transfert est ensuite close de manière ordonnée via ExitRead() [SWS_DM_01523]. Chaque handler est strictement lié à exactement une session de transfert, raison pour laquelle les opérations de copie sont interdites. En tant que condition essentielle de cycle de vie, l'instance ne doit en aucun cas être détruite avant l'appel de ExitRead() [SWS_DM_01519].

plus ›

Contexte

La classe ara::diag::DataTransferReadByPushHandler fait office de classe de base et d'interface pour les transferts de données de diagnostic initiés par des requêtes telles que RequestReadFile ou RequestReadDirectory [SWS_DM_01515]. Le modèle de transfert sous-jacent repose sur le principe du push : les données de fichiers ou de répertoires sont activement partitionnées en paquets par l'implémentation spécifique de l'application et transmises à la gestion du diagnostic (Diagnostic Management, DM) AUTOSAR_AP_SWS_Diagnostics §8.10.3 « Class: DataTransferReadByPushHandler ». L'interaction a lieu entre le client UDS externe, le composant de plateforme ara::diag et l'implémentation concrète de handler de l'application.

Diagramme de contexte : intégration du handler push entre le client UDS externe et le Diagnostic Management. Sources : [SWS_DM_01515], AUTOSAR_AP_SWS_Diagnostics §8.10.3 « Class: DataTransferReadByPushHandler »

Cycle de vie

Comme DataTransferReadByPushHandler est conçue comme une classe de base abstraite, le constructeur sans paramètre a une visibilité protégée (protected) [SWS_DM_01516]. L'instanciation s'effectue dans le contexte d'une classe dérivée au sein de l'application. Les instances sont strictement liées à exactement une session de transfert de fichiers (« one way usage ») ; en conséquence, le constructeur de copie [SWS_DM_01518] ainsi que l'opérateur d'assignation par copie [SWS_DM_01521] sont explicitement supprimés (=delete). Un transfert de propriété est possible via des opérations de déplacement, car le constructeur de déplacement [SWS_DM_01517] et l'assignation par déplacement [SWS_DM_01520] existent en tant qu'implémentations par défaut et sont déclarés sûrs vis-à-vis des exceptions (noexcept).

Pour la destruction du handler, la spécification définit une précondition stricte : une instance ne doit en aucun cas être détruite avant que la session n'ait été close via l'appel de ExitRead() [SWS_DM_01519], AUTOSAR_AP_SWS_Diagnostics §8.10.3.1.1.2 « Destructor ». En ce qui concerne la concurrence, les méthodes virtuelles de la classe sont spécifiées comme non thread-safe (« not thread-safe ») [SWS_DM_01522], [SWS_DM_01523], c'est pourquoi les accès simultanés par la plateforme doivent être synchronisés ou exécutés de manière séquentielle.

Parcours d'utilisation

Le déroulement opérationnel se divise en la mise à disposition répétitive de fragments de données et la clôture ordonnée de la session. Après l'initiation de l'opération de lecture, ara::diag appelle de manière répétée la méthode Read() [SWS_DM_01522], AUTOSAR_AP_SWS_Diagnostics §8.10.3.1.3.2 « Read ». À cette occasion, le framework transmet une valeur indicative pour la taille de retour recommandée en octets (recommended_number_bytes_to_return) afin d'obtenir un débit optimal, ainsi que le contexte de requête (MetaInfo) et un CancellationHandler. L'application génère le paquet de données et en transfère la propriété via un ara::core::Future<ara::core::Vector<ara::core::Byte>> au Diagnostic Management, qui insère les données utiles derrière le compteur de séquence de blocs dans le message de réponse UDS [SWS_DM_01522].

Dès que tous les blocs de données ont été transférés ou que la session doit être terminée, ara::diag appelle la méthode ExitRead() [SWS_DM_01523], AUTOSAR_AP_SWS_Diagnostics §8.10.3.1.3.1 « ExitRead ». Outre le motif de fin (DataTransferExitType exit_type), des paramètres de requête spécifiques au constructeur sont transmis via transfer_request_parameter_record. La durée de vie de cette vue de paramètres (span) est liée de manière obligatoire jusqu'à ce que la promesse correspondante soit résolue ou que le traitement soit interrompu [SWS_DM_01523]. Après le renvoi du jeu final de paramètres de réponse via la Future, le transfert est considéré comme terminé, ce qui remplit la condition requise pour détruire l'objet handler sans risque [SWS_DM_01519].

Diagramme de séquence : séquence d'interaction typique entre le Diagnostic Management et le handler lors d'un transfert de lecture et de la clôture du transfert. Sources : [SWS_DM_01522], [SWS_DM_01523], [SWS_DM_01519]

Scénarios d'erreur

Si une erreur survient pendant l'assemblage de blocs de données ou lors de la clôture de session, elle est signalée de manière asynchrone via le ara::core::Future correspondant. Au lieu d'une structure de réponse positive, le future est fourni avec un code d'erreur (ara::core::ErrorCode) issu de la plage DiagUdsNrcErrc, qui correspond à un code de réponse négative adéquat (Negative Response Code, NRC) selon l'ISO 14229-1 [SWS_DM_01522], [SWS_DM_01523].

Si le dialogue de diagnostic est interrompu ou si le client envoie une requête d'annulation, le CancellationHandler transmis entre en jeu. L'implémentation peut interroger l'état d'annulation actuel via cancellation_handler.IsCanceled() ou enregistrer via cancellation_handler.SetNotifier() une fonction de rappel déclenchée lors de l'interruption de la conversation [SWS_DM_01522], [SWS_DM_01523]. La résolution ou l'interruption de la promesse marque également la fin de la validité du jeu de paramètres dans ExitRead() [SWS_DM_01523].