AUTOSAR Classic LIN

Le cluster de modules LIN Communication réalise le raccordement standardisé des sous-systèmes de bus LIN via les modules LinSM, LinIf, LinTrcv et Lin (SWS COMManager p. 19). Il contrôle la transmission basée sur une table d'ordonnancement (schedule) des trames pour les maîtres, ainsi que l'évaluation réactive de l'en-tête et la transmission des données pour les esclaves ([SWS_LinIf_91004], [SWS_Lin_00168]). Parallèlement, le cluster coordonne la transition ordonnée entre la communication complète et le mode veille, ainsi que le traitement autonome des erreurs via le signal response_error ([SWS_LinIf_00763]).

plus ›

Le cluster de modules LIN Communication fournit l'implémentation AUTOSAR complète du protocole LIN et comprend le gestionnaire d'états LinSM, l'interface LinIf (y compris le protocole de transport LinTp), le pilote de transceiver LinTrcv ainsi que le pilote MCAL Lin (SWS COMManager p. 19). Il relie les sous-réseaux, les capteurs et les actionneurs à la matrice de communication AUTOSAR et fait une distinction stricte entre les nœuds maîtres avec exécution autonome du schedule et les nœuds esclaves répondant de manière purement réactive ([SWS_LinIf_00197], [SWS_Lin_00272]).

Diagramme d'architecture\u00a0: architecture en couches et relations d'interfaces du cluster LIN entre les services de communication, la couche d'abstraction et la MCAL. Sources\u00a0: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

La transmission des données s'effectue sur les calculateurs (ECU) maîtres par le pilotage périodique du pilote via Lin_SendFrame, suivi de l'interrogation d'état via Lin_GetStatus ([SWS_Lin_00168]). Sur l'esclave en revanche, la détection d'un en-tête dans le pilote entraîne le callback synchrone LinIf_HeaderIndication ([SWS_LinIf_91004]). L'interface décide de la réception, de la réponse ou de l'ignorance sur la base du PID et acquitte la fin des opérations via LinIf_RxIndication ou LinIf_TxConfirmation ([SWS_LinIf_91005], [SWS_LinIf_91006]). Le LinTp intégré traite les messages de diagnostic via des commutations automatisées de la table de schedule ([SWS_LinIf_00641]).

Dans le cycle de fonctionnement, LinSM coordonne les transitions d'état entre LINSM_NO_COM et LINSM_FULL_COM ([SWS_LinSM_00026], [SWS_LinSM_00032]). Le réveil s'effectue par impulsion de bus via Lin_Wakeup ([SWS_Lin_00169]). Le passage en mode veille s'effectue pour le maître par l'envoi actif d'une trame de sommeil (sleep frame), et pour l'esclave après réception de la commande de sommeil ou en cas de bus au repos (bus idle) via LinIf_GotoSleep, Lin_GoToSleepInternal et la commande de mise en veille du transceiver ([SWS_LinSM_00231], [SWS_LinIf_00757]).

Diagramme de séquence\u00a0: interaction des modules BSW lors de l'entrée d'un esclave LIN en état de veille après le signal bus sleep. Sources\u00a0: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Les erreurs de communication sont détectées sur les esclaves via LinIf_LinErrorIndication et signalées de manière autonome au maître dans le signal response_error ([SWS_LinIf_91007], [SWS_LinIf_00763]). Des zones de synchronisation inter-canaux et des séparations strictes entre tâches cycliques (LinIf_MainFunction) et ISR du pilote garantissent la stabilité du système ([SWS_LinIf_00384]).

plus ›

Architecture système & rôle du cluster de modules

Le cluster de modules LIN Communication fournit la communication standardisée via le Local Interconnect Network (LIN) selon la norme ISO 17987 au sein de la pile logicielle de base AUTOSAR Classic (Basic Software). Il sert principalement de sous-système de bus économique pour raccorder capteurs et actionneurs dans le réseau de bord du véhicule (AUTOSAR FO Features p. 58). Le cluster s'étend sur plusieurs couches de l'architecture AUTOSAR\u00a0: le LIN State Manager (LinSM) opère au niveau des Communication Services, la LIN Interface (LinIf) incluant le protocole de transport intégré (LinTp) constitue la Communication Abstraction, le LIN Transceiver Driver (LinTrcv) fait partie de l'ECU Abstraction et le LIN Driver (Lin) réside en tant que module proche du matériel dans la couche d'abstraction du microcontrôleur (MCAL) (SWS COMManager p. 19).

