classe ara::diag::MultipleCondition

La classe ara::diag::MultipleCondition sert à l'interrogation et à la mise à jour groupées de plusieurs conditions de diagnostic via une interface de port commune à l'aide de handles numériques ([SWS_DM_01730]). Les applications instancient l'objet via un InstanceSpecifier et contrôlent de manière ciblée les conditions au moyen de SetCondition et GetCondition ([SWS_DM_01729]). Comme contrainte essentielle, la classe n'est ni copiable ni déplaçable, et son destructeur n'est pas thread-safe. De plus, toutes les conditions adressées doivent être configurées de manière cohérente dans le modèle via des mappages de ports afin d'éviter les erreurs d'initialisation et d'exécution.

plus ›

Contexte

La classe ara::diag::MultipleCondition permet à une application adaptative d'administrer et de modifier de manière groupée plusieurs conditions de diagnostic via une interface commune ([SWS_DM_01730]). D'un point de vue fonctionnel et sémantique, elle offre les mêmes fonctionnalités que des conditions individuelles, mais étend toutefois les opérations avec l'adressage ciblé via un handle d'identification (AUTOSAR_AP_SWS_Diagnostics p. 237). Chaque condition de diagnostic gérée (DiagnosticCondition) nécessite dans le modèle une association via un DiagnosticMultipleConditionPortMapping avec un port typé de manière appropriée ([SWS_DM_01727], AUTOSAR_AP_SWS_Diagnostics p. 237). L'adressage s'effectue via le type ConditionHandleType ; en l'absence de valeur overrideId explicite, le Diagnostic Management (DM) attribue des valeurs numériques croissantes à partir de 0x010000 dans l'ordre alphabétique des noms courts ([SWS_DM_01735]).

Diagramme de contexte : intégration de ara::diag::MultipleCondition entre l'application adaptative et le Diagnostic Management. Sources : [SWS_DM_01727], [SWS_DM_01728], AUTOSAR_AP_SWS_Diagnostics p. 237

Cycle de vie

Une instance est créée via le constructeur MultipleCondition en lui transmettant un ara::core::InstanceSpecifier ([SWS_DM_01727]). La création est thread-safe et déclarée comme noexcept ([SWS_DM_01727]). L'objet possède une liaison stricte à sa portée locale : les opérations de copie tout comme de déplacement sont supprimées ; le constructeur de copie ([SWS_DM_02072]), le constructeur de déplacement ([SWS_DM_02071]), l'opérateur d'affectation par copie ([SWS_DM_02073]) et l'opérateur d'affectation par déplacement ([SWS_DM_02074]) ne sont pas disponibles (=delete).

Le destructeur ~MultipleCondition() est explicitement spécifié comme non thread-safe ([SWS_DM_01737]). L'application doit par conséquent s'assurer qu'avant la destruction, tous les accès concurrents à l'objet sont terminés. Une sécurité de thread conditionnelle s'applique aux appels de méthodes ordinaires ([SWS_DM_01728], [SWS_DM_01729]). Interprétation : étant donné que la signature du constructeur selon [SWS_DM_01727] n'accepte aucun paramètre de concurrence explicite, le ConcurrencyType requis est vraisemblablement déterminé via le modèle de port sous-jacent dans le manifeste. Question Q-f29def512a68aae9 (ouverte)

Parcours d'utilisation

Le déroulement typique lors de l'interaction avec des conditions de diagnostic comprend les étapes suivantes :

1. Initialisation : l'application instancie la classe en spécifiant le port cible ([SWS_DM_01727]).
2. Définition de l'état : avec SetCondition(conditionHandle, condition), l'application transmet un changement d'état pour la condition spécifiée et vérifie le ara::core::Result<void> résultant ([SWS_DM_01729]).
3. Interrogation de l'état : via GetCondition(conditionHandle), l'état actuel de la condition adressée est demandé de manière asynchrone sous la forme d'un ara::core::Future<ConditionType> ([SWS_DM_01728]).
4. Libération des ressources : lors de la sortie de la portée, le destructeur démantèle l'interface de manière ordonnée ([SWS_DM_01737]).

Diagramme de séquence : modèles d'appel et de réponse lors de la gestion de conditions via MultipleCondition. Sources : [SWS_DM_01727], [SWS_DM_01728], [SWS_DM_01729], [SWS_DM_01737]

Scénarios d'erreur

Lors de l'utilisation, il convient de distinguer les erreurs de construction liées à la modélisation et les erreurs fonctionnelles à l'exécution :

• Violations de construction ([SWS_DM_01727]) : Si la résolution du InstanceSpecifier échoue ou si celui-ci ne référence pas un PortPrototype, une InstanceSpecifierMappingIntegrityViolation est signalée. Une PortInterfaceMappingViolation se produit si le port n'est pas typé selon un DiagnosticMultipleConditionInterface. S'il manque au processus l'équivalent modélisé, une ProcessMappingViolation est générée. Si le même InstanceSpecifier est instancié plusieurs fois dans le processus, cela se traduit par une InstanceSpecifierAlreadyInUseViolation.
• Erreurs d'exécution lors d'appels de méthodes : Si un paramètre non autorisé ou un descripteur non valide est transmis à SetCondition ([SWS_DM_01729]) ou GetCondition ([SWS_DM_01728]), les méthodes renvoient l'erreur DiagErrc::kInvalidArgument. Si la fonctionnalité de base du Diagnostic Management est temporairement inaccessible, GetCondition acquitte l'appel par DiagErrc::kServiceNotAvailable ([SWS_DM_01728]).