AUTOSAR COM

Utilisation et sémantique

La fonction Com_Init initialise les interfaces internes et externes ainsi que les variables de la couche AUTOSAR COM pour le traitement ultérieur ([SWS_Com_00432]). L'appel s'effectue de manière synchrone et est non réentrant (Non Reentrant) ([SWS_Com_00432]). Le paramètre transmis config sert de pointeur vers les données de configuration du module COM (const Com_ConfigType* config) ; aucune valeur de retour n'existe ([SWS_Com_00432]). Dans les configurations multi-partitions, où les fonctions principales du module COM sont assignées à plusieurs partitions, COM peut fournir une fonction d'initialisation propre par partition ([SWS_Com_00432]).

Conditions d'ordonnancement et gestion des erreurs

L'initialisation via Com_Init est le prérequis fonctionnel pour l'utilisation régulière des interfaces COM : si un service d'API est appelé avant Com_Init ou après un appel de Com_DeInit, le code d'erreur COM_E_UNINIT (0x02) est généré ([SWS_Com_00804]). Sont exclusivement exemptés de ce contrôle d'erreur les appels de Com_GetStatus, Com_GetVersionInfo, Com_MainFunctionRx, Com_MainFunctionTx et Com_MainFunctionRouteSignals ([SWS_Com_00804]).

Interaction lors de l'initialisation des PDU et des signaux

Après l'exécution de Com_Init, la communication inter-ECU proprement dite reste dans un premier temps désactivée ([SWS_Com_00432]). Interprétation : pour le fonctionnement régulier en émission et en réception, une activation ultérieure des groupes d'I-PDU respectifs devrait donc être nécessaire. Question Q-8407f9a6281c3764 (ouverte) Pour certaines structures de données, Com_Init effectue cependant déjà des initialisations directes :

• Si une I-PDU n'est affectée à aucun groupe d'I-PDU, COM démarre déjà cette I-PDU au sein de Com_Init comme si elle avait été démarrée via Com_IpduGroupStart avec le paramètre d'initialisation défini ([SWS_Com_00840]).
• Pour les groupes de signaux avec accès par tableau configuré (ComSignalGroupArrayAccess), Com_Init initialise la zone de tampon associée de l'I-PDU à l'aide des valeurs initiales (ComSignalInitValue) de tous les signaux de groupe inclus ([SWS_Com_00850]).

Utilisation et contexte d'appel

La fonction synchrone [SWS_Com_00130] (Interprétation : désignée dans le payload sous 'Init', mais spécifiant la signature void Com_DeInit(void)) met fin à la communication inter-ECU et place le module AUTOSAR COM à l'état non initialisé ([SWS_Com_00130]). Question Q-3e91d7d0a140cee0 (ouverte) Le service possède le Service-ID 0x02, ne requiert aucun paramètre d'entrée, ne renvoie aucune valeur de retour et est mis à disposition via le fichier d'en-tête Com.h ([SWS_Com_00130]).

Concurrence et restrictions

Concernant le contexte d'appel, la fonction est définie comme non réentrante (Non Reentrant) ([SWS_Com_00130]). Un appel parallèle ou multiple sans réinitialisation préalable est donc interdit.

Zusammenspiel et cycle de vie

La désinitialisation arrête tous les groupes d'I-PDU précédemment démarrés ([SWS_Com_00130]). Les conditions d'ordonnancement suivantes s'appliquent pour une reprise ultérieure de la communication :

• Le module doit être réinitialisé via le service synchrone non réentrant Com_Init en transmettant le pointeur de configuration config ([SWS_Com_00432]).
• Étant donné que la communication inter-ECU demeure désactivée après l'appel de Com_Init ([SWS_Com_00432]), les groupes d'I-PDU requis doivent ensuite être redémarrés explicitement ([SWS_Com_00130]).

La fonction synchrone Com_IpduGroupStart (Service ID 0x03, en-tête Com.h) sert à démarrer un groupe d'I-PDU préconfiguré [SWS_Com_91001]. Après l'appel, la transmission des I-PDU associées est activée ; par exemple, les I-PDU cycliques sont désormais envoyées de manière cyclique [SWS_Com_91001].

Utilisation et paramètres

La fonction ne possède pas de valeur de retour et accepte deux paramètres d'entrée [SWS_Com_91001] :

• IpduGroupId : identifiant unique du groupe d'I-PDU préconfiguré à démarrer [SWS_Com_91001].
• initialize : un drapeau booléen destiné à demander l'initialisation des données des I-PDU de ce groupe avant le démarrage [SWS_Com_91001].

Si initialize est défini sur true, toutes les I-PDU du groupe doivent être (ré)initialisées avant le démarrage [SWS_Com_91001]. Les I-PDU se comportent ensuite comme immédiatement après un démarrage du module COM [SWS_Com_91001]. Cela inclut en particulier la réinitialisation de la valeur précédente (old_value) des objets filtres ainsi que des tampons d'ombre pour les groupes de signaux [SWS_Com_91001].

Concurrence et restrictions

Concernant la concurrence, Com_IpduGroupStart est réentrante pour des groupes d'I-PDU différents, mais explicitement non réentrante pour le même groupe d'I-PDU [SWS_Com_91001].

Utilisation

La fonction Com_IpduGroupStop sert à arrêter un groupe d'I-PDU préconfiguré dans le module AUTOSAR COM [SWS_Com_91002]. La déclaration est disponible via le fichier d'en-tête Com.h et possède le Service ID 0x04 [SWS_Com_91002].

• Syntaxe d'appel : void Com_IpduGroupStop (Com_IpduGroupIdType IpduGroupId) [SWS_Com_91002].
• Paramètres : le paramètre d'entrée IpduGroupId de type Com_IpduGroupIdType est transmis comme unique paramètre, définissant l'identifiant du groupe d'I-PDU à arrêter [SWS_Com_91002]. Il n'existe pas de paramètres d'entrée/sortie (inout) ou de sortie (out) supplémentaires [SWS_Com_91002].
• Valeur de retour : l'interface ne renvoie aucune valeur de retour (void) [SWS_Com_91002].
• Comportement d'exécution : l'appel est traité de manière synchrone [SWS_Com_91002]. Après l'appel de Com_IpduGroupStop, la communication du groupe concerné est arrêtée ; cela entraîne par exemple l'arrêt de l'émission des I-PDU cycliques du groupe [SWS_Com_91002].

Concurrence et restrictions

En matière de concurrence et de réentrance, il est défini que Com_IpduGroupStop est réentrante pour des groupes d'I-PDU différents, mais ne doit pas être exécutée de manière réentrante pour le même groupe d'I-PDU [SWS_Com_91002]. Si la fonction est appelée dans des environnements multitâches ou multicœurs, le logiciel appelant doit s'assurer que les appels concurrents pour un même ID de groupe sont exclus.

La fonction synchrone Com_EnableReceptionDM sert à activer la surveillance des délais de réception (Reception Deadline Monitoring) pour toutes les I-PDU au sein d'un groupe d'I-PDU prédéfini [SWS_Com_91004].

Utilisation et contexte d'appel : la fonction est déclarée via le fichier d'en-tête Com.h et possède le Service ID 0x06 [SWS_Com_91004]. Comme unique paramètre de transmission, la signature void Com_EnableReceptionDM (Com_IpduGroupIdType IpduGroupId) attend le paramètre d'entrée IpduGroupId de type Com_IpduGroupIdType, qui représente l'identifiant du groupe d'I-PDU pour les I-PDU contenues duquel la surveillance des délais doit être activée [SWS_Com_91004]. L'exécution est synchrone [SWS_Com_91004]. Il n'existe aucun paramètre d'entrée/sortie ni paramètre de sortie, et aucune valeur de retour n'est fournie (type de retour void) [SWS_Com_91004].

Concurrence et restrictions : concernant la concurrence, Com_EnableReceptionDM est réentrante pour des groupes d'I-PDU différents, mais non réentrante pour le même groupe d'I-PDU [SWS_Com_91004]. Les appels concurrents pour le même ID de groupe ne sont donc pas autorisés et doivent être évités dans le contexte d'appel [SWS_Com_91004].

La fonction synchrone Com_DisableReceptionDM désactive la surveillance de date limite de réception (Reception Deadline Monitoring) pour toutes les I-PDU au sein du groupe d'I-PDU transmis [SWS_Com_91003].

Utilisation

L'appel s'effectue via l'interface void Com_DisableReceptionDM(Com_IpduGroupIdType IpduGroupId) avec l'identifiant du groupe d'I-PDU concerné comme paramètre d'entrée IpduGroupId [SWS_Com_91003]. La fonction ne possède ni paramètres d'entrée/sortie ni paramètres de sortie et ne renvoie aucune valeur de retour (void) [SWS_Com_91003]. Le service est déclaré avec le Service ID 0x05 dans le fichier d'en-tête Com.h [SWS_Com_91003].

Concurrence et restrictions

Concernant le comportement en matière de concurrence, le service est réentrant pour des groupes d'I-PDU différents, mais ne doit pas faire l'objet d'appels concurrents (non-reentrant) pour le même groupe d'I-PDU [SWS_Com_91003].

La fonction Com_SendSignal sert à la mise à jour d'un objet signal identifié par SignalId avec les données vers lesquelles pointe le pointeur SignalDataPtr [SWS_Com_00197]. L'appel est traité de manière asynchrone [SWS_Com_00197].