Sur le plan architectural, le cluster différencie strictement les nœuds maîtres et les nœuds esclaves. Un maître LIN contrôle de façon autonome le trafic sur le bus via des tables d'ordonnancement (schedule tables) et génère tous les en-têtes, tandis que les esclaves LIN répondent de manière purement réactive aux en-têtes reçus ou évaluent les signaux ([SWS_LinIf_00197], [SWS_Lin_00272]). Pour les tâches de diagnostic et de transport selon l'ISO 14229, la LIN Interface encapsule la fonctionnalité TP, qui traite les messages de diagnostic segmentés (Master Request Frame MRF et Slave Response Frame SRF) via le PduR et le DCM ([SWS_LinIf_00351], [SWS_LinIf_00629]). Vers l'extérieur, le cluster interagit intensément avec le Communication Manager (ComM), le Basic Software Mode Manager (BswM), le PDU Router (PduR) et l'ECU State Manager (EcuM) (SWS COMManager p. 19).

Diagramme d'architecture\u00a0: architecture en couches et relations d'interfaces du cluster LIN entre les services de communication, la couche d'abstraction et la MCAL. Sources\u00a0: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

Interaction & voies d'interaction entre les modules

Les voies d'interaction dans le cluster diffèrent fondamentalement selon le rôle du nœud. Dans le maître LIN, la LIN Interface initie l'exécution de la table de schedule active via sa tâche périodique. Pour les trames d'émission arrivées à échéance, LinIf récupère les données utiles via les mécanismes de trigger transmit de la couche supérieure et transmet la structure Lin_PduType au pilote LIN via Lin_SendFrame ([SWS_Lin_00232], SWS LINInterface p. 37). Le pilote transmet l'en-tête et les données de manière non bloquante ([SWS_Lin_00027]). À l'expiration du temps d'exécution maximal de la trame, LinIf détermine le résultat de la transmission via Lin_GetStatus ([SWS_Lin_00168], SWS LINInterface p. 35). Lors des créneaux de réception, LinIf récupère les données déposées par le pilote dans le tampon et les achemine vers les couches supérieures ([SWS_Lin_00233]).

Sur un esclave LIN, le chemin de données s'exécute de manière événementielle\u00a0: si le pilote MCAL Lin détecte sur le matériel un en-tête valide comprenant break, synch et PID, il appelle de manière synchrone le callback LinIf_HeaderIndication ([SWS_Lin_00280], [SWS_LinIf_91004]). L'interface vérifie l'identifiant protégé (PID) à l'aide de la table PID interne ([SWS_LinIf_00816], [SWS_LinIf_00823]). S'il s'agit d'une trame d'émission, LinIf récupère les données utiles, configure le type de réponse sur LIN_FRAMERESPONSE_TX et met les données à disposition du pilote dans le tampon ([SWS_Lin_00230]). Si la trame est configurée en réception, le pilote signale le succès via LinIf_RxIndication une fois les octets complètement reçus ([SWS_LinIf_91005]), après quoi LinIf transmet les données au PDU Router. Les confirmations des réponses d'esclave émises s'effectuent via LinIf_TxConfirmation ([SWS_LinIf_91006]).

De plus, le pilotage du transceiver est encapsulé de manière transparente via la LIN Interface\u00a0: l'interface transmet de manière synchrone les demandes de mode telles que LinIf_SetTrcvMode à LinTrcv_SetOpMode ([SWS_LinIf_00544], [SWS_LinTrcv_00002]). Lors des transactions de protocole de transport, LinTp commande via BswM_LinTp_RequestMode la commutation ciblée de la table de schedule du maître entre le mode application (LINTP_APPLICATIVE_SCHEDULE), la demande de diagnostic (LINTP_DIAG_REQUEST) et la réponse de diagnostic (LINTP_DIAG_RESPONSE) ([SWS_LinIf_00641], [SWS_LinIf_00642], [SWS_LinIf_00643]).

Diagramme de séquence\u00a0: flux de commande et de données dynamique lors de l'indication d'en-tête, du déclenchement d'émission et de l'acquittement de réception sur un esclave LIN. Sources\u00a0: [SWS_Lin_00280], [SWS_LinIf_91004], [SWS_LinIf_91005], AUTOSAR SWS LINInterface p. 133.

Synchronisation, réentrance et contextes de tâches

