O Linux costuma ser escolhido para o computador de um veículo quando o terminal faz parte de uma máquina dedicada, em vez de uma plataforma genérica de aplicativo móvel. A equipe de software pode precisar de uma sequência de inicialização controlada, uma interface QT personalizada, acesso direto a dispositivos CAN ou seriais, serviços em segundo plano, registro local de logs e uma imagem do sistema que só pode ser alterada por meio de um processo de engenharia aprovado.
Um computador veicular com Linux pode ser utilizado em IHMs embarcadas, controle de máquinas, sistemas de orientação, coleta de dados industriais e projetos OEM de longa duração. O Linux, por si só, não garante comportamento em tempo real rígido ou certificação de segurança. O tempo de resposta depende do kernel, dos drivers, da arquitetura da aplicação, da carga de trabalho e da validação. Os compradores devem definir o tempo de resposta necessário e testá-lo no hardware final.
Por que as equipes de sistemas embarcados escolhem o Linux em veículos?
Com o Linux, a equipe de sistemas embarcados pode manter o terminal focado em uma única tarefa. Os engenheiros podem eliminar serviços não utilizados, iniciar a interface homem-máquina (IHM) logo após a inicialização do sistema, armazenar logs em locais acessíveis aos técnicos e definir como o armazenamento deve se recuperar após uma queda brusca de energia. Esse nível de controle é valioso, mas também cria tarefas que precisam ter um responsável definido.
O QT é comumente usado para interfaces gráficas dedicadas. Um aplicativo QT pode apresentar o status da máquina, linhas de orientação, alarmes, câmeras ou controles do operador sem exibir um ambiente de área de trabalho. A interface pode iniciar automaticamente após a inicialização do sistema e restringir o acesso às configurações de engenharia.
O controle a longo prazo é outro motivo. Um projeto que se estende por vários anos pode preferir uma imagem estável, dependências documentadas e lançamentos de manutenção programados em vez de mudanças frequentes na plataforma, típicas de produtos para o consumidor final. Esse benefício só se torna evidente quando o cliente e o fornecedor concordam com a propriedade do código-fonte, ferramentas de compilação, bibliotecas, política de atualização e responsabilidade pelo suporte.
O Linux não é automaticamente em tempo real.
O termo "tempo real" precisa ser quantificado. Dizer que uma tela parece rápida não é o mesmo que provar que um evento é processado dentro de 20 ms, 50 ms ou outro limite fixo. Anote o evento, seu prazo, a carga presente durante o teste e a resposta do sistema caso esse prazo seja ultrapassado.
Dependendo da resposta, o projeto pode usar um kernel em tempo real, agendamento por prioridade, núcleos de processador isolados, um microcontrolador ou um controlador de segurança separado. Em muitos veículos, o terminal Linux apenas lida com a interface homem-máquina (IHM) e registra dados, enquanto uma unidade de controle eletrônico (ECU) dedicada continua executando o circuito de controle. São dois projetos muito diferentes.
Antes de ativar o modo de tempo real de um sistema, execute testes de sincronização com as câmeras ativas, tráfego CAN na taxa alvo, registro de dados habilitado, comunicação de rede em execução e a interface gráfica sob carga. O teste deve incluir temperatura, inicializações repetidas, uso de armazenamento e os periféricos esperados.
Aplicações típicas de computadores veiculares em Linux
IHM dedicada para máquinas
Uma máquina de construção, agrícola ou de mineração pode precisar de uma tela homologada para exibir modos de operação, alarmes, dados de sensores, imagens de câmeras e informações de manutenção. O Linux e o QT permitem que a equipe de software crie uma interface controlada sem expor recursos irrelevantes para o consumidor.
Gateway de dados CAN e serial
Como gateway, o terminal pode escutar CAN, ler um instrumento RS232 ou RS485, receber dados GNSS, manter um registro de eventos e enviar registros selecionados via Ethernet ou 4G. Contar as portas não é suficiente. A ficha técnica também deve registrar a taxa de bits, o isolamento elétrico, a terminação, a pinagem, a quem pertence cada mensagem e se a versão do Linux disponibiliza o driver necessário.
Terminal de orientação e posicionamento
O Linux pode suportar uma interface de orientação dedicada que combina posicionamento GNSS ou RTK opcional com dados da máquina. A solução completa ainda precisa de posicionamento de antenas, dados de correção, gerenciamento de coordenadas, status de posicionamento, comunicação com o controlador e uma resposta definida para quando as correções forem perdidas.
Processamento de borda local
Alguns projetos processam dados de câmeras ou sensores localmente antes de enviar o resultado para a nuvem. O processador, a memória, o armazenamento, a GPU e o acelerador necessários dependem do algoritmo. Execute a carga de trabalho real no hardware de destino, em vez de estimar o desempenho com base no nome do processador.
Pontos de partida de hardware PDS Linux
A PDS atualmente oferece opções de Linux para os modelos T7 e T12. Portanto, é possível selecionar um computador veicular Linux compacto ou com tela grande, levando em consideração o layout da cabine e a carga de trabalho do aplicativo.
| Ponto de seleção | PDS T7 | PDS T12 |
|---|---|---|
| Mostrar | Tela de 7 polegadas, resolução de 1024 x 600 pixels, com brilho mínimo de 750 cd/m². | Tela de 12,1 polegadas, resolução de 1280 x 800 pixels, com brilho mínimo de 750 cd/m². |
| opção Linux | Linux 4.9 + QT5 | Kernel Linux 5.15 + QT5.15 |
| Processador publicado | Processador quad-core Cortex-A53 com velocidade de até 1,5 GHz. | Processador Cortex-A55 de 8 núcleos com clock de até 1,8 GHz |
| Memória/armazenamento publicado | 2 GB / 16 GB | 4 GB / 64 GB, armazenamento opcional de 256 GB |
| Layout do operador | Tela compacta com quatro teclas de função frontais | Tela sensível ao toque grande para IHM com vários painéis |
| Interfaces de veículos publicadas | Conector de extensão, câmera, opções de antena GNSS/LTE | Duas portas CAN, duas RS232, RS485, Ethernet, GPIO e quatro portas de câmera. |
| Energia e proteção | 9-36V CC, IP66 | 9-36V CC, IP66 |
Para uma interface compacta, o PDS T7 é o primeiro modelo a ser analisado. Seu corpo menor e quatro teclas frontais se encaixam perfeitamente em telas focadas em táxis, caminhonetes e máquinas agrícolas de pequeno porte. O PDS T12 está no outro extremo da lista: ele oferece mais espaço para uma IHM grande e fornece as conexões necessárias para câmeras e dados de equipamentos pesados.
Anote quem fornece e mantém cada camada de software.
Um protótipo do Linux pode funcionar perfeitamente e ainda assim travar antes da produção porque ninguém concordou sobre quem detém a propriedade da imagem do software. O fornecedor do dispositivo pode esperar que o cliente a compile; o cliente pode esperar um kernel, drivers e imagem de recuperação com manutenção. Defina esses limites por escrito antes que as primeiras unidades piloto sejam encomendadas.
- Versões exatas do kernel Linux e do QT.
- Pacote de suporte da placa, conjunto de ferramentas, SDK e instruções de compilação.
- Acesso do driver para CAN, serial, câmera, GNSS, 4G, Wi-Fi, Bluetooth, Ethernet, USB e armazenamento.
- Carregador de inicialização, tela de apresentação, inicialização automática de aplicativos e dependências de serviço.
- Acesso root, permissões de usuário, política de shell seguro e credenciais de produção.
- Localização dos registros, rotação dos registros, registros de falhas e diagnóstico remoto.
- Método de atualização de imagem, reversão, mídia de recuperação e procedimento de serviço de campo.
- Propriedade do código-fonte e período de suporte para a configuração selecionada.
Plano para interrupção de energia do veículo
Um sistema de arquivos Linux pode ser danificado se a energia for interrompida durante uma gravação. O terminal e o aplicativo precisam de uma estratégia de desligamento e recuperação que corresponda ao comportamento da ignição do veículo. Pergunte como o ACC é detectado, se o desligamento pode ser atrasado, quais dados devem ser apagados e como o dispositivo se comporta durante partidas curtas repetidas.
Teste a configuração de armazenamento de produção com a taxa de registro real. Um sistema que grava arquivos de câmera, bancos de dados e logs de diagnóstico requer uma estratégia diferente de uma interface homem-máquina (IHM) simples. Considere partições somente leitura, sistemas de arquivos com journaling, logs delimitados, pontos de verificação de aplicativos e um modo de recuperação de acordo com o risco do projeto.
Validar drivers e interfaces como um único sistema.
Conecte todos os periféricos planejados durante o teste piloto. Se ambas as redes CAN funcionarem juntas, teste-as simultaneamente. Para cada dispositivo serial, registre se ele usa RS232 ou RS485 e verifique a taxa de transmissão (baud rate), a pinagem, o comprimento do cabo e a terminação. As câmeras devem ser desconectadas e reconectadas durante o teste para que a equipe possa observar como a ordem de inicialização, o atraso na pré-visualização, a resolução e a gravação se recuperam.
Para 4G e GNSS, verifique o posicionamento da antena, as bandas do mercado de destino, o comportamento do SIM, a sincronização de tempo, a saída de posicionamento e a recuperação após a perda de sinal. Um driver que funciona bem durante um breve teste em bancada pode apresentar comportamento diferente após repetidos ciclos de ignição ou operação prolongada.
Segurança e atualizações precisam de um proprietário prático.
Remova senhas padrão, limite os serviços, proteja as chaves de produção e documente o acesso remoto. Defina quem monitora as vulnerabilidades do software e quem aprova as atualizações. Uma imagem estável não deve se tornar uma imagem abandonada.
Utilize a implantação em etapas. Atualize um pequeno grupo de veículos, monitore a inicialização, o aplicativo, as interfaces, os dados e o feedback do operador, e então expanda. Mantenha uma imagem de recuperação e um método claro para retornar um veículo ao serviço caso uma atualização falhe.
Linux ou Android: qual deve ser usado pelo projeto?
Escolha Linux quando o terminal for um sistema embarcado dedicado, mantido por uma equipe especializada em sistemas embarcados, especialmente quando o projeto necessitar de uma interface HMI QT personalizada, serviços controlados, integração direta de hardware e uma imagem de produto estável. Escolha Android quando o projeto for focado em toque, orientado a aplicativos e mantido por uma equipe de desenvolvimento mobile.
Ambas as plataformas são compatíveis com aplicações veiculares. A escolha mais segura é aquela que melhor se adapta ao software existente, às habilidades dos desenvolvedores, aos periféricos, ao processo de atualização e ao período de suporte. Não selecione um sistema operacional apenas por ser comum em outro setor.
Perguntas frequentes
O Linux é melhor para o controle de veículos em tempo real?
Não automaticamente. O sistema precisa de requisitos de temporização definidos e uma arquitetura testada. O controle crítico pode permanecer em uma ECU ou microcontrolador dedicado, enquanto o Linux cuida da IHM (Interface Homem-Máquina), do registro de dados e da comunicação.
O PDS T12 é compatível com Android e Linux?
A página atual do T12 lista o Android 13 e uma configuração opcional com kernel Linux 5.15 + QT 5.15. Confirme a imagem de produção exata, os drivers, as interfaces e os recursos de suporte antes de iniciar o desenvolvimento.
Qual modelo é melhor para uma interface HMI Linux compacta?
O T7 é o modelo de entrada menor e inclui teclas de função físicas. O T12 é mais adequado para uma interface com vários painéis, diversas visualizações de câmera e conectividade veicular mais ampla.
Finalize o esboço do sistema antes de escolher a tela.
Antes de escolher um computador veicular com Linux , faça um esboço do sistema em uma página. Mostre o que roda no terminal, o que permanece na ECU, todas as interfaces conectadas, o caminho de ignição e desligamento, o gerenciador de software e o método de recuperação. Quando essa página estiver completa, o tamanho da tela e a configuração de hardware necessários geralmente se tornam muito menos discutíveis.
Entre em contato com a PDS Technology e nos informe o layout da sua IHM, os requisitos para Linux e QT, as expectativas de inicialização, a lista de interfaces, a quantidade de câmeras, as necessidades de posicionamento, as condições de energia do veículo, o mercado de destino e o volume de produção. Nossa equipe pode ajudar a identificar uma configuração prática para o T7 ou T12 para avaliação de engenharia.
Contate-nos
📧E-mail: market@szpds.com
📞Tel.: +86 13421822024
🌐Site: www.szpds.com
Isenção de responsabilidade
As informações contidas neste artigo são apenas para referência. A PDS Technology Co., Ltd. não se responsabiliza por erros, omissões ou inadequação do conteúdo para aplicações específicas. As especificações do produto estão sujeitas a alterações sem aviso prévio. Os compradores devem verificar todos os detalhes técnicos com nossa equipe antes do uso.
Sobre a PDS Technology
A PDS Technology é uma fabricante líder de OEM/ODM de terminais GNSS RTK de alta precisão e computadores veiculares, atendendo aos setores de agricultura, construção, mineração, táxi e logística desde 2011.
Com mais de 15 anos de experiência em P&D para o setor automotivo, oferecemos dispositivos robustos e multi-SO (Android/Linux/OpenHarmony) com posicionamento RTK de precisão centimétrica, proteção IP66 e desempenho preparado para IA. Nossas fábricas com certificação IATF16949 produziram mais de 100.000 unidades, distribuídas globalmente, e detêm mais de 30% do mercado chinês de terminais de direção autônoma para o setor agrícola. Exportamos para o Japão, EUA, Reino Unido, Turquia, Rússia e outros países.
