PFC v1-01

Plataforma de Auxílio à Manutenção
Remota de Máquinas Controladas por

CLP
Monografia submetida à Universidade Federal de Santa Catarina

como requisito para a aprovação da disciplina:
DAS 5511: Projeto de Fim de Curso
Marco San Martins
Florianópolis, outubro de 2005

Plataforma de Auxílio à Manutenção Remota de Máquinas
Controladas por CLP
Marco San Martins
Esta monografia foi julgada no contexto da disciplina

DAS 5511: Projeto de Fim de Curso
e aprovada na sua forma final pelo
Curso de Engenharia de Controle e Automação Industrial
Banca Examinadora:
Eng. Rogério da Nova Cruz Peter

Orientador da Empresa
Prof. Carlos Montez

Orientador do Curso
Prof. Augusto Humberto Bruciapaglia

Responsável pela disciplina
Prof. Ricardo Stemmer, Avaliador
Elson Mota, Debatedor
Victor Rocha, Debatedor

Agradecimentos
Primeiramente gostaria de agradecer aos meus pais e meus irmãos que tanto
me incentivaram durante esta jornada. Tenho certeza de que sem o apoio deles
nada disso teria se realizado.
À Universidade Federal de Santa Catarina e todos os seus funcionários, por

terem me proporcionado um ensino superior de qualidade.
Aos amigos, novos e antigos. Obrigado por tornar esses cinco anos não
apenas um período de aprendizagem técnica, mas uma aprendizagem de vida.
Tenho certeza de que as amizades aqui feitas durarão para sempre.
A Juliana, com muito amor.
i
Resumo
Este trabalho tem como finalidade a criação de um sistema que viabilize o

acesso remoto a máquinas controladas por equipamentos capazes de se
comunicarem em rede. A solução aqui proposta foi focada para resolver os
problemas de manutenção nas máquinas da empresa San Martin. O objetivo era
fazer diagnósticos, alterar parâmetros e orientar testes com o mínimo auxílio dos
funcionários das empresas clientes.
Na solução implementada, foram utilizados dois protocolos de comunicação

para redes industriais, chamados Modbus RTU e Modbus TCP, para a troca de
dados local e um protocolo proprietário, baseado em Web Services, para a troca de
dados remota. Foi necessária a criação de um software supervisório, componentes
de acesso aos protocolos referidos e um software com a função de gateway entre
esses protocolos.
ii
Abstract
This work has as purpose the development of a system that makes possible
the remote access to controlled machines with capable equipment in net
communication. The solution proposed was focused in the problems of machines
maintenance of San Martin’s company. The objective was to make diagnostics, to
modify parameters and to guide tests with the minimum aid of the customer’s
companies’ employees.
In the implemented solution, two communication protocols for industrial nets

called Modbus RTU and Modbus TCP have been used for the local data exchange,
and a proprietary protocol based on Web Services has been used for the remote data
exchange. It was necessary the design of a supervisory software, that is the access
component to the above mentioned protocols, and a software with the function of
gateway between those protocols.
iii
Sumário
Agradecimentos................................................................................................. i
Resumo ............................................................................................................ ii
Abstract ........................................................................................................... iii
Sumário ........................................................................................................... iv
Lista de Figuras ............................................................................................... vi
Simbologia........................................................................................................1
Capítulo 1: Introdução ......................................................................................2
1.1: Histórico da Empresa.............................................................................2
1.2: Introdução ao Problema.........................................................................4
Capítulo 2: Estudo do Produto..........................................................................8
2.1: Fulão de Recurtimento e Tingimento .....................................................8
2.1.1: Automatização...............................................................................10
2.1.2: Interface Local ...............................................................................11
2.1.3: Arquitetura da Rede FieldBus........................................................12
2.2: Suporte Técnico ...................................................................................12
Capítulo 3: Implementação da Solução ..........................................................15
3.1: Padrões Utilizados na Modelagem do Software...................................15
3.1.1: A Análise Orientada a Objeto ........................................................15
3.1.2: Diagramas UML.............................................................................19
3.1.3: Metodologia ...................................................................................21
3.2: Modbus ................................................................................................22
3.2.1: Introdução......................................................................................22
3.2.2: Descrição do Protocolo .................................................................24
iv
3.2.3: Formato dos Dados .......................................................................29
3.2.4: Modelo de Dados ..........................................................................29
3.2.5: Modelo de Endereçamento............................................................29
3.2.6: Transação Modbus........................................................................30
3.2.7: Funções Implementadas ...............................................................32
3.3: Web Services .......................................................................................39
3.3.1: Contextualização ...........................................................................39
3.3.2: Arquitetura de Funcionamento ......................................................40
3.4: Generalização da Solução ...................................................................42
3.5: Componentes do Sistema....................................................................44
3.5.1: Supervisório...................................................................................45
3.5.2: Gateways Modbus TCP e Web Service ........................................46
3.5.3: Gateway Modbus TCP / Modbus RTU ..........................................56
3.6: Implementação do Gateway ................................................................57
Capítulo 4: Resultados ...................................................................................63
Capítulo 5: Conclusões e Perspectivas ..........................................................65
Bibliografia:.....................................................................................................67
v
Lista de Figuras
Figura 1-1: Máquina de Amaciar ......................................................................3
Figura 1-2: Fulão de Amaciar ...........................................................................3
Figura 1-3: Fulão de Recurtimento ...................................................................3
Figura 1-4: Fulão de Amaciar de Grande Capacidade .....................................3
Figura 3-1: Fulão de Recurtimento e Tingimento BorealMatic 2100.................8
Figura 3-2: Divisão Interna do Fulão.................................................................9
Figura 3-3: Vista Posterior do BorealMatic .....................................................10
Figura 3-4: Arquitetura da Rede Fieldbus.......................................................12
Figura 4-1: Definição da Classe TPDU...........................................................16
Figura 4-2: Hierarquia da Família TPDU. .......................................................17
Figura 4-3: Representação Gráfica da Classe Complexa TCustomGateway. 18
Figura 4-4: Processo de Desenvolvimento .....................................................22
Figura 4-5: Exemplo de Arquitetura de Rede Modbus....................................23
Figura 4-6: Camadas do Modbus ...................................................................24
Figura 4-7: Frame Modbus Genérico..............................................................24
Figura 4-8: Transação Modbus sem Erro .......................................................25
Figura 4-9: Transação Modbus com Erro .......................................................26
Figura 4-10: ADU sobre TCP/IP .....................................................................27
Figura 4-11: Protocolo Modbus e o Modelo ISO/OSI .....................................28
Figura 4-12: PDU sobre Linha Serial ..............................................................28
Figura 4-13: Modelo de Endereçamento Modbus...........................................30
Figura 4-14: Fluxograma de uma Transação..................................................31
Figura 4-15: Ciclo de Vida de um Web Service ..............................................42
vi
Figura 4-16: Arquitetura Simplificada..............................................................43
Figura 4-17: Arquitetura do Sistema ...............................................................44
Figura 4-18: Comunicação do Supervisório....................................................45
Figura 4-19: Software Supervisório ................................................................46
Figura 4-20: Camadas de um Gateway ..........................................................47
Figura 4-21: Sistema de Gateways Modbus TCP e Web Service ..................48
Figura 4-22: Diagrama Request / Reply .........................................................49
Figura 4-23: Serialização Excessiva...............................................................54
Figura 4-24: Serialização Minimizada.............................................................55
Figura 4-25: Diagrama de Atividades do Gateway 2 ......................................55
Figura 4-26: Gateway Modbus TCP / Modbus RTU .......................................56
Figura 4-27: Interface do Software – Servidor ................................................57
Figura 4-28: Interface do Software – Cliente ..................................................58
Figura 4-29: Interface do Software – Fieldbus................................................58
Figura 4-30: Interface do software – Tabelas .................................................58
Figura 4-31: Diagrama de Classes Gateway ..................................................59
Figura 4-32: Arquitetura de Acesso Remoto Simplificada ..............................60
Figura 4-33: Arquitetura de Acesso Local.......................................................61
vii
Simbologia
ADU – Application Data Unit
CLP – Controlador Lógico Programável
CRC – Cyclical Redundancy Checking
HTTP – Hyper Text Transfer Protocol
IHM – Interface Homem / Máquina
IP – Internet Protocol
PDU – Protocol Data Unit
POO – Programação Orientada a Objetos
RTU – Remote Terminal Unit
SOAP – Simple Object Access Protocol
TCP – Transmission Control Protocol
UDDI – Universal Discovery Description and Integration
UML – Unified Modeling Language
XML – Extensible Markup Language
WSDL – Web Services Description Language
1
Capítulo 1: Introdução
O presente trabalho foi desenvolvido na empresa San Martin Máquinas e

Veículos Ltda., e está relacionado à manutenção de máquinas desenvolvidas e
fabricadas pela empresa.
1.1: Histórico da Empresa
A empresa San Martin Máquinas e Veículos Ltda. é uma empresa do setor

metal mecânico, fundada em 1980. Instalada na cidade de Pelotas, no Rio Grande
do Sul, a empresa já fabricou máquinas para os mais diversos setores. Atualmente,
concentra suas atividades no setor de curtumes.
A empresa traz em seu histórico, equipamentos vendidos para o mercado

coureiro mundial, com equipamentos no Japão, Itália, Alemanha, Austrália, entre
outros.
Na área metal mecânica, além da fabricação de máquinas, a San Martin

presta serviços para a produção de perfis especiais de chapa dobrada, peças e
componentes em aço inoxidável, alumínio, cobre, latão e outras ligas. Produtos da
mais alta qualidade e de grande aplicação na área industrial.
A empresa ainda dispõe dos serviços de tornearia, caldeiraria,

desenvolvimento de projetos de equipamentos e instalações, soldagem pelos
processos (elétrico, mig, tig, argônio e oxiacetilênico).
Na área de equipamentos para o mercado do couro, atualmente, a San Martin

tem sua produção voltada para o ramo do curtimento, recurtimento, tingimento e
amaciamento de couros. Abaixo, seguem algumas máquinas produzidas hoje em dia
pela empresa.
2
Figura 1-1: Máquina de Amaciar
Figura 1-2: Fulão de Amaciar
Figura 1-3: Fulão de Recurtimento
Figura 1-4: Fulão de Amaciar de Grande Capacidade
Em 1997, a empresa entrou na área da automação. Primeiramente, passou a

desenvolver projetos para automatizar as máquinas que fabricava. Embalada pelos
bons resultados obtidos, a empresa começa a desenvolver projetos de automação
para terceiros.
3
1.2: Introdução ao Problema
A San Martin tem como diferencial de suas máquinas, em relação à dos

concorrentes, uma automação mais evoluída. Em geral, as máquinas são todas
controladas por CLPs que seguem receitas previamente cadastradas, enquanto as
dos concorrentes possuem painéis eletromecânicos com alguns controladores. Esse
diferencial, em alguns casos, tem se voltado contra a empresa. A justificativa dos
clientes para isto, é que, em caso de problemas, com painéis eletromecânicos, eles
mesmos resolvem, porém, quando se trata de componentes mais modernos, eles
não possuem pessoal qualificado para tais intervenções.
Devia-se buscar uma solução que minimizasse esse problema. Para isso, foi
proposta a elaboração e implementação de um sistema que permitisse ao pessoal
qualificado acessar os CLPs de forma remota, para que soluções pudessem ser
encontradas no menor tempo possível.
Sistemas como esses são estudados em disciplinas como Informática