L'exécution au sein du cluster de modules est répartie entre contextes de tâches cycliques et niveaux d'interruption proches du matériel. Au cœur du contrôle séquentiel cyclique dans la LIN Interface se trouve la fonction ordonnancée LinIf_MainFunction_<LinIfChannel.ShortName>, qui est obligatoirement instanciée séparément pour chaque canal LIN configuré ([SWS_LinIf_00384], [SWS_LinIf_00725]). Elle prend en charge l'avancement des créneaux de schedule, les interrogations d'état auprès du pilote et le traitement des temporisations (timeouts) du protocole de transport ([SWS_LinIf_00800], SWS LINInterface p. 119). En parallèle, LinSM_MainFunction gère les compteurs à rebours et temporisateurs de confirmation pour les requêtes asynchrones de canal et de réveil ([SWS_LinSM_00162], [SWS_LinSM_00159]).

Contrairement au niveau des tâches, les routines de pilote du module MCAL Lin s'exécutent dans le contexte d'interruption (ISR) en présence d'un contrôleur géré par interruption ou d'une interface UART (AUTOSAR CP SWS LINDriver p. 53). Les callbacks LinIf_HeaderIndication, LinIf_RxIndication et LinIf_TxConfirmation sont déclenchés de manière synchrone directement depuis ce contexte ISR ([SWS_Lin_00280], [SWS_LinIf_91005], [SWS_LinIf_91006]). Cela nécessite une protection stricte des zones critiques (Exclusive Areas) dans la LIN Interface\u00a0: les appels de commande tels que LinIf_Transmit, LinIf_GotoSleep, LinIf_ScheduleRequest ou LinIf_Wakeup ne doivent modifier les structures internes de canal que sous protection contre les accès parallèles issus de LinIf_MainFunction ou des callbacks ISR (SWS LINInterface p. 119).

En ce qui concerne la réentrance, les fonctions d'API des modules LinIf et LinSM sont principalement conçues comme réentrantes pour différents canaux ou réseaux, mais non réentrantes pour un même canal ([SWS_LinSM_00126], [SWS_LinIf_00201], [SWS_LinIf_00204]). Il en va de même pour les services de pilote dans Lin (par ex. Lin_Wakeup, Lin_GoToSleepInternal), qui doivent être strictement synchronisés par canal physique ([SWS_Lin_00167], [SWS_Lin_00169]). Dans le cas d'un matériel UART simple sans FIFO multi-octets, le pilote LIN met temporairement les octets en mémoire tampon au niveau logiciel ([SWS_Lin_00026]), ce qui, Interprétation : sous une charge de bus élevée, devrait entraîner une augmentation de la charge d'interruptions CPU sur les nœuds esclaves. Question Q-0d07d89d1ade6a01 (ouverte)

Cycles de vie et modes de fonctionnement typiques

Pendant le démarrage du système, le BswM initialise les modules BSW selon une chaîne prédéfinie : les pilotes de base Lin_Init et LinTrcv_Init sont d'abord initialisés, suivis de LinIf_Init, LinTp_Init et enfin LinSM_Init (ModemanagementGuide p. 54). Par défaut, LinIf_Init définit l'ordonnancement de tous les canaux maîtres sur NULL_SCHEDULE ([SWS_LinIf_00233]) et charge, pour les esclaves, les tables NAD et PID préconfigurées ([SWS_LinIf_00767], [SWS_LinIf_00768]). LinSM démarre à l'état LINSM_NO_COM sans émettre de rappels vers ComM ou BswM lors de l'initialisation ([SWS_LinSM_00026], [SWS_LinSM_00166]).

Si le ComM demande l'autorisation de communication via LinSM_RequestComMode(COMM_FULL_COMMUNICATION), LinSM déclenche directement LinIf_Wakeup et démarre une minuterie de surveillance ([SWS_LinSM_00047], [SWS_LinSM_00100]). LinIf transmet l'impulsion physique de réveil sur le bus via Lin_Wakeup ([SWS_LinIf_00205], [SWS_Lin_00043]). Si LinIf signale le succès du processus de réveil via LinSM_WakeupConfirmation(success=TRUE), l'état passe à LINSM_FULL_COM ([SWS_LinSM_00049], [SWS_LinSM_00132]). Cela est signalé à ComM via ComM_BusSM_ModeIndication et à BswM via BswM_LinSM_CurrentState ([SWS_LinSM_00033], [SWS_LinSM_00192]). Pour les esclaves, le bus n'est considéré comme réveillé avec succès que lorsque le maître transmet le premier en-tête LIN et que celui-ci est reçu ([SWS_LinIf_00761], SWS LINStateManager p. 28).

