O Veículo Agora é Definido por Software? Arquitetura de Domínio e Transformação SDV

Tecnologias de Veículos Elétricos
Autor: Deniz Erkan
Criação: 14 Outubro 2026

A arquitetura que reduz mais de uma centena de unidades de controle a poucos controladores zonais faz com que a identidade do carro agora seja produzida não a partir do aço, mas do código.

Partilhe Esta Página

Sim: o comportamento do automóvel moderno, suas características e seu caráter de desempenho são hoje definidos prioritariamente pelo software. Essa transformação, chamada de veículo definido por software (SDV), leva a arquitetura eletrônica do veículo de pilhas de ECUs para controladores de domínio e zonais, separando hardware e software e remodelando tudo, desde o peso da fiação até as atualizações OTA.

Destaques

Os veículos atuais 100 ou mais unidades de controle; as novas arquiteturas visam reduzir esse número em até 20% .
A arquitetura de domínio organiza por função, a arquitetura zonal por localização física.
Na topologia zonal, CAN XL (até 20 Mbps) e backbones de alta largura de banda como Ethernet gigabit são utilizados.
A atualização OTA é uma capacidade fundamental do SDV, possível graças à dissociação entre hardware e software.
A transição é gradual: a primeira área é o domínio de carroceria (body); ADAS, powertrain e chassi podem permanecer na estrutura atual por mais tempo.

O Que Exatamente É um Veículo Definido por Software?

A definição é clara: veículo definido por software é aquele cuja funcionalidade e comportamento são determinados prioritariamente pelo software, e não pelo hardware. No automóvel tradicional, um recurso era definido por uma peça de hardware produzida especificamente para aquela função; no SDV, o mesmo hardware pode assumir funções diferentes por meio do software que roda sobre ele. Mesmo após a venda do veículo, novos recursos podem ser adicionados, o comportamento pode ser calibrado e falhas podem ser corrigidas remotamente.

As arquiteturas E/E atuais são compostas por 100 ou mais unidades de controle; as estruturas de nova geração proporcionam economias de até 20% no número de unidades de controle e de até 10% em materiais e hardware.
Bosch Mobility, avaliação de arquitetura E/E

Os números desta frase resumem a escala da transformação. O problema não é apenas a quantidade de unidades de controle: cada ECU traz sua própria fiação, sua própria pilha de software e sua própria carga de validação. A visão do SDV é transformar essa estrutura dispersa em um sistema em que o software possa ser gerenciado como uma única camada coerente. Para isso, é necessário redefinir a arquitetura eletrônica desde o início.

Das ECUs à Arquitetura de Domínio: Agrupamento por Função

A época em que cada pequena função de um automóvel tinha sua própria unidade eletrônica de controle (ECU) tornou os chicotes de fiação incontroláveis. A arquitetura de domínio foi a primeira resposta sistemática a isso: organiza a eletrônica do veículo em grandes áreas funcionais como ADAS, infotainment, powertrain, eletrônica de carroceria, chassi e segurança. Cada domínio geralmente possui seu próprio processador, pilha de software, interface de comunicação, sensores e atuadores, e é gerenciado por um controlador de domínio.

Essa estrutura proporcionou uma simplificação considerável em relação ao caos das ECUs. Porém, à medida que o objetivo do SDV crescia, os limites da arquitetura de domínio apareceram. Especialmente os dados de sensores gerados pelas funções autônomas levaram a largura de banda das redes CAN clássicas ao limite. Além disso, cada domínio carregar seu próprio recurso de processamento manteve o chicote de fiação complexo e dificultou o escalonamento do software por todo o veículo.

Arquitetura Zonal: A Organização Passa da Função para a Localização

A arquitetura zonal inverte a lógica: agrupa a eletrônica não por função, mas por localização física no veículo. O veículo é dividido em zonas como dianteira esquerda, dianteira direita, traseira esquerda, traseira direita e cabine; em cada zona, um controlador zonal reúne os sensores, atuadores e a distribuição de energia dessa zona e se comunica com as plataformas centrais de processamento de alto desempenho.