Valeurs de retour et gestion des erreurs

La fonction renvoie un statut de type uint8 [SWS_Com_00197] :

• E_OK : le service a été accepté [SWS_Com_00197].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou l'appel a échoué en raison d'une erreur de développement [SWS_Com_00197].
• COM_BUSY : survient lorsque le tampon TP est verrouillé pour le traitement de grands types de données [SWS_Com_00197].

Concurrence et restrictions

Concernant la réentrance, Com_SendSignal n'est pas réentrante pour le même signal, mais peut être appelée de manière concurrente pour des signaux différents [SWS_Com_00197]. L'interface est mise à disposition via l'en-tête Com.h [SWS_Com_00197].

Interaction et configuration

Si la configuration ComSignalGroupArrayAccess est définie pour un groupe de signaux, l'appel de Com_SendSignal n'est pas pris en charge pour les signaux de groupe de ce groupe de signaux [SWS_Com_00843].

La fonction Classic AUTOSAR Com_SendDynSignal sert à mettre à jour un objet signal de longueur dynamique à l'aide des données utiles transmises ([SWS_Com_00627]). Le service possède l'ID de service 0x21 et fonctionne de manière asynchrone ([SWS_Com_00627]). En tant que paramètres d'entrée, l'interface attend l'identifiant du signal cible (SignalId), un pointeur vers les données utiles de signal à transmettre (SignalDataPtr) ainsi que la longueur actuelle du signal dynamique (Length) ; aucun paramètre de sortie n'est présent ([SWS_Com_00627]).

La valeur de retour de type uint8 indique le résultat de l'acceptation de la requête ([SWS_Com_00627]) :

• E_OK : l'appel de service a été accepté avec succès ([SWS_Com_00627]).
• E_NOT_OK : le paramètre Length dépasse la longueur maximale ComSignalLength configurée pour ce signal ([SWS_Com_00627]).
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé est arrêté ou le service a échoué en raison d'une erreur de développement ([SWS_Com_00627]).
• COM_BUSY : le tampon TP est verrouillé ([SWS_Com_00627]).

Concernant la concurrence, Com_SendDynSignal est réentrante pour différents signaux, mais non réentrante pour le même signal ([SWS_Com_00627]). La déclaration de la fonction est disponible via l'en-tête Com.h ([SWS_Com_00627]).

La fonction synchrone Com_ReceiveSignal copie les données du signal spécifié via SignalId à l’adresse mémoire fournie via le pointeur SignalDataPtr ([SWS_Com_00198]).

Utilisation et sémantique

L’appel traite le transfert de signal de manière synchrone et reçoit comme paramètre d’entrée l’identifiant SignalId (du type Com_SignalIdType) ainsi que comme paramètre de sortie le pointeur SignalDataPtr (void*) vers le tampon de destination ([SWS_Com_00198]). L’interface est disponible via l’en-tête Com.h ([SWS_Com_00198]).

Valeurs de retour et gestion des erreurs

La valeur de retour de type uint8 signale le résultat de l’exécution de la fonction ([SWS_Com_00198]) :

• E_OK : le service a été accepté et exécuté avec succès ([SWS_Com_00198]).
• COM_SERVICE_NOT_AVAILABLE : le groupe d’I-PDU associé a été arrêté ou le service a échoué à la suite d’une erreur de développement ([SWS_Com_00198]).
• COM_BUSY : se produit si le tampon TP est verrouillé pour le traitement de types de données volumineux ([SWS_Com_00198]).

Concurrence et restrictions

Concernant la réentrance, Com_ReceiveSignal est non réentrant pour un même signal, mais réentrant pour des signaux différents ([SWS_Com_00198]). Lors d’accès parallèles à des identifiants de signaux identiques, les appelants doivent par conséquent assurer une synchronisation appropriée.

De plus, il existe une restriction de configuration importante : si l'accès basé sur un tableau ComSignalGroupArrayAccess est configuré pour un groupe de signaux, l'appel de Com_ReceiveSignal n'est pas pris en charge pour les signaux de groupe inclus de ce groupe de signaux ([SWS_Com_00843]).

Utilisation et sémantique

La fonction synchrone Com_ReceiveDynSignal sert à recevoir un signal de longueur dynamique sur la base de son SignalId [SWS_Com_00690]. Les données de signal reçues sont copiées à l'emplacement mémoire pointé par SignalDataPtr [SWS_Com_00690]. Via le paramètre d'entrée-sortie Length, l'appelant transmet comme valeur d'entrée la longueur maximale admissible ; après une copie réussie, la longueur effective du signal dynamique reçu y est enregistrée [SWS_Com_00690].

Valeurs de retour et gestion des erreurs

La fonction renvoie une valeur d'état de type uint8 [SWS_Com_00690] :

• E_OK : l'appel de service a été accepté et les données ont été copiées avec succès [SWS_Com_00690].
• E_NOT_OK : le tampon fourni est trop petit, car la valeur d'entrée de Length est inférieure à la longueur effective du signal reçu [SWS_Com_00690].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou le service a échoué suite à une erreur de développement [SWS_Com_00690].
• COM_BUSY : le tampon TP est actuellement verrouillé [SWS_Com_00690].

Concurrence et intégration

Concernant la réentrance, Com_ReceiveDynSignal n'est pas réentrante pour le même signal, mais peut être appelée de manière réentrante pour différents signaux [SWS_Com_00690]. La déclaration est disponible via Com.h [SWS_Com_00690].

La fonction asynchrone Com_SendSignalGroup sert à copier le contenu du shadow-buffer associé dans la I-PDU correspondante [SWS_Com_00200]. Elle reçoit en paramètre d'entrée l'identifiant SignalGroupId du groupe de signaux à transmettre [SWS_Com_00200].

Valeurs de retour et gestion des erreurs

La valeur de retour signale l'état d'exécution du service [SWS_Com_00200] :

• E_OK : l'appel de service a été accepté avec succès [SWS_Com_00200].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou le service a échoué suite à une erreur de développement [SWS_Com_00200].
• COM_BUSY : le tampon TP est temporairement verrouillé pour la transmission de types de données volumineux [SWS_Com_00200].

Concurrence et restrictions

En ce qui concerne la concurrence, l'appel est non réentrant pour le même signal de groupe, mais réentrant pour différents signaux de groupe [SWS_Com_00200]. Interprétation : la restriction devrait s'appliquer aux accès simultanés au même groupe de signaux. Question Q-2f3a6da092b51794 (ouverte) De plus, l'appel de Com_SendSignalGroup n'est pas pris en charge pour un groupe de signaux si ComSignalGroupArrayAccess a été configuré pour celui-ci [SWS_Com_00843].

Interaction

Le module AUTOSAR COM traite un appel de Com_SendSignalGroupArray de manière équivalente à Com_SendSignalGroup en ce qui concerne les propriétés de transmission, la sélection du mode de transmission d'I-PDU ainsi que le flux de signaux [SWS_Com_00847].

Utilisation

La fonction synchrone Com_ReceiveSignalGroup sert à la réception de groupes de signaux. Elle copie les données du groupe de signaux reçu depuis l'I-PDU correspondante dans le tampon fantôme (Shadow Buffer) associé [SWS_Com_00201]. En tant que paramètre d'entrée, la fonction attend l'identifiant du groupe de signaux SignalGroupId de type Com_SignalGroupIdType [SWS_Com_00201]. Le service est déclaré dans le fichier d'en-tête Com.h [SWS_Com_00201].

Gestion des erreurs et valeurs de retour

Le service renvoie une valeur d'état de type uint8 qui renseigne sur le succès ou sur la cause de l'erreur [SWS_Com_00201] :

• E_OK : le service a été accepté avec succès et le groupe de signaux a été copié [SWS_Com_00201].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou l'appel a échoué en raison d'une erreur de développement [SWS_Com_00201].
• COM_BUSY : le service signale cet état si le tampon TP pour la gestion des grands types de données est verrouillé [SWS_Com_00201].

Concurrence et restrictions

Concernant le comportement de concurrence, Com_ReceiveSignalGroup est exécuté de manière non réentrante pour le même groupe de signaux, mais réentrante pour des groupes de signaux différents [SWS_Com_00201].

De plus, il existe une restriction importante lors de l'interaction avec l'accès par tableau : si la configuration ComSignalGroupArrayAccess (ECUC_Com_10003) a été définie pour un groupe de signaux, l'appel de Com_ReceiveSignalGroup pour ce groupe de signaux n'est pas pris en charge conformément à la spécification [SWS_Com_00843].

La fonction asynchrone Com_SendSignalGroupArray copie directement les données d'un groupe de signaux dans l'I-PDU associée [SWS_Com_00851] via le pointeur SignalGroupArrayPtr. Les données transmises doivent alors correspondre exactement à la représentation sous forme de tableau du groupe de signaux respectif [SWS_Com_00851], [SWS_Com_00852].

L'identifiant du groupe de signaux (SignalGroupId) ainsi que la référence au tableau de groupes de signaux (SignalGroupArrayPtr) sont transmis en tant que paramètres d'entrée [SWS_Com_00851]. Le service fournit les valeurs de retour suivantes [SWS_Com_00851] :

• E_OK : l'appel de service a été accepté avec succès.
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou l'appel a échoué en raison d'une erreur de développement.
• COM_BUSY : le tampon du protocole de transport (tampon TP) est verrouillé pour le traitement de grands types de données.

