classe apext::com::secoc::ComSecOcFvmException

La classe apext::com::secoc::ComSecOcFvmException sert, dans le module com, de classe d'exception spécialisée pour signaler les erreurs survenant au sein du SecOC Freshness Value Manager [SWS_CM_12512]. Elle hérite de ara::core::Exception et est instanciée puis levée par le Freshness Value Manager pour transmettre de manière structurée les états d'erreur aux couches de communication supérieures. Son constructeur prend obligatoirement un ara::core::ErrorCode et est déclaré comme noexcept, ce qui garantit une création de l'objet d'erreur sans émission d'exception et sans erreurs secondaires [SWS_CM_12513].

plus ›

Contexte

La classe apext::com::secoc::ComSecOcFvmException est une classe d'exception spécialisée de l'AUTOSAR Adaptive Platform dans le module com [SWS_CM_12512]. Elle sert principalement à signaler les états d'erreur qui surviennent au sein du SecOC Freshness Value Manager (FVM) (AUTOSAR_AP_SWS_CommunicationManagement §C.2.4 « Class: ComSecOcFvmException »). En dérivant de la classe de base standard ara::core::Exception, ComSecOcFvmException s'intègre dans le modèle général de traitement des erreurs de l'Adaptive Platform et agit comme vecteur d'information standardisé pour les conditions exceptionnelles lors de la sécurisation de la communication au moyen de SecOC.

Trois composants interviennent principalement comme partenaires d'interaction : le SecOC Freshness Value Manager lui-même, qui déclenche l'exception en cas d'erreur, la couche de communication fonctionnelle appelante ou l'application qui traite les données sécurisées par SecOC, ainsi que le domaine d'erreur du FVM, inclus via le fichier d'en-tête apext/com/secoc/fvm_error_domain.h [SWS_CM_12513]. La classe constitue ainsi le lien entre les états d'erreur internes de la gestion de la fraîcheur et les couches logicielles supérieures.

Cycle de vie

L'instanciation de ComSecOcFvmException s'effectue à la demande, précisément lorsqu'une erreur non récupérable est constatée lors de la détermination ou de la vérification de valeurs de fraîcheur. À cet effet, la classe fournit un constructeur explicite qui reçoit un ara::core::ErrorCode [SWS_CM_12513].

Ce constructeur est déclaré comme noexcept [SWS_CM_12513]. Cela garantit que la création de l'objet elle-même n'échoue sous aucun prétexte et ne lève aucune autre exception, ce qui respecte la spécification de sécurité face aux exceptions (exception safe) [SWS_CM_12513]. En ce qui concerne le cycle de vie et l'appartenance, l'exception est créée et levée par valeur. Côté récepteur, elle est probablement interceptée sous forme de référence constante (const ComSecOcFvmException& ou de manière polymorphe comme const ara::core::Exception&). Question Q-d170140b08fe9ca0 (ouverte)

Dès que le bloc de traitement d'exception correspondant (catch) est exécuté, l'instance d'exception est automatiquement détruite. En ce qui concerne la concurrence, les instances de l'exception sont probablement traitées localement au thread dans le contexte d'exception de chaque thread. Question Q-bd368a082b887d14 (ouverte)

Parcours d'utilisation

Le chemin d'utilisation typique s'étend de la détection d'une erreur de fraîcheur jusqu'à la réaction ciblée de la couche de communication supérieure.

Diagramme de séquence : Déroulement du traitement des exceptions par le Freshness Value Manager avec ComSecOcFvmException. Sources : [SWS_CM_12512], [SWS_CM_12513], AUTOSAR_AP_SWS_CommunicationManagement §C.2.4

Dans un premier temps, le module de communication ou l'application demande une valeur de fraîcheur auprès du Freshness Value Manager ou lui en transmet une pour validation dans le cadre du traitement SecOC. Si cette opération échoue – par exemple en raison de problèmes de synchronisation ou de valeurs de compteur non valides –, le Freshness Value Manager instancie la classe d'exception ComSecOcFvmException en lui transmettant le code d'erreur concret [SWS_CM_12513]. Immédiatement après la construction, l'exception est levée. L'appelant intercepte l'exception dans le gestionnaire approprié et peut interroger le ara::core::ErrorCode contenu afin de réagir de manière adaptée à la dégradation de la sécurité de communication [SWS_CM_12512].

Scénarios d'erreur

Comme ComSecOcFvmException constitue elle-même le moyen de transport pour la signalisation des erreurs, les scénarios d'erreur se concentrent sur le contenu sémantique du code d'erreur encapsulé. Pour sa création, la classe requiert obligatoirement un ara::core::ErrorCode [SWS_CM_12513]. L'association de l'en-tête à apext/com/secoc/fvm_error_domain.h prouve que ces codes d'erreur proviennent d'un domaine d'erreur FVM dédié [SWS_CM_12513].

Une précondition essentielle pour la création est que le contexte déclencheur fournisse un code d'erreur initialisé. Comme postcondition, l'objet résultant contient les informations d'erreur complètes du domaine d'erreur respectif. Un scénario d'erreur critique d'apparition d'exception secondaire pendant la création de l'exception est exclu par la garantie noexcept du constructeur [SWS_CM_12513]. Cela empêche de manière fiable une interruption prématurée du processus via std::terminate suite à un échec dans le chemin de traitement d'erreur.