Característica	Arquitetura de domínio	Arquitetura zonal
Princípio de organização	Por função (powertrain, ADAS, carroceria...)	Por localização física (dianteira esquerda, traseira direita...)
Recursos de processamento	Processamento específico por domínio	Processamento centralizado/distribuído consolidado
Cablagem	Feixe de cabos complexo e longo	Cablagem e peso reduzidos
Número de ECUs	Grande quantidade de ECUs	Poucos controladores zonais + computador central
Flexibilidade de software	Difícil de escalar para o SDV	Alta flexibilidade de software

O ganho é concreto e mensurável: o peso do feixe de cabos diminui, as conexões ponto a ponto são reduzidas e o esforço de validação da arquitetura do veículo e dos sistemas é simplificado. Mais importante ainda, os projetos de sensores e atuadores tornam-se independentes do nó central de processamento; assim, os ciclos de atualização de hardware e software se separam, e um projeto de sensor pode ser usado ao longo de várias gerações de veículos.

O Que Faz um Controlador Zonal? Distribuição de Tarefas e Relação com o Hardware

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

A chave da arquitetura zonal é o controlador zonal, responsável por conectar um grande número de atuadores e sensores à ECU central de processamento. Esse controlador não é apenas uma caixa de coleta de dados; ele pode executar ciclos de controle em tempo real em seu próprio processador, gerenciar os dispositivos de sua zona e enviar tráfego filtrado e priorizado ao backbone. Segundo uma avaliação de engenharia da Ti, o MCU do módulo zonal deve oferecer alto desempenho em tempo real, ampla memória, suporte à virtualização para diferentes níveis de ASIL, comunicação de alta velocidade com o backbone e um grande número de interfaces de baixo custo, como CAN FD e LIN.

Como a distribuição de energia se descentraliza?

Na arquitetura de domínio, a energia é distribuída por caixas centrais de distribuição de energia que contêm fusíveis e relés. Na estrutura zonal, a distribuição se descentraliza: um único feixe de energia é puxado da bateria para a zona, e o módulo de zona compartilha a energia entre os módulos dessa região. Cabos de energia curtos significam economia direta de peso e custo. Além disso, os fusíveis são substituídos por fusíveis inteligentes baseados em semicondutores; chaves do lado de alto com característica I²t proporcionam menor variabilidade de fusíveis e seções de cabo mais otimizadas. A caixa inteligente de distribuição de energia, composta pelo MCU, pelas chaves do lado de alto e pelos transceivers, torna-se uma unidade configurada por software: a mesma caixa pode ser usada em cada zona, adaptada conforme a carga.

Separação da E/S física e lógica

O módulo zonal reduz a complexidade da fiação ao combinar as funções lógicas de entrada/saída de vários ECUs num único ponto; as posições físicas dos sensores e atuadores são mantidas. Um passo adiante, os dispositivos de borda tornam-se "inteligentes": o circuito local mantém a informação de estado e executa o diagnóstico de falhas. Protocolos simplificados como o CAN FD Light podem até eliminar a necessidade de um MCU separado em alguns nós de borda. Esta dissociação, em que o hardware permanece fixo e a tarefa é definida por software, é a espinha dorsal de engenharia do SDV.

Barramento de Dados no Veículo Zonal: Largura de Banda, Temporização e Segurança Cibernética

A fusão de sensores e as cargas de trabalho de IA tornam obrigatório construir a topologia zonal sobre espinhaços de alta largura de banda: PCIe, até 20 Mbps CAN XL, que atinge velocidades de dados de até 20 Mbps e mantém a compatibilidade CAN existente, e Ethernet gigabit. O verdadeiro desafio vai além da largura de banda: é a temporização; mensagens curtas de controlo, dados de sensores ADAS e tráfego de infotainment têm requisitos de latência, jitter e sincronização muito diferentes entre si. Em termos aproximados: aplicam-se metas de latência ao nível dos milissegundos para áudio e ao nível dos microssegundos para transmissão de potência e controlo do chassi.

