Introducción al Bus de Red Local de Interconexión (LIN)

1. Información General sobre LIN

El bus de Red Local de Interconexión (LIN) fue desarrollado para crear un estándar para comunicación multiplexada de bajo costo en redes automotrices. A pesar que CAN cubre la necesidad para alto ancho de banda, redes de manejo de error avanzado, los costos de hardware y software por la implementación de CAN se han vuelto prohibitivos para dispositivos de menor rendimiento como controladores de potencia de ventanas y asientos. LIN proporciona comunicación rentable en aplicaciones donde el ancho de banda y la versatilidad de CAN no son requeridos. Puede implementar LIN prácticamente a un menor precio usando el transmisor/receptor estándar serial universal asincrónico (UART) embebido en la mayoría de los microcontroladores modernos de bajo costo de 8 bits.

Las redes automotrices modernas usan una combinación de LIN para aplicaciones de bajo costo principalmente en electrónicos, CAN para comunicación de tren de potencia y carrocería y el bus FlexRay para comunicaciones de datos sincronizados de alta velocidad en sistemas avanzados como suspensión activa.

El bus LIN usa un enfoque maestro/esclavo que consta de un LIN maestro y uno o más LIN esclavos.

Figura 1. Marco de Mensaje LIN

El encabezado de mensaje consiste de una interrupción usada para identificar el inicio del marco y el campo de sincronización usado por el nodo esclavo para sincronización de reloj. El identificador (ID) consta de un ID de mensaje de seis bits y un campo paridad de dos bits. El ID indica una dirección específica de mensaje pero no el destino. Después de la recepción e interrupción del ID, un esclavo comienza la respuesta del mensaje, la cual consiste de uno a ocho bytes de datos y una suma de verificación de ocho bits.

El maestro controla la secuencia de los marcos del mensaje, la cual es fija en un programa. Puede cambiar el programa según se necesite.

Hay varias versiones de LIN estándar. La versión 1.3 finalizó la comunicación byte-layer. Las versiones 2.0 y 2.1 añaden más especificaciones de mensajes y servicios pero son compatibles al nivel de byte con LIN 1.3.

¹Esta característica no está soportada por el API; sin embargo, puede implementar la funcionalidad.

Tabla 1. Comparación de Versiones LIN 1.3, 2.0 y 2.1

Back to Top

2. Formato de Marco LIN

El bus LIN es un bus con un solo dispositivo maestro y uno o más dispositivos esclavos. El dispositivo maestro contiene una tarea de maestro y una tarea de esclavo. Cada dispositivo esclavo tiene solamente una tarea de esclavo. La comunicación a través del bus LIN está controlada completamente por la tarea de maestro en el dispositivo maestro. La unidad básica de transferencia en el bus LIN es el marco, el cual está dividido en un encabezado y una respuesta. El encabezado siempre es transmitido por el nodo maestro y consiste de tres diferentes campos: la interrupción, la sincronización (symc) y el identificador (ID). La respuesta, la cual es transmitida por una tarea de esclavo y puede residir ya sea en el nodo maestro o un nodo esclavo, consiste de una carga útil de datos y una suma de verificación.

Normalmente, la tarea de maestro consulta cada tarea de esclavo en un ciclo al transmitir un encabezado, el cual consiste de una secuencia de interrupción-sincronización-ID. Antes de comenzar el LIN, cada tarea esclavo es configurada para publicar datos al bus o suscribir a datos en respuesta a cada ID de encabezado recibido. Después de recibir el encabezado, cada tarea de esclavo verifica la paridad de ID y después checa el ID para determinar si necesita publicar o suscribir. Si la tarea de esclavo necesita publicar una respuesta, transmite uno de los ochos bytes de datos al bus seguido de un byte de suma de verificación. Si la tarea de esclavo necesita suscribirse, lee la carga útil de los datos y el byte de la suma de verificación del bus y procede de manera apropiada.

Para comunicación estándar de esclavo a maestro, el maestro publica el identificador a la red y solamente un esclavo responde con una carga de datos.

La comunicación de maestro a esclavo se logra por una tarea de esclavo diferente en el nodo maestro. Esta tarea auto recibe todos los datos publicados al bus y responde como si fuera un nodo esclavo independiente. Para transmitir bytes de datos, el maestro debe primero actualizar su respuesta interna a la tarea de esclavo con los valores de datos que desea transmitir. El maestro entonces publica el encabezado de marco adecuado y la tarea interna de esclavo transmite su carga de datos al bus.

