namespace <DataElement-Namespace>

L’espace de noms <DataElement-Namespace> regroupe, dans le module AUTOSAR Adaptive diag pour la version R25-11, des interfaces générées pour le raccordement structuré d’éléments de données de diagnostic spécifiques à l’application au système de diagnostic central. Via la classe d’interface <DataElementInterface>, l’application adaptative implémente des opérations de lecture et d’écriture concrètes exécutées par la pile de diagnostic lors de requêtes de diagnostic entrantes. Concernant le cycle de vie, la création et l’enregistrement de l’instance d’interface incombent à l’application, étant entendu que interpretation : l’instance doit rester valide pendant toute la durée de fonctionnement et être sécurisée pour les threads face aux appels concurrents.

plus ›

Contexte

Dans le cadre d’AUTOSAR Adaptive Platform pour la version R25-11, le cluster fonctionnel diag (Diagnostic Management) fournit des mécanismes standardisés pour mettre à disposition des services de diagnostic de véhicule selon UDS et les lier aux fonctions internes du véhicule. L’espace de noms <DataElement-Namespace> constitue ici le cadre logique pour les interfaces destinées à l’acquisition et à la modification d’éléments de données de diagnostic. L’identifiant <DataElement-Namespace> fait vraisemblablement office d’espace réservé générique pour un espace de noms C++ spécifique au modèle, instancié lors de la génération de code à partir des descriptions formelles du modèle ARXML pour un élément de données de diagnostic concret. Question Q-2a710983ba4634ab (ouverte)

L’élément central au sein de cet espace de noms est la classe <DataElementInterface>, qui est typée en tant que DiagnosticDataElementInterface. Cette interface constitue le contrat formel entre la pile de diagnostic adaptative et le composant logiciel spécifique à l’application. La classe d’interface déclarée <DataElementInterface> sert au raccordement applicatif, probablement afin de déléguer à l’application adaptative, avec une sûreté de typage, des opérations de lecture et d’écriture sur des éléments de données de diagnostic tels que des identifiants de données (DID). Question Q-5fbb9db6b949d851 (ouverte) De cette manière, un découplage net est garanti entre le traitement générique du protocole du service de diagnostic et la mise à disposition interne des données du calculateur.

Cycle de vie

Le cycle de vie des composants définis dans <DataElement-Namespace> est couplé aux phases d’exécution de l’application adaptative et du gestionnaire de diagnostic. L’instanciation d’une implémentation concrète de <DataElementInterface> s’effectue régulièrement pendant la phase d’initialisation et de démarrage du processus applicatif respectif. Concernant les relations de propriété, la création et la destruction de l’implémentation concrète de <DataElementInterface> incombent à l’application cliente, étant entendu que interpretation : l’instance doit être maintenue valide pendant toute la phase d’enregistrement et de fonctionnement dans le système de diagnostic avant de pouvoir être libérée en toute sécurité lors de la désinitialisation.

Pendant la phase opérationnelle, l’instance d’interface enregistrée demeure dans l’état d’écoute pour les requêtes de diagnostic entrantes. Comme les demandes de diagnostic externes arrivent de manière asynchrone via la pile de diagnostic et peuvent être traitées par des threads de travail du système d’exécution, l’implémentation des méthodes d’interface doit être conçue pour être sécurisée pour les threads et réentrante. Avant l’arrêt du processus applicatif, la liaison avec le gestionnaire de diagnostic doit être défaite afin d’éviter tout accès par pointeur non valide sur des objets d’interface détruits.

Parcours d'utilisation

L’utilisation typique des interfaces issues de <DataElement-Namespace> s’articule en implémentation, enregistrement, traitement à l’exécution et nettoyage. Le logiciel applicatif dérive d’abord une classe concrète de <DataElementInterface> et redéfinit les méthodes de rappel requises pour l’accès aux données de diagnostic. Au démarrage, l’application instancie cette classe et la déclare auprès de l’environnement d’exécution du module diag en tant que fournisseur de données.

Si le cluster de diagnostic reçoit ensuite une demande de service UDS (par exemple pour l’interrogation ou la programmation d’un DID), il délègue directement l’accès aux données à l’instance enregistrée de <DataElementInterface>. L’application lit ou met à jour les données demandées et renvoie le résultat au système de diagnostic, qui génère à partir de là la réponse de diagnostic. Lors de l’arrêt contrôlé de l’application, l’instance est désenregistrée et la mémoire est libérée en bonne et due forme.