Para transportar estas diferentes classes de tráfego numa única rede, o Networking Sensível ao Tempo (TSN) baseado em Ethernet destaca-se como solução. Normas como a sincronização de tempo (IEEE 802.1AS), modelação de tráfego sensível ao tempo (802.1Qbv), tráfego express (802.3br), preempção de tramas (802.1Qbu) e redundância (802.1CB) garantem latência determinística aos dados críticos. No lado da segurança funcional, o suporte à ISO 26262, vias de comunicação redundantes, partição de segurança e deteção de falhas; no lado da segurança cibernética, a norma ISO/SAE 21434, as regulamentações UNECE e mecanismos de cifragem-autenticação de baixo nível como o MACsec são determinantes. Como a arquitetura zonal centraliza as redes, os métodos de ataque baseados em Ethernet também se tornam aplicáveis; o colapso do conceito de dissociação E/S-processamento em caso de violação de segurança é um risco que deve ser avaliado individualmente.

Como a Dissociação Hardware-Software Torna Possível a Atualização OTA?

A atualização OTA é a primeira característica que vem à mente na maioria das discussões sobre SDV, mas não é uma capacidade por si só; é um resultado arquitetónico. Não é possível fornecer atualizações ininterruptas sem que o software seja desacoplado de chips específicos através da camada de abstração de hardware (HAL) e sem que as funções do veículo sejam divididas em serviços independentes, reutilizáveis e fracamente acoplados (arquitetura orientada a serviços, SOA). O desacoplamento abrange também o isolamento entre si de softwares com diferentes níveis de segurança.

O significado concreto é este: com a arquitetura zone, atualizações OTA/FOTA e conectividade contínua com a nuvem, a manutenção de software de alto nível passa ao controle do fabricante, enquanto os ciclos de controle em tempo real podem ser deslocados para os módulos zone. Ajustes finos, como o reforço de módulos não utilizados em veículos elétricos, também se tornam mais fáceis nessa estrutura. Em última análise, o software do veículo elétrico, além de ser um canal de atualização, é a camada de definição que determina os recursos, os sistemas de segurança e o caráter de desempenho do veículo. O carro começa a se assemelhar a um centro de dados distribuído sobre rodas; a cadeia de valor se apoia no software, no poder de processamento e na arquitetura do sistema.

Qual Será a Velocidade da Transição e a Arquitetura Zonal Será Suficiente Por Si Só?

A transição será gradual. O domínio da carroceria (body), por conter um grande número de ECUs distribuídas de atuadores e sensores, será a primeira área a migrar para a arquitetura zone; a transição do controle de ADAS, powertrain e chassi pode levar mais tempo devido à sua natureza crítica para a segurança. A evolução ocorrida desde 2017 nas camadas MCAL, BSW e de aplicação mostra que isto não é um projeto técnico, mas uma mudança de mentalidade em toda a indústria.

Também é preciso ler com equilíbrio. A arquitetura zonal reorganiza fisicamente o veículo; o lado lógico e de software (SOA, HAL, cibersegurança) precisa ser resolvido separadamente - apenas reorganizar os cabos não torna um veículo definido por software. As estimativas de tamanho de mercado também variam consideravelmente conforme as definições de escopo; os números divergentes relativos ao mercado de arquitetura E/E decorrem de medições diferentes conforme o que é contabilizado (apenas as plataformas de processamento, ou toda a eletrônica distribuída). Além disso, não se deve esquecer que os fabricantes de semicondutores e os provedores de soluções, que são as partes interessadas na transição, têm naturalmente interesse nessa transformação.

A conclusão é um claro equilíbrio de engenharia: a definição do veículo por software só é possível com a existência simultânea de uma nova organização de hardware baseada em controladores de domínio e zonais, camadas de software desacopladas e uma espinha dorsal de dados determinística e segura. A atualização OTA é o fruto mais visível dessa estrutura integrada; a verdadeira revolução está na transferência, pelo hardware do veículo, da definição de sua missão ao software.