En ce qui concerne la concurrence, la fonction n'est pas réentrante pour le même groupe de signaux, mais peut être appelée de manière réentrante pour des groupes de signaux différents [SWS_Com_00851]. L'appel n'est disponible que si le commutateur de configuration ComEnableSignalGroupArrayApi est activé [SWS_Com_00853].

Concernant les caractéristiques de transmission des groupes de signaux, la sélection du mode de transmission de l'I-PDU et le flux de signaux, Com_SendSignalGroupArray est traité par le module AUTOSAR COM de manière totalement analogue à Com_SendSignalGroup [SWS_Com_00847].

Utilisation et configuration

La fonction synchrone Com_ReceiveSignalGroupArray copie le groupe de signaux reçu sous forme de représentation en tableau d'octets depuis l'I-PDU vers la zone mémoire pointée par SignalGroupArrayPtr [SWS_Com_00854], [SWS_Com_00855]. La fonction est exclusivement disponible lorsque le commutateur de configuration ComEnableSignalGroupArrayApi est activé [SWS_Com_00856]. Elle prend en charge le filtrage en réception et la Transmission Mode Selection avec les filtres ALWAYS, NEVER, MASKED_NEW_EQUALS_X, MASKED_NEW_DIFFERS_X, MASKED_NEW_DIFFERS_MASKED_OLD et ONE_EVERY_N [SWS_Com_00848].

Copie de données et gestion des erreurs

Lors de l'appel, l'SignalGroupId ainsi qu'un pointeur vers le tableau de destination sont transmis, à la position desquels le module AUTOSAR COM copie les données de l'I-PDU [SWS_Com_00849]. Même si le groupe d'I-PDU est arrêté et que le service renvoie COM_SERVICE_NOT_AVAILABLE, le module copie systématiquement les dernières données connues ou les valeurs initiales ComSignalInitValues si aucune donnée n'a été écrite auparavant [SWS_Com_00857].

Valeurs de retour et concurrence

Les valeurs de retour possibles du service sont [SWS_Com_00854] :

• E_OK : le service a été accepté avec succès.
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé est arrêté ou le service a échoué en raison d'une erreur de développement.
• COM_BUSY : le tampon TP est verrouillé pour le traitement des grands types de données.

Concernant la concurrence, la fonction est réentrante pour des groupes de signaux différents, mais non réentrante pour le même groupe de signaux [SWS_Com_00854].

La fonction synchrone Com_ReceiveSignalWithMetaData sert à lire les données de signal reçues ainsi que leurs métadonnées à partir du module de communication Com [SWS_Com_91005]. Lors de l'appel, le service copie les données du signal adressé via l'SignalId vers l'emplacement mémoire référencé par SignalDataPtr, et dépose les métadonnées reçues à la position MetaDataPtr [SWS_Com_91005].

Paramètres et contexte d'appel

L'interface est disponible via l'en-tête Com.h et est identifiée par le service ID 0x49 [SWS_Com_91005]. La structure des paramètres se décompose comme suit :

• SignalId (in) : identifiant du signal à recevoir [SWS_Com_91005].
• SignalDataPtr (out) : pointeur vers l'emplacement mémoire destiné au stockage des données de signal reçues [SWS_Com_91005].
• MetaDataPtr (out) : pointeur vers la zone mémoire destinée à recevoir les métadonnées du signal [SWS_Com_91005].

La fonction renvoie une valeur de retour de type uint8, pour laquelle aucune valeur d'erreur spécifique n'est documentée dans la présente section de la norme [SWS_Com_91005].

Concurrence et restrictions

Concernant la réentrance, le service est réentrant pour des signaux différents, mais non réentrant pour le même signal [SWS_Com_91005]. En cas d'appels parallèles ou interruptifs avec une SignalId identique, une protection externe par l'appelant devrait par conséquent être requise pour garantir la cohérence des données. Question Q-51cbdce3d4f59f24 (ouverte)

Utilisation et sémantique

La fonction Com_ReceiveDynSignalWithMetaData est fournie via le fichier d'en-tête Com.h et sert à la réception synchrone de signaux de longueur dynamique, y compris leurs métadonnées [SWS_Com_91006]. Lors de l'appel, le service copie les données du signal identifié par SignalId dans le tampon référencé par SignalDataPtr [SWS_Com_91006]. Les métadonnées reçues sont déposées au niveau du pointeur MetaDataPtr, tandis que la longueur effective du signal dynamique reçu est écrite à la position de Length [SWS_Com_91006].

Valeurs de retour et gestion des erreurs

Le service renvoie une valeur d'état de type uint8 [SWS_Com_91006] :

• E_OK : le service de réception a été accepté avec succès [SWS_Com_91006].
• E_NOT_OK : survient lorsque la valeur transmise de Length est inférieure à la longueur effective du signal dynamique reçu [SWS_Com_91006]. Interprétation : l'appelant doit fournir au préalable la taille du tampon via Length, de sorte que le paramètre fait de facto office d'entrée-sortie combinée. Question Q-8ad420c74748f219 (ouverte)
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé est arrêté ou l'appel a échoué en raison d'une erreur de développement [SWS_Com_91006].
• COM_BUSY : le tampon TP est actuellement verrouillé [SWS_Com_91006].

Concurrence et restrictions

En ce qui concerne la concurrence, la fonction est réentrante pour différents signaux, mais ne doit pas être appelée de manière réentrante pour le même signal [SWS_Com_91006]. Les appels parallèles pour un même SignalId doivent donc être synchronisés au niveau de l'appelant.

La fonction synchrone Com_ReceiveSignalGroupWithMetaData sert à recevoir un groupe de signaux, y compris les métadonnées associées, via l'interface Com.h [SWS_Com_91007]. Elle prend comme paramètre d'entrée l'identifiant SignalGroupId et copie les données reçues du groupe de signaux depuis l'I-PDU vers le shadow buffer local [SWS_Com_91007]. En même temps, le service enregistre les métadonnées reçues à l'adresse cible référencée via le paramètre de sortie MetaDataPtr [SWS_Com_91007].

Le comportement d'erreur et de retour comprend trois valeurs d'état : E_OK signale l'acceptation réussie du service [SWS_Com_91007]. La valeur de retour COM_SERVICE_NOT_AVAILABLE indique que le groupe d'I-PDU associé est arrêté ou qu'une erreur de développement est présente [SWS_Com_91007]. Si le code d'erreur COM_BUSY survient, le tampon TP est verrouillé pour le traitement de grands types de données [SWS_Com_91007]. Concernant la concurrence, la fonction est réentrante pour différents groupes de signaux, mais non réentrante pour le même groupe de signaux [SWS_Com_91007]. Comme la spécification ne mentionne aucune restriction relative aux ISR, l'appel devrait s'effectuer de manière synchrone au niveau tâche par le composant logiciel supérieur. Question Q-a23cf67bae724ae1 (ouverte)

Dans le cadre de l'interaction globale, la fonction étend le chemin de réception avec des métadonnées de manière analogue à Com_ReceiveSignalWithMetaData pour les signaux individuels [SWS_Com_91005]. Les métadonnées fournies correspondent aux informations de PDU précédemment reçues à l'interface via Com_RxIndication [SWS_Com_00123]. Pour signaler des contenus de données invalides, Com_InvalidateSignalGroup peut en outre être utilisé dans le déroulement global [SWS_Com_00557].

Utilisation

Le service synchrone Com_ReceiveSignalGroupArrayWithMetaData (ID de service 0x4c, disponible via Com.h) copie la représentation sous forme de tableau du groupe de signaux reçu depuis l'I-PDU vers l'emplacement mémoire fourni via le pointeur SignalGroupArrayPtr [SWS_Com_91008]. Simultanément, les métadonnées reçues sont écrites à la position indiquée par le paramètre MetaDataPtr [SWS_Com_91008]. La fonction ne possède pas de valeur de retour (void) [SWS_Com_91008].

Gestion des erreurs

La spécification ne définit aucune valeur de retour pour ce service et ne liste aucun code d'erreur spécifique [SWS_Com_91008]. Interprétation : d'éventuels états d'erreur lors des paramètres d'appel devraient probablement être interceptés en interne et traités via le rapport d'erreurs du module ; toutefois, aucune notification DET ou DEM concrète ne ressort de l'extrait de spécification. Question (ouverte)

Concurrence et restrictions

En ce qui concerne la concurrence, la fonction est réentrante pour différents groupes de signaux, mais non réentrante pour le même groupe de signaux [SWS_Com_91008]. Les appels parallèles avec un SignalGroupId identique doivent être évités du côté de l'appelant. Interprétation : les appelants devraient en outre être tenus de fournir des tampons cibles suffisamment dimensionnés, car l'interface n'achemine aucun paramètre de longueur. Question (ouverte)

Interaction

La mise à disposition des données dans le tampon de PDU suppose qu'une indication de réception ait eu lieu auparavant via Com_RxIndication, laquelle fournit également les métadonnées au module COM [SWS_Com_00123]. La fonction étend les interfaces de réception pour les métadonnées de manière analogue à Com_ReceiveSignalWithMetaData pour les signaux individuels [SWS_Com_91005] et se distingue de la récupération standard de signal via Com_ReceiveSignal [SWS_Com_00198].

