LIN Bus: cómo funciona y cómo diagnosticarlo correctamente
LIN (Local Interconnect Network) es una red serial de un solo conductor utilizada para sensores y actuadores donde no se necesita el ancho de banda de CAN. Para diagnosticarla correctamente hay que entender quién inicia la comunicación, cómo luce la señal y qué alimentación necesita cada nodo.
Diagnóstico LIN explicado visualmente
Recorre las nueve láminas. Puedes usar las flechas, los indicadores, las teclas ← → o deslizar en el teléfono.
Material técnico Americopp. Los niveles y arquitecturas mostrados son referencias de diagnóstico; siempre confirma el esquema y la especificación OEM del vehículo exacto.
LIN no es CAN: un cable, otra lógica de diagnóstico
LIN utiliza normalmente un solo conductor de datos referido a masa. Es una red de bajo costo y baja velocidad, hasta aproximadamente 20 kbit/s. En documentación BMW son comunes velocidades de 2.4, 9.6 y 19.2 kbit/s según el sistema.
No busques CAN-H y CAN-L. Tampoco esperes dos resistencias terminales de 120 Ω ni una lectura equivalente de 60 Ω. LIN trabaja con polarización pull-up y transceivers de un solo hilo.
Commander y responders: quién habla y cuándo
La terminología moderna de ISO 17987 utiliza commander y responder. Documentación anterior puede usar master y slave/secondary. El commander organiza el tráfico e inicia el intercambio con un header.
El header contiene Sync Break, Sync Field y Protected Identifier (PID). Después viene la respuesta con hasta 8 bytes de datos y un checksum. Si hay header válido pero falta respuesta, enfoca el diagnóstico en el responder, su alimentación, masa, ramal o configuración.
Cómo debe verse eléctricamente la señal LIN
El estado de reposo es recesivo: línea alta, normalmente cercana al voltaje de alimentación. El estado activo es dominante: línea baja, cercana a masa. LIN no es una señal fija de 5 V.
Recesivo / idle / lógica 1: línea alta, próxima a VBAT.
Dominante / lógica 0: línea baja, próxima a GND.
Actividad normal: trenes de pulsos que descienden desde el nivel alto hacia masa.
El multímetro solo muestra un promedio. Una lectura intermedia durante actividad no permite declarar por sí sola que la red está buena o mala; para ver estructura, amplitud y tiempos se usa osciloscopio.
Sleep y wake-up: una línea sin actividad puede estar funcionando
LIN permite modos de bajo consumo. Un cluster puede entrar en sleep y dejar la línea en reposo. Un responder puede solicitar wake-up para reactivar la comunicación.
Antes de diagnosticar “sin señal”, activa el sistema correcto: puerta, espejo, climatizador, terminales o prueba de actuador con ISTA según el circuito. Medir una red dormida y concluir que está averiada es un error frecuente.
Primero alimentación y masa; después condena la red
Un responder LIN no puede contestar si le falta B+, activación o masa, aunque el cable LIN esté perfecto. Verifica batería, fusible, alimentación del commander y responder, caída de tensión de masa, continuidad del conductor LIN y cortos a masa o positivo.
La prueba de caída de tensión sigue siendo clave: tener 12 V en vacío no demuestra que el componente disponga de corriente suficiente durante funcionamiento.
Osciloscopio: la prueba que separa “hay voltaje” de “hay comunicación”
Con un osciloscopio automotriz o aislado, observa el conductor LIN respecto a una masa correcta. Busca un nivel alto estable en reposo y ráfagas de pulsos hacia bajo durante comunicación.
Revisa especialmente: línea permanentemente baja, ausencia de actividad, amplitud insuficiente, nivel dominante demasiado alto, subida lenta a recesivo, ruido, deformación o respuestas faltantes después de headers repetitivos.
Qué significa cada patrón de falla
LIN pegado cerca de 0 V
Posible corto a masa, cable dañado o transceiver/nodo manteniendo el bus dominante.
LIN alto pero sin pulsos
Puede ser reposo normal, commander dormido, falta de alimentación/activación o circuito abierto.
Headers visibles, sin respuesta
El commander está intentando comunicarse. Revisa alimentación, masa, ramal, codificación y responder.
Si al desconectar un responder reaparece la actividad normal, es evidencia importante de que el nodo o su ramal puede estar colapsando la línea. Haz desconexiones solo cuando el procedimiento OEM lo permita.
Aplicación BMW: identifica primero el bus correcto
BMW utiliza LIN en múltiples subsistemas, pero la arquitectura cambia entre generaciones. En algunas plataformas el IBS comunica por LIN; en otras, IBS y otros componentes pueden utilizar BSD. Antes de medir, identifica el protocolo y el ramal exacto en el esquema del vehículo.
Este punto evita uno de los errores más comunes: asumir que un “cable de datos” funciona igual en todos los BMW.
Orden de diagnóstico recomendado
1) identificar vehículo, commander y responders; 2) leer DTC y topología; 3) revisar batería; 4) confirmar B+ y masas; 5) estudiar diagrama y ramales; 6) despertar/activar el sistema; 7) usar el multímetro como prueba preliminar; 8) observar waveform con osciloscopio; 9) decidir si faltan headers o respuestas; 10) aislar el nodo/ramal sospechoso según OEM; 11) reparar, borrar DTC y verificar otra vez.
Errores comunes que debemos evitar
- Buscar 60 Ω como si LIN fuera High-Speed CAN.
- Condenar un responder sin comprobar alimentación y masa.
- Interpretar el promedio del multímetro como una waveform correcta.
- Medir una red dormida y concluir que no hay comunicación.
- Usar una lámpara de prueba convencional directamente sobre una línea de datos.
- Desconectar módulos de seguridad sin seguir procedimiento OEM.
- Asumir que IBS, alternador o sensores usan el mismo protocolo en todas las generaciones BMW.
Conclusión
Diagnosticar LIN exige separar tres preguntas: ¿el nodo tiene alimentación?, ¿el commander está generando headers?, ¿el responder está contestando? Cuando cada una se responde con medición y osciloscopio, una falla LIN deja de ser un código ambiguo y se convierte en una causa demostrable.
Fuentes técnicas: ISO/LIN 2.2A y LIN-CIA; documentación técnica de Microchip sobre capa física y data link LIN; BMW Technical Training sobre sistemas LIN y arquitectura de redes. Siempre prevalecen el esquema, la versión de protocolo y la especificación OEM del vehículo.