classe apext::diag::uds_transport::UdsTransportProtocolMgr

Utilisation

La méthode ChannelReestablished de la classe apext::diag::uds_transport::UdsTransportProtocolMgr sert de notification d'une implémentation de protocole de transport UDS au Diagnostic Management (DM) indiquant qu'un canal de communication est à nouveau disponible après un (re)démarrage [SWS_DM_00313]. L'implémentation du protocole de transport appelle cette méthode exactement une fois dès que la nouvelle disponibilité du canal réseau représenté par ChannelID est détectée [SWS_DM_00358]. Le paramètre transmis est globalChannelId, composé du tuple constitué de son propre handlerIdent et de la ChannelID [SWS_DM_00358].

Zusammenspiel et cycle de vie

La condition préalable à la notification est un appel antérieur de NotifyReestablishment [SWS_DM_00313], [SWS_DM_00356]. Le cas d'utilisation typique est l'exécution d'un reset d'ECU (service UDS 0x11) avec l'option d'une réponse positive après le redémarrage [SWS_DM_00326]. Afin de garantir la notification même après un redémarrage du DM, la demande de notification doit être enregistrée de manière persistante par le protocole de transport [SWS_DM_00359].

Gestion des erreurs et concurrence

La fonction ne possède aucune valeur de retour et est spécifiée comme noexcept (exception safe) [SWS_DM_00313]. Étant donné que l'interface est classée comme non thread-safe (not thread-safe) [SWS_DM_00313], les gestionnaires appelants devraient devoir synchroniser les accès en externe. Question Q-aaf14893457cceb6 (ouverte) En tant que contrainte temporelle, le DM ne doit traiter l'appel de ChannelReestablished qu'après l'appel de UdsTransportProtocolHandler::Start [SWS_DM_01744].

La méthode HandleMessage sert à transmettre un message de requête UDS valide et entièrement reçu depuis la couche de transport à la couche de session du Diagnostic Management ([SWS_DM_00311]). Cela correspond au service T_Data.ind selon l'ISO 14229-2 ([SWS_DM_00311], AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.2 « HandleMessage »).

Appel et paramètres

Dès que l'implémentation du protocole de transport a rempli la charge utile du tampon préalablement demandé via IndicateMessage ([SWS_DM_00388]), elle appelle HandleMessage sur l'instance de apext::diag::uds_transport::UdsTransportProtocolMgr ([SWS_DM_00345]). message de type UdsMessagePtr est transmis en tant qu'argument. Grâce à la sémantique de std::unique_ptr, la propriété du message UDS revient au cœur DM générique ([SWS_DM_00311]). La fonction ne renvoie aucune valeur.

Sémantique, concurrence et traitement des erreurs

• Asynchronisme : L'appel doit retourner immédiatement (« instantly returns ») ([SWS_DM_00311]). Interprétation : Le traitement proprement dit de la requête de diagnostic devrait être poursuivi de manière asynchrone dans un contexte d'exécution distinct au sein du cœur DM. Question Q-b8dd1a5f3d2dcdf0 (ouverte)
• Cas d'erreur : La méthode est déclarée comme noexcept et sûre vis-à-vis des exceptions ([SWS_DM_00311]). Si la réception ou le remplissage du message échoue, aucun appel de HandleMessage ne doit avoir lieu ; l'erreur doit être signalée via NotifyMessageFailure à la place ([SWS_DM_00310]).
• Sécurité des threads : L'opération est spécifiée comme not thread-safe ([SWS_DM_00311]). Les appelants doivent synchroniser les accès parallèles à la même instance.

Interaction

L'interface appartient à la couche de protocole de transport et doit être distinguée de la méthode de traitement de service applicative ara::diag::GenericUDSService::HandleMessage ([SWS_DM_00618]).

La méthode de rappel purement virtuelle HandlerStopped de l'interface de gestion apext::diag::uds_transport::UdsTransportProtocolMgr sert de confirmation par un plugin de transport UDS au Diagnostic Manager (DM) indiquant que son exécution est terminée et que toutes les ressources associées ainsi que les connexions réseau ont été entièrement libérées [SWS_DM_00314]. Cet appel est attendu comme réponse obligatoire du handler à un appel antérieur de UdsTransportProtocolHandler::Stop() [SWS_DM_00314], [SWS_DM_00323].

Contexte d'appel et paramètres : Le plugin concerné s'identifie lors de l'appel via le paramètre d'entrée handlerId de type UdsTransportProtocolHandlerID [SWS_DM_00314]. La méthode n'a pas de valeur de retour (void) et garantit une sécurité totale face aux exceptions grâce à sa spécification en tant que noexcept (exception safe) [SWS_DM_00314]. Aucun code d'erreur spécifique, réaction aux erreurs ou message à DET ou DEM n'est défini pour cette interface.