La fonction Com_SendSignalWithMetaData ([SWS_Com_91009]) sert à mettre à jour de manière asynchrone un objet signal spécifié par SignalId avec des données utiles via SignalDataPtr ainsi que des métadonnées associées via MetaDataPtr. Le service est disponible via l'en-tête Com.h.

• Appel et concurrence : l'appel s'effectue de manière asynchrone ([SWS_Com_91009]). La fonction est réentrante pour différents signaux, mais non réentrante pour le même identifiant de signal (SignalId) ([SWS_Com_91009]).
• Valeurs de retour et traitement des erreurs : la fonction renvoie une valeur d'état de type uint8 ([SWS_Com_91009]) :
  • E_OK : la requête d'émission a été acceptée avec succès par le module ([SWS_Com_91009]).
  • COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé est arrêté ou l'appel a échoué en raison d'une erreur de développement ([SWS_Com_91009]).
  • COM_BUSY : le tampon TP est verrouillé pour le traitement des types de données volumineux ([SWS_Com_91009]).
• Interaction : à la différence du service d'émission de base Com_SendSignal ([SWS_Com_00197]), cette fonction transmet des métadonnées explicites. Elle constitue le pendant côté émission du service de réception Com_ReceiveSignalWithMetaData ([SWS_Com_91005]) et complète les services de métadonnées relatifs aux I-PDU tels que Com_TriggerIPDUSendWithMetaData ([SWS_Com_00858]).

Utilisation et sémantique

La fonction Com_SendDynSignalWithMetaData sert à mettre à jour de manière asynchrone un objet signal identifié via SignalId (type Com_SignalIdType) avec des données de signal de longueur dynamique ainsi que les métadonnées associées [SWS_Com_91010]. Les données utiles à transmettre sont référencées via le pointeur SignalDataPtr (type void*), tandis que MetaDataPtr (type uint8*) pointe vers les métadonnées [SWS_Com_91010]. La longueur effective du signal dynamique à envoyer est transmise via le paramètre Length (type uint16) [SWS_Com_91010].

Valeurs de retour et gestion des erreurs

La valeur de retour de type uint8 signale si le service a été accepté ou quelle erreur est présente [SWS_Com_91010] :

• E_OK : l'appel de service a été accepté avec succès pour traitement [SWS_Com_91010].
• E_NOT_OK : la Length transmise dépasse la ComSignalLength configurée pour ce signal [SWS_Com_91010].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou l'appel a échoué en raison d'une erreur de développement [SWS_Com_91010].
• COM_BUSY : le tampon TP est actuellement verrouillé, raison pour laquelle le signal ne peut pas être envoyé [SWS_Com_91010].

Concurrence et intégration

En ce qui concerne la concurrence, la fonction est réentrante pour différents signaux, mais non réentrante pour le même signal [SWS_Com_91010]. L'interface possède l'ID de service 0x4e et est mise à disposition dans le module Com via le fichier d'en-tête Com.h [SWS_Com_91010].

La fonction Com_SendSignalGroupWithMetaData (désignée dans le modèle de données par Data) sert à transmettre de manière asynchrone un groupe de signaux avec des métadonnées au module Com [SWS_Com_91011]. Lors de l'appel, le service copie le contenu actuel du shadow buffer associé dans l'I-PDU correspondante, les métadonnées étant fournies via le pointeur MetaDataPtr [SWS_Com_91011].

Les paramètres d'entrée comprennent l'identifiant du groupe de signaux (SignalGroupId) ainsi que le pointeur vers les métadonnées (MetaDataPtr) [SWS_Com_91011]. Les valeurs de retour signalent le résultat de la demande de service :

• E_OK : le service a été accepté avec succès [SWS_Com_91011].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé a été arrêté ou l'exécution a échoué en raison d'une erreur de développement [SWS_Com_91011].
• COM_BUSY : le tampon TP est verrouillé pour la transmission de grands types de données [SWS_Com_91011].

Concernant la concurrence, l'appel est réentrant pour différents signaux, mais non réentrant pour le même signal de groupe ; cela devrait se rapporter au groupe de signaux respectif, de manière analogue au paramètre SignalGroupId [SWS_Com_91011]. Question Q-91171d77370ae50a (ouverte) En interaction avec le module Com, le service complète l'émission de signaux individuels tels que Com_SendSignal [SWS_Com_00197] ainsi que l'invalidation de groupes de signaux via Com_InvalidateSignalGroup [SWS_Com_00557]. De plus, il correspond au service de réception Com_ReceiveSignalWithMetaData [SWS_Com_91005] et à l'appel d'émission basé sur PDU Com_TriggerIPDUSendWithMetaData [SWS_Com_00858].

Utilisation et paramètres

La fonction Com_SendSignalGroupArrayWithMetaData sert à transmettre de manière asynchrone un groupe de signaux avec ses métadonnées associées [SWS_Com_91012]. Lors de l'appel, le service copie le contenu du pointeur transmis SignalGroupArrayPtr directement dans l'I-PDU assignée [SWS_Com_91012]. Les données fournies doivent obligatoirement correspondre à la représentation sous forme de tableau du groupe de signaux, qui est identifié via le paramètre SignalGroupId de type Com_SignalGroupIdType [SWS_Com_91012]. Des métadonnées supplémentaires du groupe de signaux sont transmises à la couche de communication via le pointeur MetaDataPtr [SWS_Com_91012].

Valeurs de retour et gestion des erreurs

La fonction renvoie une valeur d'état de type uint8 qui indique le succès de la transmission ou la cause respective de l'erreur [SWS_Com_91012] :

• E_OK : l'appel de service a été accepté avec succès par la couche COM [SWS_Com_91012].
• COM_SERVICE_NOT_AVAILABLE : le groupe d'I-PDU associé est arrêté ou l'appel a échoué en raison d'une erreur de développement [SWS_Com_91012].
• COM_BUSY : le tampon du protocole de transport (TP-Buffer) est verrouillé pour le traitement de grands types de données [SWS_Com_91012].

Concurrence et restrictions

Conformément à la spécification, le service est classé comme non réentrant (Non Reentrant), raison pour laquelle les appels simultanés ou interruptifs ne sont pas autorisés [SWS_Com_91012]. L'interface possède l'ID de service 0x50 et est fournie via le fichier d'en-tête Com.h [SWS_Com_91012].

La fonction Com_InvalidateSignal sert à invalider un signal dans le module de communication [SWS_Com_00203]. Elle définit la valeur du signal transmis sur la valeur d’invalidation enregistrée dans la configuration Com Signal Data Invalid Value [SWS_Com_00203]. Le traitement s’effectue de manière asynchrone [SWS_Com_00203]. En tant qu’unique paramètre de transmission, le paramètre d’entrée SignalId est transmis pour l’identification du signal ; il n’existe pas de paramètre d’entrée/sortie ou de sortie [SWS_Com_00203].

En valeur de retour, l’appel renvoie un état de type uint8 qui représente le comportement d’acceptation et d’erreur [SWS_Com_00203] :

• E_OK : le service d’invalidation a été accepté avec succès [SWS_Com_00203].
• COM_SERVICE_NOT_AVAILABLE : le service n’est pas disponible. Cela se produit si le groupe d’I-PDU associé est arrêté, si aucun Com Signal Data Invalid Value n’a été configuré pour le SignalId indiqué ou si l’exécution échoue en raison d’une erreur de développement [SWS_Com_00203].
• COM_BUSY : le service ne peut pas être exécuté actuellement, car le tampon TP est verrouillé [SWS_Com_00203].

Concernant la concurrence, Com_InvalidateSignal n’est pas réentrant pour le même signal, mais peut être exécuté de manière parallèle et réentrante pour différents signaux [SWS_Com_00203]. Le service est déclaré sous le Service-ID 0x10 et disponible via l’en-tête Com.h [SWS_Com_00203].

La fonction Com_InvalidateSignalGroup sert à positionner tous les signaux de groupe du groupe de signaux transmis sur leurs valeurs ComSignalDataInvalidValue respectivement configurées et à invalider ainsi le groupe de signaux [SWS_Com_00557].

Utilisation et sémantique

En paramètre d'entrée, le service attend l'ID du groupe de signaux à invalider (SignalGroupId de type Com_SignalGroupIdType) [SWS_Com_00557]. L'appel est traité de manière asynchrone et renvoie une valeur d'état de type uint8 [SWS_Com_00557].

Valeurs de retour et gestion des erreurs

Les valeurs de retour suivantes sont spécifiées [SWS_Com_00557] :

• E_OK : la demande d'invalidation a été acceptée avec succès.
• COM_SERVICE_NOT_AVAILABLE : le service n'est pas disponible parce que le groupe d'I-PDU associé est arrêté, qu'aucun ComSignalDataInvalidValue n'a été configuré pour aucun des signaux de groupe ou que l'appel échoue en raison d'une erreur de développement.
• COM_BUSY : le tampon du protocole de transport (TP buffer) est actuellement verrouillé.

Concurrence et réentrance

La fonction est non réentrante pour le même groupe de signaux, mais peut être appelée de manière concurrente (réentrante) pour différents groupes de signaux [SWS_Com_00557]. La déclaration est disponible via Com.h [SWS_Com_00557].

La fonction synchrone Com_TriggerIPDUSend déclenche la transmission de l'I-PDU identifiée par le paramètre PduId [SWS_Com_00348]. Elle est disponible via l'en-tête Com.h [SWS_Com_00348].

