josé de anchieta gomes dos santos · 2017. 11. 3. · josé de anchieta gomes dos santos...
TRANSCRIPT
-
José de Anchieta Gomes dos Santos
Arquitetura Hardware/Software de um Núcleo
NCAP Segundo o Padrão IEEE 1451.1: Uma
prova de conceito
Natal-RN
2010
-
José de Anchieta Gomes dos Santos
Arquitetura Hardware/Software de um Núcleo
NCAP Segundo o Padrão IEEE 1451.1: Uma
prova de conceito
Dissertação de mestrado apresentada ao Pro-grama de Pós-graduação em Sistemas e Com-putação do Departamento de Informática eMatemática Aplicada da Universidade Fed-eral do Rio Grande do Norte, como requisitoparcial para a obtenção do grau de Mestreem Ciência da Computação.
Orientador: Prof. Dr. Ivan Saraiva Silva
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-graduação em Sistemas e Computação
Natal-RN
2010
-
Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial
Especializada do Centro de Ciências Exatas e da Terra – CCET.
Santos, José de Anchieta Gomes dos. Arquitetura hardware/software de um núcleo NCAP segundo o padrão IEEE 1451.1: uma prova de conceito. – Natal, 2010. 89 f. : il.
Orientador: Prof. Dr. Ivan Saraiva Silva. Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro
de Ciências Exatas e da Terra. Departamento de Informática e Matemática Aplicada. Programa de Pós-Graduação em Sistemas e Computação.
1. Arquitetura de computador – Dissertação. 2. Sensores inteligentes -
Dissertação. 3. Padrão IEEE – Dissertação. I. Silva, Ivan Saraiva. II. Título. RN/UF/BSE-CCET CDU: 004.2
-
i
Trabalho de Conclusão de Curso de Mestrado sob o título �Arquitetura Hardware/-
Software de um núcleo NCAP Segundo o Padrão IEEE 1451.1: Uma Prova de Conceito�,
defendida por José de Anchieta Gomes dos Santos em 06 de Agosto de 2010, em Natal,
Estado do Rio Grande do Norte, e aprovado pela banca examinadora constituída pelos
professores:
Prof. D.Sc. Ivan Saraiva SilvaOrientador - UFPI - PpgSC
Prof. D.Sc. Marcio Eduardo Kreutz -UFRN
Prof. D.Sc. Karla Darlene NepomucenoRamos - UERN
Prof. D.Sc. Cláudia Maria FernandesAraújo Ribeiro - UERN
-
ii
Dedico ao meu pai Joaquim
Maciel dos Santos (in
memórian), que sempre
incentivou a minha formação
intelectual.
-
iii
Agradecimentos
Depois de mais uma etapa importante que se cumpre da minha vida, eu não poderia
deixar de agradecer àqueles que estiveram presentes, me incentivando e apoiando, ou
mesmo contribuindo de alguma forma para que esse momento se tornasse prazeiroso.
Agradeço a minha família, em especial minha mãe Maria do Rosário e minhas irmâs
Raquel e Érica, que sempre me ajudaram nos momentos de di�culdades e �zeram de tudo
para que esta caminhada se tornasse o mais estimulante possível.
Agradeço ao meu orientador Ivan Saraiva, pela con�ança prestada e pelos momentos
de aprendizado proporcionados.
Não posso deixar de agradecer ao companheiros do laboratório do mestrado, no qual
passei um ano convivendo diretamente com os mesmos. Boas histórias e caminhadas lon-
gas para o restaurante universitário. Dentre os quais posso lembrar: Isaac, Natal, Cássio,
Cléverton, Arinaldo, Stheperson, Íria, Anderson e Valério. Dona Fátima, a frequentadora
do laboratório, não poderia deixar de ser lembrada.
Muito menos deixaria de agradecer os momentos de convivência, aprendizado e prin-
cipalmente diversão proporcionados pelos amigos do LASIC. Bruno, Alba, Tadeu, Sílvio,
Miklécio e Christiane.
-
iv
Resumo
Os sensores inteligentes são dispositivos que se diferenciam dos sensores comuns porapresentar capacidade de processamento sobre os dados monitorados. Eles tipicamente sãocompostos por uma fonte de alimentação, transdutores (sensores e atuadores), memória,processador e transceptor. De acordo com o padrão IEEE 1451 um sensor inteligentepode ser dividido em módulos TIM e NCAP que devem se comunicar através de umainterface padronizada chamada TII. O módulo NCAP é a parte do sensor inteligenteque comporta o processador. Portanto, ele é o responsável por atribuir a característicade inteligência ao sensor. Existem várias abordagens que podem ser utilizadas para odesenvolvimento desse módulo, dentre elas se destacam aquelas que utilizam microcon-troladores de baixo custo e/ou FPGA. Este trabalho aborda o desenvolvimento de umaarquitetura hardware/software para um módulo NCAP segundo o padrão IEEE 1451.1. Ainfra-estrutura de hardware é composta por um driver de interface RS-232, uma memóriaRAM de 512kB, uma interface TII, o processador embarcado NIOS II e um simuladordo módulo TIM. Para integração dos componentes de hardware é utilizada ferramentade integração automática SOPC Builder. A infra-estrutura de software é composta pelopadrão IEEE 1451.1 e pela aplicação especí�ca do NCAP que simula o monitoramentode pressão e temperatura em poços de petróleo com o objetivo de detectar vazamento.O módulo proposto é embarcado em uma FPGA e para a sua prototipação é usada aplaca DE2 da Altera que contém a FPGA Cyclone II EP2C35F672C6. O processadorembarcado NIOS II é utilizado para dar suporte à infra-estrutura de software do NCAPque é desenvolvido na linguagem C e se baseia no padrão IEEE 1451.1. A descrição docomportamento da infra-estrutura de hardware é feita utilizando a linguagem VHDL.
Palavras-Chave: Arquitetura de Computadores; Sensores Inteligentes; Padrão IEEE1451.
-
v
Abstract
Smart sensors are di�erent of ordinary sensors because they have processing capacityover the data monitored. In general they are composed by a power source, transducers(sensors and actuators), memory, processor and transceiver. According to IEEE 1451a smart sensor can be divided in TIM and NCAP modules that must to communicateitself through a standard interface called TII. The NCAP module is the part of the smartsensor which contains the processor. Therefore, it is the responsible to attribute thefeature of intelligence to the sensor. There are many approaches used to develop thismodule. Those using low-cost microcontrollers and/or FPGA stand out among them. Inthis work is shown a hardware/software architecture to a NCAP module following theIEEE 1451.1 standard. The hardware infrastructure is composed by a RS-232 Interfacedriver, a memory RAM of 512KB, a TII interface, the embedded processor NIOS II andthe TIM simulator. To integrate the system is used a tool for automatic integration calledSOPC Builder. The software infrastructure is composed by the IEEE 1451.1 standardand the speci�c application of the NCAP that works simulating the monitoring processof temperature and pressure in oleo wells to identify oil spill. The proposed module isembedded in FPGA and to the prototyping of it is used an Altera's DE2 board thatcontains the FPGA Cyclone II EP2C35F672C6. The embedded processor NIOS II is usedto support the software infrastructure of the NCAP that is developed in C language andbased on the IEEE 1451.1 standard. The hardware infrastructure behavior description ismade using the VHDL language.
Keywords: Computer Architecture; Smart Sensors; Standard IEEE 1451.
-
vi
Sumário
Lista de Figuras p. ix
Lista de Tabelas p. xi
Lista de Abreviaturas e Siglas p. xii
1 Introdução p. 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 3
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 5
1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . p. 5
2 Trabalhos relacionados p. 7
3 Sensores Inteligentes p. 11
3.1 Padrão IEEE 1451 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14
3.2 Módulo NCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16
3.2.1 Padrão IEEE 1451.1 . . . . . . . . . . . . . . . . . . . . . . . . p. 17
3.2.2 Mínimo IEEE 1451.1 . . . . . . . . . . . . . . . . . . . . . . . . p. 23
3.3 Módulo TIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 26
3.3.1 Endereçamento . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27
3.3.1.1 Endereçamento de Canal . . . . . . . . . . . . . . . . . p. 29
3.3.1.2 Endereçamento de Função . . . . . . . . . . . . . . . . p. 29
3.3.2 Transporte de dados . . . . . . . . . . . . . . . . . . . . . . . . p. 30
3.3.3 Disparo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30
-
vii
3.3.4 Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 31
3.3.5 Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
3.3.6 Interrupção . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
3.4 Interface Independente de Transdutor . . . . . . . . . . . . . . . . . . . p. 35
3.4.1 Aspectos Elétricos e Físicos da TII . . . . . . . . . . . . . . . . p. 35
3.4.2 Protocolos de Comunicação e Sincronização . . . . . . . . . . . p. 37
3.4.2.1 Disparo . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
3.4.2.2 Transferência de Bits . . . . . . . . . . . . . . . . . . . p. 39
3.4.2.3 Transferência de Bytes . . . . . . . . . . . . . . . . . . p. 39
3.4.2.4 Protocolo de Transferência de Quadro de Leitura . . . p. 40
3.4.2.5 Protocolo de Transferência de Quadro de Escrita . . . p. 40
4 Arquitetura Hardware/Software do Núcleo NCAP p. 41
4.1 Placa DE2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
4.2 NIOS II e SOPC Builder . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44
4.3 Infra-estruturas de Hardware e Software . . . . . . . . . . . . . . . . . p. 45
4.3.1 Infra-estrutura de Hardware . . . . . . . . . . . . . . . . . . . . p. 45
4.3.1.1 Interface RS-232 . . . . . . . . . . . . . . . . . . . . . p. 46
4.3.1.2 Interface TII . . . . . . . . . . . . . . . . . . . . . . . p. 47
4.3.1.3 Simulador do Módulo TIM . . . . . . . . . . . . . . . p. 49
4.3.2 Infra-estrutura de Software . . . . . . . . . . . . . . . . . . . . . p. 53
4.3.2.1 Funções de Middleware . . . . . . . . . . . . . . . . . p. 56
4.3.3 Comunicação Hardware/Software . . . . . . . . . . . . . . . . . p. 59
5 Testes e Análises p. 64
5.1 Cenário de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
5.2 Testes de software do NCAP . . . . . . . . . . . . . . . . . . . . . . . . p. 69
-
viii
5.3 Resultados de custo e desempenho da infra-estrutura de hardware . . . p. 74
6 Conclusões e Trabalhos Futuros p. 77
6.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 78
Referências p. 80
Apêndice p. 83
Funções da Hardware Abstraction Layer do NIOS . . . . . . . . . . . . . . . p. 83
Anexo p. 85
Código dos Estados do Software do NCAP . . . . . . . . . . . . . . . . . . . p. 85
-
ix
Lista de Figuras
1 Diagrama de blocos do NCAP do RIICS. Adaptado: (KOCHAN et al., 2004). p. 9
2 Estrutura do NCAP baseado em FPGA. Adptado: (TURCHENKO et al.,
2005). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 9
3 Componentes básicos de um típico sensor inteligente. . . . . . . . . . . p. 12
4 (a) Modelo de um sensor inteligente. (b) Modelo de sensor inteligente
com a divisão em módulos TIM, NCAP e TII. Adaptado: Song e Lee
(2008). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 13
5 Situação onde há comunicação entre NCAPs. . . . . . . . . . . . . . . . p. 18
6 Hierarquia de classes do modelo de objeto do IEEE 1451.1. Fonte:
(STEPANENKO et al., 2006). . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
7 Hierarquia de classes do mínimo IEEE 1451.1. Fonte: Stepanenko et al.
(2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
8 Diferentes formas de se implementar o módulo TIM. Fonte: Martins (2005). p. 28
9 Estrutura de endereçamento completo. Adaptado: IEEE-Std-1451.2-
1997 (1997). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
10 Ciclo de disparo no TIM. Fonte: Martins (2005). . . . . . . . . . . . . . p. 31
11 Interface Independente de transdutor entre o STIM e o NCAP. Fonte:
Martins (2005). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 35
12 Protocolo geral de transferência de dados. Fonte: Martins (2005). . . . p. 38
13 Placa de desenvolvimento DE2. Fonte: Altera (2009). . . . . . . . . . . p. 43
14 Arquitetura do NCAP. . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45
15 Arquitetura da Interface TII. . . . . . . . . . . . . . . . . . . . . . . . p. 48
16 Arquitetura do simulador do TIM. . . . . . . . . . . . . . . . . . . . . p. 50
-
x
17 Escolha da variação randômica a partir do número randômico gerado
pelo Xorshift. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
18 Maquina de estados da infraestrutura de software. . . . . . . . . . . . . p. 55
19 Comunicação NCAP e TII via Barramento Avalon. . . . . . . . . . . . p. 60
20 Writedata enviado pelo barramento e o modo como a interface TII o
interpreta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61
21 Address enviado pelo barramento e o modo como a interface TII o inter-
preta. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
22 Cenário de uso para o NCAP proposto. . . . . . . . . . . . . . . . . . . p. 65
23 Placas DE2 se comunicando através de uma interface RS-232. . . . . . p. 65
24 Função de inicialização do NCAP. . . . . . . . . . . . . . . . . . . . . . p. 66
25 Função de espera do NCAP. . . . . . . . . . . . . . . . . . . . . . . . . p. 68
26 Projeto �nal do NCAP integrado no SOPCBuilder. . . . . . . . . . . . p. 70
27 Teste da inicialização pelo Performance Counter. . . . . . . . . . . . . . p. 71
28 Função de veri�cação do NCAP. . . . . . . . . . . . . . . . . . . . . . . p. 73
29 Veri�cação de chave de solicitação. . . . . . . . . . . . . . . . . . . . . p. 74
30 Função de inicialização do NCAP. . . . . . . . . . . . . . . . . . . . . . p. 85
31 Função de espera do NCAP. . . . . . . . . . . . . . . . . . . . . . . . . p. 86
32 Função de veri�cação do NCAP. . . . . . . . . . . . . . . . . . . . . . . p. 87
33 Função de inatividade do NCAP. . . . . . . . . . . . . . . . . . . . . . p. 88
34 Função de publicação do NCAP. . . . . . . . . . . . . . . . . . . . . . . p. 89
-
xi
Lista de Tabelas
1 Tipos primitivos de dados. . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
2 Direção da comunicação. . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29
3 Comandos de controle do módulo TIM. . . . . . . . . . . . . . . . . . . p. 32
4 Registrador de estados padrão. . . . . . . . . . . . . . . . . . . . . . . . p. 33
5 Registrador de estados Auxiliar. . . . . . . . . . . . . . . . . . . . . . . p. 34
6 De�nição das portas da TII. . . . . . . . . . . . . . . . . . . . . . . . . p. 36
7 Atribuição de pinos e cores recomendada pelo padrão para a TII. . . . p. 37
8 Registradores do driver de interface RS-232 da Altera. . . . . . . . . . . p. 46
9 Tabela de funções comuns do TIM. . . . . . . . . . . . . . . . . . . . . p. 52
10 Tabela de chaves de publicação e subscrição do padrão IEEE 1451.1. . . p. 58
11 Tabela das novas chaves de publicação. . . . . . . . . . . . . . . . . . . p. 59
12 Tabela de comandos de controle. . . . . . . . . . . . . . . . . . . . . . . p. 62
13 Tabela de latência média de resposta a solicitação. . . . . . . . . . . . . p. 72
14 Tabela de custo do NCAP. . . . . . . . . . . . . . . . . . . . . . . . . . p. 75
15 Tabela de desempenho das operações do NCAP. . . . . . . . . . . . . . p. 75
-
xii
Lista de Abreviaturas e Siglas
LANs - Local Area Networks
MEMS - Micro-Electro Mechanical Systems
TC-9 - Technical Committee on Sensor Technology
NIST - National Institute of Standards and Technology
NCAP - Network Capable Application Processor
TIM - Transducer Independent Module
TII - Transducer Independent Interface
VHDL - VHSIC Hardware Description Language
VHSIC - Very High Speed Integrated Circuits
RSCH - Redes de Sensores para o Corpo Humano
CAN - Controller Area Network
USB - Universal Serial Bus
IRC - controlador de interface e reprogramação
TEDS - Transducer Eletronic Data Sheet
UML - Uni�ed Modeling Lenguage
CAD - Conversor Analógico-Digital
CDA - Conversor Digital-Analógico
ASIC - Application Speci�c Integration Circuit
SPI - Serial Peripheral Interface
IDE - Integrated Development Environment
SOPC - System-On-a-Programmable-Chip
GUI - Graphical User Interface
-
xiii
UART - Universal Asynchronous Receiver/Transmitter
ISR - Interruption Service Routine
HAL - Hardware Abstraction Layer
-
1
1 Introdução
O monitoramento de variáveis ambientais tais como temperatura, som, luz e pressão
é uma atividade que possibilita a análise remota de dados medidos através de um sistema
de controle e medida de informação. Os modernos sistemas de controle e medida da
informação possuem seus recursos distribuídos e são normalmente construídos como redes
locais, também conhecidas como LANs (Local Area Networks) . Esses sistemas permitem
que os dados possam ser monitorados remotamente por um usuário que pode estar próximo
ao local de medida, bem como localizado a centenas de quilômetros de distância do mesmo,
recebendo essas informações através de uma rede como a Internet.
O transdutor é o componente de um sistema de controle e medida composto por
sensores ou atuadores e em certos casos ambos. O sensor realiza a medição da variável
desejada transformando um fenômeno físico em um formato digital capaz de ser com-
putado e analisado pelo usuário, enquanto o atuador recebe uma informação em formato
digital e a transforma em um fenômeno físico, o que possibilita o usuário interagir com o
ambiente monitorado (SONG; LEE, 2008).
Segundo Oliveira (2004), os avanços na tecnologia dos sistemas micro-eletromecânicos
MEMS (Micro-Electro Mechanical Systems) �zeram com que os sensores pudessem re-
alizar atividades além daquelas necessárias para gerar apenas uma correta representação
dos dados. Esses sensores passaram a fazer parte de uma nova classe conhecida como
sensores inteligentes.
Os sensores inteligentes se diferenciam do sensor comum por possuírem a capacidade
de processamento on-board sobre os dados monitorados. Essa característica permite que
decisões sejam tomadas em tempo-real no próprio sensor inteligente. Desse modo, apenas
os dados que necessitam de uma análise mais complexa é que são enviados para o usuário
�nal1.1Usuário �nal é aquele que irá realizar as análises sobre os dados coletados, podendo também enviar
comandos a serem realizados pelo sensor inteligente.
-
2
Em 1993, o Comitê Técnico em Tecnologia dos Sensores - TC-9 (Technical Com-
mittee on Sensor Technology) da Sociedade de Instrumentação e Medidas IEEE - IEEE
Instrumentation and Measurement Society com a parceria do Instituto Americano de
Padrões e Medidas - NIST (National Institute of Standards and Technology) criaram
uma iniciativa que dividiu o sensor inteligente em dois módulos. Um deles é o módulo
NCAP (Network Capable Application Processor) ou processador de aplicação capaz de
se comunicar em rede que é responsável pelo processamento de dados e comunicação do
sensor em rede com o usuário �nal. O outro é o módulo TIM (Transducer Independent
Module) ou módulo independente de transdutor que contém os transdutores (sensores e
atuadores), o equipamento de conversão de sinal e de condicionamento do mesmo.
Essa iniciativa levou a uma série de especi�cações para o desenvolvimento padronizado
desses módulos que passaram a se comunicar através de uma interface também
padronizada chamada TII (Transducer Independent Interface) ou Interface Indepen-
dente de Transdutor. Essas especi�cações constituem o padrão IEEE 1451 que tem entre
seus objetivos proporcionar que módulos TIM e NCAP de diferentes fabricantes possam
operar em conjunto.
O módulo NCAP é a parte do sensor inteligente responsável por atribuir inteligência
ao mesmo, uma vez que é capaz de realizar o processamento dos dados. Desse modo,
esse módulo passa a conter o elemento principal que diferencia o sensor inteligente de um
sensor comum. Este é um fato que contribuiu para que o presente trabalho possua seu
foco sobre esse módulo.
Em Mayikiv et al. (2007) podem ser vistas algumas das abordagens utilizadas para o
desenvolvimento de módulos NCAPs. Nesse trabalho é feita uma análise dessas aborda-
gens, a qual conclui que o desenvolvimento de NCAP utilizando microcontroladores e/ou
FPGA re�ete uma tendência nessa área de pesquisa.
Neste trabalho é desenvolvido um módulo NCAP completamente embarcado em uma
FPGA. Esse módulo é desenvolvido baseado no padrão IEEE 1451.1 que especi�ca os re-
quisitos necessários ao software desse módulo para que possa ocorrer a troca de informação
entre NCAPs. Esse software é implementado utilizando a linguagem C e protoripado na
placa DE2 da Altera através do suporte do processador embarcado NIOS II. Esse NCAP
possui módulos de comunicação entre NCAPs através de uma interface RS-232 e com o
módulo que simula o TIM através de um módulo de interface TII que segue o padrão
IEEE 1451.2. Tanto o módulo que simula o TIM como a interface TII são desenvolvidos
utilizando a linguagem de descrição de hardware VHDL (VHSIC Hardware Description
-
3
Language) , também chamada de linguagem de descrição de hardware VHSIC (Very
High Speed Integrated Circuits) .
No decorrer deste documento são apresentados maiores detalhes sobre as abordagens
de desenvolvimento de módulos NCAP e sobre sensores inteligentes. Esses sensores serão
apresentados de acordo com o padrão IEEE 1451.
1.1 Motivação
Os sensores estão sendo utilizados em várias aplicações que estão presentes na vida
das pessoas, abrangendo desde atividades como automação industrial ou o controle e
monitoramento da condição ambiental a sistemas de transporte inteligentes ou de defesa
militar.
Em Machado (2005), é destacado o uso de sensores em áreas de grande importância
como aviação: auxiliando no controle de tráfego aéreo; medicina: na utilização das RSCH
(Redes de Sensores para o Corpo Humano) que servem para monitorar a temperatura
do corpo e auxiliar na identi�cação de patologias como a trombose; militar: detectando a
presença de inimigos ou substâncias químicas em um determinado local; meio ambiente:
monitorando a temperatura e até mesmo abalos sísmicos, vulcões ou terremotos em uma
região; tráfego: monitorando o respeito ao limite de velocidade estabelecido nas vias;
industrial: monitoramento dos dispositivos de fábrica.
O uso de sensores permite o monitoramento de variáveis como temperatura, pressão,
aceleração e potencial ácido sem a necessidade do usuário se deslocar ao local de moni-
toramento. Desse modo, mesmo à distância o usuário pode ter acesso e controle sobre os
dados monitorados, o que se torna de grande utilidade em situações como a de alerta de
incêndio em regiões �orestais ou mesmo na detecção de abalos sísmicos próximos a repre-
sas. Nesses casos, o uso de sensores pode captar um aumento elevado na temperatura ou
fenômenos que indiquem abalos sísmicos e assim a população próxima a esses locais pode
ser alertada com antecedência. São muitos os benefícios que essa tecnologia trás para
os seres humanos e por isso toda a contribuição e pesquisa nessa área assume um valor
relevante diante da sociedade.
O aumento do uso de sensores no cotidiano das pessoas tem sido estimulado pelo
desenvolvimento na área dos microprocessadores, sistemas embarcados e comunicação
sem �o. Outro fator estimulante foi o avanço na tecnologia dos transdutores (sensores e
atuadores) que propiciou a inclusão de microcontroladores como complemento do sensor,
-
4
agregando a ele funcionalidades não restritas apenas a aquisição de dados. Desse modo
o sensor passou a executar programas de correção, efetuar calibrações e interligar-se em
rede para o compartilhamento de dados e informações (SAUSEN et al., 2007),(OLIVEIRA,
2004).
Devido a esses avanços o sensor passa a ter característica inteligente, uma vez que é
capaz de realizar algum tipo de processamento de dados on-board sobre os dados moni-
torados. O padrão IEEE 1451 dividiu o sensor inteligente em módulos TIM e NCAP que
utilizam a TII como interface padrão de comunicação. No módulo NCAP, que é o foco
desse trabalho, se encontram o processador, a memória e o transceptor, ou seja, a parte
de processamento de dados, de armazenamento dos mesmos e de comunicação. Por conter
o processador, o módulo NCAP é considerado como o módulo responsável por atribuir
inteligência ao sensor inteligente (GUMUDAVELLI et al., 2009). Este fato faz com que as
pesquisas acerca do NCAP possuam uma certa relevância.
Até pouco tempo atrás trabalhos como os de Wobschall (2002) e Viegas et al. (2005)
evidenciavam o signi�cativo avanço que representa o padrão IEEE 1451, bem como a limi-
tação na adoção desse padrão por parte das empresas devido a falta de NCAP disponível.
Atualmente, já podem ser encontrados alguns trabalhos como Franzl e Gurkan (2009) e
Viegas et al. (2007) que abordam o desenvolvimento de módulos NCAP seguindo esse
padrão. Porém, ainda podem ser encontrados casos como o da Smart Sensor System
que desenvolve e disponibiliza um módulo TIM sem desenvolver o módulo NCAP. Ao
invés disso, é disponibilizado um NCAP virtual que só executa sob o sistema operacional
Windows e necessita do Microsoft Visual Studio. Tais requisitos especí�cos acabam tor-
nando alto o custo desse NCAP e abrem espaço para uma abordagem de desenvolvimento
baseada em microcontroladores ou FPGA.
Um importante e recente trabalho na área de sensores inteligentes é Mayikiv et al.
(2007). Esta literatura trata dos assuntos e abordagens existentes utilizados para o desen-
volvimento de módulos NCAPs. Nele pode-se encontrar as empresas que estão desenvol-
vendo esses módulos e qual a abordagem utilizada pelas mesmas. Também é mostrado que
a abordagem de desenvolvimento utilizando microcontroladores de baixo custo representa
uma tendência nessa área de pesquisa.
Os estudos bibliográ�cos acerca dos sensores inteligentes possibilitaram identi�car
como uma forma signi�cativa de contribuição para o presente trabalho o desenvolvimento
de uma arquitetura hardware/software de um núcleo NCAP que opere de acordo com
o padrão IEEE 1451.1. Tal arquitetura é uma nova abordagem de desenvolvimento que
-
5
serve como uma prova de conceito para um NCAP completamente embarcado em FPGA.
1.2 Objetivos
O objetivo deste trabalho é o desenvolvimento de um módulo NCAP usando FPGA.
Esse módulo deve prover a parte de inteligência do sensor inteligente por atribuir ao
mesmo a capacidade de processamento de dados simples. Além disso, ele deve possuir
capacidade de comunicação em rede tanto com outro NCAP através de uma interface RS-
232 como com o módulo TIM através de uma interface serial padronizada. Esse trabalho
pode ser subdividido nos seguintes objetivos especí�cos:
Contribuir com uma fonte a mais de pesquisa na área de sensores inteligentes e o
uso do padrão IEEE 1451.
Estudo das abordagens de desenvolvimento já existentes para módulo NCAP.
Desenvolvimento de infra-estruturas de hardware e software para um NCAP que
sigam o padrão IEEE 1451.
Uso de uma FPGA para desenvolvimento do NCAP e seus módulos de comunicação
de alto e baixo nível.
Desenvolvimento de funções de middleware para o NCAP.
Realizar testes e análises sobre o módulo NCAP desenvolvido.
Concluir sobre os resultados dos testes e análises feitos sobre o NCAP.
1.3 Estrutura do documento
Este trabalho se encontra organizado em 6 capítulos que estão sub-divididos em seções.
Cada capítulo procura contribuir de alguma forma para o esclarecimento da pesquisa.
Existem também alguns capítulos teóricos que possuem informações extras acerca de
sensores inteligentes e não apenas sobre o módulo NCAP que é o foco deste trabalho.
O capítulo 2 apresenta os trabalhos relacionados a este e que contribuíram de alguma
forma para o desenvolvimento do mesmo. Esse capítulo inicia com uma visão mais geral
sobre trabalhos na área de sensores inteligentes, porém seu �nal tem um foco no módulo
NCAP que é o objeto de estudo desse trabalho.
-
6
O capítulo 3 aborda a tecnologia dos sensores inteligentes, seus conceitos, de�nições
e sua relação com o padrão IEEE 1451. Além do módulo NCAP esse capítulo apresenta
o módulo TIM e a interface independente de transdutor para que em teoria o trabalho
possa abranger todo o sensor inteligente, sendo assim, uma fonte de pesquisa mais rica e
completa.
O capítulo 4 apresenta a proposta desse trabalho. Os módulos que serão desenvolvidos,
bem como os equipamentos e linguagens que são utilizados para este �m. Este capítulo
também apresenta alguns detalhes sobre a característica do módulo implementado, bem
como as infra-estruturas de hardware e software do NCAP.
No capítulo 5 são expostos os testes e análises do módulo NCAP desenvolvido, bem
como o cenário de uso que foi simulado nos testes.
O capítulo 6 possui as conclusões sobre o trabalho e os trabalhos futuros que podem
ser realizados a partir das contribuições que foram deixadas por este.
-
7
2 Trabalhos relacionados
Na literatura podem ser encontradas algumas obras relacionadas com a área de
pesquisa deste trabalho. Alguns desses trabalhos abordam pesquisas mais gerais sobre
sensores inteligentes enquanto outras possuem um foco mais especí�co no módulo NCAP,
assim como este trabalho.
Entre os trabalhos que possuem propósito mais geral acerca dos sensores inteligentes
podem ser destacados o de Buzdugan e Nascu (2008), de Hamrita et al. (2005) e de Song
e Lee (2008).
Em Buzdugan e Nascu (2008) pode ser encontrada uma visão geral sobre a tecnologia
dos sensores inteligentes e sua relação com o padrão IEEE 1451. Três tipos de aplicações
são desenvolvidas com o uso de sensores inteligentes. A primeira trata-se de uma inter-
face de aquisição de dados para o controle e monitoramento de aplicações industriais. A
segunda é um sistema de controle e aquisição de dados para diminuir os erros dos estu-
dantes na conexão dos equipamentos de hardware em laboratório. A terceira aplicação
é um sistema de gerenciamento de energia baseado em sensores inteligentes. Para essas
aplicações foram desenvolvidos sensores inteligentes seguindo o padrão IEEE 1451.
Na obra de Hamrita et al. (2005) são apresentados os avanços ocorridos na área
dos sensores inteligentes, bem como conceitos e de�nições importantes nessa área. Esse
trabalho possui um foco em redes de sensores inteligentes sem �o. Nele é desenvolvido um
sistema integrado utilizando sensores MICA2DOT do projeto MOTES da universidade
de Berkeley. Os sensores desse sistema são dirigidos a eventos e o acesso aos dados são
feitos através da tecnologia RFID.
Em Song e Lee (2008) é apresentado o padrão IEEE 1451 e seus modos de desenvolvi-
mento. Nela é claramente apresentada a diferença entre um sensor inteligente comum e
um sensor inteligente seguindo esse padrão. Nela também podem ser encontradas todas
as normas existentes na família IEEE 1451, bem como as normas que ainda se encontram
em fase de projeto.
-
8
Outros trabalhos possuem um foco nas abordagens de implementação do módulo
NCAP. Tais implementações visam o desenvolvimento de um módulo com capacidade de
processamento, capaz de se comunicar em rede com o usuário �nal e com o módulo TIM.
Em Mayikiv et al. (2007), é feita uma comparação entre algumas abordagens de
desenvolvimento existentes para o módulo NCAP, onde são destacadas suas vantagens
e desvantagens. Portanto, considerando esse trabalho, a seguir serão apresentadas essas
abordagens, bem como as empresas ou instituições responsáveis pelo seu desenvolvimento.
Uma abordagem é a da 3eTechnologies International que é uma empresa que desde o
ano de 2006 foi adquirida pela EF Johnson Technology (TECHNOLOGIES, 2009). Essa em-
presa implementava um módulo NCAP com propósito especí�co para sistemas de controle
militar. O módulo implementado por essa empresa é baseado em um processador Intel
Pentium e tem como requisito o sistema operacional Microsoft Windows. A sua vantagem
é o suporte à uma ampla quantidade de interfaces de rede e ao processamento de dados
avançados. Porém, os requisitos especí�cos impostos sobre o equipamento tornam seu
custo de implementação alto.
Outra abordagem é a da Kontron que é uma empresa que trabalha com computação
embarcada nas áreas de telecomunicação, computação móvel, computação medicinal e
aeroespacial (KONTRON, 2009). Esta empresa possui uma série de controladores de rede
denominados ThinkIO, capazes de realizar funções similares as de um módulo NCAP.
Para realizar suas funções esses controladores necessitam de um processador Intel Celeron
M (600MHz) ou um Pentium M (1,4GHz) e como sistema operacional necessitam do Mi-
crosoft Windows XP Embedded. Eles possuem suporte a um amplo conjunto de interfaces
de comunicação, entre elas estão CAN (Controller Area Network) , USB (Universal
Serial Bus) e duas portas Ethernet. Seu custo é bastante elevado devido aos requisitos
necessários para o seu desenvolvimento.
A Esensors Inc. trabalha com o monitoramento de variáveis ambientais através de
sensores (ESENSORS, 2009). O módulo NCAP desenvolvido por essa empresa é baseado
em microcontroladores. Ele possui uma interface Ethernet para comunicação de alto nível
e sete outras diferentes interfaces para comunicação em baixo nível. Essa abordagem de
desenvolvimento tem a vantagem de possuir um baixo custo devido ao uso de microcontro-
ladores de baixo custo em sua implementação, porém não possui nenhum processamento
de dados especí�co, o que diminui o seu potencial de inteligência.
O RIICS (Research Institute of Intelligent Computer Systems) é um instituto de Tec-
nologia da informação (TI) que trabalha com o gerenciamento de projetos e integração de
-
9
sistemas (RIICS, 2009). O NCAP implementado por esse instituto possui uma arquitetura
baseada em dois microcontroladores de baixo custo. Um desses microcontroladores é res-
ponsável por realizar processamento de dados, enquanto o outro atua como controlador
de con�guração. O NCAP possui suporte a um conjunto de interfaces de comunicação
tais como RS-232, RS-485, SPI e ISA-8. O uso dos microcontroladores reduz bastante o
custo de implementação desse módulo e ele possui a vantagem em relação ao NCAP da
Esensors pelo fato de possuir capacidade de processamento de dados.
A �gura 1 mostra o diagrama de blocos do NCAP do RIICS. Nela pode-se ver o
microcontrolador principal se comunicando com a memória e com o IRC (controlador de
interface e reprogramação) , este por sua vez é o responsável por controlar a comunicação
entre o controlador principal e as interfaces de hardware.
Figura 1: Diagrama de blocos do NCAP do RIICS. Adaptado: (KOCHAN et al., 2004).
Um outro módulo NCAP que não foi abordado por Mayikiv et al. (2007) é o NCAP
baseado em FPGA de Turchenko et al. (2005). Esse NCAP é uma evolução do NCAP
reprogramável baseado em microcontroladores de baixo custo do RIICS. Ele possui uma
arquitetura formada por dois microcontroladores de baixo custo e faz uso de um FPGA
para dar suporte a interfaces de alta velocidade como CAN e USB.
Figura 2: Estrutura do NCAP baseado em FPGA. Adptado: (TURCHENKO et al., 2005).
Na �gura 2 é mostrada a estrutura do NCAP baseado em FPGA. Nesse NCAP o IRC
-
10
é formado por um microcontrolador que atua como controlador de con�guração, por um
FPGA e por uma interface de hardware.
A seguir será apresentado um capítulo sobre sensores inteligentes. Esse capítulo possui
um foco no padrão IEEE 1451 e por isso serão apresentados os módulos NCAP e TIM,
bem como a interface TII.
-
11
3 Sensores Inteligentes
Um transdutor é um dispositivo capaz de transformar um tipo de energia em outro.
Ele pode ser formado por sensores ou atuadores e em certos casos por ambos. Nesse sen-
tido, um sensor é um transdutor que gera um sinal elétrico proporcional a um parâmetro
físico, químico ou biológico, enquanto um atuador é um transdutor que aceita um sinal
elétrico e o torna em um efeito físico (SONG; LEE, 2008).
Segundo Hamrita et al. (2005), existem três gerações de sensores. A primeira geração é
composta por sensores que realizam apenas o monitoramento dos dados a serem medidos.
A segunda geração é composta por sensores que possuem a capacidade de realizar cálculos
computacionais sobre os dados monitorados. E a terceira geração possibilita que esses
sensores possam se comunicar e trocar informações entre si. Esses sensores formam o que
se conhece por redes de sensores.
A primeira e a segunda geração são vistas em Al-Ali et al. (2005) como sendo sen-
sores ordinários e sensores inteligentes, respectivamente. Segundo o mesmo, um sensor
ordinário é aquele que necessita de um circuito externo dedicado para realizar a análise de
sinal, compensação de erro e �ltragem dos dados monitorados. Já o sensor inteligente é o
sensor que possui um circuito interno para realizar o condicionamento de sinal e para pro-
porcionar um processamento especí�co dos dados no sistema. Alguns sensores inteligentes
podem ser reprogramados para que possam atender a novos requisitos do usuário.
Uma boa de�nição de sensores inteligentes pode ser encontrada em Zhang et al. (2004).
Essa de�nição diz que um sensor inteligente é aquele que possui funcionalidades além
daquelas necessárias para gerar a correta representação dos dados sensoriados ou das
medidas controladas.
Essas de�nições permitem diferenciar um sensor inteligente de um sensor comum. O
sensor comum possui as funções básicas necessárias para a medição e a correta represen-
tação dos dados sensoriados. O sensor inteligente possui a capacidade de processamento
sobre os dados sensoriados, bem como a capacidade de diagnóstico on-board sobre o es-
-
12
tado do sensor. A capacidade de processamento do sensor inteligente faz com que ele
possa realizar processamentos simples sobre os dados sensoriados, o que permite que o
sensor possa tomar decisões em tempo-real quanto ao estado da aplicação. Já a capaci-
dade de diagnóstico on-board se refere à capacidade do sensor poder identi�car e gerenciar
o consumo de energia, testar a comunicação com outros sensores ou mesmo com outros
dispositivos que possam estar ligados a ele.
Entenda-se por processamento simples aquele que permite uma análise de dados cri-
teriosa até um certo ponto limitado pelo poder computacional do equipamento. Nesse
caso ele é simples quando comparado com o poder computacional do equipamento que o
usuário �nal poderá dispor para uma análise mais criteriosa dos dados. Assim, o sensor
inteligente realiza o processamento simples dos dados sensoriados e quando necessário
uma análise mais criteriosa os dados são enviados para o usuário �nal, onde é feita uma
análise complexa dos dados.
Para que possa realizar suas funcionalidades um sensor inteligente é composto tipica-
mente por dispositivos de condicionamento de sinal, memória, microcontrolador, fonte de
energia, transceptor e um ou mais sensores. Os sensores são os dispositivos responsáveis
por realizar a medição e o controle da variável monitorada. Os dispositivos de condi-
cionamento de sinal são responsáveis por realizar a conversão e o armazenamento do sinal
medido em um formato digital. A fonte de energia irá fornecer a alimentação necessária
para que o sensor inteligente possa realizar suas funções. O microcontrolador é o dispo-
sitivo responsável por realizar todo o processamento necessário e que atribui inteligência
ao sensor. A memória é utilizada para o armazenamento de dados e do programa de
execução do microcontrolador.
Figura 3: Componentes básicos de um típico sensor inteligente.
-
13
A �gura 3 mostra um típico sensor inteligente dividido em três partes: o elemento
sensor, formado pelo sensor e o circuito de condicionamento e conversão de sinal. O ele-
mento processador, formado por microcontrolador e memória. E a parte de comunicação,
formada pelo transceptor. Na base de tudo está a fonte de alimentação que fornece a
energia necessária ao funcionamento de todos os elementos.
O padrão IEEE 1451 é o responsável por realizar a divisão do sensor inteligente em
módulos TIM e NCAP. O módulo TIM é a parte do sensor que contém os transdutores,
circuito de condicionamento de sinal, conversores de dados e as TEDS (Transducer
Eletronic Data Sheet) . O módulo NCAP é a parte composta pelo processador, pela
memória e pelo transceptor. A �gura 4 ilustra a comparação entre um sensor inteligente
comum e o sensor inteligente particionado em módulos pelo padrão IEEE 1451.
Figura 4: (a) Modelo de um sensor inteligente. (b) Modelo de sensor inteligente com adivisão em módulos TIM, NCAP e TII. Adaptado: Song e Lee (2008).
Entre os motivos dessa divisão está o fato de que um determinado fabricante domina
melhor a tecnologia presente no módulo TIM enquanto outro fabricante possui melhor
domínio sobre a tecnologia presente no NCAP. Desse modo, a divisão do sensor inteligente
em dois módulos permite que o usuário possa escolher entre as melhores tecnologias pre-
sentes no mercado, combinando um TIM e um NCAP que melhor se adeqüem a sua
aplicação.
A seguir será discutido a respeito do padrão IEEE 1451. Será apresentado como esse
-
14
padrão surgiu, quais os seus objetivos, os avanços ocorridos e quais as perspectivas futuras
para o mesmo.
3.1 Padrão IEEE 1451
Em 1993, o Comitê Técnico em Tecnologia dos Sensores - TC-9 da Sociedade de
Instrumentação e Medidas IEEE começou a trabalhar na de�nição de um padrão de in-
terfaceamento para conexão de transdutores inteligentes em rede. Essa sociedade obteve
a parceria do Instituto Americano de Padrões e Medidas - NIST. A IEEE e o NIST de-
cidiram iniciar uma série de workshops sobre padronização de interfaces. Como resultado
surgiram os grupos de trabalho que formularam as especi�cações da família de normas
1451.
O primeiro workshop do NIST/IEEE ocorreu em março de 1994 e teve como tema
interfaces para transdutores inteligentes. Em setembro do mesmo ano foi realizado outro
workshop, onde foi apresentado o conceito de especi�cações de transdutores no formato
eletrônico. Esse conceito deu origem às Folhas de Dados Eletrônicas dos Transdutores ou
TEDS. Essas folhas de dados possuem informações sobre os transdutores armazenadas
em memória. Elas serão melhor discutidas na seção 3.3, que fala sobre o módulo TIM que
é onde estão localizadas as TEDS.
Esses eventos motivaram a formação de dois grupos de trabalho denominados IEEE
P1451.1 (em fase de projeto) e o IEEE P1451.2(também em fase de projeto). Quando
ocorreu o terceiro workshop, em maio de 1995, foram introduzidos os primeiros conceitos
de interoperabilidade e plug and play1 em redes de transdutores. No ano seguinte foram
criados dois novos grupos de trabalho, o IEEE P1451.3 e o IEEE P1451.4.
Em 1997, foi aprovado o padrão IEEE 1451.2. Esta norma foi criada com o objetivo
de padronizar a interface entre transdutores e processadores de rede. Para tanto, foram
de�nidos o Módulo de Interface para Transdutores Inteligentes (STIM - Smart Transducer
Interface Module) ou TIM, a Interface Independente de Transdutores (TII) e as especi�-
cações das TEDS (IEEE-STD-1451.2-1997, 1997). O TIM sozinho não possui características
de inteligência, mesmo assim ele é chamado de STIM em alguns casos. Isso se deve não
ao fato de o TIM possuir inteligência, mas sim ao fato dele compor o sensor inteligente,
no caso TIM e NCAP juntos.
1Plug and play é um termo que se refere ao processo de conexão e posterior funcionamento de umdispositivo em um determinado sistema, sem a necessidade de recon�gurações.
-
15
Em 1999, foi aprovado o padrão IEEE 1451.1 que foi criado com o objetivo de
padronizar o software da interface entre processador de aplicação capaz de se comunicar
em rede (NCAP) e as redes de controle. Para alcançar essa padronização foi desenvolvido
um modelo de objetos comum, onde são de�nidos os blocos dos transdutores, os blocos
de funções e os blocos de rede. Esse modelo de objeto é baseado na orientação a objetos
e serve para que dois módulos NCAP possam trocar informações em rede (IEEE-STD-
1451.1-1999, 1999). Esse padrão se encontra ativo, porém ainda está passando por uma
revisão devido ao lançamento do padrão IEEE 1451.0 que aborda características comuns
de membros da família do padrão IEEE 1451 que já existiam antes do seu lançamento em
2007.
Em 2003, foi aprovado o padrão IEEE 1451.3 que especi�ca a forma de comunicação
para um arranjo de vários transdutores distribuídos conectados a um mesmo NCAP, cujas
informações devem ser lidas de forma sincronizada por um barramento ligado ao NCAP
(IEEE-STD-1451.3-2003, 2003).
Em 2004, foi aprovado o padrão IEEE 1451.4. Esta norma especi�ca como um sinal
analógico, associado a um transdutor, e um sinal digital podem ser disponibilizados através
de um mesmo barramento. Após ser ligado o transdutor, as informações digitais como
as TEDS são disponibilizadas por esse barramento, que em seguida muda para o modo
analógico e passa a transmitir os dados coletados pelo transdutor. Este padrão se torna
bastante importante para aplicações que necessitam de elevadas taxas de aquisição de
dados (IEEE-STD-1451.4-2004, 2004).
Em 2007, foram aprovados o padrão IEEE 1451.0 e o padrão IEEE 1451.5. O padrão
IEEE 1451.0 tem como objetivo servir como uma diretriz base para todas as outras normas
da família IEEE 1451, neste caso ele possui uma uni�cação das TEDS (IEEE-STD-1451.0-
2007, 2007). O padrão IEEE 1451.5 tem como objetivo adicionar as aplicações de�nidas
no padrão para o ambiente de redes sem �o. Desse modo, o NCAP pode se comunicar com
vários módulos TIM utilizando protocolos wireless diferentes para cada comunicação. Por
exemplo, o NCAP pode se comunicar com um TIM utilizando o padrão 802.11, com um
segundo TIM seguindo o padrão Bluetooth e com um terceiro seguindo o padrão Zigbee.
Nesse caso os TIMs são chamados de WTIM (Wireless Transducer Interface Module)
(IEEE-STD-1451.5-2007, 2007).
Atualmente, existem em fase de projeto o IEEE P1451.6 e o IEEE P1451.7. O primeiro
propõe uma rede de alta velocidade baseada no sistema CANOpen, com diversos módulos
contendo transdutores, e a de�nição de uma camada de segurança no modelo de comuni-
-
16
cação (IEEE-P1451.6, 2009). O segundo propõe a de�nição de um protocolo e uma interface
de comunicação entre transdutores e sistemas RFID (IEEE-P1451.7, 2009).
A grande vantagem do padrão IEEE 1451 é a possibilidade de interoperabilidade
entre um módulo TIM de um fabricante e o módulo NCAP de outro fabricante. Essa
característica permite que o usuário possa trabalhar com módulos TIM e NCAP que
melhor se adeqüem a sua aplicação, mesmo que esses sejam de fabricantes diferentes. Isso
se deve a interface padrão TII e a característica plug and play associada a esses módulos
através das TEDS, que são consideradas como o coração do padrão.
A seguir serão apresentados os módulos do sensor inteligente e a interface padrão
segundo o IEEE 1451. É importante que se saiba que apesar de todo o sensor inteligente
ser apresentado como referencial teórico, o foco deste trabalho é o módulo NCAP.
3.2 Módulo NCAP
O NCAP é um dispositivo que funciona como um microcontrolador realizando opera-
ções simples sobre os dados coletados pelo TIM. Ele também é o responsável por enviar
comandos a serem realizados pelo TIM, sendo que para isso ele utiliza a interface inde-
pendente de transdutor.
Segundo Kochan et al. (2005), o NCAP realiza processamento de dados simples on-
board e deixa para que o usuário �nal realize uma análise mais criteriosa sobre os dados.
Assim, o principal objetivo desse módulo é o processamento de dados em tempo real.
A parte de comunicação desse módulo deve fornecer capacidade de comunicação de
baixo nível que é a comunicação com o módulo TIM e comunicação de alto nível que é
o modo como é chamado a comunicação entre NCAPs, bem como entre um NCAP e o
usuário �nal (MAYIKIV et al., 2007).
A comunicação de baixo nível pode ser feita através de uma interface serial periférica
que siga o modelo especi�cado pelo padrão. Essa interface é de�nida pelo padrão IEEE
1451.2 e será apresentada na seção 3.4. O NCAP pode utilizar outras interfaces seriais ou
paralelas para essa comunicação, pois assim ele possui compatibilidade com um número
maior de módulos TIMs existentes. Em 2007, o padrão IEEE 1451.5 foi aprovado e desde
então passou a existir uma forma padronizada de comunicação wireless de baixo nível
para o NCAP.
Na comunicação de alto nível o NCAP pode utilizar uma interface Ethernet ou se
-
17
necessário uma forma de comunicação wireless. O padrão IEEE 1451.1 que de�ne o modelo
de objeto para o NCAP permite a troca de informações entre dois ou mais NCAPs através
da rede de alto nível.
O NCAP pode conter dois tipos de memórias. Uma delas é a memória de dados onde
estarão armazenados os dados colhidos pelo TIM e que o NCAP deve armazená-los para
que possa processá-los. A outra memória é a programável, onde deve estar localizado o
programa de execução do NCAP.
Existem duas abordagens de memória programável que podem ser utilizadas no de-
senvolvimento de NCAPs. Uma opção é fazer uso de uma memória RAM e a outra é
implementar utilizando uma memória Flash-ROM. Na primeira abordagem o programa
de execução é guardado em uma memória RAM que deve ser recarregada toda vez que o
NCAP for inicializado. Nesse caso, para que o programa de execução comece a executar
é necessário esperar a inicialização do NCAP, que este tenha acesso a rede e que o pro-
grama seja completamente enviado pelo usuário. No NCAP remotamente reprogramável
de Kochan et al. (2004), que foi apresentado entre os trabalhos relacionados, o envio desse
programa não leva mais que alguns segundos.
A outra abordagem utiliza uma memória Flash-ROM que mantém o programa de
execução armazenado mesmo quando o sensor é desligado ou reiniciado. Essa abordagem
é aconselhada para situações em que a comunicação entre o NCAP e o usuário �nal
não é normalizada, como é o caso da Internet. Em redes como a Internet não se tem
uma conexão dedicada ao envio do programa de execução, não podendo ser prevista sua
velocidade de transmissão.
Para os testes e análises do NCAP deste trabalho foi utilizada uma memória RAM,
a qual era recarregada sempre que necessário realizar novos testes depois do NCAP ter
sido desligado. Diferentemente do NCAP de Kochan et al. (2004), o módulo do presente
trabalho não utiliza reprogramação remota através de uma rede.
3.2.1 Padrão IEEE 1451.1
O padrão IEEE 1451.1 se baseia na linguagem orientada a objetos para especi�car toda
a hierarquia e módulos que deve possuir o software do NCAP. O seu objetivo principal é
o desenvolvimento de um modelo de objeto comum para que os módulos NCAPs possam
trocar dados entre si (STEPANENKO et al., 2006). É importante ressaltar que apesar do
padrão de�nir toda a hierarquia baseado na orientação a objetos ele deixa livre para que
-
18
o desenvolvedor do NCAP possa utilizar outras linguagens que não sejam orientadas a
objeto, como por exemplo C.
Caso o desenvolvedor escolha uma implementação em uma linguagem que não seja ori-
entada a objetos ele deve implementar diretamente todas as funções providas por todas as
classes do padrão. Ou seja, devem haver módulos que englobem todas as funcionalidades
de todos os objetos do padrão (IEEE-STD-1451.1-1999, 1999).
A �gura 5 ilustra bem uma situação que necessita dessa troca de dados entre dois
módulos NCAPs. Na �gura um recipiente deve ser mantido a uma temperatura constante,
ou seja, com pequenas variações. Para manter a temperatura constante o sistema faz
uso de um sensor ordinário, um aquecedor, um ventilador, três sensores inteligentes e
um computador para o usuário �nal do sistema. O NCAP3 recebe a informação da
temperatura captada pelo sensor comum através do TIM3 e envia para o NCAP2. Este
compara o valor recebido com o limiar de temperatura estabelecido e, caso necessário,
envia o comando para que o TIM2 aumente ou diminua a potência do aquecedor. Se o
sistema perceber que a energia do aquecedor está acabando ele faz com que o aquecedor
possua uma potência constante e que economize energia. Assim o NCAP3 passa a enviar
os dados para o NCAP1 e as variações passam a ser feitas na velocidade do ventilador.Caso
aconteça algum problema e a temperatura do sistema ultrapasse os limiares estabelecidos
pelo usuário �nal, este é informado pelo NCAP1 através da rede.
Figura 5: Situação onde há comunicação entre NCAPs.
-
19
O padrão IEEE 1451.1 foi desenvolvido para facilitar a criação de um software de
aplicação que seja modular, independente de rede e baseado em transdutor. Para tanto,
o padrão de�ne um modelo de informação neutro e um modelo de dados (LEE, 2000),
(IEEE-STD-1451.1-1999, 1999).
O modelo de informação neutro é composto por um conjunto hierárquico de classes
que representam os blocos de objetos do NCAP. O modelo é neutro porque especi�ca a
forma geral que deve ser feita a troca de informação entre NCAPs, independentemente da
tecnologia de rede que será utilzada. Os modelos objetos que são especí�cos da rede são
abordados por outros membros da família IEEE 1451, por exemplo o IEEE 1451.5 trata
da comunicação wireless.
O modelo de dados de�nido por esse padrão especi�ca o tipo e a forma dos dados que
devem ser utilizados pelo software de aplicação do NCAP. Todos os modelos de dados
especi�cados nesse padrão derivam dos tipos de dados primitivos da tabela 1.
Tabela 1: Tipos primitivos de dados.
Tipo de dado Valor padrão DescriçãoBoolean FALSE TRUE ou FALSEInteger8 0 8 bits que representam inteirosUInteger8 0 8 bits que representam inteiros positivosInteger16 0 16 bits que representam inteirosUInteger16 0 16 bits que representam inteiros positivosInteger32 0 32 bits que representam inteirosInteger32 0 32 bits que representam inteiros positivosInteger64 0 64 bits que representam inteirosInteger64 0 64 bits que representam inteiros positivosFloat32 +0.0 IEEE Std 754-1985 número de ponto
�utuante de precisão simplesFloat64 +0.0 IEEE Std 754-1985 número de ponto
�utuante de precisão dobradaOctet bits 0 Sequência de 8 bits.
O coração do IEEE 1451.1 é composto por 35 classes que compõem o modelo de objeto
e que servem como base para o software de aplicação do NCAP. O modelo de dados consiste
de 81 classes adicionais que descrevem estruturas e tipos de dados derivados tais como os
que podem ser vistos a seguir.
Especificação da representação de argumentos de uma
publicação a partir de um tipo primitivo.
-
20
typedef OctetArray PublicationTopic;
typedef Octet PubSubDomain[8];
Especificação do conteúdo de uma publicação.
void publish(
UInteger8 publication_key,
PublicatioTopic publication_topic,
PubSubDomain publication_domain,
UInteger16 content
){...}
A �gura 6 mostra a hierarquia de classes do IEEE 1451.1 através da UML (Uni�ed
Modeling Lenguage) . No topo da hierarquia de classes do padrão estão as classes Root
e Entity. Essas classes são classes abstratas e devem servir como base para as demais
classes do padrão.
A classe Root como o próprio nome já diz é a raiz da hierarquia de classes. Ela
contém duas operações básicas que são GetClassName que retorna o nome da classe e
GetClassID que retorna um número que representa seu posicionamento na hierarquia.
No caso da classe Root o identi�cador da classe é 1.
A classe Entity é uma classe que herda as características da classe Root e adiciona as
características necessárias para que os objetos se tornem visíveis na rede. O identi�cador
dessa classe é 1.1 o das suas subclasses imediatas deve ser 1.1.1. As operações dessa classe
são listadas a seguir.
GetObjectTag que retorna o valor utilizado para identi�car um objeto servidor em
uma comunicação cliente/servidor.
SetObjectTag que permite con�gurar o valor do objeto servidor.
GetObjectID que retorna o identi�cador do objeto.
GetObjectName deve retornar o nome do objeto.
-
21
Figura 6: Hierarquia de classes do modelo de objeto do IEEE 1451.1. Fonte: (STEPA-NENKO et al., 2006).
-
22
GetDispatchAddress deve retornar o endereço do objeto servidor em uma comuni-
cação cliente/servidor. A geração desse endereço é especi�co da rede subjacente e é
de�nida fora do escopo do IEEE 1451.1.
GetOwningBlockObjectTag deve retornar o valor do Objetc Tag do Owning Block
Object. Este é um bloco composto por objetos que são capazes de aceitar e processar
operações que lhe são requisitadas.
GetObjectProperties que retorna uma estrutura contendo o valor corrente do Object-
Tag, ObjectDispatchAddress, ObjectName e o Object Tag do Owning Block Object
deste objeto.
O padrão de�ne que todas as classes devem começar pelo pre�xo �IEEE1451 �. Exis-
tem quatro categorias de classes objetos nas quais devem estar inseridas todas as classes
do padrão. Desse modo, as classes podem ser do tipo Block, Component, Service ou
Non-IEEE 1451.1 object.
As classe pertencentes à classe Block podem ser divididas nas três classes principais
a seguir:
IEEE1451 NCAPBlock responsáveis por prover a interface de suporte para comuni-
cação em rede e para a con�guração do sistema.
IEEE1451 BaseTransducerBlock são classes responsáveis por prover a comunicação
entre transdutores e o software de aplicação. As subclasses dessa classe devem
conter operações com suporte para a comunicação entre o NCAP e o módulo TIM.
Portanto, elas devem conter operações especí�cas do meio de comunicação entre
estes, de�nidas por outros membros do padrão IEEE 1451.
IEEE1451 FunctionBlock que são classes que encapsulam funcionalidades especí�cas
da aplicação.
As classes pertencentes à classe Component devem prover construções comuns da
aplicação tais como informações estruturadas ou coleções de objetos especí�cos da apli-
cação.As classes pertencentes à classe Service são aquelas que dão suporte a comunicação
entre objetos de NCAPs distintos. Elas também devem prover a sincronização do sis-
tema. A classe Non-IEEE 1451 object não é representada na hierarquia das classes do
padrão IEEE 1451.1, pois ela deve conter classes que não são especi�cadas pelo padrão.
-
23
Essas classes podem ser classes especí�cas da aplicação do fabricante do NCAP. Porém é
necessário que qualquer classe pertencente a ela seja uma subclasse da classe Entity.
O padrão IEEE 1451.1 de�ne dois tipos de comunicação entre NCAPs. Uma delas é do
tipo Cliente/Servidor e a outra é o tipo de comunicação Publisher/Subscriber. No tipo de
comunicação Cliente/Servidor um NCAP funciona como cliente e o outro como servidor.
Nesse tipo de comunicação o cliente deve interromper suas atividades até que receba
o resultado da requisição feita ao servidor. De acordo com esse padrão o NCAP cliente
deve invocar os serviços do NCAP servidor através da operação de Execute. Essa operação
possui como argumentos o status do modo de execução, o endereço do NCAP sevidor,
os argumentos de entrada para o NCAP servidor e os argumentos de saída desejados.
O NCAP servidor executa o serviço solicitado através da operação Perform e devolve o
resultado através da rede.
Na comunicação Publisher/Subscriber os NCAPs não necessitam interromper suas
atividades. O Publisher e o Subscriber não precisam saber da existência um do outro. O
NCAP Subscriber publica seu interesse na Subscriber Port e o NCAP Publisher publica
um determinado interesse que ele possui para todos os Subscribers da rede. Ao receber
um interesse publicado pelo Publisher a Publisher Port compara o mesmo com o interesse
publicado pelo Subscriber utilizando o domínio, a chave e o quali�cador de subscrição.
Caso o interesse seja satisfatório é executada a operação AddSubscriber e caso contrário é
executada a operação CallBack que realiza a comparação entre o interesse recebido com
todos os outros interesses anteriormente publicados pelo NCAP Subscriber.
Este trabalho apresenta apenas os principais conceitos e objetivos da detalhada es-
peci�cação do IEEE 1451.1. O objetivo com o referencial teórico sobre esse padrão é
descrevê-lo em linhas gerais, uma vez que ele será utilizado como base para o desenvolvi-
mento do software do NCAP proposto. Mais detalhes sobre a implementação do software
do NCAP podem ser encontrados em IEEE-Std-1451.1-1999 (1999).
3.2.2 Mínimo IEEE 1451.1
O padrão IEEE 1451.1 foi estudado e analisado por pesquisadores do NIST em
conjunto com pesquisadores da Faculty of Computer Information Technologies. Esses
pesquisadores consideraram que o padrão possui um certo grau de complexidade e que
após adicionadas as funcionalidades do software o código fonte pode se tornar bastante
grande. Isso faz com que uma implementação baseada nesse padrão requeira bastante
recursos computacionais e de memória (STEPANENKO et al., 2006).
-
24
Os pesquisadores do NIST implementaram o completo IEEE 1451.1 usando o mid-
dleware ADAPTIVE Communication Environment em um computador pessoal baseado
em Linux de 32 Bits. Para a execução da aplicação era necessário compilar as bibliotecas
libACE.so que é a biblioteca padrão do ADAPTIVE e lib1451.so que foi a biblioteca do
IEEE 1451 implementada. As versões release tinham 1,8MB de código computacional e
os pesquisadores estimaram que a versão �nal estaria em torno de 20MB de tamanho de
código.
Os pesquisadores concluíram que era difícil implementar um completo IEEE 1451.1 em
sistemas com microcontroladores de 8 e 16-bit, que geralmente possuem limitada memória
e poder computacional. Diante disso foi proposto o desenvolvimento de um mínimo IEEE
1451.1 para tais sistemas.
O mínimo IEEE 1451.1 seria desenvolvido usando apenas algumas classes
do completo IEEE 1451.1. Entre essas classes estão IEEE1451 NCAPBlock,
IEEE1451 TransducerBlock, IEEE1451 FunctionBlock, classes de parâmetros e classes de
portas. A �gura 7 mostra a hierarquia de classes do mínimo IEEE 1451.1 apresentado em
Stepanenko et al. (2006).
As classes utilizadas na �gura 7 são aquelas necessárias para tornar o software do
NCAP compatível com o padrão IEEE 1451.1. A seguir está uma lista das classes que
não são incluídas nessa nova abordagem do padrão. Elas juntas formam um total de 16
classes.
IEEE1451_ComponentGroup
IEEE1451_Action
IEEE1451_File
IEEE1451_PartitionedFile
IEEE1451_TimeParameter
IEEE1451_ScalarSeriesParameter
IEEE1451_Dot2TransducerBlock
IEEE1451_Dot3TransducerBlock
IEEE1451_Dot4TransducerBlock
IEEE1451_MutexService
IEEE1451_ConditionVariableService
IEEE1451_AssynchronousClientPort
IEEE1451_SelfIdentifyingPublisherPort
IEEE1451_EventGeneratorPublisherPort
-
25
Figura 7: Hierarquia de classes do mínimo IEEE 1451.1. Fonte: Stepanenko et al. (2006).
O mínimo IEEE 1451.1 foi implementado pelos pesquisadores na linguagem C++.
A biblioteca foi compilada e embarcada para o microcontrolador 8051. O tamanho do
código do mínimo IEEE1451.1 implementado foi de 900kB. As operações das classes do
completo IEEE 1451.1 foram analisadas e foram retiradas aquelas que eram opcionais.
O mínimo IEEE 1451.1 implementado possui biblioteca para comunicação do tipo
Cliente/Servidor e Publisher/Subscruiber. Dependendo do software de aplicação do NCAP
um tipo de comunicação pode ser escolhido e o tamanho do código pode ser reduzido ainda
mais (STEPANENKO et al., 2006).
O presente trabalho utiliza o mínimo IEEE 1451.1 para o desenvolvimento do software
do NCAP, pois este é uma revisão do padrão completo feita pelos próprios autores, os
quais identi�caram os requisitos mínimos para se estar de acordo com o padrão. Além
disso, o uso do mínimo IEEE 1451.1 auxilia em um dos trabalhos futuros a este que seria
o desenvolvimento de um microcontrolador dedicado que venha a substituir o processador
-
26
NIOS II que em conjunto com o software controlam o sistema.
3.3 Módulo TIM
O módulo TIM é a parte do sensor inteligente onde se encontram os transdutores
(sensores e atuadores) responsáveis por realizar medições sob alguma grandeza física,
química ou biológica ou interferir em fenômenos físicos, químicos ou biológicos. Além dos
transdutores nesse módulo devem estar inseridos os conversores de sinal que podem ser
CAD (Conversor Analógico-Digital) ou CDA (Conversor Digital-Analógico) , o circuito
de condicionamento de sinal e as TEDS Transducer Eletronic Data Sheet que são as folhas
de dados eletrônicas do transdutor.
As TEDS são folhas de dados eletrônicas que possuem informações sobre o módulo
TIM e sobre os transdutores presentes no mesmo. Entre essas informações podem estar
o número de transdutores do TIM, o número identi�cador de cada transdutor, data da
última calibração de cada transdutor, período entre cada calibração, entre outras. Elas são
consideradas como o coração do padrão IEEE 1451, pois proporcionam que a característica
plug-and-play seja associada ao sensor inteligente através da leitura e reconhecimento das
características do TIM pelo módulo NCAP (SONG; LEE, 2008).
O padrão IEEE 1451 possui uma cláusula especí�ca que de�ne o formato das TEDS,
estabelecendo o formato lógico e o conteúdo das mesmas. O padrão de�ne 8 formatos,
dos quais 2 são obrigatórios e 6 são opcionais.
O Bloco de dados Meta-TEDS é obrigatório e contém dados que descrevem o
módulo TIM de forma global. Entre esses dados ele inclui o identi�cador único do
TIM, o número de canais implementados, especi�cações de tempo e outras infor-
mações que são comuns a todos os transdutores.
O Bloco de dados Canal-TEDS também é obrigatório. Ele de�ne o modelo
funcional do transdutor, limites máximos e mínimos, unidades físicas, restrições de
tempo e outras informações necessárias para descrever cada canal transdutor.
O Bloco de dados calibração-TEDS deve ser adicionado caso o transdutor pos-
sua algum tipo de calibração. Nele devem estar incluídos os coe�cientes que serão
utilizados para a correção, bem como a data e hora das últimas calibrações e os
intervalos requeridos para a calibração de cada canal.
-
27
O Bloco de dados identi�cação Meta-TEDS fornece as informações do bloco
de dados Meta-TEDS em um formato do tipo string legível, ao usuário.
O Bloco de dados TEDS - Identi�cação de canal inclui informações de cada
canal individual em um formato legível ao usuário.
O Bloco de dados TEDS - Calibração de canal fornece informações de cali-
bração em um formato legível ao usuário.
O Bloco de dados TEDS - Aplicações especi�cas do usuário �nal fornece
uma forma de armazenar dados do tipo string que não têm sido abordados nos
outros blocos de dados. Por exemplo, a descrição da alocação do TIM no sistema.
O Bloco de dados TEDS - Extensões genéricas permitem a associação de
extensões futuras em conformidade com o padrão e os setores industriais.
O módulo TIM é de�nido pelo IEEE 1451.2 e sua lógica pode ser implementada de
diferentes maneiras, como por exemplo, com microcontrolador de baixo custo, FPGA,
ASIC (Application Speci�c Integration Circuit) ou mesmo um computador pessoal. A
implementação do módulo TIM é bastante �exível e pode assumir diversas formas.
A �gura 8 mostra algumas variações quanto a forma de implementação de um módulo
TIM usando um microcontrolador de baixo custo. No ítem �a� pode ser visto um TIM
dedicado onde só existe sensor como transdutor. O ítem �b� mostra um TIM com 8 canais
digitais de entrada e saída, ou seja, nele pode-se ter até 4 sensores ocupando os canais de
saída e 4 atuadores ocupando os canais de entrada. O ítem �c� mostra um TIM composto
por sensores de pressão, temperatura e potencial ácido. E o ítem �d� apresenta um TIM
com sensores de pressão e temperatura, e com uma válvula e um relé como atuadores
desse sistema.
Esse módulo possui algumas funções que auxiliam na comunicação e troca de dados
com o módulo NCAP. Dentre essas funções estão as funções de endereçamento, disparo,
transporte de dados, controle, estado e interrupção. Essas funções serão discutidas a
seguir.
3.3.1 Endereçamento
Segundo o padrão IEEE 1451 o NCAP deve utilizar 2 Bytes de endereçamento para
o envio de uma solicitação ao TIM. Cada um desses Bytes tem uma �nalidade especí�ca.
-
28
Figura 8: Diferentes formas de se implementar o módulo TIM. Fonte: Martins (2005).
O primeiro Byte (Byte mais signi�cativo) é utilizado para especi�car o endereçamento
funcional, ou seja, qual a função a ser realizada pelo TIM. O segundo Byte (Byte menos
signi�cantivo) é utilizado para especi�car o endereço do canal que irá realizar a função.
Cada transdutor associado ao TIM é um canal transdutor e possui um endereço de canal
para que possa ser distinguido dos demais. A �gura 9 mostra a estrutura de endereçamento
utilizada pelo padrão IEEE 1451.
Figura 9: Estrutura de endereçamento completo. Adaptado: IEEE-Std-1451.2-1997(1997).
O endereçamento especi�cado pelo padrão IEEE 1451 é de nível lógico. O padrão não
especi�ca como deve ser feito o seu mapeamento para endereços físicos, �cando a critério
do fabricante do TIM.
-
29
3.3.1.1 Endereçamento de Canal
O endereçamento de canal é a parte da estrutura de endereçamento utilizada pelo
NCAP que faz referência ao canal transdutor para o qual será enviada a solicitação. Cada
módulo TIM pode possuir um número N de canais transdutores implementados. Esse
número pode variar de 1 a 255, onde este último é o maior número que pode ser endereçado
por 1 Byte decrescido de 1. Desse modo, cada módulo TIM pode implementar no máximo
255 canais transdutores e os canais devem ser implementados consecutivamente iniciando-
se do número 1. Para saber qual o último canal implementado o NCAP pode solicitar a
leitura do bloco de dados Meta-TEDS.
O endereço zero tem um signi�cado especial para o padrão IEEE 1451. Ele é utilizado
para representar o endereçamento das funções que são destinadas a todos os canais trans-
dutores de forma global, vide tabela 3, página 32. Quando uma função é implementada
para o que se chama de CHANNEL ZERO, ela deve ser executada pela coleção de todos
os canais transdutores implementados no TIM.
3.3.1.2 Endereçamento de Função
O endereçamento funcional é a parte da estrutura de endereçamento utilizada pelo
NCAP para indicar qual a ação que o TIM deve desempenhar. O bit mais signi�cativo
do endereçamento de canal é utilizado para indicar a direção da comunicação, ou seja, se
é uma leitura de dados do TIM ou uma escrita no mesmo. A tabela 2 ilustra essa idéia.
Tabela 2: Direção da comunicação.
Valor Direção da comunicação0 Escrita no TIM1 Leitura do TIM
Quando o bit mais signi�cativo do endereço funcional é 0 a operação é de escrita e
quando esse bit é 1 a operação é de leitura. Os demais bits do endereçamento funcional
são utilizados para representar a função selecionada. Assim, os primeiros 128 endereços
funcionais são destinados para funções de escrita enquanto os demais são utilizados para
funções de leitura.
-
30
3.3.2 Transporte de dados
A função de transporte de dados é utilizada durante a leitura de dados do TIM ou
durante a escrita de dados no mesmo. As operações de leitura ou escrita podem ser
realizadas tanto sobre os transdutores como também sobre as TEDS. O transporte de
dados pode ser utilizado ainda para a escrita de um comando de controle ou leitura do
status do TIM.
A interface independente de transdutor possui uma porta destinada à identi�cação do
transporte de dados. Essa porta é chamada de NIOE e sempre deve estar ativa quando
estiver ocorrendo o transporte de dados. Na interface TII o transporte de dados propri-
amente dito ocorre através da porta DIN se a operação é de escrita e através da porta
DOUT caso ela seja de leitura.
Durante o transporte os dados são enviados através da interface serial iniciando-se
do bit mais signi�cativo contido no Byte mais signi�cativo do conjunto de dados a serem
enviados. Em seguida, os bits subseqüentes são enviados até que o bit menos signi�cativo
do Byte menos signi�cativo seja enviado, �nalizando o transporte.
No caso de funções globais envolvendo o transporte de dados, como write global trans-
ducer data e read global transducer data o resultado é a escrita ou a leitura de todos os
canais concatenados em conjunto, iniciando-se do canal 1. A solicitação de leitura de
dados de um atuador deve resultar no último dado nele escrito e a solicitação de escrita
em um sensor deve resultar em um comando inválido.
3.3.3 Disparo
A função de disparo é controlada pelo NCAP e é utilizada quando o mesmo necessita
enviar uma solicitação ao TIM. A TII possui uma porta que indica se o sinal de disparo
está ativo ou inativo (NTRIG). Essa função interage com a função de transporte de dados
de modo que enquanto ocorre o transporte de dados o sinal de disparo deve estar inativo.
A �gura 10 mostra um diagrama de estados com o comportamento do módulo TIM
durante a função de disparo.
De acordo com a �gura, após a inicialização o TIM �ca no estado de espera até que
ocorra o envio de um sinal de disparo para ele. Quando isso ocorre o TIM segue para
o estado de ação de disparo. Nesse momento, caso o transdutor seja um sensor ele irá
realizar a aquisição e conversão de dados, e caso ele seja um atuador ele irá validar e
-
31
Figura 10: Ciclo de disparo no TIM. Fonte: Martins (2005).
enviar para o bu�er do atuador o último dado escrito naquele canal transdutor.
Depois de ter ido para o estado de disparo ativo o TIM pode ir ou para o estado de
deter ação ou para o estado de reconhecimento do disparo. Ele vai para o estado de deter
ação quando o NCAP remove por alguma causa o sinal de disparo antes que o mesmo
seja reconhecido pelo TIM. O NCAP pode deter o disparo após ter esperado um intervalo
de tempo chamado Channel Update Time contido no Canal-TEDS, pois após esse tempo
ele assume que o canal transdutor não está operando corretamente. Caso contrário o
TIM responde o sinal de disparo e vai para o estado de reconhecimento de disparo, onde
permanece até que o NCAP retire o sinal de disparo e ele possa voltar para o estado de
espera, depois do qual pode ocorrer o transporte de dados.
No caso do disparo ter sido abortado o transporte de dados só poderá ocorrer quando
ocorrer um ciclo completo de disparo.
3.3.4 Controle
Essa função permite que o NCAP envie comandos a serem realizados pelo TIM e
que normalmente afetam o estado de funcionamento do mesmo. Esses comandos podem
ser enviados para um canal especí�co, nesse caso o endereço de função especi�cado pelo
NCAP é oWrite Channel Control Command(escrever comando de controle para um canal)
-
32
ou podem ser enviados de forma global pelo endereço de função Write global Control
Command(escrever comando de controle global).
O NCAP utiliza dois Bytes para endereçamento dos comandos de controle, ou seja,
podem ser endereçados 65.536 comandos de controle. A tabela 3 possui os comandos de
controle e seus respectivos endereços de�nidos pelo padrão.
O comando de controle �0� deve ser implementado para todos os canais do TIM. Os
comandos de controle �2� ao �4� se referem a funções opcionais que podem ser imple-
mentadas no TIM. Os comandos de controle �5� ao �7� são para TIMs com sensores que
possuem seqüência de eventos. Os comandos de controle �9� e �10� são para TIMs que
contêm sensores com seqüência de dados e com seqüência de armazenamento de dados.
Todos os endereços de comandos de controle destacados como �reservados� não podem
ser implementados no TIM, pois são utilizados para extensões futuras do padrão. Os
endereços de comando de controle marcados como �abertos� estão abertos à industria e
podem ser utilizados para os �ns especí�cos do fabricante.
Tabela 3: Comandos de controle do módulo TIM.
Valor De�nição para o CHANNEL ZERO De�nição para canais individuais0 Nenhuma operação Nenhuma operação1 Reiniciar TIM Reiniciar canal2 Auto-teste do TIM Auto-teste do canal3 Calibração de todos os canais Calibração de canal especí�co4 Zerar todos os canais Zerar canal especí�co5 Habilitar todos os sensores Habilitar sensor com seqüência
com seqüência de eventos de eventos6 Desabilitar todos os sensores Desabilitar sensor com seqüência
com seqüência de eventos de eventos7 Modo de con�guração para todos Modo de con�guração para um
sensor com seqüência de eventos sensor com seqüência de eventos8 Reservado Reservado9 Habilitar todos os sensores com Habilitar sensor com seqüência
seqüência de dados ou seqüência de de dados ou com seqüência dedados armazenados em bu�er dados armazenados em bu�er
10 Desabilitar todos os sensores com Desabilitar sensor com seqüênciaseqüência de dados ou seqüência de de dados ou com seqüência de
dados armazenados em bu�er dados armazenados em bu�er11-255 Reservado Reservado256 - Aberto à industria Aberto à industria65.535
-
33
Quando o NCAP deseja que o TIM realize algum comando de controle ele envia
primeiro 2 Bytes indicando o endereço funcional e o endereço de canal. Em seguida são
enviados mais 2 Bytes com o endereço do comando de controle a ser realizado pelo TIM.
3.3.5 Estado
A função de estado permite ao NCAP determinar o estado do TIM de forma global
ou para cada canal individual. Essa função é implementada através de registradores
de estado padrão e auxiliar. Cada bit em uma posição especi�ca de um registrador de
estado representa a presença ou ausência de uma condição particular. A presença de uma
situação é indicada por um bit �1� na posição apropriada e a ausência é indicada por um
bit �0�.
Ambos os registradores de estado, padrão e auxiliar, são do tamanho de 2 Bytes. As
tabelas 4 e 5 mostram cada bit desses regristradores de estado de�nidos pelo padrão.
Tabela 4: Registrador de estados padrão.
Bit De�nição para o CHANNEL ZERO De�nição para canais individuaisBit Aberto à industria Aberto à industriamaissig.- Aberto à industria Aberto à industria- Aberto à industria Aberto à industria- Aberto à industria Aberto à industria- Reservado Reservado- Reservado Reservado- Reservado Reservado- Bit operacional do TIM Bit operacional do canal- Bit de erro de hardware no TIM Bit de erro de hardware no canal- Bit de evento/dado do TIM Bit de evento/dado do canal- Bit de evento ou dados perdidos Bit de evento ou dados perdidos
do TIM do canal- Bit de disponibilidade do Bit de disponibilidade do
registrador auxiliar do TIM registrador auxiliar do canal- Bit de comando inválido reservado- Bit de TIM reiniciado Bit de canal reiniciado- Bit de reconhecimento de Bit de reconhecimento de
disparo do TIM disparo do canalBit Bit de requisição de serviço Bit de requisição de serviço
menos do TIM do canalsig.
-
34
Tabela 5: Registrador de estados Auxiliar.
Bit De�nição para o CHANNEL ZERO De�nição para canais individuaisBit Aberto à industria Aberto à industriamaissig.- Aberto à industria Aberto à industria- Aberto à industria Aberto à industria- Aberto à industria Aberto à industria- Reservado Reservado- Reservado Reservado- Reservado Reservado- Bit operacional do TIM Bit operacional do canal- Bit de erro de hardware no TIM Bit de erro de hardware no canal- Bit de evento/dado do TIM Bit de evento/dado do canal- Bit de evento ou dados perdidos Bit de evento ou dados perdidos
do TIM do canal- Bit de disponibilidade do Bit de disponibilidade do
registrador auxiliar do TIM registrador auxiliar do canal- Bit de comando inválido reservado- Bit de TIM reiniciado Bit de canal reiniciado- Bit de reconhecimento de Bit de reconhecimento de
disparo do TIM disparo do canalBit Bit de requisição de serviço Bit de requisição de serviço
menos do TIM do canalsig.
3.3.6 Interrupção
Essa função é utilizada por dispositivos de entrada e saída para que durante a exe-
cução do programa em curso a Unidade Microprocessadora passe a executar um programa
especial, chamado de rotina de serviço de interrupção. A TII possui uma porta chamada
NINT que permite que o TIM realize essa função sobre o NCAP. Quando essa porta está
ativa o NCAP executa um programa especial, que normalmente envolve atender ao TIM.
Ao terminar a execução da rotina de serviço de interrupção o NCAP volta executar o
programa em que estava trabalhando antes de ser interrompido.
Existem situações nas quais não é conveniente realizar uma rotina de serviço de inter-
rupção, pois essa execução leva a um estado indesejado. Desse modo devem ser utilizados
recursos para que se possa inibir a interrupção pelo programa de execução. Essa inibição
é chamada de máscara de interrupção.
A máscara de interrupção utilizada pelo padrão para que o NCAP possa inibir essa
operação é feita através dos registradores de estado padrão e auxiliar. A operação de
interrupção será executada sempre que o bit de requisição de serviços do registrador de
-
35
estados padrão estiver ativado para �1�. O valor desse bit é o resultado de um �OU�
lógico das operações lógicas �E� entre cada bit do registrador de e