Linux se suele elegir para el ordenador de un vehículo cuando el terminal forma parte de una máquina dedicada en lugar de una plataforma de aplicaciones móviles genérica. El equipo de software puede necesitar una secuencia de arranque controlada, una interfaz QT personalizada, acceso directo a dispositivos CAN o serie, servicios en segundo plano, registro local y una imagen del sistema que solo se modifique mediante un proceso de ingeniería aprobado.
Un ordenador para vehículos con Linux puede integrarse en interfaces hombre-máquina (HMI), control de maquinaria, guiado, recopilación de datos industriales y proyectos OEM de larga duración. Linux por sí solo no garantiza un comportamiento en tiempo real estricto ni la certificación de seguridad. El tiempo de respuesta depende del kernel, los controladores, la arquitectura de la aplicación, la carga de trabajo y la validación. Los compradores deben definir el tiempo de respuesta requerido y probarlo en el hardware final.
Por qué los equipos de sistemas embebidos eligen Linux en los vehículos.
Con Linux, el equipo de sistemas embebidos puede mantener la terminal enfocada en una sola tarea. Los ingenieros pueden eliminar servicios no utilizados, iniciar la interfaz hombre-máquina (HMI) directamente después del arranque, ubicar los registros donde los técnicos puedan encontrarlos y decidir cómo debe recuperarse el almacenamiento después de un corte de energía repentino. Este nivel de control es valioso, pero también genera trabajo que debe tener un responsable definido.
QT se utiliza habitualmente para crear interfaces gráficas específicas. Una aplicación QT puede mostrar el estado de la máquina, líneas de guiado, alarmas, cámaras o controles del operador sin necesidad de mostrar un entorno de escritorio. La interfaz puede iniciarse automáticamente tras el arranque y restringir el acceso a la configuración técnica.
El control a largo plazo es otro motivo. Un proyecto que se desarrolla durante varios años puede preferir una imagen estable, dependencias documentadas y actualizaciones de mantenimiento programadas, en lugar de cambios frecuentes de plataforma al estilo de los proyectos de consumo. Este beneficio solo se materializa cuando el cliente y el proveedor acuerdan la propiedad del código fuente, las herramientas de compilación, las bibliotecas, la política de actualizaciones y la responsabilidad del soporte.
Linux no es automáticamente en tiempo real.
El término "tiempo real" debe ir acompañado de una cifra. Decir que una pantalla se ve rápida no es lo mismo que demostrar que un evento se procesa en 20 ms, 50 ms u otro límite fijo. Anote el evento, su fecha límite, la carga presente durante la prueba y la respuesta del sistema si no se cumple dicha fecha límite.
Según la respuesta, el diseño puede utilizar un núcleo en tiempo real, planificación por prioridades, núcleos de procesador aislados, un microcontrolador o un controlador de seguridad independiente. En muchos vehículos, la terminal Linux solo gestiona la interfaz hombre-máquina (HMI) y registra los datos, mientras que una unidad de control electrónico (ECU) dedicada continúa ejecutando el bucle de control. Se trata de dos diseños muy diferentes.
Antes de poner un sistema en tiempo real, realice pruebas de temporización con las cámaras activas, el tráfico CAN a la velocidad objetivo, el registro de eventos habilitado, la comunicación de red en funcionamiento y la interfaz gráfica bajo carga. La prueba debe incluir la temperatura, el arranque repetido, el uso del almacenamiento y los periféricos previstos.
Aplicaciones típicas de Linux para ordenadores de vehículos
Interfaz hombre-máquina (HMI) dedicada para la máquina
Una máquina de construcción, agrícola o minera puede requerir una pantalla homologada para los modos de funcionamiento, alarmas, datos de sensores, vistas de cámara e información de servicio. Linux y QT permiten al equipo de software crear una interfaz controlada sin exponer funciones no relacionadas con el usuario.
Puerta de enlace de datos CAN y serie
Como puerta de enlace, el terminal puede escuchar CAN, leer un instrumento RS232 o RS485, recibir datos GNSS, mantener un registro de eventos y enviar registros seleccionados a través de Ethernet o 4G. Contar los puertos no es suficiente. La hoja de especificaciones técnicas también debe registrar la velocidad de transmisión, el aislamiento eléctrico, la terminación, la asignación de pines, quién es el propietario de cada mensaje y si la compilación de Linux expone el controlador necesario.
Terminal de guiado y posicionamiento
Linux puede admitir una interfaz de guiado dedicada que combina el posicionamiento GNSS o RTK opcional con datos de la máquina. La solución completa aún requiere la ubicación de la antena, datos de corrección, gestión de coordenadas, estado de posicionamiento, comunicación con el controlador y una respuesta definida cuando se pierden las correcciones.
procesamiento local en el borde
Algunos proyectos procesan los datos de la cámara o del sensor localmente antes de enviar el resultado a la nube. El procesador, la memoria, el almacenamiento, la GPU y el acelerador necesarios dependen del algoritmo. Ejecute la carga de trabajo real en el hardware de destino en lugar de estimar el rendimiento a partir del nombre del procesador.
Puntos de partida de hardware PDS Linux
Actualmente, PDS ofrece opciones de Linux para los modelos T7 y T12. Por lo tanto, se puede seleccionar un ordenador de sobremesa con Linux, compacto o de pantalla grande, en función de la distribución del habitáculo y la carga de trabajo de las aplicaciones.
| Punto de selección | PDS T7 | PDS T12 |
|---|---|---|
| Mostrar | 7 pulgadas, 1024 x 600, al menos 750 cd/m2 | 12,1 pulgadas, 1280 x 800, al menos 750 cd/m2 |
| Opción de Linux | Linux 4.9 + QT5 | Núcleo de Linux 5.15 + QT5.15 |
| Procesador publicado | Procesador de cuatro núcleos Cortex-A53 de hasta 1,5 GHz | Procesador Cortex-A55 de 8 núcleos con hasta 1,8 GHz. |
| Memoria/almacenamiento publicado | 2 GB / 16 GB | 4 GB / 64 GB, almacenamiento opcional de 256 GB |
| Diseño del operador | Pantalla compacta con cuatro teclas de función frontales. | Gran pantalla táctil para HMI multipanel |
| Interfaces de vehículos publicadas | Conector de extensión, cámara, opciones de antena GNSS/LTE | Dos puertos CAN, dos RS232, RS485, Ethernet, GPIO y cuatro puertos de cámara. |
| Potencia y protección | 9-36 V CC, IP66 | 9-36 V CC, IP66 |
Para una interfaz compacta, el PDS T7 es el primer modelo que analizaremos. Su tamaño reducido y sus cuatro teclas frontales lo hacen ideal para pantallas pequeñas en taxis, camiones ligeros y maquinaria agrícola de menor tamaño. El PDS T12 se ubica en el otro extremo de la lista: ofrece más espacio para una interfaz hombre-máquina (HMI) de mayor tamaño y proporciona las conexiones necesarias para cámaras y datos de maquinaria pesada.
Anota quién suministra y mantiene cada capa de software.
Un prototipo de Linux puede funcionar a la perfección y aun así estancarse antes de la producción porque nadie se puso de acuerdo sobre quién es el propietario de la imagen del software. El proveedor del dispositivo puede esperar que el cliente lo compile; el cliente puede esperar un kernel, controladores e imagen de recuperación actualizados. Es fundamental dejar constancia por escrito de este límite antes de encargar las primeras unidades piloto.
- Versiones exactas del kernel de Linux y de QT.
- Paquete de soporte de la placa, conjunto de herramientas, SDK e instrucciones de compilación.
- Acceso a controladores para CAN, serial, cámara, GNSS, 4G, Wi-Fi, Bluetooth, Ethernet, USB y almacenamiento.
- Cargador de arranque, pantalla de inicio, inicio automático de aplicaciones y dependencias de servicios.
- Acceso de administrador, permisos de usuario, política de shell seguro y credenciales de producción.
- Registro de ubicación, rotación de registros, registros de fallos y diagnósticos remotos.
- Método de actualización de imagen, reversión, medios de recuperación y procedimiento de servicio de campo.
- Propiedad del código fuente y período de soporte para la configuración seleccionada.
Plan para caso de interrupción del suministro eléctrico del vehículo
Un sistema de archivos Linux puede dañarse si se interrumpe la alimentación durante una escritura. La terminal y la aplicación necesitan una estrategia de apagado y recuperación que se ajuste al comportamiento de encendido del vehículo. Pregunte cómo se detecta el ACC, si se puede retrasar el apagado, qué datos deben borrarse y cómo se comporta el dispositivo durante arranques cortos repetidos.
Pruebe la configuración de almacenamiento de producción con la tasa de registro real. Un sistema que escribe archivos de cámara, bases de datos y registros de diagnóstico requiere una estrategia diferente a la de una interfaz hombre-máquina (HMI) simple. Considere particiones de solo lectura, sistemas de archivos con registro por diario, registros limitados, puntos de control de la aplicación y un modo de recuperación según el riesgo del proyecto.
Validar controladores e interfaces como un solo sistema.
Conecte todos los periféricos previstos durante la prueba piloto. Si ambas redes CAN van a funcionar simultáneamente, pruébelas juntas. Para cada dispositivo serie, registre si utiliza RS232 o RS485 y, a continuación, compruebe la velocidad de transmisión, la configuración de pines, la longitud del cable y la terminación. Las cámaras deben desconectarse y volverse a conectar durante la prueba para que el equipo pueda observar cómo se recuperan el orden de inicio, el retardo de la vista previa, la resolución y la grabación.
Para 4G y GNSS, verifique la ubicación de la antena, las bandas del mercado de destino, el comportamiento de la tarjeta SIM, la sincronización horaria, la salida de posicionamiento y la recuperación tras la pérdida de señal. Un controlador que funciona correctamente durante una breve prueba de laboratorio puede presentar un comportamiento diferente tras repetidos ciclos de encendido o un funcionamiento prolongado.
La seguridad y las actualizaciones necesitan un propietario práctico.
Elimine las contraseñas predeterminadas, limite los servicios, proteja las claves de producción y documente el acceso remoto. Decida quién supervisa las vulnerabilidades del software y quién aprueba las actualizaciones. Una imagen estable no debe quedar obsoleta.
Utilice un despliegue por fases. Actualice un pequeño grupo de vehículos, supervise el arranque, la aplicación, las interfaces, los datos y los comentarios de los operadores, y luego amplíe el despliegue. Mantenga una imagen de recuperación y un método claro para volver a poner en servicio un vehículo en caso de que falle la actualización.
Linux o Android: ¿cuál debería usar el proyecto?
Elija Linux cuando el terminal sea un sistema embebido dedicado y mantenido por un equipo especializado, especialmente si el proyecto requiere una interfaz HMI QT personalizada, servicios controlados, integración directa de hardware y una imagen de producto estable. Elija Android cuando el proyecto priorice la interfaz táctil, esté orientado a aplicaciones y sea mantenido por un equipo de desarrollo móvil.
Ambas plataformas son compatibles con aplicaciones para vehículos. La opción más segura es aquella que se adapta al software existente, las habilidades de los desarrolladores, los periféricos, el proceso de actualización y el período de soporte. No elija un sistema operativo solo porque sea común en otro sector.
Preguntas frecuentes
¿Es Linux mejor para el control de vehículos en tiempo real?
No automáticamente. El sistema requiere una temporización definida y una arquitectura probada. El control crítico puede residir en una ECU o microcontrolador dedicado, mientras que Linux gestiona la interfaz hombre-máquina (HMI), el registro de datos y la comunicación.
¿Puede el PDS T12 usar Android y Linux?
La página actual de T12 muestra Android 13 y una configuración opcional con kernel de Linux 5.15 + QT5.15. Confirme la imagen de producción, los controladores, las interfaces y los entregables de soporte exactos antes del desarrollo.
¿Qué modelo es mejor para una interfaz hombre-máquina (HMI) compacta de Linux?
El T7 es el modelo básico más compacto e incluye teclas de función físicas. El T12 se adapta mejor a una interfaz multipanel de gran tamaño, varias vistas de cámara y una mayor conectividad con el vehículo.
Finalice el esquema del sistema antes de elegir la pantalla.
Antes de elegir un ordenador para vehículo con Linux , dibuje un esquema del sistema de una página. Muestre qué se ejecuta en la terminal, qué permanece en la ECU, todas las interfaces conectadas, la ruta de encendido y apagado, el gestor de software y el método de recuperación. Una vez completada esta página, el tamaño de pantalla y la configuración de hardware necesarios suelen ser mucho más fáciles de definir.
Contacte con PDS Technology e indíquenos el diseño de su interfaz hombre-máquina (HMI), sus requisitos de Linux y QT, las expectativas de arranque, la lista de interfaces, el número de cámaras, las necesidades de posicionamiento, las condiciones de alimentación del vehículo, el mercado de destino y la cantidad de producción. Nuestro equipo le ayudará a identificar una configuración T7 o T12 práctica para su evaluación de ingeniería.
Contáctanos
📧Correo electrónico: market@szpds.com
📞Tel:+86 13421822024
🌐Sitio web: www.szpds.com
Descargo de responsabilidad
La información de este artículo es solo de referencia. PDS Technology Co., Ltd. no se responsabiliza de errores, omisiones ni de la idoneidad del contenido para aplicaciones específicas. Las especificaciones del producto están sujetas a cambios sin previo aviso. Los compradores deben verificar todos los detalles técnicos con nuestro equipo antes de usar el producto.
Acerca de PDS Technology
PDS Technology es un fabricante líder de equipos originales (OEM) y diseño y fabricación de equipos originales (ODM) de terminales GNSS RTK de alta precisión y ordenadores para vehículos, que presta servicios a los sectores agrícola, de la construcción, minero, del taxi y de la logística desde 2011.
Con más de 15 años de experiencia en I+D para el sector automotriz, ofrecemos dispositivos robustos y multi-OS (Android/Linux/OpenHarmony) con posicionamiento RTK de precisión centimétrica, protección IP66 y compatibilidad con IA. Nuestras fábricas, con certificación IATF16949, han producido más de 100 000 unidades distribuidas globalmente, lo que representa más del 30 % del mercado chino de terminales de dirección automática para maquinaria agrícola. Exportamos a Japón, Estados Unidos, Reino Unido, Turquía, Rusia y otros países.
