module ara::diag — Diagnostics

Dans l'AUTOSAR Adaptive Platform, le cluster fonctionnel Diagnostic Management fournit l'infrastructure centrale pour le diagnostic de véhicule classique UDS et moderne SOVD (AUTOSAR_AP_EXP_SWArchitecture p. 150). En tant que démon de plateforme, il termine les couches de transport telles que DoIP, pilote les gestionnaires de protocole et transmet les requêtes de diagnostic aux Adaptive Applications via des interfaces de callback à typage fort ([SWS_DM_00311]). En même temps, le module prend en charge la surveillance des défauts, le déparasitage temporel et par compteur ainsi que la gestion de la mémoire des défauts. Les applications activent les fonctions de service via un modèle déclaratif d'offre, ce qui sépare nettement la logique applicative et le traitement du protocole.

plus ›

Dans l'AUTOSAR Adaptive Platform, le cluster fonctionnel Diagnostic Management (ara::diag) fournit l'infrastructure centrale basée sur un démon pour le traitement de la communication de diagnostic adaptée aux véhicules (AUTOSAR_AP_EXP_SWArchitecture p. 150). Il découple les gestionnaires de protocole spécifiques au transport (comme DoIP ou CAN-TP) du cœur de diagnostic proprement dit (UdsTransportProtocolMgr) et permet ainsi une terminaison et une transmission uniformes des requêtes de diagnostic (AUTOSAR_AP_EXP_SWArchitecture p. 164).

Diagramme de contexte : intégration du démon de Diagnostic Management entre gestionnaires de transport, Adaptive Applications et testeurs externes. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168

Pour le traitement des services, le module implémente un modèle de mise à disposition déclaratif : le démon de diagnostic réalise les interfaces de port, tandis que les Adaptive Applications enregistrent des callbacks de service pour les DataIdentifier, les routines ou les transferts par blocs et contrôlent leur disponibilité via Offer() ou StopOffer() ([SWS_DM_00557], AUTOSAR_AP_EXP_SWArchitecture p. 156). Les messages entrants sont traités sans faille via des mécanismes d'indication et de transmission à deux niveaux (IndicateMessage et HandleMessage) ([SWS_DM_00309], [SWS_DM_00311]).

Diagramme de séquence : flux de contrôle de bout en bout d'une requête UDS depuis la couche de transport jusqu'à l'application utilisatrice en passant par le gestionnaire de diagnostic. Sources : [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130

