
/
February 25, 2026
/
#
Min Read
A maioria dos OEMs que operam nos mercados da UE já conhece a conformidade do Direito de Reparação. O Regulamento de Isenção por Categoria dos Veículos a Motor (MVBER) exige o acesso não discriminatório ao diagnóstico das oficinas de reparação independentes desde 1995. Esta não é uma nova regulamentação que incide sobre a indústria — é uma linha de base estabelecida que moldou a forma como os mercados automóveis europeus operam durante três décadas.
O que mudou foi o veículo. Os veículos definidos por software — com HPCs centralizados, aplicações em contentores, atualizações remotas OTA e fluxos de trabalho de serviço ligados à cloud — estão a tornar as arquiteturas tradicionais de diagnóstico cada vez mais frágeis. As abordagens que satisfazeram tecnicamente os requisitos do MVBER na era das ECUs autónomas e do acesso físico às oficinas estão a lutar para se adaptarem à era SDV.
A verdadeira questão para os OEMs hoje não é se devem fornecer acesso ao diagnóstico — eles já são obrigados a fazê-lo. É se a sua arquitectura de diagnóstico pode realmente fornecer esse acesso de uma forma que seja gerível, segura e operacionalmente valiosa à medida que a complexidade do software do veículo aumenta. O SOVD é a resposta arquitectónica, e os seus benefícios vão muito além da conformidade regulamentar para a forma como os OEMs permitem que os seus revendedores e redes de serviços independentes trabalhem em veículos cada vez mais orientados por software.
O MVBER concede aos OEM uma exclusão de certos requisitos do direito da concorrência da UE - incluindo o direito de operar redes de concessionários franqueados - em troca de uma obrigação clara: as oficinas de reparação independentes devem ter acesso não discriminatório a dados técnicos, ferramentas de diagnóstico e informações de reparação em condições comerciais justas.
Isso significa que os OEMs não podem usar arquiteturas de diagnóstico proprietárias para criar barreiras de acesso de fato que favorecem as redes de revendedores autorizados em vez de reparadores independentes. O acesso deve ser tecnicamente viável, não apenas teoricamente permitido. E à medida que os veículos se tornam mais definidos por software, o 'tecnicamente viabile' é um bar cada vez mais exigente.
Uma ilustração concreta: um grande OEM tem explorado o SOVD especificamente porque a sua solução de diagnóstico proprietária não pode ser implantada na UE na sua forma actual. A questão não é a intenção legal — é a realidade arquitectónica. Os sistemas proprietários concebidos para redes de concessionários criam padrões de acesso que não mapeiam de forma limpa o acesso não discriminatório que o MVBER requer, especialmente à medida que os diagnósticos se deslocam para o software e domínios remotos.
MVBER em resumo
Ativa desde 1995, prorrogada até 2028. Exige que os OEMs forneçam às oficinas de reparação independentes acesso à reparação de veículos e informações técnicas em condições não discriminatórias comparáveis às que recebem as redes de concessionários autorizados. Aplica-se a todos os OEMs que vendem veículos nos mercados da UE, independentemente da sede do OEM.
Os diagnósticos tradicionais foram concebidos em torno de uma arquitectura ECU estável e distribuída. Cada ECU tinha identificadores fixos, ficheiros de descrição estática e uma implementação UDS conhecida. Compliance significava publicar essas interfaces - complexas e imperfeitas, mas viáveis.
Os veículos definidos por software quebram este modelo de várias maneiras:
O resultado é que os OEMs que construíram arquiteturas de diagnóstico adequadas à geração anterior do veículo estão a enfrentar dívidas técnicas agravadas precisamente quando as suas obrigações de serviço e compliance estão a expandir-se.

SOVD - Service-Oriented Vehicle Diagnostics - é uma norma ASAM (progredindo através da ISO como ISO 17978) que define uma API baseada em HTTP/REST para diagnóstico de veículos. Onde os diagnósticos tradicionais exigiam todas as ferramentas para implementar a lógica de comunicação personalizada para cada programa de veículo, o SOVD fornece um contrato de API comum. O conteúdo de diagnóstico - códigos de falha, medições, parâmetros de configuração, estado de actualização de software - é exposto através de pontos de extremidade REST normalizados utilizando JSON, com capacidades auto-descritas através de especificações OpenAPI.
Para OEMs que navegam em obrigações de conformidade da UE e complexidade do serviço SDV simultaneamente, o SOVD aborda ambos através do mesmo investimento em arquitetura.
O SOVD define uma API unificada que funciona em cenários remotos (baseados na nuvem), de proximidade (na loja) e no veículo. Um reparador independente que se conecta na oficina, um operador de frota que monitora remotamente e um engenheiro de suporte OEM que faz pré-triagem antes de uma visita de serviço interagem através da mesma interface lógica - com acesso regido por permissões baseadas em função, não por qual pilha de ferramentas proprietária eles têm.
Para a conformidade MVBER, isso é importante porque a arquitetura suporta inerentemente o acesso não discriminatório. O OEM define níveis de autorização — quem vê o quê — mas a própria interface é padronizada e disponível para qualquer ferramenta autorizada, não bloqueada a um VCI específico do OEM ou cadeia de ferramentas.

