classe ara::diag::Condition

La classe ara::diag::Condition met à disposition l'interface DiagnosticConditionInterface avec laquelle les applications adaptatives signalent les conditions d'environnement et d'autorisation au Diagnostic Management ([SWS_DM_00712]). Le Diagnostic Server évalue ces états afin de piloter de manière ciblée l'exécution de fonctions de diagnostic normalisées ou d'opérations d'effacement dans le véhicule (AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 « Condition checks »). Les instances sont fermement liées à un prototype de port et ne sont ni copiables ni déplaçables. En cas d'utilisation concurrente, les opérations de consultation et de définition nécessitent une synchronisation externe car elles ne sont pas sûres au niveau des threads.

plus ›

Contexte

La classe ara::diag::Condition constitue l'interface de programmation pour les conditions de diagnostic (DiagnosticConditionInterface) dans l'AUTOSAR Adaptive Platform ([SWS_DM_00712]). Dans les systèmes de diagnostic de véhicules, certaines fonctions de diagnostic ou services UDS ne peuvent être exécutés que si le véhicule se trouve dans un état d'environnement défini – comme par exemple un véhicule à l'arrêt avec une vitesse nulle (AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 « Condition checks »). Conformément à [SWS_DM_00111], le Diagnostic Server effectue des contrôles d'environnement appropriés lorsque l'ISO 14229-1 prescrit des contrôles de conditions spécifiques au service, et répond par un Negative Response Code (NRC) configuré en cas de non-respect.

Au sein de l'architecture applicative, ara::diag::Condition sert de lien entre l'application adaptative et le Diagnostic Management (DM). Une application instancie l'objet condition via un port qui, dans le modèle, est lié soit par un DiagnosticEnableConditionPortMapping, soit par un DiagnosticClearConditionPortMapping ([SWS_DM_00712]). Interprétation : cette affectation de port détermine si l'état signalé sert de condition d'autorisation pour les séquences de diagnostic standard ou de critère pour la suppression de données de diagnostic. Question (ouverte) L'objet encapsule ainsi la transmission de l'état au Diagnostic Server, qui évalue les conditions pour les requêtes de diagnostic entrantes ([SWS_DM_00111]).

Diagramme de contexte : intégration d'ara::diag::Condition entre le logiciel applicatif et le Diagnostic Management. Sources : [SWS_DM_00712], [SWS_DM_00111], AUTOSAR_AP_SWS_Diagnostics §7.3.2.5.5 « Condition checks »

Cycle de vie

La création d'un objet ara::diag::Condition s'effectue explicitement en passant un ara::core::InstanceSpecifier au constructeur ([SWS_DM_00712]). Cet identifiant fait référence au prototype de port modélisé de l'application. Le constructeur est déclaré comme noexcept et garantit la sécurité vis-à-vis des exceptions ainsi que des threads ([SWS_DM_00712]).

En ce qui concerne les relations de propriété, la classe est conçue comme une instance unique stricte : le constructeur de copie ([SWS_DM_01625]) ainsi que l'opérateur d'assignation par copie ([SWS_DM_01623]) sont supprimés (=delete). De même, le constructeur de déplacement ([SWS_DM_01626]) et l'opérateur d'assignation par déplacement ([SWS_DM_01624]) sont supprimés. Un objet condition ne peut être ni copié ni déplacé, ce qui garantit une affectation fixe 1:1 au port respectif.

En fonctionnement normal, les méthodes SetCondition ([SWS_DM_00715]) et GetCondition ([SWS_DM_00714]) sont spécifiées comme non sécurisées au niveau des threads. En cas d'accès parallèles depuis plusieurs threads, l'application appelante doit assurer une synchronisation externe. Le cycle de vie se termine avec le destructeur ~Condition() ([SWS_DM_00713]), qui est noexcept et sécurisé vis-à-vis des exceptions, mais également non sécurisé au niveau des threads.

Parcours d'utilisation

Le chemin d'utilisation typique comprend l'initialisation, la mise à jour récurrente de l'état ainsi que l'interrogation de la condition :

1. Initialisation : l'application instancie ara::diag::Condition en spécifiant le ara::core::InstanceSpecifier ([SWS_DM_00712]) approprié pour la liaison avec la configuration du modèle.
2. Définition de l'état : si l'état déterminant du véhicule ou du système change, l'application met à jour la condition via SetCondition(condition) ([SWS_DM_00715]). L'appel confirme la prise en compte avec un ara::core::Result<void>.
3. Interrogation de l'état : pour vérifier l'état actuel, l'application appelle GetCondition() ([SWS_DM_00714]). Le résultat est mis à disposition de manière asynchrone via un ara::core::Future<ConditionType>.
4. Traitement côté serveur : Interprétation : le Diagnostic Server accède en interne à l'état enregistré afin de vérifier les requêtes de diagnostic en attente ([SWS_DM_00111]). Question Q-bbf48f735ef80e33 (ouverte)
5. Fin : lors de la terminaison du composant, l'objet est libéré via le destructeur ([SWS_DM_00713]).

Diagramme de séquence : séquence d'appels typique pour l'initialisation, la mise à jour et l'interrogation d'une condition de diagnostic. Sources : [SWS_DM_00712], [SWS_DM_00715], [SWS_DM_00714], [SWS_DM_00713]

Scénarios d'erreur

Des états d'erreur peuvent survenir lors de l'instanciation de l'objet ainsi que pendant l'exécution :

• Violations du constructeur : lors de la création ([SWS_DM_00712]), le framework valide la configuration par rapport au modèle logiciel. Les violations possibles incluent :
  • InstanceSpecifierMappingIntegrityViolation : l'identifiant ne peut pas être résolu dans le modèle ou ne référence aucun PortPrototype ([SWS_DM_00712]).
  • PortInterfaceMappingViolation : le PortPrototype est certes typé par DiagnosticConditionInterface, mais n'est référencé ni par un DiagnosticEnableConditionPortMapping ni par un DiagnosticClearConditionPortMapping ([SWS_DM_00712]).
  • ProcessMappingViolation : aucun processus modélisé correspondant n'existe à l'exécution pour la référence d'instance ([SWS_DM_00712]).
  • InstanceSpecifierAlreadyInUseViolation : l'identifiant est déjà utilisé dans le même processus par une autre instance ([SWS_DM_00712]).
• Défaillance des services de base de diagnostic : GetCondition() ([SWS_DM_00714]) peut échouer avec l'erreur DiagErrc::kServiceNotAvailable via le ara::core::Future retourné si des fonctionnalités de base du Diagnostic Management sont temporairement inaccessibles.
• Enregistrement d'état sans erreur : aucun code d'erreur standardisé n'est défini pour SetCondition() ([SWS_DM_00715]) ; la fonction signale le succès directement via un ara::core::Result<void> vide.