Industrial I e II, Redes, Integração de Sistemas Corporativos, além de Sistemas
Distribuídos entre outros. Na realidade, podemos enxergar o problema a ser
resolvido como um problema de Tecnologia de Informação, assunto bastante atual.
Durante a modelagem e implementação, vários outros tópicos vistos durante o curso
tiveram que ser utilizados, tais como engenharia de software e programação
concorrente.
A necessidade da implementação do projeto deu-se devido aos altos custos

ocasionados pelo problema descrito acima, que resultavam em:
• Inatividade do equipamento por um grande período;
• Alto custo de manutenção por contratação de pessoal especializado da

região (terceirização);
• Alto custo de deslocamento dos técnicos da San Martin;
• Inatividade do técnico durante seu deslocamento;
• Degradação da imagem da empresa junto a seus clientes;
• Elaboração de projetos especiais para máquinas sem CLP.
4
Tais problemas levaram ao questionamento de alternativas que pudessem, se
não solucionar, pelo menos minimizar os inconvenientes citados acima.
A partir da aprovação do projeto, a empresa pretende instalar o sistema em

todas as máquinas que produz, objetivando os seguintes resultados:
• Fazer diagnósticos remotos sem a ajuda do cliente;
• Diminuir o tempo de máquina parada;
• Eliminar deslocamentos desnecessários de seus técnicos;
• Elaborar um procedimento padrão para o atendimento ao cliente;
• Aumentar a confiança do cliente perante os equipamentos produzidos pela

empresa.
Para orientar o desenvolvimento do projeto, inicialmente, foi feito um estudo

das tecnologias disponíveis. Com isso, passamos a conhecer melhor as alternativas
e cuidados que seriam necessários para a implementação. Em seguida, passamos a
verificar possíveis soluções e analisar suas vantagens e desvantagens.
1. Eliminar os componentes mais complexos dos painéis das

máquinas. Com isso, os técnicos de manutenção dos clientes
estariam capacitados a dar suporte eles mesmos.
Vantagens: Os clientes se sentiriam mais seguros lidando com

tecnologias que eles compreendem.
Desvantagens: Perderíamos o diferencial, estaríamos retrocedendo

tecnologicamente ao patamar dos concorrentes.
2. Fazer o treinamento dos técnicos de manutenção das empresas

clientes. Com isso, eles poderiam solucionar os problemas ou, pelo
menos, ter a capacidade de relatar corretamente o estado das
máquinas.
5
Vantagens: Eles conheceriam melhor as máquinas, podendo inclusive,
prevenir certos problemas. A manutenção seria “instantânea”.
Desvantagens: Alto custo para o treinamento. Um curso não garante

que os “alunos” aprendam e, durante o curso, eles deixariam de estar
trabalhando.
3. Fazer acesso remoto via modens telefônicos. No caso da Siemens,

existe uma expansão que pode ser acoplada ao CLP e, através
dela, é possível acessar a memória do mesmo.
Vantagens: Não seria necessário o desenvolvimento de uma nova

solução, ela já se encontraria pronta.
Desvantagem: Custo. Para cada máquina, seria necessário adquirir

uma expansão de modem. Ficaríamos ainda presos a um fabricante e,
além disso, teríamos que passar uma linha telefônica nos locais das
instalações das máquinas.
4. Fazer o acesso remoto utilizando a arquitetura fieldbus já existente

e utilizar tecnologias de internet para a comunicação com o exterior
da empresa.
Vantagens: Não seria necessário nenhuma alteração na instalação

física das máquinas, não seria necessário nenhum dispositivo novo.
Seria uma solução de baixo custo
Desvantagens: Introdução de um novo sistema que pode necessitar

de manutenção.
6
Após a avaliação das soluções propostas, escolhemos a última por se tratar
de uma solução de baixíssimo custo. Para sua implementação, foram escolhidas as
tecnologias mais simples e que nos possibilitassem a troca de fornecedores, sem
comprometer o sistema.
No decorrer deste documento, estaremos descrevendo todas as etapas da

elaboração deste projeto, as quais foram baseadas na metodologia descrita em [ 7 ],
falaremos mais dela em 3.1.3: Metodologia. Iniciaremos pela descrição do produto
para o qual ele foi elaborado, passando pelas tecnologias escolhidas e pelos
padrões utilizados e, finalmente, descrevendo o sistema implementado com os
resultados obtidos.
7
Capítulo 2: Estudo do Produto
A motivação deste trabalho foi resolver o problema de manutenções das

máquinas produzidas pela empresa San Martin. Neste capitulo, vamos descrever,
brevemente, o funcionamento de uma máquina, o BorealMatic 2100, mostrado na
Figura 2-1, a qual foi utilizada para os testes de validação deste projeto. Logo em
seguida, abordaremos o assunto de manutenções.
Figura 2-1: Fulão de Recurtimento e Tingimento BorealMatic 2100
2.1: Fulão de Recurtimento e Tingimento
O fulão de recurtimento e tingimento, batizado de BOREALMATIC, é utilizado

pela indústria coureira em uma das etapas do processo de “fabricação” do couro.
Esta máquina, fabricada inteiramente em aço inoxidável (evita reações com os
produtos utilizados), tem a finalidade de manter o couro em contato com um banho
8
de produtos químicos, com a temperatura controlada, para que este possa ser
recurtido e/ou tingido de acordo com as necessidades do processo.
Este equipamento é dividido internamente em três partes (cestos), conforme a

Figura 2-2, que giram dentro de uma estrutura fixa que faz com que as peles entrem
e saiam do banho, atingindo-se uma boa ação mecânica (necessário para que os
produtos químicos consigam penetrar as peles).
Figura 2-2: Divisão Interna do Fulão
Durante o processo de recurtimento e tingimento, o banho é alterado

inúmeras vezes, seja pela adição de novos produtos, seja pela alteração da
temperatura, ou seja, pelo esgotamento do mesmo. O BorealMatic faz tudo isso,
automaticamente, ou de forma manual. Ele é uma máquina controlada por CLP, que
segue uma receita previamente cadastrada em um computador, que, além da
transferência das receitas para a máquina, também monitora o andamento das
mesmas. Toda a informação trocada entre o CLP e o PC é feita através de uma rede
fieldbus com um protocolo proprietário.
9
Figura 2-3: Vista Posterior do BorealMatic
2.1.1: Automatização
A máquina tem a possibilidade de ser operada, tanto em modo manual,

quanto em modo automático, exigência feita pelo mercado por uma enorme
desconfiança quanto à durabilidade de peças eletrônicas (CLP). Em qualquer um
desses modos o fulão tem a capacidade de fazer os seguintes controles:
- Controle de temperatura:
Em modo automático, o próprio CLP realiza o controle e, em modo

manual, o serviço é feito por um controlador industrial. O método de controle é
On/Off com histerese, utilizando um trocador de calor a vapor (Figura 2-3: E)
e um sensor (Figura 2-1: C) tipo PT100 ligado a um conversor de 4 a 20mA.
- Controle de injeção dos produtos químicos:

10
Em modo automático, o CLP, seguindo a receita cadastrada, controla
um banco de solenóides eletro-pneumáticos (Figura 2-3: C) que manobram as
válvulas pneumáticas de passagem de fluído (Figura 2-3: F), que, por sua
vez, estão conectadas a bicos injetores que ficam submersos em
reservatórios de produtos químicos. Em modo manual, esses solenóides são
acionados por chaves seletoras controladas pelo operador do fulão.
- Controle de velocidade de rotação:
A velocidade de rotação do cesto interno da máquina é controlada por

um inversor de freqüência. Em modo automático, essa velocidade pode variar
durante uma receita, porém no modo manual, a velocidade permanece
constante em um valor pré-definido.
- Controle de volume de entrada de água:
Válvulas pneumáticas (Figura 2-3: G), acionadas por solenóides eletro-

pneumáticos, que são controlados pelo CLP, em modo automático, ou por um
controlador industrial, em modo manual, liberam a entrada tanto de água fria
quanto água quente, de acordo com a necessidade do processo.
- Controle de esgotamento de banho:
Um sistema de esgotamento (Figura 2-3: H), dimensionado para

esvaziar a máquina em cinco minutos, em modo automático, é controlado
pelo CLP, em modo manual, o operador fica encarregado de abri-lo e fechá-
lo, conforme a necessidade do processo.
2.1.2: Interface Local
A programação da máquina pode ser feita de forma local ou remota. De forma

local, o operador precisa entrar com os dados da receita, através de um IHM.
Considerando que, normalmente, o operador é uma pessoa sem capacitação, com
bastante dificuldade de lidar com equipamentos eletrônicos, foi solicitado outra forma
11
de programar a máquina. A solução oferecida para este problema foi a ligação das
máquinas em rede, de forma que um software supervisório se encarregasse da
programação.
2.1.3: Arquitetura da Rede FieldBus
A topologia escolhida foi uma ligação em barramento, utilizando o padrão RS-

485 (multiponto) com uma comunicação do tipo mestre-escravo.
Protocolo Proprietário
Figura 2-4: Arquitetura da Rede Fieldbus
Aproveitando essa instalação já existente, o projeto aqui relatado precisou de

muito pouco investimento, o que facilitou bastante a sua aprovação. O investimento
ficou totalmente por parte da San Martin, pois não mudou em nada a arquitetura do
lado do cliente, como veremos mais adiante.
2.2: Suporte Técnico
Após a venda, um funcionário da empresa acompanha a instalação da

máquina, no local desejado pelo cliente. Esse funcionário faz o que chamamos de
Start-Up da máquina, ou seja, ele realiza todos os procedimentos necessários para
12
que a mesma possa entrar em funcionamento pela primeira vez. Logo em seguida,
solicita-se que uma carga, no caso couro, seja disponibilizada para testes e
regulagens da máquina. Normalmente, pede-se uma carga pequena, pois durante
essa etapa, os operadores ainda não conhecem muito bem o funcionamento da
máquina. O funcionário da San Martin acompanha uma partida inteira, explicando e
demonstrando todo o funcionamento e esclarecendo todas as dúvidas que,
eventualmente, possam aparecer.
Por se tratar de uma máquina que segue uma receita pré-cadastrada, a tarefa
não pára por ai. Depois de ensinar os operadores a trabalharem com a máquina,
tanto em modo manual, quanto em automático, fica faltando, ainda, a parte da
programação. Essa tarefa é realizada junto aos técnicos de couro do curtume, pois
cabe a eles o desenvolvimento das receitas ao qual os couros serão submetidos. É
tarefa do funcionário da empresa mostrar como se programa a máquina com a
receita desenvolvida e não o desenvolvimento da mesma, pois essa normalmente é
um segredo muito bem guardado pelos curtumes. Por fim, um manual de instruções
de manutenção, de operação e de programação é entregue ao cliente, para que
possam ser sanadas todas as futuras dúvidas.
Todo esse envolvimento com a instalação da máquina tem o objetivo de

minimizar os problemas causados pelo mau uso. Qualquer intervenção necessária,
por parte dos técnicos da empresa, gera uma considerável despesa com transporte
e gasta um enorme tempo de viagem, lembrando que essas máquinas são vendidas
para diversas regiões do país e fora dele.
Sempre que possível, tenta-se resolver qualquer problema com o próprio

pessoal do curtume, já que é bastante comum essas empresas possuírem um
departamento de manutenção que abrange diversas áreas como mecânica, elétrica
e informática. As orientações são passadas por telefone, o pessoal da manutenção
passa um diagnostico para os técnicos da San Martin que, por sua vez, conduzem
testes para tentar encontrar o problema e, se possível, passar orientações para que
este possa ser resolvido sem as despesas e, principalmente, sem o tempo gasto em
uma viagem, já que durante esse tempo a máquina ficaria inoperante, causando
enormes prejuízos para o curtume.
13
O sistema de suporte por telefone, boa parte das vezes, deixa de funcionar
por uma dificuldade de entendimento entre quem relata os problemas e quem tenta
solucioná-los, algumas vezes causado pela diferença de idioma, mas,
principalmente, pela falta de capacitação do pessoal da manutenção.
Os curtumes começaram a investir em máquinas automáticas há pouco

