DanielLM DISSERT

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE
C ENTRO DE T ECNOLOGIA
P ROGRAMA DE P ÓS -G RADUAÇÃO EM E NGENHARIA E LÉTRICA E
UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
DE C OMPUTAÇÃO
Arquitetura de controladores Fuzzy em redes

Foundation Fieldbus
Daniel Lopes Martins
Orientador: Prof. Dr. Adrião Duarte Dória Neto
Co-orientador: Prof. Dr. Jorge Dantas de Melo
Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Engenharia
Elétrica e de Computação da UFRN como
parte dos requisitos para obtenção do título
de Mestre em Ciências.
Natal, RN, fevereiro de 2011

Seção de Informação e Referência
Catalogação da Publicação na Fonte. UFRN / Biblioteca Central Zila Mamede
Martins, Daniel Lopes.

Arquitetura de controladores Fuzzy em redes foundation. Fieldbus. / Daniel
Lopes Martins. – Natal, RN, 2011.
80 f.; il.
Orientador: Adrião Duarte Dória Neto.

Co-orientador: Jorge Dantas de Melo.
Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte.

Centro de Tecnologia. Programa de Pós-Graduação em Engenharia Elétrica e de
Computação.
1. Redes industriais foundation fieldbus – Dissertação. 2. Lógica fuzzy –
Dissertação. 3. Controlador fuzzy – Dissertação. I. Dória Neto, Adrião Duarte.
II. Melo, Jorge Dantas de. III. Universidade Federal do Rio Grande do Norte. IV.
Título.
RN/UF/BCZM CDU 004.725.5

Agradecimentos
Agradeço primeiramente a Deus, por sempre ouvir minhas orações, por estar sempre
presente ao meu lado, seja nos momentos difíceis, seja nos momentos de alegria, zelando
por mim e por toda minha família.
Aos meus pais Aderson e Ubiraci por serem o meus alicerces, onde busco conselhos e
apoio em vários momentos da minha vida, estando ao meu lado e me acompanhando
em minhas decisões, me ajudando a alcançar meus objetivos, mesmo que para isso fosse
necessário abdicar dos seus e comemorando comigo as minhas conquistas.
Ao meu orientador Adrião, co-orientador Jorge e ao professor Affonso, que já na gradu-

ação acreditaram e hoje continuam acreditando no meu potencial, me oferecendo opor-
tunidades de trabalhar em áreas de inovação tecnológica. Agradeço por esta confiança e
também por todos os ensinamentos que me foram concedidos.
Ao professor Dennis Brandão por ter aceitado participar da banca examinadora desta
dissertação. Agradeço pelas dicas e apontamentos que acabaram se tornando uma grande
contribuição para a versão final deste trabalho.
Aos companheiros do LAMP, Alexandre, Kennedy e Victor que, comigo, desenvolveram

a primeira versão deste trabalho. Agradeço pela boa conversa e convivência ao longo
destes anos trabalhando no laboratório. Um agradecimento especial a Vinícius Pontes,
que me forneceu seu material para que eu pudesse iniciar meus estudos na linguagem
do LabVIEW e posteriormente, por tirar dúvidas sobre alguns problemas com que me
deparei. A Leonardo Guanabara que também me deu dicas sobre o LabVIEW e sempre
estava disposto a ajudar em algum problema de implementação.
Aos meus amigos Keylly Eyglys, Cicília Maia, Gláucia Azambuja, Fabiana Santana e
Vinícius Samuel que durante as aulas do mestrado foram de grande ajuda no desenvolvi-
mento das atividades que os professores passavam. Agradeço também pelas boas conver-
sas no LABSIS e pela troca de ideias sobre o meu trabalho.
Aos demais professores do departamento que contribuíram direta ou indiretamente com a

minha formação profissional e pessoal.
A todos os demais não mencionados, amigos mais próximos e familiares que contribuíram
de outras formas para a minha formação pessoal e conclusão deste trabalho.
À CAPES e CNPq, pelo apoio financeiro.

Resumo
As redes industriais Foundation Fieldbus são redes com alto padrão de tecnologia que
permitem que usuários criem lógicas de controle complexas e totalmente descentraliza-
das. Mesmo sendo tão avançadas, elas ainda possuem algumas limitações impostas pela
sua própria tecnologia.
Tentando solucionar uma destas limitações, este trabalho descreve como estruturar
um controlador Fuzzy dentro de uma rede Foundation Fieldbus utilizando seus elementos
básicos de programação, os blocos funcionais, de forma que a rede continue sendo total-
mente independente de qualquer outro dispositivo que não os próprios instrumentos que
a constituem.
Além disso, no decorrer do trabalho foi desenvolvida uma ferramenta que auxilia
este processo de construção do controlador Fuzzy, configurando os parâmetros internos
aos blocos funcionais e informando quantos e quais blocos devem ser utilizados para
determinada estrutura.
O maior desafio em criar este controlador está justamente na escolha dos blocos e
em como arranjá-los de forma a efetuarem as mesmas funções de um controlador Fuzzy
implementado em outro tipo de ambiente. A metodologia adotada foi dividir cada uma
das fases de um controlador Fuzzy tradicional e então criar estruturas simples com os
blocos funcionais para implementá-las.
Ao final do trabalho, o controlador desenvolvido é comparado com um controlador
Fuzzy implementado em uma programa matemático que possui uma ferramenta própria
para criação e execução de controladores Fuzzy, obtendo gráficos comparativos de de-
sempenho entre ambos.
Palavras-chave: Redes industriais Foundation Fieldbus, Lógica Fuzzy, Controlador
Fuzzy.
Abstract
Foundation Fieldbus Industrial networks are the high standard technology which al-
lows users to create complex control logic and totally decentralized. Although being so
advanced, they still have some limitations imposed by their own technology.
Attempting to solve one of these limitations, this paper describes how to design a
Fuzzy controller in a Foundation Fieldbus network using their basic elements of pro-
gramming, the functional blocks, so that the network remains fully independent of other
devices other than the same instruments that constitute it.
Moreover, in this work was developed a tool that aids this process of building the
Fuzzy controller, setting the internal parameters of functional blocks and informing how
many and which blocks should be used for a given structure.
The biggest challenge in creating this controller is exactly the choice of blocks and
how to arrange them in order to effectuate the same functions of a Fuzzy controller im-
plemented in other kind of environment. The methodology adopted was to divide each
one of the phases of a traditional Fuzzy controller and then create simple structures with
the functional blocks to implement them.
At the end of the work, the developed controller is compared with a Fuzzy controller
implemented in a mathematical program that it has a proper tool for the development and
implementation of Fuzzy controllers, obtaining comparatives graphics of performance
between both.
Keywords: Foundation Fieldbus Industrial Networks, Fuzzy Logic, Fuzzy Controller.
Sumário
Sumário i
Lista de Figuras iii
Lista de Tabelas v
Lista de Símbolos e Abreviaturas vii
1 Introdução 1
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Fundamentação teórica 7
2.1 Redes industriais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Rede Industrial Foundation Fieldbus (FF) . . . . . . . . . . . . . 14
2.2 Lógica Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1 Controlador Fuzzy . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3 Fuzzy aplicado ao ambiente Foundation Fieldbus 37

3.1 Introdução à aplicação Fuzzy-FF . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Controlador Fuzzy-FF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3 Estágio de Fuzzyficação-FF . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Estágio de Inferência-FF . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5 Estagio de Desfuzzyficação-FF . . . . . . . . . . . . . . . . . . . . . . . 43
4 Interface de configuração Fuzzy-FF em LabVIEW 47

4.1 Interface principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2 Gerador Memberships . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3 Configurador de regras . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5 Testes e Resultados 57
5.1 Sistema de tanques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 Modelagem do controlador . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 Construção do controlador Fuzzy-FF . . . . . . . . . . . . . . . . . . . . 62
5.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
i
6 Considerações Finais 73
Lista de Publicações 75
Referências bibliográficas 76
Lista de Figuras
2.1 Máquina de Watt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Malha de controle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 História dos sistemas de comunicação. . . . . . . . . . . . . . . . . . . . 9
2.4 Sistema Digital de Controle Distribuído-SDCD. . . . . . . . . . . . . . . 11
2.5 Convergência-CLPxSDCD. . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.6 Tendência das ligações dos sensores e atuadores. . . . . . . . . . . . . . 13
2.7 Tipos de redes de controle e automação. . . . . . . . . . . . . . . . . . . 14
2.8 Simplificação das redes. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.9 Comparação OSIxFF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.10 Estrutura de uma rede FF. . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.11 Arquitetura e organização do FF. . . . . . . . . . . . . . . . . . . . . . . 19
2.12 Modelo antigo com um driver para cada dispositivo. . . . . . . . . . . . 21
2.13 Simplificação proporcionada pelo OPC. . . . . . . . . . . . . . . . . . . 22
2.14 Funções de pertinência para o exemplo do carro. . . . . . . . . . . . . . . 25
2.15 Conjuntos Fuzzy x Conjuntos definidos. . . . . . . . . . . . . . . . . . . 25
2.16 Principais t-normas e t-conormas. . . . . . . . . . . . . . . . . . . . . . 27
2.17 Estrutura do controlador Fuzzy. . . . . . . . . . . . . . . . . . . . . . . . 28
2.18 Principais funções de pertinência. . . . . . . . . . . . . . . . . . . . . . 30
2.19 Exemplo de obtenção do grau de pertinência. . . . . . . . . . . . . . . . 30
2.20 Inferência através de Mamdani. . . . . . . . . . . . . . . . . . . . . . . . 31
2.21 Inferência através de Takagi e Sugeno. . . . . . . . . . . . . . . . . . . . 31
2.22 Métodos de desfuzzyficação. . . . . . . . . . . . . . . . . . . . . . . . . 33
2.23 Front Painel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.24 Block Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.25 Tela de conectores e ícone do programa. . . . . . . . . . . . . . . . . . . 35
2.26 Paleta de controles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.27 Paleta das funções. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.28 Exemplo de programa de temperatura. . . . . . . . . . . . . . . . . . . . 36
2.29 Tipos de linhas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.1 Tela do SYSCON: Ao centro a tela principal, À esquerda a tela de confi-

guração dos blocos, à direita a tela de configuração das lógicas. . . . . . . 38
3.2 Bloco Caracterizador de sinal (CHAR). . . . . . . . . . . . . . . . . . . 40
3.3 Estágio de fuzzyficação. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Bloco selecionador de entrada (ISEL). . . . . . . . . . . . . . . . . . . . 41
3.5 Estágio de inferência (cálculo do valor mínimo). . . . . . . . . . . . . . . 42
iii
3.6 Estágio de inferência (cálculo do valor máximo). . . . . . . . . . . . . . 43
3.7 Desfuzzyficação primeiro máximos (SOM). . . . . . . . . . . . . . . . . 44
3.8 Desfuzzyficação último dos máximos (LOM). . . . . . . . . . . . . . . . 44
3.9 Bloco Aritmético. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.10 Desfuzzyficação pelo método do centro de área. . . . . . . . . . . . . . . 46
4.1 Interface do programa. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Segunda aba do programa principal. . . . . . . . . . . . . . . . . . . . . 48
4.3 Terceira aba do programa principal. . . . . . . . . . . . . . . . . . . . . 49
4.4 Quarta aba do programa principal. . . . . . . . . . . . . . . . . . . . . . 50
4.5 Quinta aba do programa principal. . . . . . . . . . . . . . . . . . . . . . 50
4.6 Tela do programa gerador de Memberships (funções de pertinência). . . . 51
4.7 Segunda aba do programa gerador de funções(à esquerda) e funções defi-
nidas (gráfico central). . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.8 Terceira aba do programa gerador de funções. . . . . . . . . . . . . . . . 53
4.9 Terceira e quarta aba do programa gerador de funções. . . . . . . . . . . 54
4.10 Tela do programa configurador de regras. . . . . . . . . . . . . . . . . . 54
5.1 Sistema de tanques utilizado no teste. . . . . . . . . . . . . . . . . . . . 58

5.2 Esquemas de funcionamento de um controlador Fuzzy integrativo. . . . . 59
5.3 Controlador Fuzzy implementado no MATLAB. . . . . . . . . . . . . . . 60
5.4 Funções de pertinência para o Erro (entrada 1). . . . . . . . . . . . . . . 61
5.5 Funções de pertinência para a variação do Erro (entrada 2). . . . . . . . . 61
5.6 Funções de pertinência para o incremento de tensão (saída). . . . . . . . . 62
5.7 Módulo de cálculo do erro e da variação do erro. . . . . . . . . . . . . . 63
5.8 Estágio de Fuzzyficação-FF. . . . . . . . . . . . . . . . . . . . . . . . . 64
5.9 Estágio de inferência 1: Cálculo do valor mínimo entre funções de perti-
nência. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.10 Estágio de inferência 2: Cálculo do valor máximo entre as regras do con-
trolador. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.11 Estágio de Desfuzzyficação. . . . . . . . . . . . . . . . . . . . . . . . . 67
5.12 Módulo de saída do controlador (sinal de tensão enviado para a bomba). . 67
5.13 Superfície de resposta do controlador Fuzzy-MATLAB. . . . . . . . . . . 68
5.14 Superfície de resposta do controlador Fuzzy-FF. . . . . . . . . . . . . . . 68
5.15 Superfície de Erro (comparação de respostas entre os controlador Fuzzy-
MATLAB e Fuzzy-FF). . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.16 Sistema no Simulink para envio e obtenção dos dados do controlador
Fuzzy-FF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.17 Resposta do controlador Fuzzy-MATLAB (em vermelho) e Fuzzy-FF (em
azul) no controle do nível do tanque. . . . . . . . . . . . . . . . . . . . . 70
5.18 Resposta do controlador Fuzzy-FF para os macro ciclos de 516 ms (em
azul), 1000 ms (em vermelho) e 4000 ms (em ciano). . . . . . . . . . . . 71
Lista de Tabelas
2.1 Principais blocos funcionais Foundation Fieldbus. . . . . . . . . . . . . . 20

2.2 Classificação dos valores dos carros. . . . . . . . . . . . . . . . . . . . . 24
2.3 Principais t-normas e t-conormas. . . . . . . . . . . . . . . . . . . . . . 26
3.1 Tabela relativa a base de regras do exemplo. . . . . . . . . . . . . . . . . 39

3.2 Funções do bloco aritmético. . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1 Funções de pertinência utilizadas na aplicação teste. . . . . . . . . . . . . 60

5.2 Regras do controlador Fuzzy-FF. . . . . . . . . . . . . . . . . . . . . . . 62
v
Lista de Símbolos e Abreviaturas
A/D: Conversor de dados analógicos para digitais
AG: Algoritmos genéticos
AI: Analog Input, Bloco FF de entrada analógica
ARTH: Arithmetic, Bloco FF para cálculos aritméticos
BF: Blocos de função ou blocos funcionais, do inglês FB-Function blocks, são blocos
com funções predefinidas, implementados como objetos de software.
CHAR: Characterizer, Bloco FF caracterizador de sinais
CLP: Ou PLC é um Circuito Lógico Programável, um computador especializado base-

ado em microprocessador muito usado na indústria
COM: Component Object Model é uma tecnologia introduzida pela Microsoft que encap-
sula informações sobre programas, permitindo a interação entre diferentes partes
dos software
D/A: Conversor de dados digitais para analógicos
DCOM: Distributed Component Object Model é uma extensão da tecnologia COM para
sistemas distribuídos (ambiente em rede)
DFI: Distributed Field Interface, é um Linking Device responsável pelo controle da rede
Foundation Fieldbus servindo também de ponte Ethernet
FF: Foundation Fieldbus, um protocolo de rede industrial
FI: Conversor do padrão FF para o loop de corrente
H1: Barramento de alimentação dos instrumentos por onde trafegam os dados digitais
a uma taxa de 31.25 kbits/s
H2: Barramento de alimentação dos instrumentos por onde trafegam os dados digitais
a uma taxa de 1 a 2,5 Mbps/s
HSE: High Speed Ethernet, Tipo de conexão com internet de alta velocidade (100Mbit/s
até 1Gbit/s)
IF: Conversor de loop de corrente de para o padrão FF
vii
ISEL: Input Selector, Bloco FF selecionador de entrada
LabVIEW: Laboratory Virtual Engineering Workbench é um ambiente de programação

gráfica desenvolvido pela National Instruments
LAN: Local Area Network, é um rede local de computadores
LAS: Link Active Scheduler é o dispositivo responsável por gerenciar as comunicações

de uma rede FF
mA: miliampere, milésima parte do ampere que é a unidade de medição da corrente

elétrica
OLE: Tecnologia utilizada para comunicação entre aplicativos, baseado no COM
OPC: OLE for Process Control, é a tecnologia OLE utilizada em ambiente industrial, na
comunicação entre dispositivos
OSI: Open System Interconnection, é uma arquitetura para ligação entre computadores
que possui 7 camadas de abstração
PID: Proporcional, Integrativo e Derivativo, tipo de controlador utilizado na indústria
PN: Probe Node, mensagem do LAS para descoberta de novos dispositivos na rede
industrial
PR: Probe Response, resposta do dispositivo da rede à mensagem PN do LAS
RNA: Redes Neurais Artificiais
RS232: Padrão de comunicação de dados de maneira serial
SDCD: Sistema Digital de Controle Distribuído, formado por vários módulos específicos
(E/S, controle PID entre outros) interligados por uma rede de comunicação
V: Unidade de tensão elétrica
VI: Virtual Instrument é um programa gerado pelo LabVIEW

Capítulo 1
Introdução
A automação industrial cresceu muito nos últimos anos. A necessidade de se produzir

rápido e com qualidade desperdiçando o mínimo possível de recursos (matéria prima,
energia, mão de obra) é o objetivo almejado por qualquer ramo da indústria. Isso é o
grande diferencial na competição entre as diferentes empresas e pode determinar quem
continua no ramo ou quem fecha suas portas. Por este motivo, grandes investimentos são
realizados nessa área, produzindo dispositivos cada vez mais rápidos, precisos e robustos.
Com o advento dos computadores, estes passaram a ser introduzidos nos processos in-
dustriais, sendo como servidores de dados (entrada e saída automatizada de estoque, por
exemplo) ou como dispositivos programáveis, tornando a cadeia produtiva cada vez mais
autônoma, dependendo cada vez menos da intervenção humana. Estes sistemas computa-
cionais também foram gradativamente sendo embarcados em dispositivos comuns como
sensores e atuadores, dando-lhes a capacidade de processar as informações que recebem
do processo em que atuam, sem que deixassem de cumprir as exigências de robustez, se-
gurança e confiabilidade nos processos de medição e controle, tornando-os cada vez mais
independentes. Desta forma, os instrumentos de campo se tornaram instrumentos "inte-
ligentes", pois conseguem exercer muitas funções, além daquelas de monitorar ou atuar
em determinada parte do processo, de forma autônoma, ou seja, depois de programados,
eles podem cumprir suas tarefas sem grande necessidade da atuação do ser humano. Para
que tudo isso seja possível, novas tecnologias, protocolos de comunicação, hardwares e
software foram criados especificamente para este ramo da indústria.
Além dos instrumentos, a sua capacidade de comunicação também evoluiu. Se antes
eles utilizavam, na sua maioria, comunicação através de sistemas pneumáticos ou atra-
vés de fluxos de corrente, hoje em dia, graças aos sistemas embarcados nos dispositivos,
eles já se comunicam de forma digital entre si, levando muito mais que apenas a infor-
mação da variável do processo que estão medindo, mas também informações sobre o seu
funcionamento, condições do sinal de comunicação ou do estado do sensor ou atuador
entre outras. Este tipo de associação de equipamentos é denominado de rede industrial,
existindo diferentes tipos de redes com diferentes tipos de protocolos.
As redes industriais trouxeram enormes vantagens, desde sua robustez, imunidade a
ruído (muito presente na ambiente industrial), até mesmo a redução do cabeamento, já
que muitos protocolos de comunicação utilizam um único par de fios, que é o próprio
cabeamento de alimentação, para realizar a transmissão dos dados digitais. Outra vanta-
2 CAPÍTULO 1. INTRODUÇÃO
gem é a capacidade de trocar informação e da criação de lógicas de controle complexas,

