Ethernet SOMEIP da Autosar

prefácio

Em primeiro lugar, gostaria de fazer algumas perguntas, você sabe:

• Você sabe o que é SOME/IP?
• Você sabe por que existe SOME/IP, ou seja, antecedentes relacionados?
• Você sabe como o SOME/IP está intimamente ligado ao SOA?
• Como o SOME/IP deve ser usado na prática?

Hoje, vamos explorar e responder a essas perguntas juntos. Para facilitar a compreensão de todos, segue abaixo um esboço dos tópicos deste artigo:

---

texto

Introdução geral

Conforme apresentado no artigo anterior "Introdução aos links Ethernet veiculares ", a pilha de protocolos Ethernet veicular pode ser dividida em cinco camadas, ou seja , a camada física, a camada de enlace de dados, a camada de rede, a camada de transporte e a camada de aplicação . SOME/IP é um protocolo da camada de aplicação .

De acordo com a descrição no AUTOSAR, o conteúdo do protocolo SOME/IP pode ser dividido em três tipos de subprotocolos: o protocolo padrão SOME/IP na camada de aplicação, o protocolo SOME/IP-SD e o protocolo SOME/IP-TP protocolo na camada TP Os conteúdos destas três partes complementam-se, expondo de forma completa e detalhada todo o conteúdo do protocolo SOME/IP, que é a única forma de estudar o protocolo SOME/IP.

Devido ao grande conteúdo do protocolo SOME/IP e às associações complexas, a fim de permitir que todos tenham uma compreensão passo a passo do SOME/IP, este artigo explicará principalmente o protocolo padrão SOME/IP na camada de aplicação devido às limitações de espaço. O conteúdo de outros protocolos continuará a ser dado na próxima parte. Por favor, compartilhem com todos, por favor, prestem mais atenção!

plano de fundo e motivação

Em 2011, a BMW desenvolveu e projetou um conjunto de middleware, que pode realizar o método de comunicação orientado a serviços. Este middleware é diferente do método tradicional de comunicação orientada a sinais. Ele pode não apenas reduzir bastante a carga da rede e melhorar a comunicação entre ambos Eficiência das partes, enquanto a introdução da comunicação Ethernet também pode atender muito às crescentes necessidades de comunicação dos veículos futuros.

A transmissão de dados orientada a sinal sempre será enviada ciclicamente, independentemente de a rede precisar ou não, enquanto o método de comunicação orientada a serviço é diferente. Somente quando houver pelo menos um receptor na rede que precise dos dados, o remetente enviará dados.Vantagens significativas do método de comunicação de serviço.

A BMW chama o método de comunicação orientado a serviços SOME/IP (nome completo: MiddlewarE orientado a serviços escalável sobre IP ). Como o nome sugere, percebe-se que o protocolo está intimamente relacionado à Ethernet, sim! SOME/IP é o middleware executado com base na pilha de protocolos Ethernet do veículo , ou também pode ser chamado de software de camada de aplicativo.

Devido à sua popularidade, o SOME/IP é gradualmente aceito pelo AUTOSAR e está planejado para ser incorporado ao seu padrão oficial e será integrado ao AUTOSAR 4.X ​​​​em 2014. Vários nós de desenvolvimento importantes são os seguintes:

• AUTOSAR 4.0 - Integração preliminar concluída das mensagens BMW SOME/IP;
• AUTOSAR 4.1 - suporte para SOME/IP-SD e sua funcionalidade de publicação/assinatura;
• AUTOSAR 4.2 - Adicionar transformador para serialização e outras otimizações relacionadas;
• AUTOSAR 4.3 - Corrige alguns bugs do transformador e adiciona protocolo SOME/IP-TP para um grande número de pacotes UDP e outras otimizações SOME/IP-SD;
• Otimização contínua. . . . . .

O que é ALGUNS/IP

Como o nome completo de SOME/IP mencionado na seção anterior, vamos usar seu nome completo para entender o que é SOME/IP:

• Escalável

  Uma das intenções originais do projeto do protocolo é alcançar escalabilidade e interoperabilidade entre dispositivos heterogêneos com diferentes plataformas de hardware, diferentes sistemas operacionais ou firmware embarcado e diferentes aplicativos de software.