tempo, equipamentos controlados por computadores, CLPs, ainda são novidade.
Com isso, os técnicos da manutenção, por não terem o treinamento necessário,
ainda enxergam esses controladores como “caixas preta”. Sendo assim, qualquer
problema, por mais simples que seja, eles entram em contato conosco para serem
orientados. Durante essas orientações por telefone, são solicitados alguns dados,
como por exemplo, o estado de alguma saída do CLP, ou a seqüência em que
algumas luzes se acendem no painel. Porém, muitas vezes os dados são
contraditórios, ou seja, quem os está colhendo não tem segurança do que está
falando, muitas vezes, tem dificuldade para diferenciar as luzes indicativas das
entradas e das saídas do CLP.
Situações como as relatadas anteriormente resultavam em viagens

desnecessárias até o cliente. Já houve casos em que o técnico chegou ao curtume
e, com uma simples alteração de parâmetro, resolveu o “problema”.
Pensando em solucionar esses problemas é que foi sugerida a realização

deste Projeto de Conclusão de Curso.
14
Capítulo 3: Implementação da Solução
Antes de iniciar a execução propriamente dita do sistema, é necessário

elaborar um modelo de seus componentes, de forma que ela se torne mais fácil,
organizada e coesa.
Para sua implementação, era prevista a utilização da linguagem Pascal,

através do ambiente de programação Delphi 7 que segue o modelo orientado a
objetos. Orientação a objetos é uma forma de estruturar um programa, ao invés de
definirmos variáveis e criarmos funções, passando parâmetros entre elas, definimos
objetos que possuem dados e ações associadas. O programa orientado a objetos é
resultado da colaboração entre estes objetos.
Para a elaboração do modelo, utilizamos a linguagem de modelagem UML[ 1

]. A UML - Unified Modeling Language é o resultado do trabalho conjunto dos
maiores metodologistas da atualidade, na tentativa de criar uma notação unificada
para descrever sistemas de software. É uma linguagem de modelagem gráfica para
descrever um projeto de software, que simplifica o complexo processo de análise,
projeto e construção, criando visões do sistema que está sendo construído.
3.1: Padrões Utilizados na Modelagem do Software
O procedimento de modelagem é fundamental para a qualidade final do

software. É quando nós representamos o sistema e todos os seus componentes,
através de modelos abstratos, seguindo uma linguagem de modelagem pré-
determinada.
A seguir, vamos falar com um pouco mais de detalhes sobre a abordagem

escolhida, assim como sobre a linguagem de modelagem a ser seguida. Vamos
mostrar suas definições teóricas, partindo, na seqüência, a metodologia utilizada.
3.1.1: A Análise Orientada a Objeto
O passo inicial para o desenvolvimento de qualquer software é a sua

especificação. Para a realização da especificação de um sistema, este deve ser
15
modelado adequadamente. A análise de um sistema procura identificar a relação
entre os seus componentes, utilizando-se de modelos preconcebidos.
Dentre as diversas formas de análise de sistemas (diagrama de fluxo de

dados, análise funcional, etc) a análise orientada a objeto é uma ferramenta recente
que tem se tornado cada vez mais utilizada. A seguir é apresentada uma breve
introdução ao assunto. Uma revisão aprofundada sobre o assunto pode ser
encontrada em [ 13 ].
A análise orientada a objeto procura modelar as informações de um sistema

de tal forma que dados estejam fortemente ligados às funções que os manipulam. O
conceito básico utilizado é o de classes, onde todos os entes presentes no sistema
são identificados como objetos (instâncias) pertencentes a uma dada classe.
A cada classe são associados atributos e funções (métodos) que manipulam

estes atributos. Normalmente, os atributos são representados por substantivos, ao
passo que os métodos são representados por verbos. A Figura 3-1 mostra, como
exemplo, uma possível definição para a classe TPDU.
TPDU
attributes
- FData: string;
- FExceptionCode: Byte;
- FFunctionCode: Byte;
operations
+ BuildException(..)
+ BuildResponse(..)
+ IsDataCorrect: Byte;
Figura 3-1: Definição da Classe TPDU
As classes são agrupadas em famílias. Dentro de uma mesma família, as

classes estão dispostas em uma hierarquia, que vai de uma classe mais genérica
(classe base) para as mais específicas (derivadas). As classes derivadas podem
herdar os atributos e métodos das classes mais genéricas da mesma família.
16
A relação entre as classes é caracterizada pela seguinte frase: classe
derivada É UM(A) classe genérica. A Figura 3-2 mostra uma hierarquia, onde a
classe TPDU é a base e as classes TADURTU e TADUTCP são derivadas.
TPDU
TADUTCP TADURTU
Figura 3-2: Hierarquia da Família TPDU.
O relacionamento entre classes de famílias diferentes se dá através da

composição. Neste tipo de relação, uma classe mais complexa pode ter, como um
de seus atributos, um elemento de uma classe mais simples. A relação entre as
classes é caracterizada pela seguinte frase: classe composta TEM UM(A) classe
simples. A Figura 3-3 mostra uma classe complexa (TCustomGateway) composta
por outras classes (RTUMaster, TCPClient, TXMLDocument, entre outras).
17
TCustom Gatew ay
FTCPClient FRTUMaster XMLConfigFile
TCPClient RTUMaster TXMLDocum ent
Figura 3-3: Representação Gráfica da Classe Complexa TCustomGateway.
Dentre as vantagens apresentadas pela análise orientada a objeto pode-se

citar:
• proteção dos dados: os atributos de uma determinada classe só podem ser

acessados e modificados por funções pertencentes à referida classe;
• facilidade de manutenção: devido a modularidade característica dos sistemas

orientados a objeto, estes são especificados pelos serviços que prestam e
não pela forma interna como são implementados. Assim, se é interessante
modificar a forma de implementação de uma dada classe (fazer a
manutenção da classe), o funcionamento do sistema não é afetado;
• reutilização: talvez esta seja a grande vantagem da utilização de objetos para

representar um sistema. À medida que vários projetos vão sendo executados,
vai se criando uma biblioteca de classes. A análise de um novo sistema é feita
de uma forma muito mais rápida e organizada, quando já se dispõe de uma
biblioteca de objetos predefinidos que podem ser reutilizados.
18
3.1.2: Diagramas UML
A UML é uma tentativa de padronizar a modelagem orientada a objetos de

uma forma que qualquer sistema, seja qual for o tipo, possa ser modelado
corretamente, com consistência, fácil de se comunicar com outras aplicações,
simples de ser atualizado e compreensível.
Existem várias metodologias de modelagem orientada a objetos, que até o

surgimento da UML causavam uma guerra na comunidade de desenvolvedores. A
UML acabou com esta guerra, trazendo as melhores idéias de cada uma destas
metodologias, e mostrando como deveria ser a migração de cada uma para a UML.
Falaremos sobre algumas das principais metodologias que se tornaram

populares nos anos 90:
• Booch – O método de Grady Booch para desenvolvimento orientado a objetos

está disponível em muitas versões. Booch definiu a noção de que um sistema
é analisado a partir de um número de visões, onde cada visão é descrita por
um número de modelos e diagramas. O Método de Booch trazia uma
simbologia complexa de ser desenhada a mão, continha também o processo,
pelo qual sistemas são analisados por macro e micro visões.
• OMT – Técnica de Modelagem de Objetos (Object Modelling Technique) é um

método desenvolvido pela GE (General Electric) onde James Rumbaugh
trabalhava. O método é, especialmente, voltado para o teste dos modelos,
baseado nas especificações da análise de requisitos do sistema. O modelo
total do sistema baseado no método OMT é composto pela junção dos
modelos de objetos, funcional e use-cases.
• OOSE/Objectory – Os métodos OOSE e o Objectory foram desenvolvidos

baseados no mesmo ponto de vista formado por Ivar Jacobson. O método
OOSE é a visão de Jacobson de um método orientado a objetos, já o
Objectory é usado para a construção de sistemas tão diversos quanto eles
forem. Ambos os métodos são baseados na utilização de use-cases, que
definem os requisitos iniciais do sistema vistos por um ator externo. O método
Objectory também foi adaptado para a engenharia de negócios, onde é usado
19
para modelar e melhorar os processos envolvidos no funcionamento de
empresas.
Cada um destes métodos possui sua própria notação (seus próprios símbolos
para representar modelos orientados a objetos), processos (que atividades são
desenvolvidas em diferentes partes do desenvolvimento), e ferramentas (as
ferramentas CASE que suportam cada uma destas notações e processos).
Diante desta diversidade de conceitos, "os três amigos", Grady Booch, James
Rumbaugh e Ivar Jacobson decidiram criar uma Linguagem de Modelagem
Unificada. Eles disponibilizaram inúmeras versões preliminares da UML para a
comunidade de desenvolvedores e a resposta incrementou muitas novas idéias que
melhoraram ainda mais a linguagem.
O objetivo da UML é descrever qualquer tipo de sistema, em termos de

diagramas orientado a objetos. Naturalmente, o uso mais comum é para criar
modelos de sistemas de software, mas a UML também é usada para representar
sistemas mecânicos sem nenhum software. Aqui estão alguns tipos diferentes de
sistemas com suas características mais comuns:
• Sistemas de Informação: Armazenar, pesquisar, editar e mostrar informações

para os usuários. Manter grandes quantidades de dados com
relacionamentos complexos, que são guardados em bancos de dados
relacionais ou orientados a objetos.
• Sistemas Técnicos: Manter e controlar equipamentos técnicos como de

telecomunicações, equipamentos militares ou processos industriais. Eles
devem possuir interfaces especiais do equipamento e menos programação de
software do que os sistemas de informação. Sistemas Técnicos são,
geralmente, sistemas de tempo real.
• Sistemas de Tempo Real Integrados: Executados em simples peças de

hardware integrados a telefones celulares, carros, alarmes, etc. Estes
sistemas implementam programação de baixo nível e requerem suporte de
tempo real.
20
• Sistemas Distribuídos: Distribuídos em máquinas onde os dados são
transferidos facilmente de uma máquina para outra. Eles requerem
mecanismos de comunicação sincronizados para garantir a integridade dos
dados e, geralmente, são construídos em mecanismos de objetos como
CORBA, COM/DCOM ou Java Beans/RMI.
• Sistemas de Software: Definem uma infra-estrutura técnica que outros

softwares utilizam. Sistemas Operacionais, bancos de dados, e ações de
usuários que executam ações de baixo nível no hardware, ao mesmo tempo
que disponibilizam interfaces genéricas de uso de outros softwares.
• Sistemas de Negócios: descreve os objetivos, especificações (pessoas,

computadores etc.), as regras (leis, estratégias de negócios etc.), e o atual
trabalho desempenhado nos processos do negócio.
É importante perceber que a maioria dos sistemas não possui apenas uma
destas características acima relacionadas, mas várias delas ao mesmo tempo.
Sistemas de informações, de hoje, por exemplo, podem ter tanto características
distribuídas como de tempo real. E a UML suporta modelagens de todos estes tipos
de sistemas.
A UML está destinada a ser dominante, a linguagem de modelagem comum a

ser usada nas indústrias. Ela está totalmente baseada em conceitos e padrões
extensivamente testados, provenientes das metodologias existentes anteriormente,
e, também, é muito bem documentada com toda a especificação da semântica da
linguagem, representada em meta modelos.
3.1.3: Metodologia
O uso de UML define uma forma padrão de representar modelos, entretanto,

