Tecnologia

A transição para o diagnóstico veicular orientado a serviços

A Vector lança uma cadeia de ferramentas com suporte a diagnósticos orientados a serviços, para preparadores independentes acessarem arquiteturas de nova geração.

19PX
Tecnologia

A Vector lança uma cadeia de ferramentas com suporte a diagnósticos orientados a serviços, para preparadores independentes acessarem arquiteturas de nova geração.

O diagnóstico veicular orientado a serviços (SOVD) representa uma mudança fundamental na forma como profissionais independentes de desempenho e engenheiros de diagnóstico interagem com as arquiteturas veiculares modernas. À medida que o setor avança para os veículos definidos por software (SDVs), a dependência tradicional dos Serviços de Diagnóstico Unificados (UDS) sobre a Controller Area Network (CAN) está sendo complementada, e em alguns casos substituída, pela comunicação baseada em API. O lançamento recente de uma cadeia de ferramentas dedicada pela Vector visa fornecer a infraestrutura necessária para essa transição, garantindo que o acesso ao diagnóstico continue viável à medida que a complexidade dos veículos aumenta.

A mudança técnica do UDS para o SOVD

Por décadas, o cenário do diagnóstico foi dominado pela ISO 14229 (UDS). Embora altamente eficaz para a comunicação baseada em sinais, o UDS enfrenta limitações no contexto das plataformas de computação de alto desempenho (HPC) e das redes dorsais Ethernet comuns em EVs modernos e em plataformas ICE de luxo. O diagnóstico veicular orientado a serviços, padronizado pela ASAM SOVD, introduz uma abordagem de API RESTful. Isso permite que as ferramentas de diagnóstico se comuniquem com o veículo usando protocolos padrão da internet, como HTTP e JSON.

A transição não é apenas uma mudança de linguagem, mas de arquitetura. Em uma configuração tradicional, uma ferramenta de diagnóstico precisa conhecer o endereço de memória específico ou o DID (Data Identifier) localizado para solicitar uma informação. Em um ambiente SOVD, o veículo oferece um mecanismo de descoberta de serviços. Isso permite que a ferramenta consulte os “serviços” disponíveis, como monitoramento da saúde da bateria ou calibrações de gerenciamento térmico, sem exigir conhecimento detalhado e de baixo nível sobre o mapa de memória da ECU subjacente. Para o setor independente de tuning, entender essa camada de abstração é fundamental para manter a continuidade do fluxo de trabalho.

A cadeia de ferramentas atualizada da Vector enfrenta essas complexidades ao integrar o suporte a SOVD às suas principais plataformas, incluindo CANoe e Indigo. Isso permite que engenheiros validem os serviços de diagnóstico durante a fase de desenvolvimento e oferece um modelo de como as ferramentas do mercado independente poderão, no futuro, se conectar a esses sistemas. Oficinas de desempenho que querem otimizar seu fluxo de trabalho devem conhecer nosso conjunto avançado de recursos, para entender como as ferramentas atuais fazem a ponte entre protocolos legados e padrões modernos.

Integração da cadeia de ferramentas da Vector e otimização do fluxo de trabalho

A implementação do diagnóstico veicular orientado a serviços exige uma pilha de software robusta, capaz de lidar com comunicação heterogênea. A cadeia da Vector simplifica isso ao oferecer uma interface unificada tanto para o UDS legado quanto para os novos protocolos SOVD. Isso é especialmente relevante para empresas envolvidas em retrofits complexos ou em calibração de desempenho de alto padrão, em que várias gerações de veículos podem ser atendidas ao mesmo tempo.

Uma das principais vantagens da abordagem da Vector é o desacoplamento da aplicação de diagnóstico do protocolo de comunicação subjacente. Quando um técnico inicia uma solicitação de diagnóstico, a cadeia de ferramentas gerencia a tradução entre a solicitação de serviço de alto nível e os frames Ethernet ou CAN específicos exigidos pelo veículo. Isso reduz o risco de erros de comunicação e agiliza a identificação de falhas em arquiteturas complexas e multidomínio. Para empresas que avaliam sua carga atual de diagnóstico, conferir nossos modelos de preço transparentes pode ajudar no planejamento das atualizações de hardware e software necessárias para a compatibilidade com SDVs.