Figura 2. Marco de Mensaje LIN

1. Interrupción

Cada marco de LIN comienza con la interrupción, el cual consta de 13 bits dominantes (nominal) seguidos por un freno delimitador de un bit recesivo (nominal). Esto sirve como una nota de inicio del marco para todos los nodos en el bus.

2. Sincronización

El campo de sincronización es el segundo campo transmitido por la tarea de maestro en el encabezado. La sincronización está definida por el carácter x55. El campo de sincronización permite a los dispositivos esclavos que realizan detección automática de razón de transferencia para medir el periodo de la razón de transferencia y ajustar sus razones internas para sincronizarse con el bus.

3. ID

El campo de ID es el campo final transmitido por la tarea de maestro en el encabezado. Este campo proporciona identificación para cada mensaje en la red y finalmente determina cual nodo en la red recibe o responde a cada transmisión. Todas las tareas de esclavo escuchan continuamente a los campos de ID, verifican sus paridades y determinan si son publicadores o subscriptores para este identificador en particular. El bus LIN proporciona un total de 64 IDs. Los IDs 0 al 59 son usados para marcos (datos) de transmisión de señales, el 60 y 61 son usados para llevar datos de diagnóstico, el 62 es reservado para extensiones identificadas por el usuario y el 63 es reservado para mejoramientos futuros del protocolo. El ID es transmitido a través del bus como un byte de ID protegido, con los seis bits más bajos que contienen ID original y los dos bits más altos que contienen la paridad.

Tabla 2. Método de Cálculo de Paridad

4. Bytes de Datos

El campo de bytes de datos es transmitido por la tarea de esclavo en la respuesta. Este campo contiene de uno a ocho bytes de carga útil de datos.

5. Suma de Verificación

El campo de la suma de verificación es transmitido por la tarea de esclavo en la respuesta. El bus LIN define el uso de uno de dos algoritmos de suma de verificación para calcular el valor en el campo de la suma de verificación de ocho bits. La suma de verificación clásica es calculada al sumar solamente los bytes de datos, y la suma de verificación mejorada es calculada al sumar los bytes de datos y el ID protegido.

La especificación LIN 2.0 define el proceso de cálculo de la suma de verificación como la suma de todos los valores y la deducción de 255 cada vez que la suma es mayor o igual a 256 (distinto al módulo-255 o módulo-256). Según la especificación LIN 2.0, la suma de verificación clásica es para uso con nodos esclavos LIN 1.3 y la suma de verificación mejorada es para uso con nodos esclavos LIN 2.0. Especifica que los IDs 60 al 63, siempre deben usar la suma de verificación clásica. La interfaz LIN ofrece un atributo para establecer el tipo de suma de verificación, ya sea clásica o mejorada. El ajuste predeterminado es clásico. Conforme a la especificación LIN 2.0, los IDs del 60 al 63 siempre usan la suma de verificación clásica, sin importar la configuración del atributo de la suma de verificación.

La Figura 3 ilustra cómo un encabezado de tarea de maestro y una respuesta de tarea de esclavo se combinan para crear un marco LIN completo.

Figura 3. Creación de Marcos LIN

Back to Top

3. Temporización del Bus LIN

Ya que el bus LIN es un bus obtenido, el procesamiento de cada marco tiene adjudicada una ranura de tiempo nominal como sigue:

THeader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
El procesamiento de cada marco tiene adjudicada una ranura de tiempo nominal como sigue:
THeader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = THeader_Maximum + TResponse_Maximum

Back to Top

4. Topología y Comportamiento de LIN

El bus LIN conecta un solo dispositivo (nodo) maestro y un o más dispositivos (nodos) esclavo juntos en un cluster LIN. El comportamiento de cada nodo se describe por su propio archivo de capacidad de nodo. Los archivos de capacidad del nodo son entradas a una herramienta definida por software, la cual genera un archivo de descripción (LDF) que describe el comportamiento de todo el cluster. El LDF es analizado por un generador del sistema para generar automáticamente el comportamiento especificado en los nodos deseados. En este punto, la tarea del nodo maestro inicia transmitiendo encabezados en el bus y todas las tareas en el cluster (incluyendo la propia tarea de esclavo del nodo maestro) responden como se especifica en el LDF.