é necessário utilizar uma metodologia de desenvolvimento, caso contrário, técnicas
de modelagem ficam sem sentido.
A metodologia escolhida segue as etapas mostrada na figura abaixo.
21
Concepção Elaboração Construção Transição
Figura 3-4: Processo de Desenvolvimento
Este processo é um processo de desenvolvimento iterativo e incremental, no

qual o software não é implementado em um instante no fim do projeto, mas é, ao
contrário, desenvolvido e implementado em partes. A fase de construção consiste
de várias iterações, nas quais cada iteração constrói software de qualidade de
produção, que é testado e integrado, que satisfaz um subconjunto de requisitos de
projeto. A entrega pode ser externa, para usuários iniciais, ou puramente interna.
Cada iteração contém todas as fases usuais do ciclo de vida da análise, do projeto,
da implementação e do teste.
As duas primeiras fases são a concepção e a elaboração. Durante a

concepção, é estabelecida a lógica do domínio da aplicação para o projeto e é
decidido o escopo do projeto. Na elaboração, são coletados os requisitos mais
detalhados, faz-se uma análise e um projeto de alto nível para estabelecer uma
arquitetura básica, e cria-se um plano para a construção do sistema.
Mesmo com este tipo de processo iterativo, algum trabalho tem que ser
deixado para ser feito no fim, na fase de transição. Este trabalho pode incluir teste
beta, ajuste de performance e treinamento de usuário.
3.2: Modbus
3.2.1: Introdução
Modbus é um protocolo da camada de aplicação, posicionado no nível 7 do

modelo OSI, que fornece uma comunicação cliente/servidor entre os dispositivos
conectados em tipos diferentes de redes. É, atualmente, implementado usando os
seguintes padrões [ 3 ]:
• TCP/IP sobre Ethernet;
22
• Transmissão serial assíncrona sobre uma variedade dos meios (fio: RS232,
RS422, RS485; fibra, rádio, etc..);
• MODBUS PLUS, uma rede de passagem de bastão de alta velocidade.
O protocolo Modbus permite uma fácil comunicação dentro de todos os tipos

de arquiteturas de rede.
Figura 3-5: Exemplo de Arquitetura de Rede Modbus
Cada tipo de dispositivos (PLC, HMI, painel de controle, driver, dispositivo de

I/O, ...) pode usar o protocolo Modbus para iniciar uma operação remota. A mesma
comunicação pode ser feita, tanto na linha serial, como em redes tipo Ethernet
TCP/IP. Gateways permitem uma comunicação entre diversos tipos de barramentos
usando o protocolo Modbus.
23
Figura 3-6: Camadas do Modbus
3.2.2: Descrição do Protocolo
O protocolo de Modbus define uma unidade de dados de protocolo simples

(PDU – Protocol Data Unit) independente das camadas subjacentes da
comunicação. O mapeamento do protocolo Modbus no barramento específico pode
introduzir alguns campos adicionais na unidade de dados de aplicação (ADU –
Application Data Unit).
Figura 3-7: Frame Modbus Genérico
A ADU é construída pelo cliente que inicia uma transação. A função indica ao
usuário que tipo da ação executar. O protocolo de aplicação Modbus estabelece o
formato de um pedido iniciado por um cliente.
24
O campo Function Code é codificado em um byte. Os códigos válidos estão
no intervalo de 1 a 255 (128 - 255 reservados para respostas de exceção). Quando
uma mensagem é transmitida de um cliente a um dispositivo servidor, o campo
Function Code diz ao servidor que tipo da ação executar. O código "0" é inválido.
O campo data contém informações adicionais que o servidor usa para

executar a ação definida. Isto pode incluir dados como endereços, quantidade de
dados a serem tratados e a quantidade de bytes no campo.
O campo de dados pode ser inexistente (de comprimento zero) em

determinados tipos dos pedidos, neste caso, o servidor não requer nenhuma
informação adicional, o código da função sozinho especifica a ação.
Se nenhum erro ocorrer, relacionado à função Modbus solicitada, em um ADU

corretamente recebido, o campo de dados da resposta vai conter os dados pedidos.
Se um erro ocorrer, o campo terá o código da exceção que a aplicação do cliente
possa usar para determinar a próxima ação.
Por exemplo, um cliente pode ler os estados de um grupo de saídas ou de

entradas discretas. Quando o servidor responde ao cliente, usa o campo do código
de função para indicar uma resposta normal (sem erros) ou que algum tipo do erro
ocorreu (exceção). Para uma resposta normal, o usuário simplesmente devolve o
código de função original.
Figura 3-8: Transação Modbus sem Erro
25
Para uma resposta de exceção, o servidor retorna um código que seja
equivalente ao código original do pedido com seu bit mais significativo igual a um.
Figura 3-9: Transação Modbus com Erro
O tamanho do PDU é limitado pelo tamanho herdado da primeira

implementação do Modbus sobre linhas seriais (max. RS485 ADU = 256 bytes).
Portanto:
PDU para uma comunicação serial = 256 - endereço do servidor (1 byte) -

CRC (2 bytes) = 253 bytes.
Conseqüentemente:
RS232/RS485 ADU = 253 bytes + endereço do usuário (1 byte) + CRC (2

bytes) = 256 bytes.
TCP ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
3.2.2.1: Modbus sobre TCP/IP
Um cabeçalho dedicado é usado em TCP/IP para identificar o ADU. É

chamado de MBAP - Modbus Application Protocol header [ 4 ].
26
Figura 3-10: ADU sobre TCP/IP
O cabeçalho MBAP possui os seguintes campos:
o Transaction Identifier – Possui 2 bytes de comprimento. É utilizado

para o servidor identificar a qual requisição uma resposta se refere. O
cliente simplesmente copia o campo, quando vai montar a mensagem
de resposta.
o Protocol Identifier – Possui 2 bytes de comprimento. É utilizado para

a interconexão de sistemas com protocolos diferentes, o valor “0”
(zero) identifica o protocolo Modbus.
o Length – Possui 2 bytes de comprimento. Carrega a informação sobre

a quantidade de dados que vem a seguir.
o Unit Identifier – Possui 1 byte de comprimento. É utilizado para

roteamento entre sistemas. É tipicamente utilizado para permitir o
acesso a um “escravo” de uma linha serial, através de um gateway
entre uma rede Ethernet TCP/IP e Modbus serial line. Este campo é
preenchido pelo cliente em uma requisição e deve ser retornado com o
mesmo valor na resposta do servidor.
3.2.2.2: Modbus sobre Linhas Seriais
Este protocolo ocorre no nível 2 do modelo OSI.
Um sistema do tipo mestre-escravo tem um nó (o nó mestre) que é

responsável por dar início a todas as transações. Os nós escravos jamais
transmitirão dados sem um pedido do nó mestre, e não se comunicarão com outros
escravos [ 5 ].
27
A figura abaixo mostra uma comparação das camadas do protocolo Modbus,
em relação ao modelo ISO/OSI.
Figura 3-11: Protocolo Modbus e o Modelo ISO/OSI
A camada de aplicação do protocolo Modbus, posicionado no nível 7 do

modelo de OSI, fornece uma comunicação cliente/servidor entre os dispositivos
conectados em redes. Na linha serial, o papel do cliente é fornecido pelo mestre do
barramento e os nós dos escravos agem como clientes.
O Mapeamento do protocolo de Modbus em um barramento ou em uma rede

específica introduz alguns campos adicionais no PDU - Protocol Data Unit. O cliente
que inicia uma transação constrói o PDU e adiciona, então, campos a fim construir o
PDU apropriado para comunicação.
Figura 3-12: PDU sobre Linha Serial
O campo Address Field contém apenas o endereço do “escravo”, os valores

podem variar entre 1 e 247, o 0 fica reservado para mensagens do tipo broadcast.
Os campos Function Code e Data já foram descritos anteriormente 3.2.2: Descrição
do Protocolo.
28
O campo CRC é resultado do cálculo de Redundancy Checking aplicado no
conteúdo da mensagem. Seu comprimento é de 16 bits.
3.2.3: Formato dos Dados
Modbus usa uma representação do tipo big-Endian para os endereços tanto

quanto para os dados. Isto significa que quando uma quantidade numérica maior do
que um único byte é transmitido, o byte o mais significativo é transmitido primeiro.
Por exemplo:
Valor: 0x1234 (Hex), primeiro é enviado 0x12, depois 0x34.
3.2.4: Modelo de Dados
Modbus baseia seu modelo de dados em uma série de tabelas que têm
características distintas. As quatro tabelas principais são:
Tabela Tipo de Dado Tipo de Acesso
Entradas Discretas 1 bit Leitura

Discretes Inputs
Bobinas 1 bit Leitura / Escrita
Coils
Registradores de Entradas 16 bits Leitura
Input Registers
Registradores 16 bits Leitura / Escrita
Holding Registers
Para cada uma das tabelas, o protocolo permite uma seleção individual de
65536 posições de dados, e as operações de leitura ou escrita desses dados são
projetadas para trabalhar com dados consecutivos, até um limite que depende do
código da função.
3.2.5: Modelo de Endereçamento
O protocolo de aplicação define precisamente as regras de endereçamento do

PDU.
Em um PDU Modbus cada dado é endereçado de 0 a 65535.
29
Define também um modelo dos dados composto de 4 blocos que compreende
diversos elementos numerados de 1 a n.
O pré-mapeamento entre o modelo de endereçamento Modbus e o dispositivo

é totalmente dependente do fabricante.
Figura 3-13: Modelo de Endereçamento Modbus
3.2.6: Transação Modbus
A Figura 3-14 mostra uma transação genérica vista e processada pelo lado do
servidor.
30
Figura 3-14: Fluxograma de uma Transação
Uma vez que a requisição tenha sido processada pelo servidor, uma resposta
tem que ser enviada para o cliente. Dependendo do resultado do processamento,
dois tipos de respostas podem ser construídas:
• Uma resposta positiva
O campo código da função fica inalterado na resposta.
• Uma resposta de exceção
31
- O campo código da função tem seu bit mais significativo “setado”;
- O objetivo é prover para o cliente informações relevantes sobre o erro

detectado durante o processamento;
- Um código de exceção é enviado junto com a resposta para indicar a causa

do erro.
3.2.7: Funções Implementadas
Foram implementadas apenas funções de leitura e escrita de dados, funções

mais elaboradas, do tipo diagnostico e outras, não foram. Isto se deve ao fato que a
biblioteca de funções adquirida junto ao fabricante do CLP implementava apenas
estas, ou seja, foram implementadas todas as funções que a biblioteca
implementava.
• Leitura de Saídas Digitais (0x01):
Esta função é usada para ler de 1 a 2000 status contínuos de saídas digitais
de um dispositivo remoto. O PDU do pedido especifica o endereço inicial, isto é o
endereço da primeira saída especificada, e da quantidade desejada.
Os valores das saídas na mensagem de resposta são agrupados em BYTES.

O status é indicado como 1 = Ativada e 0 = Desativada. O LSB do primeiro byte de
dados contém a saída referenciada na requisição. Os outros bits seguem para a
extremidade da ordem elevada deste byte, e da ordem baixa à ordem elevada em
bytes subseqüentes.
Se a quantidade retornada de saídas não for um múltiplo de oito, os bits

restantes no byte de dados final estarão preenchidos com zero (para o fim da ordem
elevada do byte). O campo de contagem do byte especifica a quantidade de bytes
completos dos dados.
Requisição:
Função 1 Byte 0x01
32
Endereço Inicial 2 Bytes 0x0000 a 0xFFFF
Quantidade 2 Bytes 1 a 2000 (0x7D0)
Resposta:
Contagem de Bytes 1 Byte Quantidade / 8
Status dos Bits n Bytes
Erro:
Código de Exceção 1 Byte 1 ou 2 ou 3 ou 4
• Leitura de Entradas Discretas (0x02):
Esta função é utilizada exatamente da mesma forma que a função descrita