• orientado a serviço

  Indica que é um protocolo básico orientado a serviços. Os dados são, portanto, trocados em uma configuração cliente-servidor somente quando solicitados pelo cliente ou notificados pelo servidor a um assinante específico, o que garante que a largura de banda nunca seja desperdiçada e os dados sejam comunicados/trocados apenas quando e onde forem necessários.

• Middlewar E

  É também um middleware. Ou seja, está localizado na camada de aplicação e possui sua própria camada de protocolo geral para lidar com operações e aplicações mais específicas;

• sobre IP

  É também um protocolo baseado em Ethernet. Ele usa uma interface de hardware semelhante, garantindo até 100 Mbps de largura de banda. Ao mesmo tempo, os dados são comunicados através do middleware (ou seja, a camada de aplicação) através do cabo de rede usando o protocolo TCP/IP ou UDP.

  Quando um cliente precisa de dados de um servidor, eles podem ser solicitados pelo cliente usando o protocolo TCP. Se o servidor precisar transmitir dados para todos os assinantes ativos, eles podem ser transmitidos via protocolo UDP. A comunicação de dados pelo protocolo UDP pode ser unicast, multicast ou broadcast.

Conforme mostrado na Figura 1 abaixo, mostra claramente a posição de SOME/IP na pilha de protocolos Ethernet automotivo e o relacionamento com outros módulos:

Figura 1 Relação entre SOME/IP e a pilha de protocolos Ethernet do veículo

Portanto, na pilha de protocolos AUTOSAR, qual é a posição do protocolo SOME/IP? Como mostrado abaixo:

Conforme mostrado na figura acima, o protocolo SOME/IP envolve a interação com os módulos padrão AUTOSAR, como RTE, COM, PDUR e SOAd, enquanto o SOME/IP-SD usado para descoberta de serviço envolve a interação com BswM, SD e Módulos SoAd . A relação interativa entre o protocolo SOME/IP e cada módulo será mencionada no próximo artigo. É mencionada aqui para que todos tenham um conceito geral da associação entre o protocolo SOME/IP e a pilha de protocolos AUTOSAR. Este artigo não vai expandir muito.

SOME/IP foi originalmente desenvolvido como um mecanismo RPC alternativo para garantir a compatibilidade com dispositivos AUTOSAR e fornecer a funcionalidade máxima necessária para casos de uso automotivo, e também é uma camada de rede projetada para o protocolo de serialização cliente-servidor inter-ECU.

Atualmente, o protocolo pode ser implementado em vários sistemas operacionais diferentes, incluindo  AUTOSAR, OSEK e GENIVI . Ele também pode ser implementado em firmware embarcado que não executa um sistema operacional.

Dispositivos grandes, como câmeras, hosts, dispositivos telemáticos, dispositivos AUTOSAR e até mesmo sistemas de infoentretenimento, podem trocar mensagens entre ECUs com eficiência usando o protocolo SOME/IP. O suporte SOME/IP tornou-se público desde  o lançamento do Wireshark 3.2  SOME/IP, permitindo a análise de dados SOME/IP no Wireshark.

Para resumir, podemos resumir as características básicas do SOME/IP como um protocolo de comunicação orientado a serviços, um protocolo de camada de aplicação baseado na pilha de protocolos Ethernet do veículo, conforme mostrado na Tabela 1 abaixo. Cinco características básicas do protocolo IP:

Tabela 1 Cinco recursos básicos do protocolo SOME/IP

Relação entre SOME/IP e SOA

SOA

Em suma, SOA é uma arquitetura orientada a serviços ( Service-Oriented Architecture ) e, claro, também é uma forma importante de design de software. A empresa de pesquisa e consultoria de TI Gartner a propôs em 1996. Não é um conceito novo em si, e é popular no campo da Internet de TI há mais de 20 anos.

De acordo com a definição do W3C: "SOA é uma arquitetura de aplicativo na qual todas as funções são definidas como serviços independentes com interfaces chamáveis ​​bem definidas que podem ser chamadas em uma ordem definida. serviços para formar processos de negócios.

Serviço:  Um serviço é uma coleção de informações mais granulares do que um componente.Na verdade, contém uma combinação lógica que implementa vários requisitos de negócios associados e permite que cada serviço use uma plataforma, arquitetura ou solução técnica específica;