Le passage en mode veille (Go-to-Sleep) diffère considérablement : sur un maître, la requête COMM_NO_COMMUNICATION entraîne l'appel de LinIf_GotoSleep ([SWS_LinSM_00036], [SWS_LinSM_10208]). LinIf charge le pilote, via Lin_GoToSleep, d'émettre une trame standardisée Go-to-Sleep sur le bus ([SWS_Lin_00166], [SWS_Lin_00089]). Sur un esclave en revanche, l'interface reçoit la commande Go-to-Sleep ou détecte un délai d'inactivité du bus (bus-idle timeout) et informe LinSM via LinSM_GotoSleepIndication ([SWS_LinSM_91000]). LinSM appelle ensuite de manière synchrone LinIf_GotoSleep ([SWS_LinSM_00231]). L'interface commute localement le pilote à l'état LIN_CH_SLEEP via Lin_GoToSleepInternal ([SWS_LinIf_00757], [SWS_Lin_00095]) et place l'émetteur-récepteur en état de veille via LinIf_SetTrcvMode(LINTRCV_TRCV_MODE_SLEEP) ([SWS_LinIf_00544], AUTOSAR CP SWS LINInterface p. 137). Après la confirmation LinSM_GotoSleepConfirmation, LinSM passe finalement à LINSM_NO_COM ([SWS_LinSM_00046], [SWS_LinSM_00233]).

Diagramme de séquence\u00a0: interaction des modules BSW lors de l'entrée d'un esclave LIN en état de veille après le signal bus sleep. Sources\u00a0: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Gestion des erreurs, traçage DET et dégradation

Le cluster dispose d'un concept multicouche de détection d'erreurs et de diagnostic. Les erreurs de développement sont enregistrées via le Default Error Tracer (Det) : des paramètres de canal ou de réseau non valides signalent LIN_E_INVALID_CHANNEL ([SWS_Lin_00259]), LINIF_E_NONEXISTENT_CHANNEL ([SWS_LinIf_00539]) ou LINSM_E_NONEXISTENT_NETWORK ([SWS_LinSM_00127]). Les appels de modules non initialisés entraînent LIN_E_UNINIT, LINIF_E_UNINIT ou LINSM_E_UNINIT ([SWS_Lin_00258], [SWS_LinSM_00128]). Les erreurs d'émetteur-récepteur telles que des numéros de réseau non valides signalent LINTRCV_E_INVALID_LIN_NETWORK au DET ([SWS_LinTrcv_00145]).

Les perturbations de communication survenant en cours d'exploitation sont classées comme erreurs d'exécution : l'interface définit LINIF_E_RESPONSE en cas de trames erronées ainsi que LINIF_E_NC_NO_RESPONSE lors de réponses manquantes aux requêtes de configuration de nœud ([SWS_LinIf_00729]). Les erreurs physiques de bus et de protocole (erreurs de trame, erreurs de somme de contrôle, erreurs de surveillance de bit) sont signalées sur l'esclave par le pilote MCAL via LinIf_LinErrorIndication avec le statut Lin_SlaveErrorType ([SWS_LinIf_91007], [SWS_Lin_91140]). Sur les nœuds maîtres, Lin_GetStatus fournit des codes d'erreur détaillés tels que LIN_TX_HEADER_ERROR, LIN_TX_ERROR ou LIN_RX_ERROR à l'interface ([SWS_Lin_00168], [SWS_Lin_00233]).

Un mécanisme central de gestion d'erreurs pour les esclaves LIN est le signal standardisé response_error. L'interface LIN gère ce signal de 1 bit de manière autonome : si une erreur de transmission survient, LinIf arme le bit, qui est transmis au maître dans la trame d'émission inconditionnelle suivante ([SWS_LinIf_00763], SWS LINInterface p. 58). Après une transmission réussie de la trame, LinIf efface automatiquement l'indicateur ([SWS_LinIf_00747]). Dans le canal de diagnostic, LinTp surveille de strictes fenêtres temporelles de protocole : en cas d'absence de N-PDU, les temporisateurs $N_{As}$ et $N_{Cr}$ interrompent la transaction de manière définie et signalent E_NOT_OK au routeur de PDU ([SWS_LinIf_00799], [SWS_LinIf_00804], [SWS_LinIf_00806]). Si la capacité de tampon fait défaut sur le routeur de PDU, l'interface interrompt la réception et bascule la table d'ordonnancement du maître vers le mode application ([SWS_LinIf_00676], [SWS_LinIf_00792]).