module ara::com — Communication Management

Le Functional Cluster Communication Management (ara::com) permet l'interaction orientée services entre applications Adaptive via des interfaces proxy et skeleton standardisées (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Il gère la découverte dynamique des services au moyen de OfferService() et FindService() ([SWS_CM_00101], [SWS_CM_00122]) et met à disposition des méthodes synchrones ainsi qu'asynchrones, des événements et des champs avec protection E2E et SecOC intégrée ([SWS_CM_00141], [SWS_CM_90420]). En cas de perte temporaire d'un service, le middleware intercepte les interruptions de liaison et met à jour automatiquement les objets proxy existants dès qu'ils redeviennent disponibles (ARAComAPI p. 32).

plus ›

Le Functional Cluster Communication Management (ara::com) constitue l'épine dorsale de l'architecture orientée services (SOA) dans l'AUTOSAR Adaptive Platform et découple la logique applicative des protocoles de transmission concrets via le patron proxy-skeleton (SWS_CommunicationManagement p. 55, ARAComAPI p. 1). Des classes proxy côté consommateur et des classes skeleton côté fournisseur, générées à partir de descriptions d'interfaces formelles, mettent à disposition des méthodes, des événements et des champs via des API C++ à sûreté de typage ([SWS_CM_00130], [SWS_CM_00131]).

La mise à disposition et la recherche dynamique de services sont prises en charge par le Service Discovery (SWS_CommunicationManagement p. 67). Un fournisseur propose son service via OfferService() ([SWS_CM_00101]), tandis que les consommateurs déterminent les instances appropriées de manière synchrone via FindService() ou de manière asynchrone au moyen de StartFindService() ([SWS_CM_00122], [SWS_CM_00123]). Ce faisant, les instances peuvent être adressées sur une base modèle via ara::core::InstanceSpecifier et résolues au moment de l'exécution en ara::com::InstanceIdentifier concrètes ([SWS_CM_00118], [SWS_CM_00622]).

Diagramme de séquence : déroulement de l'offre de service, de la recherche asynchrone et de la création du proxy. Sources : [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Pour le transfert de données, ara::com prend en charge des méthodes requête-réponse via ara::core::Future ([SWS_CM_00191], [SWS_CM_00196]) ainsi que des patrons publication-abonnement pour les événements et les champs (AUTOSAR_EXP_ARAComAPI p. 68). Les abonnés s'enregistrent via Subscribe() ([SWS_CM_00141]) et lisent les données entrantes via GetNewSamples() ([SWS_CM_00701]). Afin d'augmenter les performances, le fournisseur met les données à disposition via Allocate() et en transfère la propriété par zero-copy via Send() ([SWS_CM_90437], [SWS_CM_90438]).

Pour sécuriser la transmission, la plateforme intègre une protection de bout en bout (E2E), une authentification cryptographique (SecOC) via la gestion des valeurs de fraîcheur (FVM) ainsi qu'une conversion signal-vers-service pour les réseaux classiques ([SWS_CM_90420], [SWS_CM_11288], [SWS_CM_10174], SWS_CommunicationManagement p. 222). Les états d'erreur sont signalés de manière standardisée via des domaines d'erreur à sûreté de typage tels que ComErrorDomain et ComE2EErrorDomain ([SWS_CM_10432], [SWS_CM_10474]). Si la connexion à un service s'interrompt, le statut du proxy passe à kSubscriptionPending ; après le rétablissement de la disponibilité, le middleware met à jour l'adressage interne de manière transparente, de sorte que la communication se poursuit sans nouvelle instanciation du proxy (ARAComAPI p. 32).

plus ›

Rôle et architecture système de la communication orientée services

Le Functional Cluster Communication Management (ara::com) constitue l'épine dorsale informatique de l'AUTOSAR Adaptive Platform et réalise la communication orientée services (Service-Oriented Architecture, SOA) entre des processus applicatifs isolés ainsi qu'au-delà des frontières de calculateurs (SWS_CommunicationManagement p. 55). Le principe fondamental repose sur le strict patron de conception proxy-skeleton (ARAComAPI p. 1) : à partir de descriptions formelles d'interfaces logicielles (Service Interfaces), un générateur de code basé sur des modèles génère des classes proxy typées pour les consommateurs de services et des classes skeleton pour les fournisseurs de services ([SWS_CM_00130], [SWS_CM_00131]). La logique applicative interagit exclusivement avec ces abstractions, tandis que les liaisons spécifiques aux protocoles comme SOME/IP, IPC ou DDS ainsi que leur sérialisation ne sont rattachées qu'au moment de l'intégration et du déploiement (AUTOSAR_AP_EXP_ARAComAPI p. 124).

