AUTOSAR Classic LIN

El clúster de módulos LIN Communication implementa la conexión estandarizada de subsistemas de bus LIN a través de los módulos LinSM, LinIf, LinTrcv y Lin (SWS COMManager p. 19). Controla la transmisión de tramas basada en schedule en los masters, así como la evaluación reactiva de cabeceras y la transmisión de datos en los slaves ([SWS_LinIf_91004], [SWS_Lin_00168]). Al mismo tiempo, el clúster coordina la transición ordenada entre comunicación completa y modo de suspensión, así como el tratamiento autónomo de errores mediante la señal response_error ([SWS_LinIf_00763]).

más ›

El clúster de módulos LIN Communication proporciona la implementación completa de AUTOSAR del protocolo LIN e incluye el gestor de estados LinSM, la interfaz LinIf (incluido el protocolo de transporte LinTp), el controlador de transceptor LinTrcv y el controlador MCAL Lin (SWS COMManager p. 19). Conecta subredes, sensores y actuadores a la matriz de comunicación de AUTOSAR y distingue estrictamente entre nodos master con procesamiento autónomo de schedule y nodos slave con respuesta puramente reactiva ([SWS_LinIf_00197], [SWS_Lin_00272]).

Diagrama de arquitectura: arquitectura en capas y relaciones de interfaz del clúster LIN entre servicios de comunicación, capa de abstracción y MCAL. Fuentes: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

La transmisión de datos se lleva a cabo en ECUs master mediante la activación periódica del controlador a través de Lin_SendFrame y la posterior consulta de estado vía Lin_GetStatus ([SWS_Lin_00168]). En el slave, por el contrario, la detección de una cabecera en el controlador conduce a la callback síncrona LinIf_HeaderIndication ([SWS_LinIf_91004]). La interfaz decide en función del PID sobre la recepción, respuesta o ignorado, y confirma la finalización a través de LinIf_RxIndication o LinIf_TxConfirmation ([SWS_LinIf_91005], [SWS_LinIf_91006]). El LinTp integrado gestiona los mensajes de diagnóstico mediante conmutaciones automatizadas de la tabla de schedule ([SWS_LinIf_00641]).

En el ciclo de funcionamiento, LinSM coordina las transiciones de estado entre LINSM_NO_COM y LINSM_FULL_COM ([SWS_LinSM_00026], [SWS_LinSM_00032]). El despertar se realiza mediante un pulso de bus a través de Lin_Wakeup ([SWS_Lin_00169]). La transición al modo de suspensión se produce en el master mediante el envío activo de una trama de suspensión, y en el slave tras la recepción del comando de suspensión o en caso de bus inactivo vía LinIf_GotoSleep, Lin_GoToSleepInternal y control de suspensión del transceptor ([SWS_LinSM_00231], [SWS_LinIf_00757]).

Diagrama de secuencia: interacción de los módulos BSW durante la entrada de un slave LIN en el estado de suspensión tras la señal de reposo del bus. Fuentes: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Los errores de comunicación se registran en los slaves a través de LinIf_LinErrorIndication y se notifican de forma autónoma al master en la señal response_error ([SWS_LinIf_91007], [SWS_LinIf_00763]). Las áreas de sincronización entre canales y las separaciones estrictas entre tareas cíclicas (LinIf_MainFunction) y las ISR del controlador aseguran la estabilidad del sistema ([SWS_LinIf_00384]).

más ›

Arquitectura del sistema & rol del clúster de módulos

El clúster de módulos LIN Communication proporciona en la pila de Basic Software de AUTOSAR Classic la comunicación estandarizada a través de Local Interconnect Network (LIN) según la norma ISO 17987. Actúa principalmente como un subsistema de bus rentable para conectar sensores y actuadores en la red del vehículo (AUTOSAR FO Features p. 58). El clúster abarca varias capas de la arquitectura AUTOSAR: el LIN State Manager (LinSM) opera en el nivel de Communication Services, la LIN Interface (LinIf), incluido el protocolo de transporte integrado (LinTp), constituye la Communication Abstraction, el LIN Transceiver Driver (LinTrcv) forma parte de la ECU Abstraction y el LIN Driver (Lin) reside como módulo próximo al hardware en la capa de abstracción de microcontrolador (MCAL) (SWS COMManager p. 19).