pois quando ligados na mesma rede, vários sensores podem fornecer informações para
um atuador realizar um controle mais preciso do processo. Como cada dispositivo possui
seu próprio hardware, eles trabalham de forma independente e simultânea.
O próximo passo, na escala desses sensores, atuadores e redes industriais, seria a de
possuírem um nível maior de inteligência, onde fossem capazes de não só processar o
dado para uso entre eles ou para um nível superior (que analisaria e tomaria decisões, nor-
malmente um sistema supervisório controlado por um operador humano), mas também,
fossem capazes de realizar uma análise baseada em algoritmos inteligentes e tomar suas
próprias decisões. Essas novas funcionalidades devem ser implementadas utilizando as
funcionalidades básicas, bem como o hardware que cada dispositivo possui, de maneira a
não torná-lo mais complexo ou mais caro.
Alguns trabalhos visando desenvolver novas funcionalidades para estes instrumentos
foram realizados pelo pessoal do laboratório de sistemas inteligentes da Universidade
Federal do Rio Grande do Norte (LABSIS-UFRN) tentando assim aumentar o nível de
inteligência dos dispositivos. Trabalhos como os de [Cagni et al. 2005], [Costa 2006],
[Fernandes 2007] e [Silva 2006] visam dar condições a estes instrumentos de realizarem
essas novas tarefas sem a necessidade de modificação de seus hardwares ou softwares, ou
seja, utilizando as funções básicas nativas para criar novas aplicações.
Estes trabalhos se baseiam em algoritmos inteligentes como é o caso das redes neurais
artificiais que trazem vários benefícios como a possibilidade de aprendizagem supervisi-
onada ou não supervisionada, onde ela pode aprender através de informações coletadas
do próprio funcionamento da planta industrial. A rede neural artificial ou RNA é, se-
gundo a definição encontrada em [Haykin 2001], um processador maciçamente paralelo
distribuído constituído de unidades de processamento simples, que tem a propensão na-
tural para armazenar conhecimento experimental e torná-lo disponível para uso. Elas são
unidades extremamente simples de serem implementadas, gastando pouquíssimos recur-
sos computacionais, se tornando candidatas perfeitas para implementação de algoritmos
inteligentes em sistemas embarcados onde os recursos computacionais são escassos. Sua
maior complexidade esta no seu treinamento (ajuste dos pesos sinápticos), existindo uma
quantidade enorme de algoritmos para tal finalidade, que pode ser realizado externamente
à rede industrial e ter os seus resultados implantados posteriormente na configuração dos
instrumentos.
Outra tecnologia que já é muito utilizada no ambiente industrial em controladores
lógicos programáveis (CLPs) é a dos controladores Fuzzy. Os controladores Fuzzy são
baseados na lógica Fuzzy criada por Zadeh em 1965 [Zadeh 1965].Diferente da lógica
booleana [Weber & Klein 2003] que trabalha apenas com duas variáveis linguísticas (ver-
dadeiro ou falso, alto ou baixo, quente ou frio e assim por diante), a lógica Fuzzy trabalha
com um sistema multivalorado para cada variável linguística, ou seja, o valor de saída
para uma variável linguística pode não ser 100% verdadeiro ou 100% falso. Isso se as-
semelha bastante à forma de raciocínio humano, pois nossas variáveis linguísticas (alto,
baixo, gordo, magro, quente, frio e suas variantes como muito alto ou um pouco alto
e etc.) não são valores totalmente precisos, podendo variar de pessoa para pessoa. No
exemplo da altura, se uma pessoa possui 1.75cm, na lógica booleana, a afirmação de que
3
ela é alta teria apenas uma possibilidade de respostas que é ou verdadeiro ou falso. Neste
caso, a variável linguística alto começando a partir de 1.75cm faria a afirmação ser apenas
verdadeira, o que na lógica Fuzzy, a resposta poderia ser de 75% verdadeira para alta e
25% verdadeira para outra variável linguística como estatura mediana.
Desta forma, a lógica Fuzzy é capaz de remover a limitação da lógica binária das
máquinas, onde um dado só pode assumir dois valores (verdadeiro ou falso). Essa van-
tagem permite a criação de regras mais simples (inferências), não havendo a necessidade
de criar uma lógica mais complexa, especificando milhares de possibilidades com várias
sentenças, como é o caso da lógica booleana. Isso para sistemas computacionais não só
simplifica um conjunto de regras em um controlador, já que o operador não terá que criar
uma variável linguística e uma regra para cada valor possível do conjunto de entrada e
saída, como diminui o uso de recursos, nesse caso memória e processamento.
O primeiro a utilizar a lógica Fuzzy em um sistema computacional, mais precisamente
em um controlador, foi Mamdani [Mamdani 1974], que aproveitou essas vantagens para
criar um novo tipo de controlador baseado em regras de controle, onde poderia ser inserida
a experiência do operador da planta. Isso se deve ao fato de que muitos processos são
extremamente complexos para se gerar modelos matemáticos, existindo casos em que
algumas variáveis do processo não podem ser medidas e nestes casos, a experiência de
um operador que já tem o conhecimento empírico de como operar a planta, com suas
particularidades, é de extremo valor.
Um controlador que se utiliza da lógica Fuzzy tem suas entradas e saídas condiciona-
das a uma base de regras do tipo se-então. Essas regras são bem explícitas e montadas com
base no conhecimento do operador do sistema onde será inserido o controlador, gerando
a base de regras do sistema Fuzzy. Um exemplo disso seria o controle de nível de um
tanque, onde o operador deseja manter o nível sempre próximo a metade do tanque. Para
isso o operador utiliza uma válvula de controle que ao ser fechada ou aberta totalmente,
impede ou permite a entrada de líquido respectivamente, sendo que a entrada de líquido
com a válvula totalmente aberta ocorre com uma vazão superior à máxima de saída do
tanque. O operador com a sua experiência adquirida, sabe que ao amanhecer, a vazão
de saída do tanque aumenta e para manter o nível do tanque pela metade, é necessário
abrir a válvula dando mais ou menos duas voltas na válvula e por volta do entardecer, a
vazão de saída do tanque diminui, necessitando fechar a válvula com uma volta e meia
e depois da meia noite, a vazão diminui novamente, necessitando fechar mais um pouco
a válvula. Para passar esse conhecimento para o controlador, deve-se realizar o mapea-
mento das variáveis de entrada e saída em variáveis linguísticas que correspondessem as
ações tomadas pelo operador e criar regras para as situações desejadas ou esperadas.
Novas técnicas para redes industriais, utilizando as próprias funcionalidades básicas
existentes nos instrumentos, utilizam configurações mais elaboradas das suas lógicas de
controle que são formadas pelos blocos funcionais, objetos de software com funções pre-
determinadas, o que muitas vezes torna complexo o entendimento por alguém que não
trabalhou na sua criação. Sendo assim, a necessidade de se criar ferramentas que possam
auxiliar operadores a criar e gerenciar tais técnicas se torna imprescindível. Mas tais fer-
ramentas também devem ser de fácil utilização ou devem possuir certo grau de utilização
dentro de ambientes industriais. O LabVIEW é um ambiente gráfico de desenvolvimento
que já tem um certo grau de utilização no ambiente industrial, permitindo a criação de ló-
gicas de controle, análise de resultados, comunicação com diversos tipos de equipamentos
entre outras funcionalidade [Instruments & Shiralkar 2007]. Devido a sua aplicabilidade
e facilidade de utilização, pois utiliza a linguagem G que é uma linguagem totalmente
gráfica permitindo programar sem a necessidade de verificar sintaxes de linhas de pro-
grama, o LabVIEW se mostrou uma ótima opção para a implementação de ferramentas de
auxílio na construção de novas técnicas no ambiente industrial.
No trabalho de [Ramalho 2009] o LabVIEW foi utilizado para desenvolver um pro-
grama de configuração e reconfiguração de redes neurais aplicadas ao ambiente indus-
trial Foundation Fieldbus e que, posteriormente, teve a ideia aplicada ao trabalho de
[Machado 2009] na criação de um sistema Multiagente também para redes do tipo Foun-
dation Fieldbus onde cada agente utilizava uma rede neural como seu núcleo.
1.1 Objetivo
Com base no exposto, este trabalho tem como objetivo principal: Aplicação de um
controlador Fuzzy em redes industriais Foundation Fieldbus utilizando blocos funcionais
padrões auxiliado por um software desenvolvido em LabVIEW.
Esse trabalho teve início em [Filho et al. 2009], onde foram realizados alguns testes
das teorias apresentadas nesta dissertação, sendo implementado ao final um controlador
simplificado, com poucas regras, devido a dificuldade de alocar e configurar toda a lógica
do controlador. Além disso, os cálculos do erro e de sua variação (entradas do contro-
lador) eram realizados externamente a rede Foundation Fieldbus (em um computador),
sendo repassados os valores ao controlador através de placas de aquisição (placas de con-
versão D/A).
O software de auxílio deve ser capaz de gerar as funções de pertinência, utilizadas na
entrada do controlador, determinar a quantidade de blocos funcionais a serem utilizados a
partir da base de regras e do tipo de saída escolhida como também configurar os principais
parâmetros dos blocos, diminuindo a tarefa do operador. Como a alocação na rede dos
blocos funcionais e a sua interligação (lógica de controle) são realizadas através de um
software proprietário, essa função não pode ser realizada por esta ferramenta, cabendo
ainda ao operador realizá-la.
A principal motivação para a realização deste trabalho foi a ausência deste tipo de
controlador dentro do ambiente das redes industriais Foundation Fieldbus. Não existe
um bloco funcional que implemente tal controlador ou que facilite seu desenvolvimento,
mesmo este tipo de controlador sendo tão utilizado nos dias de hoje. Existem alguns tra-
balhos sobre Fuzzy e redes industriais Foundation Fieldbus, seja tentando desenvolver um
bloco Fuzzy Foundation Fieldbus ([Francisco et al. 2008]), seja utilizando ideias híbridas
([Lima 2004], [Carvalho et al. 2008], [Fadaei & Salahshoor 2008], [Leite et al. 2010] e
[Junior et al. 2005]), onde o controlador Fuzzy foi implementado em sistemas externos
a rede industrial, recebendo dela as leituras dos sensores e enviando a ela as ações de
controle, seja por placas de conversão D/A e A/D, seja por sistemas supervisórios. Dessa
forma, os instrumentos da rede Foundation Fieldbus não realizavam o controle efetiva-
mente, pois o controlador não estava sendo executado pelos instrumentos.
1.2. ESTRUTURA DA DISSERTAÇÃO 5
Espera-se que este trabalho possa promover e facilitar (através da ferramenta desen-
volvida) a configuração de tais controladores neste tipo de rede. Mesmo que no futuro a
rede Foundations Fieldbus venha a possuir blocos funcionais que desenvolvam a funcio-
nalidade de controladores Fuzzy, esta ferramenta pode vir a ser adaptada para continuar
permitindo essa facilidade configuração dos blocos funcionais relativos ao controlador.
1.2 Estrutura da Dissertação

O presente trabalho foi dividido em capítulos, totalizando com este 6 capítulos orga-
nizados da seguinte forma:
O capítulo 2 fornece toda a fundamentação teórica necessária para o entendimento dos
conceitos utilizados no trabalho, explicando o que são redes industriais, lógica Fuzzy e o
ambiente de programação LabVIEW. O capítulo 3 aborda os conceitos práticos de aplica-
ção de controladores Fuzzy no ambiente industrial Foundation Fieldbus (FF). O capítulo
4 exibe todas as características da ferramenta desenvolvida em LabVIEW para o auxílio
na configuração do controlador Fuzzy-FF. O capítulo 5 demonstra os resultados obtidos
em um teste prático. Por fim, o capítulo 6 aborda as considerações finais e propostas de
trabalhos futuros.
Capítulo 2
Fundamentação teórica
Este capítulo abordará toda a fundamentação necessária para o entendimento do tra-

balho, dando a noção sobre redes industriais, lógica Fuzzy e LabVIEW.
2.1 Redes industriais

No início da revolução industrial, todas as máquinas de uma indústria eram acionadas
de forma manual, onde cada operador deveria ler as variáveis do processo no local, e então
realizar o devido controle das máquinas de forma a garantir a finalização de sua parte na
linha de produção.
Com o passar do tempo, a elevação dos custos dos insumos e o desenvolvimento
de equipamentos e processos maiores e mais elaborados, impactando diretamente nas
atividades de comissionamento, operação e manutenção, tornou necessária a utilização
de formas de controle mais precisas. Começaram então a surgir os primeiros sistemas de
automação baseados em engenhosos sistemas mecânicos capazes de automatizar algumas
tarefas críticas e repetitivas das linhas de montagem [Duarte et al. 2003].
Por volta do final do século XVIII, James Watt desenvolveu um mecanismo capaz de
regular o fluxo de vapor em máquinas, sendo considerado um dos primeiros sistemas de
controle (com realimentação) utilizado na indústria [Maruyama 2004]. Esse mecanismo
consistia de um eixo possuindo dois braços com esferas pesadas nas pontas. Esse eixo era
ligado ao eixo da máquina a vapor de tal forma que quando a máquina estava funcionando,
girava esse sistema. Devido à força centrífuga aplicada as esferas, estas impulsionavam o
eixo fechando a tubulação por onde o fluxo de vapor passava, reduzindo a velocidade de
rotação da máquina. A Figura 2.1 exibe o desenho desse sistema.
O problema destes dispositivos era que deveriam ser desenvolvidos particularmente
para atuar em apenas um determinado problema, o que era bastante incomodo, já que não
poderia ser utilizado para outra tarefa, além de necessitar de grande manutenção devido à
utilização de partes mecânicas.
Uma malha de controle é formada basicamente por um transdutor, transmissor, um
controlador e um atuador (Figura 2.2).
Desta forma, o transdutor mede a variável do processo através do seu sensor (que
fornece o valor medido em alguma grandeza física) e converte esse sinal para outro sinal
de mesma espécie ou de espécie diferente. Um exemplo é transdutor de temperatura. A
8 CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA
Figura 2.1: Máquina de Watt.

[Maruyama 2004]
Figura 2.2: Malha de controle.
temperatura é medida por um sensor que pode fornecer um sinal elétrico correspondente
(ou uma variação num sinal elétrico proveniente do transdutor) e o transdutor lê esse sinal
(ou essa variação) e o converte para um sinal de corrente, pressão ou tensão. Normalmente
chama-se, erroneamente, de sensor o conjunto formando pelo sensor e transdutor, sendo
que o sensor é apenas uma parte do equipamento (a parte sensitiva do transdutor e no caso
do exemplo do sensor de temperatura, poderia ser uma resistência que varia com o valor
da temperatura).
Depois disso o sinal é repassado para o transmissor que recebe este sinal e o converte
para o padrão utilizado na comunicação como é o caso de um transmissor de pressão,
2.1. REDES INDUSTRIAIS 9
que pode converter um sinal de corrente em pressão de 3 a 15 psi (padrão utilizado nas
comunicações pneumáticas).
O controlador é o sistema que tem como objetivo manter uma determinada variável
do processo em um valor desejado, onde esse valor é chamado de ponto de ajuste (ou no
inglês, set-point). Ele recebe a informação do sensor e compara com o valor de ajuste,
obtendo um erro caso a variável esteja fora deste valor de ajuste. Então ele envia para o
atuador um sinal para tentar zerar esse erro ou, na pior das hipóteses, minimizá-lo.
O atuador é responsável pela modificação de alguma condição do processo que afeta
direta ou indiretamente a variável a ser controlada. Essa atuação pode ser o fechamento de
válvulas, ligar ou desligar equipamentos, aumentar ou diminuir a velocidade de motores
entre outros tipos de ações [Rosário 2005] e [Ribeiro 1999].
Nos anos 20, os dispositivos mecânicos começaram a ser substituídos pelos eletro-
mecânicos (relés e contatores), permitindo a criação de novas lógicas de controle, mais
sofisticadas e complexas. O inconveniente deste sistema era o seu tamanho, pois quando
a lógica se tornava muito complexa, os painéis de relés e contatores se tornavam demasi-
adamente grandes e complexos. Alterar uma malha de controle não era uma ação trivial.
A partir da década de 1930, surgiram os instrumentos pneumáticos que permitiam a
transmissão de informações sobre as variáveis do processo através de tubulações específi-
cas até certas distâncias, permitindo que os operadores ficassem reunidos em uma mesma
sala, a sala de controle [Gutierrez & Pan 2008]. Estes instrumentos trabalhavam basica-
mente com sinais de pressão que variavam na casa de 3 a 15 psi para o monitoramento
das variáveis (A Figura 2.3 a evolução dos sistemas de comunicação).
Figura 2.3: História dos sistemas de comunicação.

[Oliveira 2005]
Nos anos 50 surgiu o transistor e a partir deles vários dispositivos eletrônicos digi-
tais começaram a ser criados como é o caso dos computadores que se tornariam papel
importante nos sistemas de controle das indústrias nas décadas seguintes.
A comunicação por sinais elétricos analógicos (contínuos) começou a ser utilizada a
partir da década de 1960, o que permitiu a substituição da grande quantidade de tubos
utilizados para a transmissão pneumática, o que reduziu substancialmente o custo de ins-
talação dos sistemas, bem como o tempo de transmissão dos sinais, naturalmente lentos
nos sistemas pneumáticos, redução do ruído (já que os sistemas pneumáticos geram bas-
tante ruído quando o ar é expelido para o meio ambiente), maior facilidade de implantação
e manutenção e aumento de confiabilidade [Gutierrez & Pan 2008] e [Bordim 2006].
Ainda no começo da década de 60 surgiram os primeiros computadores que utilizavam
a tecnologia do transistor. Estes computadores (mainframes), ainda eram gigantes, caros,
de difícil manutenção e ocupavam grandes salas isoladas, onde poucas pessoas tinham
acesso e podiam operá-los. Somente grandes empresas tinham condições de comprá-los
e mantê-los para fins de aumentar a eficiência de algumas tarefas.
A utilização de computadores em ambientes industriais se dava na forma do controle
digital direto (CDD), onde um computador agia como um controlador, recebendo os va-
lores das variáveis do processo convertidas por placas de conversão A/D, recebendo os
ajustes dos parâmetros de controle por parte dos operadores, gerando os cálculos de con-
trole necessários e enviando de volta ao processo, por meio de placas de conversão D/A,
o novo sinal de controle [Ribeiro 1999]. O grande inconveniente destes sistemas era a
possibilidade de falha do computador, que acarretaria a falha catastrófica das malhas de
controle do processo. Para que isso não ocorresse, eram utilizados sistemas de backup
(um segundo computador ou controladores analógicos ligados ao processo que atuaria na
falha do computador) o que torna essa alternativa muito onerosa.
Com o surgimento dos microprocessadores a partir da década de 70 devido à inte-
gração cada vez maior dos componentes eletrônicos, surgiram também os microcompu-
tadores e diversos outros equipamentos com processadores embutidos. Isso facilitou o
surgimento dos sistemas de processamento distribuído, que permitem maior facilidade de
desenvolvimento, operação, administração, confiabilidade, manutenção simplificada en-
tre outros. Assim, o processamento deixava de ser gerado apenas em uma única máquina,
passando a ser executado por um conjunto de máquinas, que poderia estar dispostas em
uma mesma sala, ou em ambientes diferentes. Um dos sistemas criados nesse período e
que é muito utilizado até os dias de hoje é o SDCD, sigla para Sistema Digital de Controle
Distribuído.
Estes tipos de sistemas são separados em módulos onde cada módulo tem uma fun-
ção específica. Um módulo para controle PID com linearização de sinais não lineares,
outro para gerar as telas necessárias para operação da planta, módulos para regulação do
fluxo de informação entre outros [Ribeiro 1999]. A filosofia do SDCD tem como base a
utilização de terminais remotos conectados aos dispositivos de campo e conectadas en-
tre si a uma via de dados que por sua vez possui um elemento centralizador como um
PC dedicado [Duarte et al. 2003]. Uma grande vantagem destes sistemas é o seu alto
nível de redundância, já que podem existir diversos cartões de entrada e saída, redes de
comunicação, estações de trabalho além dos próprios computadores dedicados.
O SDCD foi desenvolvido na forma de um pacote proprietário fechado (Hardware
+ Software + Rede de Comunicação) com recursos adaptados às peculiaridades de cada
segmento da indústria, embutindo requisitos rigorosos de segurança, de gerenciamento
de alarmes e de comunicação em tempo real. A Figura 2.4 mostra a arquitetura de um
sistema digital de controle distribuído.
Desta forma, este sistema utiliza uma rede de comunicação por onde trafegavam todos
Figura 2.4: Sistema Digital de Controle Distribuído-SDCD.

