ISO 11783-5 – para Gerenciamento de Rede (Network Management)

Este post faz parte da série O Pilar Para Construir Aplicações ISOBUS. Leia também os outros posts da série:

Dando continuação na série sobre o pilar para construir aplicações, no artigo de hoje falaremos sobre a ISO 11783-5 que trata sobre o gerenciamento de rede. Aqui o leitor irá encontrar as seguintes informações.

  • Como deve ser montado o nome (isobus NAME) da função de controle (CF) da ECU (Electronic Controller Unit).
  • Processo de como a ECU deve se apresentar na rede ISOBUS para reivindicar um endereço (Address Claim).

Requisitos

  • Uma ECU pode possuir mais que uma funcionalidade, portanto poderá ter mais que um NAME e para cada NAME um device address.
  • Uma ECU pode ser do tipo Endereço não-configurável (Non-Configurable-Address), nestes casos ela possui maior prioridade durante o processo de reivindicação de endereço (bit MSB do NAME é setado para 1). Este tipo de ECU é permitido na ISOBUS para garantir o funcionamento de dispositivos J1939 e equipamentos ISOBUS antigos (retro compatibilidade).
  • Uma ECU pode ser do tipo Endereço autoconfigurável (Self-Configurable-Address), nestes casos a ECU possui tratativas para reivindicar um novo endereço em caso de perda de endereço para uma ECU de maior prioridade. As ECUs em conformidade com a ISO 11783 devem ser deste tipo.

O que é e Como Definir um NAME

O NAME possui 64 bits e entre os seus diversos campos é definido qual é a funcionalidade do dispositivo na rede. O fabricante do dispositivo deve garantir que o NAME seja único. Veja na figura abaixo como é formado o NAME.

ISO 11783-5
Figura 1 – Os Campos do NAME

  • Endereço autoconfigurável (Self-configurable address) – Se igual a 1 indica que a ECU é autoconfigurável.
  • Grupo da Indústria (Industry Group) – Definido e atribuído pela ISO. Informa a qual tipo de indústria a CF pertence, por exemplo, equipamentos agrícolas.
  • Instância de categoria de dispositivo (Device Class Instance) – Determina a instância da classe do dispositivo em uma rede.
  • Categoria do dispositivo (Device Class) – Definida e atribuída pela ISO. Especifica o tipo do dispositivo, por exemplo, pulverizador.
  • Função (Function) – Definida e atribuída pela ISO. Especifica qual é a função da CF dentro da categoria do dispositivo, por exemplo, controlador de fluxo de pulverização.
  • Instância de função (Function Instance) – Determina a instância de função do dispositivo em uma rede, por exemplo, em determinada instalação existem 4 CFs do mesmo tipo, porém, tem 2 do lado esquerdo e 2 do lado direito, pode-se adotar que as ECUs do lado esquerdo possuem instância de função zero (0) e as duas do lado direito tem instância de função um (1).
  • Instância de ECU (ECU Instance) – Determina em qual grupo de CF ela esta associada, por exemplo, voltando ao exemplo das 4 CFs do mesmo tipo e que temos 2 grupos separados pelo lado esquerdo e direito, podemos dizer o seguinte, do lado esquerdo a ECU que está mais a esquerda seria a ECU de instância zero (0) e seguinte seria a ECU de instância um (1), e do outro lado e a ECU que está mais a direita seria a ECU de instância 0 e a seguinte um (1).
  • Código do fabricante (Manufacturer Code) – Definido e atribuído pela ISO. É um código que identifica o fabricante da ECU, por exemplo, 1851 é o código da Vector North America.
  • Número de identidade (Identity Number) – É atribuído pelo fabricante da ECU.

Uma observação importante é que todos os campos que estão descritos como “Definido e atribuído pela ISO” são encontrados na norma ISO 11783-1. Uma dica para facilitar o nosso trabalho é acessar o site isobus.net para obter uma lista completa e atualizada desses campos.

Endereço

Como definido na primeira parte deste artigo, o endereço é um valor de 8 bits que identifica a CF dentro da rede. Ele deve ser usado por cada mensagem enviada na rede pela CF, tornando assim uma mensagem única. Para a obtenção do endereço na rede ISOBUS a CF deve executar um procedimento chamado de Reivindicação de Endereço (Address Claim).

