classe <SI-Namespace>::skeleton::<SI>Skeleton

La méthode OfferService() est appelée sur une instance de la classe skeleton afin de proposer un service fourni dans le système et de le rendre découvrable pour les consommateurs via la Service Discovery [SWS_CM_00101], ARAComAPI §6.5 « Service Discovery ». L'appel s'effectue sans paramètre et de façon synchrone dès que l'implémentation du service a été entièrement instanciée et mise dans un état opérationnel AUTOSAR_AP_EXP_ARAComAPI §5.4.4 « Offering Service instance ». La fonction est déclarée comme noexcept et renvoie un ara::core::Result<void> [SWS_CM_00101].

L'offre est une condition préalable obligatoire pour la communication fonctionnelle via des méthodes, des événements, des champs ou des déclencheurs AUTOSAR_AP_EXP_ARAComAPI §4.2 « Means of Communication ». Si l'on tente par exemple d'envoyer un déclencheur sans offre préalable, cela échoue avec ComErrc::kServiceNotOffered [SWS_CM_00721]. Concernant la concurrence : dès que OfferService() est appelé, les appels de méthode entrants peuvent déjà être remis à l'instance de service – même si l'appel de OfferService() n'est pas encore revenu AUTOSAR_AP_EXP_ARAComAPI §5.4.4 « Offering Service instance ».

Si la mise à disposition échoue, le ara::core::Result renvoyé contient un code d'erreur correspondant issu de ComErrc [SWS_CM_00101], [SWS_CM_10432] :

• ComErrc::kFieldValueNotInitialized : au moins une valeur de champ configurée n'a pas encore été initialisée avant la mise à disposition [SWS_CM_00101].
• ComErrc::kFieldSetHandlerNotSet : pour un champ prenant en charge un setter, aucun gestionnaire n'a encore été enregistré via RegisterSetHandler() [SWS_CM_00101].
• ComErrc::kCommunicationFailure : la liaison réseau signale une erreur de communication récupérable ou l'échec d'une communication sécurisée [SWS_CM_00101].

Si la mise à disposition du service doit être terminée, StopOfferService() doit être appelée AUTOSAR_AP_EXP_ARAComAPI §5.4.4 « Offering Service instance ».

La méthode ProcessNextMethodCall() sert aux fournisseurs de service dans le skeleton à traiter de manière déterministe les appels de méthode entrants en mode polling [SWS_CM_00199]. Elle ne doit être utilisée que si l'instance de skeleton a été configurée avec le mode ara::com::MethodCallProcessingMode::kPoll EXP ARAComAPI §2 « Polling ».

Utilisation et sémantique

La fonction ne prend aucun paramètre et exécute une requête d'appel de méthode en attente de façon synchrone dans le contexte de thread de l'appelant [SWS_CM_00199], [SWS_CM_00191]. Cela permet notamment aux applications temps réel de traiter les requêtes de service sans changements de contexte de thread incontrôlés dans les limites de leur budget de temps alloué EXP ARAComAPI §5.4 « ProcessNextMethodCall ». La valeur de retour signale le résultat de la récupération :

• true : au moins une requête en attente se trouvait dans la file d'attente et a été traitée [SWS_CM_00199].
• false : aucune requête n'était en attente ; la file d'attente était vide [SWS_CM_00199]. Un appel suivant direct après un false reste en règle générale sans effet EXP ARAComAPI §5.4 « ProcessNextMethodCall ».

Gestion des erreurs et conditions limites

La fonction est spécifiée comme noexcept et exception safe [SWS_CM_00199]. Un appel sur un skeleton instancié avec kEvent ou kEventSingleThread constitue une violation (WrongMethodCallProcessingModeViolation) [SWS_CM_00199]. Interprétation : les exceptions C++ standards étant exclues par noexcept, une telle violation devrait être traitée du côté de la plateforme comme une erreur d'exécution grave. Question Q-61661dbd6cc37bc7 (ouverte)

Utilisation

La fonction SetTransportFaultConditionHandler sert à enregistrer un rappel de type ara::com::e2e::TransportFaultConditionHandler dans l’espace de noms de la classe Skeleton (<SI-Namespace>::skeleton::<SI>) [SWS_CM_00093]. Les erreurs de transport sont signalées via ce gestionnaire pour toutes les méthodes de l’instance de service correspondante AUTOSAR_AP_SWS_CommunicationManagement §7.4.1 « End-to-end communication protection for SOMEIP ». La fonction prend en charge l’objet appelable handler et ne possède aucune valeur de retour (void) [SWS_CM_00093].