anteriormente, a única diferença é que retorna o valor das entradas digitais do
dispositivo.
Requisição:
Quantidade 2 Bytes 1 a 2000 (0x7D0)
Resposta:
33
Contagem de Bytes 1 Byte Quantidade / 8
Status das Entradas n Bytes
Erro:
• Leitura de Registros (0x03):
Esta função é utilizada para ler registros em um dispositivo remoto. O PDU do

pedido especifica o endereço inicial do registro e a quantidade desejada. No PDU os
registros são endereçados a partir do zero. Conseqüentemente os registros
numerados 1-16 são mapeados como 0-15.
Os dados da mensagem de resposta são empacotados em dois bytes por

registro. Para cada registro, o primeiro byte contém os bits mais significativos e o
segundo contém os bits menos significativos.
Requisição:
Quantidade 2 Bytes 1 a 125 (0x7D)
Resposta:
Contagem de Bytes 1 Byte 2xn
Erro:
34
• Leitura de Registradores de Entradas (0x04):
Esta função é utilizada exatamente da mesma forma que a função descrita

anteriormente, a única diferença é que retorna os valores dos registros de entradas
do dispositivo, no caso do CLP siemens que foi utilizado neste trabalho, retorna os
valores das entradas analógicas.
Requisição:
Quantidade 2 Bytes 1 a 125 (0x7D)
Resposta:
Contagem de Bytes 1 Byte 2xn
Erro:
• Escrita de Saída Digital (0x05):
Esta função é usada para comandar uma única saída em um dispositivo

remoto, tanto para ativar quanto para desativar.
A definição do estado da saída ON/OFF é definido por uma constante na

requisição. Um valor 0xFF seguido 0x00 pede para ativar a saída. Um valor 0x00
35
seguido de outro 0x00 determina que é para desativar a saída. Caso o valor enviado
na requisição seja diferente, o estado da saída permanece inalterado.
O PDU do pedido especifica o endereço da saída a ser forçada. Elas são

endereçadas a começar pelo endereço zero. Conseqüentemente a saída com
endereço 1 é mapeada como 0. A resposta normal é um eco do pedido, retornado
depois que o estado da saída for escrito.
Requisição:
Endereço da Saída 2 Bytes 0x0000 a 0xFFFF
Valor 2 Bytes 0x0000 ou 0xFF00
Resposta:
Endereço da Saída 2 Bytes 0x0000 a 0xFFFF
Valor 2 Bytes 0x0000 ou 0xFF00
Erro:
• Escrita de Registro (0x06):
Esta função é utilizada para escrever um valor em um único registro. Na

requisição vai indicado o endereço e o valor a ser escrito. A resposta normal é
apenas um eco da requisição, assim que o valor tiver sido alterado no dispositivo.
Requisição:
36
Endereço do Registro 2 Bytes 0x0000 a 0xFFFF
Valor 2 Bytes 0x0000 a 0xFF00
Resposta:
Endereço do Registro 2 Bytes 0x0000 a 0xFFFF
Valor 2 Bytes 0x0000 a 0xFF00
Erro:
• Escrita de Múltiplas Saídas Digitais (0x0F):
Esta função é usada para forçar cada saída em uma seqüência, tanto para
ativar quanto para desativar, em um dispositivo remoto. O PDU da requisição
especifica o endereço inicial e a quantidade de saídas a serem forçadas.
Os estados ON/OFF de cada saída são especificados pelo conteúdo do

campo de dados. Nível lógico 1 em uma posição de bit do campo pede para a saída
correspondente ser ativada. Nível lógico 0 pede para desativá-la. A resposta normal
retorna o código da função, o endereço inicial e a quantidade de saídas forçadas.
Requisição:
37
Função 1 Byte 0x0F
Quantidade de Saídas 2 Bytes 0x0000 a 0x07B0
Quantidade de saídas /
Quantidade de Bytes 1 Byte
8
Valores n Bytes
Resposta:
Quantidade de Saídas 2 Bytes 0x0000 a 0x07B0
Erro:
• Escrita de Múltiplos Registradores (0x10):
Esta função é utilizada para escrever de 1 a 120 registros com endereços

contínuos em um dispositivo remoto.
Os valores requisitados para serem escritos vêm no campo de dados, eles

são empacotados em dois bytes por registro.
Uma resposta normal retorna o código da função, o endereço inicial e a

quantidade de registros escritos.
Requisição:
38
Quantidade de Registros 2 Bytes 0x0000 a 0x0078
Quantidade de Bytes 1 Byte 2xn
Valores n Bytes
Resposta:
Quantidade de Registros 2 Bytes 0x0000 a 0x0078
Erro:
3.3: Web Services
3.3.1: Contextualização
Os Web Services são uma tecnologia emergente, sobre a qual muito se tem
especulado. Uns apontam-na como o caminho a seguir no desenvolvimento de
aplicações distribuídas, enquanto outros vêm nelas apenas mais uma evolução de
um conceito antigo [ 11 ], [ 12 ].
Sendo aplicações modulares, auto-descritivas, acessíveis através de um URL,

independentes das plataformas de desenvolvimento e que permitem a interação
entre aplicações sem intervenção humana, os Web Services apresentam-se como a
solução para os atuais problemas de integração de aplicações.
39
Estas suas características devem-se, em grande parte, ao fato de se
basearem em normas “Standard”, dentre as quais se destacam: XML, SOAP, WSDL
e UDDI.
Segue-se uma breve descrição das funcionalidades de cada uma destas

normas:
• XML - metalinguagem de anotação na qual estão definidas todas as outras

normas que servem de base aos Web Services.
• SOAP - linguagem de anotação com a qual se pode descrever o protocolo de

comunicação, responsável pela troca de mensagens de e para os Web
Services (uma mensagem SOAP é um documento XML).
• WSDL - linguagem de anotação definida em XML e que tem como objetivo

descrever a API de um Web Service.
• UDDI - linguagem de anotação definida em XML com a qual se cria a meta

informação característica de um Web Service; vários registros UDDI são
agrupados em repositórios; estes repositórios possuem uma interface/API de
pesquisa para permitir a uma aplicação cliente pesquisar e localizar um
serviço.
3.3.2: Arquitetura de Funcionamento
O ciclo de vida de um Web Service compreende quatro estados distintos:

Publicação, Descoberta, Descrição e Invocação.
Publicação: Processo, opcional, através do qual o fornecedor do Web

Service dá a conhecer a existência do seu serviço, efetuando o registro do mesmo
no repositório de Web Services (UDDI).
Descoberta: Processo, opcional, através do qual uma aplicação cliente toma

conhecimento da existência do Web Service pretendido, pesquisando num
repositório UDDI.
Descrição: Processo pelo qual o Web Service expõe a sua API (documento
WSDL); desta maneira a aplicação cliente tem acesso a toda a interface do Web
Service, onde se encontram descritas todas as funcionalidades por ele
40
disponibilizadas, assim como os tipos de mensagens que permitem aceder às ditas
funcionalidades.
Invocação: Processo pelo qual cliente e servidor interagem, através do envio

de mensagens de input e de eventual recepção de mensagem de output.
A cada um destes estados corresponde uma das normas anteriormente

referidas, nomeadamente:
Publicação, Descoberta Æ UDDI;
Descrição Æ WSDL;
Invocação Æ SOAP.
A conjugação destes quatro estados permite constituir o ciclo de vida de um

Web Service, o qual passamos a descrever:
1. O fornecedor constrói o serviço utilizando a linguagem de programação

que entender;
2. Em seguida, especifica a interface/assinatura do serviço que definiu em

WSDL;
3. Após a conclusão dos dois primeiros passos, o fornecedor registra o

serviço no UDDI;
4. O utilizador (aplicação cliente) pesquisa num repositório UDDI e

encontra o serviço;
5. A aplicação cliente estabelece a ligação com o Web Service e

estabelece um diálogo com este, via mensagens SOAP.
41
Figura 3-15: Ciclo de Vida de um Web Service
3.4: Generalização da Solução
Inicialmente, foi pensado em simplesmente resolver o problema de acessar os

controladores das máquinas, remotamente, ou seja, criar algumas aplicações que
tornassem possível o acesso a regiões de memória do mesmo, de forma que
viabilizasse um diagnóstico do estado da máquina sem a necessidade do auxilio dos
técnicos de manutenção e, principalmente, sem a necessidade de estar presente no
mesmo local em que o equipamento estivesse instalado. Para essa implementação,
uma arquitetura como a da Figura 3-16 seria suficiente.
42
Figura 3-16: Arquitetura Simplificada
Um PC (servidor) seria designado a fazer o papel de mestre em uma rede

fieldbus multiponto, através do protocolo proprietário já utilizado. Este PC
disponibilizaria seus serviços em um servidor web, através de web service. Outro PC
(cliente), localizado na empresa que faria o diagnóstico, solicitaria o serviço
disponibilizado e o servidor web “fecharia” a conexão, ou seja, faria o papel de uma
ponte.
Durante a elaboração da proposta do projeto, surgiu o interesse da empresa

de alterar o protocolo de comunicação proprietário para um protocolo aberto. Diante
dos requisitos de compatibilidade com as instalações de máquinas que já estavam
operando e da simplicidade requerida para as tarefas em que o protocolo seria
empregado, escolhemos o padrão Modbus.
Visando a utilização deste projeto não apenas para esta aplicação, alteramos
a arquitetura do modelo de forma que a nossa ambição deixou de ser a
implementação de um sistema para a comunicação remota com um CLP e se tornou
a implementação de um sistema para interconexão de redes Modbus.
43
(1)
Cliente
ModBUS TCP (6)
CLP
ModBUS TCP
(2)
Gateway 1:
Servidor ModBUS TCP/
Cliente WebService
(5) CLP
RS232
RS485
Gateway 3:
Servidor ModBUS TCP / CLP
Cliente ModBUS RTU
(3)
(4)
WebService
Seridor
WebServices CLP
Gateway 2:
Servidor WebService /
Cliente ModBUS TCP
Figura 3-17: Arquitetura do Sistema
Com esta arquitetura, é possível que um supervisório possa se comunicar

com uma máquina que não esteja na mesma rede em que ele se encontra, e, ainda
por cima, não é necessário alterar nenhuma configuração deste supervisório. Ele vai
fazer a comunicação endereçando a mensagem a um gateway (Gateway 1) da rede
local, este vai redirecionar a mensagem para o servidor web específico, onde já
estará disponibilizado um gateway (Gateway 2) que colocará a mensagem na rede,
onde ela será tratada como uma mensagem Modbus qualquer. A resposta
percorrerá o caminho inverso até chegar ao supervisório que desencadeou estas
operações. Portanto, o supervisório se comunicou com uma máquina remota da
mesma forma que faria para se comunicar com uma máquina local.
3.5: Componentes do Sistema
Conforme podemos ver na Figura 3-17, para a implementação do sistema

foram desenvolvido os seguintes itens:
• Um programa supervisório (1);
• Um gateway Modbus TCP / Web Service (2);
44
• Uma aplicação de Web Service (3);
• Um gateway Web Service / Modbus TCP (4);
• Um gateway Modbus TCP / Modbus RTU (5);
• Um servidor de Modbus RTU (6);
3.5.1: Supervisório
O programa de supervisão tem a função de interface entre a máquina e o