Endereço Preferencial

A ISO 11783 específica alguns endereços preferenciais que deve ser usado pela CF à depender da sua categoria (NAME), caso este endereço já esteja em uso por uma CF de maior prioridade, A CF de menor prioridade deve tentar reivindicar outro endereço. Consultar a ISO 11783-1 para obter uma lista de endereços atribuídos preferidos ou o site https://www.isobus.net/isobus/sourceAddress.

Endereço NULO

O endereço NULO (254) só é permitido no campo de source address e é destinado apenas para gerenciamento de rede.

Endereço Global

O endereço Global (255) só pode ser usado no campo endereço destino para mensagem BROADCAST.

Procedimento de Gerenciamento de Rede

Os procedimentos descritos aqui são para que a CF possa se identificar e obter um endereço único de 8 bits na rede. Este endereço deve ser usado no campo source address todas as vezes que a CF enviar uma mensagem no barramento. A única exceção é o endereço NULO (254) que só é aceitável em um campo SA de mensagens de gerenciamento de rede, e somente quando a mensagem for uma solicitação de endereço ou uma mensagem do tipo “não foi possível solicitar endereço de origem”.

Veja na tabela abaixo todas as mensagens que são usadas nesta parte da norma para gerenciamento de endereços.

Tabela 1- Mensagens de gerenciamento de endereço

MensagemPGNPFPSSAComprimento do dadoDado
Solicitação de endereço reivindicado (solicitar PGN)59904(a) (0xEA00)234 (0xEA)DASA(b)3PGN 60928 (0xEE00)
Endereço Reivindicado60928 (0xEE00)238255SA8NAME (isoname)
Não foi possível solicitar endereço de origem60928 (0xEE00)2382552548NAME (isoname)
Endereço comandado65240 (0xFED8)254216SA9(c)NAME (isoname), novo SA
  • (a)Ver ISO 11783-3.
  • (b) O SA (Source Address – Endereço de origem) é configurado como 254 se nenhum endereço tiver ainda sido reivindicado.
  • (c) A mensagem do endereço comandado é enviada por meio do protocolo de transporte de mensagem de difusão (BAM).

Processo de Reivindicação de Endereço (Address Claim)

Existem 2 caminhos para requisição de endereço no barramento ISOBUS, sendo eles:

  1. O dispositivo que entra na rede, deve requisitar aos demais dispositivos presentes que enviem os seus endereços (já reivindicado), ele deve verificar se o seu endereço inicial está livre, caso esteja ele o reivindica, caso não, procura por um endereço disponível e o reivindica. Vide diagrama abaixo.
ISO 11783-5
Figura 2 – Fluxo para obtenção de endereço único a partir de uma tabela de endereços

  1. O dispositivo que entra na rede, deve reivindica um endereço preferencial, caso nenhum outro dispositivo já o tenho reivindicado, o dispositivo pode assumir o endereço preferencial, caso contrário deve reivindicar um outro endereço.
ISO 11783-5
Figura 3 – Fluxo para obtenção de endereço único por tentativa

Observações sobre os termos utilizados na máquina de estados:

  • Request_ACL [PGN = 0xEA00] para solicitar o endereço reivindicado (PGN 0xEE00) dos dispositivos que já estão no barramento.
  • ACL [PGN = 0xEE00], reposta da Request_ACL com o endereço reivindicado da FC que está no barramento.
  • Após o envio da Request_ACL o dispositivo deve aguardar por um tempo mínimo de 250ms + tempo randômico (na norma é descrito como ATxA), sendo este tempo um valor entre 0 a 255 * 0,6ms.

Considerações Finais

Com isso finalizamos o artigo sobre o Pilar para Construir Aplicações ISOBUS, com essas 3 partes da norma ISO 11783:1, ISO 11783:3, ISO 11783:5, temos a base para construir aplicações ISOBUS (do ponto de vista de software) como por exemplo aplicações como Task Controller, Virtual Terminal, File Server, etc. Mas quero deixar claro que o assunto é mais extenso do que foi apresentado neste artigo, em síntese podemos dizer que com algumas poucas exceções não foram considerados neste artigo os casos de exceções (worst case), pois isso tornaria o assunto mais exaustivo (sem necessidade).