[Gutierrez & Pan 2008]
os dados referentes ao processo e que podem ser acessados de cada terminal interligado
ao SDCD.
Outro dispositivo criado nessa época e utilizado também até os dias atuais foi o contro-
lador lógico programável, ou como é mais conhecido, CLP ou PLC (sigla do inglês). De-
senvolvido para suprir a necessidade da indústria automobilística da época, inicialmente
ele foi criado com a finalidade de substituir os gigantes painéis de relé, temporizadores e
os outros sistemas utilizados para realizar controle automático. Ele é um microcomputa-
dor mais robusto, projetado para trabalhar no chão de fábrica, próximo aos equipamentos,
mas com a desvantagem de possuir um conjunto de instruções reduzido se comparado a
um computador de escritório.
Os primeiros CLPs trabalhavam apenas com lógica de controle digital, pois não pos-
suíam interface de conversão analógica, sendo muito grandes e caros. Eles eram progra-
mados via terminais (portáteis ou não) onde sua programação utilizava e ainda utiliza o
diagrama de Ladder de relés. Da mesma forma que os sistemas SDCDs, os CLPs se co-
municavam com a sala de controle através de um barramento de dados e com sua rápida
evolução, ele passou a ser integrado aos SDCDs para controle digital.
Desta forma, os sistemas SDCDs eram utilizados para controle contínuo e os CLPs
para controle discreto, mas os avanços da eletrônica permitiram ao CLP alcançar outros
níveis, ganhando cada vez mais funcionalidades, passando também a realizar controle
contínuo e os SDCDs também incorporaram as funcionalidades de ligar e desligar equi-
pamentos, lógica Ladder, blocos de função entre outras. Isso acabou levando a inevitável
sobreposição de funções (Figura 2.5).
Na década de 1980, devido às exigências dos usuários e da evolução da eletrônica, os
microprocessadores começaram a ser implantados nos sensores e atuadores, tornando-os
Figura 2.5: Convergência-CLPxSDCD.

[Ribeiro 1999]
sensores e atuadores “inteligentes” [Bordim 2006]. Além disso, devido à grande integra-
ção dos instrumentos, os transmissores passaram a incluir os transdutores e muitas vezes
os próprios sensores, se tornando um instrumento completo, que realiza a medição e já en-
via o valor sob algum tipo padrão. Estes instrumentos dotados de poder de processamento
podem ser classificados em transmissores smart ou transmissores intelligent.
Um transmissor smart é um transmissor microprocessado com a capacidade de corri-
gir erro de não linearidade do seu sensor primário através de interpolação dos dados de
calibração mantidos na memória ou compensar efeitos de influência secundários sobre o
sensor primário incorporando um segundo sensor adjacente ao primário e interpolando os
dados de calibração dos dois sensores. Além disso ele é capaz de mudar sua calibração
por uma mudança no programa que ele executa, sem a necessidade de uma atuação me-
cânica no seu sensor, além de transmitir as medições do processo de forma digital sem
afetar as linhas comuns de comunicação analógica.
Já um transmissor intelligent, além de herdar as funções do transmissor smart, pode
armazenar informações referentes ao transmissor em si e dados de aplicação e também
pode gerenciar um sistema de comunicação que possibilita uma comunicação de duas vias
(transmissor-receptor e vice-versa) sobre a mesma linha que trafega o sinal de medição,
sendo possível realizar comunicação com qualquer equipamento ligado a rede [Ribeiro
1999].
Através do uso destes microprocessadores é possível realizar um pré-processamento
da informação no local da medição, tornando esta menos susceptível a interferências por
ruídos eletromagnéticos, muito presentes no ambiente industrial, distorções ou perdas do
sinal devido a sua propagação pelos fios ao nível do chão da fábrica. Com isso, a informa-
ção transmitida não precisa ser processada pelo receptor e da mesma forma, um comando
para um atuador pode ser mais complexo já que ele tem capacidade de interpretar e exe-
cutar, devido ao seu microprocessador.
Inicialmente as comunicações dos instrumentos eram ponto-a-ponto usando padrão

serial RS232C, mas esse padrão não se mostrou adequado para a utilização em ambiente
industrial por ter um sinal de tensão referenciado ao terra, sendo então susceptível a ruído
e impedindo-o de ser utilizado para distâncias maiores que 15 m além de não permitir a
utilização como barramento (utiliza comunicação apenas ponto-a-ponto).
Esse padrão foi substituído pelo RS422 e RS423 que utilizam tensão diferencial, o
que os torna extremamente imunes a ruídos, mas ainda tinham o mesmo problema do
RS232 de não permitirem a interligação simultânea de vários equipamentos entre si. Foi
desenvolvido então o padrão RS 485 que da mesma forma que o RS422 e 423, utilizava
tensão diferencial e permitia a ligação multiponto. Para uma rede aplicada a interligação
de dispositivos a nível de chão de fábrica é utilizada a denominação de barramento de
campo ou Fieldbus. Essa evolução pode ser vista na Figura 2.6.
Figura 2.6: Tendência das ligações dos sensores e atuadores.

[Stemmer 2001]
O nome Fieldbus é dado de forma genérica, mas na verdade as redes de chão de fábrica
podem ser divididas em três tipos diferentes: redes de sensores ou Sensorbus, redes de
dispositivos ou Devicebus e redes de instrumentação ou Fieldbus (Figura 2.7).
As redes SENSORBUS são rede mais simples, que interligam sensores e atuadores
discretos de maneira rápida, transmitindo basicamente bits de informação. A única preo-
cupação desse tipo de rede é manter os custos tão baixos quanto os possíveis.
As redes DEVICEBUS são redes que interligam dispositivos mais inteligentes e com-
Figura 2.7: Tipos de redes de controle e automação.

[Oliveira 2005]
plexos que os das redes SENSORBUS, cobrindo distâncias de até 500 m, com pacotes de
dados no formato de bytes, conseguindo gerenciar mais equipamentos e dados.
As redes FIELDBUS são redes com nível mais inteligente, onde os instrumentos lidam
com variáveis mais complexas, pois eles possuem a capacidade de desempenhar funções
de controle em loop (como PID), controle de fluxo e processos. As mensagens trocadas
nessa rede já são no formato de pacotes de dados, por onde são trocadas informações
analógicas, discretas, parâmetros, programas e informações de usuário [Bordim 2006] e
[Duarte et al. 2003].
A existência de tantos protocolos em cada tipo de rede deve-se ao fato de que cada
empresa tentou desenvolver o seu protocolo e torná-lo o modelo padrão a ser seguido,
mas o mercado tratou de selecionar apenas os mais aptos. Até os dias de hoje ainda existe
essa busca por um padrão universal, mas que está longe de acabar.
A rede utilizada para este trabalho é do terceiro nível (Fieldbus) e por este motivo,
será alvo de uma abordagem mais extensa.
2.1.1 Rede Industrial Foundation Fieldbus (FF)

O termo Fieldbus pode ser explicado como sendo uma rede de trabalho local (uma
LAN, sigla para Local Area Network) para instrumentos usados em processos e auto-
mação de mão de obra com capacidade embutida para distribuir o controle de aplicação
através da rede [Martins 2008].
O Foundation Fieldbus é um sistema de comunicação digital bidirecional que permite
a interligação direta de múltiplos instrumentos no campo, realizando funções de con-
trole e monitoração de processo e estações de operação através de softwares supervisórios

[Machado 2009].
Em 1992, dois grandes grupos lideravam o mercado para soluções de interligação de
instrumentos de campo:
• ISP (Interoperable Systems Project);
• WorldFIP (Factory Instrumentation Protocol);
Ambas possuíam diferentes visões de implementação das redes Fieldbus, mas garan-
tiam que iriam alterar seus produtos assim que a norma SP50 (norma desenvolvida por
várias empresas da área de instrumentação industrial) estivesse formalizada. Em setem-
bro de 1994, WorldFIP e ISP, juntaram-se criando a Fieldbus Foundation, com o objetivo
de acelerar o processo de normalização das redes Fieldbus [Bordim 2006].
O protocolo Foundation Fieldbus, ou FF, foi elaborado pela Fieldbus Foundation e
tem como principal ideia, interligar todos os dispositivos de campo em uma rede, per-
mitindo assim que tais instrumentos possam compartilhar informações de controle além
de permitir a monitoração e intervenção, se necessário, do funcionamento do processo
através de softwares supervisórios. Estes softwares têm, como principais características,
a possibilidade de adquirir dados do processo como medições de sensores e estados de
atuadores e exibi-los em uma tela com diferentes elementos gráficos que auxiliam o en-
tendimento, por parte do operador, de qual variável pertence a que dispositivo na planta
industrial.
Outra característica trazida pelo FF é que as estratégias de controle saem de um ele-
mento central (como é o caso de outros tipos de rede industrial que utilizam um CLP como
unidade de centralização das decisões de controle) e passam a ser distribuídas ao longo
dos dispositivos de campo. Isso se torna possível graças à ideia da utilização de blocos
funcionais para a configuração dos instrumentos e, mesmo sendo uma rede parecida com
uma LAN, ela possui maiores vantagens como o determinismo nas comunicações entre
os dispositivos, o que permite sistemas de controle mais robustos e seguros, sem que haja
a necessidade do usuário se preocupar com atrasos nas comunicações dos instrumentos e
com falhas em malhas de controle geradas por eles [Martins 2008].
Um dos benefícios deste novo protocolo é o seu custo de implantação, pois nessa
tecnologia, a transmissão dos dados é realizada de forma digital e serial por um par de
fios. Esse par de fios é o mesmo utilizado na alimentação dos dispositivos, o que diminui
significativamente a quantidade de equipamentos de campo auxiliares, como é o caso dos
subsistemas de entrada e saída, CLPs, fontes de alimentação e quantidade de cabos. A
Figura 2.8 exibe a simplificação da rede com este tipo de protocolo.
Os instrumentos que utilizam esse protocolo realizam mais tarefas do que apenas a
leitura de uma variável do processo. Eles podem transmitir o estado da comunicação, o
estado do sensor ou atuador que monitoram, podendo realizar nova calibração caso os
sensores estejam fora da faixa de operação entre outras funcionalidades. Desta forma, a
quantidade de dados transmitidos é bem superior do que as dos outros protocolos mais
simples, além de que os sensores realizam a digitalização das variáveis do processo com
altas resoluções (quantidade de bits para representar o dado) para que possam ser trans-
mitidas para outros instrumentos ou para o sistema supervisório sem perda de informação
da medição.
Figura 2.8: Simplificação das redes.

[Martins 2008]
O protocolo FF é um protocolo aberto, ou seja, todas as empresas que desejarem fabri-

car equipamentos com este protocolo têm acesso ao seu funcionamento, permitindo que
existam diversos fabricantes de equipamentos e que os usuários finais (as indústrias) pos-
sam escolher com quais fabricantes irão trabalhar. Como os dispositivos podem pertencer
a diferentes fabricantes, foi necessária a padronização das funções a serem executadas
pelos instrumentos nesse protocolo. Isso foi conseguido pela utilização dos blocos de
função (BF ou em inglês FB-Function Blocks) que são blocos de funções pré-definidas e
implementadas em software (objetos de software) que realizam desde funções simples de
captura de dados dos sensores até tarefas mais complexas como controle de processo.
Com relação ao seu funcionamento, o protocolo FF pode ser dividido em três camadas:
• A camada física
• A pilha de comunicação
• A camada aplicação
Ele foi baseado no modelo OSI de comunicação com a diferença que o protocolo FF
é mais simplificado, não possuindo as camadas 3, 4, 5 e 6, já que a camada equivalente
a camada 7 do modelo OSI mapeia diretamente a camada de especificação de mensagens
na camada de link da dados. A Figura 2.9 mostra o que foi explicado.
A camada física é a responsável por converter os dados recebidos da camada de link
de dados para sinais digitais que irão trafegar sobre o par de fios da alimentação. Os
dados digitais são sinais elétricos de corrente com amplitude de ± 10 mA trafegando
sobre os fios a uma taxa de 31.25 Kbps e são recebidos pelos instrumentos que possuem
um impedância de entrada de 50 ohms possibilitando que eles leiam uma tensão em sua
entrada de 1 V de pico a pico. Este barramento é conhecido como H1, que é mais lento,
mas intrinsecamente mais seguro, existindo também o barramento H2, com velocidades
Figura 2.9: Comparação OSIxFF.

[Martins 2008]
de 1 a 2,5 Mbps, sendo que este não foi realmente implementado na indústria, além da
existência do barramento HSE (High Speed Ethernet) de alta velocidade (100 Mbps) que
é utilizado com os Linking Devices para se comunicar com o barramento H1. A Figura
2.10 ilustra a configuração de uma rede.
A camada de link de dados (2a camada) é responsável pelo gerenciamento das co-
municações na rede. Ela realiza tal função através de um programa que agenda todas
as comunicações de forma determinística chamado de link active scheduler (LAS ou em
uma tradução literal, agendador de link ativo). Esse programa encontra-se dentro de dis-
positivos dotados da capacidade extra de processamento e memória, chamados de Link
Masters ou mestres de link. Os outros dispositivos que não possuem tal capacidade são
chamados de dispositivos básicos. Além destes dois tipos de instrumentos, existe também
os Linking Devices que são instrumentos que além de possuir a capacidade de serem Link
Masters possuem a funcionalidade de interligar os segmentos H1.
Quando a rede industrial inicia seu funcionamento, o LAS monta uma lista com todos
os instrumentos que estão na rede e o tempo em que esses instrumentos executarão suas
funções e divulgarão seus dados. Esse processo chama-se escalonamento e determina
quando os blocos de função dos instrumentos serão executados e quando ocorrerão as
comunicações. Isso garante o determinismo da rede, proporcionando ao usuário saber de
quanto em quanto tempo um dado será atualizado numa malha de controle ou em qualquer
outro tipo de lógica alocada nos instrumentos [Martins 2008].
Essa lista é chamada de lista vital (live list) e o LAS tem a função de sempre atu-
alizar tal lista, caso instrumentos deixem de funcionar na rede (por problemas ou por
terem sido removidos) ou caso algum instrumento novo seja inserido. O LAS percorre
Figura 2.10: Estrutura de uma rede FF.
esta lista, determinando quando cada instrumento deverá transmitir seus dados. O proto-
colo Foundation Fieldbus trabalha com o esquema de publish/subscriber (esquema pro-
dutor/consumidor), onde cada dispositivo pode publicar seus dados na rede e aqueles que
os necessitam, realizam a sua leitura, existindo dois tipos de comunicações na rede, a
síncrona e a assíncrona.
A comunicação síncrona é a que leva em consideração a ordem de publicação dos
dados, de acordo com o agendamento realizado pelo LAS. A comunicação Assíncrona
é realizada entre as comunicações síncronas, pois, quando um instrumento está proces-
sando a informação recebida da rede, esta fi ca ociosa, então o LAS permite que outros
instrumentos possam utilizá-la para enviar pacotes de dados, como por exemplo, pacotes
de monitoração de funcionamento dos dispositivos, de confi guração, entre outros.
Ao terminar a transmissão de todos os pacotes de todos os instrumentos, o LAS ve-
rifi ca se existem novos dispositivos na rede enviando, para outros endereços da rede,
pacotes PN (Probe Node) e existindo novos dispositivos, estes deverão responder com um
pacote PR (Probe Response), fazendo com que o LAS os adicione na Live List. Termi-
nando essas tarefas o LAS reinicia a função de percorrer a lista vital [Duarte et al. 2003].
Esse ciclo, realizado pelo LAS que percorre a lista vital, executando o escalonamento
das comunicações e esperando a execução das funções de cada instrumento, se chama
macro ciclo e é de suma importância a determinação do tempo deste ciclo na criação das
lógicas de controle, pois ele é que determina o tempo em que as lógicas de controle são
executadas (leitura do dados pelo sensor, processamento da informação pelo controlador,
execução de uma ação pelo atuador).

As funções do agendador de link (LAS) basicamente são:
• Percorrer a lista vital e determinar que instrumento irá transmitir seus dados em que
tempo.
• Manter a lista vital, verifi cando a existência de novos dispositivos ou a remoção de
algum.
• Sincronização do relógio dos dispositivos, para que eles possam se comunicar no
tempo certo.
• Envio do sinal de passagem, onde cada dispositivo pode enviar dados entre as co-
municações agendadas no macro ciclo (comunicações assíncronas).
A camada de aplicação do usuário não é defi nida no modelo OSI, mas foi defi nida no
protocolo FF e é onde o usuário pode desenvolver as suas lógicas de controle e monitora-
ção.
Ela é um dos aspectos mais importantes deste protocolo, sendo baseada nos blocos
funcionais, permite a criação de diversas lógicas e a interoperabilidade de instrumentos e
lógicas.
Blocos Funcionais
A Figura 2.11 mostra como é formada esta camada.
Figura 2.11: Arquitetura e organização do FF.

[Martins et al. 2008]
Os blocos funcionais ou blocos de função são blocos com funções pré-definidas en-
capsuladas em um objeto de software. Eles são totalmente transparentes para o usuário,
que não tem acesso ao seu funcionamento (o código fonte do bloco). Cada bloco é dotado
de entradas, saídas e parâmetros internos que podem ser ajustados pelo usuário. Exis-
tem basicamente três tipos básicos de blocos funcionais: os Resource Blocks (blocos de
recurso), Transducer Blocks (blocos transdutores) e Function Blocks (blocos de função)