En plus des fonctions UDS classiques, le cluster gère des moniteurs de diagnostic, exécute les déparasitages configurés et persiste les défauts qualifiés dans la mémoire des défauts primaire (DTCInformation) ([SWS_DM_00664], SWS_Diagnostics p. 225). Les standards étendus tels qu'ISO 13400-2 (DoIP) et ASAM SOVD (Service-Oriented Vehicle Diagnostics) sont intégrés de manière transparente dans la plateforme via des interfaces spécialisées pour les lignes d'activation, les authentifications et les données utiles JSON hiérarchiques ([SWS_DM_00834], [SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170).

plus ›

Rôle architectural et limites système du Diagnostic Management

Dans l'AUTOSAR Adaptive Platform (release R25-11), le cluster fonctionnel Diagnostic Management (ara::diag) constitue le point névralgique central pour le diagnostic embarqué et externe du véhicule (AUTOSAR_AP_EXP_SWArchitecture p. 150). Sur le plan architectural, le module est conçu comme un service d'arrière-plan basé sur un démon («aapFunctionalCluster» Diagnostic Management daemon-based). Il termine les protocoles de diagnostic physiques et logiques, gère le contexte global de diagnostic et fournit l'infrastructure middleware par laquelle les Adaptive Applications individuelles peuvent mettre à disposition des données et des routines liées au diagnostic (AUTOSAR_AP_EXP_SWArchitecture p. 156).

Le paysage des interfaces se divise principalement en deux catégories : les interfaces de port modélisées, qui sont configurées via le manifeste AUTOSAR et liées aux processus applicatifs, ainsi que les interfaces d'exécution C++ natives (AUTOSAR_AP_EXP_SWArchitecture p. 150). Parmi les interfaces natives figure notamment la classe Conversation, par laquelle les applications peuvent interroger les états de session actuels ([SWS_DM_00696]), déterminer les niveaux de sécurité ([SWS_DM_00698]) ou inspecter les conversations de diagnostic actives ([SWS_DM_00783]). Interprétation : la séparation stricte entre le démon de diagnostic central et les processus utilisateurs a vraisemblablement été choisie afin de garantir des temps de réponse déterministes vis-à-vis des testeurs externes, même lors de redémarrages de processus d'applications individuelles. Question Q-2e2ea8eb9d415fed (ouverte)

Diagramme de contexte : intégration du démon de Diagnostic Management entre gestionnaires de transport, Adaptive Applications et testeurs externes. Sources : AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168

Raccordement de la couche de transport et contrôle du cycle de vie des gestionnaires de protocole

Afin d'agir indépendamment des technologies de réseau spécifiques (comme Ethernet/DoIP ou CAN/ISO-TP), le Diagnostic Management découple le cœur de protocole via des interfaces de transport standardisées (AUTOSAR_AP_EXP_SWArchitecture p. 164). Le cœur générique implémente l'interface UdsTransportProtocolMgr, tandis que les adaptateurs spécifiques au transport sont raccordés en tant que UdsTransportProtocolHandler (AUTOSAR_AP_EXP_SWArchitecture p. 165). Chaque gestionnaire est identifié par un identifiant unique, qui peut être interrogé via GetHandlerID() ([SWS_DM_00325]).

Le contrôle du cycle de vie d'un gestionnaire de transport se divise en phases de fonctionnement déterministes (AUTOSAR_SWS_Diagnostics p. 128) : lors du démarrage, le Diagnostic Management initialise le gestionnaire via Initialize() ([SWS_DM_00319]), puis active le traitement des messages au moyen de Start() ([SWS_DM_00322]). Lors de l'arrêt contrôlé, le gestionnaire invite le gestionnaire via Stop() à fermer les connexions ouvertes ([SWS_DM_00323]), à la suite de quoi le gestionnaire acquitte l'achèvement via HandlerStopped() ([SWS_DM_00314]).

Pour les sessions de diagnostic de longue durée, AUTOSAR spécifie en outre un mécanisme de restauration à travers les cycles de vie des processus (AUTOSAR_SWS_Diagnostics p. 134). Si un canal précédemment persisté peut être rétabli après un redémarrage du gestionnaire de diagnostic, le gestionnaire de transport le signale via NotifyReestablishment() ([SWS_DM_00326]). Le gestionnaire synchronise l'état en interne et le confirme par l'appel de ChannelReestablished() ([SWS_DM_00313]).

Diagramme de séquence : contrôle du cycle de vie d'un gestionnaire de transport UDS par le gestionnaire de diagnostic générique. Sources : [SWS_DM_00314], [SWS_DM_00319], [SWS_DM_00322], [SWS_DM_00323], AUTOSAR_SWS_Diagnostics p. 128

Traitement des services UDS et gestion des requêtes spécifique à l'application

Après la validation du protocole, les messages UDS entrants sont traités étape par étape (AUTOSAR_SWS_Diagnostics p. 130). Tout d'abord, le gestionnaire de transport annonce le début d'un message auprès du gestionnaire via IndicateMessage() afin d'allouer des ressources et des tampons ([SWS_DM_00309]). Le message est encapsulé sous forme de UdsMessage, qui fournit l'adresse source ([SWS_DM_00297]), l'adresse cible ([SWS_DM_00298]) et le type d'adressage ([SWS_DM_00299]). Après réception complète, le gestionnaire transmet l'objet de données au Diagnostic Management via HandleMessage() ([SWS_DM_00311]), les métadonnées spécifiques au canal étant complétées au moyen de AddMetaInfo() ([SWS_DM_00302]).

Dans la release R25-11, l'interaction entre le démon de plateforme et l'application suit un modèle de fourniture de service inversé (AUTOSAR_AP_EXP_SWArchitecture p. 156) : le démon de plateforme réalise les ports de service, tandis que les Adaptive Applications implémentent des méthodes de callback et activent explicitement leur disponibilité pour la transmission via Offer() ([SWS_DM_00557]) ou la suspendent via StopOffer() ([SWS_DM_00558]). Cela s'applique de la même manière aux routines génériques (GenericRoutine [SWS_DM_00552]), aux routines typées (RoutineInterface [SWS_DM_00589] avec Start [SWS_DM_00591]), aux identifiants de données (GenericDataIdentifier [SWS_DM_00634] avec Read [SWS_DM_00636] et Write [SWS_DM_00637]) ainsi qu'aux services UDS génériques (GenericUDSService [SWS_DM_00616] avec HandleMessage [SWS_DM_00618]).

Les transactions de diagnostic de plus longue durée (comme les transferts par blocs via UploadService [SWS_DM_00797], DownloadService [SWS_DM_00787] ou FileTransferService [SWS_DM_01325] selon AUTOSAR_AP_EXP_SWArchitecture p. 163) sont traitées de manière asynchrone via ara::core::Future. Pour éviter le blocage des ressources, les gestionnaires spécifiques à l'application reçoivent une instance de CancellationHandler (AUTOSAR_AP_EXP_SWArchitecture p. 152). Via IsCanceled(), l'application peut vérifier une éventuelle annulation ([SWS_DM_00614]) ou enregistrer une fonction de notification via SetNotifier() ([SWS_DM_00615]). Pour les redémarrages coordonnés, l'interface EcuResetRequest est fournie ([SWS_DM_01010]), laquelle délègue les requêtes de réinitialisation au State Management (AUTOSAR_AP_EXP_SWArchitecture p. 162).

Diagramme de séquence : flux de contrôle de bout en bout d'une requête UDS depuis la couche de transport jusqu'à l'application utilisatrice en passant par le gestionnaire de diagnostic. Sources : [SWS_DM_00309], [SWS_DM_00311], [SWS_DM_00327], AUTOSAR_SWS_Diagnostics p. 130

Surveillance des événements, déparasitage et gestion de la mémoire des défauts

Pour la détection et la qualification des défauts système, Diagnostic Management implémente un modèle hiérarchique composé de moniteurs et d'événements de diagnostic (SWS_Diagnostics p. 225). Une application instancie un objet Monitor ([SWS_DM_00548]) et signale en continu les résultats de test via ReportMonitorAction() ([SWS_DM_00543]). Le module prend en charge aussi bien des algorithmes de filtrage antirebond basés sur des compteurs que basés sur le temps ([SWS_DM_00549], [SWS_DM_00550]). L'interface Event permet aux applications de déterminer la valeur actuelle de l'octet d'état UDS ([SWS_DM_00649]), de vérifier l'état du filtrage antirebond ([SWS_DM_00654]) ou d'enregistrer des rappels de changement d'état ([SWS_DM_00650]).

Afin de maintenir une faible empreinte de ports dans les systèmes complexes, la plateforme met à disposition des interfaces groupées (AUTOSAR_AP_EXP_SWArchitecture p. 153) : via MultipleMonitor ([SWS_DM_01695]), MultipleEvent ([SWS_DM_01705]) et MultipleCondition ([SWS_DM_01727]), plusieurs canaux de surveillance peuvent être adressés au moyen d'une interface de port commune. La gestion de l'autorisation pour les moniteurs s'effectue via des objets Condition ([SWS_DM_00712]), tandis que OperationCycle ([SWS_DM_00752]) et Indicator ([SWS_DM_00742], SWS_Diagnostics p. 633) pilotent les cycles de fonctionnement et signalent les demandes de voyant d'alerte.

Les événements agrégés aboutissent à la gestion de la mémoire des défauts, qui est exposée via DTCInformation ([SWS_DM_00664], AUTOSAR_AP_EXP_SWArchitecture p. 144). Cette interface permet la lecture des entrées enregistrées ([SWS_DM_00669]), l'effacement sélectif ou global des DTC ([SWS_DM_00671]) et l'activation de l'enregistrement des DTC ([SWS_DM_00674]). En cas de dépassement de capacité de la mémoire primaire, l'application est notifiée via SetEventMemoryOverflowNotifier() ([SWS_DM_00918], [SWS_DM_00919]).

Diagramme d'états/d'activités : déroulement depuis l'action du moniteur jusqu'à la qualification du DTC dans la mémoire des défauts en passant par le filtrage antirebond. Sources : [SWS_DM_00543], [SWS_DM_00649], [SWS_DM_00664], SWS_Diagnostics p. 225

Protocoles de diagnostic avancés : intégration DoIP et services SOVD

Pour les réseaux de véhicules basés sur Ethernet, le module intègre des fonctions DoIP dédiées (Diagnostic communication over Internet Protocol selon ISO 13400-2) (AUTOSAR_AP_EXP_SWArchitecture p. 166, AUTOSAR_AP_EXP_SWArchitecture p. 167). Les extensions de plateforme signalent l'état des lignes d'activation physique via DoIPActivationLine::UpdateActivationLineState() ([SWS_DM_00834], AUTOSAR_AP_TPS_ManifestSpecification p. 338). Sur cette base, des messages d'annonce de véhicule (Vehicle Announcement Messages) peuvent être déclenchés via DoIPTriggerVehicleAnnouncement ([SWS_DM_00821], [SWS_DM_00822], AUTOSAR_AP_SWS_Diagnostics p. 108). L'identification de groupe et d'entité est interrogée dynamiquement via DoIPGroupIdentification ([SWS_DM_00722]) et DoIPEntityIdentification ([SWS_DM_01364], [SWS_DM_01366]).

Diagramme de séquence : interaction entre l'application, la ligne d'activation et le déclenchement des annonces de véhicule DoIP. Sources : [SWS_DM_00822], [SWS_DM_00834], AUTOSAR_AP_SWS_Diagnostics p. 108

En plus des services UDS classiques, la release R25-11 établit des interfaces natives pour SOVD (Service-Oriented Vehicle Diagnostics, ASAM SOVD / ISO 13170) (AUTOSAR_AP_EXP_SWArchitecture p. 168). Les données de diagnostic structurées sont modélisées via DiagnosticSovdContentElementData ([SWS_DM_02370], AUTOSAR_AP_EXP_SWArchitecture p. 170). Des classes de type STL à sûreté de typage telles que DiagnosticSovdArrayContentElementDataView ([SWS_DM_02245], AUTOSAR_AP_EXP_SWArchitecture p. 172) et DiagnosticSovdRecordContentElementDataView ([SWS_DM_02289], AUTOSAR_AP_EXP_SWArchitecture p. 174) sont disponibles pour manipuler des charges utiles complexes analogues à JSON.

Pour les transactions SOVD avancées et les mécanismes de protection, le module définit des rôles standardisés : les volumes de données importants (tels que les traces ou les crash-dumps) sont transférés via SovdBulkData ([SWS_DM_01847], [SWS_DM_01854], AUTOSAR_AP_TPS_ManifestSpecification p. 321). Le contrôle d'accès s'effectue par des vérifications de jeton et de proximité via SovdAuthorization ([SWS_DM_01489]) et SovdProximityChallenge ([SWS_DM_01480], [SWS_DM_01493]), tandis que les vérifications de service sont autorisées via SovdServiceValidation ([SWS_DM_01823], [SWS_DM_01827]).

Comportement en cas d'erreur

La gestion des erreurs du module diag repose sur le modèle standard AUTOSAR ara::core::Result<T, ErrorCode> et exclut totalement les états d'erreur silencieux. En fonction de leurs causes fonctionnelles, les erreurs sont réparties en cinq domaines d'erreur spécialisés (ErrorDomain), qui définissent aussi bien des codes d'erreur que les classes d'exception correspondantes :

• Erreurs de diagnostic générales : Le DiagErrorDomain ([SWS_DM_00520], [SWS_DM_00524]) et le DiagException associé ([SWS_DM_00516]) signalent des erreurs fondamentales de plateforme ou de configuration telles que des arguments non valides ou des instances non initialisées.
• UDS Negative Response Codes (NRC) : Les rejets protocolaires UDS spécifiques selon ISO 14229 sont représentés via le DiagUdsNrcErrorDomain ([SWS_DM_00532], [SWS_DM_00536]) et DiagUdsNrcException ([SWS_DM_00528]).
• Erreurs de fourniture de service : Si l'activation ou la désactivation d'interfaces de port échoue, le DiagOfferErrorDomain ([SWS_DM_00992], [SWS_DM_01003]) intervient avec le DiagOfferException ([SWS_DM_00986]).
• Erreurs de signalement d'événements et de moniteurs : Les erreurs survenues pendant le signalement d'état par les moniteurs sont indiquées par le DiagReportingErrorDomain ([SWS_DM_00999], [SWS_DM_01004]) et DiagReportingException ([SWS_DM_00988]).
• Erreurs de protocole SOVD : Les erreurs dans les points de terminaison REST, les contenus JSON ou le contrôle d'accès sont signalées via le DiagSovdErrorDomain ([SWS_DM_01812], [SWS_DM_01816]) et DiagSovdException ([SWS_DM_01808]).

Au niveau de la couche de transport, les interruptions de transmission, les débordements de tampon ou les ruptures de connexion sont signalés à Diagnostic Management par le rappel NotifyMessageFailure() ([SWS_DM_00310]). Cela permet au module de libérer sans délai les ressources allouées et, le cas échéant, de déclencher l'envoi de messages de réponse négative au testeur.

Diagramme de classes : architecture des domaines d'erreur et affectation des codes d'exception et d'erreur standardisés dans Diagnostic Management. Sources : [SWS_DM_00520], [SWS_DM_00532], [SWS_DM_00992], [SWS_DM_00999], [SWS_DM_01812]

Preuves détaillées supplémentaires

La base normative du module diag s'appuie sur trois documents de spécification centraux de l'AUTOSAR Adaptive Platform :

• Architecture des interfaces et des composants : Les interfaces système, le modèle de démon ainsi que la séparation entre couche de transport et couche applicative sont définis dans AUTOSAR_AP_EXP_SWArchitecture (AUTOSAR_AP_EXP_SWArchitecture p. 150, AUTOSAR_AP_EXP_SWArchitecture p. 164, AUTOSAR_AP_EXP_SWArchitecture p. 168).
• Spécification de Diagnostic Management : Les signatures d'API détaillées, les séquences pour le traitement des requêtes, les cycles de vie des gestionnaires de transport et les règles de filtrage antirebond sont définis par AUTOSAR_SWS_Diagnostics (AUTOSAR_SWS_Diagnostics p. 128, AUTOSAR_SWS_Diagnostics p. 130, SWS_Diagnostics p. 225).
• Définitions des manifestes et du métamodèle : La liaison déclarative des interfaces de port, des logiques de validation et des mappages de service aux composants logiciels est régie par AUTOSAR_AP_TPS_ManifestSpecification (AUTOSAR_AP_TPS_ManifestSpecification p. 311, AUTOSAR_AP_TPS_ManifestSpecification p. 321, AUTOSAR_AP_TPS_ManifestSpecification p. 341).