usuário; é através dele que o técnico poderá visualizar o estado do equipamento e
fazer intervenções como acionar uma saída, alterar o valor de alguma variável,
podendo assim, conduzir testes e verificar seus resultados.
(1)
Cliente
ModBUS TCP
ModBUS TCP
(2)
Gateway 1:
Cliente WebService
Figura 3-18: Comunicação do Supervisório
Como mostrado na Figura 3-18, o supervisório é um cliente Modbus, ele fará

parte de uma rede TCP/IP, e fará sua requisição de leitura ou escrita, utilizando
comandos do protocolo Modbus. Essas mensagens serão endereçadas ao Gateway
1. Este se encarregará de entregar a requisição a máquina e trazer a resposta de
volta. A separação física do cliente (1) e do Gateway (2) não é obrigatória, eles
poderão estar localizados no mesmo computador.
A interface desse programa deverá permitir uma fácil visualização dos valores
desejados, será priorizada a praticidade de utilização e não diminuir a complexidade
do seu uso, lembrando que esse software será utilizado pelos técnicos que farão o
suporte, ou seja, pessoas com treinamento. Abaixo segue uma tela do software
desenvolvido.
45
Figura 3-19: Software Supervisório
Podemos notar que toda a interação do usuário com o programa se dá

através de uma grade [ 1 ] , basta que sejam colocados os endereços referentes às
posições de memória desejadas que o programa mantém os valores atualizados. Na
parte mais a esquerda inferior da tela existem algumas configurações do protocolo
Modbus e um parâmetro de intervalo de tempo para que os valores sejam
atualizados. Na parte inferior, estão disponíveis algumas informações com relação à
dinâmica das comunicações, tais como a quantidade de transações pendentes, o
tempo médio que tem demorado para atualizar todos os campos, assim como a
quantidade de erros que ocorreram.
3.5.2: Gateways Modbus TCP e Web Service
Gateways são elementos de interconexão de redes. A sua importância no que

diz respeito às necessidades de interconexão de redes é o fato de que nem todas as
46
redes de comunicação implantadas e em funcionamento, atualmente, foram
construídas com base no modelo OSI, muitas soluções proprietárias e “padrões de
fato” são adotados na forma de redes locais [ 10 ].
Isto significa que está longe do incomum a necessidade de interligação de

redes baseadas no modelo OSI com redes não OSI. Isto requer, então, a construção
de um equipamento de interconexão que seja capaz de compatibilizar as diferenças
estruturais e de protocolo existente entre as duas redes. Este equipamento é o
gateway.
Os gateways são elementos que devem possuir dois “stacks” de protocolos,

um sendo baseado na arquitetura de 7 camadas do modelo OSI e o outro, baseado
na arquitetura considerada, como o exemplo da figura abaixo.
Figura 3-20: Camadas de um Gateway
Na implementação do nosso projeto, foram desenvolvidos dois tipos de

gateway, um para a interconexão dos protocolos Modbus Serial com Modbus TCP e
outro para a interconexão de Modbus TCP com o protocolo proprietário que utiliza
serviços web.
47
(2)
Gateway 1:
Cliente WebService
ce
WebServi
Internet
(3)
(4)
WebService
Seridor
WebServices
Gateway 2:
Cliente ModBUS TCP
Figura 3-21: Sistema de Gateways Modbus TCP e Web Service
A principal razão para esta arquitetura ter sido escolhida, foi que ela soluciona
o problema do Gateway 1 não saber o endereço do Gateway 2 e vice-versa. Ela
elimina a necessidade dos gateways estarem instalados em máquinas com IP
válidos para a internet. Apenas o servidor possui um IP válido, ele fica instalado em
um servidor convencional de paginas web. Outra razão foi a simplicidade da
instalação do Gateway 2 que ficará instalado na empresa cliente. Aproveitando-se
das vantagens da tecnologia de Web Service, tais como o uso da porta 80 e o
protocolo HTTP, não é necessário alterar as configurações dos firewalls que
protegem essas empresas. Não seria muito útil desenvolver um programa para
auxilio à manutenção de máquinas, se a manutenção desse programa fosse mais
problemática que a das próprias máquinas. Outro fator decisivo para a escolha
dessa tecnologia foi que a empresa San Martin já possuía um contrato com a
empresa provedora de internet Terra e não estava disposta a alterá-lo. O contrato
tratava do uso de um servidor comum, ou seja, apenas com a porta 80 liberada para
alguma aplicação, impossibilitando a implementação de outro protocolo que não
fosse os já previstos pelo servidor.
Web Services apresentaram uma enorme vantagem quanto a sua instalação

e se encaixaram perfeitamente quanto à restrição da porta, porém, por se tratar de
um protocolo do tipo “request / reply”, sua implementação não pode ser trivial.
Surgiu, então, o seguinte problema, “Como transformar dois clientes, do modelo
48
cliente / servidor, em um cliente e outro servidor?” [ 9 ]. A solução foi implementada
no programa do servidor de web service, como mostrado na Figura 3-22.
: Gatew ay2 : Servidor : Gatew ay1
Disponibiliza Serviço (msg)

Solicita Serviço (msg)
Responde (msg)
Figura 3-22: Diagrama Request / Reply
O Gateway 2 faz o papel do servidor, ou seja, ele realiza uma chamada

convencional de web service para o servidor. Este, utilizando métodos de
sincronismo para aplicações concorrentes [ 6 ], suspende a linha de execução que
fez a chamada, aguardando uma solicitação para este serviço recém disponibilizado.
O Gateway 1, por sua vez, assim que receber uma solicitação de leitura ou
escrita pelo protocolo Modbus, faz a conversão e também realiza uma chamada
remota através de web service. No momento em que o servidor recebe a solicitação,
ele verifica se o serviço foi disponibilizado. Caso afirmativo, ele suspende também a
execução da solicitação. Utilizando compartilhamento de memória, os parâmetros da
solicitação são passados para a linha de execução que havia disponibilizado o
serviço, para que sejam retornados ao Gateway 2.
Com a chegada do retorno da função que disponibilizou o serviço, o Gateway

2 converte esses parâmetros para uma requisição do tipo Modbus e realiza uma
transação neste protocolo. Assim que obtiver uma resposta, novamente ele
transforma a resposta Modbus em parâmetros para serem utilizados em outra
chamada remota. O Gateway 2 envia a resposta de volta para o servidor, assim, ele
49
termina suas obrigações com esta transação, podendo encerrar sua execução ou
continuar disponível.
A conclusão da transação se dá no momento em que o servidor recebe a

resposta do Gateway 2 e a encaminha para o Gateway 1, e este, por fim, faz a
conversão de protocolo para Modbus e envia a resposta para o supervisório que fez
a requisição.
3.5.2.1: Gateway 1
O Gateway 1 faz o papel de servidor para o protocolo Modbus e de cliente

para as chamadas web services. Como visto anteriormente, quando ele faz a
chamada remota Solicita Serviço, ele espera que este serviço já esteja
disponibilizado.
O protótipo da função de solicitação de serviço é mostrado a seguir:
function SolicitaServico(var Buffer: String; const Nome, Host: String;

const Port: Integer; const TimeOut: Cardinal): Integer; stdcall;
Onde,
o Buffer: Campo que armazena a requisição Modbus.
o Nome: Nome é o identificador do serviço disponibilizado, inicialmente

está sendo usado o nome do curtume onde o programa está instalado.
o Host e Port: Parâmetros do protocolo TCP/IP que serão utilizados pelo

protocolo Modbus. Estes dois parâmetros não são obrigatórios, como
veremos adiante, eles podem ser preenchidos pelo Gateway 2.
o TimeOut: Tempo máximo para que a transação seja concluída antes

que o servidor retorne uma mensagem de erro.
Esses valores, que devem ser preenchidos para a realização da chamada

remota, não podem vir do supervisório, lembrando que este se comunica através do
protocolo Modbus TCP e que o nosso objetivo era tornar a implementação a mais
genérica possível, ou seja, que qualquer supervisório pudesse utilizar esses
gateways. Isso implica em fazer com que eles funcionem com comandos Modbus
convencionais.
50
A solução para esse problema foi criar tabelas nos gateways. O supervisório
vai fazer uma requisição convencional, com o endereço TCP/IP e porta do gateway e
utilizará o campo Unit Identifier explicado em 3.2.2.1: Modbus sobre TCP/IP para
identificar o dispositivo que ele deseja acessar. Esse campo será o índice da tabela
onde estará cadastrado o restante dos dados necessários.
Para entender melhor quais os dados são realmente necessários para cada
etapa do processo de roteamento da mensagem, vamos recordar a Figura 3-17.
Vamos supor que o cliente (1) deseje endereçar a mensagem para o CLP instalado
na primeira máquina (6). Para isso acontecer, o supervisório deverá conhecer o
endereço IP e a porta do Gateway 1. Esta mensagem chegará até o Gateway 2 por
meio do parâmetro Nome. Este gateway então, deverá encaminhar a mensagem
para o Gateway 3, para tanto, o endereço IP e a porta deste gateway são
necessários. Para ele decidir qual das máquinas a mensagem deve ser
encaminhada, o parâmetro Unit Identifier será utilizado. Portanto, na tabela do
Gateway 1 deverão constar os seguintes dados referentes ao destino desejado:
- Nome do serviço (Nome);
- Endereço IP do destino (Host); opcional
- Porta do destino (Port); opcional
- Endereço da Sub-rede(Unit Identifier – dentro do ADU);
O Gateway 1, ao receber a solicitação do supervisório, verifica se o Unit

Identifier está cadastrado em sua tabela. Caso afirmativo, ele substitui este valor
pelo que consta em seus dados e preenche o resto dos parâmetros necessários
para a função de solicitação de serviço. Caso contrário, retorna ao supervisório uma
mensagem Modbus de exceção, indicando o erro ocorrido.
3.5.2.2: Servidor de Web Service
O servidor foi desenvolvido para rodar sobre o IIS da Microsoft, pois era o
servidor que já estava contratado. Apenas uma alteração teve que ser feita com
relação ao serviço contratado junto à provedora, a criação de um endereço que
apontasse para um servidor específico.
51
O contrato assinado com a empresa Terra, previa que as páginas web da San
Martin ficassem armazenadas em servidores redundantes, ou seja, quando alguém
tenta acessar as páginas da empresa, os roteadores direcionam para o servidor que
tiver menos tráfego no momento. Porém, para a nossa aplicação isso não pode
acontecer, pois se o Gateway 2 disponibilizar um serviço em um servidor e quando o
Gateway 1 for utilizá-lo “cair” em outro servidor, a aplicação responderá para o
Gateway 1 que o serviço não está disponível. Portanto, foi necessária a criação de
um endereço que apontasse para um único servidor, esse endereço então, é
utilizado tanto pelo Gateway 1 quanto pelo Gateway 2.
Para a implementação deste servidor, foi utilizado todo o suporte fornecido

pelo ambiente de programação. O programa foi escrito para rodar no Servidor Web,
da mesma forma como se fosse rodar no PC. Todas as complicações ficaram
transparentes para o programador [ 2 ].
3.5.2.3: Gateway 2
O Gateway 2 faz o papel de servidor para as chamadas remotas e cliente

para o protocolo Modbus. Em primeiro lugar, é necessário disponibilizar o serviço
junto ao servidor, isto é feito através da chamada remota Disponibiliza Serviço, em
seguida, para responder a uma eventual solicitação, utiliza-se a chamada Responde
Serviço.
function DisponibilizaServico(out Buffer: String; const Nome: String; out

Host: String; out Port: Integer; out Index: Integer): Integer; stdcall;
Onde,
• Buffer: Campo por onde retornará a requisição Modbus.
• Nome: Identificador do serviço a disponibilizar.
• Host: Campo que retornará o endereço IP do servidor que o Gateway