[Duarte et al. 2003].
Os blocos de recursos descrevem as características físicas do instrumento como ID do
fornecedor, versão do dispositivo, capacidade de memória, data de revisão entre outras.
Eles podem ser visualizados, mas não podem fazer parte das lógicas de controle efetuadas
pelo usuário nem serem escalonados para a execução pelo LAS.
Os blocos transdutores são os blocos que interligam os blocos de função aos sensores
e ou atuadores do instrumento, realizando a tarefa de conformar os sinais vindos do sensor
(ou que vão para o atuador) para a escala padrão do instrumento, podendo trabalhar em
velocidade superior a dos blocos de função. Da mesma forma que os blocos de recursos,
eles não podem ser visualizados, fazer parte das lógicas de controle criadas pelo usuá-
rio nem ser escalonado para a execução, mas podem até ter alguns de seus parâmetros
modificados (no caso de calibração do sensor, por exemplo).
Os blocos de função são os blocos que permitem a criação de lógicas de controle
por parte do usuário. Cada bloco realiza uma função diferente, possuindo uma ou mais
entradas e saídas e são devidamente escalonados pelo LAS, determinando seu tempo de
execução em um macro ciclo.
Existem diversos blocos de função, pois cada fabricante pode criar seus próprios blo-
cos sob as normas do protocolo, mas as especificação do protocolo FF define os principais
blocos que devem existir de forma a permitir a utilização das funcionalidades básicas em
uma planta industrial. A Tabela 2.1 exibe alguns exemplos de blocos bem como aqueles
que são utilizados neste trabalho.
Sigla Descrição do bloco

AI Analog Input (Entrada analógica).
AO Analog Output (Saída analógica).
ARTH Arithmetic (Aritmético).
CHAR Signal Characterizer (Caracterizador de sinais).
CT Constant (Constante).
DI Discrete Input (Entrada discreta).
DO Discrete Output (Saída discreta).
ISEL Input Selector (Seletor de entrada).
PID Proportional/Integral/Derivative (Proporcional/Intergral/Derivativo).
Tabela 2.1: Principais blocos funcionais Foundation Fieldbus.
[Smar 2005]
Linking Device
Como foi exibido na Figura 2.10, existe o elemento centralizador que serve de ponte
H1-HSE chamado de linking device. No caso da rede utilizada neste trabalho o linking
device se chama DFI (Distributed Field Interface). A DFI é o hardware responsável por
gerenciar toda a rede FF, possuindo até 4 canais H1, ela gerencia todas as comunicações
por possui a implementação do LAS. Da mesma forma que os dispositivos de campo, ela
também deve ser configurada através de blocos funcionais, podendo inclusive participar
das malhas de controle, possuindo uma capacidade maior de memória para alocação dos
blocos funcionais.
Cada instrumento de campo pode armazenar no máximo 20 blocos funcionais, en-
quanto a DFI pode armazenar até 100 blocos, sendo útil para a criação de lógicas de con-
trole grandes e complexas. Como trabalha como bridge HSE, tem seu próprio endereço IP
e utiliza, como sistema de comunicação neste nível, o OPC, sendo então responsável por
encapsular os dados de comunicação dos dispositivos de campo em datagramas ethernet
100BaseT sobre protocolos UDP e IP.
OPC
Por causa do crescente aumento de fabricantes de dispositivos industriais surgiu o

problema da desconexão dos sistemas dentro de uma mesma empresa. Equipamentos di-
ferentes trabalham com drivers de comunicação diferentes, necessitando que o software
supervisório possuísse cada driver de cada dispositivo que iria monitorar no chão de fá-
brica (Figura 2.12), o que implica em um grande esforço humano na programação de cada
driver para cada dispositivo, o que muitas vezes não era realizado, levando o usuário final
(o dono da empresa ou o projetista/engenheiro responsável) a comprar equipamentos e
softwares de uma mesma empresa, mesmo que estes não atendessem às suas expectati-
vas, só para garantir a compatibilidade e transferência de dados entre os dispositivos e o
software supervisório.
Figura 2.12: Modelo antigo com um driver para cada dispositivo.
Por este motivo, surgiu a necessidade de se criar um sistema que facilitasse o desen-
volvimento de softwares. Surgiu ai o início do desenvolvimento do OPC. O OPC é um
padrão de comunicação aberto, que tem por principal objetivo permitir a interoperabi-
lidade vertical entre sistemas dentro de uma organização. A sigla OPC significa OLE
for Process Control ou OLE para Controle de Processos. Baseado nas tecnologias Mi-
crosoft OLE COM (Component Objetc Model) e DCOM (Distributed Component Object
Model), o OPC é um conjunto comum de interfaces, métodos e propriedades de comuni-
cação, agregados dentro de uma especificação padronizada e aberta para acesso público
[Puda n.d.].
A Microsoft teve a ideia de criar um sistema que permitisse o compartilhamento de
dados entre softwares diferentes de maneira mais prática, utilizando objetos. Cada ob-
jeto seria como uma instância do próprio software, que poderia ser chamado de dentro
de outro programa, acessando métodos do objeto referente a funcionalidades do software
instanciado ou mesmo, dados dele. Essa é a ideia por trás do OLE COM. Um exemplo
disso é quando se cria uma tabela Excel dentro do Word, onde a tabela do Excel abre uma
pequena janela onde o próprio Excel é visto em execução, com todas as suas funcionali-
dades, mas estando dentro do software Word. O que realmente acontece neste caso é que
o usuário criou um objeto Excel dentro do Word e pode manipulá-lo como se estivesse
realmente dentro do Excel.
O DCOM é apenas uma extensão do COM, mas agora sendo utilizado em um am-
biente de rede, quando os objetos estão distribuídos em máquinas diferentes. Como essa
tecnologia gerou bons resultados para os sistemas operacionais da Microsoft, ela começou
a ser estuda e adaptada para os sistemas industriais, surgindo assim o OPC. Com o OPC,
as diferentes empresas necessitam agora apenas criar seus dispositivos e seus servidores
OPC e com isso, os sistemas supervisórios passaram a ser clientes OPC, desaparecendo a
necessidade de se criar drivers para cada instrumento de campo. A Figura 2.13 exempli-
fica isto.
Figura 2.13: Simplificação proporcionada pelo OPC.
Com a utilização do OPC, a comunicação entre dispositivos de campo e os sistemas

supervisórios se resumiu a existência de um servidor OPC de cada fabricante que pode ler
(e disponibilizar) os dados de seus dispositivos na máquina onde o software está instalado
2.2. LÓGICA FUZZY 23
ou em rede e um ou vários clientes OPC (os sistemas supervisórios) que requisitam tais
dados. Essa é a forma que a DFI trabalha. Junto com o dispositivo é fornecido o seu
software de configuração (e de configuração de blocos funcionais dos instrumentos) que
já tem seu servidor OPC. Esse servidor, depois de instalado na máquina, faz a leitura dos
dados da(s) rede(s) ligada(s) à DFI (leitura dos sensores, posição dos atuadores, alarmes
e etc.) e disponibiliza para qualquer cliente OPC que se conecte a ele.
Isso permite a escolha de qualquer software supervisório que trabalhe com tal tecno-
logia (a maioria senão todos os supervisórios encontrados nos dias hoje), levando apenas
em consideração as funcionalidades de cada um (facilidade de utilização, interface grá-
fica, nível de segurança entre outras).
2.2 Lógica Fuzzy