Déroulement et restrictions : Lorsque le Diagnostic Manager passe à l'état ApplicationState.kTerminating au cours de l'arrêt, il appelle d'abord Stop() sur chaque implémentation de protocole de transport UDS démarrée [SWS_DM_00333]. Après le retour de Stop(), une interdiction stricte d'appel s'applique : le plugin du handler ne doit plus appeler aucune autre méthode envers UdsTransportProtocolMgr, à l'exception de HandlerStopped [SWS_DM_01741], [SWS_DM_00323]. Avant l'arrêt définitif du processus DM, celui-ci attend l'arrivée du rappel HandlerStopped respectif avec l'handlerId correspondante [SWS_DM_00340]. L'interface est désignée comme non thread-safe (not thread-safe) [SWS_DM_00314]. Interprétation : comme le DM attend séparément l'arrivée du rappel, l'arrêt effectif des connexions réseau dans le plugin devrait se dérouler de manière asynchrone par rapport au retour de la méthode Stop(). Question Q-40829d46bd661337 (ouverte)

La méthode IndicateMessage [SWS_DM_00309] de la classe apext::diag::uds_transport::UdsTransportProtocolMgr est appelée de manière synchrone par un UdsTransportProtocolHandler lorsque le début de la réception d'un message UDS doit être signalé et que le handler le prend en charge. L'appelant transmet l'adresse source et de destination (sourceAddr, targetAddr), le type d'adressage type (physique ou fonctionnel), l'ID de canal globalChannelId, la taille totale attendue size ainsi que, de manière facultative, une vue en octets sur des données utiles déjà reçues (payloadInfo). La mise à disposition d'au moins deux octets dans payloadInfo est recommandée afin que le Diagnostic Management Core puisse reconnaître des requêtes fonctionnelles telles que Tester-Present (logique de contournement) y compris pendant un traitement en cours AUTOSAR_AP_SWS_Diagnostics §7.1 « UDS Transport Layer ».

Comme valeur de retour, l'appel synchrone et sûr face aux exceptions renvoie un std::pair composé de IndicationResult [SWS_DM_00384] et d'un UdsMessagePtr [SWS_DM_00309] :

• Acceptation : Si le message peut être traité, le DM Core renvoie IndicationResult::kIndicationOk conjointement avec un UdsMessagePtr valide dont la capacité minimale est d'au moins un octet [SWS_DM_00385].
• Rejet et cas d'erreur : Si le DM est surchargé, il répond par kIndicationOccupied et nullptr [SWS_DM_00386]. En cas d'adresse de destination invalide, kIndicationUnknownTargetAddress est renvoyé avec un pointeur nul. D'autres valeurs de statut définies sont kIndicationOverflow [SWS_DM_00384].

En matière de concurrence et de durée de vie, la méthode est spécifiée comme non thread-safe (not thread-safe) [SWS_DM_00309] ; les appels doivent donc être synchronisés en conséquence. La vue transmise via payloadInfo est volatile et ne doit être utilisée qu'au sein de cet appel de fonction [SWS_DM_00309].

Dans la suite du déroulement, lors du retour de kIndicationOk, la couche de transport remplit le tampon fourni via GetPayload [SWS_DM_00301] jusqu'à la limite de capacité ou jusqu'à la longueur complète du message [SWS_DM_00388]. Après un remplissage réussi, HandleMessage est appelé [SWS_DM_00345]. Si la réception du message échoue prématurément, le handler doit restituer le tampon au DM via NotifyMessageFailure [SWS_DM_00310].

Utilisation

La méthode virtuelle pure NotifyMessageFailure est mise à disposition via l'en-tête apext/diag/uds_transport/protocol_mgr.h dans l'interface apext::diag::uds_transport::UdsTransportProtocolMgr [SWS_DM_00310]. Elle sert à l'implémentation du protocole de transport à indiquer au Diagnostic Management qu'un message préalablement signalé via IndicateMessage() a échoué et qu'aucun appel final de HandleMessage() [SWS_DM_00345] n'aura plus lieu [SWS_DM_00310]. Le pointeur message de type UdsMessagePtr est transmis en tant que paramètre, ce qui permet de restituer le message concerné à la couche de session [SWS_DM_00310]. Aucune valeur de retour n'existe (void).

Gestion des erreurs et concurrence

La fonction est déclarée comme noexcept et sûre vis-à-vis des exceptions [SWS_DM_00310]. Elle ne lève aucune exception et signale les interruptions de transmission uniquement via l'interface de paramètres. En ce qui concerne la concurrence, la méthode est classée comme non thread-safe (not thread-safe) [SWS_DM_00310]. Interprétation : les appelants devraient devoir assurer une synchronisation externe en cas de traitement parallèle au niveau du protocole de transport. Question Q-8d9b3a3561b9b6ac (ouverte)

