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