classe ara::diag::CommunicationControl

La classe ara::diag::CommunicationControl sert, dans AUTOSAR Adaptive, d'interface pour le traitement du service UDS 0x28 (CommunicationControl) dédié à la commutation des canaux de communication [SWS_DM_00808]. Après l'instanciation basée sur les modèles via un InstanceSpecifier, Offer() active le réacheminement des requêtes par le Diagnostic Manager, lesquelles sont ensuite traitées de manière asynchrone via CommCtrlRequest [SWS_DM_00806], [SWS_DM_00809]. En tant qu'élément strictement unique, la classe exclut les opérations de copie ainsi que de déplacement et requiert une désinscription via StopOffer() avant la terminaison [SWS_DM_00810].

plus ›

Contexte

La classe ara::diag::CommunicationControl définit l'interface standardisée pour le déroulement du service de diagnostic UDS 0x28 (CommunicationControl) dans l'AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_Diagnostics, p. 70. En tant que classe de base abstraite, elle sert d'intermédiaire entre le Diagnostic Manager (DM) et la fonctionnalité de diagnostic spécifique à l'application avec laquelle l'envoi ou la réception de certains messages de communication dans le réseau du véhicule est contrôlé. Le logiciel d'application dérive de cette classe et implémente la méthode purement virtuelle CommCtrlRequest afin de recevoir et d'exécuter les instructions de commande entrantes [SWS_DM_00808]. La liaison au modèle système AUTOSAR s'effectue via un ara::core::InstanceSpecifier qui référence un PortPrototype d'un DiagnosticComControlInterface [SWS_DM_00806].

Cycle de vie

Une instance est explicitement créée via le constructeur en indiquant le ara::core::InstanceSpecifier ainsi que le modèle de concurrence ConcurrencyType (kConcurrent ou kNotConcurrent) [SWS_DM_00806]. La classe possède une sémantique d'unicité stricte et n'est ni copiable ni déplaçable : le constructeur de copie [SWS_DM_01677] et le constructeur de déplacement [SWS_DM_01678] ainsi que l'opérateur d'assignation par copie [SWS_DM_01675] et l'opérateur d'assignation par déplacement [SWS_DM_01676] sont tous supprimés (=delete).

Après la création, l'instance reste d'abord inactive. Ce n'est que par l'appel de Offer() que le Diagnostic Manager est autorisé à réacheminer les requêtes de diagnostic entrantes vers le gestionnaire [SWS_DM_00809]. Inversement, StopOffer() retire cette autorisation et désactive le réacheminement [SWS_DM_00810]. La destruction s'effectue via le destructeur virtuel [SWS_DM_00807]. Interprétation : il devrait être nécessaire d'appeler StopOffer() avant la destruction de l'objet afin que le Diagnostic Manager ne maintienne pas de réacheminements orphelins. Question Q-f67e35c9fea508d8 (ouverte)

En matière de concurrence, le constructeur est thread-safe [SWS_DM_00806], tandis que le destructeur [SWS_DM_00807], Offer() [SWS_DM_00809] et StopOffer() [SWS_DM_00810] ne sont pas thread-safe. L'exécution de CommCtrlRequest est conditionnellement thread-safe (conditional) : le ConcurrencyType défini dans le constructeur détermine si l'implémentation doit être thread-safe [SWS_DM_00808].

Parcours d'utilisation

Le flux régulier comprend l'instanciation de la classe dérivée, l'enregistrement du service, le traitement asynchrone des requêtes de diagnostic et la désinscription finale :

1. Initialisation : l'application instancie le gestionnaire en spécifiant le InstanceSpecifier et le ConcurrencyType souhaité [SWS_DM_00806].
2. Offre de service : le service est activé auprès du Diagnostic Manager via Offer() [SWS_DM_00809].
3. Traitement de requête : si une requête UDS pour le service 0x28 arrive avec une sous-fonction quelconque, le Diagnostic Manager appelle CommCtrlRequest [SWS_DM_00808]. Les paramètres comprennent :
   • controlType (ComCtrlRequestParamsType) : tous les paramètres de requête UDS, y compris les éléments optionnels.
   • metaInfo (const MetaInfo&) : métadonnées relatives à la requête de diagnostic.
   • cancellationHandler (CancellationHandler) : sert à l'interrogation d'état via IsCanceled() ainsi qu'à l'enregistrement d'une fonction de rappel d'annulation via SetNotifier().
4. Retour d'information : le traitement se termine de manière asynchrone et signale le résultat via ara::core::Future<void> [SWS_DM_00808].
5. Désinscription : avant l'arrêt ou la terminaison, l'application arrête le réacheminement au moyen de StopOffer() [SWS_DM_00810].

Diagramme de séquence : déroulement typique depuis l'initialisation jusqu'à la désinscription en passant par le traitement de requêtes UDS 0x28. Sources : [SWS_DM_00806], [SWS_DM_00808], [SWS_DM_00809], [SWS_DM_00810].

Scénarios d'erreur

Dès la construction, des incohérences dans le modèle AUTOSAR peuvent conduire à des violations à l'exécution (violations) [SWS_DM_00806] :

• InstanceSpecifierMappingIntegrityViolation : le InstanceSpecifier ne peut pas être résolu dans le contexte de l'exécutable ou ne renvoie pas à un PortPrototype.
• PortInterfaceMappingViolation : le PortPrototype typé par DiagnosticComControlInterface n'est pas référencé par un DiagnosticServiceGenericMapping.
• ProcessMappingViolation : une référence d'instance correspondante existe, mais il n'y a aucun processus modélisé qui corresponde au processus actuel.
• InstanceSpecifierAlreadyInUseViolation : l'identifiant est déjà utilisé dans le même processus par une autre instance.

En cours d'exploitation, Offer() signale via la valeur de retour ara::core::Result<void> l'erreur DiagOfferErrc::kAlreadyOffered si le service a déjà été proposé auparavant et est toujours actif [SWS_DM_00809]. Si une requête de diagnostic ne peut pas être satisfaite d'un point de vue fonctionnel dans CommCtrlRequest, la méthode renvoie via le ara::core::Future<void> un Negative Response Code (NRC) conformément à l'ISO 14229-1 au moyen de DiagUdsNrcErrc [SWS_DM_00808].