Conditions d'appel et valeurs de retour

L'appel ne déclenche l'envoi que si l'I-PDU concernée est démarrée [SWS_Com_00861]. En conséquence, la valeur de retour de type Std_ReturnType différencie l'état de l'I-PDU [SWS_Com_00348] :

• E_OK : l'I-PDU a été déclenchée avec succès pour la transmission [SWS_Com_00348].
• E_NOT_OK : l'I-PDU se trouve à l'état arrêté, de sorte que la transmission n'a pas pu être déclenchée [SWS_Com_00348].

Comportement de tampon et de concurrence

La fonction est spécifiée comme non réentrante (Non Reentrant) [SWS_Com_00348]. Un mécanisme de mise en tampon est prévu pour les grandes I-PDU : si une grande I-PDU est déclenchée via Com_TriggerIPDUSend alors que son tampon est verrouillé, AUTOSAR COM mémorise temporairement la demande d'envoi et ne transmet l'I-PDU que dès que le tampon redevient disponible [SWS_Com_00867].

La fonction Com_TriggerIPDUSendWithMetaData sert à déclencher de manière synchrone la transmission d'une I-PDU et à mettre préalablement à jour ses métadonnées internes dans le module AUTOSAR COM [SWS_Com_00858]. L'appel attend comme paramètre PduId l'identifiant de l'I-PDU à envoyer ainsi qu'avec MetaData un pointeur vers les métadonnées à fournir [SWS_Com_00858]. Le module COM copie les données à partir de l'adresse référencée dans sa gestion interne de données en tenant compte de la longueur configurée globalement du type de métadonnées de l'I-PDU, puis déclenche la transmission immédiatement après [SWS_Com_00858].

Conformément à [SWS_Com_00862], le module COM ne doit toutefois déclencher la transmission de l'I-PDU que si l'I-PDU se trouve à l'état démarré. Si l'I-PDU est en revanche arrêtée, le déclenchement de la transmission n'a pas lieu.

Le résultat de l'exécution est signalé via la valeur de retour :

• E_OK : la transmission de l'I-PDU a été déclenchée avec succès [SWS_Com_00858].
• E_NOT_OK : l'I-PDU est arrêtée ; la transmission n'a pas pu être déclenchée [SWS_Com_00858].

Des codes d'erreur spécifiques pour DET ou DEM ne sont pas documentés pour ce service dans le payload.

En ce qui concerne la concurrence, l'interface est définie comme non réentrante (Non Reentrant) [SWS_Com_00858], raison pour laquelle les appels parallèles doivent être exclus ou synchronisés. Il est vraisemblablement de la responsabilité de l'appelant de veiller à la validité du pointeur MetaData et à une taille de tampon suffisante conformément à la longueur de métadonnées configurée. Question Q-66c6abae0bbde275 (ouverte)

L'interface synchrone Com_SwitchIpduTxMode sert à commuter le mode de transmission d'une I-PDU et est spécifiée dans l'en-tête Com.h sous le Service-ID 0x27 [SWS_Com_00784]. Sont transmis comme paramètres l'identifiant de l'I-PDU concernée (PduId) ainsi que le mode de transmission souhaité sous forme de valeur booléenne (Mode) ; il n'y a pas de valeur de retour ni de paramètre de sortie [SWS_Com_00784]. L'appel commute les propriétés de transmission de manière synchrone et directe pendant l'exécution [SWS_Com_00784].

Pour l'effectivité du changement de mode, la spécification définit deux cas :

• Si le mode de transmission change par l'appel, le nouveau mode de fonctionnement prend effet immédiatement pour l'I-PDU référencée [SWS_Com_00784], [SWS_Com_00239].
• Si le mode de transmission demandé était déjà actif pour l'I-PDU concernée, l'appel reste alors totalement sans effet [SWS_Com_00784].

Concernant la suite du déroulement de l'émission, la règle suivante s'applique à l'interaction avec l'envoi cyclique : si le mode de transmission d'une I-PDU est défini explicitement via Com_SwitchIpduTxMode, le module AUTOSAR COM retarde les émissions cycliques suivantes de cette I-PDU du décalage temporel ComTxModeTimeOffset [SWS_Com_00881].

Concernant la concurrence, la fonction est conçue pour être réentrante pour différentes instances d'I-PDU [SWS_Com_00784]. En revanche, un appel concurrent ou parallèle pour la même PduId est défini comme non réentrant et doit être empêché par l'appelant [SWS_Com_00784].

La fonction synchrone [SWS_Com_00001] sert à la récupération et à la copie synchrones des données de SDU d’une PDU d’émission à transmettre (TxPduId) dans le tampon mis à disposition par l’appelant. Via le paramètre d’entrée et de sortie PduInfoPtr, l’appelant transmet aussi bien l’adresse de destination SduDataPtr que la capacité maximale disponible du tampon dans SduLength. Si les données de SDU tiennent entièrement dans le tampon, elles sont copiées, PduInfoPtr->SduLength est mis à jour avec le nombre d’octets effectivement copiés et le service se termine avec succès par E_OK [SWS_Com_00001].

Gestion des erreurs et conditions limites

La fonction interrompt l’exécution, ne copie aucune donnée et renvoie E_NOT_OK si l’une des conditions suivantes est remplie :

• La taille de tampon fournie dans PduInfoPtr->SduLength est inférieure à la longueur réelle de la PDU [SWS_Com_00001], [SWS_Com_00869]. Dans ce cas, PduInfoPtr reste inchangé [SWS_Com_00001].
• L’I-PDU correspondante se trouve à l’état arrêté [SWS_Com_00884].

En cas d’erreur (E_NOT_OK), l’appelant ne doit pas évaluer ni réutiliser le pointeur PduInfoPtr, car celui-ci peut pointer vers des données non valides ou représenter un pointeur NULL [SWS_Com_00001].

concurrence

Concernant la concurrence, l’interface est conçue pour être réentrante pour différents identifiants de PDU, mais ne doit pas être appelée de manière concurrente pour un même TxPduId [SWS_Com_00001].

La fonction Com_RxIndication sert à la signalisation et au transfert d'une PDU reçue d'un module d'interface de communication sous-jacent vers le module AUTOSAR COM [SWS_Com_00123]. La déclaration de la fonction est fournie via le fichier d'en-tête Com.h et possède le service ID 0x42 [SWS_Com_00123].

L'appel s'effectue avec une sémantique synchrone et ne renvoie aucune valeur de retour (void) [SWS_Com_00123]. L'interface ne définit ni paramètres d'entrée/sortie ni paramètres purement de sortie, mais exclusivement deux paramètres d'entrée [SWS_Com_00123] :

• RxPduId (type de données PduIdType) : représente l'identifiant unique de la PDU reçue [SWS_Com_00123].
• PduInfoPtr (pointeur vers un PduInfoType constant) : renvoie à la structure de données qui contient la longueur de la PDU reçue (SduLength), un pointeur vers le tampon contenant les données de la PDU (SduDataPtr) ainsi que les métadonnées associées [SWS_Com_00123].

En ce qui concerne le comportement face à la concurrence, Com_RxIndication est définie comme réentrante pour des appels avec des PDU-ID différents, mais expressément comme non réentrante pour la même PDU-ID [SWS_Com_00123]. Interprétation : les modules appelants de l'interface de communication sous-jacente devraient donc être tenus de synchroniser ou de sérialiser les appels concurrents pour des PDU-ID identiques, afin de préserver la cohérence des données. Question Q-f3b6194f96c15091 (ouverte)

La fonction de service synchrone Com_TpRxIndication est appelée dès qu'une I-PDU a été reçue via l'API TP [SWS_Com_00650]. Elle informe le module AUTOSAR COM de l'achèvement et du résultat de l'opération de réception. Le paramètre id identifie l'I-PDU concernée, tandis que le paramètre result indique si la transmission a réussi ou a échoué [SWS_Com_00650]. La fonction ne possède aucune valeur de retour et est définie dans l'en-tête Com.h avec le Service-ID 0x45 [SWS_Com_00650]. Une couche de transport sous-jacente comme le module PduR ou un module TP devrait vraisemblablement faire office d'appelant. Question Q-d7006169cd162db4 (ouverte)

Gestion des erreurs

Si Com_TpRxIndication est appelée avec la valeur de résultat E_NOT_OK pour le paramètre result, le module COM traite tous les signaux de la grande I-PDU reçue exactement comme des signaux devenus invalides [SWS_Com_00838]. Dans ce cas d'erreur, le module exécute tous les ComDataInvalidActions configurés pour l'ensemble des signaux et groupes de signaux contenus [SWS_Com_00838].

Concurrence et contraintes

La fonction est spécifiée comme réentrante et fonctionne de manière synchrone [SWS_Com_00650]. Elle peut donc être appelée en parallèle pour différentes I-PDU, mais devrait toutefois être traitée sans délai dans le contexte de l'instance appelante.

La fonction de rappel synchrone Com_TxConfirmation est déclarée via l’en-tête Com.h et sert d’interface centrale de confirmation du module AUTOSAR COM [SWS_Com_00124]. Un module d’interface de communication sous-jacent notifie ainsi au module Com la transmission réussie d’une PDU ou l’échec du processus d’émission [SWS_Com_00124].

Contexte d'appel et paramètres

La fonction s’exécute de manière synchrone, possède l’ID de service 0x40 et ne fournit aucune valeur de retour (void) [SWS_Com_00124]. Elle attend deux paramètres d’entrée :