Pour satisfaire aux exigences de la plateforme, ara::com coopère étroitement avec d'autres clusters de fonctionnalités (SWS_CommunicationManagement p. 34). Au moment de l'exécution, Execution Management surveille le cycle de vie des processus, tandis qu'Identity and Access Management (IAM) bloque les interactions non autorisées au niveau méthode, événement et champ grâce à des vérifications d'accès basées sur des règles (Policy Decision Point) (SWS_CommunicationManagement p. 215). De plus, les événements de sécurité sont directement signalés à l'EventReporter de l'Intrusion Detection System Manager (IdSM) (SWS_CommunicationManagement p. 34).

Diagramme de contexte : intégration d'ara::com et découplage des couches applicatives via des bindings. Sources : SWS_CommunicationManagement p. 55, ARAComAPI p. 1

Découverte de services et instanciation via des proxys et des skeletons

La médiation dynamique de services (Service Discovery) régit l'établissement des relations de communication locales et distribuées (SWS_CommunicationManagement p. 67). Un fournisseur de service signale sa disponibilité en appelant OfferService() sur le skeleton ([SWS_CM_00101]). Si le service prend fin ou si sa mise à disposition est révoquée, StopOfferService() retire l'offre ([SWS_CM_00111]). Les consommateurs déterminent les instances de service correspondantes de manière synchrone via FindService() ou asynchrone via StartFindService() ([SWS_CM_00122], [SWS_CM_00123], ARAComAPI p. 103). Ce dernier enregistre un FindServiceHandler qui est notifié à chaque modification du paysage d'instances jusqu'à ce que la recherche soit explicitement arrêtée au moyen de StopFindService() ([SWS_CM_00125], [SWS_CM_00383]).

Afin de découpler le code source des identifiants fixes de réseau et d'instance, l'interface permet l'adressage via des chemins de modèle abstraits au moyen de ara::core::InstanceSpecifier ([SWS_CM_00622], [SWS_CM_00623], AUTOSAR_AP_EXP_ARAComAPI p. 124). Le middleware résout ces spécificateurs en ara::com::InstanceIdentifier concrets via le Service Instance Manifest associé ([SWS_CM_00118], [SWS_CM_11520], ARAComAPI p. 1). Un service trouvé est mis à disposition sous forme de descripteur typé (HandleType) dans un ServiceHandleContainer ([SWS_CM_10383], AUTOSAR_EXP_SensorInterfaces p. 16). Par le biais de la méthode fabrique statique Proxy::Create() ou du constructeur, le consommateur crée une instance de proxy liée en vue de l'utilisation ultérieure des fonctionnalités ([SWS_CM_10438], [SWS_CM_00131]).

Diagramme de séquence : déroulement de l'offre de service, de la recherche asynchrone et de la création du proxy. Sources : [SWS_CM_00101], [SWS_CM_00123], [SWS_CM_10438], AUTOSAR_EXP_SensorInterfaces p. 16

Modèles d'interaction : appels de méthode et traitement asynchrone

Les appels de méthode mettent en œuvre le paradigme requête-réponse synchrone et asynchrone. Le client déclenche les méthodes via l'opérateur d'appel de fonction operator() sur le proxy ([SWS_CM_00196]). Un ara::core::Future, qui encapsule le résultat ou un état d'erreur, sert par défaut de type de retour ([SWS_CM_00191], ARAComAPI p. 1). Le consommateur choisit librement le mode de synchronisation : par interrogation bloquante via get(), attente temporisée via wait_for() ou wait_until(), ou encore par enregistrement de routines de rappel basées sur les événements au moyen de then() (ARAComAPI p. 1). Pour les pures notifications unidirectionnelles sans acquittement, il existe des méthodes de type Fire-and-Forget avec un retour void ([SWS_CM_90434], [SWS_CM_90435]).