Desde el punto de vista arquitectónico, el clúster diferencia estrictamente entre nodos master y slave. Un master LIN controla el tráfico del bus de forma autosuficiente a través de tablas de schedule y genera todas las cabeceras, mientras que los slaves LIN responden de forma puramente reactiva a las cabeceras recibidas o evalúan señales ([SWS_LinIf_00197], [SWS_Lin_00272]). Para tareas de diagnóstico y transporte según ISO 14229, la LIN Interface encapsula la funcionalidad TP, que gestiona mensajes de diagnóstico segmentados (Master Request Frame MRF y Slave Response Frame SRF) a través de PduR y DCM ([SWS_LinIf_00351], [SWS_LinIf_00629]). Hacia el exterior, el clúster interactúa intensamente con el Communication Manager (ComM), el Basic Software Mode Manager (BswM), el PDU Router (PduR) y el ECU State Manager (EcuM) (SWS COMManager p. 19).

Diagrama de arquitectura: arquitectura en capas y relaciones de interfaz del clúster LIN entre servicios de comunicación, capa de abstracción y MCAL. Fuentes: SWS COMManager p. 19, AUTOSAR SWS LINInterface p. 133.

Interacción y rutas de interacción entre los módulos

Las rutas de interacción en el clúster difieren fundamentalmente según el rol del nodo. En el master LIN, la LIN Interface inicia el procesamiento de la tabla de schedule activa a través de su tarea periódica. Para las tramas de transmisión pendientes, LinIf obtiene los datos útiles mediante mecanismos de Trigger Transmit de la capa superior y transfiere la estructura Lin_PduType al controlador LIN vía Lin_SendFrame ([SWS_Lin_00232], SWS LINInterface p. 37). El controlador transmite la cabecera y los datos de forma no bloqueante ([SWS_Lin_00027]). Una vez transcurrido el tiempo de ejecución máximo de la trama, LinIf determina el resultado de la transmisión a través de Lin_GetStatus ([SWS_Lin_00168], SWS LINInterface p. 35). En los slots de recepción, LinIf recoge los datos almacenados por el controlador en el búfer y los reenvía a las capas superiores ([SWS_Lin_00233]).

En un slave LIN, la ruta de datos transcurre guiada por eventos: si el controlador MCAL Lin detecta en el hardware una cabecera válida de sincronización, ruptura e identificador protegido (Break, Synch y PID), invoca de forma síncrona la callback LinIf_HeaderIndication ([SWS_Lin_00280], [SWS_LinIf_91004]). La interfaz verifica el identificador protegido (PID) mediante la tabla interna de PID ([SWS_LinIf_00816], [SWS_LinIf_00823]). Si se trata de una trama de transmisión, LinIf recoge los datos útiles, configura el tipo de respuesta a LIN_FRAMERESPONSE_TX y pone los datos a disposición del controlador en el búfer ([SWS_Lin_00230]). Si la trama está configurada como de recepción, el controlador notifica el éxito vía LinIf_RxIndication ([SWS_LinIf_91005]) tras la recepción completa de los bytes, tras lo cual LinIf transfiere los datos al PDU Router. Las confirmaciones de respuestas de slave enviadas se realizan mediante LinIf_TxConfirmation ([SWS_LinIf_91006]).

A través de la interfaz LIN se encapsula además el control del transceptor de forma transparente: la interfaz reenvía solicitudes de modo como LinIf_SetTrcvMode de forma síncrona a LinTrcv_SetOpMode ([SWS_LinIf_00544], [SWS_LinTrcv_00002]). En transacciones de protocolo de transporte, LinTp controla a través de BswM_LinTp_RequestMode la conmutación selectiva de la tabla de schedule del master entre el modo de aplicación (LINTP_APPLICATIVE_SCHEDULE), solicitud de diagnóstico (LINTP_DIAG_REQUEST) y respuesta de diagnóstico (LINTP_DIAG_RESPONSE) ([SWS_LinIf_00641], [SWS_LinIf_00642], [SWS_LinIf_00643]).

Diagrama de secuencia: flujo dinámico de control y datos en la indicación de cabecera, disparo de transmisión y confirmación de recepción en un slave LIN. Fuentes: [SWS_Lin_00280], [SWS_LinIf_91004], [SWS_LinIf_91005], AUTOSAR SWS LINInterface p. 133.

Sincronización, reentrancia y contextos de tareas