E para finalizar gostaria de agradecer à sua leitura e gostaria de pedir a você caro leitor, que caso encontrem erros, tenha sugestões, dicas etc. que deixe o seu comentário para evoluirmos para as próximas etapas.

Referências Bibliográficas

ISO 11783:1 – https://www.iso.org/standard/57556.html

ISO 11783:2 – https://www.iso.org/standard/71171.html

ISO 11783-:3 – https://www.iso.org/standard/71172.html

ISO 11783:5 – https://www.iso.org/standard/74366.html

ISOBUS 11783 Online Data Base – https://www.isobus.net/isobus/

Outros artigos da série

<< O Pilar Para Construir Aplicações ISOBUS – Introdução
Licença Creative Commons Esta obra está licenciada com uma Licença Creative Commons Atribuição-CompartilhaIgual 4.0 Internacional.

Receba os melhores conteúdos sobre sistemas eletrônicos embarcados, dicas, tutoriais e promoções.

Comunicações » ISO 11783-5 – para Gerenciamento de Rede (Network Management)
Comentários:
Notificações
Notificar
guest
6 Comentários
recentes
antigos mais votados
Inline Feedbacks
View all comments
Angelo José Roncali Da Silva
07/08/2020 08:05

Excelente série de artigos!!!! Muito esclarecedora!!!
A minha empresa está começando a entrar no mundo do ISOBUS agora, até comprarmos algumas partes da norma.
Eu tenho uma dúvida com relação ao Manufacturer Code, como a minha empresa procederia para obter um para usarmos em nossos futuros produtos. Você saberia como proceder?

Ronaldo Lins
Ronaldo Lins
Reply to  Angelo José Roncali da Silva
07/08/2020 14:17

Olá, Angelo!
Obrigado pela sua leitura do artigo o feedback é sempre bem vindo.
Sobre o Manufacturer Code a solicitação deve ser feita junto a SAE, se eu não me engano tem essa informação na ISO 11783:1 (procura por Request Form), mas você também tem essa informação na HOME desse site https://www.isobus.net/isobus/ ou no próprio site da sae https://www.sae.org/works/committeeResources.do?resourceID=714476.

Espero ter ajudado.

Angelo José Roncali Da Silva
Reply to  Ronaldo Lins
10/08/2020 08:14

Ajudou e muito!!!
Muito obrigado!!!
E a série irá continuar com as partes 6 e 10 da Iso?

Ronaldo Lins
Ronaldo Lins
Reply to  Angelo José Roncali da Silva
10/08/2020 22:04

Olá, Angelo!
Que bom que te ajudou.
Sobre a continuação da série, sim eu pretendo dar continuidade com uma aplicação (provavelmente será a parte 6) para mostrar o funcionamento das partes 1,3 e 5 e talvez mostrar como é montando um object pool.

Angelo José Roncali Da Silva
Reply to  Ronaldo Lins
11/08/2020 08:03

Muito bom!!!!
E sobre object pool eu teria uma dúvida.
Para gerar o object pool para o VT, parte 6, existem vários softwares no mercado, basta escolher um deles, visualmente montar as telas e gerar o object pool.
E para o object pool para o TC, parte 10, existe algo do tipo? Eu não achei, estou tendo que montar o object pool “na unha”. E é complicado assim, pois se erra um byte, não funciona e para achar o erro numa sequência de bytes leva tempo.

Ronaldo Lins
Ronaldo Lins
Reply to  Angelo José Roncali da Silva
11/08/2020 09:20

Infelizmente eu não conheço um software para montagem do OP para TC, literalmente tem que ser montado escovando bytes/bits. O que deve existir são empresas que vendem a library isobus fornecer em conjunto um builder.

Talvez você goste:

Nenhum resultado encontrado.

Séries



Outros da Série

Menu

WEBINAR

Projeto de Hadware: ASIC e FPGA

DATA: 24/02 às 15h