En términos generales, el LDF es usado para configurar y crear el comportamiento programado del cluster LIN. Por ejemplo, identifica la razón de transferencia, la ordenación y los retrasos de tiempo para la transmisión de la tarea de maestro de los encabezados y el comportamiento de cada tarea de esclavo en respuesta. El hardware LIN y el API NI-CAN de Trama para LIN no proporciona de manera original soporte completo para LDFs, lo que significa que usted no puede descargar el comportamiento programado al hardware. Sin embargo, el soporte de bajo nivel del acceso al bus (escribir encabezados y publicar o suscribir a respuestas) es proporcionado para que el usuario pueda crear este comportamiento programado al nivel de la aplicación. Como se mencionó en la descripción para el tipo de entrada de marco de respuesta de LIN, el hardware LIN tiene una respuesta en espera para almacenar respuestas de tarea de esclavo. La respuesta en espera detiene 64 respuestas, uno para cada uno del número máximo de 64 IDs especificados por LIN. Esto asegura que la tarea de interfaz esclavo de LIN puede responder a los encabezados durante el tiempo de respuesta definido por la especificación LIN.

API NI-CAN de Trama para LIN ofrece una interacción de bajo nivel con el bus LIN. Esto proporciona al usuario final la funcionalidad desde la cual se desarrollan aplicaciones complejas que involucran el análisis y generación de prototipos de redes LIN. El API NI-CAN de Trama para LIN no soporta de manera original diagnósticos LIN o configuración, LDFs o tablas de programación. Sin embargo, puede implementar estas tareas en aplicaciones que usan el API NI-CAN de Trama para LIN.

Back to Top

5. Detección de Error de LIN y Confinamiento

La especificación LIN 2.0 establece que la detección de error debe ser manejada por las tareas de esclavo y que no se requiere el monitoreo de error por la tarea de esclavo. La especificación LIN 2.0 no requiere el manejo de múltiples errores en un marco LIN o el uso de contadores de error. Después de encontrar el primer error en un marco, la tarea de esclavo aborta el procesamiento del marco hasta la detección de la próxima secuencia interrupción-sincronización (en el próximo encabezado transmitido por el maestro). Si el atributo de registro de errores de bus está establecido como verdadero, se registra un marco de error de bus en la lectura en espera. Si el atributo de registro de errores de bus está establecido como falso, se genera un error por ncWriteNet o ncWriteNetMult.

LIN también proporciona reportes por error a la red. La especificación LIN 2.0 define un bit de estado de Respuesta_Error, para el cual se requiere el esclavo para reportar al maestro en uno de sus marcos transmitidos. Este bit se establece en cuanto un marco recibido o transmitido por un nodo esclavo contiene un error en el campo de respuesta. El bit es liberado después de ser transmitido en uno de las respuestas publicadas del esclavo. El API NI-CAN de Marco para LIN no soporta de manera original el bit de Respuesta_Error pero proporciona al usuario final una manera de implementar fácilmente esta funcionalidad al nivel de la aplicación. El procedimiento consiste en establecer el atributo de registro de errores de bus igual a 1 para permitir el registro de los marcos de error del bus en la lectura en espera. La aplicación entonces puede monitorear una lectura de un marco de error del bus con el código de error indicando un error en la respuesta. Después de esta condición, la aplicación puede establecer un estado de Respuesta_Error en una variable local. La aplicación puede entonces usar el tipo de entrada de marco de respuesta de LIN para actualizar la respuesta de esclavo en espera con datos que contengan el bit de estado de Respuesta_Error y después liberar el bit en la variable local.

Back to Top

6. LIN Sleep and Wakeup

LIN tiene un mecanismo que permite a los dispositivos ya sea entrar en el modo de sleep o mantenerse encendidos. De acuerdo a la especificación LIN 2.0, todos los esclavos deben ser forzados al modo sleep al maestro enviar un marco de solicitud de diagnóstico maestro (ID=60) con el primer byte de datos igual a cero. Este marco especial se llama comando go-to-sleep. Los esclavos también entran automáticamente en modo sleep si el LIN está inactivo por más de cuatro segundos. El API NI-CAN de Trama para LIN proporciona gran flexibilidad al permitir que el usuario ponga la interfaz LIN en sleep cuando lo desee al nivel de la aplicación. Después de recibir un marco completo que contiene un mensaje de solicitud de sleep, o un marco de bus inactivo indica cuatro segundos de inactividad del bus, el usuario puede poner la interfaz LIN en sleep al establecer el atributo LIN Sleep en TRUE.