• TxPduId (type PduIdType) : identifiant unique de la PDU dont la transmission est achevée ou a échoué [SWS_Com_00124].
• result (type Std_ReturnType) : état du résultat du processus d’émission [SWS_Com_00124]. La valeur E_OK confirme la transmission effectuée de la PDU, tandis que E_NOT_OK signale un échec de la transmission de la PDU [SWS_Com_00124].

Concurrence et restrictions

Com_TxConfirmation est réentrant pour différents identifiants de PDU, mais non réentrant pour un même identifiant de PDU [SWS_Com_00124]. Interprétation : les appelants de la couche sous-jacente devraient devoir éviter les appels consécutifs ou avec interruption avec le même TxPduId à partir de différents contextes d’exécution afin que l’état de traitement interne du module Com reste cohérent. Question Q-146c1c92403b64fa (ouverte)

Gestion des erreurs

La spécification ne définit aucune valeur de retour spécifique pour ce service et n’indique aucun message d’erreur DET ou DEM particulier [SWS_Com_00124]. Les transmissions erronées sont transmises au module Com exclusivement via le paramètre result avec la valeur d’erreur E_NOT_OK [SWS_Com_00124].

Utilisation et sémantique

La fonction Com_TpTxConfirmation est appelée après qu'une I-PDU a été transmise sur le réseau, afin de notifier au module COM le résultat de l'opération d'émission [SWS_Com_00725]. Le paramètre id de type PduIdType permet d'identifier l'I-PDU transmise, tandis que result de type Std_ReturnType indique si la transmission a réussi ou a échoué [SWS_Com_00725]. La fonction ne possède pas de valeur de retour (void) et présente une sémantique d'exécution synchrone [SWS_Com_00725]. Elle est disponible via le fichier d'en-tête Com.h et possède le Service ID 0x48 [SWS_Com_00725].

Gestion des erreurs

La transmission d'erreurs sur cette interface s'effectue exclusivement par le biais du paramètre result, qui reflète le succès ou l'échec du transfert de l'I-PDU [SWS_Com_00725]. La spécification de la fonction ne mentionne aucun code d'erreur spécifique ni message d'erreur destiné au module Default Error Tracer (DET) ou Diagnostic Event Manager (DEM) [SWS_Com_00725].

Concurrence et contraintes

L'interface est spécifiée comme réentrante et peut donc être exécutée en parallèle [SWS_Com_00725]. En tant que contrainte temporelle, l'appel ne doit avoir lieu qu'après la fin de la transmission de l'I-PDU sur le réseau [SWS_Com_00725]. Interprétation : en raison de la convention de nommage et de la structure modulaire, l'appel devrait typiquement être initié par un module de protocole de transport sous-jacent. Question Q-8320e76ff63f62ce (ouverte)

La fonction synchrone et réentrante Com_StartReception (disponible via Com.h, Service-ID 0x46) est appelée au début de la réception d'une N-SDU, laquelle est transmise non fragmentée sous forme de Single Frame (SF) ou fragmentée via une First Frame (FF) suivie de Consecutive Frames (CF) [SWS_Com_00691].

L'I-PDU est identifiée via le paramètre id et TpSduLength indique la longueur totale de la N-SDU à recevoir [SWS_Com_00691]. Le pointeur info pointe vers les données utiles et la longueur utile de la première trame ou de la trame unique ainsi que vers les métadonnées associées ; si ni données de trame ni métadonnées ne sont disponibles, NULL_PTR est transmis [SWS_Com_00691]. Via le paramètre de sortie bufferSizePtr, la fonction fournit la taille de tampon disponible que le module de protocole de transport utilise pour déterminer la Block Size (BS) [SWS_Com_00691]. Si le service est appelé avec un TpSduLength de 0, il fournit la taille de tampon actuellement maximale disponible [SWS_Com_00691].

Le résultat de la demande est renvoyé sous la forme de BufReq_ReturnType [SWS_Com_00691] :

• BUFREQ_OK : la connexion est acceptée et la réception se poursuit ; bufferSizePtr indique le tampon disponible ou signale 0 si aucun tampon de la taille demandée n'est disponible [SWS_Com_00691].
• BUFREQ_E_NOT_OK : la connexion est rejetée et la réception est interrompue ; la valeur de bufferSizePtr reste inchangée [SWS_Com_00691].
• BUFREQ_E_OVFL : aucun tampon de la longueur requise ne peut être mis à disposition, ce qui entraîne l'interruption de la réception ; bufferSizePtr reste inchangé [SWS_Com_00691].

Utilisation et sémantique d'appel

La fonction synchrone Com_CopyRxData est appelée pour transmettre les données reçues d'un segment d'I-PDU (N-PDU) à la couche supérieure [SWS_Com_00692]. Lors de transmissions segmentées, chaque appel successif de cette interface fournit la partie suivante des données complètes de l'I-PDU [SWS_Com_00692].

Paramètres et gestion de tampon

• id : identifie de manière unique l'I-PDU reçue [SWS_Com_00692].
• info : pointeur vers une structure de type PduInfoType. Elle transmet via SduDataPtr le pointeur vers le tampon source et via SduLength le nombre d'octets à copier [SWS_Com_00692]. Une spécification de 0 pour SduLength sert à interroger la taille de tampon actuellement disponible de la couche supérieure ; dans ce cas de simple interrogation, SduDataPtr peut être défini sur NULL_PTR [SWS_Com_00692].
• bufferSizePtr : pointeur vers une variable de type PduLengthType, dans laquelle est écrite la taille du tampon de réception restante après l'opération de copie [SWS_Com_00692].

Valeurs de retour et propriétés

La fonction renvoie un statut de type BufReq_ReturnType [SWS_Com_00692] :

• BUFREQ_OK : les données ont été copiées avec succès dans le tampon de destination [SWS_Com_00692].
• BUFREQ_E_NOT_OK : la copie des données a échoué car une erreur est survenue [SWS_Com_00692].

L'interface possède le Service-ID 0x44, est spécifiée comme réentrante et est disponible via l'en-tête Com.h [SWS_Com_00692].

La fonction synchrone et réentrante Com_CopyTxData est appelée par des modules sous-jacents (tels que des protocoles de transport) afin de récupérer pas à pas, à partir du tampon d'émission du module COM, des données d'émission pour des segments (N-PDU) d'une I-PDU [SWS_Com_00693].

Utilisation et paramètres

Chaque appel met à disposition la partie suivante des données d'I-PDU [SWS_Com_00693] :

• id : identifie l'I-PDU à transmettre [SWS_Com_00693].
• info : indique via SduDataPtr le tampon de destination et via SduLength le nombre d'octets à copier. Une longueur de 0 est autorisée afin de transmettre des changements d'état via retry ou de consulter la quantité de données disponible ; dans ce cas, SduDataPtr peut être un NULL_PTR [SWS_Com_00693].
• retry : confirme les données envoyées ou provoque des retransmissions. Si retry est un NULL_PTR, les données peuvent être retirées du tampon immédiatement après la copie. Si retry pointe vers une structure RetryInfoType, TpDataState contrôle la rétention en tampon : TP_CONFPENDING conserve les données dans le tampon pour correction d'erreurs, TP_DATACONF confirme les données copiées avant l'appel en vue de leur suppression, et TP_DATARETRY copie à nouveau les données lues précédemment à partir de l'offset TxTpDataCnt [SWS_Com_00693].
• availableDataPtr : renvoie le nombre restant d'octets disponibles dans le tampon d'émission, ce qui permet par exemple aux protocoles de transport dynamiques (comme FrIsoTp) de déterminer la taille des segments suivants [SWS_Com_00693].

Valeurs de retour et gestion des erreurs

Le résultat de la fonction signale le succès de la demande de tampon via BufReq_ReturnType [SWS_Com_00693] :

• BUFREQ_OK : les données ont été entièrement copiées dans le tampon de destination comme demandé [SWS_Com_00693].
• BUFREQ_E_BUSY : la quantité de données demandée n'est pas disponible dans le tampon d'émission. Aucune donnée n'est copiée et le module sous-jacent peut réitérer l'appel ultérieurement [SWS_Com_00693].
• BUFREQ_E_NOT_OK : la demande a échoué ; aucune donnée n'a été copiée [SWS_Com_00693].

Utilisation

La fonction synchrone Com_MainFunctionRx prend en charge le traitement interne de réception du module AUTOSAR COM pour les opérations qui ne sont pas exécutées directement dans le contexte d'exécution des API appelées par le PDU Router (PduR) telles que Com_RxIndication [SWS_Com_00398]. Elle ne possède aucun paramètre d'entrée ni de sortie et ne renvoie aucune valeur de retour [SWS_Com_00398]. La déclaration s'effectue via l'en-tête SchM_Com.h ; le contexte d'appel devrait donc généralement intervenir de manière périodique par le Schedule Manager (SchM) [SWS_Com_00398]. Question Q-48d121e36f62c6de (ouverte)

Gestion des erreurs et initialisation

Si la fonction est exécutée avant l'initialisation du module par Com_Init ou après un appel de Com_DeInit, aucune erreur COM_E_UNINIT (0x02) n'est générée, contrairement à la plupart des API COM régulières, car Com_MainFunctionRx en est explicitement exclu [SWS_Com_00804]. Aucun code d'erreur ou de retour spécifique n'existe pour cette interface [SWS_Com_00398].