O termo lógica foi criado por Aristóteles, com contribuições de Platão e Sócrates,
filósofos gregos, que de forma contínua desenvolveram este princípio. Sócrates propôs
uma forma de se investigar o pensamento, que foi utilizado por Platão, seu discípulo, em
diálogos para defender seu mestre e, posteriormente, Aristóteles desenvolveu as regras
para o pensamento. Estes estudos no campo da lógica continuaram até os dias de hoje,
com notáveis contribuições. Uma delas foi a do matemático inglês Boole, no século XIX,
que estudou e empregou com sucesso as ideias algébricas no domínio da lógica, definindo
uma matemática abstrata [Weber & Klein 2003].
Dessa forma, afirmações lógicas passaram a utilizar formalismo matemático, sendo
calculadas de forma algébrica e obtendo resultados bem definidos para afirmações (ver-
dadeiro ou falso, alto ou baixo, quente ou frio, pertence ou não pertence a um conjunto).
A álgebra booleana é binária, pois reduz as afirmações a apenas verdadeiro ou falso, ou no
caso de sistemas computacionais, 1 ou 0 relativos aos bits. Isso também reduz à utilização
dos conectivos OU, E e NEGAÇÃO com diversos circuitos lógicos que implementam tais
conectivos, chamados de portas lógicas.
Mas em alguns tipos de problemas, ter apenas duas possibilidades (verdadeiro ou
falso, por exemplo) não satisfaz completamente a resposta do problema. Valores interme-
diários a estes dois seriam respostas melhores, sendo que no caso dos sistemas computa-
cionais isso levaria a utilização de circuitos analógicos para conseguir valores entre 1 e 0,
levando a aumentar a complexidade dos circuitos em geral.
As afirmações para as quais não se pode ter muita certeza necessitam de uma modela-
gem diferenciada. Pode-se dizer que ira chover hoje, mas posso afirmar isto com um grau
de certeza de 0.8, por exemplo, tomando como base que a certeza completa é grau 1.0.
Este tipo de situação é um modelo de lógica Fuzzy. A lógica Fuzzy opera com propostas
que podem ser verdadeiras com grau de certeza de 0 a 1 [Weber & Klein 2003].
A lógica Fuzzy foi proposta pela primeira vez em 1965 pelo engenheiro eletricista
Lotfi A. Zadeh em um artigo chamado Fuzzy Sets [Zadeh 1965]. Ele procurava resolver
um problema que ele observou onde os recursos computacionais disponíveis eram inca-
pazes de automatizar atividades humanas relacionadas a problemas de natureza indus-
trial, biológica ou química, que compreendessem situações ambíguas, ou que, segundo
suas próprias palavras, apresentassem “sentimentos matemáticos humanísticos” [Weber

& Klein 2003].
Um objetivo da lógica Fuzzy é fazer computadores “pensarem” como pessoas. Ela
pode lidar com a incerteza intrínseca ao pensamento humano e da linguagem natural e
reconhecer que ela é naturalmente diferente da aleatoriedade. Usando algoritmos com ló-
gica Fuzzy pode-se permitir que máquinas compreendam e respondam conceitos humanos
vagos como quente, frio, grande, pequeno e etc. podendo também prover uma abordagem
relativamente simples de se chegar a conclusões definidas a partir de informações impre-
cisas [Ibrahim 2004]. Por exemplo, o conjunto de pessoas que tem dinheiro para comprar
um carro à vista é bem definido, sem ambiguidades, pois cada pessoa deverá possuir uma
quantidade igual ou superior ao valor do carro para comprá-lo. Logo, se o conjunto A de
pessoas que podem comprar um carro à vista esta contido no conjunto universo U de todas
as pessoas que possuem renda, podemos definir a função característica (função na lógica
tradicional que relaciona os elementos com o conjunto) de um indivíduo x ∈U como:
(
1 se x ∈ A
γA (x) = (2.1)
0 caso contrário
Neste caso a função característica γ(.) sempre assumirá os valores 0 ou 1, mas quando
A é um conjunto Fuzzy e x é um objeto relevante, a proposição "x é membro de A"não
é necessariamente verdadeira ou falsa, como requerido numa lógica de dois valores, mas
pode ser somente verdadeira para algum grau, o grau para o qual x é atualmente um
membro de A. Desta forma, está função passa a ser chamada de função de pertinência,
denotada como µ(.), que mostra o grau com que uma variável se relaciona com o con-
junto. É muito comum, mas não necessário, expressar graus de funções de pertinência em
conjuntos Fuzzy, bem como os graus de verdade associados as proposições, por números
no conjunto fechado [0,1][Klir & Yuan 1995].
Um exemplo de conjunto nebuloso seria o das pessoas que acham caro ou barato os
preços de um carro popular (que deve ser, por exemplo, em torno de R$ 23.000). A
variável agora seria o preço e ela poderia assumir os seguintes valores:
P=p0 (muito barato), p1(barato), p2(normal), p3(caro) e p4(muito caro) (2.2)
Ao se entrevistar pessoas na rua poderia-se obter a Tabela 2.2 abaixo:
Valor
P Preços dos carros
linguístico
Muito
p0 19.000 19.000 20.000 21.000
Barato
p1 Barato 20.000 21.000 22.000 23.000
p2 Normal 22.000 22.000 23.000 24.000
p3 Caro 23.000 24.000 25.000 26.000
p4 Muito caro 25.000 26.000 26.000 27.000
Tabela 2.2: Classificação dos valores dos carros.
Montando-se as curvas das funções de pertinência obteríamos a Figura 2.14.
Figura 2.14: Funções de pertinência para o exemplo do carro.
Os conjuntos Fuzzy facilitam a transição gradual entre estados e, consequentemente,

possuem a capacidade natural para expressar e tratar incertezas de observações e medi-
ções, o que os conjuntos definidos (crisp) não podem fazer. Embora os conjuntos defini-
dos estejam matematicamente corretos, eles são irrealistas frente a medições com erros
[Klir & Yuan 1995]. A Figura 2.15 ilustra a diferença entre conjuntos Fuzzy e Defi nidos
(com seus respectivos valores linguísticos).
Figura 2.15: Conjuntos Fuzzy x Conjuntos definidos.

[Klir & Yuan 1995]
Pode-se perceber que se a variável se aproximar da fronteira de decisão entre dois

determinados conjuntos (por exemplo, entre os conjuntos LOW e MEDIUM), no caso dos
conjuntos definidos, qualquer variação na medição faria o sistema oscilar rapidamente
entre um conjunto e outro. Já no caso dos conjuntos Fuzzy, uma pequena variação na
medição não afetaria o sistema, já que o que iria se alterar seriam apenas os graus de
verdade para as duas funções, mas elas continuariam sendo verdade.
As variáveis linguísticas vistas na Tabela 2.2 são elementos simbólicos utilizados para
descrever o conhecimento, pois a lógica Fuzzy as utiliza no lugar de variáveis numéricas.
Elas são associadas a conjuntos Fuzzy (ou funções de pertinência) relacionando a es-
ses termos linguísticos, os graus de pertinência, possibilitando um significado numérico
[Weber & Klein 2003].
Utilizando-se da ideia de termos linguísticos, pode-se definir sentenças lógicas con-
dicionais do tipo “Se premissa então conclusão”. Continuando no exemplo dos preços
do carro popular, digamos que os valores linguísticos relativos ao preço são as entradas
do processo de compra de um carro e a saída seria as variáveis linguísticas relativas ao
interesse na compra, denotado por I. Então, um exemplo de uma sentença seria:
Se (P é barato) então (I é alto) (2.3)

Na lógica tradicional as operações lógicas realizadas com conjuntos (criando sen-
tenças compostas para as premissas, por exemplo) utilizam operadores lógicos como E
(Intersecção), OU (União) e NEGAÇÃO (complemento). Como na lógica Fuzzy, os con-
juntos são nebulosos, foram definidas novas formas de realizar estas operações, que são
basicamente divididas em duas classes: As t-normas (usadas para intersecção) e as t-
conormas (usadas para a união). As principais t-normas e t-conormas são exibidas na
Tabela 2.3 e de forma gráfica, sobre conjuntos com funções de pertinência triangular, na
Figura 2.16.
t-norma t-conorma Nome
min(a,b) max(a,b) Zadeh
a.b a+b-ab Probabilística
max(a+b-1,0) min(a+b,1) Lukasiewicz
 
a
 se b=1 a
 se b=0
b se a=1 b se a=0 Weber
 
0 senão 1 senão
 
Tabela 2.3: Principais t-normas e t-conormas.

[Sandri & Correa 1999]
A NEGAÇÃO ou complemento é dada pelo principal operador: A=1-A.
2.2.1 Controlador Fuzzy

Quando se deseja criar um sistema de controle para um processo, necessita-se, primei-
ramente, obter seu modelo matemático utilizando técnicas como transformada de Laplace
Figura 2.16: Principais t-normas e t-conormas.

ou transformada Z. Para isso, cada parte do processo a ser modelado deve ser conhecida
para que a modelagem possa ser a mais fiel possível. Isso muitas vezes não é possível, pois
muitas variáveis do mundo real, que influenciam direta ou indiretamente o processo, não
podem ser quantificadas e outras são totalmente desconhecidas ou mesmo, a modelagem
completa do sistema leva à equações extremamente grandes e complexas. Um exemplo
disso é a temperatura em um processo, que pode variar de uma área para outra por causa
da presença ou ausência de proteção contra o sol nestes locais e que muitas vezes não é
considerada no modelo.
Por estes e outros motivos que modelos de processos são na maioria das vezes repre-
sentações mais simplificadas, que possam levar o projetista a uma análise do processo
o mais próximo possível do real, mas no final, a própria experiência dos operadores do
processo é que permite a sintonia fina dos controladores. Os operadores, analisando o
processo durante dias, meses ou até anos, acabam por descobrir determinadas particulari-
dades do seu funcionamento (variações com chuva, sol, vento, calor, frio, estações do ano
e etc.) e baseados nessas analises determinam a melhor sintonia para os controladores.
A ideia básica em controle Fuzzy é modelar as ações a partir de conhecimento es-
pecialista, ao contrário de modelar o processo em si. Esta abordagem é diferente dos
métodos convencionais de controle de processos, onde os mesmos são desenvolvidos via
modelagem matemática [Pagliosa 2003].
As técnicas de controladores nebulosos originaram-se com os trabalhos propostos por
Mamdani [Mamdani 1974], que após inúmeras tentativas frustradas de controlar uma
máquina a vapor com tipos distintos de controladores, inclusive o PID (Proporcional,
Integrativo e Derivativo), somente conseguiu fazê-lo através da aplicação do raciocínio
Fuzzy [Weber & Klein 2003].
Os controladores Fuzzy podem ser dividido em três fases, como visto na Figura 2.17.
Figura 2.17: Estrutura do controlador Fuzzy.
Funções de pertinência
Para iniciar a criação do controlador Fuzzy, é necessário antes montar os conjuntos
Fuzzy (as funções de pertinência) que serão utilizadas tanto na entrada do controlador
(estágio de Fuzzyficação) quanto na saída do controlador (estágio de Desfuzzyficação).
Para isso é levantado primeiramente as variáveis linguísticas que serão utilizadas, sendo
depois divididos os conjuntos relativos a estas variáveis.
Existem diversos métodos encontrados na literatura, como por exemplo, em [Klir &
Yuan 1995], são definidos dois métodos de construção das funções de pertinência: o
método direto e o método indireto. No método direto, o especialista é quem deve informar
todos os dados das funções de pertinência (quem são os valores que representam cada
função e o grau de pertinência, dentro da função, de cada um deles) de forma a defini-las
explicitamente. Já no método indireto, as informações fornecidas pelos especialistas são
mais simples, como a comparação entre os elementos dentro do conjunto, e partir destas
informações são calculados os graus relativos a cada variável.
Base de regras
Como vista na Figura 2.17 a base de regras é utilizada na segunda fase do controla-
dor, pois a partir dela é que podem ser realizados os cálculos referentes às entradas do
controlador.
Essa base de regras também é montada através do conhecimento do especialista, que
no caso de uma indústria, pode ser um operador da planta, um engenheiro ou qualquer
outra pessoa que esteja ligada diretamente com o processo e que possua grande conheci-
mento teórico e empírico de seu funcionamento. Ele determina qual ação deve ser tomada
para determinada entrada, mapeando a entrada, que seria uma variável linguística, numa
saída, outra variável linguística.
A base de regras é montada utilizando sentenças condicionais com a seguinte estru-
tura:
Se <premissas> Então <conclusão> (2.4)
Um exemplo desse tipo de regra para o controle de freio de um carro para não bater
num objeto a frente seria:
Se “velocidade é alta” e “distância é pequena” então “aplicar grande força”.

A quantidade de regras varia de um controlador para outro (com a quantidade de en-

tradas e saídas), mas deve existir uma quantidade suficiente de forma que possa abranger
todas as possíveis combinações das entradas e saídas, pois do contrário, pode acontecer
uma combinação de entradas em que o controlador não saberá exatamente o que fazer.
Outra coisa que deve ser analisada é a consistência das regras que não devem conter con-
tradições, ou seja, uma regra mandando abrir uma válvula para um determinado conjunto
de entradas e outra regra mandando fechar a mesma válvula com o mesmo conjunto de
entradas.
Estágio de Fuzzyficação
O estágio de Fuzzyficação é o primeiro estágio do controlador Fuzzy e é responsável

por normalizar as variáveis de entrada no universo de discurso (universo do problema),
identificando a qual ou quais conjuntos Fuzzy elas pertencem, atribuindo o grau respec-
tivo de cada pertinência (o µ(.)). Os conjuntos Fuzzy, representados pelas funções de
pertinência, devem ser ajustados sobre o universo de discurso de maneira a cobri-lo com-
pletamente.
Existem várias funções de pertinência, mas as mais utilizadas são as de forma trian-
gular, trapezoidal, gaussiana e sino como exibidas na Figura 2.18.
O valor da pertinência é obtido pelo mapeamento x-y da função de pertinência, ou
seja, o eixo x corresponde ao universo de entrada do sistema e o eixo y, indica o grau de
correspondência com o conjunto nebuloso, que será utilizado nos próximos estágios do
controlador. Um exemplo disso pode ser visto na Figura 2.19.
Estágio de inferência
Neste estágio, as entradas são analisadas para gerar o conjunto nebuloso de saída com
seu respectivo grau de compatibilidade. Na literatura existem dois modelos de controlador
que são muito utilizados: o proposto por Mamdani [Mamdani 1974] e o proposto por
Takagi e Sugeno [Takagi & Sugeno 1985].
No modelo de Mamdani, de posse dos dados (o µ(.) de cada regra ativada), o sistema
de inferência determina o grau de compatibilidade da premissa das regras contidas na base
de regras. Neste caso o grau de compatibilidade da regra é calculado usando a t-norma
descrita por Zadeh [Zadeh 1965], ou seja, é utilizado o min no caso de um “e” entre as
cláusulas da premissa.
Após isso, determinam-se quais regras foram ativadas (através da base de regras) e
aplica-se, à função de pertinência de saída, o grau obtido nas premissas, restando unir
todas as conclusões (os conjuntos nebulosos de saída ativados e seus respectivos graus de
compatibilidade) em um único conjunto nebuloso de saída (CS). Neste cálculo utiliza-se
a t-conorma também de Zadeh (o max para o “ou”) entre os valores de cada regra.
Esse conjunto de saída (CS) representa todas as ações que são aceitáveis para o con-
junto de entrada, cada uma com seu nível de compatibilidade, necessitando-se gerar uma
ação de controle geral para a saída (um valor numérico único), que é realizado pela fase
de desfuzzyficação.
Figura 2.18: Principais funções de pertinência.

[Pagliosa 2003]
Figura 2.19: Exemplo de obtenção do grau de pertinência.
Já o modelo de Takagi e Sugeno (conhecido como modelo Sugeno ou modelo Takagi-

Sugeno) utiliza-se do método de interpolação, onde cada regra está associada uma função
estritamente monotônica para gerar a sua conclusão. Essa função é uma combinação
linear das entradas onde cada parâmetro é uma constante.
Com isso, cada regra obtém uma resposta definida para o conjunto de entradas, res-
tando apenas gerar a interpolação que nada mais é do que uma media aritmética ponde-
rada, onde os pesos são os próprios graus de compatibilidade das entradas em cada regra
[Sandri & Correa 1999]. As Figuras 2.20 e 2.21 ilustram esses dois tipos de controladores.
Figura 2.20: Inferência através de Mamdani.

Figura 2.21: Inferência através de Takagi e Sugeno.

Estágio de Desfuzzyfi cação

O estágio de desfuzzyfi cação existe apenas em controladores como o proposto por
Mamdani. Ele é utilizado para gerar um valor numérico único, a partir de todos os possí-
veis valores contidos no conjunto nebuloso, obtido através do estágio de inferência, para
gerar a ação de controle.
Para isso, os métodos mais utilizados e que obtém bons resultados são descritos a
seguir [Passino & Yurkovich 1998] e [Klir & Yuan 1995]:
• Centro de área: Também conhecida erroneamente como centróide, essa técnica

calcula o centro da área do conjunto CS gerado no estágio de inferência e determina
sua projeção sobre o eixo x, que é o valor de saída de controle. Uma desvantagem
deste método é a necessidade do cálculo da área do conjunto de saída, pois isso é
uma tarefa computacional relativamente pesada e nem todo hardware é capaz de
realizá-la.
• Critério dos máximos: Neste método é realizada a procura do valor máximo do con-
junto CS (maior grau de compatibilidade das regras que formaram esse conjunto).
A sua posição projetada sobre o eixo x será a saída do estágio de desfuzzyficação.
Mesmo possuindo uma baixa complexidade computacional, esse método tem o in-
conveniente de necessitar que exista apenas um máximo, devendo ser adotado outra
técnica caso ocorra a existência de mais de um máximo.
• Média dos máximos: Esse método realiza a média aritmética de todos os valores
máximos do conjunto CS e é utilizado em substituição ao critério dos máximos
quando há mais de um máximo na função. Esse método é bem mais simples de se
utilizar, necessitando apenas que o dispositivo em que está embarcado o controlador
realize o cálculo dos pontos máximos do conjunto gerado pelo estágio de inferência.
Além destes métodos, ainda existem outros na literatura que também podem ser utili-
zados no estágio de desfuzzyficação [Jantzen 1998]:
• Centro de área para singletons: Este método visa diminuir a complexidade do cál-
culo de área do método centro de área, onde cada regra de saída possui não uma
função de pertinência comum (triangular, gaussiana ou outra) e sim uma função
singleton (uma função pulso com altura determinada pelo grau de compatibilidade).
Dessa forma o cálculo do centro vai se restringir a uma soma ponderada pelos pró-
prios graus de compatibilidade de cada regra.
• Bissetor de área: Nesse método o valor de saída do estágio de desfuzzyficação é a
posição exata que divide o conjunto CS em duas áreas iguais. Da mesma forma que
o cálculo do centro de área, esta técnica possui uma grande complexidade compu-
tacional.
• Primeiro e último dos máximos: É um método alternativo ao critério dos máxi-
mos, pois neste é escolhido o primeiro (ou o último) valor máximo encontrado na
varredura do conjunto CS feita da esquerda pra a direita ou vice-versa. Possui a
vantagem de ser muito simples do ponto de vista computacional.
A Figura 2.22 exemplifica o resultado obtido por alguns destes métodos sobre um
conjunto CS de exemplo.
Destes métodos descritos, os que utilizam o cálculo de área são mais indicados para
controles mais suaves, pois a variação da área nunca é brusca, o que já não ocorre com os
outros métodos, pois o valor máximo pode mudar de uma função de pertinência de uma
2.3. LABVIEW 33
Figura 2.22: Métodos de desfuzzyficação.

regra para outra, afetando bruscamente o valor de saída do controlador, o que pode acabar
por danificar os equipamentos em que estes controladores estão atuando.
2.3 LabVIEW
O LabVIEW (acrônimo para Laboratory Virtual Instrument Engineering Workbench)
é um ambiente de programação gráfica, desenvolvido pela National Instruments, que uti-
liza ícones em vez de linhas de texto para criar aplicações. Ele utiliza uma forma de
programação totalmente gráfica e intuitiva, utilizando fluxograma de dados (dataflow),
acomodando também códigos em linguagem C ou MATLAB, bem como várias aplica-
ções em ActiveX e DLLs (Dynamic Link Libraries) [Kehtarnavaz & Kim 2005].
No LabVIEW, o usuário utiliza-se de um conjunto de blocos pré-prontos para realizar
a programação. Estes blocos são representados apenas pelos seus ícones e aparecem numa
janela chamada de diagrama de blocos. Existe também outra janela, o painel frontal, que
contém a interface do programa criado, por onde o usuário pode interagir com a aplicação.
A Figura 2.23 ilustra a tela da interface e a Figura 2.24 exibe a tela de programação
onde são utilizados os blocos de função.
A linguagem de programação do LabVIEW é chamada de linguagem G e os programas
são denominados instrumentos virtuais (VI-Virtual Instruments). Os blocos de função
também são VIs porque cada programa pode ser utilizado como sub-programa (sub-VI)
de outro ou simplesmente pode ser executado. Dessa forma o sub-VI é tratado como uma
sub-rotina de programas baseados em texto. A utilização de um VI por outro pode ser
realizado através da construção do painel de conectores (Figura 2.25), onde é realizado o
mapeamento de entradas e saídas do VI. Sob ele fica o painel do ícone, onde o usuário
pode desenhar o ícone para a sua aplicação e que será exibido quando o programa for
utilizado como sub-VI.
O LabVIEW conta com diversos blocos de função padrões, além daqueles que o usuá-
rio pode criar, para serem utilizados tanto na tela de diagrama de blocos, quanto no painel
Figura 2.23: Front Painel.
Figura 2.24: Block Diagram.
frontal. A paleta de controles fornece todos os blocos padrões do LabVIEW referentes

à utilização da interface gráfica (gráficos, botões, chaves, indicadores, etc.) e a paleta
de funções fornece os blocos para a programação (blocos aritméticos, lógica booleana,
blocos de comunicação, tratamento de arquivos, vetores, matrizes, etc.). As Figuras 2.26
e 2.27 exibem estes dois painéis, que são divididos em grupos (controles, indicadores,
aritméticos, arrays, etc.).
Para gerar a programação, o usuário interliga cada bloco de função através de linhas
(Wire Data Path), o que define o fluxo dos dados dentro do VI. A execução do VI (ou
sub-VI) só se inicia quando todas as suas entradas estão disponíveis e os resultados do
processamento ficam disponíveis na saída assim que o programa tenha terminado. Assim,
2.3. LABVIEW 35
Figura 2.25: Tela de conectores e ícone do programa.
Figura 2.26: Paleta de controles.
a ordem de execução do programa se dá pelo fl uxo dos dados e não pela forma que são
dispostos os blocos de função, o que permite a criação de processos paralelos, pois aqueles
sub-VIs que não tem dependência de dados são executados em paralelo. A Figura 2.28
mostra um exemplo de programa, com uma sub-VI, saídas de dados e sua interface gráfica.
Desta forma, a criação da interface gráfi ca é intuitiva sem a necessidade de que o
usuário programe linhas de código. Além disso, muitos dos blocos de função são poli-
mórficos, ou seja, eles se adaptam ao tipo de dado que é apresentado às suas entradas,
facilitando a programação, pois o programador não precisa se preocupar em realizar di-
versas conversões de tipos de dados, como é o caso de outras linguagens de programação.
As linhas que interligam os blocos possuem cores específi cas para determinar que tipo
de dado está fl uindo por ele, além de espessuras diferentes para as dimensões utilizadas
nos dados (Figura 2.29).
Figura 2.27: Paleta das funções.
Figura 2.28: Exemplo de programa de temperatura.
Figura 2.29: Tipos de linhas.

[Instruments & Shiralkar 2007]
Capítulo 3
Fuzzy aplicado ao ambiente Foundation

Fieldbus
Este capítulo aborda os aspectos práticos relativos aos blocos funcionais e as suas li-
gações na implementação de um controlador Fuzzy no ambiente da rede industrial Foun-
dation Fieldbus.
3.1 Introdução à aplicação Fuzzy-FF

Como já foi mencionado na Seção 2.2, a lógica Fuzzy trás diversos benefícios aos
sistemas computacionais, permitindo a eles, interpretarem e poderem se utilizar de variá-
veis linguísticas humanas no seu processamento. Hoje em dia a lógica Fuzzy já é muito
utilizada em diversos sistemas como monitoramento de saúde, sistema de controle de
foco em câmeras digitais, controladores de servo motores, braços robóticos entre mui-
tas outras aplicações [Chen & Pham 2001]. Em aplicações industriais, os controladores
Fuzzy normalmente são implementados dentro de dispositivos com maior poder de pro-
cessamento, como são os casos dos CLPs. Mas como os instrumentos inteligentes estão
ganhando cada vez mais destaque no ambiente industrial principalmente pela sua capaci-
dade de processamento, levando a uma descentralização dos sistemas de controle e uma
melhoria nestes sistemas e nos de monitoração, eles deverão ganhar cada vez mais a aten-
ção para as possíveis aplicações de sistemas de controles mais avançados, como é o caso
dos controladores Fuzzy. Até o presente momento, ainda não existem blocos funcionais
Fuzzy para o protocolo Foundation Fieldbus, apesar de um estudo ter sido realizado com
o intuito de desenvolver tal aplicação [Francisco et al. 2008], devido principalmente as
limitações de hardware que ainda existem nos instrumentos de campo, sendo este tipo
de controlador adotado em sistemas mais robustos como os CLPs. Apesar destes instru-
mentos não poderem realizar todas as funcionalidades que um CLP é capaz, eles possuem
uma capacidade de processamento que pode ser aproveitada quando utilizadas estruturas
de controle mais complexas e este foi o motivo para o inicio do estudo e desenvolvimento
de uma arquitetura que pudesse realizar as funções de um controlador Fuzzy dentro de
uma rede Foundation Fieldbus, apenas utilizando apenas blocos funcionais padrões deste
protocolo, o que permitiria a sua replicação em redes de diversos fabricantes. A primeira
versão (encontrada em [Filho et al. 2009]) foi desenvolvida como um teste inicial para
38 CAPÍTULO 3. FUZZY APLICADO AO AMBIENTE FOUNDATION FIELDBUS
aplicar os conceitos da lógica Fuzzy e verificar que blocos poderiam ser utilizados na con-
figuração de um controlador Fuzzy. Esta configuração é abordada neste capítulo. A rede
utilizada é a rede Foundation Fieldbus do fabricante SMAR. Essa rede é configurada pelo
software chamado SYSCON (Figura 3.1).
Figura 3.1: Tela do SYSCON: Ao centro a tela principal, À esquerda a tela de configura-
ção dos blocos, à direita a tela de configuração das lógicas.
Nele são configurados os blocos funcionais (a janela da esquerda mostra a árvore de

instrumentos e seus respectivos blocos funcionais e abaixo dela, na janela suspensa, a
tela de configuração do bloco A0, que é um bloco de configuração de saída analógica
do instrumento de conversão Foundation Fieldbus para loop de corrente, exibindo alguns
dos parâmetros configuráveis) e a lógica de controle (a janela da direita exibe a árvore de
lógicas referente à célula "Controlador"e a janela suspensa abaixo que exibe a lógica de
controle referente ao estágio de Fuzzyficação).
3.2 Controlador Fuzzy-FF

O controlador Fuzzy-FF, da mesma forma que um controlador Fuzzy normal, é for-
mado pelos três estágios apresentados na seção 2.2: estágio de fuzzyficação, estágio de
inferência e estágio de desfuzzyficação. Como existe a limitação da utilização de blo-
cos funcionais padrões do protocolo Foundation Fieldbus, a primeira tarefa realizada foi
um levantamento dos blocos padrões que poderiam ser úteis para cada estágio. Cada es-
tágio tem as suas próprias características e necessidades e os blocos utilizados atendem
exatamente à elas.
3.3. ESTÁGIO DE FUZZYFICAÇÃO-FF 39
Para exibir corretamente a arquitetura, o seguinte exemplo é utilizado: Um controlador

com duas entradas e uma saída. Na entrada 1 são utilizadas 3 funções de pertinência (A0,
A1 e A2), na entrada 2 são utilizadas 2 funções de pertinência (B0 e B1) e na saída são
utilizadas 3 funções de pertinência (C0, C1 e C2). A base de regras e a respectiva Tabela
3.1 são apresentadas abaixo.
• Se A0 e B0 então C0
A0 A1 A2
B0 C0 C1 C0
B1 C1 C2 C2
Tabela 3.1: Tabela relativa a base de regras do exemplo.
3.3 Estágio de Fuzzyficação-FF

No estágio de Fuzzyficação as variáveis do processo são convertidas para variáveis
linguísticas para serem utilizadas no processo de inferência. Além disso, são calculados
os graus de pertinência de cada função relativos ao valor da entrada. Essa função nada
mais é do que mapear uma função x-y: entra-se com o valor de x (referente ao dado no
universo dos conjuntos) e o bloco retorna o valor de y (referente ao grau de compatibi-
lidade com um determinado conjunto). Um bloco funcional que realiza essa tarefa é o
bloco caracterizador de sinal (CHAR) (Figura 3.2). Este bloco serve para gerar funções
para utilização de outros blocos funcionais ou lógicas de controle. Para isso, este bloco
realiza a interpolação de até 20 pontos (formados pelos parâmetros x e y, totalizando 40
parâmetros), que são configurados internamente ao bloco pelo usuário. Caso a função seja
simples ou não necessite de todos os 20 pontos para ser definida, os pontos restantes são
inutilizados aplicando-se o valor +Inf a cada um deles (tanto para o x quanto para o y), o
que informa para o bloco que aqueles pontos não devem ser considerados na interpolação
[Martins 2008].
No caso de uma função triangular ou trapezoidal, seriam necessários apenas 3 ou 4
pontos, respectivamente, para representar corretamente as funções. Já no caso de uma
função sino (Bell-shape), seriam necessários os 20 pontos para que a interpolação fosse a
mais próxima possível da função real.
Como cada variável linguística tem uma função de pertinência associada, é necessá-
rio que sejam alocados a mesma quantidade de blocos funcionais CHAR. Com isso, no
exemplo dado seriam necessário 5 blocos caracterizadores de sinais (3 para a entrada 1 e
2 para a entrada 2). Não serão utilizados blocos CHAR para a saída devido à utilização
Figura 3.2: Bloco Caracterizador de sinal (CHAR).

[Martins 2008]
de funções singletons nas saídas, o que é mais detalhado na seção 3.5. Assim é obtido o
grau de pertinência de cada função para ser utilizado no próximo estágio. A Figura 3.3
ilustra a configuração deste estágio, mostrando as duas entradas (blocos Analog Inputs-AI
dos instrumentos IF-302-1 e IF-302-2, nomeados respectivamente como Input1 e Input2
ligados aos blocos CHAR respectivos).
3.4 Estágio de Inferência-FF

Neste estágio de Inferência, as regras da base de regras são avaliadas e os cálculos
sobre cada função de pertinência são realizados. No caso do controlador proposto por
Mamdani, neste estágio são utilizadas as t-normas para intersecções (E) e t-conormas
para as uniões (OU). A t-norma e a t-conorma definidas por Zadeh realizam os cálcu-
los do valor mínimo e valor máximo entre dois argumentos respectivamente. Então, para
cada regra que possui o conectivo E, é necessário calcular-se o valor mínimo entre os argu-
mentos e para regras que levam ao mesmo conjunto de saída, deve-se utilizar o conectivo
OU, necessitando-se calcular o valor máximo entre elas. Para estas funções, utiliza-se o
bloco funcional ISEL-Input Selector (Figura 3.4). Este bloco é um selecionador de en-
trada, possuindo 5 entradas (IN_1, IN_2, IN_3, IN_4 e OP_SELECT) e duas saída (OUT
e SELECTED).
Ele se assemelha a um multiplexador, possuindo uma entrada discreta (OP_SELECT)
para selecionar a entrada (do conjunto das 4 entradas IN) que será repassada para a saída
OUT. O que o diferencia de um simples multiplexador é a existência de um algoritmo
interno ao bloco para escolha automática das entradas. Esse algoritmo, quando configu-
rado, pode escolher as entradas baseando-se em algumas características delas: Primeira
entrada com o estado good, entrada com o valor próximo ao valor médio das entradas,
entrada com o maior valor dentre todas as entradas, entrada com o menor valor dentre
todas as entradas e a o valor médio de todas as entradas [Martins 2008]. A segunda saída
3.4. ESTÁGIO DE INFERÊNCIA-FF 41
Figura 3.3: Estágio de fuzzyfi cação.
Figura 3.4: Bloco selecionador de entrada (ISEL).

[Martins 2008]
(SELECTED) informa qual das entradas foi escolhida, seja pela forma manual, seja pelo
algoritmo de escolha.
No caso da avaliação dos argumentos de cada regra, são utilizados os blocos ISEL
confi gurados com a opção de valor mínimo das entradas. A quantidade de blocos ISEL
para esta função vai depender da quantidade de entradas. Até 4 entradas, pode-se utilizar
apenas 1 bloco ISEL para cada regra, mas passando de 4 entradas, serão necessários mais
blocos ISEL arranjados em cascata para gerar a operação do valor mínimo corretamente.
Seguindo o exemplo dado, como existem 6 regras, são necessários 6 blocos ISEL na
confi guração valor mínimo, um para cada regra, onde em cada bloco ISEL são utilizadas
duas entradas (uma para a entrada 1 e a outra para a entrada 2).
Para a saída, em teoria, são necessários uma quantidade de blocos exatamente igual
a quantidade de saídas, pois sobre cada função de pertinência de saída é avaliado o valor
máximo das regras destinados a ela. Mas, como cada bloco ISEL possui apenas 4 entra-
das, a quantidade máxima de regras que podem ser ligadas a um bloco ISEL são 4, sendo
necessário acrescentar mais blocos ISEL em cascata caso ultrapasse esse valor.
Para a avaliação das regras que levam ao mesmo conjunto de saída do exemplo dado,
são necessários apenas 3 blocos ISEL confi gurados com a opção de escolha do valor
máximo de entrada, onde cada um utiliza apenas duas de suas entradas, pois como pode
ser visto na Tabela 3.1, existem duas regras para cada função de pertinência de saída. As
Figuras 3.5 e 3.6 ilustram a formação deste estágio.
Figura 3.5: Estágio de inferência (cálculo do valor mínimo).

3.5. ESTAGIO DE DESFUZZYFICAÇÃO-FF 43
Figura 3.6: Estágio de inferência (cálculo do valor máximo).
Ao final desta etapa, são obtidos os graus de compatibilidade das funções de pertinên-
cia de saída do controlador que são repassados para o estágio de desfuzzyfi cação.
3.5 Estagio de Desfuzzyficação-FF

No estágio de desfuzzyficação-FF, cada função de pertinência de saída ativada é pon-
derada pelo seu grau de compatibilidade calculado no estágio de inferência. Depois as
funções de pertinência são unidas formando um conjunto único de saída. Sobre este con-
junto são aplicados os métodos vistos na seção (2.2.1) como centro de área, média dos
máximos e assim por diante, para calcular o valor numérico de saída para ser utilizado no
controle. Alguns destes métodos exigem um esforço computacional muito grande e nem
sempre o hardware onde o controlador é aplicado é capaz de realizar tais operações. No
caso dos instrumentos inteligentes não é diferente. Eles não possuem blocos funcionais
capazes de calcular o centro de área do conjunto de saída, impedindo de utilizar este mé-
todo, mas três métodos são passíveis de serem utilizados neste ambiente: Primeiro dos
máximos para singletons, último dos máximos para singletons e a técnica de centro de
área para singletons.
Os dois primeiros métodos são simples de explicar, pois dada a explicação de como
o blocos ISEL funciona, fi ca óbvio a sua utilização para encontrar o primeiro e último
dos máximos. A diferença está que para este caso são necessários dois blocos ISEL em
cascata (Figura 3.7 e Figura 3.8).
Figura 3.7: Desfuzzyfi cação primeiro máximos (SOM).
Figura 3.8: Desfuzzyfi cação último dos máximos (LOM).

3.5. ESTAGIO DE DESFUZZYFICAÇÃO-FF 45
No caso do primeiro dos máximos, o primeiro bloco ISEL é utilizado para descobrir
qual dos conjuntos de saída (na ordem de suas ligações que devem ser efetuadas da es-
querda para a direita do conjunto de saída) possui o maior valor. No caso do último dos
máximos basta inverter a ordem de ligação dos blocos ISEL (da direita para a esquerda).
Quando encontrado o maior valor, o valor correspondente será colocado na saída OUT e
o número da entrada escolhida será colocado na saída SELECTED.
Esta segunda saída é colocada como entrada do OP_SELECT do segundo bloco ISEL
e nas suas entradas IN são colocados os valores dos singletons de saída (a posição x da
função singleton). Dessa forma, a saída do segundo bloco ISEL será exatamente a posição
da função de pertinência de saída com maior grau de compatibilidade.
Já para o caso do centro de área, como foi explicado na seção (2.2.1), quando aplicado
a singletons este método se resume a um cálculo de média ponderada. Para realizar este
cálculo, utiliza-se o bloco ARTH-Arithmetic (Figura 3.9).
Figura 3.9: Bloco Aritmético.

[Martins 2008]
Este bloco foi desenvolvido para realizar cálculos matemáticos sobre sinais provindo
de sensores, possuindo 5 entradas, onde as duas primeiras são utilizadas para uma fun-
ção de extensão de range e as outras três para combinações com o valor da PV (que é a
saída da função de extensão de range). Cada uma das outras três saída possui seu próprio
ganho e bias associado, podendo efetuar correções nos dados recebidos pelos sensores
e a saída do bloco também possui um ganho e um bias para correções posteriores dos
cálculos. A escolha da função a ser utilizada no bloco aritmético se dá através do pa-
râmetro ARTH_TYPE[Martins 2008]. As funções executadas pelo bloco no processo de
desfuzzyficação são exibidas na Tabela 3.2 onde T1, T2 e T3 são os resultados das opera-
ções das entradas IN_1, IN_2 e IN_3 somadas aos respectivos bias e multiplicadas pelos
respectivos ganhos.
Para realizar a soma ponderada, primeiramente cada um dos graus de pertinência ob-
tidos no estágio de inferência é multiplicado pela posição da função de pertinência res-
pectiva utilizando-se para isso as entradas IN_1, IN_2 e IN_3. No ganho de cada uma
Função Definição
Divisão tradicional múl-
OUT = PV * f, onde f = (T1/T2) + T3 e que é limitado pelo
tipla
COMP_HI e COMP_LO.
Soma tradicional OUT = PV + T1 + T2 + T3.
Tabela 3.2: Funções do bloco aritmético.
destas entradas é colocada a posição do singleton da função de pertinência. Como função

do bloco ARTH é utilizada a soma tradicional. Da mesma forma que acontece com o
bloco ISEL, o bloco ARTH possui limite de entradas, podendo trabalhar com três entra-
das, sendo assim, se a quantidade de funções de pertinência de saída for maior que três,
será necessário a utilização de blocos ARTH em cascata (utilizando a entrada IN que não
é utilizada por não possuir um ganho próprio).
A saída desse somatório será o numerador da soma ponderada. Para calcular o deno-
minador realiza-se o mesmo processo, alocando a mesma quantidade de blocos funcionais
ARTH com a mesma função e alterando apenas os ganhos que passam a ser unitários. De
posse do numerador e denominador da soma ponderada, basta realizar a divisão utilizando
mais um bloco ARTH com a função divisão múltipla tradicional. Para que a divisão fun-
cione é necessário utilizar as entradas T1 e T2 e colocar na entrada IN o valor constante
1. A Figura 3.10 exibe a configuração final deste método. Com isso a saída deste último
bloco conterá a média ponderada das funções de pertinências singletons de saída pelos
seus respectivos graus de compatibilidade.
Figura 3.10: Desfuzzyficação pelo método do centro de área.

Capítulo 4
Interface de configuração Fuzzy-FF em

LabVIEW
Este capítulo se destina a explicar o funcionamento do programa desenvolvido no

ambiente LabVIEW que permite a configuração de controladores Fuzzy em uma rede
industrial Foundation Fieldbus.
Na primeira versão do trabalho ([Filho et al. 2009]) foi criado um programa em MA-
TLAB que gerava os 20 pontos de uma função de pertinência do tipo sino (bell-shape) e
através da comunicação OPC do MATLAB, podia-se enviar estes dados para um bloco
CHAR.
Esta interface de configuração foi desenvolvida partindo desta ideia, mas acrescen-
tando um maior automatismo ao processo de criar as funções de pertinência (todas as que
fossem utilizadas no controlador), podendo visualiza-las enquanto criadas, ajustá-las e
com os pontos gerados para cada uma, configurar todos os seus respectivos blocos CHAR
de forma automática. Além disso foram adicionadas mais algumas funcionalidades para
facilitar o processo de criação dos controladores no ambiente FF.
4.1 Interface principal

O programa é formado por uma VI principal (Figura 4.1) que possui outras VIs para
realizar determinadas funções.
A tela principal é dividida em abas que seguem um fluxo de execução (do tipo next-
next-finish). Em cada aba é executada uma tarefa específica, todas sendo tarefas de sim-
ples. As tarefas com níveis de complexidade mais altas são executadas pelas sub-VIs.
A modularização do programa foi realizada de forma a tornar mais simples a questão da
facilidade de implementação e modificação. Na necessidade de se expandir o programa,
fica fácil reorganizar os novos módulos, sem que estes afetem os antigos.
Na primeira aba do programa (exibida na Figura 4.1) o usuário entra com a primeira
informação, utilizada na construção do controlador Fuzzy-FF, que é a quantidade de entra-
das. Apesar de aparecer a opção da quantidade de saídas, a funcionalidade para trabalhar
com uma maior quantidade de saídas ainda não foi desenvolvida. A quantidade de en-
tradas ainda é limitada devido ao alto grau de complexidade que implicaria a utilização
de uma quantidade maior (maior quantidade de blocos funcionais dentro da rede), desta
48 CAPÍTULO 4. INTERFACE DE CONFIGURAÇÃO FUZZY-FF EM LABVIEW
Figura 4.1: Interface do programa.
forma, por enquanto, o software se restringe à 4 entradas, o que já é uma quantidade

razoável para a maioria dos controladores.
A segunda aba do programa principal (Figura 4.2) é utilizada para nomear as entradas
do controlador.
Figura 4.2: Segunda aba do programa principal.

4.1. INTERFACE PRINCIPAL 49
Já terceira (Figura 4.3) é utilizada para definir as funções de pertinência de cada en-
trada (e da saída). Depois de escolhida a entrada pelo usuário no menu a esquerda, o
usuário deve clicar no botão “Gerar Memberships” que abre uma sub-VI para gerar as
funções a seres utilizadas no bloco CHAR.
Figura 4.3: Terceira aba do programa principal.
O usuário repete estas operações para cada entrada até que todas estejam configuradas.
Já a configuração da saída é um pouco diferente. Devido à utilização de funções de
pertinência do tipo singleton, não é necessário a geração de funções de pertinência para a
saída, por isso, ao clicar no botão “Gerar Memberships” para a função de saída, o usuário
é levado a uma tela simples onde ele pode escolher apenas o nome de cada função (que
serão utilizados em outra fase do programa).
Na quarta aba do programa principal (Figura 4.4) o usuário pode defi nir as regras
utilizadas no seu controlador Fuzzy, bem como um método de Desfuzzyfi cação. Ao clicar
no botão “Confi gurar Regras & Contar Blocos” o usuário é levado para outra tela, um
outro sub-VI, que utiliza os nomes das entradas e saída e das funções de pertinência,
defi nidos nas abas anteriores do programa principal, para permitir que o usuário crie sua
tabela de regras, sendo informado de quantos blocos funcionais serão necessários para
montar a estrutura do controlador.
Na última aba do programa principal (Figura 4.5) o usuário pode enviar os dados gera-
dos para a rede. O programa se comunica via OPC com a DFI e configura os parâmetros
(os 20 pontos) de cada bloco funcional (bloco CHAR) com os valores calculados pelo
sub-VI que gera as funções de pertinência.
Figura 4.4: Quarta aba do programa principal.
Figura 4.5: Quinta aba do programa principal.
4.2 Gerador Memberships

O botão “Gerar Memberships” na terceira aba do programa principal abre a tela (Fi-
gura 4.6). Esta tela pertence a uma sub-VI destinada apenas a gerar funções de pertinên-
cia.
4.2. GERADOR MEMBERSHIPS 51
Figura 4.6: Tela do programa gerador de Memberships (funções de pertinência).
Da mesma forma que o programa principal, este também possui abas e segue a ideia
do fluxo de execução. Na primeira aba existe um menu à esquerda onde o usuário define
a quantidade de funções de pertinência que serão utilizadas para a entrada escolhida,
bem como o limite mínimo e máximo desta entrada. Ao clicar em novo, inicia-se o
processo de definição dos parâmetros de cada função. O “nome da função” deve ser
preenchido de forma correta, pois ele será utilizado em outra aba do programa principal,
da mesma forma que deve ser preenchido corretamente o parâmetro “nome do bloco”, que
se refere ao nome do bloco funcional CHAR onde a função de pertinência será alocada.
O preenchimento de forma errada do nome do bloco causa um erro no envio para a rede
(quando há falha de comunicação ou erro nos parâmetros de envio, o programa tenta
enviar por 10 vezes consecutivas e não conseguindo, passa para o próximo parâmetro).
O parâmetro “tipo de função” se refere ao tipo de função (Figura 2.18) que será utili-
zada na criação da função de pertinência.
Após a correta parametrização da função, deve-se clicar no botão “Param. Ok”, o
que avisa ao programa o término da defi nição de uma das funções de pertinência. Ao
término da confi guração de todas as funções, a tela ao centro as exibe grafi camente (Figura
4.7). Acima desta tela central (como pode ser visto na Figura 4.7) existe um botão de
troca de funções onde o usuário pode escolher ver as funções originais ou as geradas
pela interpolação. Na segunda aba deste sub-VI, o usuário pode realizar correções nos
parâmetros, nomes das funções ou nomes dos blocos caso haja algum erro nos parâmetros.
Ao clicar no botão “Corrigir”, o sub-VI aguarda a escolha de uma função para corrigir.
Escolhendo uma das funções o usuário pode visualizar seus dados clicando sobre o botão
“Original”. Depois basta alterar os parâmetros que desejar e clicar em “Modificar” para
realizar a alteração.
Figura 4.7: Segunda aba do programa gerador de funções(à esquerda) e funções definidas
(gráfi co central).
Na terceira aba deste sub-VI (Figura 4.8), existe apenas um botão que inicia o processo
de geração das funções que serão utilizadas na rede FF.
Como cada função de pertinência será alocada num bloco funcional do tipo CHAR
e, como já foi explicado na seção 3.3, este bloco determina a função que ele trabalha
utilizando a interpolação de 20 pontos, o sub-VI gera os 20 pontos para cada tipo de
função. Para as funções triangular e trapezoidal é relativamente simples defini-las, já que
são necessários apenas 3 ou 4 pontos respectivamente, mas no caso da função Bell-Shape
esta tarefa se torna um pouco mais complexa. Como esta função possui várias curvas, faz-
se necessário alocar os 20 pontos de forma a conseguir a melhor aproximação da função
real. Para realizar tal tarefa, foi utilizada uma versão aprimorada do algoritmo genético
utilizado no trabalho [Filho et al. 2009]. Este algoritmo faz uma busca no espaço do
conjunto universo, buscando os pontos que minimizam uma função de custo que compara
a função interpolada à função original.
Esse algoritmo genético foi implementado em MATLAB e devido a facilidade de
incorporação de códigos de outras linguagens ao LabVIEW, o código foi importado e
alocado em uma outra sub-VI. Depois de clicar no botão, deve-se aguarda o término
do processamento do algoritmo (exibido grafi camente por uma barra horizontal), onde o
4.3. CONFIGURADOR DE REGRAS 53
Figura 4.8: Terceira aba do programa gerador de funções.
resultado pode ser visualizado na tela central ao alternar o botão superior a ela. Dessa
forma, pode-se fazer um comparativo entre as funções reais e as interpoladas, a fim de
procurar grande falhas ocasionadas por uma não convergência do algoritmo genético.
Caso seja constatado algum problema nas funções (a aproximação não tenha chegado a
um bom resultado), pode-se re-gerar os pontos utilizando a quarta e última aba (Figura
4.9).
Nesta última aba, o usuário pode re-calcular as funções do genético utilizando o bo-
tão “Re-gerar pontos”, podendo escolher no menu superior o número da função a ser
re-gerada, dando início ao processo pelo clique do botão “Ponto Escolhido”. Para fina-
lizar este sub-VI é necessário clicar no botão “Finalizar Programa”, o que faz voltar ao
programa principal.
4.3 Confi gurador de regras

O botão “Configurar Regras & Contar Blocos” abre o sub-VI (Figura 4.10) onde o
usuário pode criar sua base de regras, além de determinar qual será o método de des-
fuzzyfi cação, que determinará a quantidade de blocos funcionais que serão utilizados na
estrutura do controlador. O programa não gera as ligações dos blocos referentes às regras,
pois não existe a possibilidade de criar confi gurações de lógicas de blocos funcionais sem
utilizar o programa do fabricante, neste caso o SYSCON. Ainda é necessário que o usuá-
Figura 4.9: Terceira e quarta aba do programa gerador de funções.
rio faça isso manualmente dentro do SYSCON, mas ele permite que usuário saiba quantos
blocos serão utilizados na estrutura, sendo necessário para isso a montagem da tabela de
regras.
Figura 4.10: Tela do programa confi gurador de regras.
Na tela do configurador de regras existem 5 menus superiores (referentes a todas as

entradas possíveis e a saída) onde deve-se escolher as funções de pertinência que irão fazer
4.3. CONFIGURADOR DE REGRAS 55
parte da regra. Para adicionar uma nova regra, utiliza-se o botão “Adicionar”, fazendo
com que a regra seja escrita na lista abaixo dos botões. Caso o seja necessário modificar
alguma regra criada, basta clicar sobre ela na lista, atribuir os novos valores nos menus
superiores e clicar no botão “Modificar”, podendo também apagar uma regra, clicando-
se em “Apagar”. Ao lado direito existem as caixas de texto que informam a quantidade
de blocos utilizados em cada configuração e abaixo delas, o menu de escolha do tipo de
desfuzzyficação e o botão “Contar”.
Ao finalizar o preenchimento das regras, o usuário deve clicar no botão “Contar” para
que o programa calcule a quantidade de blocos para o tipo de desfuzzyficação escolhida
e exiba nas caixas de texto. Para finalizar este sub-VI, deve-se clicar no botão “Finalizar
Programa”, o que faz retornar ao programa principal.
Capítulo 5
Testes e Resultados
Este capítulo se destina a mostrar os testes utilizando controlador Fuzzy embarcado

em uma rede industrial Foundation Fieldbus, de forma a validar o trabalho.
5.1 Sistema de tanques
Para a implementação do controlador, pensou-se no problema prático do controle de

nível de um de tanque, onde para isso seria utilizado um controlador Fuzzy do tipo Mam-
dani, integrativo (ou controle Fuzzy-PI).
O tanque faz parte de um sistema de tanques, que pode ser visto na Figura 5.1. Ele
é um kit didático fabricado pela empresa Quanser, sendo formado por dois tanques de
aproximadamente 32 cm de altura (mas sua parte graduada vai até apenas 30 cm), colo-
cados um sobre o outro de forma que a água que entra no primeiro tanque passe para o
segundo através de um orifício na parte de baixo, o mesmo acontecendo com o segundo
tanque, que devolve a água para o reservatório. Esse sistema de tanques é utilizado para
atividades de controle de nível.
Esse sistema de tanques original possui dois sensores de nível, uma bomba e uma
placa para conformação de sinais, mas o que foi utilizado no laboratório foi adaptado para
trabalhar com sensores industriais de nível. Desta forma, seus sensores padrões foram
removidos e substituídos por conectores para mangueiras de conexão. Essas mangueiras
(em azul na foto) são ligadas às entradas dos sensores de pressão, que realizam o cálculo
de nível baseados na pressão de fundo de cada tanque.
A bomba também foi substituída, sendo utilizada uma bomba de pára-brisas de carro
(12 V, 4A). O acionamento da bomba é realizado por um módulo de potência desenvol-
vido no laboratório (caixa de madeira ao fundo), que possui internamente um sistema de
buffer de alta potência, necessário para alimentar a bomba. Esse sistema recebe um sinal
de tensão originário do FI (conversor de Foundation Fieldbus para corrente), que disponi-
biliza um sinal de corrente de 4-20 mA que é convertido por um pequeno circuito acima
do módulo de potência.
58 CAPÍTULO 5. TESTES E RESULTADOS
Figura 5.1: Sistema de tanques utilizado no teste.
5.2 Modelagem do controlador

Ao controlador é fornecido o nível desejado, de onde se calcula o erro pela subtra-
ção do nível desejado pelo nível obtido do tanque real (através da leitura do sensor de
pressão). O erro informa ao controlador o quão longe o nível real está da referência. O
objetivo do controlador é gerar um sinal para o processo de forma a zerar este erro. So-
bre o erro é calculado a variação, o que informa ao controlador a velocidade com que o
erro está aumentando ou diminuindo, o que permite adotar determinadas estratégias para
aproximações mais suaves do nível desejado (evitando overshoots e undershoots).
De posse do erro e da variação dele, o controlador calcula o incremento (ou decre-
mento no caso de um incremento negativo) de tensão necessário para zerar o erro. Este
incremento é armazenado por um sistema incrementador (que pode ser representado por
um somador com uma memória), que vai somando ou subtraindo os incrementos gerados
pelo controlador. A saída do sistema incrementador é a ação de controle real (a tensão)
que é aplicada à bomba, que bombeia a água para o tanque a partir de um reservatório e
faz variar o nível dele, que é captado pelo sensor de pressão que gera o sinal de volta para
o controlador fechando a malha de controle. Todo este ciclo pode ser visto na Figura 5.2.
Esse tipo de controlador (Fuzzy-PI) é mais adequado para sistemas em que não se
deseja variações bruscas no acionador do sistema. Realizando pequenos incrementos
ou decrementos da tensão, o acionador não sofre avarias por repentinas mudanças de
5.2. MODELAGEM DO CONTROLADOR 59
Figura 5.2: Esquemas de funcionamento de um controlador Fuzzy integrativo.
tensão, como é o caso do controlador Fuzzy tradicional. Outra vantagem é que esse tipo
de controlador tende a zerar completamente o erro, mas a desvantagem é que ele pode
se tornar um pouco lento ou mesmo ter grandes overshoots e/ou undershoots, mas isto
depende muito da sintonia do controlador.
Para iniciar a criação do controlador no ambiente FF primeiramente criou-se um con-
trolador Fuzzy no Simulink do MATLAB. Isso facilitou os testes do controlador, pois o
MATLAB possui uma ferramenta para Fuzzy amigável e com uma interface gráfi ca que
permite analisar regras ativadas, o grau de pertinência da ativação, além da possibilidade
do ajuste das funções de pertinência em tempo real.
Além disso, o Simulink permite a criação do modelo matemático do processo, permi-
tindo a total simulação do sistema de controle, mas neste trabalho ele não chegou a ser
utilizado para este propósito. Para conseguir criar o modelo matemático seriam necessá-
rias informações como constante da bomba, atraso de leitura, zona morta da bomba e dos
sensores entre outros fatores que seriam difíceis de serem obtidos com precisão, caindo
exatamente no problema mencionado na seção 2.2.1. Optou-se apenas por utilizar uma
comunicação via OPC (através de blocos de comunicação OPC do Simulink) com a rede
obtendo o nível do tanque real e enviando o sinal de tensão para a bomba, o que pode ser
visto na Figura 5.3.
Para as duas entrada, o erro e a variação do erro, foram utilizadas 5 funções de perti-
nência e para a saída foram utilizadas 7 funções com o método de desfuzzyfi cação pelo
centro de massa. Todas as funções de pertinências utilizadas são do tipo triangular, sendo
que as funções de saída são funções singletons, ou seja, elas não possuem largura em
teoria, sendo simuladas no MATLAB através de funções triangulares com larguras muito
pequenas de maneira a se assemelhar a função pulso unitário. A Tabela 5.1 ilustra o nome
de cada uma das funções de pertinência utilizas, sua sigla e seus parâmetros (que no caso
da função triangular são três, “a‘”, “b” e “c” como visto na Figura 2.18).
O erro negativo se refere a quando a referência (set-point) está abaixo do nível real e o
erro positivo o caso contrário. Já a variação do erro, quando negativo indica que o nível do
tanque está se aproximando da referência e quando positivo, que ele está se afastando. O
Figura 5.3: Controlador Fuzzy implementado no MATLAB.
Entrada 1 Sigla Parâmetros

(Erro) (a,b,c)
Erro Grande Negativo EGN (-31,-30,-2)
Erro Pequeno Negativo EPN (-4,-2,0)
Erro Zero EZ (-2,0,2)
Erro Pequeno Positivo EPP (0,2,4)
Erro Grande Positivo EGP (4,30,31)
Entrada 2 Sigla Parâmetros
(Variação do Erro) (a,b,c)
Variação Grande Negativa VGN (-9,-8,-1)
Variação Pequena Negativa VPN (-2,-1,0)
Variação Zero VZ (-1,0,1)
Variação Pequena Positiva VPP (0,1,2)
Variação Grande Positiva VGP (1,8,9)
Saída Sigla Parâmetros
(Incremento de Tensão) (a,b,c)
Incremento Grande Negativo IGN (-0.081,-0.08,-0.079)
Incremento Médio Negativo IMN (-0.041,-0.04,-0.039)
Incremento Pequeno Negativo IPN (-0.005,-0.004,-0.003)
Incremento Zero IZ (-0.001,0,0.001)
Incremento Pequeno Positivo IPP (0.001,0.004,0.005)
Incremento Médio Positivo IMP (0.039,0.04,0.041)
Incremento Grande Positivo IGP (0.079,0.08,0.081)
Tabela 5.1: Funções de pertinência utilizadas na aplicação teste.
valor numérico da variação do erro indica a velocidade com que o nível se aproxima ou se
afasta da referência. A escala do erro foi obtida analisando o pior caso nos dois sentidos,
se a referência estiver no máximo e o nível real no mínimo (30 e 0 cm respectivamente)
5.2. MODELAGEM DO CONTROLADOR 61
e vice-versa, fixando a escala de -30 a 30 cm de erro. Já a variação depende muito da

velocidade de amostragem do sistema, pois se ele for muito rápido, a variação medida será
muito pequena, e se ele for muito lento, a variação será muito grande. Foi tomado como
base para amostragem o macro ciclo da rede industrial, que estava confi gurado durante
os teste para o tempo de 1 segundo. Com esse macro ciclo foram realizados alguns teste
para verificar a variação no nível do tanque entre uma leitura e outra, chegando à escala
aproximada de -8 a 8 cm para o pior caso (a máxima variação entre uma leitura e outra).
Como a função de pertinência representa o conjunto Fuzzy, então, por exemplo, um
erro grande negativo abrange toda a área que vai desde um erro de 30 cm até um erro de
2 cm acima da referência. Este espaço de entrada também é dividido em parte com o erro
pequeno negativo, que se inicia a partir de um erro de 4 cm acima da referência até o erro
de 0 cm. A mesma analise pode ser efetuada para todas as outras funções de pertinência.
As Figuras 5.4, 5.5 e 5.6 ilustram graficamente os conjuntos Fuzzy para este controlador.
Uma coisa importante a ser considerada é que no caso das funções de pertinência que
fi cam no limite das escalas, foram adotados valores que ultrapassam a escala (no caso
-31 e 31 cm , -9 e 9 cm) apenas para garantir que no caso de algum ruído gerado nas
medições efetuadas pelo sensor, o valor das entradas ainda estejam dentro das escalas do
controlador.
Figura 5.4: Funções de pertinência para o Erro (entrada 1).
Figura 5.5: Funções de pertinência para a variação do Erro (entrada 2).

Figura 5.6: Funções de pertinência para o incremento de tensão (saída).
Para a geração da base de regras foram utilizadas todas as combinações possíveis das
entradas, sem nenhuma simplificação, rendendo no total 25 regras exibidas na Tabela 5.2.
EGN EPN EZ EPP EGP

VGN IMP IGP IPN IGN IPN
VPN IPP IPP IZ IPN IZ
VZ IMN IPN IZ IPP IMP
VPP IMN IPN IZ IPP IGP
VGP IGN IMN IPP IMP IGP
Tabela 5.2: Regras do controlador Fuzzy-FF.
Os parâmetros das funções pertinência mostrados na Tabela 5.1 e a base de regras

da Tabela 5.2 foram obtidas após alguns testes no Simulink com a planta real a partir
de parâmetros iniciais utilizados em um controlador Fuzzy para um sistema de tanques
simulado com características similares ao do laboratório. Não foram realizados ajustes
finos nos parâmetros do controlador para que este tivesse uma velocidade de subida alta e
nem níveis de overshoot e undershoot baixos, pois o objetivo do trabalho não é o de obter
um controlador ótimo para a planta, mas sim, obter um controlador que desempenhe de
forma satisfatória a sua função e compará-lo com o controlador Fuzzy implementado na
rede Foundation Fieldbus com os mesmo parâmetros (funções de pertinências e base de
regras).
5.3 Construção do controlador Fuzzy-FF

Devido à explicação mais geral e detalhada do capítulo 3 sobre os blocos utilizados
em cada estágio do controlador e suas funções, está seção se destina à explicar as novas
configurações, específicas para o controlador utilizado.
De posse da base de regras e das posições das funções de pertinência e utilizando o
software desenvolvido para o auxílio na configuração dos controladores Fuzzy, determinou-
se a quantidade de blocos a serem utilizados na construção do controlador. Foi necessário
5.3. CONSTRUÇÃO DO CONTROLADOR FUZZY-FF 63
desenvolver também o sistema de cálculo da variação do erro e o sistema acumulador de

tensão na rede FF. Da mesma forma que no controlador Fuzzy desenvolvido no Simulink,
estes dois sistemas são sistemas externos ao controlador, mas são bem semelhantes do
ponto de vista de implementação. O sistema de cálculo da variação é composto por um
bloco para gerar o atraso, dois blocos para calcular o módulo dos valores e um bloco para
gerar a subtração. No caso do acumulador, ele é formado por um bloco somador e um
bloco de memória.
Como o SYSCON permite a criação de lógicas separadas utilizando os mesmo blocos
funcionais, o controlador foi dividido em vários módulos, um para cada tarefa. O módulo
de cálculo de erro e da sua variação pode ser visto na Figura 5.7.
Figura 5.7: Módulo de cálculo do erro e da variação do erro.
O cálculo do erro é realizado de forma simples através de um bloco ARTH (o Bloco de

nome “Erro”), subtraindo o set-point (nível de referência) do nível atual. Já o cálculo da
variação é realizado por três blocos: dois CHAR e um ARTH. O primeiro bloco CHAR de
nome “Unit_Delay” realiza o atraso através de uma realimentação da primeira saída para
a segunda entrada. Devido a isso, o dado da segunda saída (que será o mesmo da primeira
saída) só estará disponível no ciclo seguinte do macro ciclo da rede. O segundo bloco
CHAR de nome “ABS” realiza o módulo dos sinais obtidos utilizando, internamente,
uma função rampa unitária simétrica sobre o eixo y. Por último o bloco ARTH de nome
“V_Erro” realiza a subtração do erro atual pelo erro anterior fornecido pela primeira e
segunda saída do bloco “Unit_Delay”, após passar pelo bloco ABS.
Para a construção do estágio de Fuzzyficação-FF foram utilizados 10 blocos CHAR,
um para cada função de pertinência, sendo 5 para a entrada do erro e 5 para a variação do
erro (Figura 5.8).
Figura 5.8: Estágio de Fuzzyficação-FF.
Para o estagio de Inferência-FF, foram utilizados 34 blocos ISEL (25 para a função
min e 9 para a função max). Os blocos ISEL para a função min foram dispostos na
forma de matriz para facilitar a compreensão. As Figuras 5.9 e 5.10 ilustram as duas
confi gurações.
Para o estágio de Desfuzzyficação-FF foram utilizados 7 blocos ARTH, que realizam
a média ponderada da saída (Figura 5.11). Três calculam a soma dos resultados obtidos
do estágio de inferência para cada função de pertinência de saída, multiplicados pelas
suas respectivas posições. Outros três calculam apenas a soma deste valores e o último
calcula a média ponderada (divide o resultado do cálculo do numerador pelo resultado do
cálculo do denominador).
Como a saída do Fuzzy é um incremento de tensão, a tensão do motor é dada pelo
acumulador, formado por um bloco ARTH e um bloco CONST. O bloco ARTH faz o papel
de somador e memória e o bloco CONST serve para dar o valor inicial do bloco ARTH
(de maneira que ele tenha uma referência com status de comunicação GOOD e iniciando
em zero). A Figura 5.12 ilustra o estágio final do controlador. A realimentação do bloco
ARTH só é computada a cada ciclo do macro ciclo, desta forma, o valor calculado em
uma iteração só é utilizado na soma do próximo macro ciclo, fazendo este sistema se
comportar como uma memória.
A configuração dos parâmetros de cada bloco CHAR do estágio de Fuzzyficação fica
por conta do programa desenvolvido em LabVIEW que configura os 400 parâmetros refe-
rentes a cada uma das 5 funções de pertinência das 2 entradas.
5.4. RESULTADOS 65
Figura 5.9: Estágio de inferência 1: Cálculo do valor mínimo entre funções de pertinência.
5.4 Resultados
O primeiro teste realizado foi verifi car se as respostas do controladorFuzzy-FF eram
idênticas às obtidas com o controlador desenvolvido na ferramenta Fuzzy do MATLAB.
Para isso, levantou-se a superfície de resposta dos dois controladores. Esta superfície
é formada pelas coordenadas x-y referentes as duas entradas (erro e variação do erro)
do controlador e o eixo z que corresponde a resposta do controlador (o incremento de
tensão). Para levantar esta superfície foi desenvolvida uma rotina em MATLAB que en-
via, via OPC para a rede FF, os dados do erro e da variação do erro além de executar o
mesmo com o controlador da ferramenta Fuzzy do MATLAB. Foram criados dois vetores
com 21 pontos para cada uma das entradas, totalizando uma superfície possui 441 pontos
(resposta dos controladores Fuzzy do MATLAB e da rede FF). As repostas foram arma-
zenadas em duas matrizes e delas foram geradas as superfícies exibidas nas Figuras 5.13
e 5.14.
Pode-se perceber que a superfície das respostas dos dois controladores foi aproxima-
damente a mesma, mas para se verifi car o quão iguais as respostas dos dois controladores
foram, realizou-se a diferença entre estas superfícies gerando uma superfície de erro, exi-
bida na Figura 5.15.
Figura 5.10: Estágio de inferência 2: Cálculo do valor máximo entre as regras do contro-
lador.
Por esta superfície de erro pode se perceber que o controlador Fuzzy-FF responde da
mesma foram que o controlador Fuzzy do MATLAB.
O segundo teste realizado foi o de verifi car o funcionamento do controlador na prática,
efetuando o controle de nível do tanque para comandos de set-points diferentes. Para re-
alizar a comparação, foi realizado o mesmo teste de controle em ambos os controladores
com o mesmos set-points para ambos. Também foi utilizado no Simulink um tempo de
amostragem (para a simulação) de 1 segundo, o mesmo tempo utilizado no macro ciclo
da rede industrial FF, além de tomar-se o cuidado de ajustar todos os blocos da simula-
ção para que não gerassem atrasos, o que desta forma, garantia a execução da simulação
no tempo de 1 segundo. Utilizando o sistema desenvolvido no Simulink mostrado na
Figura 5.3, foram levantadas as curvas de nível e referência para o controlador Fuzzy im-
plementado no MATLAB. Para obter os mesmo gráfi cos do controladorFuzzy-FF foram
realizadas algumas alterações neste primeiro sistema para gerar apenas o sinal de referên-
cia e obter o sinai de nível do controlador na rede FF (Figura 5.16). Com isso obteve-se o
gráfico da Figura 5.17.
Como pode-se visualizar em ambos os gráficos, eles são semelhantes, mas existem
algumas diferenças com relação ao overshoot e undershoot, onde o controlador Fuzzy-FF
obteve menores níveis.
Isso provavelmente se deve ao fato de que o controlador Fuzzy-FF não está sujeito a
atrasos no processamento das informações, já que ele está rodando dentro de uma rede
altamente determinística, com atualizações a cada 1 segundo. Já no caso do controlador
Fuzzy-MATLAB, apesar de estar rodando em tempo real, também com atualizações na
casa de 1 segundo, não se pode garantir que a comunicação do servidor OPC e da rede
5.4. RESULTADOS 67
Figura 5.11: Estágio de Desfuzzyficação.
Figura 5.12: Módulo de saída do controlador (sinal de tensão enviado para a bomba).
Figura 5.13: Superfície de resposta do controlador Fuzzy-MATLAB.
Figura 5.14: Superfície de resposta do controlador Fuzzy-FF.

5.4. RESULTADOS 69
Figura 5.15: Superfície de Erro (comparação de respostas entre os controlador Fuzzy-

MATLAB e Fuzzy-FF).
Figura 5.16: Sistema no Simulink para envio e obtenção dos dados do controlador Fuzzy-
FF.
Ethernet através de roteadores (a forma de ligação entre a DFI e o computador) seja

exatamente de 1 segundo. O MATLAB pode garantir o envio a cada 1 segundo, mas
não pode garantir que a informação seja captada pelo sistema de tanques exatamente a
cada 1 segundo, o que pode gerar esta pequena diferença de comportamento entre os dois
controladores.
Figura 5.17: Resposta do controlador Fuzzy-MATLAB (em vermelho) e Fuzzy-FF (em

azul) no controle do nível do tanque.
O último teste realizado foi para verificar a influência do macro ciclo na configuração
do controlador Fuzzy-FF. A ideia é verificar quanto o macro ciclo pode melhorar ou pi-
orar o desempenho do controlador. Como base para a comparação, utilizou-se o caso do
macro ciclo de 1 segundo, o qual foi utilizado nos outros testes. Primeiramente diminui-
se ao máximo o macro ciclo (o mínimo permitido para esta configuração é de 516 ms) e
realizou-se o mesmo teste com os set-points variando entre 15, 25 e 5 cm respectivamente
como nos testes anteriores. Depois o tempo de macro ciclo foi elevado para 4 segundos.
A Figura 5.18 ilustra as respostas obtidas.
Como pode ser visto, a mudança no tempo do macro ciclo para um valor menor fez
com que o controlador respondesse de forma mais rápida. Com incrementos mais rápidos
o controlador eleva mais rapidamente a tensão fazendo subir mais rapidamente o nível
do tanque e também alcança a estabilidade mais rapidamente. Em compensação, com
incrementos mais rápidos e uma subida mais rápida do nível do tanque, isso acaba gerando
overshoots e undershoots maiores. Já no caso do aumento do tempo do macro ciclo, os
incrementos de tensão ficaram mais lentos, o que faz com que o nível do tanque suba
lentamente. No caso do teste, a subida do nível ficou tão lenta que não alcançou o primeiro
nível desejado do teste antes dele ser alterado.
Isso mostra que, como foi dito no capítulo 2, a definição do macro ciclo se torna
muito importante na execução de qualquer lógica de controle. A utilização de sistemas
mais lentos em conjunto com mais rápidos pode acarretas falhas catastróficas, como por
5.4. RESULTADOS 71
Figura 5.18: Resposta do controlador Fuzzy-FF para os macro ciclos de 516 ms (em azul),
1000 ms (em vermelho) e 4000 ms (em ciano).
exemplo, um sistema supervisório enviando um sinal para ser incrementado na rede e

depois lido novamente pelo supervisório. A definição de um macro ciclo mais rápido que
o sistema supervisório poderia acarretar em incrementos muito grandes antes de que a
leitura pudesse ser realizada. O caso contrário também seria um problema, já que se uma
rede estivesse trabalhando com um macro ciclo muito lento poderia retardar comandos
dados pelo sistema supervisório e causar acidentes no processo em que estivesse atuando.
Capítulo 6
Considerações Finais
Este trabalho apresentou uma metodologia de como criar controladores Fuzzy dentro
de redes industriais Foundation Fieldbus, mostrando detalhadamente a criação de cada
estrutura utilizada nesse tipo de controlador. Além disso, apresentou também o desen-
volvimento de uma ferramenta para o auxílio na criação e configuração do controlador
Fuzzy-FF.
No decorrer do texto, foi dado toda uma abordagem teórica sobre redes industriais
e lógica Fuzzy, explicando sua importância para diversos ambientes e as dificuldades
de implementação em alguns dispositivos de hardware, permitindo assim que o leitor
pudesse se embasar do tema e pudesse entender melhor a motivação e como se dá a
criação de cada estrutura utilizada no controlador desenvolvido.
Como forma de comparar o controlador Fuzzy-FF, utilizou-se uma ferramenta ma-
temática com capacidade de trabalhar com lógica Fuzzy e com os resultados obtidos,
comprovou-se que é possível aplicar e utilizar este tipo de controlador em redes indus-
triais do tipo Foundation Fieldbus. O desempenho do controlador Fuzzy-FF foi igual ao
do controlador Fuzzy da ferramenta matemática, com a principal vantagem de que o con-
trolador Fuzzy-FF é executado dentro da rede industrial FF, não dependendo de nenhuma
estrutura auxiliar para funcionar, nem de nenhum sistema de comunicação que não do da
própria rede.
Os gráficos obtidos nos testes mostram que em questão de resposta, os dois contro-
ladores possuem a mesma saída para as mesma variáveis de entrada. Numa aplicação
prática de controle de nível, é possível ver que o controlador Fuzzy-FF chega a ter um
desempenho um pouco melhor que o outro controlador.
Apesar de que sua utilização se tornar um pouco limitada por causa do baixo poder
de processamento dos instrumentos e, por isso, não poder ser aplicado todo tipo de mé-
todos de desfuzzyficação (como os métodos de centro de área e bissetor de área), isso
não impede que seja aplicado a casos mais simples de controle (com métodos utilizando
funções singleton). Em poucos anos a questão do baixo poder de processamento será uma
questão trivial e estes métodos que exigem um poder de processamento maior poderão ser
aplicados de maneira fácil a todo dispositivo de hardware. A tecnologia vem evoluindo
de forma muito rápida e em pouco tempo já deverão existir processadores embarcados em
sensores com alto poder de processamento. A utilização da lógica Fuzzy traz diversos be-
nefícios, um deles é a falta da necessidade de especificar modelos complexos, dos quais
74 CAPÍTULO 6. CONSIDERAÇÕES FINAIS
não se tem muito conhecimento. Este trabalho exemplificou bem isso, já que os dados
sobre o atraso (entre o envio da tensão e a efetiva mudança de nível), vazão do tanque e
das zonas mortas da bomba e sensores atualmente não são conhecidos, mas não fizeram
grande diferença no controle do nível do tanque.
Com relação à ferramenta de configuração, esta se mostrou realmente útil, já que di-
minui o trabalho de configuração dos blocos funcionais, além de proporcionar um sistema
de informação para a alocação correta da lógica Fuzzy no ambiente FF. Apesar de não po-
der configurar diretamente a rede industrial (configurar as ligações dos blocos) ela permite
que o usuário possa configurar os parâmetros deles, umas das tarefas que mais despende
tempo.
Como sugestões de trabalhos futuros ficam o desenvolvimento de uma tela que exiba
as ligações que devem ser efetuadas entre cada um dos blocos funcionais da rede FF. Isso
facilitaria mais ainda a configuração da lógica Fuzzy, já que o usuário poderia acompanhar
de forma gráfica quais blocos ele deve interligar para que o controlador Fuzzy pretendido
funcione. Outras sugestões seriam o acréscimo de novas funções de pertinência além das
três existentes, modificação da configuração da saída permitindo acrescentar mais saídas e
a uma modificação no sistema de configuração dos blocos, permitindo que outros blocos,
além dos blocos sinais caracterizadores, possam ser configurados de forma automática.
Lista de Publicações
Machado, V. P.; Brandão, D.; Dória Neto, A. D.; de Melo J. D.; Ramalho, L.; Me-
deiros, J.; Martins, D. L.; (2008) Dynamic Function Blocks Allocation: A Multiagent
Approach. XVII Congresso Brasileiro de Automática - CBA 2008. Juiz de Fora.
Filho, A. M. P. P.; Lopes, K. R.; Silva, V. L. C. M. da; Martins, D. L.; Neto, A. D. D.;
Melo, J. D. de; Oliveira, L. A. H. G. de; Controle de uma Coluna Debutanizadora Simu-
lada Utilizando um Controlador Fuzzy Embarcado em uma Rede Foundation Fieldbus,
Simpósio Brasileiro de Automação Inteligente - SBAI 2009, Brasília.
Martins,Daniel L.; Ramalho, Leonardo S. G.; da Costa, Bruno X.; Rodrigues, Igor
de O.; Neto, Adrião D. D.; de Melo, Jorge D.;Implementação de um Demultiplexador
Aplicado ao Ambiente Foundation Fieldbus, XVII Congresso Brasileiro de Automática -
CBA 2008. Juiz de Fora.
75
76 LISTA DE PUBLICAÇÕES
Referências Bibliográficas
Bordim, Jacir L. (2006), Redes industriais-fieldbus. Universidade de Brasília-UNB.
Cagni, Eloi, David Ricardo Pereira, Adrião Duarte Dória Neto, Jorge Dantas de Melo
& Luiz Affonso Henderson Guedes de Oliveira (2005), The implementation of the
self-calibration, self-compensation and self-validation algorithms for foundation fi-
eldbus sensors are presented using standard function blocks, em ‘Computational
Intelligence for Measurement Systems and Applications, 2005. CIMSA. 2005 IEEE
International Conference on’, pp. 220 – 225.
Carvalho, Adelson Siqueira, Ronald Coutinho da Silva & Dênis Barbosa do Nascimento
(2008), ‘Aplicação de técnicas de sintonia fuzzy em uma coluna de destilação pi-
loto’, V Simpósio de Excelência em Gestão e Tecnologia-SEGeT .
Chen, Guanrong & Trung Tat Pham (2001), Introduction to Fuzzy Sets, Fuzzy Logic, and
Fuzzy Control Systems, CRC Press.
Costa, Isabele Morais (2006), Projeto e implementação em ambiente foundation fieldbus

de filtragem estocástica baseada em análise de componentes independentes, Disser-
tação de mestrado, Universidade Federal do Rio Grande do Norte-UFRN.
Duarte, André F., Gilberto T. Júnior, Rafael A. V. dos Santos & Saint-Clair Chaves (2003),
‘Redes de automação industrial’, Projeto Final do Curso de Engenharia Industrial
Elétrica com Ênfase em Telecomunicações. Centro Federal de Educação Tecnoló-
gica do Rio de Janeiro - CEFET-RJ.
Fadaei, A. & K. Salahshoor (2008), Improving the control performance of networked

control systems using a new fuzzy pid, em ‘Industrial Electronics, 2008. ISIE 2008.
IEEE International Symposium on’, pp. 2066 –2071.
Fernandes, Raphaela Galhardo, Diego R. Cabral Silva Luiz Affonso Guedes & Adrião
Duarte Dória Neto (2007), ‘An implementation of a fault detection and isolation
system on foundation fieldbus environment’, International Journal of Factory Auto-
mation, Robotics and Soft Computing 3, 130–136.
Filho, Alexandre M. P. P, Kennedy R. Lopes, Victor L. C. M. da Silva, Daniel L. Martins,

Adrião D. D. Neto, Jorge D. de Melo & Luiz A. H. G. de Oliveira (2009), ‘Controle
de uma coluna debutanizadora simulada utilizando um controlador fuzzy embarcado
em uma rede foundation fieldbus’, Simpósio Brasileiro de Automação Inteligente-
SBAI .
77
78 REFERÊNCIAS BIBLIOGRÁFICAS
Francisco, Marcos Salazar, Karl Heintz Kienitz & Dennis Brandão (2008), ‘Blocos funci-
onais foundation fieldbus para controle fuzzy’, Congresso Brasileiro de Automática-
CBA .
Gutierrez, R. M. & S. S. Pan (2008), ‘Complexo eletrônico:automação do controle indus-

trial.’.
Haykin, Simon (2001), Redes Neurais princípios e prática, Bookman.
Ibrahim, Ahmad M. (2004), Fuzzy Logic for Embedded Systems Applications, Newnes-
Elsevier.
Instruments, National & Malan Shiralkar (2007), Labview graphical programming course,
Collection courses, Connexions, Rice University, Houston, Texas.
Jantzen, j. (1998), Design of fuzzy controllers, Technical Report TR 98-E-864, Technical

University of Denmark, Lyngby, Denmark.
Junior, Francisco Guerra Fernandes, José Soares Batista Lopes, André Laurindo Maitelli,
Fabio Meneghetti Ugulino de Araújo & Luiz Affonso Henderson Guedes de Oliveira
(2005), ‘Implementação de controladores pid utilizando lógica fuzzy e instrumenta-
ção industrial’, VII Simpósio Brasileiro de Automação Inteligente-SBAI .
Kehtarnavaz, Nasser & Namjin Kim (2005), Digital Signal Processing System-Level De-
sign using LabVIEW, Newnes.
Klir, George J. & Bo Yuan (1995), Fuzzy Sets And Fuzzy Logic: Theory and Applications,
Prentice Hall.
Leite, Manuela Souza, Ana Maria Frattini Fileti & Flávio Vasconcelos da Silva (2010),
‘Desenvolvimento e aplicação experimental de controladores fuzzy e convencional
em um bioprocesso’, Sba: Controle & Automação Sociedade Brasileira de Automa-
tica 21, 147 – 158.
Lima, Fábio Soares de (2004), Estratégia de escalonamento de controladores pid baseado

em regras fuzzy para redes industriais foundation fieldbus usando blocos padrões,
Dissertação de mestrado, Universidade Federal do Rio Grande do Norte-UFRN.
Machado, V. P. (2009), Uma Arquitetura Baseada em Agentes para Configuração Dinâ-

mica de Aplicações Inteligentes em Ambiente Foundation Fieldbus, Tese de douto-
rado, UFRN, Natal, RN.
Mamdani, E. H. (1974), ‘Application of fuzzy algorithms for control of simple dynamic

plant’, Procedings of IEEE 121(12), 1585–1588.
Martins, D. L. (2008), ‘Implementação de um demultiplexador aplicado ao ambiente

foundation fieldbus’, Monografia de Graduação em Engenharia de Computação e
Automação. Universidade Federal do Rio Grande do Norte-UFRN.
REFERÊNCIAS BIBLIOGRÁFICAS 79
Martins, Daniel L., Leonardo S. G. Ramalho, Bruno X. da Costa, Igor de O. Rodrigues,

Adrião D. D. Neto & Jorge D. de Melo (2008), ‘Implementação de um demultiplexa-
dor aplicado ao ambiente foundation fieldbus’, Congresso Brasileiro de Automática-
CBA .
Maruyama, Newton (2004), Uma breve introdução aos sistemas de controle, Notas de
aula.
Oliveira, Luiz A. H. G. (2005), Classificação das redes para automação industrial, Apre-
sentação em slides, Universidade Federal do Rio Grande do Norte-UFRN, Natal,
RN.
Pagliosa, Angelo L. (2003), Obtenção das funções de pertinência de um sistema neuro-

fuzzy modificado pela rede de kohonen, Dissertação de mestrado, Universidade do
Estado de Santa Catarina - UDESC.
Passino, Kevin M. & Stephen Yurkovich, eds. (1998), Fuzzy Control, Addison-Wesley
Longman, The Ohio State University.
Puda, Adriano P. (n.d.), Padronização da comunicação através da tecnologia opc. Soft-

Brasil Automação Ltda.
Ramalho, Leonardo Sávio Guanabara (2009), Reconfiguração dinâminca de estratégias

distribuídas em dispositivos foundation fieldbus para a otimização de processos na
indústria do petróleo, Dissertação de mestrado, Programa de pós-graduação em ciên-
cias e Engenharia de petróleo, Universidade Federal do Rio Grande do Norte-UFRN.
Ribeiro, Marco Antônio (1999), Automação industrial, Apostila para curso de treina-
mento.
Rosário, João Maurício (2005), Princípios de Mecatrônica, Prentice Hall.
Sandri, Sandra & Cláudio Correa (1999), ‘Lógica nebulosa’, V Escola de Redes Neurais,
Conselho Nacional de Redes Neurais pp. 073–090.
Silva, Diego R. Cabral, Luiz Affonso Guedes Adrião Duarte Dória Neto & Jorge Dantas
de Melo (2006), ‘Neural networks implementation in foundation fieldbus environ-
ment: A case study in neural control’, International Journal of Factory Automation,
Robotics and Soft Computing .
Smar (2005), Manual de intruções dos blocos funcionais, Smar.
Stemmer, Marcelo Ricardo (2001), Sistemas distribuídos e redes de computadores para

controle e automação industrial, Apostila de aula.
Takagi, Tomohiro & Michio Sugeno (1985), ‘Fuzzy identification of systems and its ap-
plications to modeling and control’, IEEE Transactions on Systems, Man, and Cy-
bernetics 15(1), 116–132.
80 REFERÊNCIAS BIBLIOGRÁFICAS
Weber, Leo & Pedro Antonio Trierweiler Klein (2003), Aplicação da Lógica Fuzzy em
Software e Hardware, Editora da Ulbra.
Zadeh, L.A. (1965), ‘Fuzzy sets’, Information Control 8, 338–353.

DanielLM DISSERT

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

DanielLM DISSERT

Enviado por

Direitos autorais:

Formatos disponíveis

U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE

Arquitetura de controladores Fuzzy em redes

Daniel Lopes Martins

Orientador: Prof. Dr. Adrião Duarte Dória Neto

Co-orientador: Prof. Dr. Jorge Dantas de Melo

Dissertação de Mestrado apresentada ao

Natal, RN, fevereiro de 2011

Martins, Daniel Lopes.

Orientador: Adrião Duarte Dória Neto.

Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte.

RN/UF/BCZM CDU 004.725.5

Ao meu orientador Adrião, co-orientador Jorge e ao professor Affonso, que já na gradu-

Aos companheiros do LAMP, Alexandre, Kennedy e Victor que, comigo, desenvolveram

Aos demais professores do departamento que contribuíram direta ou indiretamente com a

À CAPES e CNPq, pelo apoio financeiro.

Lista de Figuras iii

Lista de Símbolos e Abreviaturas vii

3 Fuzzy aplicado ao ambiente Foundation Fieldbus 37

4 Interface de configuração Fuzzy-FF em LabVIEW 47

2.1 Máquina de Watt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Tela do SYSCON: Ao centro a tela principal, À esquerda a tela de confi-

4.1 Interface do programa. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1 Sistema de tanques utilizado no teste. . . . . . . . . . . . . . . . . . . . 58

2.1 Principais blocos funcionais Foundation Fieldbus. . . . . . . . . . . . . . 20

3.1 Tabela relativa a base de regras do exemplo. . . . . . . . . . . . . . . . . 39

5.1 Funções de pertinência utilizadas na aplicação teste. . . . . . . . . . . . . 60

A/D: Conversor de dados analógicos para digitais

AG: Algoritmos genéticos

AI: Analog Input, Bloco FF de entrada analógica

ARTH: Arithmetic, Bloco FF para cálculos aritméticos

CHAR: Characterizer, Bloco FF caracterizador de sinais

CLP: Ou PLC é um Circuito Lógico Programável, um computador especializado base-

D/A: Conversor de dados digitais para analógicos

FF: Foundation Fieldbus, um protocolo de rede industrial

FI: Conversor do padrão FF para o loop de corrente

IF: Conversor de loop de corrente de para o padrão FF

LabVIEW: Laboratory Virtual Engineering Workbench é um ambiente de programação

LAN: Local Area Network, é um rede local de computadores

LAS: Link Active Scheduler é o dispositivo responsável por gerenciar as comunicações

mA: miliampere, milésima parte do ampere que é a unidade de medição da corrente

OLE: Tecnologia utilizada para comunicação entre aplicativos, baseado no COM

PID: Proporcional, Integrativo e Derivativo, tipo de controlador utilizado na indústria

PR: Probe Response, resposta do dispositivo da rede à mensagem PN do LAS

RNA: Redes Neurais Artificiais

RS232: Padrão de comunicação de dados de maneira serial

V: Unidade de tensão elétrica

VI: Virtual Instrument é um programa gerado pelo LabVIEW

A automação industrial cresceu muito nos últimos anos. A necessidade de se produzir

gem é a capacidade de trocar informação e da criação de lógicas de controle complexas,

1.2 Estrutura da Dissertação

Este capítulo abordará toda a fundamentação necessária para o entendimento do tra-

2.1 Redes industriais

Figura 2.1: Máquina de Watt.

Figura 2.2: Malha de controle.

Figura 2.3: História dos sistemas de comunicação.

Figura 2.4: Sistema Digital de Controle Distribuído-SDCD.

Figura 2.5: Convergência-CLPxSDCD.

Inicialmente as comunicações dos instrumentos eram ponto-a-ponto usando padrão

Figura 2.6: Tendência das ligações dos sensores e atuadores.

Figura 2.7: Tipos de redes de controle e automação.

2.1.1 Rede Industrial Foundation Fieldbus (FF)

trole e monitoração de processo e estações de operação através de softwares supervisórios

Figura 2.8: Simplificação das redes.