Comparando esquemas de auto‑direccionamiento para sistemas de acceso a coche Bluetooth
Los sistemas de acceso a coche Bluetooth Low Energy (BLE) típicamente cuentan con un módulo central y múltiples nodos satélite que comunican sobre un bus Controller Area Network (CAN) o Local Interconnect Network (LIN). Los satélites están estratégicamente colocados alrededor del vehículo para extender el rango BLE.
Los diseñadores buscan streamline fabricación de satélites usando un único diseño PCB y firmware idéntico across todos los nodos. Esta uniformidad, sin embargo, necesita un mecanismo on‑board para que el módulo central asigne direcciones CAN o LIN únicas a cada satélite tras la instalación.
Enfoques cableados tradicionales emplean un LIN daisy‑chain dedicado para distribuir CAN IDs durante fabricación. La interfaz LIN se deshabilita luego para la vida del vehículo. Una alternativa reduce costes BOM reemplazando el bus LIN dedicado con un circuito discreto mínimo. Una opción verdaderamente inalámbrica elimina hardware extra completamente, aprovechando la infraestructura BLE existente para realizar la asignación de direcciones.
Al remover la necesidad de hardware LIN dedicado, el método inalámbrico recorta cableado, BOM y el overhead de stockear y ensamblar componentes innecesarios. Este artículo primero revisa técnicas cableadas de auto‑direccionamiento antes de profundizar en el enfoque inalámbrico.
Los sistemas modernos de acceso a coche adoptan cada vez más BLE para funciones phone‑as‑a‑key o digital‑key. Estos sistemas operan como configuraciones passive‑entry, passive‑start pero reemplazan llaveros tradicionales con el smartphone del conductor. Una configuración típica consiste en un módulo central y seis a doce módulos satélite, cada uno capaz de recibir señales BLE del teléfono o llavero (Figura 1).
Para que el sistema phone‑as‑a‑key desbloquee, el módulo central debe determinar cuándo el smartphone o llavero está dentro de la zona de desbloqueo del vehículo. Esto se logra triangulando señales recibidas por múltiples módulos satélite distribuidos en ubicaciones estratégicas como puertas de pasajero, paneles laterales, maleteros y parachoques.
El módulo central comunica con los satélites vía CAN o LIN. Usando datos de cada satélite, triangula la ubicación del smartphone y decide si conceder entrada. La Figura 2 ilustra una topología de comunicación basada en CAN.
La dirección CAN de cada satélite permite al módulo central identificar la fuente de datos entrantes. Asignar un ID CAN único o dirección a cada satélite es esencial para operación correcta. En lugar de hard‑codear un PCB distinto para cada satélite, fabricantes prefieren un único diseño PCB corriendo el mismo firmware en todos los nodos. Este enfoque reduce complejidad de inventario y permite instalación del mismo módulo en cualquier ubicación del vehículo.
Como todos los satélites son idénticos y sin dirección en la instalación, se requiere un esquema de auto‑direccionamiento post‑instalación.
Auto‑direccionamiento cableado: método LIN daisy‑chain
Actualmente, muchos OEMs usan un bus LIN separado para asignación única de dirección CAN. El módulo central envía una dirección CAN sobre LIN al primer satélite; ese nodo reenvía la siguiente dirección al segundo satélite, y así sucesivamente (Figura 3). Cada módulo requiere dos PHYs LIN —uno para transmisión y uno para recepción— usados solo durante auto‑direccionamiento. Con seis a doce satélites, un vehículo puede necesitar 14 a 26 PHYs LIN, inflando BOM y complejidad.
Auto‑direccionamiento cableado: método single‑wire
Texas Instruments introdujo una alternativa de ahorro de coste que reemplaza los PHYs LIN con un MOSFET y unas pocas resistencias. En este esquema, todos los satélites ignoran el bus CAN hasta que se recibe una señal de despertar en la línea P_IN (Figura 4). El módulo central inicia el proceso pulsando P_IN1 a través de Q1. El primer satélite recibe la señal de despertar, comienza a escuchar el bus CAN y recibe su CAN ID. Tras confirmar recepción, envía la señal de despertar al siguiente satélite, y la secuencia se repite hasta que cada nodo está direccionado.
Aunque este método reduce conteo de componentes, aún requiere una conexión de cableado dedicada entre el módulo central y cada satélite (Figura 5).
Auto‑direccionamiento inalámbrico / reemplazo de cable
Otra solución TI elimina cableado extra completamente usando localización BLE. Durante fabricación o reemplazo de módulo, el módulo central asigna direcciones CAN basadas en distancias medidas (derivadas de RSSI). Satélites más cercanos al módulo central reciben los IDs CAN más bajos, seguidos por módulos progresivamente más lejanos. La ubicación física real no es necesaria; consistencia en distancias medidas garantiza direccionamiento repetible.
Por ejemplo, si las distancias medidas satisfacen d1 < d6 < d5 < d2 < d4 < d3, el módulo central puede asignar confiablemente direcciones 1 a 6. Si dos satélites producen distancias similares, un satélite ya direccionado puede servir como referencia secundaria para diferenciarlos (Figura 7).
Detalles de implementación
En línea con el Generic Access Profile (GAP) de BLE, el módulo central es termed "scanner" y los satélites "advertisers". La capa GAP gestiona descubrimiento de dispositivos, establecimiento de enlace y seguridad. Dos estados clave son:
- Advertiser: Emite advertising data conectable, incluyendo dirección de dispositivo única y nombre opcional.
- Scanner: Escanea advertisements, envía scan requests e inicia conexiones.
Durante auto‑direccionamiento, cada advertiser emite con un identificador aleatorio para prevenir duplicación. El scanner mide RSSI repetidamente, promedia los valores y selecciona el advertiser más cercano. Luego envía un scan request, transmite el mensaje CAN de auto‑direccionamiento y espera acknowledgment. Tras acknowledgment, el advertiser deja de advertiser y procede al siguiente nodo. Este ciclo se repite hasta que todos los satélites están direccionados.
Resultados
Testing empleó el reference design TI Bluetooth Low Energy + CAN satélite y un harness de 12‑ft con ~6‑ft spacing entre conectores (Figura 9). El scanner usó duración de scan de 1‑s con ventana/intervalo 250‑ms; advertisers advertían cada 100 ms. Se tomaron diez muestras RSSI por nodo, y el promedio se usó para estimar distancia.
La Tabla 1 resume delay, fiabilidad y coste de implementación de los tres métodos. El enfoque inalámbrico incurre aproximadamente cinco veces más tiempo de direccionamiento comparado a esquemas cableados, pero ofrece el BOM más bajo y elimina cableado. El rendimiento puede mejorarse refinando parámetros BLE y accounting por variaciones de propagación RF.
Para datos de test single‑wire detallados, refiérase a la guía de referencia del módulo satélite TI car‑access Bluetooth Low Energy + CAN. Al elegir una estrategia de auto‑direccionamiento, considere coste, complejidad de cableado y necesidad de flexibilidad post‑fabricación.
* Para detalles adicionales y resultados de test en el método single‑wire auto‑direccionamiento, consulte la guía de referencia de diseño Texas Instruments car access Bluetooth Low Energy + CAN satélite module.
Referencias
- Especificaciones core Bluetooth
- The Standard for Connection Sets New Standards in Safety, Bluetooth SIG
>> Este artículo fue publicado originalmente en nuestro sitio hermano, EDN.
Incrustado
- Elecciones de diseño Bluetooth Mesh: Módulo vs. Dispositivo discreto
- Cervoz DDR4 Very Low‑Profile SO‑DIMM – Memoria industrial ahorra‑espacio para Intel Coffee Lake y Purley
- NXP lanza chip UWB para convertir smartphones en llaves digitales seguras
- Módulo Bluetooth 5.0 u‑blox BMD‑380 ultra‑pequeño con antena cerámica integrada
- Murata y Google presentan el módulo Edge TPU IA más pequeño: 4 TOPS en chip de 10×15×1,5 mm
- Skyworks presenta FEM integrado 5‑GHz para aplicaciones Wi‑Fi 6
- ams acelera desarrollo de medidores ultrasónicos de agua con módulo IA‑UWM‑2‑GP30‑DN20
- Módulo biosensor compacto OB1203 une frecuencia cardíaca, oximetría de pulso y más para wearables
- Constructores en C#: Tipos, ejemplos y patrones avanzados
- Entendiendo clases anidadas en C#: Definición, uso y herencia
- Dominando la Sobrecarga de Constructores en C#