Introducción al protocolo de bus LIN

El bus de la red de interconexión local (LIN) y el bus de la red de área de controlador (CAN) son protocolos de comunicación comúnmente utilizados en sistemas automotrices e industriales. Si bien LIN y CAN sirven para propósitos similares, hay diferencias notables en sus arquitecturas y capacidades. 

LIN fue desarrollado para crear un estándar para la comunicación multiplexada de bajo costo y gama baja en redes automotrices. Aunque CAN aborda la necesidad de redes avanzadas de gestión de errores de gran ancho de banda, los costos de hardware y software de la implementación de CAN se han vuelto prohibitivos para dispositivos de menor rendimiento, como elevalunas eléctricos y controladores de asientos. LIN proporciona una comunicación rentable en aplicaciones no críticas donde no se requiere el ancho de banda y la versatilidad de CAN. Puede implementar LIN de manera relativamente económica utilizando el receptor/transmisor asíncrono universal serie estándar (UART) integrado en la mayoría de los microcontroladores de 8 bits de bajo costo modernos.

Las redes automotrices modernas utilizan una combinación de LIN para aplicaciones de bajo costo principalmente en electrónica de carrocería, CAN para comunicaciones convencionales de tren motriz y carrocería, y el bus emergente FlexRay para comunicaciones de datos sincronizadas de alta velocidad en sistemas avanzados como la suspensión activa.  

El bus LIN utiliza un enfoque maestro/esclavo que comprende un maestro LIN y uno o más esclavos LIN.

 
^{Figura 1: Trama de mensaje LIN}

El encabezado del mensaje consiste en una interrupción utilizada para identificar el inicio de la trama y el campo de sincronización utilizado por el nodo esclavo para la sincronización del reloj. El identificador (ID) consiste en un ID de mensaje de 6 bits y un campo de paridad de 2 bits. El ID indica una dirección de mensaje específica, pero no el destino. Tras la recepción e interpretación del ID, un esclavo comienza la respuesta del mensaje, que consiste en uno a ocho bytes de datos y una suma de verificación de 8 bits. 

El maestro controla la secuencia de tramas de mensajes, que se fija en una programación. Puede cambiar el horario según sea necesario. 

Existen varias versiones del estándar LIN. La versión 1.3 finalizó la comunicación de capa de bytes. Las versiones 2.0 y 2.1 agregaron más especificaciones y servicios de mensajería, pero son compatibles a nivel de bytes con LIN 1.3. 

¹Esta característica no es compatible de forma nativa con la API; sin embargo, puede implementar la funcionalidad. 

^{Tabla 1: Comparación de las versiones de LIN 1.3, 2.0 y 2.1}

El bus LIN es un bus sondeado con un solo dispositivo maestro y uno o más dispositivos esclavos. El dispositivo maestro contiene tanto una tarea maestra como una tarea esclava. Cada dispositivo esclavo contiene solo una tarea esclava. La comunicación a través del bus LIN es controlada completamente por la tarea maestra en el dispositivo maestro. La unidad básica de transferencia en el bus LIN es la trama, que se divide en una cabecera y una respuesta. El encabezado siempre es transmitido por el nodo maestro y consta de tres campos distintos: la interrupción, la sincronización (sync) y el identificador (ID). La respuesta, que es transmitida por una tarea esclava y puede residir en el nodo maestro o en un nodo esclavo, consiste en una carga útil de datos y una suma de control. 

Normalmente, la tarea maestra sondea cada tarea esclava en un bucle transmitiendo un encabezado, que consiste en una secuencia break-sync-ID. Antes de iniciar la LIN, cada tarea esclava está configurada para publicar datos en el bus o suscribirse a datos en respuesta a cada ID de encabezado recibido. Al recibir el encabezado, cada tarea esclava verifica la paridad de ID y luego comprueba el ID para determinar si necesita publicar o suscribirse. Si la tarea esclava necesita publicar una respuesta, transmite de uno a ocho bytes de datos al bus seguido de un byte de suma de comprobación. Si la tarea esclava necesita suscribirse, lee la carga útil de datos y el byte de suma de control del bus y toma las medidas internas apropiadas. 

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

La comunicación maestro-a-esclavo se logra mediante una tarea esclava separada en el nodo maestro. Esta tarea recibe automáticamente todos los datos publicados en el bus y responde como si fuera un nodo esclavo independiente. Para transmitir bytes de datos, el maestro debe actualizar primero la respuesta de su tarea interna de esclavo con los valores de datos que desea transmitir. A continuación, el maestro publica el encabezado de trama apropiado, y la tarea esclava interna transmite su carga útil de datos al bus.

