namespace apext::diag::uds_transport

L’espace de noms apext::diag::uds_transport fournit l’interface de transport C++ destinée à découpler la gestion générique du diagnostic des protocoles de transport UDS spécifiques AUTOSAR_AP_SWS_Diagnostics §7.1 « UDS Transport Layer ». Les greffons de protocole dérivent de la classe de base UdsTransportProtocolHandler et suivent un cycle de vie strict composé de la construction, de l’initialisation, du démarrage et de l’arrêt ordonné [SWS_DM_00329]. Les messages entrants sont signalés via IndicateMessage et reçoivent, en cas de capacités libres, un UdsMessagePtr à mémoire gérée pour la prise en charge des données utiles. Une contrainte centrale est qu’après l’arrêt, aucun autre appel ne doit être adressé à la gestion du diagnostic, à l’exception du message de confirmation.

plus ›

Contexte

L’espace de noms apext::diag::uds_transport définit l’interface de transport C++ standardisée (Transport Protocol API) pour la gestion du diagnostic (DM) dans l’AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_Diagnostics §7.1 « UDS Transport Layer ». L’architecture sépare fonctionnellement le cœur générique de la gestion du diagnostic des couches réseau et de transport concrètes. De cette manière, des protocoles standardisés tels que DoIP ainsi que des protocoles de transport futurs ou spécifiques aux constructeurs (par exemple pour CAN, CAN-FD ou FlexRay) peuvent être intégrés sous forme de greffons modulaires AUTOSAR_AP_SWS_Diagnostics §7.1 « UDS Transport Layer ».

L’instance de médiation centrale est constituée par la classe UdsTransportProtocolMgr, qui coordonne l’interaction entre les instances du Diagnostic Server et les protocoles de transport raccordés. Les greffons de protocole concrets dérivent de la classe de base abstraite UdsTransportProtocolHandler AUTOSAR_AP_SWS_Diagnostics §7.1.1 « Support of UDS Transport Layer » [SWS_DM_00315]. Les différentes instances de gestionnaire sont adressées via UdsTransportProtocolHandlerID [SWS_DM_00336], tandis que les canaux de communication sont identifiés via le type ChannelID [SWS_DM_00337]. Pour prendre en charge les interrogations périodiques de données selon le service ISO 0x2A, l’interface intègre en outre la classe UdsTransportProtocolPeriodicHandler.

Cycle de vie

La gestion du diagnostic pilote le cycle de vie de chaque instance de UdsTransportProtocolHandler selon un ordre strictement prédéfini [SWS_DM_00329] :

1. Création : le DM instancie le greffon de protocole via le constructeur UdsTransportProtocolHandler::UdsTransportProtocolHandler [SWS_DM_00329].
2. Initialisation : le DM appelle UdsTransportProtocolHandler::Initialize [SWS_DM_00329]. Hormis l’interrogation de GetPeriodicHandler, le DM ne doit appeler aucune autre méthode sur le gestionnaire avant le retour réussi de kInitializeOk [SWS_DM_01746].
3. Démarrage et fonctionnement : après une initialisation réussie, le gestionnaire est activé avec UdsTransportProtocolHandler::Start. Ce n’est qu’après cet appel que le DM traite les notifications relatives aux canaux réactivés via UdsTransportProtocolMgr::ChannelReestablished [SWS_DM_01744].
4. Terminaison : lorsque le DM passe à l’état ApplicationState.kTerminating, il appelle UdsTransportProtocolHandler::Stop pour tous les greffons actifs [SWS_DM_00333]. Après le retour de cet appel, le greffon ne doit appeler exclusivement que UdsTransportProtocolMgr::HandlerStopped [SWS_DM_01741]. Le DM attend activement cette confirmation [SWS_DM_00340].

Diagramme d’états : phases du cycle de vie et conditions de transition d’une implémentation de gestionnaire de protocole de transport. Sources : [SWS_DM_00329], [SWS_DM_00333], [SWS_DM_00340], [SWS_DM_01741], [SWS_DM_01744], [SWS_DM_01745], [SWS_DM_01746]

Parcours d'utilisation

En cours de fonctionnement, la transmission des messages de diagnostic entrants s’effectue via une interaction coordonnée entre le gestionnaire et le manager :

1. Indication de message : lorsque le gestionnaire reçoit des données sur un canal (ChannelID [SWS_DM_00337]), il appelle UdsTransportProtocolMgr::IndicateMessage. Ce faisant, il peut transmettre des données utiles préliminaires dans payloadInfo ; il est recommandé de transmettre au moins les deux premiers octets pour la détection précoce des requêtes fonctionnelles AUTOSAR_AP_SWS_Diagnostics §7.1 « UDS Transport Layer ».
2. Allocation de tampon : si le DM est prêt à recevoir, IndicateMessage répond avec un std::pair issu de IndicationResult::kIndicationOk et un pointeur intelligent valide UdsMessagePtr [SWS_DM_00309] [SWS_DM_00385]. L’objet UdsMessage référencé possède une capacité minimale d’un octet [SWS_DM_00385]. Le tampon est géré sous la forme d’un std::unique_ptr doté d’un délecteur spécifique du cœur de DM et n’est pas sûr vis-à-vis des threads [SWS_DM_00303]. Pour les accès en lecture, il existe l’équivalent constant UdsMessageConstPtr [SWS_DM_00304].
3. Transfert de données : le gestionnaire écrit les données de diagnostic reçues dans le tampon mis à disposition, dont la séquence d’octets est typée via le type ByteSpan (alias pour ara::core::Span<ara::core::Byte> [SWS_DM_00338]). Vraisemblablement, la mise à disposition de la classe distincte UdsTransportProtocolPeriodicHandler via GetPeriodicHandler sert à découpler le service de transmission périodique 0x2A de la voie normale des messages UDS. Question Q-230ef0b7c384c594 (ouverte)

Diagramme de séquence : déroulement de l’indication de message et de l’allocation de tampon entre le gestionnaire, le manager et le cœur de DM. Sources : AUTOSAR_AP_SWS_Diagnostics §7.1 « UDS Transport Layer », [SWS_DM_00303], [SWS_DM_00309], [SWS_DM_00385], [SWS_DM_00386]

Scénarios d'erreur

La spécification définit des états d’erreur concrets et des conditions préalables pour le raccordement de transport :

• Échec de l’initialisation : si UdsTransportProtocolHandler::Initialize fournit le résultat kInitializeFailed, le DM interrompt immédiatement le processus d’initialisation pour ce gestionnaire et n’appelle plus aucune méthode sur lui [SWS_DM_01745].
• Rejet en cas de cœur de diagnostic occupé : si le DM est bloqué par le traitement en cours d’un service de la même conversation Tester-Present et qu’il ne s’agit pas d’un Tester-Present fonctionnel avec payloadInfo 0x3E 0x80, IndicateMessage renvoie le résultat kIndicationOccupied conjointement avec un nullptr au lieu d’un tampon de message [SWS_DM_00386].
• Appels non autorisés après la terminaison : si un greffon appelle une méthode de UdsTransportProtocolMgr autre que HandlerStopped après le retour de Stop, cela enfreint les directives du protocole [SWS_DM_01741]. De même, le DM ignore des signaux tels que ChannelReestablished s’ils parviennent avant l’appel réussi de Start [SWS_DM_01744].