Côté fournisseur, le MethodCallProcessingMode définit la stratégie d'exécution pour les appels entrants ([SWS_CM_00301], [SWS_CM_00130]). En mode événementiel (kEvent ou kEventSingleThread), l'appel de méthode s'effectue immédiatement au sein d'un thread de travail géré par le middleware (AUTOSAR_SWS_CommunicationManagement p. 60). En mode d'interrogation (kPoll), l'application pilote elle-même les instants de traitement de manière déterministe en appelant régulièrement ProcessNextMethodCall() ([SWS_CM_00199], EXP_SWArchitecture p. 68). L'implémentation de la méthode génère le résultat en interne via un ara::core::Promise et renvoie le future associé (ARAComAPI p. 1).

Diagramme de séquence : appel de méthode entre le proxy et le skeleton avec dispatching kPoll et kEvent. Sources : [SWS_CM_00196], [SWS_CM_00199], AUTOSAR_SWS_CommunicationManagement p. 60

Communication par événements et par champs selon le modèle publication-abonnement

La distribution des flux de données continus et des changements d'état s'effectue via des événements et des champs selon le modèle publication-abonnement (SWS_CommunicationManagement p. 67). Un abonné actif signale son intérêt pour la réception via Subscribe() en indiquant le nombre maximal d'échantillons à conserver (maxSampleCount) ([SWS_CM_00141], [SWS_CM_12002]). L'état de l'abonnement est interrogé via GetSubscriptionState() ou surveillé de manière asynchrone par des rappels via SetSubscriptionStateChangeHandler() ([SWS_CM_00310], [SWS_CM_00316], [SWS_CM_01110]). La résiliation de l'abonnement s'effectue via Unsubscribe() ([SWS_CM_00151]).

La réception des données peut s'effectuer de manière événementielle via SetReceiveHandler() ou par lecture périodique du tampon de réception ([SWS_CM_00181], [SWS_CM_11356]). Avec GetNewSamples(), le consommateur transmet un objet fonction (lambda) qui est appelé pour chaque échantillon arrivé avec un SamplePtr typé ([SWS_CM_00701], [SWS_CM_11610]). Pour éviter les opérations de copie (zero-copy), le skeleton alloue de la mémoire via Allocate() et transmet le pointeur typé SampleAllocateePtr à la couche de transport via Send() avec transfert complet de propriété ([SWS_CM_90438], [SWS_CM_90437], [SWS_CM_00308], AUTOSAR_EXP_ARAComAPI p. 63, ARAComAPI p. 1).

Un champ étend le concept d'événement avec une sémantique de getter et de setter (AUTOSAR_EXP_ARAComAPI p. 68). Les consommateurs lisent le champ via Get() ou l'écrivent via Set() ([SWS_CM_00112], [SWS_CM_00113]). Côté serveur, ces requêtes sont traitées avec RegisterGetHandler() ou RegisterSetHandler() ([SWS_CM_00114], [SWS_CM_00116]). Si le serveur met à jour l'état via Update(), le champ agit automatiquement comme notificateur et distribue la modification à tous les abonnés enregistrés ([SWS_CM_00119], ARAComAPI p. 1).

Diagramme de séquence : allocation zero-copy, publication d'événements, abonnement et consommation GetNewSamples. Sources : [SWS_CM_00141], [SWS_CM_00701], [SWS_CM_90437], AUTOSAR_EXP_ARAComAPI p. 63

Sécurisation, traduction de services et intégration de plateforme

Pour les flux de données déterministes et critiques pour la sécurité, ara::com intègre une protection de bout en bout (E2E) ainsi qu'une authentification conforme aux normes AUTOSAR (AUTOSAR_AP_TR_SystemTests p. 132). Via GetProfileCheckStatus() et GetE2EStateMachineState(), les consommateurs peuvent vérifier l'état d'intégrité et de validation des données reçues ([SWS_CM_90420], [SWS_CM_90421], [SWS_CM_11554]). Côté serveur, l'application enregistre des routines de traitement des erreurs via SetTransportFaultConditionHandler() afin de réagir de manière standardisée aux défauts E2E et de transport au niveau méthode ([SWS_CM_00093], [SWS_CM_00094], [SWS_CM_00100], EXP_SWArchitecture p. 68).

L'intégrité et l'authenticité cryptographiques des messages externes sont assurées par Secure Onboard Communication (SecOC) (SWS_CommunicationManagement p. 222). À cette fin, le middleware intègre une bibliothèque interchangeable de Freshness Value Management (FVM) qui gère les valeurs de fraîcheur via GetRxFreshness(), GetTxFreshness() et Initialize() ([SWS_CM_11288], [SWS_CM_11289], [SWS_CM_11290], SWS_CommunicationManagement p. 226). Des fonctions de diagnostic et de sécurité surveillent ou contrôlent la vérification via des interfaces spécifiques telles que SetVerificationStatus() ([SWS_CM_19999], AUTOSAR_AP_EXP_SWArchitecture p. 70).