^{Figura 2: Trama de mensaje LIN}

1. pausa

Cada trama LIN comienza con la ruptura, que comprende 13 bits dominantes (nominales) seguidos de un delimitador de ruptura de un bit (nominal) recesivo. Esto sirve como aviso de inicio de trama para todos los nodos en el bus.

2. Sync.

El campo de sincronización es el segundo campo transmitido por la tarea maestra en el encabezado. Sync se define como el carácter x55. El campo de sincronización permite a los dispositivos esclavos que realizan la detección automática de la velocidad de baudios medir el período de la velocidad de baudios y ajustar sus velocidades de baudios internas para sincronizarse con el bus.

3. ID

El campo ID es el campo final transmitido por la tarea maestra en el encabezado. Este campo proporciona identificación para cada mensaje en la red y, en última instancia, determina qué nodos de la red reciben o responden a cada transmisión. Todas las tareas esclavas escuchan continuamente los campos ID, verifican sus paridades y determinan si son editores o suscriptores de este identificador en particular. El bus LIN proporciona un total de 64 ID. Los ID 0 a 59 se usan para tramas portadoras de señales (datos), 60 y 61 se usan para transportar datos de diagnóstico, 62 se reserva para extensiones definidas por el usuario y 63 se reserva para futuras mejoras de protocolo. El ID se transmite a través del bus como un byte ID protegido, con los seis bits inferiores que contienen el ID sin procesar y los dos bits superiores que contienen la paridad.

^{Cuadro 2: Método de cálculo de paridad}

4. Bytes de datos

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

5. Suma de verificación

El campo checksum es transmitido por la tarea esclava en la respuesta. El bus LIN define el uso de uno de los dos algoritmos de suma de comprobación para calcular el valor en el campo de suma de comprobación de ocho bits. La suma de comprobación clásica se calcula sumando los bytes de datos solos, y la suma de comprobación mejorada se calcula sumando los bytes de datos y el ID protegido.

La especificación LIN 2.0 define el proceso de cálculo de la suma de comprobación como la suma de todos los valores y la resta de 255 cada vez que la suma es mayor o igual a 256 (a diferencia de módulo-255 o módulo-256). Según la especificación LIN 2.0, la suma de verificación clásica es para usar con nodos esclavos LIN 1.3 y la suma de verificación mejorada es para usar con nodos esclavos LIN 2.0. Precisa además que los números de identificación 60 a 63 utilizarán siempre la suma de control clásica. La interfaz NI LIN proporciona un atributo para establecer el tipo de suma de verificación en clásico o mejorado. El ajuste predeterminado es clásico. Según la especificación LIN 2.0, los ID 60 a 63 siempre utilizan la suma de comprobación clásica, independientemente de la configuración del atributo de suma de comprobación.

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

^{Figura 3: Creación de marcos LIN}

Debido a que el bus LIN es un bus sondeado, al procesamiento de cada trama se le asigna un intervalo de tiempo nominal de la siguiente manera:

Theader_Nominal = 34 * TBit
TResponse_Nominal = 10 * (NData + 1) * TBit
TFrame_Nominal = THeader_Nominal + TResponse_Nominal
Al procesamiento de cada trama se le asigna un intervalo de tiempo máximo como sigue:
Theader_Maximum = 14 * THeader_Nominal
TResponse_Maximum = 1.4 * TResponse_Nominal
TFrame_Maximum = Theader_Maximum + TResponse_Maximum

El bus LIN conecta un único dispositivo maestro (nodo) y uno o más dispositivos esclavos (nodos) juntos en un clúster LIN. El comportamiento de cada nodo es descrito por su propio archivo de capacidad de nodo. Los archivos de capacidad de nodo son entradas a una herramienta de definición de sistema, que genera un archivo de descripción de LIN (LDF) que describe el comportamiento de todo el clúster. 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 maestra del nodo maestro comienza a transmitir encabezados en el bus y todas las tareas esclavas del clúster (incluida la tarea esclava del propio nodo maestro) responden, como se especifica en el LDF.

