classe apext::diag::uds_transport::UdsTransportProtocolPeriodicHandler

La classe apext::diag::uds_transport::UdsTransportProtocolPeriodicHandler fournit une interface purement virtuelle pour le traitement du service UDS périodique 0x2A via des canaux de diagnostic spécifiques au transport ([SWS_DM_01064]). Elle permet à la gestion du diagnostic de déterminer les limites de charge utile et de quantité spécifiques au canal ainsi que d'assurer la transmission ordonnée de plusieurs messages UDS au moyen de PeriodicTransmit ([SWS_DM_01067]). Si l'envoi d'un message échoue, l'opération est interrompue et l'état est signalé via une fonction de confirmation. Toutes les méthodes étant spécifiées comme non thread-safe, les accès concurrents doivent être synchronisés par l'appelant.

plus ›

Contexte

La classe purement virtuelle apext::diag::uds_transport::UdsTransportProtocolPeriodicHandler constitue l'interface standardisée permettant de prendre en charge la lecture périodique de données de diagnostic conformément au service UDS 0x2A ([SWS_DM_01064], AUTOSAR_AP_SWS_Diagnostics §C.3.1 « Class: UdsTransportProtocolPeriodicHandler »). Dans le système de diagnostic d'AUTOSAR Adaptive Platform, elle découple la gestion de diagnostic de niveau supérieur de l'implémentation concrète du réseau et du protocole de transport. Tandis que la gestion de diagnostic évalue les requêtes entrantes pour les transmissions périodiques et assemble les paquets de données correspondants, le gestionnaire prend en charge la transmission effective de ces messages périodiques via une connexion concrète ([SWS_DM_01067]). Les partenaires d'interaction sont la gestion de diagnostic côté appelant ainsi que le canal de communication respectif, identifié par un ChannelID unique ([SWS_DM_01065], [SWS_DM_01066]).

Diagramme de contexte : intégration de l'UdsTransportProtocolPeriodicHandler entre le serveur de diagnostic et la couche de transport. Sources : [SWS_DM_01064], [SWS_DM_01067], AUTOSAR_AP_SWS_Diagnostics §C.3.1 « Class: UdsTransportProtocolPeriodicHandler ».

Cycle de vie

Étant donné que UdsTransportProtocolPeriodicHandler est définie comme une interface de base abstraite dotée de méthodes purement virtuelles, elle ne peut pas être instanciée directement ([SWS_DM_01064]). L'instanciation de gestionnaires concrets est vraisemblablement effectuée par des composants pilotes spécifiques au transport (par exemple pour les protocoles basés sur DoIP ou CAN). Question Q-d0b3bf3b0c14dcf6 (ouverte) Le cycle de vie de l'instance est typiquement lié à la disponibilité de la pile de protocoles de transport respective. Pour assurer une destruction polymorphe propre lors de l'arrêt de la pile de communication, la classe fournit un destructeur virtuel ~UdsTransportProtocolPeriodicHandler() ([SWS_DM_02089], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.1.1 « Destructor »).

Concernant la concurrence, toutes les fonctions membres de la classe sont explicitement désignées comme non sûres pour les threads (not thread-safe) ([SWS_DM_01065], [SWS_DM_01066], [SWS_DM_01067], [SWS_DM_02089]). En cas d'accès parallèle via plusieurs threads ou de requêtes simultanées via le même ChannelID, les appelants doivent donc synchroniser les accès sous leur propre responsabilité.

Parcours d'utilisation

Un déroulement typique de réalisation de transmissions de messages périodiques pour le service 0x2A se décompose selon les étapes suivantes :

• Détermination de la longueur maximale des données utiles : la gestion de diagnostic appelle GetMaxPayloadLength(channelId) afin de vérifier la longueur maximale de données utiles prise en charge sur la connexion spécifiée pour une transmission périodique individuelle ([SWS_DM_01066], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.2.1 « GetMaxPayloadLength »).
• Interrogation de la capacité en messages : le nombre possible de messages périodiques spécifique au protocole de transport et à la connexion est interrogé via GetNumberOfPeriodicMessages(channelId) ([SWS_DM_01065], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.2.2 « GetNumberOfPeriodicMessages »).
• Exécution de la transmission périodique : la gestion de diagnostic transmet une liste ordonnée de messages dans un ara::core::Vector<UdsMessageConstPtr> à la méthode PeriodicTransmit(channelId, messages) ([SWS_DM_01067], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.2.3 « PeriodicTransmit »). Le gestionnaire transmet les messages contenus dans l'ordre défini.
• Confirmation : la couche de transport signale le résultat de l'opération d'émission via l'appel de PeriodicTransmit Confirmation, qui renvoie le nombre de messages transmis avec succès ainsi que le vecteur d'origine ([SWS_DM_01067]).

Diagramme de séquence : déroulement typique de l'interrogation de capacité, de l'émission périodique et de la confirmation. Sources : [SWS_DM_01065], [SWS_DM_01066], [SWS_DM_01067].

Scénarios d'erreur

Pendant l'exécution de PeriodicTransmit, tous les messages de la liste sont transmis successivement. Si la transmission d'un message individuel échoue, l'ensemble du processus d'émission est immédiatement interrompu ([SWS_DM_01067]). Les messages suivants de la liste ne sont alors plus envoyés. Pour le diagnostic d'erreurs et l'information de la gestion de diagnostic, l'appel de confirmation PeriodicTransmit Confirmation est néanmoins déclenché. Celui-ci contient le nombre de messages transmis avec succès jusqu'à l'interruption ainsi que, sans modification, le vecteur complet de messages UDS ([SWS_DM_01067]). La gestion de diagnostic peut ainsi déterminer avec exactitude quel message a provoqué l'erreur.

Toutes les méthodes d'interface sont spécifiées comme noexcept et sûres vis-à-vis des exceptions (exception safe) ([SWS_DM_01065], [SWS_DM_01066], [SWS_DM_01067], [SWS_DM_02089]). Les états d'erreur lors de la transmission n'entraînent pas d'exceptions C++, mais sont signalés de manière déterministe par le biais du mécanisme de confirmation prévu.