Concurrence et fonctionnement multi-instance

Concernant le contexte d'exécution et la réentrance, les exigences suivantes s'appliquent [SWS_Com_00398] :

• Réentrance : la fonction n'est pas réentrante pour la même instance, mais peut être appelée en parallèle pour des instances différentes [SWS_Com_00398].
• Déclinaison spécifique à l'instance : pour chaque conteneur ComMainFunctionRx défini dans la configuration de l'ECU, une fonction autonome sous la forme Com_MainFunctionRx_<shortName> est implémentée, où <shortName> correspond au Short-Name du conteneur de configuration [SWS_Com_00398].

Utilisation et fonctionnement

La fonction Com_MainFunctionTx exécute les activités d'émission du module AUTOSAR COM qui ne sont pas traitées directement au sein des fonctions COM appelées par la RTE (comme par exemple Com_SendSignal) ([SWS_Com_00399]). L'exécution s'effectue de manière synchrone. Elle ne possède aucun paramètre d'entrée, d'entrée/sortie ni de sortie et ne renvoie aucune valeur de retour ([SWS_Com_00399]). L'interface est déclarée via SchM_Com.h ; Interprétation : en raison de cette appartenance d'en-tête, le contexte d'appel devrait se situer dans le Schedule Management (SchM). Question Q-c33cfcf81700bcc5 (ouverte)

Pour chaque conteneur configuré d'une Com Main Function Tx dans la configuration de l'ECU, une fonction d'instance spécifique doit être implémentée selon le schéma de nommage Com_MainFunctionTx_<shortName>, où <shortName> correspond au nom court du conteneur de configuration ([SWS_Com_00399]).

Concurrence et restrictions

Concernant la réentrance, Com_MainFunctionTx est conçu pour être réentrant pour différentes instances, mais ne doit pas être appelé de manière réentrante pour la même instance ([SWS_Com_00399]).

Gestion des erreurs et état d'initialisation

Conformément à [SWS_Com_00804], l'appel de services COM avant l'initialisation via Com_Init ou après la désinitialisation via Com_DeInit conduit régulièrement à l'erreur COM_E_UNINIT (0x02). Com_MainFunctionTx en est toutefois explicitement exclu et ne produit pas d'erreur d'initialisation de ce type dans ces états ([SWS_Com_00804]).

La fonction de rappel Com_CbkTxAck sert, dans le module Com, de notification concernant l’envoi réussi d’un message [SWS_Com_00468]. Elle représente la classe de notification 2 (notification class 2) et est appelée immédiatement après la transmission réussie de l’I-PDU contenant le message concerné [SWS_Com_00468].

Pour le contexte d’appel et les propriétés de l’interface, les directives suivantes s’appliquent selon la spécification [SWS_Com_00468] :

• Signature et paramètres : la fonction de rappel possède la signature void Com_CbkTxAck (void). Elle n’accepte aucun paramètre d’entrée, d’entrée/sortie ni de sortie et ne renvoie aucune valeur de retour [SWS_Com_00468].
• Synchronicité : l’appel est spécifié comme synchrone (Synchronous) [SWS_Com_00468].
• Réentrance : le comportement de réentrance est classé comme don't care [SWS_Com_00468].
• Configuration : l’interface est déclarée comme configurable (configurable) [SWS_Com_00468]. Interprétation : le nom réel de la fonction de rappel devrait être paramétré dans l’outil de configuration de manière spécifique au message ou au signal. Question Q-3670b7b04fd7c74c (ouverte)

Les codes d’erreur spécifiques, les réactions aux erreurs ainsi que les messages à destination de DET ou DEM ne sont pas définis pour cet élément dans la spécification [SWS_Com_00468]. Aucune condition d’ordonnancement supplémentaire par rapport à d’autres appels n’est non plus mentionnée [SWS_Com_00468].

La fonction de rappel Com_CbkTxErr est appelée de manière synchrone lorsqu’une transmission n’est pas possible parce que le groupe d’I-PDU associé est arrêté [SWS_Com_00491]. Elle correspond à la classe de notification 4 selon les spécifications sous-jacentes [SWS_Com_00491].

Appel et sémantique

• Signature et paramètres : la fonction ne possède aucun paramètre d’entrée, d’entrée/sortie ni de sortie (void Com_CbkTxErr (void)) et ne renvoie aucune valeur de retour [SWS_Com_00491].
• Comportement d’exécution : l’appel s’effectue de manière synchrone (« Synchronous »), tandis que « don't care » est spécifié pour la réentrance [SWS_Com_00491].
• Disponibilité : l’interface de rappel est configurable (« configurable ») [SWS_Com_00491].

Traitement des erreurs et interaction

La fonction sert spécifiquement à signaler à la couche appelante ou supérieure le cas d’erreur d’une demande d’émission empêchée en raison d’un groupe d’I-PDU arrêté [SWS_Com_00491]. Aucun paramètre n’étant transmis, le contexte du signal ou de l’I-PDU concerné est vraisemblablement prédéfini via la configuration ou des affectations spécifiques au module. Question Q-d7153324d2eb2995 (ouverte)

Utilisation et contexte d'appel

La fonction de rappel Com_CbkTxTOut sert d’interface de notification en cas d’absence de transmission réussie. Selon [SWS_Com_00554], elle est appelée immédiatement après que le mécanisme de surveillance des échéances (deadline monitoring mechanism) a détecté une erreur de transmission d’un message. L’appel est synchrone et correspond à la classe de notification 4. Étant donné que la signature void Com_CbkTxTOut(void) ne possède ni valeur de transmission ni valeur de retour, la signalisation vers la couche supérieure s’effectue sans paramètre.

Concurrence et configuration

Concernant la réentrance, la fonction est spécifiée selon [SWS_Com_00554] avec don't care. Il incombe dès lors vraisemblablement au logiciel applicatif appelé de prendre les mesures appropriées pour la sécurité des threads dans le cas où des événements de surveillance pourraient survenir de manière concurrente. Question Q-793a6c18d81de85e (ouverte) La disponibilité de la fonction de rappel est configurable dans le module de communication et est adaptée aux exigences de surveillance respectives.

Gestion des erreurs

Dans [SWS_Com_00554], aucun message d’erreur DET ou DEM distinct et aucune valeur de retour pour l’acquittement d’erreur ne sont définis pour Com_CbkTxTOut. Le déclenchement du rappel constitue lui-même la réaction d’erreur à une échéance d’émission dépassée.

La fonction de rappel Com_CbkRxAck sert dans le module AUTOSAR COM de confirmation de réception configurable et représente la classe de notification 1 selon [17] [SWS_Com_00555]. Le module COM appelle cette routine de rappel immédiatement après qu’un message reçu a été déposé et enregistré avec succès dans l’objet de message de réception prévu à cet effet [SWS_Com_00555].

Utilisation et contexte d'appel

• Comportement d’exécution synchrone : la fonction est spécifiée comme synchrone [SWS_Com_00555]. Elle est exécutée directement au cours du processus d’enregistrement, de sorte que le contexte appelant du module COM attend l’exécution du rappel.
• Paramètres et valeurs de retour : conformément à la signature void Com_CbkRxAck (void), aucun paramètre d’entrée, aucun paramètre d’entrée/sortie et aucun paramètre de sortie ne sont transmis [SWS_Com_00555]. La fonction ne renvoie en outre aucune valeur de retour au module appelant [SWS_Com_00555].
• Disponibilité : le mécanisme d’appel est à la disposition du système en tant qu’interface configurable [SWS_Com_00555].

Concurrence et traitement des erreurs

Pour la réentrance, la propriété « don't care » est définie [SWS_Com_00555]. Cela devrait signifier que la spécification COM n’impose aucune exigence quant à un appel réentrant et que les mécanismes de protection contre les accès simultanés relèvent de la responsabilité de l’utilisateur. Question (ouverte) Comme ni valeurs de retour, ni codes d’erreur spécifiques, ni messages d’erreur pour DET ou DEM ne sont définis [SWS_Com_00555], les erreurs éventuelles lors du traitement devraient probablement devoir être traitées entièrement localement au sein de la fonction de rappel.

Utilisation et sémantique

La fonction de rappel Com_CbkRxTOut sert à notifier l’absence d’un message attendu. Selon [SWS_Com_00556], elle est appelée immédiatement dès que le mécanisme de deadline monitoring du module constate une erreur lors de la réception d’un message. Cette notification correspond à la classe de notification 3 (« notification class 3 of [17] ») et est disponible en tant qu’interface configurable [SWS_Com_00556].

L'appel s'effectue de manière synchrone (Synchronous) sans paramètre d'entrée ni valeur de retour (void Com_CbkRxTOut(void)) [SWS_Com_00556]. La fonction signale ainsi au récepteur appelant ou à la couche logicielle supérieure uniquement l'événement de temporisation lui-même, sans transmettre de données de contexte directement dans l'appel.

Concurrence et restrictions

Pour la réentrance de la fonction, la spécification stipule don't care [SWS_Com_00556]. Étant donné que l'appel a lieu immédiatement et de manière synchrone après la détection d'erreur, l'implémentation de la routine de rappel devrait probablement devoir être conçue de façon à minimiser les blocages, afin de ne pas retarder indûment la surveillance des délais d'échéance (deadline monitoring) du module COM. Question Q-88055efc50f5843b (ouverte)