La ejecución dentro del clúster de módulos se divide en contextos de tareas cíclicas y niveles de interrupción cercanos al hardware. El núcleo del control de ejecución cíclica en la LIN Interface es la función planificada LinIf_MainFunction_<LinIfChannel.ShortName>, que se instancia obligatoriamente por separado para cada canal LIN configurado ([SWS_LinIf_00384], [SWS_LinIf_00725]). Esta asume el avance de los slots de schedule, las consultas de estado en el controlador y la gestión de tiempos de espera del protocolo de transporte ([SWS_LinIf_00800], SWS LINInterface p. 119). Paralelamente a esto, LinSM_MainFunction gestiona los temporizadores de cuenta atrás y de confirmación para solicitudes asíncronas de canal y de wakeup ([SWS_LinSM_00162], [SWS_LinSM_00159]).

A diferencia del nivel de tareas, las rutinas del controlador del módulo MCAL Lin se ejecutan en el contexto de interrupción (ISR) si existe un controlador gestionado por interrupciones o una interfaz UART (AUTOSAR CP SWS LINDriver p. 53). Las callbacks LinIf_HeaderIndication, LinIf_RxIndication y LinIf_TxConfirmation se disparan de forma síncrona directamente desde este contexto de ISR ([SWS_Lin_00280], [SWS_LinIf_91005], [SWS_LinIf_91006]). Esto requiere una protección estricta de las áreas críticas (Exclusive Areas) en la LIN Interface: las llamadas de control como LinIf_Transmit, LinIf_GotoSleep, LinIf_ScheduleRequest o LinIf_Wakeup solo deben modificar estructuras de canales internas estando protegidas frente a accesos paralelos desde la LinIf_MainFunction o callbacks de ISR (SWS LINInterface p. 119).

En cuanto a la reentrancia, las funciones de API de los módulos LinIf y LinSM están diseñadas predominantemente como reentrantes para diferentes canales o redes, pero no reentrantes para el mismo canal ([SWS_LinSM_00126], [SWS_LinIf_00201], [SWS_LinIf_00204]). Del mismo modo se comportan los servicios del controlador en Lin (por ejemplo, Lin_Wakeup, Lin_GoToSleepInternal), que deben sincronizarse estrictamente por canal físico ([SWS_Lin_00167], [SWS_Lin_00169]). En hardware UART simple sin FIFO multibyte, el controlador LIN almacena en búfer los bytes temporalmente por software ([SWS_Lin_00026]), lo que, según interpretación: probablemente provoque una mayor carga de interrupciones de CPU en los nodos slave bajo una alta carga de bus. Pregunta Q-0d07d89d1ade6a01 (abierta)

Ciclos de vida típicos y modos de funcionamiento

Durante el inicio del sistema, el BswM inicializa los módulos BSW en una cadena predeterminada: primero se inicializan los controladores básicos Lin_Init y LinTrcv_Init, seguidos de LinIf_Init, LinTp_Init y, por último, LinSM_Init (ModemanagementGuide p. 54). LinIf_Init establece el schedule de todos los canales master por defecto en NULL_SCHEDULE ([SWS_LinIf_00233]) y carga en los slaves las tablas de NAD y PID preconfiguradas ([SWS_LinIf_00767], [SWS_LinIf_00768]). LinSM arranca en el estado LINSM_NO_COM, sin emitir callbacks a ComM o BswM durante la inicialización ([SWS_LinSM_00026], [SWS_LinSM_00166]).

Si el ComM solicita la habilitación de la comunicación a través de LinSM_RequestComMode(COMM_FULL_COMMUNICATION), LinSM activa directamente LinIf_Wakeup e inicia un temporizador de supervisión ([SWS_LinSM_00047], [SWS_LinSM_00100]). LinIf envía el pulso físico de wakeup al bus a través de Lin_Wakeup ([SWS_LinIf_00205], [SWS_Lin_00043]). Si LinIf notifica el proceso de despertar exitoso vía LinSM_WakeupConfirmation(success=TRUE), el estado cambia a LINSM_FULL_COM ([SWS_LinSM_00049], [SWS_LinSM_00132]). Esto se señaliza a ComM vía ComM_BusSM_ModeIndication y a BswM vía BswM_LinSM_CurrentState ([SWS_LinSM_00033], [SWS_LinSM_00192]). En los slaves, el bus solo se considera despierto con éxito cuando el master envía la primera cabecera LIN y esta es recibida ([SWS_LinIf_00761], SWS LINStateManager p. 28).

