1 UNIVERSIDADE ESTADUAL PAULISTA “JÚLIO DE MESQUITA FILHO” FACULDADE DE ENGENHARIA CÂMPUS DE ILHA SOLTEIRA WELINGTON LUIS CODINHOTO GARCIA TEDS-EASY - DESCRIÇÃO AUTOMÁTICA DE TRANSDUCER ELECTRONIC DATA SHEET Ilha Solteira 2014 2 WELINGTON LUIS CODINHOTO GARCIA TEDS-EASY - DESCRIÇÃO AUTOMÁTICA DE TRANSDUCER ELECTRONIC DATA SHEET Dissertação apresentada à Faculdade de Engenharia do Câmpus de Ilha Solteira, para obtenção do título de mestre em Engenharia Elétrica - UNESP. Eng. Eletr. Alexandre César R. da Silva Orientador Prof. Dr. Tércio Alberto dos Santos Filho Co-orientador Ilha Solteira 2014 3 4 5 AGRADECIMENTOS A Deus, Por me dar força nessa caminhada até a conclusão desde trabalho. Aos meus pais, Luiz Garcia Scritorio e Inês Aparecida Codinhoto Garcia, Pelo apoio, incentivo, cooperação, ajuda e, em especial, a todo o carinho prestado a mim ao longo deste percurso. A minha irmã, Anna Beatriz Codinhoto Garcia, Pelo carinho e incentivo. A minha namorada, Danmilles Alves de Almeida, Pelo incentivo, cooperação, carinho e compreensão prestados a mim nesta jornada até aqui. Ao meu co-orientador, Tércio Alberto dos Santos Filho, e meu orientador, Alexandre César Rodrigues da Silva, Pela dedicação, ajuda na orientação deste trabalho. 6 RESUMO Neste trabalho, apresenta-se uma ferramenta para descrição automática de TEDS (Transducer Electronic Data Sheet), facilitando a configuração de transdutores em uma rede de sensores inteligentes de acordo com o padrão IEEE 1451. As TEDS são tabelas virtuais definidas no padrão IEEE 1451, que contém a descrição dos transdutores. No desenvolvimento desta ferramenta, denominada de TEDS-EASY, utilizou-se a linguagem de programação web JSP (Java Server Pages) e sistema de banco de dados PostGreeSQL. Utilizou-se também a UML (Unified Modeling Language) para realizar a modelagem do projeto. Foram realizados testes com o sistema TEDS-EASY, a fim de validar as TEDS geradas por meio de descrições manuais e descrições encontradas na literatura, comparando com a descrição obtida ao utilizar a ferramenta de descrição de TEDS apresentada neste trabalho. Palavras-chaves: IEEE 1451. JSP. TEDS. Transdutor. UML. Web. 7 ABSTRACT This work presents a tool for automatic description of TEDS (Transducer Electronic Data Sheet), facilitating the configuration of transducers on a network of smart sensors according to the IEEE 1451 standard.'s TEDS are virtual tables defined in the IEEE 1451 standard containing the description of the transducers. In developing this tool called TEDS-EASY used the language of web programming JSP (Java Server Pages) and database system PostgreSQL database. We also used the UML (Unified Modeling Language) to perform the modeling project. Tests with TEDS-EASY system were performed in order to validate the TEDS generated through manual descriptions and descriptions found in the literature, comparing with the description obtained when using the tool for describing TEDS show in this project. Keywords: IEEE 1451. JSP. TEDS. Transducer. UML. Web. 8 LISTA DE FIGURAS Figura 1 - Visão geral do padrão IEEE 1451 ........................................................................... 15 Figura 2 - Modelo do STIM de acordo com o padrão IEEE 1451.2 ........................................ 23 Figura 3 - Diagrama de use-case do sistema de descrição de TEDS ........................................ 65 Figura 4 - Diagrama de classes do sistema de descrição de TEDS .......................................... 68 Figura 5 - Diagrama de sequência do sistema de descrição de Meta-TEDS ............................ 69 Figura 6 - Diagrama de sequência do sistema de descrição de Transducer Channel TEDS .... 69 Figura 7 - Diagrama de estados do sistema de descrição de TEDS ........................................ 71 Figura 8 - Modelo relacional do banco de dados .................................................................... 74 Figura 9 - Interface inicial ....................................................................................................... 75 Figura 10 - Interface de cadastro de usuário............................................................................. 76 Figura 11 - Interface de opções de transdutores ....................................................................... 77 Figura 12 - Interface de Cadastro de Transdutores................................................................... 77 Figura 13 - Interface de Cadastro de TEDS .............................................................................. 78 Figura 14 - Interface de Cadastro de Meta-TEDS .................................................................... 79 Figura 15 - Interface de Cadastro de Meta-TEDS (Campos Opcionais) .................................. 80 Figura 16 - Interface de Hexadecimais da Meta-TEDS ........................................................... 81 Figura 17 - Interface de Seleção de Transdutores Cadastrados ................................................ 82 Figura 18 - Interface de Seleção de Visualização de Transdutores Cadastrados ..................... 83 Figura 19 - Download do código para o módulo TIM..............................................................84 Figura 20 - Arquivo de código para embarcar no módulo TIM ...............................................84 Figura 21 - Campos do arquivo de TEDS ................................................................................85 Figura 22 - Interface de Hexadecimais Gerados para META-TEDS ....................................... 88 Figura 23 - Interface de Hexadecimais Gerados para Transducer Channel TEDS .................. 89 Figura 24 - Interface de Hexadecimais Gerados para User’s Transducer Channel TEDS ....... 90 Figura 25 - Interface de Hexadecimais Gerados para Phy - TEDS ......................................... .91 Figura 26 - Meta-TEDS - TEDS EASY....................................................................................93 Figura 27 - PHY-TEDS - TEDS EASY………………………..……………………………..94 Figura 28 - User Transducer Name TEDS - TEDS EASY………………..….………………95 9 LISTA DE TABELAS Tabela 1 - Formato de uma TEDS ............................................................................................ 21 Tabela 2 - Type/Length/Value .................................................................................................. 22 Tabela 3 - Exemplo da Estrutura de uma Meta-TEDS ............................................................. 25 Tabela 4 - Estrutura da estrutura de uma TransducerChannel TEDS....................................... 29 Tabela 5 - Enumeração de chaves de auto teste ....................................................................... 33 Tabela 6 - Estrutura do User’s Transducer Name TEDS ......................................................... 36 Tabela 7 - Estrutura de uma PHY TEDS .................................................................................. 37 Tabela 8 - Estrutura da Calibration TEDS................................................................................ 40 Tabela 9 - Valores de correção da chave do TransducerChannel ............................................. 44 Tabela 10 - Estrutura de uma Frequency Response TEDS ...................................................... 45 Tabela 11 - Estrutura da Tabela de Pontos ............................................................................... 46 Tabela 12 - Estrutura de uma Transfer Function TEDS ........................................................... 47 Tabela 13 - Estrutura da Text-Based TEDS ............................................................................. 50 Tabela 14 - Lista de Linguagens ISO 639 ................................................................................ 51 Tabela 15 - Tabela de Algoritmos de Compressão................................................................... 52 Tabela 16 - Formato da End User Application Specific TEDS ................................................ 53 Tabela 17 - Meta-TEDS ID ...................................................................................................... 54 Tabela 18 - UUID da Meta TEDS. ........................................................................................... 55 Tabela 19 - Binário do UUID da Meta TEDS. ......................................................................... 56 Tabela 20 - Hexadecimais do UUID da Meta TEDS. .............................................................. 56 Tabela 21 - Octetos da Meta TEDS. ......................................................................................... 57 Tabela 22 - Transducer Channel TEDS. ................................................................................... 58 Tabela 23 - Valores para Unidades Físicas. ............................................................................. 59 Tabela 24 - Octetos Finais da Transducer Channel TEDS. ...................................................... 61 Tabela 25 - Octetos Finais da User’s Transducer Name TEDS. .............................................. 62 Tabela 26 - UUID – Sensor IntelBras ...................................................................................... 86 Tabela 27 - Meta-TEDS ........................................................................................................... 91 Tabela 28 - Meta-TEDS Hexadecimais .................................................................................... 92 Tabela 29 - PHY-TEDS ............................................................................................................ 93 Tabela 30 - PHY-TEDS Hexadecimais .................................................................................... 94 Tabela 31 - User Transducer Name TEDS ............................................................................... 95 10 LISTA DE ABREVIATURAS A/D Analógico/ Digital APIs Application Programming Interfaces D/A Digital/ Analógico EEPROM Electrically-Erasable Programmable Read-Only Memory FPGA Field-Programmable Gate Array IEEE Institute of Electrical and Eletronic Engineers I/O Input/ Output HTML Hyper Text Markup Language JSP JavaServer Pages MVC Modelo/ Visão/ Controle MMI Mixed Mode Interface NCAP Network Capable Application Processor NIST National Institute of Standards and technology PIR Passive Infrared RFID Radio-Frequency IDentification STIM Smart Transducer Interface Module SQL Structured Query Language TBC Transducer Bus Controller TBIM Transducer Bus Interface TEDS Transducer Electronic Data Sheet TIM Transducer Interface Module T/L/V Type/ Length/ Version UML Unified Modeling Language USB Universal Serial Bus XML Extensible Markup Language WTIM Wireless Transducer Module 11 SUMÁRIO 1 INTRODUÇÃO ............................................................................................................. 13 1.1 Objetivos ........................................................................................................................ 14 1.2 Revisão da literatura ..................................................................................................... 15 1.3 Organização do Texto ................................................................................................... 19 2 PADRÃO IEEE 1451 .................................................................................................... 20 2.1 Padrão IEEE 1451.0 – 2007 .......................................................................................... 21 2.2 Padrão IEEE 1451.1 – 1999 .......................................................................................... 22 2.3 Padrão IEEE 1451.2 – 1997 .......................................................................................... 22 2.4 Padrão IEEE 1451.3 – 2003 .......................................................................................... 23 2.5 Padrão IEEE 1451.4 – 2004 .......................................................................................... 23 2.6 Padrão IEEE 1451.5 – 2007 .......................................................................................... 24 2.7 Padrão IEEE 1451.7 – 2009 .......................................................................................... 24 2.8 TEDS obrigatórias ........................................................................................................ 24 2.8.1 Meta-TEDS ..................................................................................................................... 25 2.8.2 TransducerChannel TEDS ............................................................................................. 29 2.8.3 User´s Transducer Name TEDS .................................................................................... 36 2.8.4 PHY TEDS ..................................................................................................................... 37 2.9 TEDS Opcionais ............................................................................................................ 40 2.9.1 Calibration TEDS ........................................................................................................... 40 2.9.2 Frequency Responce TEDS ........................................................................................... 45 2.9.3 Transfer Function TEDS ............................................................................................... 47 2.9.4 Text-Based TEDS ........................................................................................................... 49 2.9.5 End User Application Specific TEDS ............................................................................ 52 2.9.6 Manufacturer-defined TEDS ......................................................................................... 53 2.10 Exemplo de implementação manual de TEDS ........................................................... 54 2.10.1 Meta-TEDS ................................................................................................................... 54 2.10.2 Transducer Channel TEDS ........................................................................................ 58 2.10.3 User’s Transducer Name TEDS .................................................................................. 62 2.10. Considerações finais sobre o capítulo ........................................................................... 62 3 MATERIAIS E MÉTODOS ........................................................................................ 63 3.1 Unified Modeling Language (UML) ............................................................................ 63 12 3.2 Diagrama de Use-Case .................................................................................................. 64 3.3 Diagrama de Classes ..................................................................................................... 65 3.3.1 Multiplicidade ................................................................................................................. 67 3.4 Diagrama de Sequência ................................................................................................ 67 3.5 Diagrama de Estados .................................................................................................... 70 3.6 Linguagem de Programação Java ............................................................................... 70 3.7 Servlet ............................................................................................................................. 71 3.8 JSP .................................................................................................................................. 72 3.9 PostgreSQL .................................................................................................................... 73 3.10 Considerações finais sobre o capítulo .......................................................................... 74 4 DESCRIÇÃO DO SISTEMA TEDS-EASY ............................................................... 75 4.2. Testes realizados com o sistema ................................................................................... 85 4.3 Testes realizados com exemplos da literatura ............................................................ 91 4.4 Considerações finais sobre o capítulo .......................................................................... 95 5 CONCLUSÃO ............................................................................................................... 97 6 TRABALHOS FUTUROS............................................................................................ 98 REFERÊNCIAS ............................................................................................................ 99 13 1 INTRODUÇÃO Considerações Iniciais Sistemas e ambientes supervisionados através de redes de transdutores inteligentes são cada vez mais utilizados nas mais diversas áreas, tais como: medicina, aplicações ambientais, agricultura de precisão, ambiente doméstico, automobilismo, indústrias, aplicações militares e etc. Vários são os problemas que surgiram na construção e configuração das redes de sensores inteligentes, devido à falta de padronização e à grande quantidade de tecnologias disponíveis no mercado. Como exemplo, pode-se citar: o elevado custo de implementação, dificuldade para realizar a manutenção da rede e falta de escalabilidade da rede, dentre outros. Para solucionar o problema da padronização das redes de transdutores, o National Institute of Standards and Technology (NIST), juntamente com o Institute of Electrical and Electronics Enginners (IEEE) desenvolveram um padrão para garantir a conexão de novos transdutores na rede, denominado de padrão IEEE 1451. O padrão IEEE 1451 define um conjunto de normas para o desenvolvimento de rede de transdutores inteligentes, cujos componentes da rede são definidos de acordo com subcomitês, descritos a seguir: IEEE 1451.0 (descreve o formato das TEDS), IEEE 1451.1 (descrição do Network Capable Application Processor (NCAP)), IEEE 1451.2 (descrição de Smart Transducer Interface Module (STIM)), IEEE 1451.3 (rede de transdutores baseados em padrões de barramentos mult-drop), IEEE 1451.4 (interface de modo misto), IEEE 1451.5 (interfaces de comunicação sem fio) e IEEE 1451.7 (interface por Radio-Frequency IDentification (RFID)) (SANTOS FILHO, 2012). O padrão específica dois módulos denominados de NCAP e TIM e uma interface para realizar a comunicação entre os módulos. O NCAP é responsável pelo processamento e gerenciamento da rede, e o TIM é um módulo que possui de 1 a 255 transdutores conectados, uma interface para a realização da comunicação com o NCAP e uma memória não volátil para o armazenamento das TEDS. Em alguns casos, é necessário armazenar as TEDS fora do módulo TIM. Essas TEDS são denominadas TEDS virtuais e são arquivos eletrônicos que fornecem as mesmas funcionalidades das implementadas em memória. As TEDS, (Transducer Electronic Data Sheet), são tabelas contendo informações para configuração dos transdutores de acordo com o padrão IEEE 1451, através de um conjunto de TEDS é possível descrever um transdutor. 14 Para a descrição de um transdutor, por meio do padrão IEEE 1451, são definidas quatro TEDS obrigatórias e seis TEDS opcionais, em cada tabela de TEDS é necessário um conjunto mínimo de informações descritas através das “tuplas”. Define-se tuplas sendo campos contendo informações para a composição de uma TEDS, podendo variar a quantidade dependendo da TEDS descrita. Para cada tupla em uma TEDS, deve-se realizar a conversão das informações para representação hexadecimal e adequar os octetos. Cada campo possui um identificador e uma quantidade de octetos definidos para sua descrição. Nesse trabalho, apresenta-se uma ferramenta para descrever TEDS de maneira automática, auxiliando na descrição de transdutores em redes, baseadas no padrão IEEE 1451. A ferramenta desenvolvida foi denominada de TEDS-EASY. 1.1 Objetivos Este trabalho teve origem em um trabalho de doutorado, que utilizou o padrão IEEE 1451 para configurar diversas interfaces de comunicação entre o NCAP (Network Capable Application Processor) e o módulo TIM (Transducer Interface Module), sendo que o NCAP foi configurado em uma FPGA com processador NIOS II e sistema operacional µCLINUX. Nesse trabalho, foi identificado a dificuldade em realizar a descrição das TEDS de maneira manual sendo necessário muito tempo para realizar essa tarefa, nesse contexto surgiu à proposta de implementar uma ferramenta para descrição automática das TEDS (SANTOS FILHO, 2012). O objetivo principal deste trabalho foi desenvolver um programa de computador para a descrição automática de TEDS que consiste em um sistema web, onde é possível cadastrar usuário, transdutores e TEDS e gerar as TEDS no formato correto para ser utilizada junto ao módulo TIM. A descrição das TEDS de forma manual é árdua e demanda uma quantidade significativa de tempo, e a ferramenta TEDS-EASY tem o objetivo de minimizar o trabalho de descrição de TEDS. Na Figura 1, ilustram-se as partes componentes do padrão IEEE 1451, sendo possível visualizar a divisão entre NCAP e TIM. O TIM é o módulo que contém os transdutores, circuitos de condicionamento de sinais, processador e lógica necessária para realizar a comunicação com o NCAP. Dentro do contexto geral do padrão IEEE 1451 este trabalho teve como foco a descrição das TEDS representadas na região circular amarela no esquemático da Figura 1. 15 Figura 1 - Visão geral do padrão IEEE 1451 Fonte: Elaboração do próprio autor 1.2 Revisão da literatura Nessa seção, é apresentada a revisão bibliográfica sobre os trabalhos relacionados com o padrão IEEE 1451. No trabalho de Song e Lee (2006), apresentou-se uma proposta de implementação com os padrões IEEE 1451.0 e padrão IEEE 1451.2. O sistema apresentado tem como base a descrição do sistema em UML (Unified Modeling Language) e o desenvolvimento do NCAP em linguagem de programação JAVA. Esse trabalho utiliza interface RS-232 para a comunicação entre os módulos, foi utilizado um sensor simples de temperatura para os testes. Dois estudos de caso foram implementados, no primeiro estudo foi analisado o processo de leitura da PHY-TEDS através de envios de comando para leitura e análise da resposta, verificando a integridade dos dados obtidos e tempo de resposta. No segundo estudo analisou-se a temperatura através da leitura de dados do Transducer Channel, nesse teste foi verificada a precisão na leitura dos dados. O NCAP foi desenvolvido em um notebook e programado em JAVA. Nesse trabalho é ressaltada a viabilidade do uso da linguagem de programação JAVA para aplicações utilizando o padrão IEEE 1451 devido a características que auxiliam no desenvolvimento de aplicações voltadas para o padrão. Manda e Gurkan (2009), apresentaram um sistema para escrita de TEDS utilizando o Framework .NET. No aplicativo apresentado, foi feita a automatização da escrita para as 16 seguintes TEDS: Meta-TEDS, Transducer Channel TEDS, Calibration TEDS, Frequency Response TEDS, Transfer Function TEDS, End User Application Specific TEDS e User’s Transducer Name TEDS. A ferramenta apresentada nesse artigo é uma aplicação desktop para descrição automática das TEDS. Nesse trabalho não foram implementadas todas as TEDS previstas no padrão. Nesse artigo é apresentada as características da descrição das TEDS implementadas e o funcionamento da ferramenta de descrição de TEDS proposto. Esse artigo se relaciona com este trabalho, pois realiza a descrição de TEDS previstas no padrão IEEE 1451 de maneira automática, no entanto a proposta apresentada é de uma ferramenta desktop e este trabalho apresenta uma proposta de desenvolvimento de uma ferramenta web para descrição de todas as TEDS previstas no padrão. Higuera e Polo (2011), apresentaram uma rede de sensores sem fio baseado no protocolo IPv6 utilizando o padrão IEEE 1451 e rede de sensor baseado padrão IEEE 802.15.4. Nesse trabalho foram usados módulos sem fio chamados de WTIM (Wireless Transducer Module) e foram realizados testes para validar a comunicação por meio de uma rede sem fio 6loWPAN. Para realizar os testes foi necessário elaborar TEDS para descrever os transdutores ligados ao WTIM. Nesse artigo foi apresentado um modelo para a Meta-TEDS e a PHY-TEDS utilizado, ressaltou-se que o padrão IEEE 1451 não define um formato padrão para as PHY-TEDS. Foram realizados testes para validar os dados obtidos e os resultados demonstraram comprovações do baixo consumo de energia por parte dos módulos, nesse sistema de rede é apresentado também uma proposta de formato para PHY-TEDS. Em relação com este trabalho foi utilizado o modelo de PHY-TEDS proposto como base para o desenvolvimento da descrição da PHY-TEDS. Santos Filho, et.al. (2010), apresentaram a descrição das TEDS para controlar um motor de passo e a implementação de um módulo TIM em um microcontrolador ATMEGA 8. Utilizou-se também como interface de comunicação o RS-232, de acordo com a norma IEEE 1451.2. Aplicou-se, através de comando para leitura das TEDS, metodologias para comprovar o funcionamento do TIM validando os dados obtidos pelo motor de passo. Foi analisada também a integridade dos dados das TEDS obtidos através da conexão plug and play, conexão essa obtida pelo uso do padrão IEEE 1451. Esse trabalho apresentou os modelos de TEDS descritas para controlar o motor de passo, esses modelos foram utilizados neste trabalho como base para a implementação da descrição das TEDS. Em Limin (2012), apresenta-se um sistema de monitoramento de vídeo e temperatura baseado no padrão IEEE 1451. Nesse trabalho estudou-se a viabilidade da utilização do padrão IEEE 1451 para o monitoramento de ambientes por meio de vídeo e monitoramento de 17 temperatura usando comunicação web para transmissão dos dados. A leitura dos dados foi realizada remotamente por uma função ligada a um servidor web, funções essas que consistiram no uso de protocolos de comunicação e um software para controle e monitoramento do trafego de dados. O objetivo desse trabalho foi analisar a viabilidade do uso de aplicações web para monitoramento de ambientes usando redes baseadas no padrão IEEE 1451. Esse trabalho forneceu base na formação do conhecimento sobre o padrão IEEE 1451 em relações a aplicações web e na formação de conceitos sobre o funcionamento do padrão. Jevtic e Drndarevic (2012) apresentaram um estudo baseado no padrão IEEE 1451.4 para interface de comunicação mista. Para tanto desenvolveram uma ferramenta em LabVIEW para leitura, escrita e edição das TEDS do transdutor. Nesse trabalho utilizou-se um microcontrolador de 8 bits sendo que o armazenamento das TEDS foi feito na EEPROM do microcontrolador. Foram utilizadas as TEDS obrigatórias e as TEDS opcionais: Calibration TEDS, Manufacturer/ user TEDS. O NCAP em foi implementado em LabVIEW e configurado em um computador que se liga ao módulo TIM por meio de conexão USB. Juntamente com o NCAP foi elaborado também um editor de TEDS que faz a leitura, edição e gravação das TEDS no módulo. O artigo traz informações sobre como foi implementado o sistema de leitura e escrita de TEDS. Esse artigo auxiliou na formação de conhecimento para estruturar o sistema de descrição de TEDS apresentado neste trabalho. Kumar et al. (2013), apresentaram um sistema de monitoramento de ambientes usando o padrão IEEE 1451. Foi analisado nesse trabalho o consumo de energia do módulo TIM além da vantagem do seu uso quando utilizado no monitoramento de ambientes. Nesse trabalho é apresentada uma proposta de interface gráfica para controle e monitoramento baseada em C e C#. Para fazer os testes foram utilizados sensores para leitura da oxidação de metais e quantidade de gases no ambiente analisado. Para elaboração do sistema de leitura foi criado um NCAP, a programação foi realizada em LabVIEW e a comunicação com o módulo TIM feita por USB. Nesse trabalho foi possível comprovar a eficiência e rapidez na troca de informações quando utilizado o padrão IEEE 1451 para monitoramento de ambientes. Esse trabalho apresenta modelos de transdutores e detalhes que ajudaram na realização dos testes apresentados neste trabalho. Perera et al. (2013), apresentaram um sistema desenvolvido em Field-Programmable Gate Array (FPGA) que incorpora todas as funcionalidades do IEEE 1451, usando um único transdutor com o objetivo de comprovar que, por meio de dispositivos reconfiguráveis, é possível acelerar o sistema de processamento do NCAP em redes baseadas no padrão IEEE 18 1451. Além da FPGA foi utilizado um computador para a transferência de dados e para realizar os testes, um módulo TIM e interface de comunicação RS-232. Através de comandos de envio e leitura de TEDS procurou-se testar a comunicação entre o módulo TIM e o NCAP configurado na FPGA. Nesse trabalho foi apresentado exemplos de implementação de TEDS que foram utilizados para realizar testes no sistema proposto neste trabalho. Ning-Chuan et al. (2013), apresentaram um sistema com duas interfaces de comunicação, o CANOpen e wireless, utilizando Zigbee. O objetivo de trabalho é apresentar um software que faça a ligação entre o NCAP e o TIM e auxilie na precisão e troca de informações em redes baseadas no padrão IEEE 1451. Para isso, foi utilizado protocolos de comunicação diferentes para cada interface de comunicação e foi desenvolvido diversas Application Programming Interface (APIs) para controlar a comunicação e troca de informações dos módulos. Esse trabalho auxiliou na compreensão do funcionamento das PHY-TEDS ajudando na formação de base de conhecimento para implementação dessas TEDS neste trabalho. Harikrishnam et al. (2013), apresentaram um estudo para avaliar as vantagens que o padrão IEEE 1451 fornece ao se trabalhar com redes de sensores sem fio. Nesse trabalho é apresentada a implementação de diferentes interfaces de comunicação, nas quais, usa-se um sensor ZigBee para reconhecimento de atividades, um sensor PIR (Passive Infrared), um acelerômetro e um sensor de temperatura. Este trabalho apresenta uma proposta de TEDS para configuração dos transdutores, são utilizados também comandos para leitura e escrita da TEDS a fim de testar o comportamento de cada transdutor de maneira isolada. Em relação a este trabalho, esse artigo auxiliou na implementação e testes das TEDS geradas pelo sistema TEDS-EASY, sendo que foi utilizado os exemplos como base para implementação da PHY- TEDS. Em relação aos trabalhos apresentados nessa seção, o presente trabalho se encaixa de maneira geral na descrição das TEDS auxiliando e agilizando no processo de descrição. Ao se realizar testes com os trabalhos apresentados, com o sistema TEDS-EASY, utilizando os mesmos valores aplicados na literatura, foi possível comprovar a validade das TEDS geradas. Os artigos apresentados nessa seção apresentaram formatos para a PHY-TEDS, TEDS essa não prevista no padrão, gerando uma base para elaborar um modelo de descrição dessas TEDS neste trabalho. 19 1.3 Organização do Texto Nesta seção, apresenta-se a organização do texto, abordando uma visão geral sobre os próximos capítulos. No Capítulo 2, é apresentada uma abordagem mais detalhada sobre o padrão IEEE 1451. Na Seção 2.1, é abordado de maneira detalhada as TEDS obrigatórias e opcionais definidas no padrão IEEE 1451.0. Na Seção 2.2, é apresentado o processo de descrição das TEDS de maneira “manual”. Na Seção 2.3, apresenta-se as considerações finais sobre o capítulo. No Capítulo 3, demonstra-se as tecnologias utilizadas para criar o sistema de descrição de TEDS. Na Seção 3.1, é apresentada a análise por meio da UML (Unifiqued Modeling Language), mostrando os diagramas elaborados para modelar o sistema de descrição de TEDS. A Seção 3.2 apresenta a linguagem de programação utilizada para criar a ferramenta de descrição de TEDS. Na Seção 3.3, é apresentado o sistema de banco de dados utilizado para gerenciar os dados do sistema, e por fim na Seção 3.4 são realizadas as considerações sobre o capítulo. O Capítulo 4 demonstra, de maneira detalhada, o sistema de descrição de TEDS, no qual, a Seção 4.1 descreve as interfaces do sistema. Na Seção 4.2, é apresentado à descrição das TEDS e detalhes sobre cada campo de cada formulário. Na Seção 4.3, demonstra-se os testes realizados com sistema descrição de TEDS e na Seção 4.4, são apresentadas as conclusões sobre o capítulo. E por fim, as conclusões finais a cerca do trabalho apresentado e possíveis trabalhos futuros. 20 2 PADRÃO IEEE 1451 Considerações Iniciais O padrão IEEE 1451 é composto pelos seguintes comitês: IEEE 1451.0, IEEE p1451.1, IEEE 1451.2, IEEE 1451.3, IEEE 1451.4, IEEE p1451.5 e IEEE p1451.7. Cada comitê define determinadas especificações para a padronização de interfaces nas áreas de sistemas Distribuited Measurement and Control (DMC). De forma sucinta, o padrão IEEE 1451 é dividido em dois módulos: o NCAP, definido na norma IEEE 1451.1 e o TIM, que é descrito de acordo com a interface de comunicação com o NCAP. (SANTOS FILHO, 2012; TORBEN, 2004). O NCAP é um nó de rede, com capacidade de processamento que pode ser visto por toda a rede. O NCAP tem a função de identificar o tipo de rede a qual está conectado, garantindo assim a característica de interoperabilidade, além de receber informações sobre os transdutores na rede, facilitando a aplicação do modo plug and play para os transdutores (IEEE, 1999). O NCAP é dividido em duas partes, a física e a lógica. A parte física é composta de microprocessador e circuitos associados, como hardware de comunicação com a rede e interfaces de acesso I/O (Input/Output). A parte lógica compreende componentes lógicos que são agrupados em componentes de aplicação e suporte (IEEE, 1999). O padrão IEEE 1451.2 introduz o conceito de STIM e será detalhado na Seção 2.3, na Seção 2.4 é apresentado o padrão IEEE 1451.3. O padrão IEEE 1451.4 traz um modelo de compatibilidade através de um módulo Mixed Mode Interface (MMI), que será apresentado na Seção 2.5. A Seção 2.6 detalha o padrão IEEE 1451.5 e o padrão IEEE 1451.7 é detalhado na Seção 2.7. Dentre os padrões que compõem a norma IEEE 1451 apresentados, este trabalho detalha o padrão IEEE 1451.0, o qual define como deve ser o formato padrão das TEDS e as funções e comandos necessários para sua implementação. As TEDS dividem-se em TEDS obrigatórias e TEDS opcionais. 21 2.1 Padrão IEEE 1451.0 – 2007 O padrão IEEE 1451.0 define o formato das tabelas que compõe as TEDS. As tabelas são blocos de informações armazenados em uma memória não volátil do TIM, cuja finalidade é descrever o TIM e os transdutores nele conectados (IEEE 1451, 2007). O primeiro campo da TEDS é denominado TEDS length, e trata-se de um número inteiro formado por quatro octetos, cuja finalidade é armazenar a quantidade de octetos que serão utilizados na descrição de toda a TEDS. O campo Data Block contém a descrição dos campos que compõem as TEDS. A estrutura e tamanho de cada TEDS são definidos na própria TEDS, podendo variar dependendo da TEDS que estará sendo descrita. O último campo é denominado checksum. As informações contidas neste campo servem para verificar a integridade da TEDS, somando o tamanho dos octetos anteriores e comparando com o TEDS Lenght. A estrutura do formato padrão de uma TEDS é apresentado na Tabela 1. Tabela 1 - Formato de uma TEDS Descrição Tipo Octetos TEDS length Unit32 4 Data Block Variável Variável Checksum Unit16 2 Fonte: IEEE 1451.0 (2007). O conjunto dos campos apresentados na Tabela 1 forma a estrutura de uma TEDS. A TEDS deve possuir obrigatoriamente o campo TEDS length e o campo Checksum, os campos que compõem o Data Block podem variar em quantidade, tipo e número de octetos dependendo da necessidade e da TEDS descrita. De acordo com cada TEDS, os campos que compõem o data block podem ser alterados. Entretanto, todas as TEDS seguem o esquema de dados, chamado de Type/Length/Value (TLV), apresentado na Tabela 2. 22 Tabela 2 - Type/Length/Value Tipo Descrição Type Identifica o valor contido dentro do campo “value”. Exceto para os valores 2 e 3 referentes ao campo Length e Value que possuem valores diferentes para cada TEDS. Length Apresenta a quantidade de octetos do campo “value”. Value Representa informações das TEDS referentes ao campo “type”. Fonte: IEEE 1451.0 (2007). O padrão IEEE 1451.0 especifica que para a implementação das TEDS, existe a necessidade da implementação de TEDS obrigatórias e opcionais. 2.2 Padrão IEEE 1451.1 – 1999 O padrão IEEE 1451.1 surgiu da ideia de facilitar o desenvolvimento de interfaces de sensores e atuadores em redes de controle. O objetivo da NIST/IEEE foi criar métodos de conexão padronizada entre os transdutores e redes de controle, sem a necessidade de mudar a tecnologia existente. Pensando nesse aspecto, o padrão propõe o uso de um nó de rede chamado NCAP com capacidade de processamento local e faz papel semelhante à de um gateway. O NCAP recebe as informações por meio de um protocolo, converte essas informações em outro protocolo em uma rede externa e reenvia para a rede interna de transdutores. Além disso, o NCAP é capaz de abstrair informações sobre o tipo de transdutor que está conectado, o que garante a capacidade plug and play na rede e reconhece o tipo de rede em que está inserido de forma automática (IEEE 1451.1, 1999). 2.3 Padrão IEEE 1451.2 – 1997 O padrão IEEE 1451.2 tem a finalidade de introduzir o conceito de STIM à família de padrões IEEE 1451. O STIM é um módulo que conecta um ou mais transdutores com a finalidade de garantir a capacidade plug and play à aplicação. Um STIM pode ter de 1 a 255 23 transdutores conectados a ele. Além disso, pode conter um circuito interno de condicionamento de sinal, como conversores Analógico/Digital (A/D) e Digital/Analógico (D/A). O modelo de um STIM é demonstrado na Figura 2 (IEEE 1451.2, 1997). Figura 2 - Modelo do STIM de acordo com o padrão IEEE 1451.2 Fonte: Santos Filho (2012) 2.4 Padrão IEEE 1451.3 – 2003 O padrão IEEE 1451.3 tem como objetivo descrever uma rede de transdutores distribuída, baseada em barramentos multi-drop. O padrão define o conceito de Transducer Bus Interface Module (TBIM) e Transducer Bus Controller (TBC), ambos conectados a um barramento de transdutores. O TBIM é um módulo que contém conversores A/D e D/A e transdutores ligados a ele quando necessário, e o TBC está vinculado ao NCAP e contém elementos de hardware e software incorporados a ele, e tem a finalidade de prover uma interface para o barramento de transdutores (IEEE 1451.3, 2003). 2.5 Padrão IEEE 1451.4 – 2004 O padrão IEEE 1451.4 traz o modelo de compatibilidade através de um módulo misto Mixed Mode Interface (MMI) analógico/digital. A interface, utilizando sinais mistos, permite 24 a transmissão dos dados das TEDS para o NCAP e a leitura dos dados dos sensores ou controle dos atuadores de forma analógica. Para comunicação com o NCAP, é feita a divisão de memória do MMI com o NCAP para armazenamento das TEDS e saída dos transdutores, sendo que ambos partilham do mesmo meio físico. Esta norma tem a finalidade de trazer a característica plug and play para transdutores analógicos (IEEE 1451.4, 2004). 2.6 Padrão IEEE 1451.5 – 2007 O padrão IEEE 1451.5 específica uma interface entre o NCAP e um Wireless Transducer Module (WTIM), em conformidade com as tecnologias de comunicação sem fio Bluetooth (IEEE 802.15.1) e ZigBee (IEEE 802.15.4) (IEEE 1451.5, 2007). 2.7 Padrão IEEE 1451.7 – 2009 O padrão IEEE 1451.7 define a comunicação do NCAP com o TIM, por meio de RFID. O RFID é uma tecnologia baseada em rádio frequência, atualmente empregada na indústria, comércio e segurança, dentre várias outras áreas (IEEE 1451.7, 2009). 2.8 TEDS obrigatórias As TEDS obrigatórias são blocos de informações, com a finalidade de garantir a característica plug and play aos transdutores, e devem estar presentes na descrição de qualquer transdutor. As TEDS obrigatórias são denominadas de Meta-TEDS, Transducer Channel TEDS, User’s Transducer Name TEDS e PHY-TEDS. 25 2.8.1 Meta-TEDS A Meta-TEDS apresenta parâmetros que são usados pelo NCAP, definindo valores para identificar quando o TIM responde à comunicação, são eles: Tempo de saída operacional, Tempo limite de acesso lento e Tempo de auto teste. Este bloco de informações descreve o relacionamento entre os Transducer Channels que existem no TIM. A Tabela 3 apresenta a estrutura de uma Meta-TEDS, de acordo com o padrão IEEE 1451.0 (IEEE 1451.0, 2007). Tabela 3 - Exemplo da Estrutura de uma Meta-TEDS ID Nome Descrição Tipo de Dado Octetos - Tamanho UInt32 4 0-2 - Reservado - - 3 TEDSID Cabeçalho de identificação de TEDS UInt8 4 4 UUID Identificador único global UUID 10 5-9 - Reservado - - Relacionado a informações de temporização 10 OholdOff Tempo de saída operacional Float32 4 11 SHoldOff Tempo limite de acesso lento Float32 4 12 TestTime Tempo para auto teste Float32 4 Numero de TransducerChannels implementados 13 MaxChan Número de TransducerChannels Implementados UInt16 2 14 CGroup Sub-bloco de controle de informação - - Os tipos 20 e 21 definem um grupo de controle 20 GrpType Tipo de grupo de controle UInt8 1 21 MemList Controle de membro de lista do grupo Vetor de UInt16 NTc 15 VGroup Sub-bloco de informação sobre grupo de vetores - - 26 Os tipos 20 e 21 definem um grupo de vetores 20 GrpType Tipo de grupo de vetor UInt8 1 21 MemList Membro da lista do grupo de vetor Vetor de UInt16 NTv 16 GeoLoc Grupo de vetor responsável pela localização geográfica - - Os tipos 24, 20 e 21 definem um conjunto de informações sobre a localização geográfica 24 LocEnum Número que define informações da localização do TIM UInt8 1 20 GrpType Tipo de Grupo de vetor UInt8 1 21 MemList Membro do Grupo de vetor Vetor de UInt16 NTv 17 Proxies Sub-bloco de definição de proxy do TransducerChannel - - Os tipos 22, 23 e 21 definem um proxy de TransducerChannel 22 ChanNum Número do TransducerChannel no proxy do TransducerChannel UInt 16 1 23 Organiz TransducerChannel Proxy organização de conjunto de dados UInt8 1 21 MemList Proxy do TransducerChannel membro da lista Vetor de UInt16 NTp 18-19 - Reservado - - 25- 127 - Reservado - - 128- 255 - Aberto para Fabricantes - - - Checksum UInt16 2 Fonte: IEEE 1451.0 (2007). Na Tabela 3, o campo de ID, cuja descrição é o Tamanho, é responsável por armazenar qual será o tamanho em octetos da TEDS. Neste campo é guardada a quantidade de octetos que terá toda a TEDS. 27 O campo, cujo ID varia de 0 até 2, é reservado, sendo que todos os campos com a descrição reservado são destinados a futuras alterações no padrão. O campo Cabeçalho de identificação de TEDS (TEDSID) é um campo de escrita obrigatória. Para descrever este campo, é necessário dividi-lo em quatro subcampos, denominados: Família, Classe, Versão e Tamanho da Tupla, onde:  Família: esse campo identifica qual membro da família IEEE 1451, sendo usado, definindo as TEDS;  Classe: esse campo é usado para identificar as TEDS que estão sendo acessadas;  Versão: esse campo define qual versão de TEDS esta sendo usada;  Tamanho da Tupla: esse campo contém o número de octetos e o tamanho dos campos de todas as tuplas, exceto este campo. O Identificador Único Global (UUID) é um campo obrigatório que, quando associado ao TIM, deve gerar uma identificação única em todo o planeta, campo este que possui 10 octetos e para descrevê-lo, utiliza-se 4 subcampos, listados a seguir:  Campo de Localização: esse campo é definido pelo fabricante do TIM para identificar um determinado local na terra, podendo ser esse local o endereço real do fabricante. Deve ter 42 bits e guardam valores de latitude e longitude.  Campo do Fabricante: esse campo é reservado para armazenar qualquer tipo de dado, sendo que o conteúdo desse campo não deve interferir no campo de localização.  Campo Ano: esse campo deve conter o ano em curso. Este campo possui 12 bits de valor inteiro.  Campo Tempo: é definido pelo fabricante do TIM de maneira que se combine com os campos localização, fabricante e ano, sendo que dessa maneira a UUID resultante é única para todos os TIMs feitos pelo fabricante. O campo de ID 10, denominado Tempo de Saída Operacional (OholdOff), é obrigatório e armazena o intervalo de tempo decorrido após o disparo de uma ação para que ela seja considerada uma operação que falhou. O campo Tempo de Acesso Lento (SHoldOff) de ID 11 é um campo opcional. Nele, é definido um intervalo de tempo em segundos após o disparo de uma ação, caso a resposta desta seja interpretada como uma operação que falhou, e o tempo que deve ser esperado para iniciar um novo comando. 28 O campo Tempo de Auto Teste (TestTime) é obrigatório e contém o tempo máximo em segundos para execução de auto teste caso não haja a necessidade de auto teste, esse campo deve ser especificado com o valor zero. O campo MaxChan é obrigatório para todos os TIMs. Nesse campo, é especificado o número de TransducerChannel implementados no TIM. Os TransducerChannel devem ser numerados a partir de um e serem contínuos, de maneira que se faltar algum número pode ocorrer a não leitura do TransducerChannel pulado na listagem numérica. O campo Controle de Grupos (CGroup) de ID 14 pode ser omitido caso não haja controle de grupos no módulo transdutor. O controle de grupos é usado para identificar transdutores que controlam outros transdutores na rede. O campo Grupo de tipo (GrpType) é obrigatório. Se existir controle de grupos de transdutores no TIM. Podendo ser omitido caso não haja controle de grupos. O campo de ID 21 é denominado Membro da lista (MemList). Esse campo é obrigatório para TIMs que implementam Controle de Grupos e Grupo de Vetores existentes no módulo transdutor. Esse campo é uma lista de canal de transdutores que farão parte do grupo de controle. O campo Grupo de Vetores (VGroup) é obrigatório no TIM quando for implementado um Grupo de vetores, caso contrário pode ser omitido. Esse campo é uma lista de números de canais de transdutores que farão parte do grupo de vetores. O campo Grupo de Localização Geográfica (GeoLoc) de ID 20 é obrigatório para TIMs que possuem implementação de localização dinâmica. Caso o campo seja omitido, o NCAP assume que o TIM não fornece informações sobre a localização. Esse campo tem uma estrutura T/L/V: LocNum, Group Type, Member List e implementa um tipo de vetor de grupo especializado que é usado para fornecer informações sobre localização geográfica dinâmica.  Enumeração de localização (LocEnum): esse campo é opcional. Caso seja omitido o NCAP deve assumir que o TIM não possui nenhuma informação geográfica.  Lista de Membros (Member List): esse campo pode ser omitido caso o TIM não contenha informações de localização geográfica. Essa lista de membros compõe a lista de membros dos canais.  O campo Grupo de Tipo é o mesmo definido anteriormente. O campo TransducerChannels Proxies (Proxies) é necessário caso o TIM contenha localização geográfica e pode ser omitido caso o TIM não forneça localização geográfica. É usado para combinar as saídas de múltiplos sensores ou entradas múltiplas para atuadores em uma única estrutura. 29 O campo ID de número 22 é denominado de Número de TransducerChannel no Proxy do TransducerChannel (ChanNum). Esse campo é necessário, caso o TIM implemente TransducerChannels Proxies. Contém o canal do transdutor que será utilizado quando abordar o proxy. Pode ser usado para ler dados de um proxy de um sensor, para gravar dados de um sensor atuador ou para acionar todos os transdutores representados pelo proxy. O campo Organização de Conjunto de Dados (Organiz) é obrigatório para TIMs, que possuem proxies de TransducerChannel, caso contrário esse campo deve ser omitido. Deve ser usado quando o conjunto de dados de diferentes transdutores contém diferentes números de identificação em uma mesma rede. Na seção 2.10.1 deste capítulo foi apresentado um exemplo prático de descrição de Meta-TEDS para um sensor simples de temperatura. Nessa seção é demostrado como deve-se realizar o cálculo de cada campo da Meta-TEDS. 2.8.2 TransducerChannel TEDS TransducerChannel TEDS tem a função de fornecer informações detalhadas sobre as especificações dos transdutores, além de fornecer os parâmetros físicos que estão sendo usados, tais como: faixa que o transdutor está operando, características digitais de I/O, modo de operação do transdutor e medidas de tempo. Na Tabela 4, apresenta-se um exemplo da estrutura de TransducerChannel TEDS, de acordo com o padrão IEEE 1451.0 (IEEE 1451.0, 2007). Tabela 4 – Estrutura da estrutura de uma TransducerChannel TEDS ID Nome do Campo Descrição Tipo Octetos - Tamanho da TEDS UInt32 4 0-2 - Reservado - - 3 TEDSID Identificação da TEDS UInt8 4 4-9 - Reservado - - Informações Relacionadas ao TransducerChannel 10 CalKey Chave de Calibração UInt8 1 11 ChanType Tipo de Chave do TransducerChannel UInt8 1 12 PhyUnits Unidades Físicas UNITS 11 50 UnitType Enumeração e interpretação física de UInt8 1 30 Unidades 51 Radianos Expoente para Radianos UInt8 1 52 SterRad Expoente para Steradianos UInt8 1 53 Meters Expoente para Meters UInt8 1 54 Quilogramas Expoente para Quilogramas UInt8 1 55 Segundos Expoente para Segundos UInt8 1 56 Amperes Expoente para Amperes UInt8 1 57 Kelvins Expoente para Kelvins UInt8 1 58 Moles Expoente para Moles UInt8 1 59 Candelas Expoente para Candelas UInt8 1 60 UnitsExt Extensão de código de acesso UInt8 1 13 LowLimit Projeto operacional de alcance menor Float32 4 14 HiLimit Projeto operacional de alcance maior Float32 4 15 OError Pior caso Float32 4 16 SelfTest Chave de auto teste UInt8 1 17 MRange Capacidade de Multi-Range UInt8 1 - Conversão de informações relatadas - - 18 Amostra - - 40 DatModel Modelos de dados UInt8 1 41 ModLenth Tamanho do modelo de dados UInt8 1 42 SigBits Modelo de bits mais significante UInt16 2 19 DataSet 43 Repeats Máxima repetição de dados UInt16 2 44 SOrigin Origem da serie Float32 4 45 StepSize Incremento das Series Float32 4 46 SUnits Unidades de Series UNITS 11 47 PreTrigg Máximo de amostras de pré-trigger UInts16 2 Relacionado à temporalização das informações 20 UpdateT Tempo de atualização do TransducerChannel Float32 4 21 WSetupT Tempo de escrita do TransducerChannel Float32 4 22 RSetupT Tempo de leitura do TransducerChannel Float32 4 23 SPeriod Período de amostragem do TransducerChannel Float32 4 24 WarmUpT Tempo de aquecimento do TransducerChannel Float32 4 31 25 RDelayT Leitura de Tempo de Atraso do TransducerChannel Float32 4 26 TestTime Requisito de tempo para auto teste do TransducerChannel Float32 4 Informação de amostra de tempo 27 TimeSrc Código para amostra de tempo UInt8 2 28 InPropD Atraso de propagação de dados através de lógica de transporte de dados Float32 4 29 OutPropD Atraso de propagação de saída através da logica de transporte de dados Float32 4 30 TSError Gatilho para amostra de atraso Float32 4 Atributos 31 Amostragem Atributo de Amostragem - - 48 SampMode Modo de capacidade de amostragem UInt8 1 49 SDefault Modo de amostragem padrão UInt8 1 32 DataXmit Atributo de transmissão de dados UInt8 1 33 Buffered Atributo de Buffer UInt8 1 34 EndOfSet Operação de atributo de fim do conjunto de dados UInt8 1 35 EdgeRpt Relatório de atributo UInt8 1 36 ActHalt Atuador de parada de atributo UInt8 1 Sensibilidade 37 Direção Sensibilidade de direção Float32 4 38 DAngles Ângulos de direção Dois Float32 8 Opções 39 ESOption Opções de evento de sensor UInt8 1 61-127 - Reservado - - 128- 255 - Aberto para fabricantes - - - - Chechsum UInt16 2 Fonte: IEEE 1451.0 (2007). Na Tabela 4, os dois primeiros campos possuem descrição igual à citada nos mesmos campos da Meta-TEDS, e as demais funcionalidades são listadas a seguir. 32 O campo, cujo ID é 3, possui a descrição de Unidades Físicas (PhyUnits). É usado para controlar a unidade física que está sendo medida ou controlada. O Campo Tipo de unidade (TypeUnits) é obrigatório para todos as TransducerChannel TEDS e serve para identificar qual será o tipo de unidade de medida usada para leitura dos dados. Os dados utilizados podem ser Radianos, Steradianos, Amperes, Meters, Kilograms, Segundos, Kelvins, Moles, Candelas. Esses campos possuem 8 bits de inteiros, e são representados na Tabela 4 pelos IDs que compreendem o 51 até 59 e não são obrigatórios, sendo dependentes do tipo de unidade. O campo Extensão de Código de Acesso (UnitsExt) é opcional, e quando não é implementado, o NCAP assume que não existem extensões de TEDS nesse TransducerChannel. Esse campo é fornecido para assumir extensões baseadas em textos para uma unidade física na TEDS do TransducerChannel. Esse campo deve fornecer um código de acesso para as TEDS através de um texto base que permite a extensão das TEDS. O campo Projeto Operacional de Alcance Menor (LowLimit) é obrigatório para todos os TransducerChannel TEDS. A omissão desse campo faz com que o NCAP emita uma mensagem de erro. No caso de sensores, esse é o menor valor para dados do TransducerChannel que é projetado após as correções aplicadas. Devem ser interpretadas em unidades físicas específicas, sendo que se os dados corrigidos no TransducerChannel ficam abaixo do limite, onde o TransducerChannel não atenderá às especificações do fabricante. Se tratando de atuadores, esse será o menor valor válido para todos os TransducerChannels, sendo projetado antes de aceitar as correções aplicadas. Deve ser interpretados nas unidades específicas. A gravação dos dados corrigidos no TransducerChannel pode resultar em comportamento diferente do previsto pelo fabricante. O campo Projeto Operacional de Alcance Maior (HiLimit) é obrigatório para todos os TransducerChannel TEDS. Caso seja omitido, o NCAP emite uma mensagem de erro. Para sensores, esse será o maior valor válido, sendo que se o valor desse campo ultrapassar o limite, pode não cumprir com as especificações do fabricante. Para atuadores esse será o maior valor válido para todos os TransducerChannel, sendo que, quando ultrapassado o limite, pode também provocar uma resposta fora das especificações do cliente. O campo de ID 15, denominado Erro (OError), é obrigatório. Esse campo descreve incertezas quanto a saída do TransducerChannel, tais como, variação de energia, variações de tensão e variações no ambiente, que podem mudar a saída do TransducerChannel. O campo Chave de auto teste (SelfTest) deve estar presente em todos os TransducerChannel TEDS, sendo que na sua ausência, o NCAP emite uma mensagem de erro. 33 Nele é definido a capacidade de auto teste da TransducerChannel TEDS como apresentado na Tabela 5: Tabela 5 - Enumeração de chaves de auto teste Valor Significado 0 Sem função do auto teste necessário 1 Função de auto teste necessária 2 – 255 Reservado para futuras expansões Fonte: IEEE 1451.0 (2007). O campo Capacidade de Multirange (MRange) é opcional, e quando não for informado, o NCAP assume que não existe Capacidade de Multirange no TransducerChannel. O conteúdo deste campo identifica qualquer transdutor no TIM que possui a capacidade de operar em faixas diferentes. Caso esse campo seja informado, o TransducerChannel é capaz de operar em mais de um intervalo. Caso seja definida a existência de Capacidade de Multirange, é necessário que seja definido também um TEDS de comando usado para definir comandos para selecionar a faixa de operação. O campo Definição Simples (Amostra) é obrigatório, e sua definição ocorre por meio de três campos requeridos por todos os TransducerChannel TEDS. São eles: Modelo de Dados, Tamanho do Modelo de dados, Modelo de Bit Mais Significante, que serão detalhados a seguir:  Modelo de Dados (DataModel): é um campo obrigatório e descreve modelos de dados usados na emissão ou gravação para o TransducerChannel;  Tamanho do Modelo de Dados (ModeLeght): esse campo possui a quantidade de octetos especificados na representação do campo de modelos de dados;  Modelo de Bit Mais Significante (SigBits): esse campo é obrigatório, e quando omitido, o NCAP pode reportar erro fatal de TEDS. Quando o campo Modelo de Dados é um N-octeto inteiro, variando entre 0 ou 5, ou o N-octeto fração variando entre 3 ou 6, o valor desse campo é o número de bits mais significante. Quando o Modelo de Dados for um N-octeto, N-octeto fração, um inteiro longo, ou fração de tempo, sendo que esse campo não pode exceder oito vezes o tamanho do Modelo de Dados. Quando o Modelo de Dados for um N-octeto inteiro ou inteiro longo, os bits de dados devem ser alinhados à direita dentro do fluxo do octeto. O valor zero não é aceito. Se o Modelo de Dados for um N-octeto fração ou fração de tempo, os bits de dados são alinhados à esquerda no octeto. Se o Modelo de Dados é de precisão real 34 simples ou dupla, o valor do campo Número de Bits no sinal do TransducerChannel’s é convertido. Quando o Modelo de Dados é de precisão simples real, dupla precisão real, bit de sequência, ou tempo do dia, e o campo Bits de Modelo Significativo pode ser fixo ou ignorado. O campo de ID 19 Conjunto de Dados (DataSet) é obrigatório em todos os TransducerChannel TEDS. Se o campo for omitido, as repetições de dados Maximum e o pré- trigger Maximum devem assumir o valor zero. O campo de ID 43, denominado Máxima repetição de dados (Repeats), é opcional. Caso o campo seja omitido, o valor deve ser igual à zero. Esse campo contém o número de repetições que o TransducerChannel pode produzir ou que seja exigido por um único Trigger. Cada repetição representa uma medição ou valor produzido, ou consumido pelo TransducerChannel. O campo Origem da Série (SOrigim) deve ser omitido se o máximo de repetições de dados for igual a zero. Caso o número de repetições não for zero e o campo for omitido, o NCAP assume o valor zero para a Origem da Série. O campo denominado Incremento das Séries (StepSize), cujo ID é 45 pode ser omitido caso o campo Repeats seja zero. Se o campo Repeats não for zero e esse campo for omitido, o NCAP apresentará uma mensagem de erro. O campo de Unidades de Série (SUnits) contém as unidades físicas associadas com o campo Origem da Série e Incremento das Séries no TransducerChannel TEDS. O campo cujo ID é 47, Máximo de Amostras do Pré-Trigger (PreTrigg), apresenta o número de repetições que podem ser incluídas e armazenadas antes que um trigger que seja disparado. Quando o valor for igual à zero, o sensor não pode ser operado no modo de funcionamento livre de pré-trigger. O campo Tempo de atuação do TransducerChannel (UpdateT) contém o tempo máximo em segundos do primeiro trigger e o engate da primeira amostra em um conjunto de dados para este TransducerChannel. O campo cujo ID é 22 denomina-se Tempo de Leitura do TransducerChannel (RSetupT) é obrigatório. Contém o tempo máximo em segundos entre a recepção do gatilho pelo módulo transdutor e o tempo que os dados estarão disponíveis para leitura. Caso o valor seja zero, os dados podem ser lidos a qualquer momento depois que ele é acionado. O campo denominado Período de amostragem do TransducerChannel (Speriod) é obrigatório para todos os TransducerChannels. Quando o período de amostragem não for necessário o valor indicado deve ser zero. Esse parâmetro representa o período de 35 amostragem determinado pela implementação do módulo transdutor, sendo representado em segundos. O campo Tempo de escrita do TransducerChannel (WarmUpT) cujo ID é 24, é obrigatório. Contém o período de tempo expresso em segundos, no qual o TransducerChannel estabiliza sua performance com tolerância pré-definidas. Levando em consideração as condições dos piores casos e depois de aplicar energia no TransducerChannel. O campo denominado Tempo de leitura do TransducerChannel (RDelayT) é obrigatório para todos os TransducerChannels e contém o máximo de tempo de atraso em segundos, entre a leitura do comando de segmento do TransducerChannel e o início de transmissão de quadro de dados. O campo, cujo ID é 26, denomina-se Requisito de Tempo para Auto Teste do TransducerChannel (TestTime). Deve estar presente em todos os TransducerChannels que possuem a capacidade de auto teste. Esse campo possui o valor em segundos necessário para executar o auto teste. O campo, Código para Amostra de Tempo (TimeSrc) é opcional, e, quando não é informado a opção “NoHelp”, deve ser acionada. O campo, Atraso de Propagação de Dados Através de Lógica de Transporte de Dados (InPropDl), é obrigatório se a fonte para o Campo de Amostra de Tempo tiver o valor “Incoming”. Caso contrário, pode ser omitido. Esse campo possui um número de precisão que define o atraso de tempo representado em segundos. O campo, cujo ID é 29, denomina-se Atraso de propagação de saída através da logica de transporte de dados (OutPropD). É obrigatório caso a fonte do tempo contenha o valor de “saída”, podendo ser omitido caso contrário. Esse campo guarda um valor real que define em segundos o atraso de tempo entre a última amostra e o sinal de trava. O campo, Gatilho para amostra de atalho (TSError), é opcional para todas os TransducerChannels, e marca o tempo em segundos que leva entre o gatilho e a amostra a ser aplicada ou retirada. O campo de ID 48, denominado Modo de capacidade de amostragem (SampMode), é obrigatório para todos os TransducerChannels. É usado para descrever quais modos de amostragem são suportados pelo TransducerChannel. O campo, Modelo de Amostragem Padrão (SDefault), é obrigatório a todos os TransducerChannel que operam em mais de um modo de amostragem. Esse campo é usado pra descrever os modos de amostragem padrão para esse TransducerChannel. 36 O campo, Atributo de Buffer (Buffered), cujo ID é 33, é opcional. Quando omitido o NCAP assume que existe somente um Buffer disponível. Esse atributo é usado para descrever os modos de operação de buffer disponíveis no TransducerChannel. O campo, Operação de atributo de fim do conjunto de dados (EndOfSet), é obrigatório quando existe um TransducerChannel para um atuador. Pode ser omitido para sensores. O campo, cujo ID é 32, denomina-se Atributo de Transmissão de Dados (DataXmit), e é opcional para sensores, podendo ser omitido para atuadores. Esse campo descreve os modos de transmissão de dados usados por esse TransducerChannel. O campo, Relatório de Atributo (EdgeRpt), é obrigatório para TransducerChannels de sensores de eventos e descreve os modos de operação usados por esse sensor. O campo, Atuador de Parada de Atributo (ActHalt), é obrigatório no caso de um TransducerChannel operador e descreve os modos suportados por esse atuador. O campo, Sensibilidade de Direção (Direction), é opcional, sendo que, quando utilizado, o fabricante deve identificar pelo menos dois ou três eixos para identificação da direção. O campo denominado Ângulos de Direção (DAngles) é opcional, e usado para fornecer coordenadas espaciais em radianos. O campo, Opções de Evento do Sensor (ESOpition), somente é usado em sensores de eventos. Esse parâmetro define a capacidade do módulo transdutor para detectar e relatar inconsistências. 2.8.3 User´s Transducer Name TEDS A estrutura dessas TEDS tem por finalidade identificar o transdutor através de um nome e seu conteúdo é definido pelo usuário. A User’s Transducer Name TEDS possui a seguinte estrutura apresentada na Tabela 6 (IEEE 1451.0, 2007). Tabela 6 - Estrutura do User’s Transducer Name TEDS Tipo Nome Descrição Tipo de Dados Octetos - Tamanho UInt32 4 0-2 - Reservado - - 3 TEDID Cabeçalho de Identificação de TEDS UInt8 4 4 Formato Descrição do formato das TEDS UInt8 1 37 5 TCName Nome do TIM ou TransducerChannel - - Checksum UInt16 2 Fonte: IEEE 1451.0 (2007) Os respectivos campos apresentados na Tabela 6 representam: Descrição do formato das TEDS (Formato): esse campo é obrigatório e mostra que a estrutura do bloco dos dados é definida pelo usuário. Nome do TIM ou TransducerChannel (TCName): esse campo guarda o nome do TIM ou TransducerChannel. 2.8.4 PHY TEDS As PHY TEDS são definidas de acordo com o meio de comunicação utilizado, e tem a função de disponibilizar uma interface de comunicação para acesso a qualquer canal. Por exemplo, a interface de comunicação sem fio ZigBee. Os octetos da PHY TEDS são constantes e somente de leitura, seguindo o formato geral das TEDS propostas no padrão IEEE 1451.0 utilizando a arquitetura TLV (Type/Length/Value) para módulos de comunicação que utilizam arquitetura cabeada para a comunicação dos dados. Todos os campos da PHY TEDS são obrigatórios, sendo que, se houver erro ou omissão de algum campo, o NCAP enviará uma mensagem de erro. Para a comunicação sem fio, a PHY TEDS é definida no padrão IEEE 1451.5. A Tabela 7 ilustra o formato de uma PHY TEDS (IEEE 1451.5, 2007). Tabela 7 - Estrutura de uma PHY TEDS Tipo Nome Descrição Tipo Octetos - Tamanho das TEDS UInt32 4 3 TEDID Cabeçalho de Identificação de TEDS UInt8 4 4-9 Reservado 10 Rádio Tipo de Rádio Frequência UInt8 1 11 MaxBPS Max. Transferência de Dados UInt32 4 12 MaxCDev Max. de Dispositivos Conectados UInt16 2 13 MaxRDev Max. de Dispositivos Registrados UInt16 2 14 Encrypt Encriptação UInt16 2 38 15 Authent Autenticação Booleano 1 16 MinKeyL Tamanho da Chave Mínima UInt16 2 17 MaxKeyL Tamanho da Chave Máxima UInt16 2 18 MaxSDU Tamanho Máximo do SDU UInt16 2 19 MinALat Latência Mínima de Acesso UInt32 4 20 MinTLat Latência Mínima de Transmissão UInt32 4 21 MaxXact Máximo de Transações Simultâneas UInt8 1 22 Battery Dispositivo Ligado a Bateria UInt8 1 23 RadioVer Versão do Rádio UInt16 2 24 MaxRetry Máximo de Tentativas Antes de Desconectar UInt16 2 25-31 - Reservado 32-41 Específico para o Protocolo Bluetooth 42-47 Reservado 48-54 Rádio Frequência 802.11 55-63 Reservado 64-80 Específico para o Protocolo ZigBee 81-95 Reservado 96-103 Específico ao Protocolo 6LowPAN 104-127 Reservado 128-255 Aberto aos Fabricantes - Checksum UInt16 2 Fonte: IEEE 1451.5 (2007) Os campos apresentados na Tabela 7 são descritos a seguir. Todos os campos, cuja descrição é “reservado”, são usados para atualizações previstas no padrão IEEE 1451. O campo, Cabeçalho de Identificação de TEDS (TEDSID), é utilizado para identificação da TEDS. 39 O campo, cujo ID é 10, Tipo de Radio Frequência (Rádio), define o tipo de rádio frequência que será utilizada. O campo, Max. Transferência de Dados (MaxBPS), marca a taxa máxima de transferência de dados em bits por segundo. O campo de ID 12 é denominado Max. Dispositivos Conectados (MaxCDev) e contém o número máximo de dispositivos que trabalharão simultaneamente. O campo, Max. Dispositivos Registrados (MaxRDev), mostra o número máximo de dispositivos que podem ser conectados simultaneamente a um nó de rádio. O campo, cuja descrição é Encriptação (Encrypt), indica se o rádio usado para comunicação de suporte a algum tipo de encriptação. O campo, Autenticação (Authent), indica se existe autenticação suportada pelo tipo de rádio. O campo de ID 16, cuja descrição é Tamanho da Chave Minima (MinKeyL), contém o parâmetro mínimo de autenticação ou tamanho da chave de encriptação suportada pelo tipo de rádio. O campo, Tamanho da Chave Máxima (MaxKeyL), contém o parâmetro máximo de autenticação ou tamanho da chave de encriptação suportada pelo tipo de rádio. O campo denominado Tamanho Máximo do SDU (MaxSDU) contém o máximo de serviço de unidade de dados, e o tamanho dos bytes aceitos para transferência entre esse dispositivo e outro. O campo, cujo ID é 19, denomina-se Latência Mínima de Acesso (MinALat) e possui o tempo mínimo para transmissão se iniciar primeiro a um dispositivo desligado em nanossegundos. O campo, Latência Mínima de Transmissão (MinTLat), contém o tempo mínimo em nanossegundos para transmitir o menor pacote de dados a partir do nó de rádio. O campo, Máximo de Transações Simultâneas (MaxXact), de ID 24 possui o número máximo de operações simultâneas que podem ocorrer. O campo, Dispositivo Ligado a Bateria (Battery), indica se um nó de rádio é ligado a uma bateria. O campo, Versão de Rádio (RadioVer), indica qual a versão de rádio que será usada. O valor de zero é o padrão, e indica que a versão de rádio é desconhecida. Um valor diferente de zero é interpretado com os dois dígitos superiores, que indica o número da versão principal de rádio, e os dois menores dígitos indicam o número da versão secundária. 40 O campo, Máximo de Tentativas Antes de Desconectar (MaxRetry), indica o número máximo de tentativas que o rádio irá realizar para tentar desconectar com outro dispositivo. 2.9 TEDS Opcionais Além das TEDS obrigatórias, ainda pode ser usada TEDS opcionais, dependendo da necessidade do usuário. São seis TEDS opcionais, que são apresentadas na subseção 2.1.2.1 até a subseção 2.1.2.6. 2.9.1 Calibration TEDS A Calibration TEDS é responsável por converter a saída do sensor em constantes da engenharia, e as constantes da engenharia em dados requeridos pelo atuador. Na Tabela 8 é apresentada a estrutura dessa TEDS (IEEE 1451.0, 2007). Tabela 8 - Estrutura da Calibration TEDS ID Nome Descrição Tipo Obr/Op Octetos - Tamanho UInt32 - 4 0-2 - Reservado - - - 3 TEDID Identificador de TEDS UInt8 Op 4 4-9 - Reservado - - - - Informações sobre dados de calibração - - 10 LstCalDt Dados da última calibração TimeInstance Ob 8 11 CalInrvl Intervalo de calibração TimeDuration Ob 8 Informações de Unidade 12 SIConvrt Unidades Constantes de conversão SI - Ob - 30 SISlope Unidades de Conversão Slope SI Float32 Ob 4 41 31 Intrept Unidades de Conversão Intrept SI Float32 Ob 4 Limites Operacionais e Incerteza 13 LowLimi t Limite de alcance operacional menor Float32 Ob 4 14 HiLimit Limite de alcance operacional maior Float32 Ob 4 15 OError Incerteza Operacional Float32 Ob 4 Correção Matemática a ser realizada nos dados antes e após a correção 16 OConver t Operação de Pós-Conversão UInt8 Ob 1 17 IConvert Operação de Pré-Conversão UInt8 Ob 1 Usado quando um método Linear de Conversão é utilizado 20 LinOnly Utilizado quando existe conversão linear - Ob - Descreve o TransducerChannel envolvido nas correções envolvidas neste TEDS 21 XdcrBlk Descrição do TransducerChannel - Ob - 40 Element Número do Elemento UInt6 Ob 1 41 ChanNu m Correção de Entrada do TransducerChannel UInt6 Ob 1 42 ChanKey Chave de Correção de Entrada UInt8 Ob 1 43 Degree Grau do TransduceChannel UInt8 Ob 1 44 STable Segmento Limite da Tabela de valores - - - 45 OTable Compensar tabelas de valores de segmento Float32Array Ob 1 46 LoBndry Matriz de limites baixos de fronteira Float32Array Ob 1 47 HiBndry Matriz de limites altos de fronteira Float32Array Ob 1 Providência um segmento de correção para esta TEDS 42 22 CoefBlk Coeficiente multinominal - Ob - 50 CellNum Número de células para aplicar no conjunto de coeficientes UInt8 Ob 1 51 CoefSet Conjunto de Coeficientes desta célula Float32Array Ob 2 18-19 - Reservado - - - 23-29 - Reservado - - - 48-49 - Reservado - - - 52- 127 - Reservado - - - 128- 255 - Reservado - - - - Cheksum UInt32 - 2 Fonte: IEEE 1451.0 (2007). A descrição de cada campo apresentado na Tabela 8 é detalhada a seguir. O campo, Limite de alcance operacional menor (LowLimit), é opcional, porém caso esse campo seja omitido, os campos de inclinação de conversão de unidade e unidade de conversão de interceptação devem ser iguais a um e zero, respectivamente. Para sensores, esse valor deve ser o menor valor válido para os TransducerChannels após a correção. Se tratando de atuadores, esse valor deve ser o menor valor válido para os TransducerChannels antes da correção aplicada nas unidades adequadas para esse TEDS. O campo, cuja descrição é Limite de alcance operacional maior (HiLimit), é opcional e caso seja omitido, o NCAP irá emitir uma mensagem de erro FATAL. Para sensores, esse valor deve ser o valor válido para os TransducerChannels após a correção. Para atuadores, esse valor deve ser o maior valor válido para os TransducerChannels antes da correção aplicada nas unidades adequadas para esse TEDS. O campo, cujo ID é 15, denomina-se Incerteza Operacional (OError). Esse campo é opcional, caso não seja informado. O NCAP deve usar a incerteza nas piores condições especificadas nas TransducerChannel TEDS. O campo, Operação de Pós-Conversão (OConvert) é opcional, e caso seja omitido, o NCAP deverá supor que não existe nenhuma operação de pós-conversão. Esse campo 43 contém uma enumeração para identificar uma operação matemática que deve ser realizada para produzir o valor das unidades especificadas no TransducerChannel TEDS. O campo, Operação de Pré-Conversão (IConvert), é opcional, e caso seja omitido, o NCAP deve assumir que não existe nenhuma operação de pré-conversão. Esse campo guarda os valores que identificam uma operação matemática que deve ser realizada para contribuir no processo de correção, que deve ser feito no processo de correção realizado para produzir um valor nas unidades especificadas o TransducerChannel TEDS. O campo, Conversão Linear (LinOnly), de ID 20, é opcional, e deve ser utilizado quando um método de conversão linear é usado. Caso os campo 20, 21 ou 22 não forem fornecidos, o NCAP retornará erro FATAL de TEDS. Esse campo descreve todas as constantes necessárias para uma única TransducerChannels quando a conversão for linear e conter um único corte. O campo, Descrição do TransducerChannel (XdcrBlk), é obrigatório caso apenas o método de conversão seja usado. Caso os campos 20, 21 ou 22 não sejam informados, o NCAP apresentará mensagem de erro. Esse campo descreve todas as constantes necessárias para uma única TransducerChannel quando uma conversão for linear e conter um único corte. Descreve ainda, todas as constantes necessárias para uma única TransducerChannel que faz parte do processo de correção. Possui os seguintes campos:  Número do Elemento;  Entrada de Correção do TransducerChannel;  Entrada de Correção Chave do TransducerChannel;  Grau do TransducerChannel;  Segmento Limite de Tabela de Valores;  Segmento Compensar da Tabela Valores. Se múltiplas TransducerChannels fornecerem valores de entrada para processos de correção para o TransducerChannel, em seguida, cada um dos TransducerChannels que fornecem um valor de entrada deve ter uma descrição na Calibration TEDS (IEEE 1451.0, 2007). O campo, Número do Elemento (Element), é obrigatório e usado para determinar um número de células. Caso esse campo seja usado, torna obrigatório o uso do campo cujo ID é 50. 44 O campo, Correção de Entrada do TransducerChannel (ChanKey), é obrigatório e contém a chave para determinar a fonte de dados associados a esse TransducerChannel. Na Tabela 9 é possível ver os possíveis valores das chaves. Tabela 9 - Valores de correção da chave do TransducerChannel Valor Significado 0 O valor de entrada deve ser obtido a partir do transdutor 1 O valor de entrada deve ser obtido a partir do NCAP 2-255 Inválido Fonte: IEEE 1451.0 (2007). O campo, Grau do TransducerChannel (Degree), requer a inclusão do campo 21 e corresponde ao grau de correção à entrada. O campo, Segmento Limite da Tabela de Valores (STable), requer a inclusão do campo 21 e consiste em dois subgrupos: matriz de limites baixos de fronteira, Limite alto. O campo, Compensar tabela de valores de segmentos (OTable), requer a existência de um valor no campo 21 além de ser obrigatório. Esse campo é armazenado nas TEDS como precisão simples ou números reais, apesar de poder representar dados numéricos diferentes. O campo, Matriz de Limites Baixos de Fronteira (LoBndry), é obrigatório e requer o campo 21 preenchido. Esse campo representa uma tabela que contém o limite inferior de cada segmento em ordem numérica crescente, onde são armazenados na TEDS como números reais de precisão simples, podendo representar outros números. O campo, Matriz de Limites Altos de Fronteira (HiBndry), é obrigatório e requer o campo 21 preenchido. Esse campo é um número de precisão única, que deve conter o maior valor para o mais elevado segmento do intervalo. O campo, cujo ID é 22, denomina-se Coeficiente Multidimensional (CoefBlk) e é obrigatório se um método de conversão geral é usado, sendo que, além desse campo, o campo 20 ou 21 devem ser informados se o campo 20 for informado, e os campos 21 e 22 devem ser omitidos. Esse campo consiste em dois sub-blocos, o CelNum e CoefSet. O campo, Número de células, desse segmento, para aplicar no conjunto de coeficientes (CelNum), é obrigatório, caso o campo 22 seja incluído. As células são enumeradas de zero a N com os valores de segmentos mais baixos de toda entrada dos TransducerChannels. O campo, Conjunto de Coeficientes (CoefSet), é obrigatório se o campo 20 é utilizado. Esse campo é uma matriz unidimensional contendo o coeficiente para cada termo da 45 equação. Todos os blocos, dentro de alguns Calibration TEDS, devem conter o mesmo tamanho e coeficientes. Caso não sejam necessários para um segmento, porém necessário a outro, devem ser ajustados com o valor zero. 2.9.2 Frequency Responce TEDS A Frequency Responce TEDS torna disponíveis informações relativas à resposta de frequência do canal do transdutor. É responsável por fornecer uma lista parcial de fatores que afetam a resposta de sinal analógico condicionado, suavização de filtro e processamento de sinal digital. Essa TEDS é acessada por meio de comandos de consulta, leitura, gravação ou atualização das TEDS. Sendo que esses comandos podem ser somente de leitura ou de leitura e gravação (isso fica a critério do fabricante). Na Tabela 10, é apresentado um exemplo de Frequency Response TEDS (IEEE 1451.0, 2007). Tabela 10 - Estrutura de uma Frequency Response TEDS Tipo Nome Descrição Tipo Octetos - Tamanho das TEDS UInt32 4 0-2 - Reservado - - 3 TEDID Identificação da TEDS UInt8 4 4-9 - Reservado - - 10 RefFreq Frequência de Referência Float32 4 11 RefAmp Teste de Amplitude Float32 4 12 RefPhase Fase com a Frequência de Referência Float32 4 Os campos seguintes representam uma estrutura que define um ponto de dados 13 Points Pontos na Tabela - - 14-127 - Reservado - - 128-255 - Aberto aos Fabricantes - - - - CheckSum - - Fonte: IEEE 1451.0 (2007). Os campos presentes na Tabela 10 têm as seguintes funções: 46 O campo, Identificação das TEDS (TEDSID), é obrigatório e usado para identificar a TEDS. O campo, Frequência de Referência (RefFreq), é obrigatório e identifica a frequência de referência em que a amplitude é definida como sendo unidade, que deve ser medida em Hertz. O campo, Teste de Amplitude (RefAmp), é obrigatório e identifica a amplitude de entrada utilizada para obter a informação de resposta. As unidade desse campo devem ser as mesmas que as definidas nos campos de unidades físicas do TransducerChannel TEDS. O campo, Fase com a Frequência de Referência (RefPhase), é obrigatório. Ele identifica o deslocamento da fase de saída na frequência de referência do TransducerChannel. A unidade deste campo é medida em radianos. O campo, Pontos na Tabela (Points), é obrigatório e define o campo de dados na tabela de resposta, sendo que cada ponto de dados é constituído por três subcampos: frequência, resposta de amplitude, resposta de fase. Esse campo pode se repetir sempre que o fabricante achar adequado para definir a resposta de frequência do Transducer Channel. A Tabela 11 apresenta a estrutura dos dados desse campo. Tabela 11 - Estrutura da Tabela de Pontos Campo Definição Tipo de Campo Sempre 13 para este campo. Tamanho Sempre 12 porque existem 3 números de ponto flutuante no campo de valor. Amplitude Define a amplitude da saída do TransducerChannel em relação a amplitude na frequência de referência definida no campo 2. Calcula a resposta da amplitude: amplitude na frequência/amplitude na frequência de referência. Fase Identifica o deslocamento de fase de saída na frequência do TransducerChannel, esse parâmetro deve ser medido em radianos. Fonte: IEEE 1451.0 (2007) 47 2.9.3 Transfer Function TEDS A Transfer Function TEDS fornece uma série de constantes que podem ser utilizadas para descrever a função de transferência do transdutor. Fatores que influenciam a função de transferência do sensor e o condicionamento de sinal analógico, filtro anti-aliasing e processamento de sinais digitais. Essa TEDS é normalizada com a função de transferência e assume que os dados dos transdutores são referenciados por essa frequência. Quando a função de transferência descreve a relação entre a entrada de saída e do TransducerChannel, a função inversa pode ser utilizada para linearizar ou compensar a frequência de resposta do sistema (IEEE 1451.0, 2007). A resposta de compensação da aplicação utiliza uma função matemática específica com base nos dados do TransducerChannel. O objetivo da compensação depende do tipo de TransducerChannel, entretanto o pedido de compensação independente do tipo de TransducerChannel (IEEE 1451.0, 2007). As TEDS são acessadas através de um comando de consulta de TEDS, gravação de segmento de TEDS, leitura de segmento de TEDS ou uma atualização de comando. A estrutura dessas TEDS segue na Tabela 12: Tabela 12 - Estrutura de uma Transfer Function TEDS Campo Nome Descrição Tipo Octetos - Tamanho da TEDS UInt32 4 0-2 - Reservado - - 3 TEDID Cabeçalho de Identificação de TEDS UInt8 4 4-9 - Reservado - - Relato de informações da Transfer Function TEDS 10 RefFreq Frequência de Referência Float32 4 11 OneZero Único Zero TF_SZ Float32 4 12 OnePole Único Polo TF_SP Float32 4 13 ZeroPole Único Zero com Polo Dependente - - 14 PoleZero Único Polo com Zero Dependente - - 15 ComplexZ Complexo Zero - - 16 ComplexP Complexo de Polo - - 17 OneZZPol Único Zero a Zero de um Polo Único - - 48 18 CRSlope Constante Relativa de Slope Float32 4 19 SampleT Amostra / Atraso de Tempo Float32 4 20 DependP Único Polo Dependente de um TF_SPm zero (X) Float32 4 21 DependZ Único Zero Dependente do Polo TF_SZm (X) Float32 4 22 ComplexZF Complexo de Frequência Zero Float32 4 23 ComplexoZQ Fator de Qualidade Complexo de Zero Float32 4 24 ComplexPF Complexo de Polo de Frequência Float32 4 25 ComplexPQ Pólo de Fator de Qualidade Complexo Float32 4 26-29 - Reservado - - 30 NCoeff Número de Coeficientes Array de Float32 N*4 31 DCoeff Denominador de Coeficientes Array de Float32 N*4 32-127 - Reservado - - 12-255 - Aberto Para Uso dos Fabricantes - - CheckSum Fonte: IEEE 1451.0 (2007) Os respectivos campos descritos na Tabela 12 possuem as seguintes funções a seguir: O campo, Único Zero TF_SZ (OneZero), é opcional. Caso seja omitido deve conter o valor zero. O valor usado descreve um filtro de primeira ordem com o ponto de -3dB a F. O campo, Polo Único (Single Pole), é opcional, sendo composto de dois subgrupos, um deles é o mesmo que o zero único e outro é o mesmo que o polo único. O campo, cujo ID é 20, denomina-se Único Polo Dependente de um TF_SPm zero (X) (DependP), é obrigatório caso o campo 13 esteja presente. Caso este campo seja omitido e o campo 13 estiver presente, o NCAP emitirá uma mensagem de erro. O campo, Único Zero Dependente do Polo TF_SZm (X) (DependZ), para que funcione de maneira correta, requer que o campo 14 seja preenchido. Caso o campo 14 seja omitido o NCAP deve reportar uma mensagem de erro. O campo, Complexo Zero (ComplexZ), é opcional. Caso esse campo seja omitido a função de transferência não contém um complexo zero. Esse campo tem dois subcampos, a frequência zero Complexo e fator de qualidade Complexo Zero. 49 O campo, Complexo de Frequência Zero (ComplexZF), é obrigatório se o campo 15 estiver presente. Se o campo for omitido, e o campo 15 estiver presente o NCAP enviará mensagem erro fatal de TEDS. O campo de Pólo de Fator de Qualidade Complexo (ComplexPQ) é obrigatório, caso o campo 16 esteja presente. Se esse campo for omitido e o campo 16 estiver presente, o NCAP deverá emitir uma mensagem de erro fatal de TEDS. É tipicamente usado para descrever o comportamento de um sistema de graus de liberdade único como um sistema de massa Mole ou um acelerômetro. A quantidade para esse campo é “sem unidade”. O campo, Único Zero a Zero de um Polo Único (OneZZPol), é opcional, e guarda um valor em Hertz. Descreve um filtro passa-alta de primeira ordem. O campo, Constante Relativa de Slope (CRSlope), é opcional e caso seja omitido a função de transferência não possui função de inclinação. O campo, cujo ID é 19, denomina-se Amostra / Atraso de Tempo (SampleT), é opcional. Se omitido, a função de transferência não conterá um filtro digital. Para esse tempo entre as amostras ou tempo de atraso, é usado um filtro digital, sendo que as unidades desse campo devem ser medidas em segundos. O campo, Número de Coeficientes (NCoeff), é opcional. Se esse campo for omitido, a função de transferência não contém um “Z” transformar. Caso esse campo não estiver presente, mas o campo 31 estiver presente o NCAP apresentará um erro fatal de TEDS. Esse campo contém uma lista de coeficientes necessários no numerador da equação, sendo que o número de coeficientes pode ser obtido dividindo o comprimento da tupla por quatro. O campo, Denominador de Coeficientes (DCoeff), é opcional. Se for omitido, a função não terá uma transformação de “Z”. Se esse campo não for preenchido, mas o campo 30 estiver preenchido, o NCAP apresentará uma mensagem de erro de TEDS. Esse campo contém uma lista de coeficientes exigidos pelo denominador da equação. 2.9.4 Text-Based TEDS A Text-Based TEDS tem a função de fornecer informações para exibição de um operador. O fabricante pode optar por implementar essa TEDS como sendo somente de escrita ou de leitura e escrita. A Text-Based TEDS possui estruturas baseadas em blocos de texto, sendo que cada bloco é apresentado em uma linguagem específica, onde a primeira parte 50 dessa TEDS é usada para permitir que o processador leia e localize um único idioma. O fabricante que determina o número de línguas implementadas. Na Tabela 13, é apresentada detalhadamente a estrutura da Text-Based TEDS (IEEE 1451.0, 2007). Tabela 13 - Estrutura da Text-Based TEDS Campo Nome Descrição Tipo Octetos - Tamanho da TEDS UInt32 4 0-2 _ Reservado - - 3 TEDID Cabeçalho de Identificação de TEDS UInt8 4 4-9 - Reservado - - Os campos seguintes compreendem o cabeçalho de idioma 10 NumLag Número de Blocos de Linguagens diferentes nessa TEDS UInt8 1 11 DirBlock Bloco de Descrição do Idioma. Esse Bloco pode ser repetido N vezes - - 20 LangCode Código da Linguagem ISO 639 UInt8 2 21 OffSet Desativar Idioma UInt32 4 22 Length Tamanho da Linguagem = LL UInt32 4 23 Compress Técnica de compressão utilizada UInt8 1 12 SubSum Sem verificação do checksum UInt16 2 Os campos a seguir representam a estrutura que um texto contém em um idioma - XMLText XML – baseado em bloco de texto Text LL-2 - XMLSum ChekSum do Bloco de Texto UInt16 2 13-19 - Reservado - - 23-127 - Reservado - - 128-255 - Aberto ao Fabricante - - - CheckSum UInt16 2 Fonte: IEEE 1451.0 (2007). A descrição de cada campo da Tabela 13 é descrita a seguir: O campo, Cabeçalho de identificação de TEDS (TEDSID), é obrigatório e é responsável por identificar a TEDS. 51 Se o campo Número de Linguagens (NumLang) não for preenchido, o NCAP assume que só existe uma linguagem sendo usada. Esse campo contém o número de identificação para saber a quantidade de linguagens usadas. O campo, Bloco de Descrição de Idioma (DirBlock), é obrigatório e composto pelos seguintes subcampos: Código de Linguagem, Idioma Compensado, Tamanho do Sub-bloco de Linguagem, Enumeração de Técnica de Compressão. O campo, Código de Linguagem (LangCode), é obrigatório e indica os idiomas que os campos de textos no TEDS são escritos. O valor desse campo deve ser correspondente à lista de idiomas usados na ISO 639. Na Tabela 14, é possível verificar algumas das possíveis linguagens e sua representação de acorde com a ISO 639. Tabela 14 - Lista de Linguagens ISO 639 Código de Linguagem - ISO 639 Linguagem Reservado - Aa Lingua Afar Da Dinamarquês De Alemão Em Inglês Es Espanhol Eu Basco Fi Finlandês Fr Francês Ga Irlandês It Italiano Nl Holandês No Norueguês Pl Polonês Pt Português Ru Russo Sv Sueco Vi Vietnamita Zu Zulu Fonte: IEEE 1451.0 (2007). 52 O campo, Desativar Idioma (OffSet), é obrigatório e indica o deslocamento do início das TEDS de acordo com o idioma especificado nos dados de informação contidos no XML, normalmente esse campo não é exibido. O campo, Tamanho de Linguagem (Length), é obrigatório e tem a função de localizar a informação mostrada. Esse campo contém o número de octetos no sub-bloco incluindo a soma de verificação. O campo, Enumeração para identificar a técnica de compressão utilizada (Compress), é usado para indicar o algoritmo de compressão usado no bloco de texto de idioma. A Tabela 15 demonstra o valores aceitos para o campo Compress. Tabela 15 - Tabela de Algoritmos de Compressão Enumeração Descrição 0 Significa que nenhuma compressão é usada no bloco de linguagens 1 WinZip 2 GZip 3 Reservado 4-127 Reservado 128-255 Aberto aos fabricantes Fonte: IEEE 1451.0 (2007). O campo, Sem verificação de CheckSum, contém a soma de todos os octetos que o precederam. Esse campo é obrigatório. O campo, XML Baseado em um Bloco de Texto (text), é obrigatório e contém informações sobre todas as TEDS baseadas em texto descrito no padrão IEEE 1451.2. 2.9.5 End User Application Specific TEDS A End User Application Specific TEDS armazena dados no TIM ou TransducerChannel de acordo com o desejado pelo usuário, sendo que cabe ao usuário definir seu conteúdo. Esta TEDS deve ser tanto lida como escrita. O formato da End User Application Specific TEDS é mostrado na Tabela 16 (IEEE 1451.0, 2007): 53 Tabela 16 - Formato da End User Application Specific TEDS ID Descrição Tipo Tipo Octetos - Tamanho da TEDS UInt32 UInt32 4 0-2 - Reservado - - 3 TEDID Cabeçalho pra Identificação de TEDS UInt8 UInt8 4-9 - Reservado - - 10 DadosUsuarioFinal Variado Variado - CheckSum UInt16 2 Fonte: IEEE 1451.0 (2007). A Tabela 16 possui a seguinte descrição para seus campos: O campo, tamanho, define a quantidade de octetos que essa TEDS possui para sua representação. Os campos, cujo ID varia de 0 a 2, são reservados para futuras alterações no padrão. O campo, DadosUsuarioFinal, não é definido no padrão. Ele recebe uma cadeia de caracteres para definir dados de acordo com o especificado pelo usuário. O campo, CheckSum, é usada para validar a quantidade de octetos da TEDS. 2.9.6 Manufacturer-defined TEDS A Manufacturer-defined TEDS pode ser de qualquer formato definido pelo fabricante da aplicação. O sistema não deve tentar analisar esses TEDS ou interpretar seu conteúdo. O sistema deve ler as TEDS e passar para o sistema que fez a requisição as informações. Essa TEDS pode ser somente de leitura ou de leitura e gravação. O conteúdo e estrutura da Manufacturer-defined TEDS é definido pelo usuário (IEEE 1451.0, 2007). 54 2.10 Exemplo de implementação manual de TEDS Nesta seção, apresenta-se a descrição de três TEDS obrigatórias para um sensor simples de temperatura com a intenção de evidenciar o trabalho a ser realizado quando é feita a descrição de uma TEDS por meio manual. As demais TEDS seguem o mesmo esquema apresentado nos exemplos para sua elaboração (IEEE 1451.0, 2007). 2.10.1 Meta-TEDS Nesta seção, é abordada a descrição passo a passo das TEDS para um sensor simples de temperatura. A primeira TEDS a ser descrita é a META-TEDS. Toda TEDS precisa de um campo para identificação. Esse campo é formado por diversos outros campos que em conjunto formam a identificação da TEDS, como segue na Tabela 17. Tabela 17 - Meta-TEDS ID Campo Conteúdo Função Tipo 03 Este campo é usado para identificação da TEDS Tamanho 04 Este campo define a quantidade de octetos que serão usados na descrição. Família 00 Este campo indica qual membro da família de padrões IEEE 1451 definem a TEDS. Classe 01 Identifica qual TEDS está sendo acessada. Versão 01 Identifica a versão das TEDS. Tamanho da Tupla 01 Indica o número de octetos no campo comprimento de todas as tuplas nas TEDS. Fonte: IEEE 1451.0 (2007). Na Tabela 18, o campo, “Tamanho”, é definido pelo padrão IEEE 1451 com o valor 04 obrigatório. O campo, “Classe”, identifica qual TEDS está sendo descrita. O valor 01 é correspondente a Meta-TEDS. O campo, Versão, define que versão da TEDS está definida no Padrão IEEE 1451, sendo que o valor 01 indica que a TEDS está em conformidade com a versão inicial prevista na norma. 55 Realizando-se a conversão dos valores para o formato TLV, tem-se o seguinte conjunto que define o ID da Meta-TEDS: 03 04 00 01 01 01 O próximo campo a ser definido é o UUID, que funciona como o identificador universal da TEDS. Este campo é composto por um conjunto de vários outros campos que são descritos na Tabela 18. Tabela 18 - UUID da Meta TEDS. Campo Descrição Número de Bits 1 Campo de Localização: esse valor é escolhido pelo fabricante do TIM e representa o local exato do fabricante. 42 2 Campo do Fabricante: o valor desse campo deve ser escolhido pelo fabricante do TIM. 4 3 Campo Ano: O valor desse campo deve ser o valor do ano atual. 12 4 Campo Tempo: Esse campo é escolhido pelo fabricante de tal maneira que gere uma combinação única para o UUID. 22 Fonte: IEEE 1451.0 (2007).  Campo de Localização: é definido pelo fabricante do TIM e deve ser preenchido de maneira que os valores de satisfação sejam os requisitos deste campo. Esse campo possui 42 bits, sendo que 20 bits representam a localização quanto a norte e os outros 20 bits representam as coordenadas do sul. E os demais bits representam a magnitude em um arco de segundos.  Campo do Fabricante: deve ser escolhido de maneira que não haja interferências na utilização do Campo de Localização, a interferência ocorre quando dois fabricantes reivindicam o controle físico sobre o mesmo local definido no Campo de Localização.  Campo Ano: O valor desse campo é representado por um inteiro de 12 bits. A variação dos valores para esse campo tem como ano mínimo 4095 D.C.  Campo Tempo: esse campo é representado por um inteiro de 22 bits, e os valores que esse campo pode assumir variam entre 0 a 4194303. Nesse exemplo, foi utilizada a data de 25 de setembro de 2013, sendo que, esse TIM foi gerado com número 120 representado na data especificada. O fabricante deste TIM estava 56 nas seguintes coordenadas: latitude 14367 e longitude 381218. Existe apenas um fabricante para esse ponto, então o Campo do Fabricante assume o valor 0. É necessário para gerar o UUID descobrir qual é o dia do ano que a data 14 de agosto de 2005 corresponde. Neste caso, esse dia corresponde ao dia de número 224. Realizando-se a seguinte operação para descobrir o valor do Campo Tempo: (dia do ano * 1000) + número da unidade produzida no dia. Calculando: Campo Tempo = ((244*1000) +120) = 2.240.120 Convertendo esses valores para binário, temos os valores demostrados na Tabela 19. Tabela 19 - Binário do UUID da Meta TEDS. Campo Valor Binário Quantidade de Bits N/S N 1 1 Latitude 14367 00000011100000011111 20 E/W W 0 1 Longitude 381218 01011101000100100010 20 Fabricante 0 0000 4 Ano 2005 101111000101 12 Data/ Tempo 2240120 1000101001101111011000 22 Fonte: IEEE 1451.0 (2007). O próximo passo, após a conversão dos valores para binário, diz respeito a união de todos os binários, gerando uma string da seguinte maneira: 10000001 11000000 11111001 01110100 01001000 10000010 11