La fonction de rappel Com_CbkInv notifie les couches logicielles supérieures de la réception de données de communication erronées ou invalides dans le module COM AUTOSAR [SWS_Com_00536]. Elle est appelée immédiatement après la réception d’un signal invalide ou d’un groupe de signaux invalide et informe le destinataire de la présence d’une valeur de signal invalide [SWS_Com_00536].

L’interface possède la signature void Com_CbkInv(void), n’accepte par conséquent aucun paramètre de transmission et ne renvoie aucune valeur de retour à l’appelant [SWS_Com_00536]. L’appel s’effectue de manière synchrone, tandis que le comportement de réentrance est indiqué par « don't care » dans la spécification [SWS_Com_00536]. Étant donné qu’aucun paramètre n’est transmis pour identifier le signal concerné, l’identifiant Com_CbkInv sert vraisemblablement de modèle de signature configurable pour des notifications spécifiques aux signaux. Question Q-6e02e6bcf324eb93 (ouverte)

En ce qui concerne l’intégration et le comportement du système, les conditions limites suivantes s’appliquent :

• La mise à disposition de la fonction est configurable, ce qui permet d’activer la notification au besoin par signal ou groupe de signaux [SWS_Com_00536].
• Sur le plan fonctionnel, la fonction correspond à l’exigence SWS_Com_00680 pour le traitement d’invalidation des signaux reçus dans le module COM [SWS_Com_00536].
• Aucune routine spécifique de traitement des erreurs, aucun code d’erreur ni aucun message d’erreur vers des modules de développement ou de diagnostic tels que DET ou DEM ne sont indiqués pour cette interface [SWS_Com_00536].

La fonction de rappel configurable Com_CbkCounterErr sert à signaler des erreurs lors de la surveillance du compteur d'I-PDU conformément à [SWS_Com_00726]. Elle est appelée immédiatement et de manière synchrone par le module AUTOSAR COM lorsqu'une valeur de compteur ne correspondant pas à la valeur attendue est détectée pour une I-PDU reçue. Cela permet une détection précoce des erreurs de séquence lors de la réception des messages.

L'interface ne possède pas de valeur de retour (void) et transmet trois paramètres d'entrée pour l'analyse des erreurs lors de son appel ([SWS_Com_00726]) :

• ComPduId (PduIdType) : identifiant de l'I-PDU concernée sur laquelle l'erreur de compteur est survenue.
• ExpectedCounter (uint8) : valeur de compteur de l'I-PDU attendue par le module COM.
• ReceivedCounter (uint8) : valeur de compteur effectivement trouvée dans le message reçu.

Concernant la concurrence, la réentrance de la fonction est déclarée avec « don't care » dans la spécification ([SWS_Com_00726]). Aucun message d'erreur DET ou DEM spécifique n'est prescrit pour cette interface dans [SWS_Com_00726]. La fonction de rappel étant définie comme configurable, elle devrait probablement être implémentée dans une couche supérieure telle que l'application, afin de réagir de manière spécifique à l'application aux erreurs de transmission ou aux pertes de paquets. Interprétation : l'appel ayant lieu immédiatement et de manière synchrone dans le contexte du traitement de réception de COM ([SWS_Com_00726]), la routine appelée ne devrait exécuter aucune opération bloquante. Question Q-a745eb5416fc156b (ouverte)

La fonction de rappel Com_CbkTxPrep sert de notification indiquant que les signaux ou groupes de signaux d'une instance dédiée de Com_MainFunctionTx sont désormais en cours de préparation pour la transmission [SWS_Com_91013]. L'exécution de la fonction est synchrone avec l'instance appelante [SWS_Com_91013]. Conformément à sa signature void Com_CbkTxPrep(void), elle n'accepte aucun paramètre d'entrée, paramètre d'entrée/sortie ou paramètre de sortie, et ne possède aucune valeur de retour [SWS_Com_91013].

La mise à disposition de l'interface s'effectue par l'intermédiaire d'une configuration [SWS_Com_91013]. Si le paramètre de configuration ComPreparationNotification est configuré, la fonction respective Com_CbkTxPrep doit être appelée au sein de l'instance correspondante de MainFunctionTx [SWS_Com_00886]. Ce faisant, une condition stricte d'ordre chronologique doit obligatoirement être respectée : l'appel doit avoir intégralement lieu avant que le traitement effectif des I-PDU au sein de la fonction principale Tx ne soit démarré [SWS_Com_00886].

Concernant le comportement en matière de concurrence et les restrictions possibles, Com_CbkTxPrep est spécifiée comme non réentrante (Non Reentrant) [SWS_Com_91013]. Le contexte d'appel est strictement lié au déroulement de l'instance respective de MainFunctionTx [SWS_Com_91013]. La fonction de rappel devant être exécutée immédiatement avant le début du traitement des I-PDU, elle est intégrée de manière synchrone dans la routine d'émission correspondante [SWS_Com_00886].

La fonction Com_RxIpduCallout est un callout configurable côté récepteur qui sert à implémenter des mécanismes de filtrage de réception spécifiques à l'utilisateur pour les I-PDU [SWS_Com_00700]. L'exécution est synchrone et, en matière de réentrance, l'interface est spécifiée comme don't care [SWS_Com_00700].

L'identifiant ainsi que les données de la PDU reçue sont transmis à l'appel [SWS_Com_00700] :

• PduId : identifiant de l'I-PDU reçue [SWS_Com_00700].
• PduInfoPtr : pointeur vers une structure PduInfoType fournissant la longueur (SduLength) ainsi qu'un pointeur vers les données utiles (SduDataPtr) de l'I-PDU reçue [SWS_Com_00700].

Concernant la mise à disposition des données, [SWS_Com_00816] exige que le module AUTOSAR COM transmette l'intégralité des données de l'I-PDU reçue à Com_RxIpduCallout, exactement telles qu'elles ont été fournies par la couche de routage de PDU (PduR).

Le callout contrôle le traitement ultérieur de l'I-PDU dans le module COM par l'intermédiaire de la valeur de retour booléenne [SWS_Com_00700] :

• true : l'I-PDU reçue fait l'objet d'un traitement ultérieur normal [SWS_Com_00700].
• false : l'I-PDU ne fait l'objet d'aucun traitement ultérieur et est donc rejetée [SWS_Com_00700].

Aucun code d'erreur spécifique, constante de code retour ou message DET et DEM n'est prévu pour ce callout dans la spécification [SWS_Com_00700].

La fonction Com_TxIpduCallout sert de callout configurable côté émetteur et est appelée de manière synchrone afin d'effectuer un prétraitement ou un filtrage de transmission spécifique à l'utilisateur sur une I-PDU sortante [SWS_Com_00346].

Paramètres et valeur de retour

• PduId (in) : transmet l'identifiant de l'I-PDU à transmettre [SWS_Com_00346].
• PduInfoPtr (inout) : contient la longueur des données utiles (SduLength) ainsi qu'un pointeur vers les données utiles (SduDataPtr) de l'I-PDU [SWS_Com_00346]. Cela permet d'inspecter ou de modifier les données de l'I-PDU avant l'envoi.
• Valeur de retour (boolean) : contrôle la suite du traitement de l'I-PDU [SWS_Com_00346]. Une valeur de retour de true déclenche l'envoi régulier de l'I-PDU, tandis que false interrompt tout traitement ultérieur et donc la transmission [SWS_Com_00346].

Concurrence et configuration

Le callout possède le Service-ID 0x29 et sa réentrance est définie côté spécification par « don't care » [SWS_Com_00346]. Interprétation : la réentrance étant sans restriction, les appels devraient intervenir dans différents contextes de tâches selon la demande d'émission déclenchante, raison pour laquelle les implémentations côté utilisateur devraient être thread-safe en présence de ressources partagées. Question Q-3ce35701879bb60c (ouverte)

Le type énuméré Com_StatusType définit la valeur d'état pour le module AUTOSAR COM et est mis à disposition via le fichier d'en-tête Com.h [SWS_Com_00819]. Ce type sert de valeur de retour au service d'API Com_GetStatus(), grâce auquel les appelants peuvent interroger l'état actuel d'initialisation et de fonctionnement du module de communication [SWS_Com_00819].

La plage de valeurs spécifiée de Com_StatusType distingue exactement deux états [SWS_Com_00819] :

• COM_UNINIT : indique que le module AUTOSAR COM n'est pas initialisé ou n'est pas utilisable [SWS_Com_00819]. Cet état possède obligatoirement la valeur numérique 0x00 (ou valeur 0) et constitue la valeur par défaut obligatoire immédiatement après une réinitialisation du système [SWS_Com_00819].
• COM_INIT : signale que le module AUTOSAR COM a été correctement initialisé et est donc opérationnel et utilisable [SWS_Com_00819].

Pour le logiciel appelant, l'évaluation de cette valeur de retour sert à vérifier que le module de communication est prêt à l'emploi avant son utilisation [SWS_Com_00819]. Tant que le service Com_GetStatus() renvoie la valeur COM_UNINIT, le module COM est considéré comme non initialisé ou non utilisable [SWS_Com_00819]. Ce n'est que lorsque l'état présente la valeur COM_INIT que le module est initialisé et opérationnel [SWS_Com_00819]. Aucun autre code d'erreur ou valeur de retour n'est spécifié pour ce type énuméré [SWS_Com_00819].