El apagado al modo de suspensión (Go-to-Sleep) difiere drásticamente: en un master, la solicitud COMM_NO_COMMUNICATION da lugar a la llamada de LinIf_GotoSleep ([SWS_LinSM_00036], [SWS_LinSM_10208]). LinIf encarga al controlador a través de Lin_GoToSleep enviar una trama Go-to-Sleep estandarizada en el bus ([SWS_Lin_00166], [SWS_Lin_00089]). En un slave, en cambio, la interfaz recibe el comando Go-to-Sleep o detecta un tiempo de espera de bus inactivo e informa a LinSM vía LinSM_GotoSleepIndication ([SWS_LinSM_91000]). LinSM llama entonces de forma síncrona a LinIf_GotoSleep ([SWS_LinSM_00231]). La interfaz conmuta el controlador localmente al estado LIN_CH_SLEEP a través de Lin_GoToSleepInternal ([SWS_LinIf_00757], [SWS_Lin_00095]) y pone el transceptor en estado de suspensión vía LinIf_SetTrcvMode(LINTRCV_TRCV_MODE_SLEEP) ([SWS_LinIf_00544], AUTOSAR CP SWS LINInterface p. 137). Tras la confirmación LinSM_GotoSleepConfirmation, LinSM cambia finalmente a LINSM_NO_COM ([SWS_LinSM_00046], [SWS_LinSM_00233]).

Diagrama de secuencia: interacción de los módulos BSW durante la entrada de un slave LIN en el estado de suspensión tras la señal de reposo del bus. Fuentes: [SWS_LinSM_91000], [SWS_LinSM_00231], [SWS_LinIf_00757], AUTOSAR SWS LINStateManager p. 48.

Tratamiento de errores, rastreo en DET y degradación

El clúster cuenta con un concepto de detección de errores y diagnóstico de varios niveles. Los errores de desarrollo se registran a través del Default Error Tracer (Det): los parámetros de canal o de red no válidos notifican LIN_E_INVALID_CHANNEL ([SWS_Lin_00259]), LINIF_E_NONEXISTENT_CHANNEL ([SWS_LinIf_00539]) o LINSM_E_NONEXISTENT_NETWORK ([SWS_LinSM_00127]). Las llamadas a módulos no inicializados conllevan LIN_E_UNINIT, LINIF_E_UNINIT o LINSM_E_UNINIT ([SWS_Lin_00258], [SWS_LinSM_00128]). Los errores de transceptor, como números de red no válidos, notifican LINTRCV_E_INVALID_LIN_NETWORK a DET ([SWS_LinTrcv_00145]).

Las perturbaciones de comunicación que se producen durante el funcionamiento continuo se clasifican como errores de tiempo de ejecución: la interfaz define LINIF_E_RESPONSE en caso de tramas erróneas, así como LINIF_E_NC_NO_RESPONSE ante respuestas ausentes a solicitudes de configuración de nodos ([SWS_LinIf_00729]). Los errores físicos de bus y de protocolo (errores de trama, errores de suma de comprobación, errores de monitorización de bits) los notifica el controlador MCAL en el slave a través de LinIf_LinErrorIndication con el estado Lin_SlaveErrorType ([SWS_LinIf_91007], [SWS_Lin_91140]). En los nodos master, Lin_GetStatus proporciona códigos de error detallados como LIN_TX_HEADER_ERROR, LIN_TX_ERROR o LIN_RX_ERROR a la interfaz ([SWS_Lin_00168], [SWS_Lin_00233]).

Un mecanismo de fallo central para los LIN-Slaves es la señal estandarizada response_error. La interfaz LIN gestiona esta señal de 1 bit de forma autónoma: si se produce un error de transmisión, LinIf activa el bit, que se transmite al máster en la siguiente trama de transmisión incondicionada ([SWS_LinIf_00763], SWS LINInterface p. 58). Tras una transmisión correcta de la trama, LinIf borra el flag de forma automática ([SWS_LinIf_00747]). En el canal de diagnóstico, LinTp supervisa estrictas ventanas de tiempo de protocolo: en caso de ausencia de N-PDUs, los temporizadores $N_{As}$ y $N_{Cr}$ cancelan la transacción de forma definida y notifican E_NOT_OK al PDU Router ([SWS_LinIf_00799], [SWS_LinIf_00804], [SWS_LinIf_00806]). Si falta capacidad de búfer en el PDU Router, la interfaz cancela la recepción y conmuta la tabla de planificación del máster de nuevo al modo de aplicación ([SWS_LinIf_00676], [SWS_LinIf_00792]).