Interface chamável:  A interface orientada a serviços é diferente da interface do componente, sua implementação não tem nada a ver com uma linguagem específica ou uma plataforma específica, sendo muito conveniente realizar a interação de diferentes plataformas heterogêneas;

Contato e diferença:

• Em primeiro lugar, deve ficar claro que SOME/IP não é SOA e SOA não é SOME/IP;
• Como o próprio SOME/IP também é um protocolo orientado a serviços, geralmente acredita-se que SOME/IP seja apenas uma escolha de protocolo viável para SOA;
• De um modo geral, tanto a comunicação baseada em mensagens quanto a comunicação RPC (Remote Procedure Call) podem realizar SOA, e SOME/IP é um protocolo baseado na estrutura RPC;
• Pode ser usado para realizar SOA através de SOME/IP, mas a realização de SOA não necessariamente tem que usar SOME/IP;

Análise de protocolo SOME/IP

Em seguida, deixe a manga levar todos a descobrir o mistério de SOME/IP analisando SOME/IP juntos! , de modo a estabelecer uma base sólida para o aprendizado subsequente da Ethernet automotiva.

Identificadores Relacionados e Notas de Lançamento

A Figura 2 abaixo mostra a estrutura do Cabeçalho do protocolo SOME/IP:

Figura 2 Cabeçalho do protocolo SOME/IP

A explicação detalhada da ID da mensagem, ID da solicitação, versão do protocolo e versão da interface marcada na figura acima é mostrada na Tabela 2 abaixo:

Tabela 2 Identificadores relacionados e notas de versão

Comprimento

O comprimento, conforme mostrado na Figura 2 acima, abrange o intervalo desde o início da ID da solicitação até o final da mensagem SOME/IP.

Tipo de mensagem

É utilizado para identificar diferentes tipos de mensagens. Os tipos existentes atualmente são mostrados na Figura 3 abaixo, onde TP representa uma mensagem subcontratada, que é definida da seguinte forma de acordo com o padrão AUTOSAR ( R21-11 ) :

Figura 3 Tabela de tipo de mensagem

Código de retorno

O Código de Retorno é utilizado para indicar se a Mensagem foi processada com sucesso, ou para dar feedback sobre o conteúdo do erro na requisição. A Figura 4 abaixo mostra o tipo de Código de Retorno definido no AUTOSAR ( R21-11 ):

Figura 4 Tabela de definição do código de retorno

Mecanismo de comunicação SOME/IP

Depois de entender a definição detalhada do padrão do protocolo SOME/IP, é necessário discutir quais regras a ECU do veículo precisa seguir para realizar a transmissão de dados. Portanto, a familiaridade com esta parte do conteúdo será essencial para o desenvolvimento e teste do veículo Ethernet SOME/IP importante.

Descoberta de serviço

O mecanismo de comunicação de descoberta de serviço é realizado através do protocolo SOME/IP-SD, principalmente para informar ao cliente a disponibilidade e método de acesso da instância de serviço atual na Ethernet do veículo, que pode ser realizado através de Find Service e Offer Service.

Antes de transmitir dados através do protocolo SOME/IP, precisamos saber quais serviços existem em toda a rede atual de veículos, qual a disponibilidade dos serviços e se o cliente assina os serviços fornecidos pelo servidor.

Uma vez que o protocolo SOME/IP-SD também é uma parte muito importante, não será expandido aqui, mas suas funções básicas e mecanismos serão brevemente apresentados. O conteúdo específico do protocolo SOME/IP-SD será apresentado separadamente posteriormente, então fique ligado!

Conforme mostrado na Figura 5 abaixo, é a função básica do SOME/IP-SD, mostrando a interação entre Cliente e Servidor.

Figura 5 Diagrama de interação entre cliente SOME/IP-SD e servidor

Como pode ser visto na figura acima, o processo de descoberta do serviço SOME/IP pode ser dividido nas três etapas básicas a seguir:

• O cliente busca as instâncias de serviço disponíveis na rede do veículo enviando uma mensagem Find Service;
• Servidor envia resposta de Oferta de Serviço através de UDP após receber Find Server do Cliente;
• O Cliente inscreve-se em Eventos relacionados ao enviar Inscrever-se em Grupo de Eventos;
• O servidor verifica se o cliente atende as condições de assinatura, e se estiver satisfeito, responderá ACK, caso contrário, responderá NACK;
• Após o Cliente se inscrever com sucesso no evento relevante, o Servidor publicará o Cliente que se inscreveu no evento de acordo com os atributos do próprio evento;