1 deseja se comunicar.
• Port: Campo que retornará o número da porta pela qual deverá ocorrer
a conexão com o Host, descrito anteriormente. Lembrando que a porta
padrão a ser utilizada pelo protocolo Modbus é a 502, mas por
52
recomendação feita pelo manual do protocolo, deve ser possível se
conectar, através de outra, se necessário.
• Index: Campo de identificação da transação, ele é gerado pelo

servidor.
Todos esses campos, com exceção do Nome, são parâmetros de retorno, ou

seja, na hora de chamar esta função, eles não devem ser preenchidos.
O Gateway 2 disponibiliza o serviço junto ao servidor e fica “travado”,

aguardando o retorno da função. Quando esta chega, ele deve tratar a mensagem
antes de encaminhá-la para o destino desejado. Se nos recordarmos da chamada
feita pelo Gateway 1, a solicitação de serviço, foi mencionado que os parâmetros
Host e Port não são obrigatórios, isso vem do fato que o Gateway 2 também tem
uma tabela com máquinas cadastradas.
O uso de uma tabela por parte do Gateway 2 não era imprescindível, ele foi
criado com o intuído de deixar o sistema mais flexível, vejamos um exemplo.
Imagine que o sistema já esteja implantado, ou seja, os três gateways instalados e
configurados e já existe uma máquina cadastrada na tabela do Gateway 1. Caso o
computador onde estivesse instalado o Gateway 3 estragasse, e este tivesse que
ser instalado em outra máquina, sem uma tabela no Gateway 2, o Gateway 1
deveria ser informado desta alteração, para que fossem feitas as correções em sua
tabela. Já com o uso da tabela no Gateway 2, isto não é necessário, o próprio
Gateway 2 se encarregará de reendereçar a mensagem sem o conhecimento de
quem fez a solicitação do serviço.
A resposta da solicitação é feita através da função mostrada abaixo:
function RespondeServico(const Buffer, Nome: String; const Index:

Integer): Integer; stdcall;
Onde,
• Buffer: Campo que contém a mensagem do protocolo Modbus.
• Nome: Nome do serviço que está sendo respondido.
• Index: Número que identifica a qual transação do serviço a resposta se

refere.
53
Após a implementação do sistema de gateways, alguns testes começaram a
ser realizados, porém os resultados mostraram uma falha na abordagem, uma
“serialização” excessiva das mensagens, havia um “gargalo” no sistema.
: Supervisorio : Gatew ay1 : ServidorWeb : Gatew ay2 : Servidor
Disponibiliza
Req1 Solicita(Req1)
Req2 (Req1)
Solicita(Req2) Req1
Responde(Req1)
(Req1)
(Req1) Disponibiliza
(Req2)
Req2
Responde(Req2)
(Req2) (Req2)
Figura 3-23: Serialização Excessiva
Se olharmos com atenção o exemplo da Figura 3-23, podemos notar, na troca

de mensagens entre o ServidorWeb e o Gateway 2, que este gateway finaliza uma
transação antes de dar início a outra, ou seja, ele primeiro chama o método remoto
Responde (Req1) antes do segundo Disponibiliza. Isso ocorre porque, inicialmente,
o Gateway 2 foi projetado como uma aplicação com apenas uma linha de execução
para esta tarefa, porém, como foi mencionado antes, os testes não foram
satisfatórios, sendo assim, ele teve que ser reprojetado para trabalhar com múltiplas
linhas de execução. Veremos a diferença na figura abaixo.
54
: Supervisorio : Gatew ay1 : ServidorWeb : Gatew ay2 : Servidor
Disponibiliza
Req1 Solicita(Req1)
Req2 (Req1)
Solicita(Req2) Req1
Disponibiliza
(Req2)
Req2
(Req1) Responde(Req1)
(Req1)
Responde(Req2)
(Req2)
(Req2)
Figura 3-24: Serialização Minimizada
Podemos notar, agora, que a primeira coisa que o Gateway 2 faz, após
receber uma requisição, é disponibilizar outra. Essa alteração mostrou-se bastante
eficiente para conexões rápidas com a internet, quanto mais rápida a internet e
quanto mais lento o Servidor, mais eficiente se mostra a solução. Ao passo que,
quando o tempo do tráfego da mensagem pela internet for muito maior que o tempo
de resposta do servidor, o desempenho desta solução acaba se tornando igual ao da
anterior.
Disponibiliza Trata
Serviço Requisição
Recebe Responde
Requisição Serviço
Requisição de
Encerramento
Figura 3-25: Diagrama de Atividades do Gateway 2
55
A figura acima evidencia a forma como são criadas novas threads para cada
requisição de serviço.
Como podemos perceber, o problema da serialização ainda existe, uma vez

que a função de disponibilizar um serviço precisa retornar, antes que outra possa ser
chamada, porém os resultados obtidos foram satisfatórios.
3.5.3: Gateway Modbus TCP / Modbus RTU
(5) (6)
CLP
ModBus TCP
RS232
RS485
(4)
ModBUS RTU
Gateway 3:
Servidor ModBUS TCP /
Cliente ModBUS RTU
CLP
Gateway 2:
Cliente ModBUS TCP
Figura 3-26: Gateway Modbus TCP / Modbus RTU
O Gateway 3 tem a função de converter o protocolo Modbus TCP para o

Modbus RTU e vice-versa. A figura acima mostra, também, a necessidade de outra
conversão de protocolos, mas essa se dá na camada 1 do modelo ISO/OSI, a
conversão do padrão RS232 (comumente encontrados em PCs) para RS485. Não
vamos entrar em detalhes sobre estes padrões, vamos apenas citar algumas
vantagens do RS485, padrão escolhido para a rede de chão de fábrica [ 10 ].
• Ligação multiponto;
• Transmissão por sinal diferencial (maior imunidade a ruído);
• Maior alcance (pode chegar a 1200m);
• Maior velocidade de transmissão.
Apesar de já existirem várias implementações de programas e componentes

para realizarem a tarefa desse gateway no mercado, achamos melhor desenvolvê-lo
nos mesmos. As empresas que os comercializam cobram valores que consideramos
56
desnecessários que fossem pagos e os freeware, encontrados na internet, não
sabíamos se poderíamos confiar.
Por fim, a última parte que faltava para completar o sistema era o
desenvolvimento do firmware para a comunicação sobre o protocolo Modbus RTU.
Para isso utilizamos bibliotecas fornecidas pelo fabricante do CLP, nesse projeto foi
utilizado o CLP da marca Siemens, da série SIMATIC S7200, modelo 226XM [ 8 ].
3.6: Implementação do Gateway
O sistema é composto por três gateways distintos, todos eles já foram

discutidos em capítulos anteriores. Optamos pela implementação de apenas um
software, sendo que a função de cada um dos gateways pode ser habilitada ou
desabilitada, individualmente, através de um arquivo de configuração.
Figura 3-27: Interface do Software – Servidor
57
Figura 3-28: Interface do Software – Cliente
Figura 3-29: Interface do Software – Fieldbus
Figura 3-30: Interface do software – Tabelas
58
Nas figuras acima podemos ver todos os parâmetros que podem ser
configurados. Preferimos não torná-los editáveis, através da interface do programa,
eles estão presentes apenas para a visualização. Para editá-los, é necessário alterar
um arquivo de configuração, que se encontra no formato XML. Esta escolha foi
tomada para prevenir que usuários possam alterar as configurações acidentalmente,
lembrando que este programa deverá estar instalado na empresa cliente. Na Figura
3-30 podemos visualizar as tabelas de endereçamento presentes, tanto no Gateway
1, quanto no Gateway 2, descritas anteriormente.
Os Gateway 1 e 2 denominados Gateway Server e Gateway Client,

respectivamente (devido ao papel que desempenham perante o protocolo Modbus),
originaram-se de uma classe base (CustomGateway) que incorpora o
comportamento padrão que passaremos a descrever.
O CustomGateway incorpora os componentes de comunicação para ser

cliente, tanto do Modbus TCP (TCPClient), quanto do Modbus RTU (RTUMaster),
além de possuir todos os dados de configuração vistos nas interfaces acima, possu,i
também, a tabela que mantém o cadastro dos equipamentos (XMLConfigFile).
TCPClient RTUMaster
TCustom Gatew ay
attributes
- XMLConfigFile: TXMLDocument;
TGatew ayServer
TGatew ayClient
attributes
attributes
- TCPServer: TModbusTCPServer;
- WSServer: TWSServer;
- WSClient: TWSClient;
Figura 3-31: Diagrama de Classes Gateway
59
A Figura 3-31 não representa exatamente o diagrama de classes, utilizado na
implementação do gateway, serve apenas como uma ilustração das diferenças entre
o Gateway Server e o Gateway Client. O primeiro tem a capacidade de receber
solicitações Modbus TCP, através do uso do componente TCPServer, e realizar
solicitações remotas, com a utilização do WSClient. Já o segundo tem a capacidade
de disponibilizar serviços, através de web services, WSServer. O CustomGateway,
classe ancestral dos Gateways Server e Client, oferece o comportamento padrão
descrito anteriormente. Isto possibilita a implementação de arquiteturas como as
mostradas abaixo.
Supervisório /
Gateway
CLP
ice
WebServ
ModBUS RTU
Internet
CLP
RS232
WebService RS485
Seridor
WebServices
Gateway
CLP
Figura 3-32: Arquitetura de Acesso Remoto Simplificada
A arquitetura mostrada acima foi implementada durante os testes do software.

O software de supervisão e o gateway (apenas com o Gateway 1 habilitado) ficam
instalados no mesmo computador. Na empresa cliente, também é utilizado apenas
um micro, onde fica instalado o gateway com os comportamentos do Gateway 2 e do
Gateway 3 habilitados.
60
Figura 3-33: Arquitetura de Acesso Local
Na figura acima, é mostrada a possibilidade da utilização do software para um

monitoramento local. Tanto o supervisório, quanto o gateway (Gateway 1 habilitado)
ficam instalados na mesma máquina, trocando informações pelo protocolo Modbus
TCP. Para isso, basta configurar o endereço do gateway como endereço local (ex.:
‘127.0.0.1’). O gateway se encarregará da comunicação através do protocolo
Modbus RTU, lembrando que este comportamento ele herdou do CustomGateway,
mencionado anteriormente.
Outra particularidade da implementação utilizada, foi a criação de funções de

configuração remota do próprio gateway. Foram criados métodos remotos que
trafegam apenas entre os componentes mostrados na Figura 3-21, ou seja, não
trafegam sobre o protocolo Modbus. Estes métodos permitem a alteração de
configurações do software instalado na máquina cliente, sem o auxílio de ninguém.
Os seguintes métodos foram desenvolvidos:
• Configuração Remota:
Com a utilização deste método, é possível substituir o arquivo de

configuração onde se encontram todos os dados, desde a paridade da
61
porta serial até o nome do serviço a ser disponibilizado. Este comando
deve ser executado com muito cuidado, pois algum erro na configuração
do Gateway 2 pode tirar o serviço do ar, impossibilitando novas
configurações remotas até que alguma configuração correta seja feita
novamente.
• Logs Remoto:
Este comando retorna um arquivo de log, através do qual é possível

diagnosticar algum problema de configuração na comunicação. Todos os
acontecimentos, tanto de sucesso, quanto de erros, ficam armazenados
neste arquivo, com a hora em que ocorreram. Desta forma, fica possível
descobrir a seqüência de eventos que levaram a um determinado erro.
• Limpeza dos Logs Remotos:
Este comando esvazia os arquivos de log remotos.
Com a implementação destes últimos comandos, o suporte técnico remoto

fica quase que independente do conhecimento técnico dos clientes.
62
Capítulo 4: Resultados
Após a etapa de implementação do software ser concluída, passamos à etapa