Um ponto crítico que vale a pena enfatizar: o SOVD não abre diagnósticos de veículos a ninguém. Os OEMs mantêm o controlo total sobre a autorização através do OAuth 2.0 e do OpenID Connect - os mesmos padrões de segurança utilizados em todo o software empresarial. O controlo de acesso baseado em funções determina exatamente o que cada tipo de cliente pode fazer. Um reparador independente obtém acesso a códigos de falha e rotinas de diagnóstico definidas. Um engenheiro OEM obtém acesso mais profundo às funções de calibração e depuração. Um operador de frota vê dados de saúde e estado.
O que muda não é quem controla o acesso — os OEMs continuam a fazer — mas como esse acesso é gerido. Uma API normalizada, registada e auditável substitui um conjunto fragmentado de integrações proprietárias que são difíceis de governar em escala.
O SOVD não exige a substituição da infra-estrutura ECU existente. Um Adaptador de Diagnóstico Clássico trata da tradução entre pedidos SOVD e comandos UDS para ECUs tradicionais - os sistemas legados continuam a funcionar. Novas aplicações baseadas em HPC podem expor diagnósticos nativamente via SOVD. A ferramenta do reparador independente fala com uma interface; o veículo lida com o roteamento internamente. Isso torna a adoção em fases realista sem um programa de rip-and-replace.

A UN R156 exige que os OEMs mantenham Sistemas de Gestão de Actualizações de Software com provas estruturadas de como as actualizações são planeadas, executadas e validadas. As interações API padronizadas e registradas do SOVD geram essa evidência naturalmente. Inventário de software, verificações de prontidão, validação pós-atualização e logs de auditoria são resultados de operações SOVD normais - não um exercício forense separado montado no momento da revisão de conformidade.
Para além da conformidade, o valor mais profundo do SOVD é o que permite para redes de serviços independentes e de concessionários que prestam serviços a SDVs. É aqui que o ROI operacional se torna concreto.
O suporte central OEM pode aceder aos veículos através do SOVD antes que estes cheguem para assistência - recuperando registos, identificando padrões de falha, configurando a captura de dados de alta resolução e, em muitos casos, resolvendo problemas sem uma visita física. Quando é necessária uma visita à oficina, o técnico chega com contexto, não com uma lousa em branco. As taxas de correcção pela primeira vez melhoram. Substituições desnecessárias de peças diminuem. Os custos da garantia caem.
No veículo definido por software, o perfil de diagnóstico do carro pode mudar a cada atualização OTA. A arquitectura autodescritiva do SOVD significa que as ferramentas do concessionário descobrem as capacidades atuais do veículo em tempo de execução, em vez de depender de bases de dados de descrição estática que podem já estar desatualizadas. Os concessionários trabalham no veículo que existe hoje, não num instantâneo de software de há seis meses.
Uma das principais tensões no direito de reparação sempre foi: como fornecer acesso significativo ao diagnóstico sem expor software de calibração proprietário, código ECU e algoritmos de alto valor? O SOVD resolve isto através do encapsulamento do serviço. A API expõe o que um reparador precisa para diagnosticar e fazer a manutenção do veículo — códigos de falha, valores de medição, rotinas de teste definidas — sem expor a implementação do software subjacente. Os OEMs definem o limite do serviço de diagnóstico; o SOVD o impõe.
Os operadores de frotas representam alguns dos cenários de serviço mais exigentes: contagens elevadas de veículos, operações críticas em tempo de atividade, frotas geograficamente distribuídas. O SOVD permite a monitorização da integridade a nível da frota através da mesma API utilizada para diagnósticos individuais de veículos - agregando padrões de falhas, rastreando versões de software em toda a frota e apresentando necessidades de serviço proactivas antes que se tornem avarias.

Sibros SOVD: Da Avaliação à Produção
A Sibros construiu um completo Oferta SOVD - abrangendo tanto as capacidades do servidor no veículo como as ferramentas de nuvem/back-office - concebidas para OEMs que passam da avaliação da arquitectura para a implementação da produção. A nossa oferta inclui:
O direito da UE à reparação da conformidade tem sido a linha de base há trinta anos. O que está a mudar é o veículo - e com ele, as exigências arquitectónicas de fornecer essa conformidade à escala em frotas definidas por software. Os OEMs que constroem infra-estruturas de diagnóstico em torno do SOVD não estão apenas a resolver um problema de conformidade. Estão a construir a base das operações de serviço para a era SDV.