Além disso, a migração para o SOVD facilita o diagnóstico remoto. Como o protocolo se baseia em tecnologias web padrão, ele é naturalmente mais compatível com plataformas de diagnóstico em nuvem. Isso permite sessões de diagnóstico no estilo “over-the-air” (OTA), nas quais um especialista pode analisar os dados do veículo a partir de outro local, sem hardware proprietário especializado em cada ponto de atendimento. Essa flexibilidade é um fator-chave para oficinas independentes que querem ampliar seu alcance de serviço em um mercado cada vez mais digital.

Impacto no desempenho e na calibração independentes

A introdução das cadeias de ferramentas SOVD marca um momento decisivo para o setor independente de tuning. À medida que os fabricantes fecham as arquiteturas E/E, a capacidade de usar interfaces padronizadas e orientadas a serviços pode se tornar o único caminho legítimo para o acesso ao diagnóstico. O envolvimento da Vector no padrão ASAM SOVD garante que as ferramentas disponíveis no mercado estejam alinhadas aos ciclos de desenvolvimento dos OEMs.

Para profissionais de calibração, o SOVD oferece uma forma mais estruturada de acessar dados em tempo real. Em vez de decodificar fluxos brutos de hexadecimal, os usuários podem interagir com dados JSON estruturados, que incluem metadados sobre os valores lidos. Isso reduz a “adivinhação” frequentemente associada à identificação de novos parâmetros em firmwares de ECU atualizados. No entanto, essa mudança também exige um nível maior de letramento em TI na oficina, passando do conhecimento básico de comunicação serial para a compreensão de APIs web e arquitetura de redes.

Para garantir que sua empresa esteja preparada para essas mudanças, recomendamos começar um teste completo das nossas integrações de diagnóstico mais recentes. Isso permite que sua equipe se familiarize com as estruturas de dados em evolução antes que veículos exclusivamente SOVD se tornem presença padrão nas suas baias de serviço. O objetivo é passar de uma postura reativa de diagnóstico para uma abordagem proativa e orientada a serviços, que aproveite todo o potencial do fluxo de dados dos veículos modernos.

Perguntas frequentes

Qual é a principal diferença entre UDS e SOVD?

UDS (Serviços de Diagnóstico Unificados) é um protocolo baseado em sinais, normalmente usado sobre CAN ou DoIP, que exige conhecimento específico de identificadores e endereços de memória. SOVD (Diagnóstico Veicular Orientado a Serviços) usa uma abordagem baseada em API (HTTP/JSON), permitindo a descoberta de serviços e uma interação mais abstrata com as funções do veículo.

O SOVD vai substituir a porta OBD-II?

Embora a porta OBD-II física possa permanecer por conformidade regulatória (principalmente de emissões), o protocolo de comunicação usado por essa porta está migrando para o SOVD baseado em Ethernet, para diagnósticos não relacionados a emissões e para dados de desempenho.

Preciso de hardware novo para as ferramentas Vector SOVD?

O SOVD normalmente exige hardware capaz de comunicação Ethernet de alta velocidade (DoIP). Embora algumas interfaces Vector existentes ofereçam suporte a isso, a cadeia de software (CANoe, Indigo) precisa ser atualizada para a versão mais recente, a fim de lidar com as novas camadas de diagnóstico orientadas a serviços.

O SOVD é mais seguro que o diagnóstico tradicional?

Sim. Como o SOVD se baseia em protocolos web padrão, ele pode incorporar facilmente medidas de segurança consolidadas, como a criptografia TLS e a autenticação baseada em OAuth, tornando-o mais resiliente do que as comunicações tradicionais sem proteção no barramento CAN.

Como o SOVD afeta o tuning?

O SOVD muda a forma como os dados de diagnóstico são lidos e como certas rotinas (como adaptação ou configurações básicas) são acionadas. Ele oferece um ambiente de dados mais estruturado, o que pode simplificar o registro de logs depois que a conexão inicial por API for estabelecida.

Voltar ao blog