namespace <RoutineInterface-Namespace>

Cet espace de noms met à disposition des interfaces pour l’encapsulation et l’exécution de routines de diagnostic spécifiques à l’application au sein du module diag d’Adaptive Platform. La tâche principale consiste probablement à offrir, vis-à-vis du système de gestion de diagnostic, une couche d’abstraction pour des opérations de routine telles que le démarrage, l’arrêt et l’interrogation des résultats. Question (ouverte) Le pilotage de l’exécution de la routine devrait typiquement être couplé au cycle de vie de la pile de diagnostic parente. Comme contrainte essentielle, les implémentations doivent garantir la sécurité des threads requise ainsi qu’un comportement déterministe lors d’appels asynchrones.

plus ›

Contexte

L’espace de noms namespace <RoutineInterface-Namespace> fait partie du cluster fonctionnel diag (Diagnostic Management) d’AUTOSAR Adaptive Platform dans la version R25-11. Au sein de cet espace de noms, la classe d’interface <RoutineInterface> est définie en tant que DiagnosticRoutineInterface. Le rôle principal de cet espace de noms consiste à fournir un cadre standardisé pour encapsuler les routines de diagnostic exécutées par les composants logiciels applicatifs dans le véhicule.

La classe <RoutineInterface> devrait servir de couche d’abstraction entre le système de gestion de diagnostic de la plateforme et les déroulements de routines spécifiques au véhicule. La gestion de diagnostic parente traite les requêtes de diagnostic externes (telles que UDS RoutineControl selon ISO 14229-1) et les transmet à la routine applicative enregistrée. L’application fournit la logique réelle de commande, de test et de contrôle via l’implémentation de l’interface, sans présenter de dépendances directes vis-à-vis de la couche de protocole de transport ou des topologies de réseau. Question Q-03b9b94f9c2849b0 (ouverte)

Cycle de vie

Le cycle de vie des instances de la classe d’interface <RoutineInterface> devrait être étroitement couplé à l’état de mise à disposition des services de diagnostic associés. Une instanciation a lieu typiquement au cours de la phase d’initialisation de l’application adaptative, avant que l’interface ne soit enregistrée auprès du gestionnaire de diagnostic et activée pour les requêtes externes. L’application assume alors la responsabilité de la création de l’objet et de la mise à disposition des contextes d’exécution nécessaires. Question Q-32a86efa16843445 (ouverte)

Pendant la phase opérationnelle, l’instance d’interface reste active et reçoit les commandes de pilotage entrantes. Comme les appels de diagnostic par des testeurs externes peuvent arriver de façon concurrente aux tâches applicatives régulières, les implémentations doivent garantir la sécurité des threads requise. Lors de l’arrêt de l’application ou de la désactivation du service, un désenregistrement ordonné est nécessaire pour garantir qu’aucune routine en cours d’exécution ne demeure dans un état indéfini et que les ressources allouées soient libérées de manière déterministe.

Parcours d'utilisation

Un chemin d’utilisation typique pour une routine de diagnostic s’articule en une suite structurée d’étapes d’interaction entre le système de gestion de diagnostic et la logique applicative. Le déroulement devrait vraisemblablement comporter les phases suivantes : Question Q-da2cd4e1ceb5b3b8 (ouverte)

1. Initialisation et enregistrement : l’application instancie la classe <RoutineInterface> et enregistre l’objet d’interface auprès de la gestion du diagnostic du module diag.
2. Démarrage de la routine : lors de la réception d’une requête de diagnostic correspondante, le système appelle la méthode de démarrage de l’interface. Cela déclenche la logique spécifique à l’application, par exemple un test d’actionneur, un cycle d’étalonnage ou un cycle de calcul.
3. Interrogation d’état et de résultat : pendant l’exécution ou après l’achèvement de l’opération, des états intermédiaires ou le résultat final peuvent être interrogés par des appels d’interface correspondants et transmis au système de gestion.
4. Arrêt ou interruption prématurée : la routine s’achève soit de façon régulière après un traitement réussi, soit, en cas de besoin, par une interruption contrôlée via une demande d’arrêt explicite de l’infrastructure de diagnostic.

Scénarios d'erreur

Dans le cadre de l'exécution de la routine, divers états d'erreur peuvent survenir et nécessitent un traitement d'erreur cohérent. Si des états de fonctionnement imprévus surviennent pendant l'exécution d'une routine de diagnostic – par exemple une tension d'alimentation insuffisante, des états du véhicule non autorisés ou des pénuries de ressources –, l'interface doit le signaler. Les paramètres d'entrée erronés ou les interruptions d'exécution doivent être signalés à la gestion du diagnostic via des codes d'erreur définis. Cela permet à la plateforme de transmettre des codes de réponse négatifs (NRCs) conformes aux standards au testeur de diagnostic externe et de préserver un état sûr du véhicule.