LIN también ofrece un mecanismo para despertar dispositivos en el bus. Wakeup es una de las tareas que se deben iniciar para cualquier nodo en el bus (un esclavo así como el maestro). Conforme la especificación LIN 2.0, la solicitud wakeup se realiza al forzar el dominante del bus para 250 µs a 5 ms. Cada esclavo debe detectar la solicitud de wakeup y debe estar listo para procesar encabezados en 100 ms. El maestro debe detectar también la solicitud de wakeup y comenzar a enviar encabezados cuando los nodos esclavo están listos (entre 100 y 150 ms después de recibir la solicitud wakeup). Si el maestro no envía encabezados 150 ms después de recibir la primera solicitud de wakeup, entonces el esclavo que solicita a wakeup debe intentar una segunda solicitud de wakeup (y esperar por otros 150 ms). Si el maestro aún no responde, el esclavo debe solicit la solicitud de wakeup y esperar 150 ms por tercera vez. Si así, aún no hay respuesta, el esclavo debe esperar 1.5 segundos antes de enviar una cuarta solicitud de wakeup. El API NI.CAN de Trama para LIN permite que el wakeup se realice de acuerdo a la especificación 2.0 sin importar si la interfaz LIN está operando como un maestro o esclavo.

Back to Top

7. Tipos de Marcos Avanzados

La especificación LIN 2.0 clasifica los marcos LIN en seis tipos:

1. Incondicional
2. Por Evento
3. Esporádico
4. Diagnóstico
5. Definido por el usuario
6. Reservado

Es importante notar que las diferencias entre estos tipos de marco se deben ya sea a la temporización de cómo son transmitidos o al contenido de los bytes de datos. Independientemente de la clasificación del marco, un marco LIN completo consiste en un encabezado transmitido por la tarea de maestro y una respuesta transmitida por una tarea de esclavo. El API NI-CAN de Trama para LIN puede cubrir las necesidades del manejo de cada uno de estos tipos de marcos especificados por LIN. El tipo de marco incondicional es el usado con más frecuencia. Los marcos incondicionales llevan señales (datos) y sus identificadores están en el rango de 0 a 59.

El tipo de marco por evento intenta conservar el ancho de banda del bus al solicitar una respuesta de marco incondicional desde múltiples esclavos en un tiempo de ranura de marco.

El marco por evento puede tener un ID en el rango de 0 a 59. Cada esclavo que puede responder al ID de encabezado por evento tiene su primer byte de datos cargado con el ID protegido que respondería si el maestro lo cuestiona para un marco incondicional. El marco por evento funciona de la siguiente manera: El maestro escribe un ID de disparo en un encabezado. Los esclavos pueden responder solamente al ID por evento si sus datos han sido actualizados.

Si solamente un esclavo publica una respuesta, entonces el maestro lo recibe y por ver el primer byte de datos, sabe desde cual esclavo fue recibido (a través del ID protegido). Si varios esclavos publican una respuesta, ocurre un choque, la cual la tarea de esclavo del dispositivo maestro reporta como un error del bus. El dispositivo maestro entonces solicita una respuesta desde cada esclavo usando marcos incondicionales.

Los marcos esporádicos proporcionan algún comportamiento dinámico al LIN. Siempre llevan señales (datos) y sus IDs van desde 0 a 59. El encabezado de un marco esporádico debe ser enviado solamente en su ranura de marco cuando la tarea de maestro sabe que el valor del dato (señal) en el marco ha sido actualizada. Este requerimiento convierte a la tarea de esclavo del dispositivo maestro el editor normal de respuesta de marco esporádico.

Los marcos de diagnóstico siempre tienen ocho bytes de datos y siempre llevan datos de diagnóstico o configuración. Sus IDs son ya sea 60 para un marco de solicitud de maestro o 61 para marco de respuesta de esclavo. Los marcos definidos por el usuario, los cuales tienen un ID de 62, pueden llevar cualquier tipo de información. Los marcos reservados tienen un ID de 63 y no deben ser usados en un cluster LIN 2.0.

Back to Top

8. Interfaces PC LIN Recomendadas

Figura 4. Interfaz LIN NI USB-8476

Se puede comunicar con dispositivos LIN usando la Interfaz LIN USB-8476.

Back to Top

9. Información LIN Adicional

Para más información sobre las especificaciones de LIN, visite el consorcio LIN en www.lin-subbus.org.