Gestion des erreurs

L’opération est déclarée avec noexcept et est sûre vis-à-vis des exceptions (exception safe) [SWS_CM_00093]. Si l’entité appelable transmise n’existe pas ou vaut null, un InvalidHandlerViolation est déclenché [SWS_CM_00093]. En cas d’erreur, le gestionnaire configuré signale les perturbations de transport survenues, telles que TransportFaultCondition::kSampleRejected, lorsque des requêtes sont rejetées en raison d’un manque de ressources ou d’une corruption dans la couche de transport AUTOSAR_AP_SWS_CommunicationManagement §7.4.2.3 « Methods ».

Concurrence et restrictions

Interpretation : comme cette interface de base ne prend en charge aucun contexte d’exécution, le rappel devrait être appelé de manière synchrone depuis le thread interne de Communication Management. Question Q-e4007fa72de6aa12 (ouverte) Si l’exécution du gestionnaire doit avoir lieu dans un pool de threads ou un worker défini, il convient d’utiliser la surcharge avec ExecutorT&& executor [SWS_CM_00094].

Interaction

L’enregistrement lie le traitement des erreurs de manière centralisée à toutes les méthodes d’une instance de Skeleton [SWS_CM_00093]. Il s’intègre dans le traitement global des erreurs de ara::com :

• Tandis que les méthodes du Skeleton signalent les erreurs de transport via ce gestionnaire, les méthodes clientes signalent les défaillances de transport de manière asynchrone via leur ara::core::Future résultant avec ComErrc::kCommunicationFailure [SWS_CM_00090].
• Pour les opérations sur les champs (Get/Set) au niveau du Skeleton, il existe des interfaces distinctes [SWS_CM_00096].
• Au niveau du Proxy, des fonctions d’enregistrement analogues sont disponibles pour les événements [SWS_CM_00099], les déclencheurs [SWS_CM_00106] ainsi que les notificateurs [SWS_CM_00109].

La fonction modèle SetTransportFaultConditionHandler dans l'espace de noms de la classe squelette sert à enregistrer un gestionnaire d'erreurs pour les erreurs de transport de toutes les méthodes d'une instance de service [SWS_CM_00094]. Elle étend la fonction de base sans paramètre [SWS_CM_00093] d'un contexte d'exécution :

• Appel et paramètres : sont transmis un callable handler de type ara::com::e2e::TransportFaultConditionHandler ainsi qu'une référence universelle executor [SWS_CM_00094]. Tous les calculs asynchrones et exécutions de callbacks doivent être démarrés dans cet objet executor. La fonction ne possède aucune valeur de retour.
• Traitement des erreurs : l'interface est déclarée comme noexcept et spécifiée comme sûre vis-à-vis des exceptions [SWS_CM_00094]. Si le callable transmis n'existe pas ou s'il est nul, il s'agit d'un InvalidHandlerViolation [SWS_CM_00094].
• Interaction : le domaine de validité englobe toutes les méthodes du squelette [SWS_CM_00094], tandis que des fonctions d'enregistrement distinctes sont disponibles pour les opérations Get et Set de fields ([SWS_CM_00096], [SWS_CM_00097]). Dans le binding réseau DDS, le gestionnaire configuré signale des erreurs de transport telles que TransportFaultCondition::kSampleRejected [SWS_CM_00216] ; côté client, de telles erreurs sont en revanche signalées via ComErrc::kCommunicationFailure dans les futures de résultat [SWS_CM_00090].
• Concurrence : interprétation : la transmission de l'executor découple le traitement des erreurs du contexte interne de la couche de communication ; l'enregistrement devrait probablement s'effectuer précocement lors de l'initialisation du squelette, avant l'arrivée des premiers appels de méthode. Question Q-e56b2a1928cf32ad (ouverte)

Le constructeur [SWS_CM_00130] instancie un squelette de service sur la base d'un ara::com::InstanceIdentifier concret. Le squelette raccorde l'implémentation de service côté application à la couche de transport du Communication Management, afin que les consommateurs de service distribués puissent y accéder (ARAComAPI §5.1 « Proxy Skeleton Pattern »).