En términos generales, el LDF se utiliza para configurar y crear el comportamiento de programación del clúster LIN. Por ejemplo, define la velocidad de baudios, el orden y los retrasos de tiempo para la transmisión de encabezados de la tarea maestra, y el comportamiento de cada tarea esclava en respuesta. El hardware de NI LIN y la API de tramas NI-CAN para LIN no proporcionan compatibilidad completa con los LDF de forma nativa, lo que significa que no puede descargar el comportamiento de programación en el hardware. Sin embargo, el soporte de bajo nivel para acceder al bus (escribir encabezados y publicar o suscribirse a respuestas) se proporciona de manera que el usuario pueda crear este comportamiento de programación a nivel de aplicación. Como se mencionó en la descripción para el tipo de trama de entrada de respuesta NI LIN, el hardware NI LIN cuenta con una cola de respuestas para almacenar respuestas de tareas esclavas. La cola de respuestas contiene 64 respuestas, una para cada uno del número máximo de 64 ID especificados para LIN. Esto garantiza que la tarea esclava de interfaz LIN pueda responder a los encabezados dentro del tiempo de respuesta definido por la especificación LIN.

La API NI-CAN Frame para LIN ofrece un medio robusto de interacción completa y de bajo nivel con el bus LIN. Esto proporciona al usuario final la funcionalidad básica a partir de la cual desarrollar aplicaciones complejas que implican el análisis y prototipado de redes LIN. La API de tramas NI-CAN para LIN no admite de forma nativa diagnósticos o configuración, LDF ni tablas de programación de LIN. Sin embargo, puede implementar estas tareas en aplicaciones que utilizan la API de marco NI-CAN para LIN.

La especificación LIN 2.0 establece que la detección de errores debe ser manejada por las tareas esclavas y que no se requiere monitorización de errores por la tarea maestra. La especificación LIN 2.0 no requiere el manejo de múltiples errores dentro de una trama LIN ni el uso de contadores de errores. Al encontrar el primer error en una trama, la tarea esclava aborta el procesamiento de la trama hasta la detección de la siguiente secuencia de sincronización de ruptura (en la siguiente cabecera transmitida por el maestro). Si el atributo log bus errors se establece en true, se registra una trama de error de bus en la cola de lectura. Si el atributo log bus errors se establece en false, ncWriteNet o ncWriteNetMult devuelven un error. 

LIN también proporciona informes de errores a la red. La especificación LIN 2.0 define un bit de estado Response_Error, que el esclavo debe informar al maestro en una de sus tramas transmitidas. Este bit se establece cada vez que una trama recibida o transmitida por un nodo esclavo contiene un error en el campo de respuesta. El bit se borra después de que se transmite en una de las respuestas publicadas del esclavo. La API NI-CAN Frame para LIN no admite de forma nativa el bit de estado Response_Error, pero proporciona al usuario final un medio para implementar fácilmente esta funcionalidad a nivel de aplicación. El procedimiento establece el atributo log bus errors igual a 1 para habilitar el registro de tramas de error de bus en la cola de lectura. A continuación, la aplicación puede monitorear una lectura de una trama de error de bus con el código de error indicando un error en la respuesta. Bajo esta condición, la aplicación puede establecer un bit de estado Response_Error en una variable local. La aplicación puede utilizar el tipo de trama de entrada de respuesta NI LIN para actualizar la cola de respuesta esclava con datos que contienen el bit de estado Response_Error y, a continuación, borrar el bit en la variable local.

LIN cuenta con un mecanismo que permite a los dispositivos entrar en el estado de suspensión y potencialmente conservar energía. Según la especificación LIN 2.0, todos los esclavos pueden ser forzados al modo de suspensión por el maestro enviando una trama de solicitud maestra de diagnóstico (ID=60) con el primer byte de datos igual a cero. Este marco especial se llama el comando go-to-sleep. Los esclavos también entran automáticamente en modo de suspensión si el LIN está inactivo durante más de cuatro segundos. La API NI-CAN Frame para LIN proporciona una gran flexibilidad al permitir al usuario poner la interfaz de LIN en reposo como desee a nivel de aplicación. Al recibir una trama completa que contiene un mensaje de solicitud de suspensión, o una trama inactiva de bus que indica cuatro segundos de inactividad de bus, el usuario puede elegir poner la interfaz LIN en suspensión estableciendo el atributo LIN Sleep en TRUE.

