namespace <ExtendedDataRecord-Namespace>

Dans le module diag d’AUTOSAR Adaptive Platform, l’espace de noms namespace <ExtendedDataRecord-Namespace> regroupe des interfaces telles que DiagnosticExtendedDataRecordInterface pour la mise à disposition d’Extended Data Records spécifiques à l’application pour les entrées de mémoire d’événements de diagnostic. Interpretation : l’application devrait instancier et enregistrer l’interface lors de l’initialisation afin de traiter de manière asynchrone les demandes de lecture entrantes du gestionnaire de diagnostic avec des données de contexte et de compteur actuelles. Question (ouverte) Ce faisant, l’accès concurrent depuis le sous-système de diagnostic exige une mise à disposition des données sécurisée pour les threads et une réponse en temps opportun pour éviter les dépassements de délai de protocole.

plus ›

Contexte

Dans le module diag d’AUTOSAR Adaptive Platform, l’espace de noms namespace <ExtendedDataRecord-Namespace> prend en charge l’encapsulation logique d’interfaces pour la mise à disposition de données de diagnostic étendues. Dans le diagnostic lié au véhicule selon ISO 14229 (UDS), les Extended Data Records (EDR) jouent un rôle central car ils associent à une entrée de mémoire de diagnostic (DTC) des informations complémentaires spécifiques, telles que des compteurs d’occurrence de défauts, des compteurs de vieillissement ou des données d’état spécifiques au constructeur. Interpretation : l’identifiant <ExtendedDataRecord-Namespace> devrait servir d’espace réservé formel pour des espaces de noms configurés selon le modèle, dans lesquels des interfaces de diagnostic spécifiques à l’application sont générées pour des éléments d’enregistrements de données. Question Q-96107a4ff53015bb (ouverte) La classe centrale DiagnosticExtendedDataRecordInterface (indiquée dans le modèle sous <ExtendedDataRecordElementInterface>) fait office de couche d’abstraction entre le gestionnaire de diagnostic AUTOSAR et l’application exécutante qui maintient les valeurs d’état physiques ou logiques.

Cycle de vie

La durée de vie et la gestion d’état d’objets du type DiagnosticExtendedDataRecordInterface sont étroitement couplées au cycle de vie du composant applicatif fournisseur. Interpretation : l’instanciation et la gestion du cycle de vie de l’instance d’interface devraient suivre le patron de fournisseur de services habituel de ara::diag, dans lequel l’application crée l’interface pendant sa phase d’initialisation et la met à la disposition du framework de diagnostic. Question Q-9968bfe101348d1f (ouverte) Pendant la phase opérationnelle de fonctionnement, l’instance reste active en mémoire afin de traiter les demandes de lecture entrantes pour les données de diagnostic. Lors d’un arrêt ordonné du logiciel fonctionnel, l’instance doit être désenregistrée ou détruite avant l’arrêt des sous-systèmes dépendants. Comme les requêtes de diagnostic peuvent survenir de manière asynchrone via le démon de diagnostic, l’implémentation de la classe d’interface requiert une conception sécurisée pour les threads afin de protéger les accès simultanés en lecture aux données d’état internes de l’application.

Parcours d'utilisation

Un déroulement typique d’utilisation comprend la définition, la mise à disposition et l’exécution de l’interrogation d’enregistrements de données. Au début, l’application fonctionnelle instancie l’implémentation concrète de DiagnosticExtendedDataRecordInterface et la lie au port configuré. Si un testeur de diagnostic externe émet ensuite, via une commande UDS (par exemple le service 0x19 pour l’interrogation d’informations de défauts), une demande de lecture pour un Extended Data Record déterminé, le gestionnaire de diagnostic délègue celle-ci à l’interface enregistrée. Interpretation : l’interface devrait être conçue comme une interface de service via laquelle le gestionnaire de diagnostic récupère en cas de besoin le contenu actuel des enregistrements de données. L’application collecte les valeurs de données requises, les encode dans le format de données spécifié et renvoie le résultat au gestionnaire de diagnostic, qui assemble le message de réponse UDS pour l’outil de test. Question Q-00d5498b4380bf74 (ouverte)

Scénarios d'erreur

Lors de l’exploitation des interfaces d’enregistrements de données, différentes situations d’erreur peuvent survenir et doivent être traitées de manière ciblée par le logiciel applicatif. Si l’instance d’interface n’est pas complètement enregistrée au moment d’une requête de diagnostic ou si elle se trouve dans un état transitoire, le gestionnaire de diagnostic ne peut pas transmettre la demande à l’application et répond typiquement au testeur par un code de réponse négative (NRC). Si la mise à disposition des données au sein de l’application tarde au-delà d’une fenêtre temporelle définie, des dépassements de délai de protocole menacent sur l’interface de diagnostic. De plus, l’interface doit être robuste face à des valeurs de mesure temporairement indisponibles en signalant au gestionnaire de diagnostic les accès non valides aux données ou les états d’erreur via les mécanismes d’erreur prévus, au lieu de déclencher des exceptions non gérées dans le processus.