Le paramètre mode définit la manière dont les appels de méthode entrants sont traités. Le mode événementiel ara::com::MethodCallProcessingMode::kEvent est prédéfini comme valeur par défaut [SWS_CM_00130]. Si un mode basé sur le polling est choisi à la place, l'exécution des appels de méthode en attente s'effectue de manière synchrone dans le contexte d'appel de ProcessNextMethodCall() [SWS_CM_00199].

Gestion des erreurs et conditions limites

La fonction constructeur est déclarée avec noexcept et ne lève aucune exception C++ [SWS_CM_00130]. D'éventuelles violations sont signalées via le système d'exécution : si la création est refusée par le grant enforcement, il s'agit d'un InsufficientPermissionsViolation ; lors de la transmission d'un mode de traitement invalide, il en résulte un WrongMethodCallProcessingModeViolation [SWS_CM_00130]. Interprétation : la validation du mode de traitement devrait avoir lieu directement pendant l'exécution du constructeur. Question Q-80e02c0079757082 (ouverte)

Les opérations de copie sont explicitement supprimées pour le squelette [SWS_CM_00134], tandis que la construction par déplacement est prise en charge [SWS_CM_00135]. Pour que le service devienne découvrable sur le réseau, OfferService() doit être appelé après l'instanciation [SWS_CM_00101] (ARAComAPI §6.5 « Service Discovery »). Avant la destruction de l'instance [SWS_CM_11370], la mise à disposition peut être interrompue à l'aide de StopOfferService() [SWS_CM_00111].

Le constructeur instancie un squelette de service à l'aide d'un identifiant d'instance [SWS_CM_00152]. Il sert à raccorder une implémentation concrète de service à la couche de transport du Communication Management. Sont transmis comme paramètres un ara::core::InstanceSpecifier ainsi que, de manière facultative, le mode de traitement ara::com::MethodCallProcessingMode, qui est préconfiguré par défaut sur kEvent [SWS_CM_00152].

Concernant la gestion des erreurs et le comportement face aux exceptions, le constructeur est déclaré comme noexcept et exception safe [SWS_CM_00152]. En cas de configurations erronées ou d'écarts de modélisation, les violations suivantes sont spécifiées :

• InstanceSpecifierMappingIntegrityViolation, si l'identifiant ne peut pas être résolu dans le contexte d'exécution ou ne référence pas un PortPrototype [SWS_CM_00152].
• PortInterfaceMappingViolation et ProcessMappingViolation, si le type de mapping et le type d'interface ne correspondent pas [SWS_CM_00152].
• InstanceSpecifierAlreadyInUseViolation, si l'InstanceSpecifier est déjà utilisé [SWS_CM_00152].
• WrongMethodCallProcessingModeViolation ainsi que InsufficientPermissionsViolation en cas de droits insuffisants [SWS_CM_00152].

Interprétation : le constructeur étant déclaré comme noexcept, les violations spécifiées ne devraient pas être propagées à l'exécution sous la forme d'exceptions C++ levées, mais interceptées par des vérifications côté plateforme ou par le Grant Enforcement. Question Q-f1a1a0baeb56e482 (ouverte)

Pour le cycle de vie et la concurrence, le constructeur de copie est supprimé [SWS_CM_00134], tandis qu'un constructeur de déplacement est mis à disposition [SWS_CM_00135]. La libération s'effectue via le destructeur virtuel [SWS_CM_11370]. Après une construction réussie, le service est typiquement proposé sur le réseau via [SWS_CM_00101] (OfferService). Si le mode de traitement choisi est kPoll, l'application doit traiter explicitement les appels entrants des méthodes de service [SWS_CM_00191] via [SWS_CM_00199] (ProcessNextMethodCall).

Utilisation

Le constructeur instancie un squelette de service à partir d'un conteneur d'identifiants d'instance (instanceIDs) et relie l'implémentation du service côté serveur à la couche de transport de Communication Management [SWS_CM_00153], ARAComAPI §5.1 « Proxy Skeleton Pattern ». Le paramètre mode définit la manière dont les appels de méthode entrants sont traités ; par défaut, le traitement est événementiel via kEvent [SWS_CM_00153]. Des constructeurs pour des identifiants d'instance individuels [SWS_CM_00130] ou des spécificateurs d'instance [SWS_CM_00152] sont également disponibles.

Gestion des erreurs et concurrence

La fonction est déclarée comme noexcept et spécifiée comme sûre vis-à-vis des exceptions (exception safe) [SWS_CM_00153]. Les violations possibles lors de la création sont WrongMethodCallProcessingModeViolation en cas de transmission d'un mode de traitement non autorisé ainsi que InsufficientPermissionsViolation si le contrôle des autorisations (Grant Enforcement) échoue [SWS_CM_00153].