de testes.
Inicialmente, começamos a testar diversas arquiteturas diferentes, para

verificar se a versatilidade que havíamos imaginado, no desenvolvimento do projeto,
seria constatada em sua utilização. A cada erro encontrado, ou a cada sugestão de
melhoria, avaliávamos e, se possível, fazíamos as alterações.
Após os testes das possibilidades de arquiteturas, passamos para os testes

de desempenho. Estes testes tinham o objetivo de avaliar as limitações desse
projeto para a monitoração de sistemas, ou seja, queríamos descobrir o quão rápida
poderia ser a dinâmica de um sistema e, ainda assim, podermos utilizar o nosso
projeto. Foi durante estes testes que nos deparamos com a necessidade de fazer
uma alteração nas bases do projeto, tivemos que remodelar a maneira que o
Gateway 2 deveria funcionar. Esse problema foi relatado em 3.5.2.3: Gateway 2.
Após essa alteração, retomamos os testes de desempenho, onde os resultados
mostraram que o tempo, para que uma transação Modbus finalize, é de
aproximadamente 2 segundos em média. Esses tempos variam de acordo com o
tráfego da rede e com o tipo de conexão. Durante os testes realizados internamente,
utilizamos a arquitetura mostrada na Figura 3-32 e alternamos o tipo de conexão,
com ADSL e por linha discada, mesmo assim os tempos ficaram em uma faixa de
1,5 a 3 segundos por transação. Para a nossa aplicação, realizar diagnóstico
remoto, esses resultados foram muito satisfatórios. Estes testes também
contribuíram para ficarmos atentos para projetos futuros, pois se desejarmos
monitorar variáveis com essa taxa de amostragem (2 a 5 segundos), é necessário
que as posições físicas de memória estejam próximas, a fim de que, com apenas
uma transação, seja possível ler todas as variáveis desejadas.
Foram realizados, também, testes para verificar a taxa de erros por

transações, os resultados foram bastante satisfatórios também. Retornavam erros
em menos de 1 % das transações. Estes testes foram realizados em dias diferentes,
o supervisório ficava monitorando variáveis a maior taxa possível, durante 3 a 4
63
horas consecutivas, no final, fazíamos a contagem do número de transações e do
número de erros.
Após todos os testes realizados, internamente, o software foi levado ao

Curtume Natur, localizado na cidade de Portão – RS. Esse cliente já possuía uma
máquina (Boralmatic 2100) instalada, juntamente a uma rede fieldbus como
mostrado na Figura 3-33. Lá, foi testada a capacidade de alterar configurações, tanto
do software, quanto da máquina, com a mínima intervenção possível. Os resultados
obtidos foram bons, ou seja, o sistema se comportou da mesma forma, conseguimos
fazer as alterações sem nenhuma intervenção. Porém, a “prova de fogo” ainda não
foi obtida, pois, até então, o sistema não economizou nenhum deslocamento
desnecessário. Não tivemos a oportunidade de solucionar nenhum problema, pois
este, desde a instalação do sistema, não ocorreu.
64
Capítulo 5: Conclusões e Perspectivas
Ao final deste trabalho, os resultados obtidos superaram muito as nossas

expectativas, pois, além do objetivo pretendido, inicialmente, resolver o problema da
falta de informações para algum auxilio por telefone, o projeto mostrou-se capaz de
ir muito mais longe. No decorrer deste trabalho, começamos a enxergar toda a
potencialidade de uma supervisão remota.
Dos objetivos pretendidos inicialmente (Fazer diagnósticos remotos sem a

ajuda do cliente; Diminuir o tempo de máquina parada; Eliminar deslocamentos
desnecessários de seus técnicos; Elaborar um procedimento padrão para o
atendimento ao cliente; Aumentar a confiança do cliente perante os equipamentos
produzidos pela empresa), com exceção da padronização do atendimento ao cliente,
pois este depende de outros fatores, acredito que todos serão alcançados. Alguns
são difíceis de mensurar, a confiança do cliente, por exemplo, outros ainda é muito
cedo para avaliar. Porém, o principal deles, fazer diagnóstico remoto, foi testado e
aprovado, de forma que os outros têm grandes chances de serem alcançados
também.
Todos os novos projetos de máquinas da San Martin irão incorporar a

capacidade de uma comunicação, através do protocolo Modbus, permitindo o
acesso remoto a elas. No momento, estamos estudando a possibilidade de alterar as
máquinas já instaladas, gradativamente, com o menor custo possível. Futuramente,
tentaremos utilizar este projeto em outras áreas, não apenas na industrial. Alguns
clientes do setor agrícola já se mostraram bastante interessados. Estamos
negociando a instalação de um sistema de monitoração do estado das bombas de
irrigação. O funcionamento permanente dessas bombas é essencial para não haver
prejuízos na lavoura.
O desenvolvimento de sistemas como esse traz vários pontos positivos

consigo. Para começar, é tecnologia local, específica às nossas necessidades, e de
baixíssimo custo. Além disso, tem manutenção facilitada, justamente por ser de
desenvolvimento local.
65
Mas, por trás de tantos pontos positivos, tantas vantagens, estão os esforços
para sua execução. A elaboração de um sistema como esse não é uma tarefa
simples. Envolve bastante esforço em pesquisas e exige muito conhecimento prévio,
conhecimentos esses que o curso de Engenharia de Controle e Automação
Industrial forneceu uma ótima base.
Gostaria de salientar também, que, além da economia que este projeto

pretende gerar, ele mostrou um outro lado igualmente importante. Ao incorporarmos
essa tecnologia nas máquinas, os clientes sentem-se muito mais seguros, ficam
muito mais confiantes, sabendo que, ao fazer um grande investimento em uma
máquina moderna, não ficarão frustrados vendo-as paradas, por não ter ninguém
capacitado para dar uma eventual manutenção.
Enfim, após a finalização deste projeto, pudemos perceber a importância, nos

dias de hoje, do uso da tecnologia como uma forma de agregação de valor. A
competitividade no mercado atual exige o máximo de diferencial possível, objetivo
que é bastante facilitado com o correto emprego da tecnologia de automação.
66
Bibliografia:
[ 1 ] CANTÙ, Marco, “Mastering Delphi 6”, Makron Books, 2002.
[ 2 ] CANTÙ, Marco, “Mastering Delphi 7”, Pearson, 2005.
[ 3 ] Anônimo, “Modbus Application Protocol Specification v1.1a”, Modbus.org,

2004.
[ 4 ] Anônimo, “Modbus Messaging on TCP/IP Implementation Guide v1.0a”,

Modbus.org, 2004.
[ 5 ] Anônimo, “Modbus over Serial Line Specification & Implementation v1.0”,

Modbus.org, 2002.
[ 6 ] OLIVEIRA, Rômulo; CARISSIMI; TOSCANI, “Sistemas Operacionais” 2ª

ed., Sagra Luzzato, 2001.
[ 7 ] FOWLER, M.; SCOTT, K., “UML Essencial” 2ª ed., Bookman, 2000.
[ 8 ] Anônimo, “S7-200 Programmable Controller System Manual”, Siemens

AG, 2004
[ 9 ] TANENBAUM, A. S., “Computer Networks” 4ª ed., Prentice Hall, 2003.
[ 10 ] STEMMER, M. R., “Sistemas Distribuídos e Redes de Computadores

para Controle e Automação Industrial”, Apostila do Curso de Graduação,
UFSC, 2001.
[ 11 ] CURBERA, F.; DUFTLER, M; KHALAF, R.; NAGY, W.; MUKHI, N.;

WEERAWARANA, S., “Unraveling the Web Sevices Web”, IBM T.J.
Watson Research Center, 2001.
[ 12 ] TSALGATIDOU, A., “An Overview of Standards and Related Technology

in Web Service”, University of Athens, 2002.
67
[ 13 ] COAD, P.; YOURDON, E., “Análise Baseada em Objetos” 2ª ed., Rio de
Janeiro: Campus, 1991.
68

PFC v1-01

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

PFC v1-01

Загружено:

Авторское право:

Доступные форматы

Plataforma de Auxílio à Manutenção

Remota de Máquinas Controladas por

Monografia submetida à Universidade Federal de Santa Catarina

Marco San Martins

Florianópolis, outubro de 2005

Marco San Martins

Esta monografia foi julgada no contexto da disciplina

Eng. Rogério da Nova Cruz Peter

Prof. Carlos Montez

Prof. Augusto Humberto Bruciapaglia

Prof. Ricardo Stemmer, Avaliador

Elson Mota, Debatedor

Victor Rocha, Debatedor

À Universidade Federal de Santa Catarina e todos os seus funcionários, por

A Juliana, com muito amor.

Este trabalho tem como finalidade a criação de um sistema que viabilize o

Na solução implementada, foram utilizados dois protocolos de comunicação

In the implemented solution, two communication protocols for industrial nets

Abstract ........................................................................................................... iii

Lista de Figuras ............................................................................................... vi

Capítulo 1: Introdução ......................................................................................2

1.1: Histórico da Empresa.............................................................................2

1.2: Introdução ao Problema.........................................................................4

Capítulo 2: Estudo do Produto..........................................................................8

2.1: Fulão de Recurtimento e Tingimento .....................................................8

2.1.2: Interface Local ...............................................................................11

2.1.3: Arquitetura da Rede FieldBus........................................................12

2.2: Suporte Técnico ...................................................................................12

Capítulo 3: Implementação da Solução ..........................................................15

3.1: Padrões Utilizados na Modelagem do Software...................................15

3.1.1: A Análise Orientada a Objeto ........................................................15

3.1.2: Diagramas UML.............................................................................19

3.1.3: Metodologia ...................................................................................21

3.2: Modbus ................................................................................................22

3.2.2: Descrição do Protocolo .................................................................24

3.2.4: Modelo de Dados ..........................................................................29

3.2.5: Modelo de Endereçamento............................................................29

3.2.6: Transação Modbus........................................................................30

3.2.7: Funções Implementadas ...............................................................32

3.3: Web Services .......................................................................................39

3.3.1: Contextualização ...........................................................................39

3.3.2: Arquitetura de Funcionamento ......................................................40

3.4: Generalização da Solução ...................................................................42

3.5: Componentes do Sistema....................................................................44

3.5.2: Gateways Modbus TCP e Web Service ........................................46

3.5.3: Gateway Modbus TCP / Modbus RTU ..........................................56

3.6: Implementação do Gateway ................................................................57

Capítulo 4: Resultados ...................................................................................63

Capítulo 5: Conclusões e Perspectivas ..........................................................65

Figura 1-1: Máquina de Amaciar ......................................................................3

Figura 1-2: Fulão de Amaciar ...........................................................................3

Figura 1-3: Fulão de Recurtimento ...................................................................3

Figura 1-4: Fulão de Amaciar de Grande Capacidade .....................................3

Figura 3-1: Fulão de Recurtimento e Tingimento BorealMatic 2100.................8

Figura 3-2: Divisão Interna do Fulão.................................................................9

Figura 3-3: Vista Posterior do BorealMatic .....................................................10

Figura 3-4: Arquitetura da Rede Fieldbus.......................................................12

Figura 4-1: Definição da Classe TPDU...........................................................16

Figura 4-2: Hierarquia da Família TPDU. .......................................................17

Figura 4-3: Representação Gráfica da Classe Complexa TCustomGateway. 18

Figura 4-4: Processo de Desenvolvimento .....................................................22

Figura 4-5: Exemplo de Arquitetura de Rede Modbus....................................23

Figura 4-6: Camadas do Modbus ...................................................................24

Figura 4-7: Frame Modbus Genérico..............................................................24