LIN también ofrece un mecanismo para activar dispositivos en el autobús. La activación es una tarea que puede ser iniciada por cualquier nodo en el bus (un esclavo, así como el maestro). Según la especificación LIN 2.0, la solicitud de reactivación se emite forzando al bus a ser dominante durante 250 μs a 5 ms. Cada esclavo debe detectar la solicitud de activación y estar listo para procesar encabezados dentro de 100 ms. El maestro también debe detectar la solicitud de activación y comenzar a enviar encabezados cuando los nodos esclavos estén listos (dentro de 100 ms a 150 ms después de recibir la solicitud de activación). Si el maestro no emite encabezados dentro de 150 ms después de recibir la primera solicitud de activación, entonces el esclavo que solicita la activación puede intentar emitir una segunda solicitud de activación (y esperar otros 150 ms). Si el maestro todavía no responde, el esclavo puede emitir la solicitud de activación y esperar 150 ms por tercera vez. Si aún no hay respuesta, el esclavo debe esperar 1,5 segundos antes de emitir una cuarta solicitud de activación. La API de tramas NI-CAN para LIN permite realizar la activación de acuerdo con la especificación LIN 2.0 independientemente de si la interfaz LIN está operando como maestra o esclava.

La especificación LIN 2.0 clasifica además las tramas LIN en seis tipos:

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

Es importante tener en cuenta que las diferencias en estos tipos de tramas se deben a la sincronización de cómo se transmiten o al contenido de los bytes de datos. Independientemente de la clasificación de tramas, una trama LIN completa siempre consiste en una cabecera transmitida por la tarea maestra y una respuesta transmitida por una tarea esclava. La API de tramas NI-CAN para LIN puede abordar las necesidades de manejo de cada uno de estos tipos de tramas especificadas por LIN. El tipo de marco incondicional es el más utilizado. Las tramas incondicionales llevan señales (datos), y sus identificadores caen en el rango de 0 a 59.

El tipo de trama activada por evento intenta conservar el ancho de banda del bus solicitando una respuesta de trama incondicional de varios esclavos dentro de un intervalo de tiempo de trama.

El fotograma activado por evento puede tener un ID en el rango de 0 a 59. Cada esclavo que potencialmente podría responder al ID de encabezado activado por evento tiene su primer byte de datos cargado con el ID protegido al que respondería si el maestro le estuviera consultando por una trama incondicional. El fotograma activado por evento funciona de la siguiente manera. El maestro escribe un ID activado por evento en un encabezado. Los esclavos pueden responder solo al ID activado por evento si sus datos se han actualizado.

Si solo un esclavo publica una respuesta, entonces el maestro la recibe y, al mirar el primer byte de datos, sabe de qué esclavo (a través del ID protegido) se recibió. Si varios esclavos publican una respuesta, se produce una colisión, que la tarea del esclavo del dispositivo maestro informa como un error de bus. A continuación, el dispositivo maestro consulta una respuesta de cada esclavo utilizando tramas incondicionales. 

Las tramas esporádicas intentan proporcionar cierto comportamiento dinámico al LIN. Siempre llevan señales (datos), y sus identificaciones van de 0 a 59. La cabecera de una trama esporádica debe enviarse solo en su ranura de trama cuando la tarea maestra sepa que se ha actualizado un valor de datos (señal) dentro de la trama. Este requisito hace que la tarea de esclavo de dispositivo maestro sea el editor normal de respuestas de fotogramas esporádicas.

Las tramas de diagnóstico siempre tienen ocho bytes de datos de longitud y siempre llevan datos de diagnóstico o configuración. Sus ID son 60 para una trama de solicitud maestra o 61 para una trama de respuesta esclava. Los marcos definidos por el usuario, que tienen un ID de 62, pueden llevar cualquier tipo de información. Las tramas reservadas tienen un ID de 63 y no deben usarse en un clúster de LIN 2.0.

NI-XNET LIN

La línea de productos NI-XNET es una combinación de interfaces aceleradas CAN, LIN y FlexRay; un controlador optimizado; API fáciles de usar; y utilidades de configuración y depuración. Con las interfaces NI-XNET, puede desarrollar aplicaciones para crear prototipos, simular y probar redes CAN, LIN y FlexRay de forma más rápida y sencilla en NI LabVIEW y LabVIEW Real-Time, así como en C/C++.

Las interfaces NI-XNET PCI/PXI y C Series LIN también cuentan con soporte LDF integrado, programación cronometrada por hardware para tareas maestras y comunicación de tramas y señales. 

^{Figura 4: Plataforma NI-XNET para CAN, LIN y FlexRay}

NI USB LIN

^{Figura 5: NI USB-8506 LIN Interfaz}

También puede comunicarse con dispositivos LIN utilizando un dispositivo USB LIN Interface. Esta es una solución móvil de menor costo para comunicarse con redes LIN.