Si le modèle d'interrogation (kPoll) est configuré pour mode, l'application serveur doit exécuter les appels de méthode en attente de manière synchrone dans son propre contexte de thread en appelant ProcessNextMethodCall() [SWS_CM_00199]. Le constructeur de copie de la classe skeleton est supprimé (delete) [SWS_CM_00134] ; en revanche, les déplacements sont pris en charge via le constructeur de déplacement [SWS_CM_00135].

Interaction

Après une instanciation réussie, le service est mis à disposition des consommateurs distants ou locaux via OfferService() [SWS_CM_00101], ARAComAPI §6.5 « Service Discovery ». Avant de détruire le squelette à l'aide du destructeur [SWS_CM_11370], la mise à disposition doit être terminée via StopOfferService() [SWS_CM_00111]. Les appels de méthode entrants renvoient chacun un ara::core::Future côté serveur [SWS_CM_00191].

Le destructeur virtuel ~<SI>Skeleton() [SWS_CM_11370] met fin au cycle de vie d'une instance de skeleton de service. En tant qu'artefact généré, le skeleton de service relie l'implémentation concrète du service à la couche de transport du Communication Management, afin que les consommateurs de services puissent atteindre les méthodes et fonctionnalités offertes (ARAComAPI §5.1 « Proxy Skeleton Pattern »).

La destruction s'effectue de manière synchrone lors de la déconstruction de la classe d'implémentation dérivée. La méthode ne prend aucun paramètre et ne déclare aucune valeur de retour. Contrairement aux constructeurs du skeleton tels que [SWS_CM_00130] ou [SWS_CM_00152], le destructeur est explicitement classé comme not exception safe dans la spécification [SWS_CM_11370].

En ce qui concerne le traitement des erreurs et les conditions aux limites, il est établi qu'une DanglingSamplesViolation peut survenir en cas de précondition violée [SWS_CM_11370]. Si le service a été préalablement proposé vers l'extérieur au moyen de OfferService() [SWS_CM_00101] (ARAComAPI §6.5 « Service Discovery »), la méthode StopOfferService() [SWS_CM_00111] devrait vraisemblablement devoir être appelée avant l'appel du destructeur afin de clore proprement les relations de communication en cours. Question Q-c430a7f0fc838eba (ouverte)

Pour le skeleton, le constructeur de copie est supprimé [SWS_CM_00134], tandis que les opérations de déplacement sont prises en charge [SWS_CM_00135]. Les opérations de traitement en cours – telles que l'exécution des appels en attente via ProcessNextMethodCall() [SWS_CM_00199] – devraient être terminées avant le début de la destruction.

La méthode [SWS_CM_00111] met fin à la proposition d'une instance de service par l'application fournisseuse de service dans ara::com. L'appel s'effectue sans paramètre sur l'instance concrète de skeleton dans l'espace de noms <SI-Namespace>::skeleton::<SI> et ne renvoie aucune valeur de retour (EXP_ARAComAPI §5.4.1 « Skeleton Class API’s »).

Les conditions suivantes s'appliquent à l'utilisation et au comportement à l'exécution :

• Contexte d'appel et précondition : la méthode est appelée lorsqu'une instance précédemment mise à disposition au moyen de OfferService() ne doit plus être disponible (EXP_ARAComAPI §5.4.4 « Offering Service instance »), par exemple à la suite de changements d'état.
• Garantie contractuelle (Contract) : dès que StopOfferService() est retournée, aucun appel de méthode supplémentaire n'est plus transmis à cette instance de service, conformément au contrat (EXP_ARAComAPI §5.4.4 « Offering Service instance »).
• Cycle de vie et destructeur : si une instance de service est encore activement proposée lors de l'appel du destructeur de la classe skeleton, le destructeur exécute obligatoirement StopOfferService() en interne (EXP_ARAComAPI §5.4.4 « Offering Service instance »).
• Service Discovery : par cet appel, le registre local ou le protocole de Service Discovery du middleware est mis à jour concernant le retrait du service (EXP_ARAComAPI §7.2.1 « Central vs Distributed approach »).

La fonction est déclarée comme noexcept et est considérée comme sûre vis-à-vis des exceptions ([SWS_CM_00111]). Elle ne signale d'erreurs ni par le biais d'exceptions, ni par des messages d'erreur ou des codes de retour.