protocolo de comunicação profinet para redes de...
TRANSCRIPT
PROTOCOLO DE COMUNICACAO PROFINET PARA REDES DE
AUTOMACAO
Vinicius de Souza Lima Oliveira
Projeto de Graduacao apresentado ao Corpo
Docente do Departamento de Engenharia
Eletrica da Escola Politecnica da Universidade
Federal do Rio de Janeiro, como parte dos
requisitos necessarios a obtencao do tıtulo de
Engenheiro Eletricista.
Orientador: Marcos Vicente de Brito Moreira
Rio de Janeiro
Setembro de 2016
PROTOCOLO DE COMUNICACAO PROFINET PARA REDES DE
AUTOMACAO
Vinicius de Souza Lima Oliveira
PROJETO DE GRADUACAO SUBMETIDO AO CORPO DOCENTE
DO DEPARTAMENTO DE ENGENHARIA ELETRICA DA ESCOLA
POLITECNICA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO
COMO PARTE DOS REQUISITOS NECESSARIOS PARA A OBTENCAO DO
GRAU DE ENGENHEIRO ELETRICISTA.
Examinado por:
Prof. Marcos Vicente de Brito Moreira, D.Sc.
Prof. Lilian Kawakami Carvalho, D.Sc.
Prof. Felipe Gomes de Oliveira Cabral, M.Sc.
RIO DE JANEIRO, RJ – BRASIL
SETEMBRO DE 2016
de Souza Lima Oliveira, Vinicius
Protocolo de comunicacao PROFINET para Redes de
Automacao / Vinicius de Souza Lima Oliveira. – Rio de
Janeiro: UFRJ/Escola Politecnica, 2016.
XII, 65 p.: il.; 29, 7cm.
Orientador: Marcos Vicente de Brito Moreira
Projeto de Graduacao – UFRJ/Escola Politecnica/
Departamento de Engenharia Eletrica, 2016.
Referencias Bibliograficas: p. 65 – 65.
1. PLC. 2. Automacao. 3. Comunicacao. I. de
Brito Moreira, Marcos Vicente. II. Universidade Federal
do Rio de Janeiro, Escola Politecnica, Departamento
de Engenharia Eletrica. III. Protocolo de comunicacao
PROFINET para Redes de Automacao.
iii
”A persistencia e o menor
caminho para o sucesso.”
-Charles Chaplin
iv
Agradecimentos
A minha Mae, Marta Maria, pela insistencia nas minhas horas de fraqueza, pela
confianca nas horas de duvida e pelo amor incondicional de sempre. Ao meu Pai,
Marcos, pela paciencia e ombro amigo de todas as horas. A ambos pela educacao
que me foi dada. Sem voces nao seria possıvel sequer comecar essa caminhada.
Aos meus professores do departamento de Engenharia Eletrica, em especial ao
professor Marcos Moreira por ter me orientado neste trabalho e por ter me mostrado
o mundo da automacao industrial.
A minha famılia pelo apoio e uniao. Sou abencoado por fazer parte dessa famılia.
Aos meus amigos da UFRJ, do Colegio de Sao Bento e do condomınio Terrazas,
pelo companheirismo e amizade.
v
Resumo do Projeto de Graduacao apresentado a Escola Politecnica/UFRJ como
parte dos requisitos necessarios para a obtencao do grau de Engenheiro Eletricista
PROTOCOLO DE COMUNICACAO PROFINET PARA REDES DE
AUTOMACAO
Vinicius de Souza Lima Oliveira
Setembro/2016
Orientador: Marcos Vicente de Brito Moreira
Departamento: Engenharia Eletrica
Neste trabalho sao apresentados conceitos de redes de computadores e formas
de se estabelecer uma comunicacao entre controladores industriais da famılia S7, da
fabricante Siemens, sob o protocolo PROFINET. Parte do trabalho e apresentado
em forma de tutorial, para que o leitor consiga elaborar um projeto desde o inıcio.
Afim de validar o conteudo do tutorial, um exemplo de aplicacao foi desenvolvido
no Laboratorio de Controle e Automacao(LCA), da Universidade Federal do Rio de
Janeiro(UFRJ).
vi
Abstract of Graduation Project presented to POLI/UFRJ as a partial fulfillment of
the requirements for the degree of Electrical Engineer
GRADUATION PROJECT TITLE
Vinicius de Souza Lima Oliveira
September/2016
Advisor: Marcos Vicente de Brito Moreira
Department: Electrical Engineering
In this work we present network concepts and how to stablish communcation
between Siemens S7 Controllers, under PROFINET protocol. A section of this work
is presented as a tutorial, to allow the reader to create and develop his own project,
from the beginning. In order to validate the material presented at the tutorial,
a praticle example was developed at the Control and Automation Laboratory at
Federal University of Rio de Janeiro.
vii
Sumario
Lista de Figuras x
Lista de Tabelas xii
1 Introducao 1
2 Redes de Comunicacao 3
2.1 Introducao as Redes de Comunicacao . . . . . . . . . . . . . . . . . . 3
2.1.1 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Topologias de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1 Topologia fısica e logica . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Metodos de Acesso a Mıdia . . . . . . . . . . . . . . . . . . . 15
2.3 Protocolo Ethernet (IEEE 802.3 CSMA/CD) . . . . . . . . . . . . . . 16
2.3.1 Camada Fısica . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Formato do frame MAC . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 Controle de Acesso ao Meio . . . . . . . . . . . . . . . . . . . 19
3 PROFINET 22
3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2 Topologias de uma rede PROFINET . . . . . . . . . . . . . . . . . . 22
3.3 Canais de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Comunicacao entre Dispositivos em uma Rede PROFINET . . . . . . 24
3.4.1 Bloco GET e Bloco PUT . . . . . . . . . . . . . . . . . . . . . 25
3.4.2 I-Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4.3 Conectando Redes PROFINET e Fieldbus . . . . . . . . . . . 28
3.4.4 Protocolos de Redundancia . . . . . . . . . . . . . . . . . . . 29
3.5 PROFIenergy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4 Comunicacao 34
4.1 Criando um Novo Projeto no TIA Portal . . . . . . . . . . . . . . . . 34
4.2 Adicionando Dispositivos ao Projeto . . . . . . . . . . . . . . . . . . 35
4.3 Bloco GET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
viii
4.3.1 Criando uma Conexao S7 entre os CLPs . . . . . . . . . . . . 38
4.3.2 Criando Data Blocks . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.3 Parametrizando o Bloco GET . . . . . . . . . . . . . . . . . . 43
4.4 Bloco PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Comunicacao I-Device . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.1 Habilitando a funcionalidade de I-Device . . . . . . . . . . . . 53
4.5.2 Conectando os PLCs . . . . . . . . . . . . . . . . . . . . . . . 54
4.5.3 Configurando as Areas de Transferencia . . . . . . . . . . . . . 55
4.6 Protocolo de Redundancia . . . . . . . . . . . . . . . . . . . . . . . . 56
5 Exemplo de Aplicacao 60
6 Conclusao 64
Referencias Bibliograficas 65
ix
Lista de Figuras
2.1 Modelo OSI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Topologia de Transmissao . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Topologia em Anel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Topologia de Barramento. . . . . . . . . . . . . . . . . . . . . . . . . 10
2.5 Topologia em Estrela. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.6 Topologia em Anel-Estrela. . . . . . . . . . . . . . . . . . . . . . . . . 13
2.7 Topologia em Estrela Distribuıda. . . . . . . . . . . . . . . . . . . . . 13
2.8 Topologia em Arvore . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.9 Topologia Mesh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.10 Numero MAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.11 Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.12 Dinamica do principio de deteccao de colisoes . . . . . . . . . . . . . 20
3.1 Exemplo de combinacoes de topologias em PROFINET . . . . . . . . 23
3.2 Diferentes tipos de processos e sua criticidade. . . . . . . . . . . . . . 24
3.3 I-device como IO controller de um subprocesso. . . . . . . . . . . . . 27
3.4 I-Device com funcionalidade de Device compartilhado. . . . . . . . . 28
3.5 Conexao de diferentes redes Fieldbus. . . . . . . . . . . . . . . . . . . 29
3.6 Topologia em linha . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Redundancia em anel . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.8 Dispositivos Redundantes. . . . . . . . . . . . . . . . . . . . . . . . . 31
3.9 Redundancia em anel duplo . . . . . . . . . . . . . . . . . . . . . . . 32
4.1 Tela de abertura do TIA Portal V13 . . . . . . . . . . . . . . . . . . 34
4.2 Dados do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Acessando o ambiente de engenharia . . . . . . . . . . . . . . . . . . 35
4.4 Adiconando dispostivos . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.5 Adiconando a CPU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6 Network View dos PLCs criados. . . . . . . . . . . . . . . . . . . . . 37
4.7 Configurando uma conexao S7 entre os controladores. . . . . . . . . . 39
4.8 Selecionando o Bloco GET. . . . . . . . . . . . . . . . . . . . . . . . 40
x
4.9 Selecionando o Bloco GET. . . . . . . . . . . . . . . . . . . . . . . . 40
4.10 Estrutura do Bloco GET . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11 Desablitando o Optmized Block Acess. . . . . . . . . . . . . . . . . . 42
4.12 Adicionando um Data Block. . . . . . . . . . . . . . . . . . . . . . . . 42
4.13 Criando uma variavel no Data Block. . . . . . . . . . . . . . . . . . . 43
4.14 Criando uma variavel no Data Block. . . . . . . . . . . . . . . . . . . 43
4.15 Selecionando a CPU Partner. . . . . . . . . . . . . . . . . . . . . . . 44
4.16 Connection ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.17 Habilitando o memoria de Clock. . . . . . . . . . . . . . . . . . . . . 46
4.18 Selecionando o Clock de chamada do bloco. . . . . . . . . . . . . . . 46
4.19 Configurando a Area de Leitura . . . . . . . . . . . . . . . . . . . . . 47
4.20 Configurando a Area de leitura. . . . . . . . . . . . . . . . . . . . . . 48
4.21 Configurando a Area de Armazenamento . . . . . . . . . . . . . . . . 49
4.22 Bloco GET com os parametros completo . . . . . . . . . . . . . . . . 50
4.23 Inserindo o Bloco Move . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.24 Bloco Move do CLP remoto. . . . . . . . . . . . . . . . . . . . . . . . 51
4.25 Bloco Move do CLP Local. . . . . . . . . . . . . . . . . . . . . . . . . 51
4.26 Parametros Send Area e Write Area do Bloco PUT. . . . . . . . . . . 52
4.27 Bloco PUT com os parametros completos. . . . . . . . . . . . . . . . 52
4.28 Configuracao do CLP I-Device. . . . . . . . . . . . . . . . . . . . . . 53
4.29 Configuracao do CLP I-Device. . . . . . . . . . . . . . . . . . . . . . 54
4.30 Conexao entre os CLPs. . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.31 Configurando o IO Cycle . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.32 Area de Transferencia. . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.33 Conectando os PLCs a uma mesma rede Profinet. . . . . . . . . . . . 57
4.34 Conectando os PLCs a uma mesma rede Profinet. . . . . . . . . . . . 57
4.35 Configurando o Ring Manager. . . . . . . . . . . . . . . . . . . . . . . 58
4.36 Configurando os clientes. . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.37 Visao geral de uma configuracao MRP. . . . . . . . . . . . . . . . . . 59
5.1 Proposta de aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2 Obtendo o valor inteiro do CLP 1214 atraves do bloco GET . . . . . 61
5.3 Enviando o valor de uma tag do tipo byte atraves da Area de Trans-
ferencia do I-Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Topology View da aplicacao . . . . . . . . . . . . . . . . . . . . . . . 62
5.5 Network View da aplicacao . . . . . . . . . . . . . . . . . . . . . . . . 63
xi
Lista de Tabelas
2.1 Tipos de Cabos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Codigos de Erro do bloco GET . . . . . . . . . . . . . . . . . . . . . 49
xii
Capıtulo 1
Introducao
O ambiente industrial moderno se encontra cada vez mais integrado e descentrali-
zado. Isso se deve, principalmente, a crescente complexidade dos processos e pela
alta demanda por disponibilidade. Atualmente, existem diversos protocolos de co-
municacao industrial disponıveis, e com caracterısticas proprias de acordo com sua
aplicacao na industria. Integrar sistemas e processos exige que os computadores in-
dustriais responsaveis pelos mesmos se comuniquem de uma forma eficiente, segura
e confiavel. A escolha do protocolo de comunicacao e fundamental para alcancar
esses requisitos.
Uma linha de montagem de veıculos ou uma industria quımica de grande porte,
por exemplo, possui diversos processos independentes e fisicamente distantes um dos
outros. Desde a materia prima ate a embalagem, um longo caminho e percorrido
na fabricacao de um produto. Diferentes partes, componentes e subprodutos sao
produzidos, sequencial ou paralelamente, para juntos constituırem o produto final.
Processos integrados resultam em ganhos de sincronia de producao, economia em
hardware e aumento de confiabilidade dos processos que, conectados, sao capazes
de se enxergar e influenciar uns aos outros.
Integrar processos significa, em grande parte, coloca-los em uma mesma rede.
Dessa forma, os dados disponibilizados pelos sensores de cada processo individual
podem ser utilizados para se tomar decisoes em outros. Alem disso, pode-se distri-
buir o processamento dos dados por diferentes unidades, em vez de termos unidades
individuais para cada processo, diminuindo consideravelmente os custos de um pro-
jeto.
Este projeto visa demonstrar as alternativas disponıveis para se trocar dados en-
tre CLPs (Controlador Logico Programavel) Siemens sob o protocolo PROFINET.
Para tal, sera utilizada a linguagem Ladder e blocos de funcoes especıficos do fabri-
cante. No capitulo 2, sao apresentadas as caracterısticas do protocolo PROFINET,
bem como suas vantagens. No capitulo 3, sao discutidos os diferentes meios dis-
ponıveis para realizar trocas de dados entre CLPs, e suas particularidades em forma
1
de tutorial. No capitulo 4 uma aplicacao demonstrativa e descrita e no capitulo 5
as conclusoes sao apresentadas.
2
Capıtulo 2
Redes de Comunicacao
2.1 Introducao as Redes de Comunicacao
Redes de comunicacao permitem que computadores enviem e recebam informacoes
uns dos outros. A internet e o melhor exemplo da capacidade que as redes podem al-
cancar, mas redes menores tambem possuem papeis importantes. Redes industriais
sao um exemplo disso. A comunicacao atraves de redes e essencial para o ambiente
industrial moderno, em que os processos sao cada vez mais complexos e interde-
pendentes e a necessidade de comunicacao entre os computadores responsaveis e
essencial.
O protocolo Ethernet surgiu nos anos 80, mas somente com a necessidade das
funcionalidades de TI e que o protocolo, nos anos 2000, alcancou a industria. Ar-
quiteturas escalaveis, acesso descentralizado aos dispositivos conectados a rede, fa-
cilidade de manutencao e custos de implementacao e monitoramento reduzidos sao
algumas das caracterısticas que as funcionalidades do protocolo trouxeram a indus-
tria.
Quanto ao tipo de redes, dividimos em 2 grupos: Local Area Network(LAN), onde
os dispositivos conectados estao relativamente perto, com uma distancia maxima de
poucas centenas de metros; e Wide Area Network (WAN), em que os dispositivos
conectados estao mais distantes. Enquanto em uma rede LAN podemos conectar
muitos dispositivos com altas velocidades de comunicacao, em uma rede WAN tanto
a quantidade de dispositivos quanto a velocidade de conexao sao reduzidas. Porem,
e preciso enfatizar que a recente tecnologia de fibra otica permitiu que a distancia e
velocidade entre redes WAN tivessem ganhos consideraveis. [1]
Quando se fala de redes e comum ouvir o termo Protocolo, que se refere ao
conjunto de regras que regem a comunicacao das redes. Para que dois dispositivos se
comuniquem e preciso que ambos entendam o mesmo protocolo. Frames, ou quadros
em portugues, sao equivalentes as frases que formamos para nos comunicar. Assim
3
como existem regras para formacao de frases, existem regras para a formacao dos
Frames. Cada Frame precisa conter tanto o endereco da fonte quanto o endereco
do destinatario, alem das informacoes que ele carrega. Para a compreensao de
como esses Frames trafegam e como eles sao tratados, tanto por quem envia quando
por quem recebe, e preciso entender o modelo OSI (Open System Interconnection
Reference Model), que e ate hoje a base de como as redes modernas sao estruturadas.
2.1.1 Modelo OSI
O modelo OSI divide a operacao de redes de computadores em sete camadas, onde
as camadas sucessivas “envelopam” as antecessoras, ou seja, as camadas inferiores
escondem as suas informacoes das camadas superiores. O modelo OSI especifica as
caracterısticas de uma rede que podem ser incorporadas por um protocolo.
As camadas do Modelo podem ser resumidas em[1]:
1. Fısica: E a camada responsavel por enviar e receber os bits atraves de um
meio fısico. Nela sao especificadas as interfaces eletricas e mecanicas alem da
forma como os dados sao levados as camadas superiores.
2. Enlace de dados: Estabelece enderecos para identificar os nos da rede, e divide
os pacotes a serem enviados pela camada fısica
3. Rede: Lida com o enderecamento de dados, ou seja, por leva-los da sua fonte
ate o receptor.
4. Transporte: E responsavel pela movimentacao dos dados da camada de sessao
para a camada de rede e vice-versa, alem de separar as camadas de aplicacao
das camadas fısicas.
5. Sessao: Tem a funcao de permitir que aplicacoes em diferentes dispositivos se
comuniquem.
6. Apresentacao: Recebe os dados da camada de aplicacao e os converte em um
formato usual do protocolo utilizado.
7. Aplicacao : E responsavel por permitir que as aplicacoes utilizem servicos de
rede e prove meios para que a comunicacao seja possıvel.
Camada Fısica
A primeira camada do modelo OSI e responsavel por enviar e receber os bits atraves
de um meio fısico. Nela, sao especificadas as interfaces eletricas/oticas e mecanicas,
alem da forma como os dados sao levados as camadas superiores. No ”remetente”a
4
camada fısica recebe os pacotes de dados da camada de enlace de dados e os converte
em uma serie de sinais eletricos que representam 1s e 0s. Esses sinais sao enviados
pelo meio fısico, e ao chegarem no destinatario, a camada fısica novamente converte
os sinais eletricos em 1s e 0s, que sao novamente agrupados em pacotes e enviados
para a camada de enlace de dados.
As propriedades mecanicas e eletricas do meio de transmissao sao definidas nessa
camada:
• O tipo de cabo e conectores utilizados. Os cabos podem ser coaxiais, fibra
oticas, etc. Os conectores dependem do tipo de cabo.
• A quantidade de pinos dos conectores.
• O formato dos sinais eletricos que carregam a informacao.
Camada de Enlace de dados
A camada de enlace de dados e responsavel por criar, enviar e receber os paco-
tes de dados contendo os bits, e utiliza a camada fısica para transmitir e receber
informacao. A camada de enlace cria os Frames, ou pacotes, de acordo com a ar-
quitetura utilizada. [1]
• Estabelecer e finalizar vınculos logicos entre dois nos.
• Controlar o trafego dos pacotes.
• Sequenciamento de pacotes.
• Confirmar a recepcao dos pacotes.
• limitar o tamanho dos pacotes.
• Verificacao da integridade dos pacotes.
• Gerenciar o acesso dos nos aos pacotes que trafegam.
Camada de Rede
A terceira camada do modelo OSI decide o caminho fısico que os dados devem seguir,
com base nas caracterısticas da rede e de prioridade. E responsavel por:[1]
• Determinar os enderecos, ou traduzir os enderecos fısicos para enderecos de
rede.
• Encontrar uma rota entre o remetente e o destinatario.
5
• Estabelecer e manter uma conexao entre os nos que se comunicam.
• Fragmentar pacotes maiores em menores para que possam ser transmitidos
pela camada de enlance. A camada de rede do destinatario e responsavel por
remontar esses pacotes menores no pacote original.
Camada de Transporte
A camada de transporte e responsavel pela movimentacao dos dados da camada
de sessao para a camada de rede e vice-versa, alem de assegurar a qualidade dos
dados e o recebimento dos mesmos. Para assegurar que foram entregues, os pacotes
recebem numeros em sequencia. A camada de transporte do destinatario verifica essa
numeracao para assegurar que todos os pacotes foram recebidos e entao ordena-los na
sequencia correta. A camada de transporte e a camada de conexao entre as camadas
inferiores, com maior dependencia das caracterısticas de rede, e as superiores, mais
relacionadas as aplicacoes. A camada de transporte e responsavel por:[1]
• Segmentar mensagens com tamanhos acima dos limites suportados pela ca-
mada de rede, para que a mesma possa recebe-los.
• Confirma a entrega de mensagens.
• Controlar a fila de pacotes dos destinatarios.
• Multiplexar as sessoes e controlar o fluxo de mensagens, designando a quais
sessoes as mesmas pertencem.
Camada de Sessao
A camada de sessao e responsavel por sincronizar e sequenciar a comunicacao e
os pacotes que trafegam em uma rede. Tambem e responsavel por garantir a co-
nexao ate que a transmissao de todos os pacotes se complete, por realizar tarefas de
seguranca, reconhecimento de enderecos, registro de logs, etc.
Camada de Apresentacao
A sexta camada e responsavel por apresentar a informacao de maneira que as
aplicacoes consigam interpreta-las. Funcoes como conversao de dados entre diferen-
tes formatos, compressao, expansao de dados e encriptacao sao responsabilidades
dessa camada. Ou seja, a camada de apresentacao fornece suporte para a camada
seguinte, e utiliza a camada de sessao para isso. [1]
6
Camada de Aplicacao
E a setima e ultima camada do modelo OSI. A camada de aplicacao e responsavel
por fornecer acesso a rede as aplicacoes, provendo meios para que a comunicacao seja
possıvel. Entre as funcoes dessa camada estao transferencia de arquivos, servicos
de e-mail e gerenciamento de rede. Os servicos fornecidos por essa camada sao
muito mais variados do que os das camadas inferiores pois a quantidade de tarefas
e aplicacoes diferentes e extensa. Diferentes aplicacoes de gerenciamento de rede
fornecem servicos especıficos para diferentes tipos de redes, e a forma como lidam
com a camada de aplicacao e seus recursos tambem e diferente. [1]
Na figura 2.1 pode-se ter uma visao geral de como os dados fluem entre as camadas:
Figura 2.1: Modelo OSI.
7
2.2 Topologias de Rede
A forma como os pontos de rede se conectam e conhecido como topologia. Existem
diversas topologias diferentes, mas basicamente elas formam dois tipos diferentes de
topologias: De transmissao e Point-to-Point.[1]
Em topologias de transmissao a informacao sai de um no com o objetivo de atingir
todos os nos, nao existindo regeneracao do sinal pelos nos, o que limita o alcance
da transmissao e o tamanho dessas topologias. Na figura 2.2 pode-se observar esse
tipo de topologia de forma ilustrada.
Figura 2.2: Topologia de Transmissao
Em uma topologia point-to-point, cada no se comunica diretamente com outro
no, de forma que a informacao e capaz de ser verificada e regenerada pelo no receptor,
antes de repassa-lo adiante. Isso garante a integridade do sinal e permite topologias
muito maiores. Um exemplo de topologia point-to-point e a em anel, ilustrada na
figura 2.3, em que os nos A e B se comunicam atraves de outros nos da rede.
Figura 2.3: Topologia em Anel
8
2.2.1 Topologia fısica e logica
Existe uma diferenca entre a forma como a topologia e fisicamente montada, e a
forma como os dados fluem nessa topologia. Uma topologia logica define como os
elementos da rede comunicam uns com os outros e como a informacao e transmitida
pela rede . Os diferentes tipos de metodos de acesso determinam como um no comeca
a transmitir informacoes ao longo da rede. Em uma topologia de barramento, por
exemplo, a informacao e transmitida e cada no recebe a mesma informacao. Ja
em uma topologia em anel cada no recebe informacao do no anterior e envia para
o proximo no. As informacoes sao transmitidas sequencialmente, por uma ordem
determinada. O mecanismo de Token, por exemplo, e usado para determinar quem
tem os direitos de transmissao e um no pode transmitir apenas quando ele tem esse
direito.
A topologia fısica define a configuracao de fiacao da rede, especificando como
os nos sao ligados um ao outro eletricamente, determinando o que acontece se um
no na rede falhar, por exemplo. Topologias fısicas se dividem em tres categorias
principais: Barramento, Estrela e Topologia em Anel. As combinacoes destes podem
ser utilizados para formar topologias hıbridas para superar as deficiencias em uma
ou outra topologia especıfica.
Topologia de Barramento
Uma topologia de barramento refere-se tanto a uma topologia fısica quanto a uma
topologia logica. Como uma topologia fısica , um barramento descreve uma rede
em que cada no esta conectado a um canal de comunicacao ou um bus. Este bus
e as vezes chamado de backbone, ou espinha dorsal, uma vez que fornece a espinha
dorsal para a rede. Cada no conectado pode receber os pacotes que passam pelo
barramento.
Como uma topologia logica, um barramento passivo distingue-se pelo fato de
que os pacotes sao transmitidos e cada no recebe a mensagem ao mesmo tempo.
Pacotes tramitam em ambas as direcoes ao longo do barramento e nao precisam
passar por nos individuais, como em um sistema de ponto-a-ponto. Em vez disso,
cada no verifica o endereco de destino para determinar se esse pacote e destinado
para um no especıfico ou para varios. Quando o sinal atinge o final do barramento,
um terminador eletrico absorve o sinal para evitar que o mesmo reflita de volta ao
longo do barramento, podendo causar interferencia. Cada extremidade de um cabo
de barramento tem de ser terminada.
Em uma topologia de barramento os nos devem ser suficientemente afastados
de modo que nao interfiram uns nos outros. Se o cabo de barramento principal
for muito longo , pode ser necessario aumentar a intensidade do sinal utilizando
9
algum tipo de amplificacao ou repetidor. A figura 2.4 exemplifica uma topologia de
barramento.[1]
Figura 2.4: Topologia de Barramento.
Entre as vantagens dessa topologia, pode-se destacar:
• Arquiteturas simples e flexıveis.
• A topologia de transmissao e vantajosa quando se quer transmitir a mesma
informacao para muitos pontos ao mesmo tempo.
• Utiliza menos cabo quando comparado com outros tipos de topologias.
• E facil de inserir e retirar nos do barramento, tornando a arquitetura facil de
se expandir.
Desvantagens da Topologia de Barramento:
• Todos os nos da rede recebem todos os pacotes, mesmo aqueles que sao desig-
nados a um no especifico. Isso pode representar um problema de seguranca.
• Diagnosticar uma falha na comunicacao pode ser trabalhoso ja que pode estar
em qualquer lugar ao longo do barramento.
• A quantidade de dados que trafega no barramento e limitada, visto que pode
haver sobrecarga de informacao devido a lentidao causada pelo tempo dos nos
ao acessarem o barramento.
Topologia em Estrela
Uma topologia em estrela e uma topologia fısica em que varios nos sao conectados a
um componente central, um roteador. O centro de uma estrela normalmente e ape-
nas um centro de fiacao, ou seja, um ponto de terminacao comum para os nos , com
uma unica conexao a um roteador. Todos os sinais, instrucoes e dados que trafegam
na rede devem passar pelo roteador. O sistema de telefonia e sem duvida o exem-
plo mais conhecido de uma topologia em estrela, com linhas de clientes individuais
provenientes de uma central telefonica. Nao ha muitas implementacoes de LAN que
10
usam uma topologia em estrela. As redes ARCnet sao provavelmente os melhores
exemplos. No entanto, a configuracao fısica de muitas outras LANs parecem com
uma topologia em estrela. A figura 2.5 e um exemplo dessa topologia.[1]
Figura 2.5: Topologia em Estrela.
Vantagens da Topologia em Estrela:
• Facil de diagnosticar e isolar falhas na comunicacao ou em algum dispositivo
defeituoso.
• Facil de inserir e retirar nos.
• A falha de um no nao isola os demais, como na topologia em barramento.
• a introducao de um roteador central facilita a gestao da rede
Desvantagens da Topologia em Estrela:
• Se o roteador central apresentar problemas, toda a rede e afetada. Por isso,
em certas condicoes, se faz necessario uma redundancia de roteadores.
• A topologia em estrela necessita de mais cabo do que outras topologias.
Topologia em Anel
Uma topologia em anel e tanto uma topologia logica quanto uma topologia fısica.
Como uma topologia logica, um anel distingue-se pelo fato de que os pacotes de
mensagem sao transmitidos sequencialmente no por no, em uma ordem predefinida.
E um exemplo de topologia ponto-a-ponto. Os nos estao dispostos num circuito
fechado. Como uma topologia fısica, descreve um anel de uma rede em que cada no
esta ligado a exatamente dois outros nos.
11
Um pacote de mensagem viaja em torno do anel ate que ele retorne ao no que
originalmente o enviou. Em uma topologia em anel, cada no pode agir como um
repetidor, aumentando o sinal antes de envia-lo. Cada no verifica se o no de destino
do pacote de mensagem corresponde ao seu endereco. Quando o pacote chega ao
seu destino, o no de destino aceita a mensagem e em seguida a envia de volta para
o remetente, de forma a acusar a recepcao.
Topologias em anel usam Tokens para controlar o acesso a rede. O Token e
devolvido ao remetente com o sinal de reconhecimento. O remetente, em seguida,
libera o sinal para o proximo no na rede. Se este no nao tem ”nada a dizer”, ele
passa o sinal para o proximo no, e assim por diante. [1]
Vantagens da Topologia em Anel:
• Uma topologia em anel necessita pouco cabeamento.
• Nao e necessario um roteador central para gerenciar o trafego de dados.
• Cada no pode amplificar o sinal.
Desvantagens da Topologia em Anel:
• Diagnostico e isolamento de falhas de comunicacao ou de dispositivos pode
ser difıcil, se nao for gerenciado, ja que a comunicacao se da em apenas um
sentido.
• A adicao ou remocao de nos interrompe o funcionamento da rede.
• Existe um limite da distancia entre os nos.
Topologia em Anel-Estrela
Uma topologia de Anel-Estrela e uma topologia fısica hıbrida que combina as
caracterısticas das topologias em estrela e anel. No interior do roteador, no entanto,
as conexoes sao feitas em anel. A vantagem do uso dessa topologia em vez da anel
simples e que e facil de desligar um no com defeito a partir do anel interno do
roteador. A figura 2.6 ilustra esse tipo de topologia.[1]
Vantagens da Topologia Anel-Estrela:
• Diagnosticar e corrigir falhas e relativamente facil.
• O design modular facilita na expansao da rede, o que torna as configuracoes
flexıveis.
12
• Roteadores podem ser conectados para formar aneis maiores.
Desvantagens da Topologia Anel-Estrela:
• O cabeamento pode se tornar complexo devido, justamente, a flexilidade da
configuracao.
Figura 2.6: Topologia em Anel-Estrela.
Topologia em Estrela Distribuıda
Uma topologia em estrela distribuıda e uma topologia fısica que consiste em dois ou
mais roteadores, cada um dos quais e o centro de uma configuracao em estrela. A
topologia pode ser observada na figura 2.7. [1]
Figura 2.7: Topologia em Estrela Distribuıda.
13
Topologia em Arvore
Uma topologia em arvore, tambem conhecida como barramento distribuıdo e uma
topologia hıbrido que combina caracterısticas de topologias em estrela e barramento.
Varios barramentos podem ser encadeados em conjunto. A extremidade inicial da
arvore e conhecida como a extremidade da raiz ou Root. Este tipo de topologia e
usado na prestacao de servicos de televisao por cabo, por exemplo. Na figura 2.8 a
topologia em Arvore e ilustrada.[1]
As vantagens de uma topologia em Arvore:
• A rede e de facil expansao, adicionando-se ramos.
• Isolar uma falha e relativamente facil
Desvantagens de uma topologia em Arvore:
• Se a extremidade inicial sofrer um falha, toda a rede e comprometida
• Se um roteador sofrer uma falha, toda a ramificacao desse roteador e afetada
• Se a rede ficar muito grande, pode haver dificuldades de acesso pela extremi-
dade inicial
Figura 2.8: Topologia em Arvore
Topologia Mesh
Uma topologia Mesh e uma topologia fısica em que existem pelo menos dois caminhos
de e para cada no . Este tipo de topologia e vantajosa em ambientes hostis em que
as conexoes sao facilmente quebradas. Se uma ligacao e interrompida , pelo menos
um caminho substituto esta sempre disponıvel. Uma definicao mais restrita requer
14
que cada no seja ligado diretamente a todos os outros nos. Por causa das condicoes
de ligacao complexas, tais topologias mais restritas sao viaveis apenas para redes
pequenas. A topologia Mesh pode ser observada na figura 2.9[1]
Figura 2.9: Topologia Mesh
2.2.2 Metodos de Acesso a Mıdia
Um metodo comum e importante de diferenciar os diferentes tipos de LAN, e con-
siderar seus metodos de acesso a mıdia. Uma vez que deve haver algum metodo de
determinacao de qual no pode enviar ou receber uma mensagem, a escolha de como
isso ira acontecer determina a eficacia da LAN. Ha uma serie de metodos que podem
ser considerados, dos quais os dois mais comuns em LANs atuais sao o metodo de
contencao e o metodo de passagem de Token.
Metodo de Contencao
O metodo de contencao e um metodo de acesso probabilıstico e se assemelha com
a forma como a comunicacao humana e feita. Em geral, em uma conversa, quando
uma pessoa esta falando as outras ouvem e esperam sua vez de falar. Se em algum
ponto da conversa mais de uma pessoa comeca a falar ao mesmo tempo, se reconhece
isso e todos param de falar por um tempo, antes de alguem retomar a palavra. Em
um metodo de acesso de contencao o primeiro no a buscar acesso quando a rede esta
disponıvel, ganha o direito de transmitir. Esse metodo e a base do padrao Ethernet.
Metodo de Passagem de Token
O metodo de passagem de Token e um metodo de acesso determinıstico em que
um Token e passado de no em no, de acordo com uma sequencia predefinida. Este
metodo de acesso determinıstico garante que cada no ira receber acesso para a
rede dentro de um determinado perıodo de tempo, geralmente na ordem de alguns
milissegundos.
15
Como cada no recebe sua vez dentro de um perıodo fixo, metodos de acesso
determinısticos sao mais eficientes em redes que tem o trafego pesado. Em tais redes,
nos usando metodos de acesso probabilısticos gastam muito tempo competindo para
ganhar acesso e relativamente pouco tempo na transmissao de dados.
Para transmitir, o primeiro no primeiro marca o sinal como ”em uso”e em seguida
transmite um pacote de dados, de no a no ate o pacote atingir o seu destino. O
destinatario confirma o pacote enviando a mensagem de volta para o remetente
que em seguida envia o Token para o proximo no na rede. Uma rede Token Ring
requer um monitor ativo (Active Monitor ou AM) e um ou mais monitores de espera
(Standby Monitor). O AM mantem o controle do Token para se certificar de que
nao foi corrompido, perdido, ou enviado para um no que tenha sido desconectado
da rede.
Em uma rede de topologia de barramento, por exemplo, o proximo destinatario
de um Token nao e necessariamente o no seguinte ao no que possui o token. Em
vez disso, o proximo no e determinado por uma regra predefinida. Redes que usam
passagem de Token geralmente tem alguma forma de definir a prioridade com que
um no recebe o Token. Protocolos de nıvel superior podem especificar que uma
mensagem e importante e deve receber prioridade maior.
Metodo de Sondagem
O metodo de sondagem, ou Polling, refere-se a um processo de verificacao de ele-
mentos de rede, tais como computadores ou filas, afim de verificar se o elemento
sondado necessita de atencao ou seja, quer transmitir, contem postos de trabalho,
e assim por diante. Em LANs, o metodo fornece um meio determinıstico de acesso,
que determina se um no quer acessar a rede.
2.3 Protocolo Ethernet (IEEE 802.3 CSMA/CD)
Ethernet e o protocolo de comunicacao mais utilizado em redes locais (LAN) e redes
metropolitanas (MAN). Foi introduzido inicialmente em 1980 e padronizado como
IEEE 802.3 em 1983. Basicamente o padrao e responsavel por definir como os dados
sao transmitidos pelo meio fısico. Sua funcao e agrupar os dados das camadas
superiores e transforma-los em Frames que serao enviados na rede. O CSMA/CD
(Carrier Sense Multiple Access with Collision Detection) e um metodo de acesso de
contencao.
O Ethernet opera nas camadas fısica e de enlace e sua versao original operava em
10 Mpbs. Atualmenteo Ethernet abrange diferentes sub-protocolos com velocidades
de ate 10 Gbps. Um dos principais conceitos do Ethernet e o controle de acesso ao
16
Tabela 2.1: Tipos de CabosCabo Tipo de cabo Velocidade Comprimento Maximo
10Base2 Coaxial 10 Mbps 185m10Base5 Coaxial 10 Mbps 500m10BaseT Par trancado 10 Mbps 100m10BaseF Fibra optica 10 Mbps 2000m1Base5 Par trancado 1 Mbps 500m
meio, ou MAC. O MAC e responsavel por montar o Frame de dados a ser transmi-
tido. Ele emprega o CSMA/CD para transmitir fisicamente os dados entregues pela
camada de controle de acesso ao meio. [2]
2.3.1 Camada Fısica
O IEEE 802.3 define uma serie de cabos que podem ser utilizados como meio
fısico do padrao. Eles incluem cabo coaxial, cabo de par trancado e cabo de fibra
optica. Alem disso, existem diferentes padroes de envio de sinais e de diferentes
velocidades. Para o padrao original, com velocidade de 1 a 10 Mbps, a tabela 2.1
especifica os tipos de cabos:
2.3.2 Formato do frame MAC
O enderecamento de rede e feito atraves de um numero unico de 6 bytes, atrelado
a placa de rede de cada computador. Em uma mesma rede nao podem haver dois
dispositivos com o mesmo numero MAC (Media Acess Control). Comparado com o
IP, que e um endereco de rede variavel e a mudanca de uma rede pra outra leva a
um IP diferente, o MAC e um numero unico e invariavel.
O MAC de um dispositivo e representado como um conjunto de 12 algarismos
em hexadecimal. Cada algarismo hexadecimal equivale a um numero de 4 bits. O
IEEE padronizou os enderecos MAC como a figura 2.10. Os 3 primeiros bytes sao
o endereco OUI que identificam o fabricante da placa de rede. Os 3 ultimos bytes
sao designados pela fabricante e cada placa fabricada por esse fabricante possui um
numero diferente. [2]
17
Figura 2.10: Numero MAC.
O formato basico de um Frame para uma rede 802.3 e mostrado na figura abaixo.
Existem oito campos em cada Frame MAC, como pode ser observado na figura 2.11.
Figura 2.11: Frame
1. Preambulo: sequencia de uns e zeros alternados (10101010....1010) com 7 by-
tes, que tem a funcao de informar as estacoes receptoras que um frame esta
comecando.
2. Delimitador de inıcio de frame(SoF): Campo de 1 byte terminado com 2 bits
1 (10101011) usados para sincronizar a parte de recepcao dos Frames entre as
diferentes estacoes receptoras.
3. Endereco de destino: Endereco MAC do destinatario.
4. Endereco de origem: Endereco MAC do remetente.
5. Tamanho: Campo de 2 bytes que indica o tamanho do campo de dados. Esse
campo e necessario pois nao existe um delimitador de final de frame para
indicar quando o mesmo termina.
6. Dados: Contem os dados a serem transmitidos para as camadas superiores do
receptor. Deve possuir no mınimo 64 bytes e no maximo 1500 bytes.
7. Preenchimento: Se os dados do frame forem insuficientes para preencherem o
tamanho mınimo de 64 bytes, bytes de preenchimento sao inseridos.
8. CRC ou Cyclic Redundancy Check e um campo de 4 bytes que contem o
valor de verificacao de redundancia. Esse campo e criado pelo transmissor e
recalculado pelo dispositivo receptor para verificar se o Frame sofreu algum
tipo de dano durante a transmissao.
18
Durante a transmissao, os dados podem ser corrompidos devido a interferencias
eletromagneticas, falhas de sincronismo, componentes eletronicos danificados e ou-
tros fatores. Para que a rede seja segura e preciso que tais erros sejam identificados e
corrigidos, de forma a garantir a integridade dos dados transmitidos. Existem duas
classes de metodos para lidar com isso:
• Codigos de Correcao de Erros: Em cada Frame transmitido sao incluıdos in-
formacoes redundantes o suficiente para que a estacao receptora possa deduzir
a informacao transmitida mesmo que haja interferencia no sinal.
• Codigos de Deteccao de Erros: Sao incluıdas informacoes para o receptor
deduzir com eficiencia que houve um erro na transmissao e dessa forma solicitar
uma nova transmissao.
2.3.3 Controle de Acesso ao Meio
O Ethernet permite dois tipos diferentes de operacao: Half-duplex e Full-duplex.
Uma rede baseada no IEEE 802.3 pode operar tanto em modo Half-duplex quanto
em Full-duplex.[3]
Half-duplex
Para que o processo de envio, recebimento e deteccao de erros seja possıvel, para
cada estacao da rede e atribuıdo um dos tres estados abaixo:
• Inativo.
• Transmitindo.
• Disputando.
No estado inativo, a estacao simplesmente monitora o trafego que passa por ela.
Quando deseja transmitir, a estacao aguarda ate que o meio fique livre, e entao
entra em modo de transmissao. Em certo momento, colisoes irao ocorrer. Como
os diferentes sinais analogicos nao podem coexistir no mesmo meio, as diferentes
estacoes transmissoras entram em modo de disputa. Nesse estado ambas as estacoes
continuam transmitindo em intervalos aleatorios, para que a outra estacao perceba
o conflito, entre em estado inativo e aguarde um perıodo de tempo antes de tentar
transmitir novamente. O princıpio de deteccao de colisoes e demonstrado na figura
2.12.
19
Figura 2.12: Dinamica do principio de deteccao de colisoes
O controle da transmissao em modo Half-duplex e realizado pelo CSMA/CD,
com a finalidade de tornar possıvel a comunicacao e a recuperacao devido a colisoes.
O modo de transmissao Half-duplex determina que apenas uma estacao transmita
enquanto que as outras permanecem em espera. O CSMA/CD gerencia esse pro-
cesso.
O modo Half-duplex e utilizado em redes ethernet de 10 a 100 Mbps.
Full-duplex
Enquanto que em Half-duplex nao e possıvel transmitir e receber ao mesmo tempo,
sendo necessario regras de controle para organizar o trafego de dados entre as
estacoes, no modo full-duplex nao existe essa limitacao. Para isso, uma topolo-
gia ponto-a-ponto e necessaria. O mecanismo de controle de transmissao passa a
ser o Flow-Control e nao mais o CSMA/CD. No Flow-Control quando a estacao
receptora esta congestionada, um pause Frame e enviado para que a estacao trans-
missora suspenda o envio de dados por um determinado intervalo de tempo. A
estacao transmissora aguarda o tempo requisitado e reinicia a transmissao. Caso a
estacao receptora descongestione antes do fim desse intervalo, ela envia um Frame
20
com instrucoes para que a estacao transmissora recomece o envio.
A utilizacao de Full-duplex dobra a capacidade de banda da rede e aumenta as
distancias possıveis, alem de eliminar colisoes. Existem pre-requisitos para que o
meio suporte o modo Full-duplex, como a capacidade de enviar e receber de forma
simultanea sem interferencia, a necessidade de arquiteturas Point-to-Point e das
proprias estacoes serem capazes de trabalhar em Full-duplex. Esse modo e mais
utilizado em redes Gigabit-Ethernet.
21
Capıtulo 3
PROFINET
3.1 Introducao
O PROFINET (Process Field Network) e um protocolo aberto de comunicacao in-
dustrial, baseado no Fast Ethernet, que manteve do padrao Ethernet original a
forma de enderecamento, o formato, o tamanho do Frame e o mecanismo de de-
teccao de erros. A mudancas mais significativa foi o aumento de velocidade de 10
para 100 Mpbs em Half-duplex. Alem disso, o PROFINET se baseia nos protocolos
TCP, UDP e IP para configuracao, troca de dados e diagnostico de rede, sendo seu
principal objetivo a criacao de um ambiente de rede industrial integrado, robusto e
seguro. [4]
O conceito do protocolo nasceu para satisfazer todos os conceitos necessarios em
uma rede de comunicacao industrial ideal. Seus parametros foram criados e desen-
volvidos pela Profibus International (PI), uma associacao internacional de empresas
do segmento de automacao industrial. O protocolo esta em constante desenvolvi-
mento a partir das necessidades e desafios propostos pela industria.
3.2 Topologias de uma rede PROFINET
O PROFINET tambem permite o uso de topologias em estrela, arvore e anel alem da
topologia linear, a mais comum entre redes industriais. Como no protocolo Ether-
net, uma infra-estrutura de rede pode consistir em varias sub-secoes com diferentes
topologias, simples ou hıbridas. A figura 3.1 ilustra um exemplo de combinacao de
topologias possıvel.
22
Figura 3.1: Exemplo de combinacoes de topologias em PROFINET
3.3 Canais de Comunicacao
O padrao PROFINET e dividido em tres canais de comunicacao, diferenciados, so-
bre tudo, por nıveis de performance para os diferentes tipos de processos industriais
automatizados, que podem ser generalizados por: Automacao de Processos, Manu-
fatura e Controle de Eixos. Para cada tipo de processo tem-se diferentes tempos de
sincronizacao, que regem o nıvel de performance da rede. A figura 3.2 compara o
tipo de aplicacao com os canais PROFINET. [4]
• NRT (Non Real Time): Para aplicacoes onde o tempo de ciclo nao e crıtico
(≥ 100ms), como na Automacao de Processos, PROFINET utiliza o padrao
TCP/IP para transmissao dos pacotes de dados.
• RT (Real Time): Em processos com maior necessidade de precisao, como
na maioria dos processos de manufatura, utiliza-se o PROFINET RT para
transmissao de dados em alta performance, pois possui tempos de ciclo mais
rapidos (100 ≥ t ≥ 10ms). Por isso tambem e utilizado para programacao de
alarmes e de outros elementos mais crıticos do processo.
• IRT (Isochronous Real Time): Para comunicacao sincronizada por clock, ou
seja, processos onde o tempo de ciclo e extremamente crıtico (≤ 1ms), em
geral aplicacoes de controle de eixo, utiliza-se o canal IRT.
23
Figura 3.2: Diferentes tipos de processos e sua criticidade.
Se tratando de aplicacoes, definimos tres tipos de dispositivos diferentes:
• IO-Controllers sao CLPs. Sao os Mestres da rede, ou seja, os responsaveis por
estabelecer as conexoes com os outros dispositivos, trocar dados e controlar o
sistema como um todo.
• IO-Device sao os dispositivos escravos, que sao atribuıdos a um Mestre com a
finalidade de receber e enviar dados de uma parte do processo.
• IO-Supervisor sao as estacoes de engenharia responsaveis pela programacao,
comissionamento e diagnostico da rede e dos seus elementos.
3.4 Comunicacao entre Dispositivos em uma
Rede PROFINET
Dispositivos conectados em uma mesma rede PROFINET podem se comunicar de
duas formas: utilizando blocos GET e blocos PUT ou atraves da funcionalidade
I-Device.
Uma terceira forma, utilizando os comandos TSEND e TRCV permite, de uma
forma mais abrangente, que dispositivos com porta de comunicacao PROFINET
se comuniquem com qualquer outro tipo de dispositivo em uma rede Ethernet In-
dustrial. Esse tipo de comunicacao nao sera abordado no presente trabalho, mas e
importante que o leitor saiba da sua existencia. O uso desse tipo de comunicacao
e chamado de OPC (Open Platform Communications) e se faz necessario quando e
preciso comunicar CLPs Siemens com CLPs e supervisorios de outros fabricantes.
[4]
24
3.4.1 Bloco GET e Bloco PUT
Os blocos GET e PUT utilizam o sub-protocolo S7Comm, baseado no ISO TCP
(RF 1006). O S7Comm opera nas camadas de sessao, apresentacao e aplicacao do
modelo OSI, e e usado nao so para comunicacao entre CLPs, mas tambem para o
acesso de dados de CLPs por sistemas SCADA.
Cada bloco GET/PUT consiste em:
• Um cabecalho.
• Um conjunto de Parametros.
• Um Data Block.
Ambos os blocos funcionam da seguinte forma: Apontam para um banco de
dados proprio (Data Block), especificam um tipo de dado e o endereco de inıcio
desse dado e leem/escrevem no banco de dados do CLP parceiro.
O comando do bloco PUT, por exemplo, pode ser traduzido de forma extensa:
“Escreva esse dado no Banco de dados do parceiro a partir do endereco
0.0.”
Enquanto que a sequencia de comandos do bloco GET pode ser traduzida, por
exemplo, como:
“Leia esse dado do Banco de dados do parceiro a partir do endereco 1.0.”
3.4.2 I-Devices
Um IO Device e um dispositivo de campo, em geral remotas, responsavel por coletar
e enviar sinais processados por IO Masters. Sao dispositivos sem capacidade de
processamento, mas com funcionalidades de rede. Pode-se dizer que sao extensoes
dos sinais de entrada e saıdas dos CLPs.
I-Device deriva de ”Intelligent CPU as IO-Device”, ou seja, com essa funcionali-
dade pode-se comunicar com dispositivos com capacidade de de processamento como
se fossem IO-devices. Isso e util pois alem do ganho de engenharia em programacao
descentraliza-se parte do processamento dos controladores principais, implicando em
ganhos em diferentes aspectos, como:[4]
• A capacidade de processamento dos CLPs e limitada, de forma que a descen-
tralizacao de processos se faz necessaria em casos onde as tarefas de automacao
sao extensas e complexas.
25
• O processamento de uma automacao pode ser dividido em tarefas menores
ou em subprocessos simplificados. Os ganhos na facilidade de operar e de
diagnosticar falhas nesse tipo de topologia sao consideraveis.
• Pode-se separar processos maiores e complexos em subprocessos, que podem
ser salvos como projetos individuais e depois agrupados para se formar um
mesmo projeto maior.
O uso de I-Devices permite a comunicacao rapida e de facil configuracao entre
controladores, ao mesmo tempo e atraves do mesmo barramento. Alem disso, ao
estar conectada em uma mesma rede PROFINET, a imagem gerada por um I-Device
pode ser acessada por qualquer dispositivo conectado em qualquer ponto de acesso
da rede. O exemplo a seguir ilustra uma aplicacao onde o uso de I-Devices se mostra
bastante util:
Exemplo: Em um Trem, cada carro tem um CLP como I-Device. Um CLP dedi-
cado e utilizado como controlador central para todos os carrinhos. Toda automacao
dos carrinhos no sistema pode ser projetada usando uma configuracao de hardware
identico mas com enderecamento individual para cada carrinho. Assim, cada carro
e tratado na rede com um nome proprio e como um dispositivo unico. Isso ajuda
a economizar tempo para a engenharia e custos de comissionamento porque apenas
duas configuracoes de hardware independentes sao necessarios - um para os carrinhos
e um para a CPU dedicada.
I-device como IO controller de um subprocesso
Um I-device funcionando como um IO-Device de outros controladores tambem pode
ser configurado como um IO-Controller de outros IO-Devices. Ou seja, o I-Device
pode fazer parte de uma rede de nıvel superior como um IO-Device, e se comportar
como um IO-controler de uma rede de nıvel inferior. A rede de nıvel inferior tambem
pode possuir I-Devices com as mesmas funcionalidade, de modo que pode-se estru-
turar varios nıveis de redes com essa mesma hierarquia. A figura 3.1 exemplifica
essa funcionalidade.
26
Figura 3.3: I-device como IO controller de um subprocesso.
I-Device com funcionalidade de Device compartilhado (Shared-Device)
Um I-Device pode ser compartilhado entre IO-Controllers com a funcionalidade de
Shared-Device. Com isso, podemos designa-lo a um IO-Controller principal e ter
modulos especıficos acessados por outros IO-Controllers da mesma rede PROFINET.
A topologia e representada abaixo. Esse tipo de arquitetura de controle e util
quando precisamos de acesso a modulos especıficos do controlador de um processo.
A flexibilidade proporcionada pelo acesso aos modulos de um I-Device retorna em
economia de hardware distribuıdo, ja que o mesmo I-Device pode ser utilizado como
um mesmo IO-Device para diferentes controladores, que desejam obter informacoes
de modulos especıficos que atendem um mesmo processo. Na figura 3.4 pode-se
observar essa funcionalidade ilustrada.
27
Figura 3.4: I-Device com funcionalidade de Device compartilhado.
3.4.3 Conectando Redes PROFINET e Fieldbus
O protocolo PROFINET permite que se integre redes Fieldbus (PROFIBUS, ASI,
etc...) existentes com redes PROFINET. Os dispositivos conectados a essas redes
fieldbus sao mapeados atraves de dispositivos intermediarios (Proxys) responsaveis
por fazer uma traducao entre protocolos, de forma que pode-se construir redes hi-
bridas entre sistemas Fieldbus e Ethernett. Essa caracterıstica e fundamental para
o desenvolvimento do protocolo, pois a quantidade instalada de dispositivos Field-
bus e grade, e a necessidade de integracao se faz necessaria para que o protocolo
PROFINET aos poucos ganhe espaco na industria. Na figura 3.5, pode-se observar
um exemplo de topologia hıbrida entre redes Fieldbus e PROFINET, atraves de um
IE/PB link, um gateway entre redes Industrial Ethernet e PROFIBUS ,para realizar
a conexao com uma rede PROFIBUS, e um IE/AS-I link , para realizar a conexao
a uma rede ASI.
28
Figura 3.5: Conexao de diferentes redes Fieldbus.
3.4.4 Protocolos de Redundancia
O tempo de producao de um produto esta diretamente relacionado com seu impacto
no mercado, o que faz com que a demanda por plantas de alta disponibilidade seja
cada vez maior. Com a certeza da inexistencia de sistemas imunes a falhas, o que
pode-se fazer e contorna-las. Topologias de redes redundantes em anel produzem
solucoes eficientes nesse aspecto. Quando temos uma topologia em linha, como
a da figura 3.6, qualquer falha em um dos dispositivos roteadores impossibilita a
comunicacao entre os dispositivos conectados atraves dele, gerando uma falha crıtica
que pode ocasionar a interrupcao da planta.
Figura 3.6: Topologia em linha
Sistemas conectados em topologia de anel sob o protocolo MRP(Media Redun-
29
dancy Protocol), como no exemplo da figura 3.7, resolvem esse problema. Esse tipo
de topologia pode ser implementado tanto com roteadores, ou atraves das portas
PROFINET integradas dos dispositivos. De uma forma ou de outra, se algum dos
dispositivos em anel falhar, existe um caminho alternativo pelo qual a informacao
pode continuar fluindo, minimizando a falha apenas ao dispositivo em que ela ocor-
reu. Isso resulta em uma maior disponibilidade do processo, que durante uma falha,
em vez de ter mais de uma parte do processo comprometida, possui um problema
pontual.
Figura 3.7: Redundancia em anel
O PROFINET faz isso de uma forma simples. Ao estabelecer um anel, escolhe-
mos um dispositivo para ser o supervisor da redundancia (Redudancy Manager). No
supervisor, a comunicacao entre suas duas portas conectadas ao anel e bloqueada,
de forma que o caminho em que a informacao flui e decido por esse dispositivo. Ou
seja, em termos de transmissao de dados, temos uma topologia em linha. O super-
visor de redundancia entao monitora a rede por falhas de comunicacao, enviando 2
telegramas teste , um por cada portas conectadas no anel. Os telegramas circulam
o anel em direcoes opostas, ate chegarem no supervisor novamente. A figura 3.8
ilustra esse processo.
Uma falha pode ser ocasionada pela perda de comunicacao entre 2 dispositivos,
ou pela falha de algum do dispositivos no anel. De toda forma, em caso de falha, os
30
Figura 3.8: Dispositivos Redundantes.
telegramas teste nao chegarao mais ao supervisor, que enxerga isso como uma falha
e passa a habilitar a comunicacao entre suas duas portas internas, antes bloqueada,
criando um novo caminho para que a informacao flua pelos dispositivos saudaveis.
O tempo que o supervisor da redundancia leva para enxergar e corrigir a falha e
chamado de tempo de reconfiguracao. Com o protocolo MRP (Media Redundancy
Protocol), consegue-se atingir tempos de reconfiguracao de ate 200ms quando al-
gum dispositivo individual apresenta falha. Esse tempo de reconfiguracao tem um
limite de 50 dispositivos. Com um numero superior a 50, nao e possıvel garantir
tempos de reconfiguracao menores do que 200ms. Sendo assim, deve-se lembrar
que so e possıvel configurar esse tipo de redundancia em redes PROFINET RT ou
NRT. Para um aumento ainda maior da disponibilidade de plantas grandes e com-
plexas, com processos em diferentes aneis, como o exemplo da figura 3.9, utiliza-se
o casamento redundante de aneis, onde a conexao entre os diferentes aneis possui
2 supervisores, um em operacao (Stand-by Master) e outro em Stad-by (Stand-by
Slave), responsaveis pela interconexao dos aneis. Em caso de falha na interconexao
principal, o supervisor em Stand-by (Stand-by Slave), identifica a falha e entra em
operacao, mantendo a interconexao entre os aneis.
31
Figura 3.9: Redundancia em anel duplo
3.5 PROFIenergy
Processos de automacao sao cada vez mais direcionados para minimizar o consumo
de energia, de forma a reduzir custos e atender as crescentes obrigacoes ambientais,
das quais derivam normas de consumo cada vez mais rıgidas. Os metodos para aten-
der essas obrigacoes vao desde o desligamento manual de maquinas e dispositivos a
instalacao de sistemas de desligamento, que por sua vez sao caros, brutos e inefici-
entes. O PROFINET propoe outra abordagem para o problema: O PROFIenergy.
Desenvolvido para ser um padrao de controle de consumo de multiplos dispositi-
vos conectados em rede, o PROFIenergy permite que controladores (CLPs) enviem
comandos para Unidades de Consumo de Energia (ECU), para sinalizar horarios
de pico de consumo, pausas na producao, horarios de almoco, etc, de forma que o
firmware das ECU identificam os comandos e hibernam os dispositivos durante as
pausas. O resultado do PROFIenergy sao reducoes consideraveis no consumo de
32
energia sem afetar a producao da planta. O exemplo a seguir ilustra uma aplicacao
do PROFIenergy.
Exemplo: Em uma celula robotica, o engenheiro de sistemas implementa uma rotina
de economia de energia baseada em ligar e desligar as maquinas quando ociosas .
Assim, um desligamento apropriado e a sequencia para ativacao podem ser defini-
dos. Se os sistemas estiverem usando a funcionalidade I -Device, plantas completas
ou maquinas individuais podem ser desligados com a mesma facilidade .
33
Capıtulo 4
Comunicacao
O Protocolo PROFINET permite que diferentes CLPs troquem informacoes de di-
ferentes formas. Este capıtulo tem como objetivo abordar essas formas e detalhar
como utiliza-las.
4.1 Criando um Novo Projeto no TIA Portal
Ao abrir o TIA Portal, algumas opcoes aparecem, dentre elas as opcoes de abrir um
projeto existente e criar um novo. Na figura 4.1 pode-se observar essas opcoes.
Figura 4.1: Tela de abertura do TIA Portal V13
Clicando em Create New Project uma janela com os dados do novo projeto se
abre e alguns campos aparecem. Na figura 4.2 pode-se observar esses campos.
34
Figura 4.2: Dados do Projeto
Na figura 4.3, ao preencher os dados e clicar em Create, o projeto sera criado e
uma nova janela aparecera. Entre as opcoes disponıveis, deve-se clicar em Project
View para ter acesso ao ambiente de engenharia.
Figura 4.3: Acessando o ambiente de engenharia
4.2 Adicionando Dispositivos ao Projeto
Agora que o projeto esta criado, o proximo passo e adicionar os dispositivos com
que ira se trabalhar. Aqui pode-se adicionar CLPs, IHMs e PCs ao projeto. Os
outros dispositivos como roteadores, drive e perifericos sao adicionados no proprio
ambiente de engenharia. Na figura 4.4 e possıvel observar este passo.
35
Figura 4.4: Adiconando dispostivos
No presente exemplo utilizou-se uma CPU 1212C como CLP local (PLC-1) e
uma 1214C como PLC remoto (PLC-2). Com a referencia exata da CPU, busca-
se entre os dispositivos disponıveis, seleciona-se a versao de Firmware instalada e
segue-se clicando em OK. Na figura 4.5 esta etapa pode ser observada.
36
Figura 4.5: Adiconando a CPU.
Com os CLPs Local e Remoto criados, a tela de projeto deve ficar como a figura
4.6:
Figura 4.6: Network View dos PLCs criados.
4.3 Bloco GET
A funcao do bloco GET e obter o valor de alguma variavel armazenada em um CLP
remoto e ler seu valor no CLP local. O tipo de variavel inteira utilizada no exemplo
37
representa um valor de entrada analogica. Ou seja, o objetivo sera ler no CLP-1 um
valor de entrada analogica do CLP-2.
4.3.1 Criando uma Conexao S7 entre os CLPs
O proximo passo e criar uma conexao S7 entre os dois CLPs. Em Connections, no
retangulo amarelo da figura 4.7, deve-se selecionar S7-Connection, clicar na porta
Ethernet do CLP local, indicado como CLP-1 na figura 4.7, arrastar e soltar na
porta Ethernet do CLP remoto, indicado como CLP-2. Uma conexao com o nome
de S7-Connection-1 vai ser criada entre os dois CLPs. Outros CLPs tambem
podem ser adicionados a essa conexao. Essa conexao tambem pode ser criada pela
configurador, apontado pelas setas vermelhas.
Uma observacao importante deve ser feita aqui. O retangulo em verde destaca
os diferentes tipos de vistas que temos das redes e dos dispositivos. Em Topology
View encontram-se as conexoes da forma mais detalhada possıvel, ou seja, as co-
nexoes fısicas de cada porta de comunicacao dos CLPs e outros dispositivos. Em
Network View se tem um panorama dos diferentes tipos de redes estabelecidas e
como cada PLC participa dessas redes. Ja em Device View e possıvel observar
cada dispositivo de forma detalhada: seus cartoes de entrada e saıda, cartoes de co-
municacao, fontes de alimentacao, etc. Pode-se fazer uma analogia entre Topologias
Logicas e Fısicas comentadas no capıtulo 2.
38
Figura 4.7: Configurando uma conexao S7 entre os controladores.
4.3.2 Criando Data Blocks
Com a conexao S7 estabelecida, o passo seguinte e adicionar um bloco GET ao OB1
do PLC-1. Para isso, deve-se acessar o OB1 do CLP-1 e na tabela de ferramentas a
direita, em Connection, S7-Communication, seleciona-se o bloco GET e o adiciona
a rede desejada do OB1 do CLP-1. Nas figuras 4.8 e 4.9 observa-se essa etapa.
39
Figura 4.8: Selecionando o Bloco GET.
Figura 4.9: Selecionando o Bloco GET.
A seguir, na figura 4.10, pode-se observar o bloco GET e sua estrutura, que sera
explicada ao longo dos proximos passos.
40
Figura 4.10: Estrutura do Bloco GET
O proximo passo consiste em criar um Data Block para cada um dos dois CLPs.
O Data Block nada mais e do que um banco de dados, onde serao armazenadas as
variaveis que queremos transferir do CLP remoto para o local. Para isso, deve-se
acessar a pasta Program Blocks de cada um dos CLPs, clicar em Add New Block e
escolher na lista de blocos o Data Block, ou DB. As imagens 4.11 e 4.12 sao referente
ao CLP remoto (CLP-2). Deve-se repetir o procedimento para o CLP local. O
nome do bloco e de livre escolha, desde que nao existam Data Block com o mesmo
nome no mesmo CLP. Nas configuracoes do Data Block, deve-se desmarcar o campo
Optimized Block Acess. Essa funcao e padrao dos CLPs e otimiza o gerenciamento
dos enderecos das variaveis dos blocos, que passam a nao ter um endereco fixo.
Como ira se trabalhar com ponteiros, e preciso que esses enderecos sejam absolutos,
e desmarcar essa opcao permite isso.
41
Figura 4.11: Desablitando o Optmized Block Acess.
Figura 4.12: Adicionando um Data Block.
O proximo passo e adicionar uma variavel aos Data Blocks criados. No exemplo
utilizou-se uma variavel do tipo inteira (Int). Se o objetivo fosse a obtencao de um
valor de um sinal de uma entrada digital, por exemplo, bastaria utilizar uma variavel
do tipo boleana. Novamente as figuras 4.13 e 4.14 sao referidas ao PLC-2, ou seja,
deve-se repetir o procedimento no Data Block do CLP-1. O campo star value se
refere ao byte do Data Block em que a informacao esta alocada. No exemplo, o byte
AnalogInput2 se inicia no byte 0 e termina no byte 1, mais precisamente no bit 1.7.
42
Figura 4.13: Criando uma variavel no Data Block.
Figura 4.14: Criando uma variavel no Data Block.
4.3.3 Parametrizando o Bloco GET
Com as variaveis criadas, o proximo passo e parametrizar o Bloco GET. Para isso,
deve-se acessar o OB1, abrir a rede onde o bloco GET foi adicionado e clicar no
bloco. Na aba Configuration existem duas partes a serem configuradas: Connection
e Block Parameter. Em Connection, seleciona-se o CLP parceiro do qual deseja-se
obter os dados e a porta PROFINET pela qual ele esta conectada. Na lista de
possıveis parceiros serao exibidos apenas CLPs que estejam na mesma rede S7. A
figura 4.15 demonstra esse passo:
43
Figura 4.15: Selecionando a CPU Partner.
Com a conexao estabelecida, o parametro ID do bloco ira automaticamente pre-
encher a informacao Conection ID das configuracoes, que corresponde ao canal da
conexao S7 exclusivo para a comunicacao entre os dois CLPs. O Padrao desse
parametro e 100. O preenchimento deste parametro pode ser observado na figura
4.16
44
Figura 4.16: Connection ID
O campo REQ do bloco e o parametro de chamada do bloco. O trabalho de
comunicacao inicia quando o sinal de chamada tem uma borda positiva e nenhum
outro trabalho esta em curso. A comunicacao e assıncrona, ou seja, pode durar
diversos ciclos. E preciso atentar para possıveis chamadas constantes do bloco antes
que o trabalho de comunicacao em curso termine, o que pode causar uma sobrecarga
na comunicacao.
Diversos tipos de sinais podem ser usados para habilitar o bloco. Pode-se, por
exemplo, utilizar um evento, como o acionamento de um botao, para chamar o bloco.
Mas, de forma geral, sao utilizados Clocks de memoria para isso. Pode-se reservar
um espaco na memoria para isso. E possıvel escolher um byte e seus 8 bits para
que correspondam a diferentes frequencias de Clock, mas e preciso habilita-los. Nas
configuracoes do CLP local, ou seja, no qual o bloco GET esta, em System and
clock memory, a opcao Enable the use of memory byte. Na figura 4.17, pode-se
observar esse passo. Seleciona-se entao o byte de memoria que se deseja utilizar e
as frequencias de Clock atreladas aos bits desse byte.
45
Figura 4.17: Habilitando o memoria de Clock.
No exemplo em questao utilizou-se um Clock de 0.5Hz. Ou seja, no parametro
REQdo bloco deve-se escrever o endereco M0.7, que corresponde ao Clock desejado.
A figura 4.18 mostra como parametrizar o Clock de chamada do bloco GET.
Figura 4.18: Selecionando o Clock de chamada do bloco.
O parametro ADDR 1, Read Area, e um ponteiro para a area do PLC remoto
que se deseja ler. Existem tres campos a serem preenchidos: de onde se vai buscar
46
essa informacao do PLC remoto, o tamanho da informacao, e por ultimo o tipo de
dado.
Figura 4.19: Configurando a Area de Leitura
No presente exemplo o objetivo e ler uma variavel do tipo INT do Data Block
1 (DB1) do CLP remoto. Esse dado comeca no bit 0.0 e vai ate o bit 1.7, ou seja,
e um INT de comprimento 1, ja que cada dado do tipo INT possui 2 bytes de
comprimento. Na figura 4.19 pode-se ver como fica o preenchimento dos parametro
do ponteiro:
47
Figura 4.20: Configurando a Area de leitura.
O campo RD 1 e o ponteiro, no CLP local, onde sera armazenada a informacao
lida do CLP remoto. Os parametros a serem preenchidos sao os mesmos da Read
Area. Como se deseja armazenar a informacao tambem no byte 0 e 1 do DB1
do PLC local, o campo do ponteiro do PLC local fica identico ao do ponteiro do
PLC remoto. Isso e apenas para o exemplo aqui demonstrado, e em geral esses
enderecos sao diferentes. Os parametros em azul sinalizam que os parametros sao
validos. Quando em vermelho, o campo possui algum erro e deve ser verificado
antes de compilar o programa. Na figura 4.21, o campo Store Area esta marcado
pelo retangulo vermelho.
48
Figura 4.21: Configurando a Area de Armazenamento
Os campos ERROR e STATUS auxiliam no diagnostico de erros. O parametro
ERROR e um sinal de saıda de 1 bit. Quando ha algum erro seu estado e 1.
Quando nao ha erros, 0. Ja o STATUS e uma variavel de saıda do tipo Word, e
disponibiliza o status do bloco em hexadecimal. Os codigos de erro e o respectivo
diagnostico podem ser observados na tabela 4.1:
Tabela 4.1: Codigos de Erro do bloco GET
ERROR STATUS(Dec) Diagnostico
0 11Novo trabalho nao esta ativo pois o
anterior ainda nao foi concluıdo
0 25 Comunicacao Iniciada
1 1Problemas de conexao, como por exemplo:
Conexao interrompida ou dados da conexao incorretos
1 2 Conexao com o CLP paceiro nao efetuada
1 4Esses erros se referem a erros nos enderecos dos
ponteiros ou na configuracao dos Data Blocks
1 8 Erro de acesso ao CLP paceiro
1 10 O acesso a memoria de usuario do PLC local nao foi possıvel
1 20 Numero maximo de trabalhos em paralelo excedido
49
Figura 4.22: Bloco GET com os parametros completo
Para diagnosticar o erro, e preciso criar uma armadilha para a variavel de status.
Para isso, criam-se uma variavel de ERROR, e duas de STATUS: uma que ficara no
bloco GET e outra na saıda do bloco MOVE, que e ativado pela borda de subida
do sinal de erro e transfere o sinal do STATUS do bloco GET para o valor STATUS
retido. A figura abaixo demonstra como se faz isso. Como o sinal de erro nao e
constante, ou seja, ele acontece apenas em uma das vezes, devido a frequencia de
ativacao do bloco ser bem rapida, e preciso aprisionar o sinal de STATUS quando o
erro ocorre, para poder observa-lo.
Caso se deseje utilizar a informacao obtida do CLP remoto em uma saıda fısica do
CLP local, utiliza-se o bloco MOVE, como na figura a seguir. O bloco MOVE tem
como objetivo justamente mover um valor de uma variavel para outra. No exemplo,
o objetivo era obter os dados de uma entrada analogica de um CLP remoto, transferir
o valor para o CLP local e imprimir esse valor em uma saıda analogica. A figura 4.23
demonstra o local da biblioteca de blocos em que o bloco MOVE esta localizado.
50
Figura 4.23: Inserindo o Bloco Move
As figuras 4.24 e 4.25 mostram a estrutura dos blocos MOVE dos CLPs remoto
e local.
Figura 4.24: Bloco Move do CLP remoto.
Figura 4.25: Bloco Move do CLP Local.
Os parametros ERROR e STATUS sao informacoes utilizadas para diagnosticar
quando uma falha ocorre. O valor do ERROR e 0 ou 1, ou seja, sem falhas ou com
falhas. Ja o status retorna um valor hexadecimal.
51
4.4 Bloco PUT
No bloco GET o objetivo era ler uma informacao de um CLP remoto. O bloco PUT
tem como objetivo escrever uma informacao em um CLP remoto. A parametrizacao
do bloco e identica, mas ao inves de uma Area de Leitura e outra de Armazenamento,
tem-se os ponteiros Area de Escrita (Write Area, ADDR 1) e Area de Envio (Send
Area, SD 1). Na imagem 4.26 pode-se observar o preenchimento desses parametros.
Figura 4.26: Parametros Send Area e Write Area do Bloco PUT.
Na figura 4.27, o bloco PUT completo pode ser observado.
Figura 4.27: Bloco PUT com os parametros completos.
4.5 Comunicacao I-Device
A funcao de I-Device pode ser utilizada para a troca de dados entre dois CLPs
de forma simples. Um I-Device e um PLC que e utilizado como um IO-Device
inteligente. Essa funcao e adequada para solucoes onde diversos controladores se
encontram conectados em uma mesma rede e podem se beneficiar disso.
No presente exemplo sera demonstrado como fazer a troca de dados entre dois
CLPs, sendo um deles um IO-Controller e outro um I-Device. Apesar da fabricante
nao utilizar o nome de Mestre-Escravo, esse conceito, herdado do PROFIBUS, con-
52
tinua a existir. Utizou-se um CLP S7-1500 como IO-Controller e um S7-1200 como
I-Device.[5]
4.5.1 Habilitando a funcionalidade de I-Device
O primeiro passo e habilitar a funcao de I-Device no CLP que deseja-se realizar essa
funcao. No presente caso, o S7-1200. Para isso, acessa-se as configuracoes do CLP,
e em Profinet Interface, Operating Mode, a opcao IO Device deve estar assinalada.
Abaixo dessa opcao, existe um campo onde e designado um IO-Controller para o
I-Device. Seleciona-se o S7-1500 e assinala-se um numero, o Device number. Esse
numero e endereco do I-Device conectado ao IO-Controller. Cada I-Device conectado
a um mesmo IO-Controller deve possuir um Device number proprio.
A opcao Parameter assigment of PN interface by High-Level IO Controller deve
estar marcada caso se deseje que a configuracao dos parametros de comunicacao do
I-Device seja feita a partir do IO-Controller, de forma automatica.
A opcao Prioritized Startup e uma funcao do PROFINET que acelera o restabe-
lecimento da conexao de um I-Device, diminuindo o tempo necessario para que os
I-Devices voltem a participar da comunicacao cıclica da rede PROFINET apos uma
queda de energia ou problemas na rede.
A figura 4.28 e 4.29 apresentam esses parametros.
Figura 4.28: Configuracao do CLP I-Device.
53
Figura 4.29: Configuracao do CLP I-Device.
4.5.2 Conectando os PLCs
O proximo passo e estabelecer a conexao entre os dois CLPs. Com os CLPs adi-
cionados ao programa, deve-se acessar Network View, clicar na porta PROFINET
do CLP local e coneta-la ao CLP parceiro. Uma rede, designada de PN/IE 1 como
padrao, sera estabelecida. A figura 4.30 ilustra essa etapa.
Figura 4.30: Conexao entre os CLPs.
A seguir, deve-se configurar o IO Cycle, que consiste no tempo de atualizacao e
de monitoramento de falha do I-Device. Na aba Real Time Settings se tem acesso
a esses parametros. O tempo de atualizacao consiste no intervalo de tempo cıclico
em que o I-Device vai enviar as informacoes da Area de Transferencia para o IO-
Controller, enquanto que Watchdog Time e o tempo de ciclo vezes a quantidade de
ciclos sem informacoes antes que uma falha seja declarada, ou seja, e o tempo em
que aceita-se que o I-Device nao envie nenhuma informacao. Passado esse tempo e
assumido que o CLP entrou em algum Loop, ou ocorreu algum outro tipo de falha
no processador. O CLP entao tem seu processador reiniciado. A figura 4.31 mostra
esses parametros.
54
Figura 4.31: Configurando o IO Cycle
4.5.3 Configurando as Areas de Transferencia
Por ultimo, novamente em Operating Mode, criam-se as Areas de Transferencia , ou
Transfer Areas. A Area de Transferencia e uma parte do endereco logico destinado a
troca de dados entre o I-Device e seu IO-Controller. Cada troca de dado corresponde
a uma Area de Transferencia diferente. O fluxo de dados e fixo, ou seja, em cada
area de transferencia a informacao flui ou do I-Device para o IO-Controller, ou do
IO-Controller para o I-Device. A taxa mınima de transferencia e de 1 byte, ou
seja, os CLPs estarao sempre transferindo ou recebendo pelo menos um byte de
informacao. A partir desse byte, e possıvel obter apenas parte da informacao, caso
a informacao desejada seja menor do que 1 byte.
A Area de Transferencia e uma das razoes pela qual o uso de comunicacao por
I-Devices e mais simples do que o uso de blocos GET/PUT. Em uma mesma area
pode-se observar o fluxo de informacao de uma forma mais pratica.
Na area de transferencia ”1500 para 1200”da figura 4.32, o IO-Controller esta
enviando o byte Q1 para o byte I2 do I-Device e na ”1200 para 1500”o I-Device esta
enviando o byte Q2 para o byte I1 do IO-Controller.
55
Figura 4.32: Area de Transferencia.
4.6 Protocolo de Redundancia
Se tratando de comunicacao industrial, garantir o funcionamento da comunicacao
entre CLPs, drives e outros dispositivos de campo esta diretamente ligado com a
disponibilidade do processo. Mas, como falhas em dispositivos acontecem, o que
se pode fazer e diminuir os efeitos delas. O Protocolo de Redundancia (Media
Redundancy Protocol) garante que o funcionamento de parte do processo nao seja
comprometido por uma falha pontual. Isso e feito atraves da criacao de um anel
PROFINET entre os dispositivos e/ou roteadores.
Na figura 4.33 tres CLPs S7-1500 (1515-2PN) serao ligados em anel e uma re-
dundancia entre eles sera configurada. Os requerimentos para que o protocolo MRP
possa ser utilizado sao:
• Todos os dispositivos que estao no anel devem suportar a funcao de MRP.
• O MRP deve estar ativo para todos os dispositivos do anel.
• Todos os dispositivos devem estar conectados atraves de suas portas PROFI-
NET.
• Pelo menos um dispositivo do anel deve atuar como Supervisor de Redundancia
(Redundancy Manager).
• O anel nao deve conter mais do que 50 dispositivos. Se for o caso, tempos
de reconfiguracao da rede apos alguma falha ocorrer pode ser de mais de 200
milissegundos.
56
• Nenhum dos dispositivos do anel pode possuir a opcao de Inıcio Priorizado
ativa.
O primeiro passo para a configuracao de uma redundancia em anel e acessar a
Network View e conectar os tres CLPs a uma mesma rede PROFINET.
Figura 4.33: Conectando os PLCs a uma mesma rede Profinet.
Em seguida, em Topoly View deve-se conectar as portas dos CLPs em forma de
anel, como na figura 4.34:
Figura 4.34: Conectando os PLCs a uma mesma rede Profinet.
Como toda configuracao em MRP necessita de um administrador do anel, e
preciso designar a funcao para pelo menos um dos CLPs. Como foi explicado na
parte teorica deste trabalho, no supervisor de redundancia a comunicacao entre
suas duas portas conectadas ao anel e bloqueada, de forma que o caminho em que a
informacao flui e decido por esse dispositivo. Ou seja, em termos de transmissao de
57
dados, temos uma topologia em linha. O supervisor de redundancia entao monitora
a rede por falhas de comunicacao, enviando 2 telegramas teste, um para cada porta
conectada no anel. Os telegramas circulam o anel em direcoes opostas, ate chegarem
no supervisor novamente. Caso isso nao ocorra, o supervisor identifica a falha,
desbloqueia a comunicacao entre suas duas portas internas e reorganiza a topologia
da rede.
Precisa-se entao designar um CLP para a supervisao do anel. Para isso, deve-
se escolher o dispositivo e acessar suas configuracoes. Em Advanced Mode, Media
Redudancy, altera-se o parametro Media Redundancy Role para Manager(Auto).
Pode-se observar nas linhas seguintes as portas do CLP participantes do anel. A
ultima opcao, Diagnostic Interrupts deve estar marcada caso se deseje que mensa-
gens de status de diagnostico do anel sejam gerados pelo CLP. Os seguintes status
podem ser configurados:
• Erro na Porta (Clientes e Supervisores): Status de erros sao gerados caso uma
das portas do PLC esteja conectado a um vizinho que nao suporta MRP, que
uma porta do anel esta conetada a um outra porta que nao esta no anel ou a
uma porta de um outro anel.
• Interrupcao/Retorno(apenas o PLC supervisor): Caso um dispositivo do anel
falhe, e retorne, um status de erro vai ser gerado.
Na figura 4.35 pode-se observar a configuracao dos supervisores do anel
Figura 4.35: Configurando o Ring Manager.
Os dispositivos que nao se deseja designar o papel de supervisor devem ser con-
figurados como clientes, como na figura 4.36:
58
Figura 4.36: Configurando os clientes.
Por ultimo, ao acessar as configuracoes da Rede PROFINET estabelecida entre
os CLPs, em Domain Management, MRP domains, pode-se observar, como na figura
4.37, todos os aneis estabelecidos nessa rede. Ao acessar o anel desejado, tem-se o
panorama geral do anel:
Figura 4.37: Visao geral de uma configuracao MRP.
59
Capıtulo 5
Exemplo de Aplicacao
Para demonstrar as funcionalidades dos formas de comunicacao apresentadas no
capıtulo anterior, um exemplo de aplicacao envolvendo alguns CLPs foi criada. O
objetivo e demonstrar o funcionamento da comunicacao tanto pela funcionalidade
I-Device quanto atraves dos blocos GET e PUT.
No exemplo foram utilizados tres CLPs:
• 1214C DC/DC/Relay
• CPU 1513-1 PN
• CPU 1516-3 PN
Alem dos PLCs, utilizou-se duas IHMs para demonstracao do trafego de dados :
• IHM KTP600 Basic PN
• IHM KTP700 Basic PN
O objetivo desse exemplo e utilizar os conhecimentos apresentados na sessao 3
para testar a comunicacao entre o PLC 1513 e o 1214C atraves de blocos GET/PUT,
e entre o PLC 1513 e o 1516 utilizando-se as Areas de Transferencia da funcionalidade
I-Device. A figura 5.1 apresenta o conceito da aplicacao proposta.
60
Figura 5.1: Proposta de aplicacao
A aplicacao pode ser dividida em duas etapas. Na primeira parte e feita a
configuracao da comunicacao do bloco GET no CLP 1513 que ira obter os dados do
CLP 1214. O dado que se deseja obter e do tipo inteiro, esta alocado no banco de
dados DB1 do CLP 1214 e tem seu valor de entrada mostrado na IHM. A figura
5.2 ilustra essa etapa.
Figura 5.2: Obtendo o valor inteiro do CLP 1214 atraves do bloco GET
Na segunda parte, A CPU 1516 e configurada como I-Device da CPU 1513
e a Area de Transferencia e configurada para enviar um dado do tipo byte de
comprimento 1 do CLP 1513 para o CLP 1516, e em seguida mostrar esse dado na
IHM do CLP 1516. A figura 5.3 ilustra essa etapa.
61
Figura 5.3: Enviando o valor de uma tag do tipo byte atraves da Area de Trans-
ferencia do I-Device
Apos a configuracao dos blocos e da Area de Transferencia, a Topology View
deve estar conectada da forma apresentada na figura 5.4:
Figura 5.4: Topology View da aplicacao
A Network View deve estar configurada como mostra a figura 5.5
62
Figura 5.5: Network View da aplicacao
63
Capıtulo 6
Conclusao
O trabalho desenvolvido nesse projeto de fim de curso teve como principal objetivo
demonstrar as formas de comunicacao entre diferentes dispositivos conectados em
PROFINET, atraves de um tutorial. Para isso, foram abordados conceitos de redes
e aspectos particulares do PROFINET. Como demonstracao das funcionalidades
abordadas no trabalho, uma implementacao pratica foi desenvolvida.
Considerando a importancia das redes para as plantas industriais modernas,
e o impacto que falhas em um sistema de comunicacao causam a uma fabrica e
industria, os conceitos de redundancia e topologias de alta disponibilidade tambem
foram aspectos importantes do trabalho.
Com o auxılio do tutorial de comunicacao desenvolvido, alunos do curso e do
laboratorio de controle e automacao poderao obter auxılio no desenvolvimento de
projetos de automacao.
64
Referencias Bibliograficas
[1] REYNDERS, D. Practical TCP/IP and Ethernet Networking. 1 ed. Oxford,
Elsevier, 2003.
[2] NEUHAUS, R. A Beginner’s Guide to Ethernet 802.3. 1 ed. O’Reilly Me-
dia, 2005. Disponıvel em <http://www.analog.com/media/en/technical-
documentation/application-notes/EE-269.pdf>.
[3] CHARLES E. SPURGEON, J. Z. Ethernet: The Definitive Guide. 2 ed. ,
O’Reilly Media, 2014.
[4] SIEMENS. PROFINET With STEP7 V13. 2014. Disponıvel em
<https://cache.industry.siemens.com/dl/files/856/49948856/att -
38388/v1/profinet step7 v13 function manual en-us.pdf>.
[5] PRUDENTE, F. PLC S7-1200: Teoria e Aplicacoes. 1 ed. Rio de Janeiro, LTC,
2004.
65