Chamada de procedimento remoto (RPC)

As chamadas de procedimento remoto podem ser divididas principalmente em quatro modos de comunicação:

• O modo de comunicação Pedido/Resposta pode ser resumido como um dos Métodos ; seu modelo básico de comunicação é mostrado na Figura 6 abaixo:

  O modelo Request-Response é um dos métodos de comunicação mais comuns.Sua principal tarefa é que o cliente envie as informações da solicitação e o servidor receba a solicitação, execute o processamento relevante e responda de acordo.

Figura 6 Modelo de comunicação de solicitação-resposta

• O modo de comunicação Fire&Forget pode ser resumido como um dos métodos ;

  A principal tarefa desse modelo de comunicação é que o cliente envie uma solicitação ao servidor e o servidor não precise dar nenhuma resposta, o que é semelhante à resposta positiva de supressão no serviço de diagnóstico.

Figura 7 Modelo de comunicação Fire&Forget

• Notificação Modo de comunicação do evento;

  Este modo de comunicação descreve principalmente o conteúdo da mensagem de publicação/assinatura. A tarefa principal é permitir que o cliente assine o grupo de eventos relevante no servidor. Publicar conteúdo atualizado.

Figura 8 Modelo de comunicação do evento de notificação

• Controle de processo remoto (Campo)

  O mecanismo de comunicação do processo de acesso é principalmente para obter dados e modificação para o aplicativo.A principal tarefa é permitir que o cliente obtenha o valor do Servidor através do Getter e defina o valor do Servidor através do Setter.

  Field pode ser entendido como o atributo básico de um Service, que pode incluir Getter, Setter e Notifier de três formas. Entre eles, Getter é um método para ler um valor em Field, Setter é um método para alterar o valor de Field e Notifier é um evento de gatilho quando o valor em Field muda.

  

  Figura 9 Modelo de Comunicação de Campo

Como pode ser visto na figura acima, utilizamos o mecanismo Request/Response na forma de Getter e Setter. Na mensagem de solicitação do Getter é um Payload vazio, o Payload na mensagem de resposta é o valor a ser obtido; ao usar a solicitação do Setter, o Payload na mensagem de solicitação é o valor a ser definido, se a configuração for bem-sucedida, o mensagem de resposta Neste artigo, Payload é o valor para definir o sucesso.

Ao mesmo tempo, também podemos concluir que a entidade de serviço é um conceito muito importante no protocolo SOME/IP. Uma entidade de serviço pode ser qualquer combinação de Field, Events e Method .

Mecanismo de tratamento de erros SOME/IP

Sempre há vários erros em qualquer processo de comunicação, e o SOME/IP não é exceção como um protocolo de aplicativo orientado a serviços. Portanto, para localizar os problemas no processo de comunicação com mais eficiência, a AUTOSAR formulou um mecanismo de tratamento de erros para verificar o conteúdo do formato de protocolo SOME/IP.

Por exemplo, verificação de informações de versão, ID de serviço, etc. Outras informações de falha podem ser definidas em Payload em detalhes. Atualmente, o SOME/IP suporta os dois mecanismos de tratamento de erros a seguir, que podem ser selecionados de acordo com a configuração.

• Tipo de mensagem 0x80, Informação de resposta, ou seja, o problema pode ser localizado através do Código de Retorno na Mensagem de Resposta;
• Tipo de mensagem 0x81, mensagem de erro explícita;

A Figura 10 abaixo mostra o fluxo básico de SOME/IP lidando com erros gerais:

Figura 10 Processo de tratamento de erros SOME/IP

Se você quiser saber mais sobre como implementar o conteúdo da pilha de protocolo SOME/IP, consulte o código-fonte aberto no GitHub liderado pela BMW e procure a palavra-chave " vsomeip " no GitHub para encontrar o código-fonte aberto correspondente código para aprender .

Vale ressaltar que vsomeip é uma pilha de protocolos SOME/IP desenvolvida em linguagem C++ baseada na plataforma Linux.