Interaction et déroulement

Dans le déroulement régulier, le protocole de transport remplit la charge utile du UdsMessage [SWS_DM_00388] après un IndicateMessage() réussi et la transmet au Diagnostic Management via HandleMessage() [SWS_DM_00345]. Cependant, si la transmission échoue – par exemple lors d'erreurs pendant la réception d'une requête multi-trames –, NotifyMessageFailure est appelé à la place [SWS_DM_00310]. Cela empêche les appels de traitement ultérieurs et influe sur la gestion de session : alors que le temporisateur S3Server est arrêté lors du démarrage de la réception [SWS_DM_00383], une erreur de réception d'un message multi-trames entraîne la réinitialisation du temporisateur S3Server et son redémarrage depuis le début (SWS Diagnostics §7.3.2.7 « Session handling » / [SWS_DM_00310]).

Utilisation

La méthode virtuelle pure PeriodicTransmitConfirmation fait partie de la classe apext::diag::uds_transport::UdsTransportProtocolMgr et est déclarée via le fichier d'en-tête apext/diag/uds_transport/protocol_mgr.h [SWS_DM_01069]. Elle sert à confirmer les messages de diagnostic périodiques envoyés ainsi qu'à transmettre le nombre de messages expédiés avec succès AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.6 « PeriodicTransmitConfirmation ».

Lors de l'appel, deux paramètres d'entrée sont transmis, tandis que la méthode ne fournit aucune valeur de retour :

• messages (ara::core::Vector<UdsMessageConstPtr>) : la même liste ordonnée de messages que celle préalablement transmise à la méthode UdsTransportProtocolPeriodicHandler::PeriodicTransmit() [SWS_DM_01069].
• numberOfSentMessages (std::size_t) : le nombre de messages de la liste messages transférés avec succès [SWS_DM_01069].

Traitement des erreurs et sécurité vis-à-vis des exceptions

En ce qui concerne la sécurité face aux exceptions, l'interface est spécifiée comme exception safe et pourvue de l'identificateur noexcept [SWS_DM_01069]. Elle ne lève donc aucune exception C++. Aucun code d'erreur spécifique ou message d'erreur via DET ou DEM n'est défini dans la spécification pour cette fonction de confirmation.

Concurrence et contraintes

La fonction est classée selon la spécification comme non sûre vis-à-vis des threads (not thread-safe) [SWS_DM_01069]. Les appels concurrents sur la même instance ne sont par conséquent pas sécurisés et doivent être coordonnés par l'appelant.

Interaction

La fonction s'inscrit directement à la suite du processus d'envoi périodique : elle reçoit la confirmation des messages effectivement émis après un appel de UdsTransportProtocolPeriodicHandler::PeriodicTransmit() AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.6 « PeriodicTransmitConfirmation ». Au niveau des exigences, la fonction est associée à l'exigence en amont RS_Diag_04215 [SWS_DM_01069].

Utilisation

La méthode purement virtuelle TransmitConfirmation de l'interface apext::diag::uds_transport::UdsTransportProtocolMgr sert à notifier le Diagnostic Management (DM) de l'achèvement d'un ordre d'émission préalablement initié par le DM via UdsTransportProtocolHandler::Transmit [SWS_DM_00312] [SWS_DM_00348]. La fonction met en œuvre le service primitif T_Data.con conformément à l'ISO 14229-2 [SWS_DM_00312].

Deux paramètres sont transmis lors de l'appel [SWS_DM_00312] :

• message (UdsMessageConstPtr) : pointeur vers le message UDS qui a été préalablement mis à disposition dans IndicateMessage() et dont la transmission est acquittée [SWS_DM_00312].
• result (TransmissionResult) : indique le résultat de la transmission. Si la couche réseau a réussi à émettre la réponse UDS sur le réseau, la valeur doit être définie sur kTransmitOk, sinon sur kTransmitFailed [SWS_DM_00351] SWS Diagnostics §7.1.1.3 « Confirmation Result ».

La méthode ne possède aucune valeur de retour (void) et est déclarée comme noexcept, raison pour laquelle elle doit être exécutée sans lever d'exceptions [SWS_DM_00312].

Concurrence et comportement du système

L'interface est explicitement spécifiée comme non sûre pour les threads [SWS_DM_00312]. Les appels issus de contextes réseau ou de gestionnaires concurrents devraient donc nécessiter une synchronisation externe par l'implémentation du protocole de transport. Question Q-e540ca89c3f61ecb (ouverte)

De plus, l'appel influe sur la gestion de l'authentification : si un client se trouve dans la session par défaut et dans l'état kAuthenticated, le serveur de diagnostic le fait passer à l'état kDeAuthenticated si aucune nouvelle requête n'est reçue pendant une durée de authenticationTimeout après le dernier TransmitConfirmation [SWS_DM_01210].