Descoberta na Automação de Integração Acelera Desenvolvimento de Controlo para Veículos Elétricos
Num domínio onde milissegundos podem significar a diferença entre desempenho ideal e atrasos no sistema, a corrida para simplificar o desenvolvimento de veículos elétricos (VE) nunca foi tão urgente. À medida que a eletrificação remodela o panorama automóvel, os engenheiros enfrentam uma pressão imensa — não apenas para inovar mais rapidamente, mas para o fazer de forma fiável, segura e em escala. Neste contexto, uma nova metodologia, recentemente revelada num estudo publicado no Journal of Chongqing University of Technology (Natural Science), está a atrair séria atenção tanto dos meios académicos como industriais pela sua promessa de reduzir o tempo de desenvolvimento, diminuir erros humanos e standardizar a integração de lógica de controlo complexa em hardware do mundo real.
O cerne da inovação é uma fusão perfeita entre o design de estratégias de controlo de alto nível e a configuração de drivers embebidos de baixo nível — dois domínios que historicamente permaneceram teimosamente fragmentados. Tradicionalmente, o desenvolvimento de uma unidade de controlo do veículo (VCU), o “cérebro” por trás de qualquer veículo elétrico puro, segue um fluxo de trabalho em modelo-V: os engenheiros projetam a lógica de controlo da camada de aplicação (por exemplo, arbitragem de binário, lógica de mudança de mudanças), simulam-na extensivamente, geram código automaticamente (frequentemente via MATLAB/Simulink) e, depois, ligam manualmente essa lógica aos drivers de hardware subjacente — codificados separadamente para microcontroladores como as séries STM32. Este passo final de integração, repleto de incompatibilidades de variáveis, desvios de versão e erros de digitação, tem sido um longo estrangulamento.
A abordagem recentemente proposta muda radicalmente este paradigma. Em vez de gerar código de aplicação e código de driver em ambientes dissociados, a equipa — liderada por Huan Shen, Jianguo Mao, Fuliang Zhou, Wei Chen e Zhiwei Yan da Faculdade de Engenharia de Energia e Potência da Universidade de Aeronáutica e Astronáutica de Nanjing — demonstrou um fluxo de trabalho totalmente co-simulado e co-gerado. O seu método aproveita duas ferramentas estreitamente acopladas da STMicroelectronics e da MathWorks: STM32CubeMX e STM32-MAT/TARGET, sendo esta última um pacote de integração oficial do Simulink que traduz configurações de periféricos a nível de chip em blocos do Simulink do tipo drag-and-drop.
Pense nisto da seguinte forma: no passado, construir uma VCU moderna era como montar um carro desportivo de alta performance em duas garagens separadas — uma para o motor e transmissão, outra para o chassi e eletrónica — com engenheiros a deslocarem-se constantemente entre elas, na esperança de que os pontos de montagem e os feixes de cabos coincidissem. Agora, com este fluxo de trabalho, é como se todo o veículo saísse de uma única linha de montagem sincronizada — motor, ECU, sensores e atuadores, todos modelados, simulados e compilados num ambiente unificado.
As implicações são substanciais — não apenas para a eficiência, mas para a segurança e escalabilidade.
Vamos desconstruir como isto se materializa na prática. Os investigadores selecionaram o STM32F407ZGT6, um microcontrolador ARM Cortex-M4 de 32 bits amplamente utilizado em prototipagem automóvel e ECUs de produção de gama média. Em vez de escrever código C ao nível de registos para conversores analógico-digitais (ADCs), entradas/saídas de uso geral (GPIOs) ou comunicação UART, configuraram primeiro todos os periféricos de hardware — atribuição de pinos, árvores de clock, taxas de amostragem, prioridades de interrupção — visualmente dentro do STM32CubeMX. Uma vez exportada, essa configuração foi automaticamente importada para o Simulink como uma biblioteca de blocos prontos a usar: ADC_Read, GPIO_Read, UART_TX, e assim por diante.
Estes blocos não eram stubs ou marcadores de posição; eram representações funcionalmente precisas dos drivers de hardware reais. Isso significou que, quando a equipa construiu a sua lógica da camada de aplicação — abrangendo funções críticas como a sequência de arranque/paragem do veículo, gestão do estado das mudanças, interpretação dos sinais dos pedais e arbitragem de binário — pôde ligar entradas de sensores reais (por exemplo, posição do pedal do acelerador, estado do travão, sinais do seletor de mudanças) diretamente a blocos algorítmicos dentro do mesmo ambiente de modelação. Chegou ao fim o adivinhar tipos de dados ou fatores de escala. Chegou ao fim o desalinhamento de tamanhos de buffer ou as chamadas de inicialização omitidas.
Um aspeto particularmente elegante da estratégia reside na forma como lida com o sequenciamento de estados — um aspeto notoriamente complexo do controlo de VEs. Considere o processo de arranque do veículo. Este deve seguir uma ordem estrita de “tensão baixa primeiro, depois tensão alta” para evitar arcos elétricos catastróficos ou danos em componentes eletrónicos sensíveis, como o sistema de gestão de bateria (BMS) ou o inversor do motor. Nos fluxos de trabalho convencionais, esta sequência seria codificada proceduralmente: uma série de verificações if-else, triggers de temporizador e toggles de flags — difícil de visualizar, ainda mais difícil de verificar.
Aqui, a equipa modelou os fluxos de energia de arranque/paragem como máquinas de estados embebidas no Simulink, com transições governadas não apenas por condições lógicas, mas por sinais de hardware em tempo real puxados da camada virtual de driver. Por exemplo, quando o sinal GPIO simulado “KEY_ON” passava a alto, o modelo acionava a VCU para acordar o BMS (via um sinal virtual CAN ou discreto), aguardava por um handshake “BMS_OK” (simulado como uma constante 0 neste protótipo) e depois comandava o relé de pré-carga. O sistema monitorizava continuamente uma “tensão do controlador” simulada (alimentada por um bloco ADC que mimetizava uma leitura de um divisor de tensão) e só fechava o contactor principal uma vez que a diferença de tensão entre o controlador e a bateria caía abaixo de 15 volts — espelhando a lógica de pré-carga do mundo real.
Criticamente, isto não era apenas teatro de simulação. Após o modelo completo — lógica de aplicação entrelaçada com drivers de hardware — estar montado, a equipa usou o Real-Time Workshop (RTW) do Simulink para gerar automaticamente um projeto completo em C, pronto para compilar para o Keil µVision (um IDE de desenvolvimento ARM padrão). Nos bastidores, o MATLAB invocava o STM32CubeMX via automação COM, garantindo que o código gerado permanecia perfeitamente sincronizado com a camada de abstração de hardware (HAL) configurada. Sem edição manual. Sem incompatibilidades de copiar-colar. Um clique, uma base de código coerente.
Depois, veio o teste real: a implementação.
Os investigadores construíram uma bancada de testes semifiísica. Potenciómetros mecânicos fizeram as vezes dos pedais do acelerador e do travão. Botões táteis imitaram posições da chave (OFF/ON/START) e seletores de mudanças (D/N/R). Estes alimentavam sinais analógicos e digitais reais nos pinos físicos da placa STM32 — sem entradas simuladas aqui. Entretanto, um PC anfitrião baseado em LabVIEW monitorizava a telemetria UART transmitida a partir da VCU, registando em tempo real timestamps, flags de estado, pedidos de binário e leituras de tensão.
Os resultados foram impressionantes — não porque a VCU executasse funções novas, mas porque executou funções conhecidas de forma impecável e previsível desde o primeiro arranque.
Numa sequência de testes, aos 1,3 segundos, o botão “KEY_ON” foi premido. Dentro de milissegundos, a VCU acionou o sinal de despertar do BMS e fechou o relé de pré-carga (PreRelay = 1). À medida que o operador rodava lentamente o potenciómetro de “tensão do controlador”, o sistema manteve-se em modo de pré-carga — à espera — até que a tensão simulada atingiu 85 V (contra um pacote de baterias fixo de 100 V), altura em que, precisamente como projetado, o relé de pré-carga abriu (PreRelay = 0) e o relé principal fechou (MainRelay = 1). Arranque de baixa tensão concluído.
Depois, aos 3,9 segundos, “KEY_START” foi accionado. A VCU ativou o controlador do motor (MCU_Enable = 1), verificou a ausência de falhas e ativou o conversor DC/DC. O sistema entrou em modo “Pronto” — luzes acesas, sem erros, trem de força preparado. Todas as transições corresponderam aos tempos e dependências lógicas esperados. Sem passos omitidos. Sem condições de corrida.
Ainda mais reveladora foi a simulação de condução dinâmica. Aos 1,2 segundos, o seletor de mudanças moveu-se de Neutro para Condução (Drive). A VCU confirmou que a velocidade do veículo estava abaixo de 8 km/h (uma condição de segurança para o engate em frente) e autorizou a mudança. Depois, aos 1,4 segundos, o acelerador foi pressionado a 30% — e o binário aumentou suavemente, iniciando o movimento em frente no modelo de dinâmica simulado.
O verdadeiro teste de stress surgiu aos 2,3 segundos: uma mudança direta de Condução para Marcha-atrás (Reverse) enquanto o veículo ainda se deslocava para a frente a 5 km/h. A sabedoria convencional — e muitas ECUs de produção — rejeitariam isto por inseguro. Mas a equipa tinha explicitamente codificado uma permissão de mudança bidirecional a baixa velocidade (≤8 km/h) para melhorar a maniobrabilidade urbana sem comprometer a segurança. E o sistema cumpriu: o binário inverteu o sinal, começou a desaceleração, a velocidade caiu para zero e o movimento de marcha-atrás começou — sem falhas, sem desengates.
Depois, o momento decisivo: aos 5,0 segundos, o pedal do travão foi pressionado. Instantaneamente — dentro do mesmo ciclo de controlo — o comando de binário caiu para zero, independentemente da posição do acelerador. Esta “sobreposição de prioridade ao travão” é um requisito de segurança não negociável, mandatado globalmente. O facto de ter sido accionada imediatamente, mesmo durante uma aceleração agressiva, validou não apenas a lógica, mas o determinismo em tempo real do código auto-gerado. Mais tarde, aos 18,2 segundos, outra aplicação do travão sobrepôs-se a uma entrada de aceleração total com fiabilidade idêntica — um comportamento essencial para intervenções de emergência.
O que se destaca não é IA reluzente ou hardware exótico. É disciplina. É a eliminação do modo de falha mais evitável no desenvolvimento automóvel embebido: o erro de transcrição humana. Quantos recalls no campo tiveram origem num erro tipográfico num fator de escala de um sinal CAN? Da inicialização omitida de um watchdog timer? De uma incompatibilidade de versão entre uma atualização de algoritmo e a sua dependência HAL?
Este trabalho contorna esses riscos por design. Quando o modelo do Simulink é a especificação, e o código é o modelo — compilado por completo, sem intervenção manual — o caminho do conceito ao silício torna-se auditável, repetível e certificável. Isto é música para os ouvidos dos engenheiros de segurança funcional que trabalham sob a ISO 26262. A rastreabilidade melhora. A cobertura de testes torna-se mais significativa. A reutilização de modelos entre plataformas de veículos — por exemplo, de um VE citadino para uma furgoneta comercial ligeira — torna-se exequível sem semanas de trabalho de reintegração.
Veteranos da indústria notarão paralelos com a visão da AUTOSAR de uma arquitetura de software em camadas e standardizada. Mas, enquanto a adoção total da AUTOSAR permanece dispendiosa e complexa para OEMs mais pequenos ou startups, este caminho Simulink + STM32-MAT/TARGET oferece um meio-termo pragmático: rigoroso o suficiente para funções de segurança crítica, mas suficientemente acessível para prototipagem rápida e investigação académica.
Claro, o artigo reconhece que o seu âmbito é uma prova de conceito. Os sinais de falha foram hardcoded (BMS_Fault = 0, VCU_Fault = 0), simplificando a validação. Veículos reais têm de lidar com dezenas de flags de falha assíncronas, curvas de derating térmico, monitorização de isolamento e estratégias de recurso — camadas ainda não modeladas aqui. E, embora o desempenho em tempo real tenha sido verificado num MCU representativo, a escalabilidade para processadores multi-core ou arquiteturas time-triggered (por exemplo, para sistemas ASIL-D) exigiria uma integração mais profunda com schedulers de RTOS e unidades de proteção de memória.
Os próprios autores apontam para o próximo passo lógico: validação conjunta hardware-in-the-loop (HIL). Comparar a saída do código embebido auto-gerado com a simulação offline original do Simulink — não apenas em lógica, mas em fidelidade temporal — permitiria quantificar o jitter, o tempo de execução no pior caso (WCET) e a latência de interrupção sob carga. Esses dados são essenciais antes da implementação em produção.
Ainda assim, a base é sólida. E o seu timing não podia ser melhor.
Considere as tendências macro: as startups de VEs enfrentam exigências brutais de eficiência de capital. As OEMs tradicionais lutam para recapacitar milhares de engenheiros versados na lógica da combustão interna. Os organismos reguladores apertam o escrutínio sobre a segurança definida por software. Neste ambiente, ferramentas que comprimem os ciclos de desenvolvimento sem sacrificar o rigor não são apenas convenientes — são existenciais.
Já se ouvem rumores que sugerem que grandes fornecedores Tier-1 estão a testar fluxos de trabalho semelhantes. Alguns estão a estender o paradigma para além das VCUs — para a gestão de baterias, sistemas térmicos, até mesmo controladores de direção by-wire. O fio condutor? Manter o modelo como autoridade. Deixar a máquina escrever o código.
Isto substituirá o assembly otimizado manualmente para o controlo de motor de ultra-baixa latência? Improvável. Haverá sempre um lugar para o artesanato embebido de nível artesanal na vanguarda do desempenho. Mas para a vasta maioria das funções de controlo do veículo — gestão de estado, arbitragem de sinal, transições de modo, sequenciação de diagnósticos — este nível de automação não é apenas viável. Está a tornar-se na melhor prática.
De volta a Nanjing, a configuração do laboratório pode parecer modesta: uma placa de ensaios, alguns potenciómetros, um portátil a correr LabVIEW. Mas o que representa é muito maior: uma revolução silenciosa em como nascem os veículos inteligentes — não em silos fragmentados de código e hardware, mas como sistemas unificados e auto-consistentes, verificados antes que a primeira soldadura arrefeça.
À medida que a eletrificação acelera, o estrangulamento já não é a química da bateria ou a topologia do motor. É a capacidade de engenharia. Métodos como este não poupam apenas semanas de dores de cabeça de integração — libertam espaço cognitivo para os engenheiros se focarem no que verdadeiramente diferencia os veículos: a sensação de condução, a nuance da recuperação de energia, as estratégias térmicas adaptativas, a resiliência a atualizações over-the-air. A experiência, não a canalização.
E numa indústria onde a lealdade à marca agora depende da responsividade do software tanto como da dinâmica do chassi, essa mudança de foco pode revelar-se decisiva.
Uma nota final: o DOI do artigo — 10.3969/j.issn.1674–8425(z).2023.05.002 — não é apenas uma nota de rodapé de citação. É um ponto de referência. Um marcador na transição de “código como arte” para “código como artefacto contínuo e verificado”. Para os desenvolvedores que lutam diariamente com o desvio de integração e a dívida de testes, vale a pena guardá-lo.
Porque o futuro do controlo do veículo não será escrito linha a linha em C. Será modelado, simulado e gerado — de ponta a ponta — com confiança. E esse futuro, graças a trabalhos como este, já está na pista de testes.
Huan Shen, Fuliang Zhou, Jianguo Mao, Wei Chen, Zhiwei Yan, Faculdade de Engenharia de Energia e Potência, Universidade de Aeronáutica e Astronáutica de Nanjing, Journal of Chongqing University of Technology (Natural Science), DOI: 10.3969/j.issn.1674–8425(z).2023.05.002