IEEE 1451 com TIM e NCAP unificados
- Descrição:
De acordo com LEE apud RUFINO (2012), a norma IEEE 1451 é um padrão que define um conjunto de interfaces de comunicação comum, com o objetivo de conectar transdutores a sistemas baseados em microprocessadores, instrumentos e redes de campo, independente da rede utilizada.
Um transdutor inteligente padrão IEEE 1451 possui dois componentes principais chamados de Transducer Interface Module (TIM) e Network Capable Application Processor (NCAP). O TIM possui um transdutor inteligente que representa a integração de um elemento sensor ou atuador analógico/digital, um condicionador de sinal e os Transducer Electronic Data Sheet (TEDS) que carregam consigo informações dos sensores. O NCAP possui uma unidade de processamento e uma interface de comunicação. O esquema geral é mostrado na figura abaixo:
Figura 1: Modelo de transdutor inteligente IEEE 1451.
A família IEEE 1451 possui várias normas ativas como mostrado na figura 2, porém como nosso trabalho tem o objetivo de eliminar a conexão que divide NCAP e TIM unificando as duas partes da norma e a simplificando, iremos nos focar somente nos padrões que determinam regras de um para um entre os mesmos e estas são: IEEE1451.0, IEEE1451.1, IEEE1451.2 e IEEE1451.4.
Figura 2 - Modelo de Referência IEEE 1451
IEEE 1451.0: Introduz o conceito de TIM e NCAP, conectados através de um meio de comunicação especificado por outro membro da família. Também, descreve um conjunto de funcionalidades comuns a toda norma, as quais são independentes do meio físico de comunicação, e incluem especificações dos formatos de alguns TEDS, protocolos de comunicação comuns e funções básicas necessárias para controlar gerênciar os transdutores. Alem disso, IEEE 1451.0 define um conjunto de APIs (Application Programming Interface) independentes de implementação (IEEE 1451.0, 2007).
IEEE 1451.1: Define uma interface para conexão de NCAPs a redes de controle, através do desenvolvimento de um modelo de objeto comum e uma especificação de interface para sensores e atuadores inteligentes. A norma IEEE 1451.1 e aplicável a aplicações de controle e medicão distribuída e foca, principalmente, nas comunicações entre os próprios NCAPs, assim como entre NCAPs e os outros nós do sistema (IEEE 1451.1, 2000).
IEEE 1451.2: Estabelece uma interface digital para conexão entre transdutores e microprocessadores. O mesmo descreve alguns TEDS e seus formatos de dados, assim como define uma interface elétrica, funcões lógicas de leitura e escrita para acessar os TEDS e uma ampla variedade de transdutores. Esta norma não especifica qual sistema de condicionamento e conversão de sinal deve ser utilizado, nem mesmo como os dados contidos nos TEDS devem ser usados pelas aplicações. Ou seja, o padrão IEEE 1451.2 define uma interface transdutor-NCAP e TEDS para configurações ponto-a-ponto (IEEE 1451.2, 1998).
IEEE 1451.4: Define um protocolo e uma interface, os quais permitem que transdutores analógicos trafeguem informações digitais com um objeto IEEE 1451. Também, define o formato dos TEDS dos transdutores. A norma não especifica o projeto do transdutor, condicionador de sinal ou o uso específico dos TEDS. Enfim, este padrão define uma interface de modo misto para transdutores analógicos com modos de operação analógico e digital (IEEE 1451.4, 2004).
Tendo como premissa que o hardware para implementar um NCAP e um TIM tem valores parecidos e parte significativa da norma diz respeito a interação entre ambos. O objetivo do trabalho é transformar os dois blocos em um, de modo que quando o conjunto receber pela rede uma solicitação de leitura do sensor este responda de acordo com uma mensagem que teria sido gerada por um TIM e encapsulada por um NCAP. O resultado disto é demonstrado na figura 3:
Figura 3: Modelo IEEE 1451 unificado.
- Diagrama de Classes:
Figura 4: Diagrama de Classes
Convenções usadas de acordo com IEEE Standard for a Smart Transducer Interface for Sensors and Actuators - Network Capable Application Processor (NCAP) Information Model:
-Nome das classes: Para melhor visualização, toda classe referente ao padrão terá como prefixo “IEEE1451_”
- Sintaxe descritiva:
-Nomes de tipos: exemplo, TemperatureSensor (sem separação de palavras e a inicial de cada uma em letra maiúscula).
-Nome das classes: Com o prefixo “IEEE1451_” as palavras não deve ser separadas e a inicial de cada uma com letra maiúscula.
- Operações de classe: exemplo, CheckTemperature (sem separação de palavras e a inicial de cada uma em letra maiúscula).
- Enumeração e constantes globais: exemplo, HIGH, TEMPERATURE_SETPOINT
(separação de palavra por underscore e todas as letras maiúsculas).
- Todas as outras variáveis: exemplo read_status (todas as letras em minúsculo e separação por underscore).
- Modelo de comunicação:
O modelo de comunicação do padrão IEEE1451 define a sintaxe e a semântica entre o objeto de aplicação e a interface de rede. O padrão standard faz isso especificando cliente, desenvolvedor e operações com os objetos. Estas interfaces são independentes da rede específica que está sendo usada.
O standard IEEE1451.1 não especifica nenhuma sintaxe de transferência ou protocolo. Para cada tipo de rede é utilizado suas bibliotecas e rotinas para chamadas entre as operações de comunicação do IEEE 1451.1 e a rede. Essas bibliotecas devem incluir rotinas de empacotamento e desempacotamento para transformar os dados em seu formato on-the-wire. E também deve ser compatível com a infraestrutura da rede. Para nosso trabalho iremos utilizar a rede RS232 já existente no EPOS e toda sua estrutura.
Na figura 5 é demonstrado a organizção proveniente de cliente e servidor
Figura 5 - Componente de comunicação cliente-servidor
Os passos requiridos para um cliente remotamente invocar uma operação em um objeto servidor são mostraso a seguir:
Passo 1: Durante o comissionamento do sistema, o atributo serverDispatchAddress de uma porta do objeto cliente processa o espaço necessario para o valor do endereço.
Passo 2: Durante a inicialização do sistema, o objeto cliente é providenciado com uma referencia para a porta do cliente objeto.
Passo 3: O objeto Cliente invoca a operação Execute no objeto de porta do cliente, indicando qual operaçãodo objeto servidor vai ser executada. Este providencia a operação que estava no argumento de input e referencia para os argumentos de output, cada um em um arranjo de argumentos.
Passo 4: Usando a infraestrutura da rede, a Objeto de porta do cliente executa a operação resultando na operação no objeto servidor.
Passo 5: É executada a operação invocada no Objeto Servidor.
Passo 6: Quando o objeto servidor completa a operação é retornada pelos seus argumentos de output.
Passo 7: A operação Perform usa a rede para retornar o resultado para a porta do objeto cliente
Passo 8: A operação executada é retornada para o objeto cliente com o conjunto de argumentos.
Figura 6 - Máquina de Estados da Ação
Tabela 1 - valores PerformCodes.
- Implementação
/**
actuationComplete (
in short operationId,
in short status);
Parameters:
Este método é invocado por uma chamada startWrite(). Para uma operação não bloqueante, isso provem uma informação de status para a aplicação.
* operationId especifica a operação ID que é retornada para a chamada startWrite().
* status especifica o codigo de erroa da operação não bloqueante.
Return result: The application must return a status code back to IEEE p1451.0.
*/
virtual short actuationComplete(short operationId, short staus);
/**
short commandComplete(
short operationId,
IEEE1451_ArgumentArray outArgs,
short status);
Este método é invocado por um startCommand(). Isso provêm o output IEEE1451_ArgumentArray de volta para a aplicação.
Parametros:
* operationId especifica a operação desejada ID que é retornada para a chamada startRead( ) ou startStream( ).
* outArgs contem o array que retorna. Essa informação é especifica para cada comando.
* status Especifíca o código de erro.
Return : A aplicação deve retornar um codigo de status.
*/
virtual short commandComplete(IEEE1451_ArgumentArray operationId, IEEE1451_ArgumentArray outArgs, short status);
/**
short measurementUpdate(
short operationId,
IEEE1451_ArgumentArray measValues,
status status);
Este método é invocado por uma chamada startRead( ) ou startStream( ) call. Este provem uma medição para a aplicação. No caso do stram, essa chamada irá acontecer a cada vez que uma medição é efetudada.
Parameters:
* operationId Especifica o ID da operação desejada retornada para a chamada startRead( ) ou startStream( ).
* measValues contêm a informação da medição.
* status especifica o codigo de erro.
*/
virtual short measurementUpdate(short operationId, IEEE1451_ArgumentArray measValues, short status); /**
short statusChange(
short operationId,
short status);
Este método é invocado por uma chamada registerStatusChange( ).
Parameters:
* Possuem as mesmas funções das anteriores
*/
virtual short statusChange(short operationId, short status);
/**
short triggerComplete(
short operationId,
short status);
Este método é invocado por um startTrigger( ). Este provem uma informação de status para informar a aplicação quando o trigger é completado.
*/
virtual short triggerComplete(short operationId, short status);
Como foi sugerido utilizamos a implementação do Ruffino, porém encontramos alguns problemas pois ele não utiliza o formato de mensagem padrão do NCAP como visto no trecho “Esta dissertação visa utilizar o protocolo SIP para a comunicação entre a rede do usuario e o NCAP. Esta nova abordagem traz benefícios em frente as propostas presentes na norma IEEE 1451 principalmente quando utilizado sensores multimídia, pois IEEE 1451.1 e IEEE 1451.0 HTTP não tratam este tipo de dispositivo, enquanto que SIP representa um protocolo próprio para o estabelecimento de sessões para comunicação interativa entre usuários. Este protocolo e muitas vezes utilizado juntamente com o protocolo RTP, o qual é empregado em aplicações de tempo real, por exemplo, entrega de dados de audio, como voz sobre IP (do inglês Voice over Internet Protocol, VoIP).” (RUFINO, 2012) e também no trecho “Chunshan propõe o uso de certas mensagens SIP para a comunicação entre sensores conectados a uma rede. Este trabalho utiliza somente os conceitos do padrão IEEE 1451, tais como NCAP, TIM e TEDS, porém, os comandos presentes na norma não são utilizados, sendo os mesmos substituídos por mensagens SIP. A requisição SIP REGISTER e utilizada quando um nó deseja entrar na rede, INFO inicializa uma sessão, BYE permite que um sensor deixe a sessão e as mensagens UPDATE e INFO modificam os dados dos TEDS. Alguns dos benefícios da utilização do protocolo SIP são: plug and play pode ser realizado facilmente através dos princípios de registro SIP, redes híbridas podem ser conectadas através do protocolo e, por fim, usuários podem gerenciar sensores através da Internet, utilizando dispositivos SIP” (CHUNSHAN apud RUFINO, 2012).
Para nosso trabalho, o que tentamos fazer foi transformar o NCAP application criado por Ruffino de um jeito que não fosse necessário utilizar as funções de descoberta de TIM incluindo no próprio header dele as funções do TIM.
#include "ieee1451_ncap.h"
#include "ieee1451_objects.h"
#include "ieee1451_tim.h"
#include <list>
#include <cstdlib>
Modificamos a classe também para não ser necessário passar um endereço de um TIM, já que só existe um.
unsigned short send_read_data_set(const std::string &address, unsigned short channel_number) {
unsigned int offset = 0;
return IEEE1451_NCAP::get_instance()->send_command(COMMAND_CLASS_READ_TRANSDUCER_CHANNEL_DATA_SET_SEGMENT, (char *) &offset, sizeof(offset));
}
unsigned short send_start_read_data_set(const std::string &address, unsigned short channel_number) {
return IEEE1451_NCAP::get_instance()->send_command(COMMAND_CLASS_START_READ_TRANSDUCER_CHANNEL_DATA_SET_SEGMENT);
}
unsigned short send_stop_read_data_set(const std::string &address, unsigned short channel_number) {
return IEEE1451_NCAP::get_instance()->send_command(COMMAND_CLASS_STOP_READ_TRANSDUCER_CHANNEL_DATA_SET_SEGMENT);
}
- Problemas de implementação:
Para a implementação, ao invés de utilizar o EPOSMote, optou-se por utilizar mensagens trocadas pela rede, utilizando uma VLAN.
Para este procedimento o EPOS foi instalado em uma máquina virtual, para que o linux instalado na máquina física fizesse a conexão com o QEMU, uma vez que o QEMU somente autoriza a conexão, quem faz o trabalho é o próprio linux.
Para verificar se a troca de mensagens estava ocorrendo utilizou-se o Wireshark, porém após várias tentativas ainda não foi possível fazer a conexão.Outras abordagens para os problemas encontrados então sendo estudadas.
- Referências
IEEE Standard for a Smart Transducer Interface for Sensors and Actuators - Network Capable Application Processor (NCAP) Information Model. In: The Institute of Electrical and Electronics Engineers, Inc.
(http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=841361)
SONG, E.;LEE, K. Sensor Network Based on IEEE 1451.0 and IEEE p1451.2 - RS232. In: National Institute of Standards and Technology: [s.n.]. (http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=4547323)
RUFINO, L. Integração do Protocolo SIP a Norma IEEE 1451 para Redes de Sensores Sem Fio. In: Universidade Federal de Santa Catarina. 2012. (http://www.lisha.ufsc.br/pub/Rufino_MSC_2012.pdf)
TORRI, L. A norma IEEE 1451 aplicada a redes heterogêneas de sensores sem fio. In: Universidade Federal de Santa Catarina. 2012. (http://www.lisha.ufsc.br/pub/Torri_BSC_2008.pdf)
QEMU supports network in user mode (http://www.h7.dion.ne.jp/~qemu-win/HowToNetwork-en.html#vlan)