Pour assurer l'interopérabilité avec l'AUTOSAR Classic Platform, ara::com prend en charge la communication basée sur les signaux (Signal-to-Service Translation) (SWS_CommunicationManagement p. 146, TPS_ManifestSpecification p. 476). Conformément à [SWS_CM_10174] et [SWS_CM_80001], les I-PDU de signaux classiques et les messages SOME/IP peuvent être transportés sur le même socket. En présence d'une configuration SecOC basée sur les signaux, le middleware lit directement les paramètres de protection à partir du déclenchement de PDU (PDU-Triggering) du manifeste ([SWS_CM_11346], SWS_CommunicationManagement p. 228).

Diagramme d'activité : pipeline de sécurisation E2E et SecOC des messages entrants. Sources : [SWS_CM_90420], [SWS_CM_11288], SWS_CommunicationManagement p. 222

Comportement en cas d'erreur

La gestion des erreurs de ara::com repose sur des domaines d'erreur à sûreté de typage et des codes de retour du framework AUTOSAR Core ([SWS_CM_11334], [SWS_CM_11335]). Les erreurs de la couche générale de communication sont regroupées dans ComErrorDomain et codées via l'énumérateur ComErrc ([SWS_CM_10432]). En cas d'erreurs de vérification E2E, ComE2EErrorDomain signale via la valeur d'énumération ComE2EErrc des erreurs de vérification spécifiques, telles que des écarts de somme de contrôle ou des compteurs invalides ([SWS_CM_10474], [SWS_CM_12510], [SWS_CM_12511]). Pour les erreurs de fraîcheur SecOC, il existe de manière analogue ComSecOcFvmErrorDomain avec ComSecOcFvmErrc ([SWS_CM_12521], [SWS_CM_12522]).

Si une perte de connexion survient pendant l'exécution, l'état d'abonnement du proxy passe de kSubscribed à kSubscriptionPending ([SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32). Les appels de méthode échouent durant cette phase avec une erreur. Si le fournisseur de service réapparaît ensuite via Service Discovery, le middleware met à jour de façon transparente l'adressage interne du proxy sans que le consommateur ait à réinstancier l'objet proxy ; après une resynchronisation réussie, l'état repasse automatiquement à kSubscribed (ARAComAPI p. 32). Conformément à la spécification du système, la surveillance des délais impartis et des échéances (Deadline Monitoring) relève de la responsabilité du logiciel d'application lui-même (TPS_ManifestSpecification p. 504).

Diagramme d'états : cycle de vie et états de connexion d'une instance de proxy lors des changements de disponibilité du fournisseur. Sources : [SWS_CM_00310], [SWS_CM_00316], ARAComAPI p. 32

Preuves détaillées supplémentaires

Les principales exigences et interfaces système s'intègrent comme suit dans les spécifications AUTOSAR :

• Cycle de vie des services et découverte : la mise à disposition des services et les mécanismes de recherche reposent sur [SWS_CM_00101], [SWS_CM_00111], [SWS_CM_00122] et [SWS_CM_00123], détaillés dans le guide d'architecture logicielle (ARAComAPI p. 103).
• Paradigmes d'interaction : les méthodes et les valeurs futures asynchrones sont normalisées dans [SWS_CM_00191] et [SWS_CM_00196] ; les abonnements aux événements et les transmissions d'échantillons suivent [SWS_CM_00141], [SWS_CM_00701] et [SWS_CM_90437] (SWS_CommunicationManagement p. 67).
• Sécurité et sérialisation : les concepts de protection pour E2E ([SWS_CM_90420]), SecOC ([SWS_CM_90108], [SWS_CM_11288]) et la traduction de signaux en services ([SWS_CM_10174]) régissent l'échange de données à l'échelle du système (SWS_CommunicationManagement p. 146, SWS_CommunicationManagement p. 222).
• Définitions de manifestes et de types : la représentation des types de données structurés, des champs optionnels et des spécificateurs d'instance est ancrée dans la spécification du manifeste (TPS_ManifestSpecification p. 161, TPS_ManifestSpecification p. 458).