modelo de dissertação/tese - dainfcristina/pmon.pdf · porque amigo não se pede, não se compra,...

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA

CURSO DE TECNOLOGIA EM DESENVOLVIMENTO DE SISTEMAS DISTRIBUÍDOS

CRISTIAN DE CONTO LEONARDO BECHER DE SOUZA

PROPOSTA DE DESENVOLVIMENTO DE APLICATIVO DE COMUNICAÇÃO PARA SHOPFLOOR AUTOMOTIVO

TRABALHO DE CONCLUSÃO DE CURSO

CURITIBA 2010

Cristian De Conto Leonardo Becher Souza

PROPOSTA DE DESENVOLVIMENTO DE APLICATIVO DE COMUNICAÇÃO PARA SHOPFLOOR AUTOMOTIVO

Trabalho de Conclusão de Curso de graduação, apresentado à disciplina de Trabalho de Diplomação, do Curso Superior de Tecnologia em Desenvolvimento de Sistemas Distribuídos do Departamento Acadêmico de Informática – DAINF – da Universidade Tecnológica Federal do Paraná– UTFPR, como requisito parcial para obtenção do título de Tecnólogo

Orientador: Leandro Batista de Almeida

Co-Orientadora: Ana Cristina Kochem Vendramin

Curitiba 2010

____________________________________________________ 4

AUTOPSICOGRAFIA BONS AMIGOS Abençoados os que possuem amigos, os que os têm sem pedir. Porque amigo não se pede, não se compra, nem se vende. Amigo a gente sente! Benditos os que sofrem por amigos, os que falam com o olhar. Porque amigo não se cala, não questiona, nem se rende. Amigo a gente entende! Benditos os que guardam amigos, os que entregam o ombro pra chorar. Porque amigo sofre e chora. Amigo não tem hora pra consolar! Benditos sejam os amigos que acreditam na tua verdade ou te apontam a realidade. Porque amigo é a direção. Amigo é a base quando falta o chão! Benditos sejam todos os amigos de raízes, verdadeiros. Porque amigos são herdeiros da real sagacidade. Ter amigos é a melhor cumplicidade! Há pessoas que choram por saber que as rosas têm espinho, Há outras que sorriem por saber que os espinhos têm rosas!.

Machado de Assis

Dedico esta tese aos meus pais que apoiaram em todas as decisões da minha vida e aos meus amigos e todos que desejam e trabalham por um mundo melhor.

____________________________________________________ 5

AGRADECIMENTOS

A todos os professores do curso de Tecnologia em Desenvolvimento de

Sistemas Distribuídos que nos guiaram pelos semestres letivos sempre com total

dedicação.

Aos colegas de classe que compartilharam suas experiências,

conhecimentos e conselhos, sem os quais certamente hoje não estaríamos tão

satisfeitos pessoalmente.

Aos colegas da T-Systems Brasil LTDA que nos apoiaram e ajudaram a

entender como funciona o sistema de controle e produção de veículos da

Volkswagen Audi Brasil LTDA, em especial ao Gabriel Schön pela ajuda prestada no

desenvolvimento do sistema PMON.

Ao nosso gestor Fábio Siqueira que nos ajudou a concretizar a idéia de

desenvolvimento desse sistema e a todos que direta ou indiretamente colaboraram

na execução deste trabalho.

____________________________________________________ 6

RESUMO

O principal objetivo do projeto é criar um aplicativo dedicado baseado em

regras e princípios de um protocolo desenvolvido pela Volkswagen. Esta aplicação

permite estabelecer conexões e proporcionar o intercâmbio de informações entre os

Sistemas de Controle de Produção do grupo Volkswagen e equipamentos

considerados shopfloor (interfaces).

O número crescente de equipamentos para atender a demanda de produção

requer a aplicação de um protocolo para proporcionar o intercâmbio de informações

entre diferentes sistemas. O objetivo deste projeto é o desenvolvimento deste

aplicativo, deixando para as empresas que implantam novos equipamentos a

responsabilidade de apenas instalá-lo.

Palavras chaves: Controle de Produção, Protocolo, Equipamentos.

____________________________________________________ 7

ABSTRACT

The project's main objective is to create a dedicated application based on

rules and principles of a protocol developed by Volkswagen. This application will

establish connections and provide information exchange between the Production

Control Systems from Volkswagen group and the equipment considered Shopfloor

(interface).

The increasing number of equipments to assist the production control

demands the development of a protocol to provide information exchange between

different systems. The objective of this project is the development of this application,

leaving to the third-part companies the responsibility of just installing the equipment

as well as the application developed.

Key words: Production Control, Protocol, Equipment.

____________________________________________________ 8

LISTA DE FIGURAS

Figura 1: Sequência de comunicação na Volkswagen ................................. 17

Figura 2: Detalhe dos processos de comunicação ....................................... 19

Figura 3: Caso de uso PMON ...................................................................... 26

Figura 4: Caso de Uso SendOpen ............................................................... 27

Figura 5: Caso de uso AcknowledgeOpen ................................................... 28

Figura 6: Caso de Uso SendData ................................................................. 29

Figura 7: Caso de Uso AcknowledgementData ............................................ 31

Figura 8: Caso de Uso SendClose ............................................................... 32

Figura 9: Caso de Uso AcknowledgeClose .................................................. 33

Figura 10: Diagrama de Sequência SendOpen e AcknowledgeOpen .......... 35

Figura 11: Diagrama de Sequência SendData e AcknowledgeData ............ 36

Figura 12: Diagrama de Sequência SendClose e AcknowledgeClose ......... 37

Figura 13: Diagrama de Colaboração .......................................................... 38

Figura 14: Diagrama de Estrutura de Módulos ............................................. 39

Figura 15: Diagrama de Estados – SendOpen ............................................. 40

Figura 16: Diagrama de Estados – SendData .............................................. 40

Figura 17: Diagrama de Estados – SendClose ............................................ 41

Figura 18: Representaçao Modelo OSI , TCP/IP e Sistema proposto. ......... 44

Figura 19: Diagrama de Classe .................................................................... 61

Figura 20: Conexão via emissor ................................................................... 62

Figura 21: Conexão via receptor .................................................................. 62

Figura 22: Transmissão dos dados .............................................................. 62

Figura 23: Fechar conexão via emissor ....................................................... 63

Figura 24: Fechar conexão via receptor ....................................................... 63

Figura 25: Conflito no pedido da conexão .................................................... 64

Figura 26: Conflito no envido do bloco de mensagem ................................. 64

Figura 27: Conflito no pedido de fechamento de conexão ........................... 64

Figura 28: Elemento desconhecido no telegrama ....................................... 65

Figura 29: Elemento desconhecido no telegrama ........................................ 65

Figura 30: Imagem SendData ...................................................................... 73

Figura 31: Imagem Send Data ..................................................................... 73

____________________________________________________ 9



Figura 34: Acknowledge fhudp ..................................................................... 73

____________________________________________________ 10

LISTA DE TABELAS

Tabela 1: Levantamento equipamentos Curitiba .......................................... 23

Tabela 2: Levantamento equipamentos Taubaté ......................................... 23

Tabela 3: Levantamento equipamentos Anchieta ........................................ 23

Tabela 4: Equipamentos de desenvolvimento .............................................. 23

Tabela 5: Equipamento de testes ................................................................. 24

Tabela 6: Descrição Caso de Uso SendOpen .............................................. 27

Tabela 7: Descrição Caso de uso AcknowledgeOpen ................................. 28

Tabela 8: Descrição Caso de Uso SendData ............................................... 29

Tabela 9: Descrição Caso de Uso Acknowledment Data ............................. 31

Tabela 10: Descrição Caso de Uso SendClose ........................................... 32

Tabela 11: Descrição Caso de Uso AcknowledgeClose .............................. 34

Tabela 12: Sequência de mensagens .......................................................... 43

Tabela 13: Pedido para abrir submissão ...................................................... 66

Tabela 14: Acknowledge para abertura de submissão ................................. 67

Tabela 15: Pedido para fechar submissão ................................................... 69

Tabela 16: Acknowledge ao fechar submissão ............................................ 70

Tabela 17: Enviar bloco de dados ................................................................ 71

Tabela 18: Acknowledge ao enviar um bloco de dados ............................... 72

____________________________________________________ 11

LISTA DE ABREVIATURAS E SIGLAS

Bps: bits por segundo.

DCP: Data Capture Point

FIS: Sistema de Controle de Produção Automotivo

JVM: Java Virtual Machine

LAN: Local Area Network

Mps: Megabits por segundo

OSI: Open Systems Interconnection

PLC: Programmable Logic Controller

PMON: Protocolo de monitoramento

TCP: Transmission Control Protocol

UDP: User Datagram Protocol

DLE: Data Link Escape

ETX: End of Text

STX: Start of Text

ACK: Acknowledge

SSNR: Sender Submission Number

RSNR: Receiver Submission Number

____________________________________________________ 12

SUMÁRIO

1 INTRODUÇÃO .............................................................................. 14

1.1 APRESENTAÇÃO ..................................................................... 15

1.2 JUSTIFICATIVA DA ESCOLHA DO TEMA ............................... 16

1.3 OBJETIVOS DO TRABALHO ................................................... 16

2 LEVANTAMENTO BIBLIOGRÁFICO E ESTADO DA ARTE ....... 17

2.1 PROTOCOLO UDP .................................................................... 18

2.2 PROTOCOLO TCP .................................................................... 18

2.3 PLC (PROGRAMMABLE LOGIC CONTROLLER) ................... 19

2.4 DESCRIÇÃO DOS APLICATIVOS FIS ...................................... 19

2.4.1 DAE (Distributed Application Environment) ................... 20

2.4.2 EM (Event Manager) .......................................................... 20

2.4.3 KH (Kanal-Handler) ........................................................... 20

2.4.4 PMON-UDP......................................................................... 21

3 METODOLOGIA ........................................................................... 22

3.1 ESTUDO DO CASO ................................................................... 22

3.2 LEVANTAMENTO DE DADOS .................................................. 22

3.3 EQUIPAMENTOS UTILIZADOS PARA DESENVOLVIMENTO 23

3.4 EQUIPAMENTOS UTILIZADOS PARA TESTE ........................ 24

3.5 CUSTO DE DESENVOLVIMENTO ............................................ 24

4 RESULTADOS .............................................................................. 25

4.1 MODELAGEM ............................................................................ 25

4.1.1 Descrição Da Arquitetura ................................................. 25

4.1.2 Diagrama De Classe .......................................................... 25

4.1.3 Diagramas De Caso De Uso ............................................. 25

4.2 DIAGRAMAS DE SEQUÊNCIA ................................................. 34

4.2.1 Send Open (SO) e Acknowledge Open (AO) ................... 35

4.2.2 Send Data (SD) e Acknowledge Data (AD) ...................... 36

4.2.3 Send Close (SC) e Acknowledge Close (AC) .................. 36

4.3 DIAGRAMAS DE COLABORAÇÃO .......................................... 37

4.4 DIAGRAMA DE ESTRUTURA DOS MÓDULOS ....................... 38

4.5 DIAGRAMA DE TRANSIÇÃO DE ESTADOS ........................... 39

4.6 REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS ................... 41

____________________________________________________ 13

4.7 TRANSMISSÃO DE DADOS ..................................................... 43

4.7.1 FHUDP – Descrição Do Protocolo ................................... 44

4.8 PROTOCOLO PMON ................................................................. 47

4.8.1 Abrindo Uma Submissão ................................................. 47

4.8.2 Fechando Uma Submissão .............................................. 47

4.8.3 Transferindo Um Telegrama............................................. 48

4.9 ELEMENTOS DO PROTOCOLO PMON ................................... 48

4.10 AMOSTRA DA COMUNICAÇÃO ............................................ 49

5 DESCRIÇÃO DO PROGRAMA PMON ......................................... 50

5.1 ORDENS ORGANIZACIONAIS ................................................. 50

5.2 ORDENS DE USO ..................................................................... 51

5.3 ORDENS DE COMUNICAÇÃO .................................................. 51

5.4 TELEGRAMAS SO-AO .............................................................. 52

5.5 TELEGRAMAS SD-AD .............................................................. 54

5.6 TELEGRAMAS SC-AC .............................................................. 55

6 IMPLANTAÇÃO ............................................................................ 57

6.1 RESULTADOS DA IMPLANTAÇÃO ......................................... 57

7 CONCLUSÃO ............................................................................... 58

7.1 CONTRIBUIÇÕES ..................................................................... 59

7.2 TRABALHOS FUTUROS ........................................................... 59

8 REFERÊNCIAS ............................................................................. 60

____________________________________________________ 14

1 INTRODUÇÃO

Atualmente, no grupo Volkswagen, um grande número de equipamentos e

sistemas realiza troca de informações com o sistema de controle de produção FIS,

para que estas informações possam transitar corretamente foram criadas regras e

padrões que chamados de protocolo de comunicação. Cada sistema ou grupo de

equipamentos possui um protocolo que fará interpretação de determinada rotina e

realizará determinada ação.

Através desta premissa, conseguimos determinar que o protocolo PMON

utilizado para comunicação entre equipamentos de shopfloor poderia ser explorado

para possível implementação e assim ofertar mais um produto ao grupo Volkswagen.

É comprovado que o número de centrais de comunicação entre o controle de

produção e a área de processamento de dados cresce continuamente. O FIS é o

sistema que centraliza todos estes dados, ou seja, sua tarefa é associar diferentes

aplicações a partir de várias plataformas, através de um protocolo uniforme de

transmissão e recepção de dados, o PMON.

O sistema baseia-se no protocolo de comunicação PMON onde varias

conexões lógicas em uma conexão física é mapeada, cada ligação é operada como

uma relação bidirecional, ou seja, os dados são recebidos ou enviados por meio da

camada de aplicação do modelo OSI.

Os equipamentos de controle de shopfloor1 (tais como parafusadeiras,

gravadoras de chassis, equipamentos acústico e elétrico, impressoras laser de

chassis, entre outros) que são instalados na fábrica necessitam se comunicar com o

sistema FIS, seja para receber ou enviar dados, através do protocolo PMON. Cada

fornecedor desses equipamentos tem que desenvolver uma aplicação que seja

capaz de estabelecer comunicação com o sistema FIS através do protocolo PMON,

pois a Volkswagen não cede uma aplicação compatível somente à documentação de

como desenvolver um sistema compatível protocolo.

1 Os equipamentos de controle de shopfloor nada mais são do que equipamentos de chão de

fábrica que auxiliam na produção de veículos; pode-se definir shopfloor como “interface” também.

____________________________________________________ 15

Na maioria das vezes, os fornecedores não são capacitados para

desenvolver um sistema compatível com a especificação exigida pela Volkswagen,

podendo ocasionar atraso na entrega do produto e gerar prejuízo tanto para a

fábrica quanto para o fornecedor. Em casos extremos, os fornecedores desistem de

realizar o negócio, pois, consideram complexo e trabalhoso criar o sistema exigido.

Em outras situações, eles procuram empresas de desenvolvimento para resolver

este problema, mas estas além de cobrarem um preço exorbitante, não conhecem

muito bem o processo de automação da fábrica (logístico). Por esse motivo é

comum acontecerem erros de comunicação quando o fornecedor implanta o

equipamento com o sistema e este não está na conformidade com o exigido pela

Volkswagen.

A escolha deste tema leva em consideração a necessidade continua do

Grupo Volkswagen em melhorar o processo automotivo e ainda a possibilidade de

vender o produto. O desenvolvimento do sistema foi baseado na maneira que os

equipamentos se comunicam com o sistema hoje. Sendo assim, levando em

consideração estes requisitos, um piloto com estas especificações e a

documentação necessária para programar uma aplicação compatível com as

exigências do protocolo PMON foi criada.

O escopo do projeto abrange a criação de um sistema que fará a

comunicação entre os equipamentos existentes e o sistema de produção FIS,

garantindo a integridade das informações trafegadas durante este processo e

respeitando o fluxo de entrada e saída de mensagens para estes equipamentos.

1.1 APRESENTAÇÃO

O tema central deste trabalho de diplomação é a elaboração do protocolo de

comunicação compatível com o existente.

Este documento está dividido em cinco partes:

a) Revisão da Literatura: são abordados os seguintes temas:

Estudo do protocolo UDP;

Estudo do protocolo TCP;

Estudo sobre PLCs;

Estudo sobre os aplicativos do FIS;

____________________________________________________ 16

Melhor abordagem de programação para ambientes de grande

transição de informações;

Requisitos desejáveis para a implantação do protocolo desenvolvido;

b) Metodologia: onde serão apresentados os métodos empregados para a

avaliação qualitativa do protocolo desenvolvido;

c) Resultados: onde serão apresentados os resultados da avaliação

qualitativa e dos experimentos em laboratório, apresentação dos

diagramas e escopo do sistema desenvolvido;

d) Discussão: na qual os resultados dos experimentos em laboratório e da

avaliação qualitativa são discutidos;

e) Conclusões.

1.2 JUSTIFICATIVA DA ESCOLHA DO TEMA

O desejo de um sistema que é compatível com qualquer sistema operacional

seja ele Linux, Windows ou Unix é almejado pela Volkswagen há muito tempo, por

isso o desenvolvimento da aplicação em JAVA, devido à sua portabilidade.

Com o anseio da Volkswagen de existir um programa com estas

funcionalidades, veio a possibilidade de vender este produto e gerar lucros à T-

Systems do Brasil LTDA.

1.3 OBJETIVOS DO TRABALHO

O objetivo principal do projeto é apresentar uma proposta de sistema capaz

de proporcionar à Volkswagen agilidade na integração de novos equipamentos,

representação de mensagens trafegadas em logs para análise de qualquer problema

que possa existir, uma documentação completa do desenvolvimento do sistema e

análises feitas para chegar ao resultado esperado.

Os objetivos citados anteriormente serão divididos em três etapas, sendo

que a primeira consiste no levantamento de requisitos necessários para criação do

sistema e criação dos diagramas de sequência. A etapa seguinte será provida do

desenvolvimento da aplicação em si, seguindo os requisitos exigidos pela

Volkswagen. E a etapa final consiste na fase de testes que será realizada em um

ambiente que simula a linha de produção existente hoje na Volkswagen.

____________________________________________________ 17

2 LEVANTAMENTO BIBLIOGRÁFICO E ESTADO DA ARTE

Para o levantamento bibliográfico usamos uma documentação interna do

grupo Volkswagen onde são descritas algumas exigências que o protocolo deve

conter para o perfeito sincronismo entre o sistema de produção FIS e o equipamento

de controle do shopfloor.

O projeto sendo desenvolvido será responsável por criar as funcionalidades

exigidas pelo PMON, cujo funcionamento está declarado no Capítulo 3.

Após estudos verifica-se que para a elaboração do referido sistema deve-se

entender como funciona os protocolos UDP (User Datagram Protocol) e TCP

(Transmission Control Protocol), assim como os padrões Ethernet, pois é exigência

da Volkswagen a interação entre os equipamentos e estes protocolos. A Figura 1

representa como é realizada a sequência de comunicação no sistema de produção

de veículos da Volkswagen, pode-se observar equipamentos de shopfloor (PLC,

impressoras, etc.) onde realizam a captura de informações da linha de produção,

estes equipamentos centralizam as informações na interface, a qual pode-se

identificar como sendo um equipamento responsável pela troca de informações com

o FIS, é na interface onde o sistema com o protocolo PMON deve ser implementado

e então este atuará juntamente com os processos do sistema FIS para realizar

determinada ação.

Figura 1: Sequência de comunicação na Volkswagen

Nas sessões abaixo descre-se algumas informações sobre os protocolos

UDP e TCP e características pertinentes aos sistemas chão de fábrica e dos

aplicativos do FIS.

____________________________________________________ 18

2.1 PROTOCOLO UDP

O protocolo UDP (User Datagram Protocol) é um protocolo da 4ª camada

(camada de transporte) no modelo OSI, que se caracteriza por ser mais simples que

o TCP ou outro protocolo da mesma camada. Enquanto o TCP se preocupa com a

conexão e a chegada correta dos dados no destino, o UDP por ser mais simples não

tem a mesma preocupação, portanto, ele não verifica o recebimento dos dados pelo

destino, não possui o serviço de reenvio e não ordena as mensagens, ou seja, elas

vão sendo agrupadas conforme vão chegando, e assim também não controla o fluxo

de informações e não verifica a integridade dos dados para o destino. As

possibilidades do destino não receber os dados são várias como, por exemplo:

perda de dados, duplicação de dados ou agrupamento dos dados de forma errada.

A simplicidade deste protocolo garante ganho de velocidade na transmissão e

recepção de dados, algo que nos dias atuais se torna cada vez mais importante.

Outra característica importante do UDP e neste ponto, semelhante ao TCP, é que

ele se baseia em portas para a troca de informações, ou seja, uma porta é atribuída

ao destino e outra a origem.

2.2 PROTOCOLO TCP

O TCP (Transmission Control Protocol) é um dos principais protocolos da

camada de transporte do modelo TCP/IP. Ele é um protocolo orientada a conexão,

ou seja, permite que duas máquinas que estão se comunicando tenham a

capacidade de controlar o estado da transmissão.

As principais características do protocolo TCP são as seguintes:

Faz com que seja possível colocar datagramas em ordem, quando

vindos do protocolo IP;

Permite monitoração do fluxo de dados, de modo a evitar a saturação da

rede;

Permite que os dados sejam agrupados em segmentos de comprimento

variável;

Torna possível multiplexar os dados, ou seja, informações provenientes

de fontes distintas (aplicações, por exemplo) podem circular na mesma

linha de transmissão simultaneamente;

TCP permite que a comunicação seja inicializada e finalizada.

____________________________________________________ 19

2.3 PLC (PROGRAMMABLE LOGIC CONTROLLER)

Também nomeado de CLP (Controlador Lógico Programável), o PLC nada

mais é do que um computador especializado, baseado em um microprocessador que

desempenha funções de diversos tipos e níveis de complexidade. Geralmente as

famílias de Controladores Lógicos Programáveis são definidas pela capacidade de

processamento de um determinado numero de pontos de Entradas e/ou Saídas

(E/S).

Segundo a NEMA (National Electrical Manufacturers Association), é um

aparelho eletrônico digital que utiliza uma memória programável para armazenar

internamente instruções e para implementar funções específicas, tais como lógica,

seqüenciamento, temporização, contagem e aritmética, controlando, por meio de

módulos de entradas e saídas, vários tipos de máquinas ou processos.

Com relação a este projeto, o PLC é usado para capturar os dados de um

veículo e encaminhar para uma interface (ou equipamento), a qual centraliza as

informações e as envia para o sistema de controle de produção FIS através do

protocolo PMON.

2.4 DESCRIÇÃO DOS APLICATIVOS FIS

A seguir são explicados alguns detalhes no processos de comunicação entre

shopfloor e FIS.

Figura 2: Detalhe dos processos de comunicação

____________________________________________________ 20

De acordo com a Figura 2 pode-se verificar que os processos e sistemas

envolvidos durante a execução de troca de telegramas entre os equipamentos de

shopfloor e o sistema de controle de produção FIS. A comunicação se da inicio

quando um equipamento PLC executa uma ação sobre determinada carroceria, a

informação trafegada durante este processo é realizada através de um protocolo ou

método especifico representado na Figura 2 pelos números 1 e 2, o próximo passo

se da quando o PMON_UDP encapsula as informações no telegrama compatível

com o protocolo e envia através de uma conexão ativar utilizando o protocolo de

rede UDP, processos representados pelos números 3 e 4; no momento que a

informação chega no sistema FIS o telegrama é interpretado pelo aplicativo PMON-

UDP e encaminhado para um canal de recebimento (KH ou EM), o qual ao

interpretar o conteúdo do telegrama, conforme configurações previas no servidor do

FIS encaminha à middleware DAE que será responsável por executar determinada

função no servidor, estas etapas estão descritos pelos números 5, 6, 7 e 8 da Figura

2.

2.4.1 DAE (Distributed Application Environment)

O DAE é uma plataforma de aplicações distribuídas, ou seja, um

middleware, desenvolvido pela IBM cuja funcionalidade é fazer a mediação entre

outros softwares. É utilizado para mover informações entre programas ocultando do

programador diferenças de protocolos de comunicação, plataformas e dependências

do sistema operacional.

Todos os processos do FIS se comunicam diretamente com o middleware

DAE, de acordo com a. Figura 2.

2.4.2 EM (Event Manager)

A função do Event Manager é basicamente distribuir os telegramas oriundos

do FIS para vários recursos de destino, como se fosse um carteiro de mensagens,

detalhes na Figura 2.

2.4.3 KH (Kanal-Handler)

O recurso KH, ou também chamado Channel Handler, é um programa de

interface versátil utilizado para conversão de dados entre o PMON e os aplicativos

____________________________________________________ 21

do FIS. Cada recurso KH definido pelo usuário corresponde a um canal de

submissão que pode ser de envio ou recebimento de dados, detalhes na Figura 2.

2.4.4 PMON-UDP

O modulo PMON-UDP consiste no sistema responsável pela interpretação

do protocolo padronizado pela Volkswagen. Este módulo é responsável por criar,

interpretar e enviar o telegrama entre os atores Interface – FIS. Este modulo do

sistema será melhor explorado e explicado no Capítulo 5.

____________________________________________________ 22

3 METODOLOGIA

Nesta seção será descrito o planejamento realizado para elaboração deste

projeto, o estudo realizado para o desenvolvimento, como foi realizado o

levantamento de dados e o custo para sua elaboração.

3.1 ESTUDO DO CASO

Para elaboração do projeto, iniciou-se com o estudo da documentação e

exigências do protocolo utilizado pela Volkswagen, onde é possível concluir que o

número de equipamentos que auxiliam na produção de veículos continuamente

cresce e o FIS é o sistema que centraliza as informações encaminhadas e recebidas

destes equipamentos.

Estes equipamentos são chamados de PLCs e fazem comunicação com um

computador o qual são chamados de “interface”. Essa “interface” age como um

servidor, centralizando as informações recebidas. Por exemplo, uma parafusadeira

quando aperta um parafuso, envia seu torque à interface, que por sua vez prepara

um telegrama contendo dados do veículo como o número de identificação (ID),

modelo, data, hora, torque e encaminha para o sistema de controle de produção FIS,

o qual armazena essas informações no banco de dados.

3.2 LEVANTAMENTO DE DADOS

O levantamento de dados deu-se com o recolhimento do número médio de

equipamentos por fábrica da Volkswagen que fazem parte do “chão de fábrica”,

equipamentos como parafusadeiras, outros que realizam teste acústico e elétrico,

gravadoras de chassis e pontos de capturas de status pela área de produção

(Armação, Pintura e Montagem), com este levantamento foi possível avaliar a

viabilidade do projeto e a aplicação do mesmo. Nas tabelas 1, 2 e 3 é possível

verificar o número de equipamentos presentes em cada setor de uma fabrica de

automóveis da Volkswagen instalada no Brasil.

____________________________________________________ 23

Tabela 1: Levantamento equipamentos Curitiba

Unidade de produção Curitiba

Armação Pintura Montagem

7 8 35

Total = 50

Tabela 2: Levantamento equipamentos Taubaté

Unidade de produção Taubaté


10 12 43

Total = 65

Tabela 3: Levantamento equipamentos Anchieta

Unidade de produção Anchieta


10 20 68

Total = 98

3.3 EQUIPAMENTOS UTILIZADOS PARA DESENVOLVIMENTO

O desenvolvimento do projeto foi realizado nos laptops dos integrantes do

projeto. A Tabela 4: Equipamentos de desenvolvimento mostra os detalhes dos

equipamentos.

Tabela 4: Equipamentos de desenvolvimento

Sony Vaio FZ140e Acer Aspire

Processador Intel Core 2 Duo 1.8 GHz T7100 Processador Intel Core 2 Duo 2.0 GHz

Memória – 2 Gb DDR2 Memória – 3 Gb DDR3

Armazenamento Drive C: 50 Gb

Drive D: 200 Gb Armazenamento

Drive C: 150 Gb

Drive D: 150 Gb

Backup HD externo 200 Gb Backup HD externo 500Gb

____________________________________________________ 24

Windows 7 Ultimate Windows 7 Ultimate

Office 2007 Professional Office 2007 Professional

NetBeans versão 6.7.1 NetBeans versão 6.7.1

3.4 EQUIPAMENTOS UTILIZADOS PARA TESTE

Os testes foram realizados primeiramente nos laptops dos integrantes do

projeto e após passada por essa fase preliminar, os testes passaram a ser

realizados em um ambiente que simula o de produção. A tabela 5 mostra detalhes

dos equipamentos utilizados.

Tabela 5: Equipamento de testes

Semp Toshiba CS-5038

Processador - Intel Core 2 Duo 1.6 GHz T6800

Memória - 1 Gb DDR2

Armazenamento Drive C: 40 Gb

Drive D: 40 Gb

Windows Xp Professional SP2

FenixPmon

3.5 CUSTO DE DESENVOLVIMENTO

Não haverá necessidade de compra de equipamentos ou softwares para

elaboração do sistema, portanto o custo do projeto ficará por conta da de impressão

de material de leitura e pesquisa, assim como a própria impressão das cópias

disponibilizadas aos professores e a universidade.

____________________________________________________ 25

4 RESULTADOS

Neste capítulo serão representados os resultados atingidos com o

desenvolvimento do sistema proposto. Para o desenvolvimento dos diagramas

apresentados nesta documentação usou-se a modelagem baseada em a Análise

Orientada a Objetos.

4.1 MODELAGEM

Nesta seção é exposto o detalhamento da modelagem por Análise Orientada

a Objetos.

4.1.1 Descrição Da Arquitetura

A arquitetura usada no desenvolvimento deste projeto baseia-se no

conceito de Orientação a Objeto utilizando Java como linguagem de

programação. O sistema desenvolvido está dividido basicamente em dois

módulos.

Módulo FHUDP: responsável pelo estabelecimento da conexão e

envio/recebimento dos telegramas entre os parceiros de comunicação.

Módulo, FHPMON: responsável por implementar os métodos de verificação

dos telegramas que estão sendo encaminhados e recebidos.

4.1.2 Diagrama De Classe

O Diagrama de Classe é uma representação abstrata das classes que serão

implementadas no programa, no qual estão descritos as classes, atributos e

métodos que serão utilizados. (Ver Apêndice A).

4.1.3 Diagramas De Caso De Uso

Casos de uso representam funcionalidades completas para o usuário

representando apenas o panorama visual das funcionalidades presentes no sistema.

Abaixo estão descritos os casos de uso para cada elemento do protocolo que o

sistema aborda.

____________________________________________________ 26

Figura 3: Caso de uso PMON

O Caso de uso representado em Figura 3 representa o sistema como um todo,

contendo todas as funcionalidades abordadas durante a execução de envio de um

telegrama. Para que isto aconteça, é necessário uma conexão ativa representado

pelo UserCase Abrir Conexão; após a confirmação o UserCase Transmitir

Mensagem representa a transmissão de um telegrama e por fim o UserCase Encerar

Conexão representa a solicitação de fechamento de conexão.

4.1.3.1 Send Open (SO)

O caso de uso representado pela Figura 4 descreve o processo de pedido

de abertura de conexão, na Tabela 6 estão descritos os estados e condições para

que o caso de uso seja executado.

____________________________________________________ 27

Figura 4: Caso de Uso SendOpen

Tabela 6: Descrição Caso de Uso SendOpen

Nome do caso de uso SendOpen

Descrição Solicitação de abrir uma conexão para o envio de

dados.

Atores envolvidos Equipamentos do chão de fábrica e Sistema de

produção - FIS.

Pré-condições Emissor e Receptor devem estar cadastrados no

arquivo config.xml;

Pós-condições A conexão deve estar ativa entre os

equipamentos envolvidos.

FLUXO BÁSICO

Emissor Receptor

Solicita abertura de submissão

{Verificar o tamanho do telegrama} A1

{Verifica o tipo do cabeçalho} A1

{Verifica SSNR e RNSR} A1

{Verifica check-digit} A1

{Verificar o telegrama do equipamento e

reconhecer o elemento de protocolo AO} A1

Executa sub-fluxo enviar telegrama conf.

{Fim} Fim caso de uso

FLUXOS ALTERNATIVOS

A1: em { Verificação de telegrama } Todos os processos descritos por A1 devem estar

de acordo com o especificado, caso alguma

____________________________________________________ 28

condição não seja atendida a submissão não é

aberta e uma mensagem de erro é retornada ao

emissor.

A2: em { Verificar se existe submissão aberta }

O sistema verifica se já existe uma conexão ativa

entre os atores envolvidos, caso a conexão esteja

ativa ele encaminha a confirmação sem abrir uma

nova conexão.

4.1.3.2 Acknowledgement Open (AO)

O caso de uso descrito pela Figura 5 representa a confirmação da

solicitação de abertura de conexão, na Tabela 7 estão descritos os estados e

condições para a execução do caso de uso.

Figura 5: Caso de uso AcknowledgeOpen

Tabela 7: Descrição Caso de uso AcknowledgeOpen

Nome do caso de uso AcknowledgeOpen

Descrição Confirmação de abertura de conexão.


produção - FIS.

Pré-condições

Emissor e Receptor devem estar cadastrados no

arquivo config.xml e a conexão entre os

equipamentos deve estar ativa.

Pós-condições O receptor deve enviar a confirmação na qual a

submissão foi aberta.

FLUXO BÁSICO

Emissor Receptor

____________________________________________________ 29

Prepara um telegrama com os parâmetros

necessários para enviar ao equipamento que

solicitou a abertura de conexão






FLUXOS ALTERNATIVOS

A1: em { Verificação de telegrama }

Todos os processos descritos por A1 devem estar




emissor.

4.1.3.3 Send Data (SD)

O caso de uso representado pela Figura 6 mostra o envio de um telegrama

após a confirmação de abertura de conexão entre os parceiros de conexão, logo

abaixo a Tabela 8 descreve as condições para que o caso de uso ocorra.

Figura 6: Caso de Uso SendData

Tabela 8: Descrição Caso de Uso SendData

Nome do caso de uso SendData

Descrição

Envio de um telegrama com informações de

como, por exemplo, os resultados chegam ao

sistema FIS.


____________________________________________________ 30

produção - FIS.

Pré-condições




Pós-condições O receptor deve enviar a confirmação que os

dados foram recebidos corretamente.

FLUXO BÁSICO

Emissor Receptor

Envia um telegrama contendo as informações

pertinentes ao equipamento ao qual este

pertence.





reconhecer o elemento de protocolo SD } A1

Executa sub-fluxo de enviar as informações

contidas no telegrama para o destino cadastrado

no arquivo config.xml.


FLUXOS ALTERNATIVOS

A1: em {Verificação de telegrama}





emissor.

4.1.3.4 Acknowledgement Data (AD)

A Figura 7 representa a confirmação do telegrama enviado por uma

interface.

____________________________________________________ 31

Figura 7: Caso de Uso AcknowledgementData

Na Tabela 9 estão descritos os processos utilizados para a execução do caso

de uso descrito pela Figura 7.

Tabela 9: Descrição Caso de Uso Acknowledment Data

Nome do caso de uso AcknowledgementData

Descrição Confirmação de recebimento dos dados.


produção - FIS.

Pré-condições




Pós-condições O receptor deve enviar a confirmação do

recebimento dos dados.

FLUXO BÁSICO

Emissor Receptor


necessários para confirmação das informações

recebidas.






FLUXOS ALTERNATIVOS

A1: em {Verificação de telegrama} Todos os processos descritos por A1 devem estar

____________________________________________________ 32

de acordo com o especificado no protocolo, caso

alguma condição não seja atendida, a submissão

não é aberta e uma mensagem de erro é

retornada ao emissor.

4.1.3.5 Send Close (SC)

A Figura 8 representa a solicitação de fechamento de conexão, isto acontece

após o emissor receber o telegrama AcknowledgementData ou após determinado

tempo em que não existe transmissão de dados entre os parceiros de comunicação.

Figura 8: Caso de Uso SendClose

Na Tabela 10 são descritos os processos essenciais para que o caso de uso

apresentado na Figura 8 seja executado.

Tabela 10: Descrição Caso de Uso SendClose

Nome do caso de uso SendClose

Descrição Envio de um telegrama com pedido de finalização

de conexão.


produção - FIS.

Pré-condições




Pós-condições O receptor deve enviar a confirmação de conexão

finalizada.

FLUXO BÁSICO

____________________________________________________ 33

Emissor Receptor

Envia um telegrama solicitando o fechamento da

conexão.





reconhecer o elemento de protocolo SC } A1

Executa sub-fluxo finalizar conexão.


FLUXOS ALTERNATIVOS

A1: em {Verificação de telegrama}





emissor.

4.1.3.6 Acknowledgement Close (AC)

A Figura 9 representa a confirmação de finalização de conexão ativa entre

os equipamentos.

Figura 9: Caso de Uso AcknowledgeClose

Na Tabela 11 estão descritos os processos necessários para que o caso de uso

descrito na Figura 9 seja executado.

____________________________________________________ 34

Tabela 11: Descrição Caso de Uso AcknowledgeClose

Nome do caso de uso AcknowledgeClose

Descrição Confirmação de fechamento de conexão.


produção - FIS.

Pré-condições




Pós-condições A conexão entre os equipamentos deve ser

finalizada.

FLUXO BÁSICO

Emissor Receptor


necessários para enviar ao equipamento que

solicitou o fechamento da conexão.


{Verificar o tipo do cabeçalho} A1

{Verificar SSNR e RNSR} A1


reconhecer o elemento de protocolo AC} A1

FLUXOS ALTERNATIVOS

A1: em {Verificação de telegrama }


de acordo com o especificado no protocolo, caso

alguma condição não seja atendida a submissão

não é aberta e uma mensagem de erro é

retornada ao emissor.

4.2 DIAGRAMAS DE SEQUÊNCIA

Os diagramas de sequência enfatizam o ordenamento temporal das ações,

os quais são construídos de acordo com as seguintes convenções:

Linhas verticais representam os objetos;

Setas horizontais representam as mensagens passadas entre os objetos;

Rótulos das setas são os nomes das operações;

A posição na vertical mostra o ordenamento relativo das mensagens;

____________________________________________________ 35

O diagrama pode ser complementado e esclarecido por anotações.

4.2.1 Send Open (SO) e Acknowledge Open (AO)

A Figura 10 representa a sequência de mensagens trocadas para a abertura

de uma conexão que posteriormente será usada para a transmissão de dados entre

o equipamento de controle de shopfloor e o FIS.

O módulo FHUDP presente na interface encapsula um telegrama

(IP+porta+número da sequência) com os dados recebidos através do módulo

FHPMON e envia ao sistema FIS; então uma confirmação de recebimento é enviada

ao aplicativo da interface pelo modulo FHUDP presente no sistema FIS, após isto, as

informações pertinentes ao protocolo são traduzidas pelo PMON que, de acordo com

o elemento de protocolo, faz com que o sistema FIS realize uma ação. Após as

instruções serem executadas, o modulo FHUDP presente no FIS encapsula um novo

telegrama contendo (IP+porta+número da sequência) juntamente com o

AcknowledgeOpen e encaminha novamente para a interface finalizando o processo

de transmissão após a interface responder com a confirmação do recebimento deste

telegrama..

Figura 10: Diagrama de Sequência SendOpen e AcknowledgeOpen

____________________________________________________ 36

4.2.2 Send Data (SD) e Acknowledge Data (AD)

O Diagrama representado na Figura 11 descreve a sequência de

mensagens trocadas entre uma interface e o sistema FIS durante o envio e

recebimento dos telegramas SendData e AcknowledgeData.

Figura 11: Diagrama de Sequência SendData e AcknowledgeData

4.2.3 Send Close (SC) e Acknowledge Close (AC)

O digrama representado pela Figura 12: Diagrama de Sequência SendClose

e AcknowledgeClose mostra a sequência de mensagens trocadas entre uma

interface e o sistema FIS durante a solicitação de fechamento de conexão e

confirmação de conexão finalizada.

____________________________________________________ 37

Figura 12: Diagrama de Sequência SendClose e AcknowledgeClose

4.3 DIAGRAMAS DE COLABORAÇÃO

Os diagramas de colaboração enfatizam os relacionamentos entre os

objetos participantes. Eles são construídos de acordo com as seguintes convenções:

Nodos representam os objetos;

Os arcos representam as mensagens passadas entre os objetos;

s rótulos dos arcos são os nomes das operações;

Os números de sequência mostram o ordenamento relativo das

mensagens;

s anotações podem complementar o diagrama.

Nos diagramas de colaboração a ordenação das mensagens é mostrada

apenas pela numeração delas. Na Figura 13 mostra-se o diagrama de colaboração

que corresponde a uma ação genérica entre uma interface e o Sistema FIS.

____________________________________________________ 38

Figura 13: Diagrama de Colaboração

4.4 DIAGRAMA DE ESTRUTURA DOS MÓDULOS

O Diagrama de estrutura dos módulos descreve os aspectos estáticos do

modelo físico. Ela mostra os módulos utilizados na implementação, assim como

componentes reutilizados do ambiente. Mostra também as dependências existentes

entre eles, que indicam o impacto das alterações realizadas em cada componente.

Na Figura 14 são representados os módulos envolvidos durante uma

transação de mensagens. Inicialmente o PLC realiza uma ação de leitura ou

gravação de informação em um determinado veículo, esta ação é interpretada pela

interface onde o modulo PMON cria um telegrama que será encaminhado ao

sistema FIS pelo FHUDP, no FIS este telegrama é reconhecido pelo FIS-FHUDP e

interpretado pelo FIS_PMON onde conforme configuração nos arquivos de

parametrização interpreta os canais de submissão que estão envolvidos na

transmissão e ativa determinado modulo no FIS_Resources que realizará a ação de

leitura ou escrita na base de dados.

____________________________________________________ 39

Figura 14: Diagrama de Estrutura de Módulos

4.5 DIAGRAMA DE TRANSIÇÃO DE ESTADOS

A Figura 15: Diagrama de Estados – SendOpen representa a transição de

estados no momento de uma solicitação de abertura de conexão. No início do

estado, o sistema fica aguardando pela leitura de algum veículo através de um PLC,

e após detectar que houve uma leitura de dados, imediatamente uma solicitação de

abertura de conexão com o sistema FIS é registrada. Esta solicitação pode ser

interpretada como positiva (conexão realizada com sucesso) ou negativa, caso o

retorno for reconhecido como negativo, serão realizadas mais duas tentativas,

contendo o mesmo número de sequência, e caso nenhuma deles retorne

positivamente a solicitação é encerrada.

____________________________________________________ 40

Figura 15: Diagrama de Estados – SendOpen

A Figura 16: Diagrama de Estados – SendData representa a transição de

estados que ocorre no momento em que os dados são enviados ao sistema. O pré-

requisito é a conexão estar ativa, demonstrada pelo diagrama de estados anterior.

Assim que os dados são encaminhados, o sistema receptor deve responder com a

confirmação do recebimento dos dados. Caso algum erro ocorra durante este

processo, por mais duas vezes o telegrama é reenviado e o não-sucesso destas

novas tentativas terá como consequência a finalização do processo de transmissão.

Figura 16: Diagrama de Estados – SendData

____________________________________________________ 41

A Figura 17: Diagrama de Estados – SendClose representa a solicitação de

finalização de conexão. Esta ação é tomada no momento em que a confirmação de

recebimento de dados é interpretada pela interface emissora. Neste momento um

novo telegrama é montado e encaminhado para a interface receptora que será

responsável por finalizar a conexão entre os equipamentos. Caso algum erro ocorra

durante este processo, por mais duas vezes o telegrama é reenviado e o não-

sucesso destas novas tentativas terá como consequência a finalização do processo

de transmissão.

Figura 17: Diagrama de Estados – SendClose

4.6 REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS

Nesta seção é exposta a maneira como o programa deve ser desenvolvido,

declarando suas definições e exigências para que a comunicação com o sistema FIS

seja realizada com sucesso.

A maneira como o PMON trabalha é mapeando várias conexões lógicas

dentro de uma conexão física, onde cada conexão é operada como um link bi-

direcional, ou seja, os dados são enviados e recebidos por meio de um canal de

submissão.

Uma submissão pode ser estabelecida por ambos os equipamentos; embora

cada submissão só pode ser criada para uma direção de transferência.

____________________________________________________ 42

A direção de transferência para cada canal de submissão é definida durante

o planejamento e parametrização de um link PMON e não pode ser alterada durante

a operação. Se dois equipamentos requerem uma transferência de dados bi-

direcional na rede, pelo menos dois canais de submissão são necessários. O PMON

não executa qualquer interpretação do conteúdo de dados da rede.

O uso do UDP, melhor explicado no capítulo Protocolo UDP, é obrigatório,

pois garante a velocidade na transmissão dos dados. Como se trata de um protocolo

não confiável é necessário criar métodos dentro do PMON que garantam que os

dados transmitidos entre os equipamentos não foram corrompidos.

Para que o PMON garanta uma transferência de dados segura, medidas

como monitoramento do estado da ligação de transferência e da transferência de

dados foram implementadas. Isto é realizado por meio de reconhecimentos

(acknowledgements), funções que retornam a confirmação do recebimento da

mensagem transferida e funções de detecção de falhas (checksum para verificação)

realizados internamente pelo PMON. Desta forma, o PMON garante uma

transmissão de dados correta ou que, em caso de ocorrência de erros, mensagens

de erro sobre as tentativas mal sucedidas de transferência são relatadas para o

correspondente equipamento.

Em caso de grandes quantidades de dados deve-se segmentar os dados,

isto deve ser feito pela estação transmissora. A estação receptora deve, então,

recombinar esses dados em conformidade. Telegramas com dados maiores que 512

Bytes são automaticamente segmentados no lado da transmissão de dados, ou seja,

quebrar em vários telegramas para que a transferência leve um curto prazo. Um

telegrama pequeno em caso de erro terá um tempo para a retransmissão mais curto.

O padrão Ethernet 100BASE-T é utilizado para comunicação entre a

interface e o sistema FIS. A Figura 2 Erro! Fonte de referência não

ncontrada.mostra os detalhes do momento no qual o protocolo PMON é utilizado

coletando os dados que estão chegando do PLC e os transformando em uma

sequência de caracteres que o sistema FIS será capaz de interpretar.

Para identificar qual o equipamento que está enviando e recebendo as

informações é necessário cadastrá-lo através de um registro que é adicionado no

cabeçalho do telegrama que será encaminhado, chamado de canal de submissão. O

____________________________________________________ 43

canal de submissão irá identificar qual o equipamento que está encaminhando e

para qual equipamento a mensagem será enviada.

O sistema FIS exige que uma sequência de seis mensagens sejam trocadas

para realizar a transmissão completa, estas mensagens são respectivamente

mostradas na Tabela 12:

Tabela 12: Sequência de mensagens

Descrição Função Sigla

Estabelecer conexão com o

Canal de Submissão. SendOpen SO

Confirmação de conexão

estabelecida AcknowledgeOpen AO

Transmissão dos dados SendData SD

Confirmação de transmissão AcknowledgeData AD

Fechar conexão SendClose SC


fechada AcknowledgeClose AC

4.7 TRANSMISSÃO DE DADOS

A transmissão de dados é realizada usando o protocolo UDP. A classe

responsável pela transmissão do telegrama é a fhudp, a qual permanece

aguardando continuamente por uma nova mensagem, quando isto acontece inicia-

se a conexão com o outro equipamento para a transmissão de dados.

A troca de dados entre dois equipamentos deve ser iniciada com abertura da

submissão. Uma submissão é uma conexão em um canal de dados lógico entre dois

equipamentos. O equipamento de comunicação responsável por abrir a conexão é

aquele que quer transmitir o pacote de informações.

Ao abrir uma conexão, uma mensagem de partida pode ser trocada entre os

parceiros. Neste caso, o receptor de dados especifica o conjunto de dados passado

corretamente e processados na forma de um número consecutivo. O remetente

transmite então o conjunto de dados.

____________________________________________________ 44

Após uma submissão ser aberta, os dados podem ser transferidos até que

seja fechada a conexão ou que uma falha ocorra. Um bloco de dados grande deve

ser dividido se necessário durante a transmissão, e reconstruído pelo receptor

automaticamente. Caso não exista nenhum dado sendo transferido, a conexão pode

expirar em ambos os lados após um determinado tempo.

4.7.1 FHUDP – Descrição Do Protocolo

O módulo FHUDP trabalha na camada de transporte, e é implementado de

maneira que a troca de informações seja possível sem que sejam afetadas as

aplicações de camadas superiores. A representa a divisão das aplicações em

comparação com as camadas do modelo OSI. Pode-se verificar que o módulo

FHPMON está representado dentro da camada de aplicação e o modulo FHUDP na

camada de transporte.

Aplicação

Aplicação FHPMON Apresentação

Sessão

Transporte Transporte FHUDP

Rede Internet IP - Porta

Enlase Interface com a Rede Envio do Telegrama

Física

Modelo OSI TCP/IP Sistema

Figura 18: Representação Modelo OSI , TCP/IP e Sistema proposto.

Fonte: Autor Indisponível, 2010.

O FHUDP é utilizado para uma comunicação ponto a ponto, cuja tarefa é

assegurar a transmissão de uma mensagem (sequência de bytes) de um dispositivo

para outro dispositivo (Interface - FIS).

A transmissão de uma sequência de bytes (mensagem) entre dois sistemas

é controlada na camada de transporte. Portanto, a recepção de uma mensagem é

reconhecida pelo FHUDP através de uma mensagem de resposta própria. Após o

acknowledgment, a transmissão é finalizada.

____________________________________________________ 45

A transmissão de uma sequência de bytes do sistema A para o sistema para

B ocorre em duas etapas:

1. A envia uma mensagem para B, que contém a sequência de bytes que

será transmitida; seguindo a sequência descrita abaixo:

<Start> <Number> <Message> <End> <Checksum>

Os componentes têm o seguinte significado e conteúdo:

Start: define o início da transmissão FHUDP. O componente Start é usado

para dividir entre Pedido e Resposta. Seu tamanho é correspondente a um Byte

sendo os seguintes valores permitidos:

STX (Start of Text) – hexa 02 –> marca um Pedido

ACK (Acknowledge) – hexa 06 –> marca uma Resposta

Number: Esse componente é um número seqüencial da mensagem que é

criado pelo FHUDP ao enviar um Pedido. O número é um decimal com 4 dígitos em

um intervalo de 1 até 9999. Estes dígitos são transmitidos como caracteres ASCII.

Espaços à esquerda são substituídos por "0".

Message: Esse componente é a própria mensagem. O conteúdo dela não é

interpretado ou modificado pelo FHUDP.

End: A combinação dos bytes [DLE] e [ETX] marca o final de uma

transmissão.

DLE (Data Link Escape) – hexa 10

ETX (End of Text) – hexa 03

Checksum: O checksum é construído como uma interligação XOR para

todos os caracteres transmitidos incluindo o [DLE] e [ETX]. O comprimento da soma

de verificação é um Byte.

2. B envia uma mensagem de acknowlegment para A, o qual confirma o

recebimento.

<Start> <Number> <Error> <End> <Checksum>

Os componentes têm o seguinte significado e conteúdo:

Start: define o início da transmissão FHUDP. O componente Start é usado

para dividir entre Pedido e Resposta. Seu tamanho é correspondente a um Byte

sendo os seguintes valores permitidos:

STX (Start of Text) – hexa 02 –> marca um Pedido;

____________________________________________________ 46

ACK (Acknowledge) – hexa 06 –> marca uma Resposta;

Number: O número da mensagem é idêntico ao número do Pedido que será

respondido com esta resposta.

Error: Este componente é o número de erro que é criado através da

recepção de um pedido. Este número de erro é enviado de volta dentro da

mensagem de resposta.

Possíveis números de erro:

0 - Nenhum erro detectado.

1 - Erro de checksum na mensagem recebida.

2 - Pacote da mensagem recebida não pôde ser encaminhado.

O número de erro contém 4 dígitos com uma escala de 1 a 9999. Esses

dígitos são transmitidos como caracteres ASCII. Espaços à esquerda são

substituídos por "0".

End: A combinação dos bytes [DLE] e [ETX] marca o final de uma

transmissão.

DLE (Data Link Escape) – hexa 10

ETX (End of Text) – hexa 03

Checksum: O checksum é construído como uma interligação XOR para

todos os caracteres transmitidos incluindo o [DLE] e [ETX]. O comprimento da soma

de verificação é um Byte.

O remetente verifica a recepção da resposta para um pedido de envio dentro

de um período máximo de 2 segundos e o tamanho permitido da mensagem

transmitida no FHUDP é definido separadamente para cada interface através de

parametrização.

Uma solicitação é enviada do FHUDP para o destinatário até três vezes,

somente se a transmissão não for bem sucedida (mensagem de erro na resposta ou

timeout), onde o número da mensagem será o mesmo para todas as retransmissões.

O exemplo a seguir mostra o processo de transmissão de dados para uma

conexão aberta entre dois sistemas A e B onde os números de submissão são 1234

e 5678 respectivamente.

O sistema A é a submissão mestre e os checksums são escritos como

<chk>. A transmissão ocorre sem erros, sendo assim, o número de erro obtido na

resposta do driver é 0.

____________________________________________________ 47

A->B : [STX]000112345678SO0000000000000000000003000512000400000000[DLE][ETX]<chk>

B->A : [ACK]00010000[DLE][ETX]<chk>

B->A : [STX]000156781234AO000000000001000256000401230000[DLE][ETX]<chk>

A->B : [ACK]00010000[DLE][ETX]<chk>

4.8 PROTOCOLO PMON

Nesta seção serão descritos os processos e detalhamentos do protocolo

PMON.

4.8.1 Abrindo Uma Submissão

Quando uma conexão é realizada com sucesso entre dois equipamentos,

estes passam a ser chamados de parceiros e é possível para ambos abrirem uma

submissão. Se o remetente inicia a submissão, o receptor reconhece o elemento do

protocolo „SO‟ (Send Open, solicitação para estabelecer uma conexão). Se o

receptor transmite no protocolo o elemento „SO‟, o remetente também responde a

esse elemento. O receptor então transmite o acknowledgement de submissão

aberta, „AO‟, Acknowledgement Open.

O remetente do pedido de abertura de uma conexão informa ao seu parceiro

os parâmetros relevantes, como o comprimento máximo do bloco da transmissão,

modo de transmissão e ponto de partida, o parceiro, por sua vez, retorna os

parâmetros necessários na sua confirmação e o remetente de dados avalia os dados

relevantes para ele.

4.8.2 Fechando Uma Submissão

A submissão pode ser fechada por ambos os lados e a conexão deve ser

bloqueada. Posteriormente, a submissão deve ser reaberta antes que os dados

possam ser trocados novamente.

Quando no telegrama do remetente o elemento do protocolo „SC‟, (Send

Close, pedido para fechar submissão) é transmitido, o receptor responde com o „AC‟

(Acknowledgement Close, confirmação de solicitação de encerramento).

Se o encerramento é iniciado pelo receptor, este transmite o elemento do

protocolo „SC‟ (pedido para fechar submissão). Em contrapartida, o remetente

____________________________________________________ 48

também envia o elemento de protocolo „SC‟ (pedido para fechar submissão) que

depois é reconhecido pelo receptor com o elemento de protocolo AC (confirmação

de solicitação de encerramento).

4.8.3 Transferindo Um Telegrama

A transferência efetiva de dados na rede só pode ser realizada através da

conexão que tenha sido aberta. Cada parceiro na submissão só pode definir uma

direção para a transferência de dados.

A transferência de dados pode ser feita bloco a bloco ou segmentada. No

caso de transmissão segmentada, o aplicativo de envio não precisa se preocupar

com a segmentação, pois esta é realizada pelo PMON. Um contador de bloco, que

conta os blocos individuais e o comprimento do telegrama também é enviado.

4.9 ELEMENTOS DO PROTOCOLO PMON

Os seguintes elementos são necessários para a criação de um telegrama de

acordo com o protocolo:

Requisitos para criar uma submissão.

Acknowledgements após criar uma submissão.

Requisitos para fechar a submissão.

Acknowledgements após fechar a submissão.

Transmissão de um bloco de dados.

Acknowledgements de um bloco de dados.

Existem dois elementos de protocolo pedido e confirmação

(acknowledgements). Os pedidos são transmitidos a partir do remetente, o receptor

deve reconhecê-los. O sentido único de transmissão de dados na rede significa que

há sempre um emissor e receptor para cada submissão.

Há casos em que o receptor pode tomar a iniciativa de abrir e fechar uma

submissão. Neste caso, os elementos de protocolo correspondentes a ordem são

usados pelo remetente para responder ao pedido a Figura 21 presente no

APENDICE A representa esta situação, em que o receptor, previamente definido,

solicita uma abertura de conexão ao emissor, este não irá responder com o

elemento de confirmação de conexão AO mas sim com o elemento de abertura de

____________________________________________________ 49

conexão SO pois somente o receptor tem o poder de realizar a abertura de uma

conexão.

Os métodos disponíveis para solicitar uma conexão estão apresentados no

APÊNDICE A – Métodos possíveis de solicitação de conexão.

No APÊNDICE B – Casos de conflito ao solicitar abertura ou fechamento de

conexão, estão representados os casos de conflitos identificados.

Nos apêndices mostrados abaixo são o detalhamento do conteúdo de cada

telegrama enviado e recebido pelo sistema proposto, estás tabelas são a base para

configuração e interpretação dos telegramas do protocolo PMON.

Representação do telegrama que faz a solicitação de abertura de conexão.

APÊNDICE C – Telegrama: Pedido Para Abrir Submissão.

Representação do telegrama de confirmação de abertura de conexão.

APÊNDICE D – Telegrama: Acknowledge para criar submissão.

Representação do telegrama que realiza o pedido de fechamento de

conexão. APÊNDICE E – Telegrama: Pedido para fechar submissão.

Representação do telegrama de confirmação de fechamento de conexão

APÊNDICE F – Telegrama: Acknowledge ao fechar submissão.

Representação do telegrama contendo a sequencia para o envio correto de

um bloco de dados. APÊNDICE G – Telegrama: Enviar bloco de dados.

Representação do telegrama de confirmação de recebimento de um bloco

de dados. APÊNDICE H – Telegrama: Acknowledge ao enviar um bloco de dados.

4.10 AMOSTRA DA COMUNICAÇÃO

Foram realizados testes para comprovar a comunicação entre o sistema

proposto pela equipe e o sistema FenixPmon (Desenvolvido pela Volkswagen

México). Veja detalhes nos apêndices I, J, K e L.

____________________________________________________ 50

5 DESCRIÇÃO DO PROGRAMA PMON

O programa é interpretado como um estado controlado para o computador,

ou seja, o programa tem um estado definido para cada submissão, geralmente por

causa de mudanças internas (temporal) ou eventos (telegramas).

Mudanças internas são definidas para cada submissão, ou seja, existem

intefaces que de tempos em tempos enviam um telegrama informando que o

equipamento está no ar estes canais de submissão são chamados de canais de vida

e é usado em equipamentos críticos como impressoras de chassis, que não podem

deixar de funcionar pois podem ocasionar parada de linha de produção, caso esta

comunicação é perdida, um alerta é gerado para que a situação seja normalizada o

mais rápido possível.

Eventos são os próprios telegramas que um PLC encaminha ou recebe

da/para a interface.

Depois de receber um telegrama, uma análise do conteúdo ocorre e uma

segmentação acontece. Após a separação dos grupos de informações presentes na

mensagem, podemos organizar as seguintes sessões:

Bloqueio de ordens organizacional, ou melhor, abrir uma conexão e

para trabalhar em estado de submissão (ativa, fechada ou bloqueada).

Uso de ordens para montar ou fechar uma conexão e para a recepção

e transmissão de dados.

Acknowledge-telegram a partir da interface.

Ordens de comunicação para criar ou fechar uma conexão e receber

ou transmitir dados para um parceiro de comunicação externa.

5.1 ORDENS ORGANIZACIONAIS

Enquanto o telegrama é analisado, uma checagem é realizada para

descobrir se o canal está configurado, caso o elemento de protocolo "SendOpen" é

interpretado uma submissão para transmissão de dados deve ser criada. Somente

depois de reconhecer o elemento de pedido de abertura de submissão é que um

telegrama de resposta é montado e enviado ao emissor.

Para o estado de uma submissão bloqueado, antes do processamento é

realizada uma verificação se já existe uma conexão ativa sobre este canal, ou seja,

existe transmissão ativa de dados. Se for esse o caso, a interface que está fazendo

____________________________________________________ 51

o pedido de bloqueio é anotada e é preciso aguardar a criação da conexão para esta

interface (se necessário, a criação é interrompida quando o tempo limite for

alcançado).

No estado de comunicação aberta a transmissão pode ser do telegrama é

efetivada sem nenhuma ação. Caso o estado da submissão esta como bloqueado, e

necessário o desbloqueio para que a transmissão oi recebimento de um telegrama

aconteça.

5.2 ORDENS DE USO

As ordens de uso de comunicação para a criação, desconexão, recepção,

transmissão de dados e aplicações de uso são tratadas.

Primeiramente deve-se determinar se existe uma configuração correta para

o canal ordenado. Depois que a verificação é realizada a ordem de utilização pode

ser cumprida no momento ou não. Se não for possível executar a ordem uma

confirmação negativa é gerada com um acknowledgecode, no qual a razão para não

ser capaz de realizá-la é indicada.

5.3 ORDENS DE COMUNICAÇÃO

Quando o programa recebe um telegrama dos recursos de comunicação

configurados, primeiramente é analisado se existe um canal configurado para a

ordem recebida, no caso de erro uma mensagem é exibida.

O estado atual para o canal que está em comunicação é calculado pela

estrutura de gerenciamento. Um exemplo ocorre ao receber um elemento de

protocolo errado, o recurso de comunicação recebe a ordem para enviar uma

confirmação negativa para o parceiro de comunicação.

Se o elemento de protocolo “SendOpen” foi recebido pelo parceiro de

conexão, primeiramente é examinado se a conexão está bloqueada. Se for esse o

caso, o PMON transmite o elemento de protocolo “AcknowledgeOpen", com a

informação "bloqueado".

Enquanto o elemento de protocolo “AcknowledgeOpen” estiver ativo, o

comprimento do objeto de identificação, o modo de transmissão e o tamanho

máximo do bloco são examinados. Se já houver uma falha, o parceiro de

____________________________________________________ 52

comunicação recebe uma confirmação negativa. Se não, a conexão interna é

configurada como aberta e o usuário recebe um “AcknowledgeOpen” positivo.

Se o parceiro de conexão está enviando o elemento de protocolo “SendClose",

é analisado se a causa para o pedido de desconexão no telegrama é admissível.

Enquanto um canal de transmissão está ativo o pedido de desconexão fica

aguardando até que a transmissão seja concluída. Somente após que a transmissáo

é concluída, O PMON gera um telegrama com o elemento de protocolo "Sendclose"

para o canal de recepção e transmite para o recurso de comunicação configurado.

O elemento de protocolo “AcknowledgeClose” define o estado da ligação

como "não conectado". O Acknowledge de desconexão é transmitido para a

interface do aplicativo em um canal de transmissão.

Para os dados serem recebidos em um canal de transmissão pelo parceiro

de conexão, é necessário o elemento de protocolo “SendData”. Estas informações

somente são transmitidas se a conexão não estiver bloqueada, Após o envio do

bloco de dados deve ser confirmado com o elemento de protocolo

“AcknowledgeData”.

O elemento de protocolo “AcknowledgeData” apenas é enviado em um

canal de transmissão ativo. Antes de o Acknowledge ser enviado, a informação é

verificada, após isso o blockcounter do Acknowledge é comparado com o

blockcounter do telegrama anteriormente transmitido. Se o Acknowledge refere-se

ao telegrama de dados transmitidos, ou seja, os blockcounters são iguais, é

analisado qual o método de envio que existe neste canal. Se os telegramas não são

transmitidos em segmentos, o Acknowledge pode ser encaminhado para a

aplicação. Se os telegramas são transmitidos em segmento deve-se examinar se

ainda existem blocos de dados a serem transmitidos através do Acknowledge do

último bloco de dados. Quando ocorre uma falha o Acknowledge é transmitido para

o parceiro de comunicação.

5.4 TELEGRAMAS SO-AO

O exemplo a seguir mostra uma solicitação de conexão (SO) e a

confirmação do pedido de conexão (AO).

Emissor:

00110002SO000000000000000000000100051200060000010000

____________________________________________________ 53

Destinatário:

00020011AO00000000000100051200060001230000

O emissor envia um pedido para estabelecer uma conexão (SO), com o

canal de submissão do emissor Sender Submission Number (SSNR) = 0011 e o

canal de submissão do receptor Receiver Submission Number (RSNR) = 0002.

Dentro do telegrama temos as seguintes informações:

SSNR = 0011 canal de submissão do emissor.

RSNR = 0002 canal de submissão do receptor.

SO = elemento do protocolo.

00 = tamanho do objeto de identificação.

000000 = Número de blocos que serão transmitidos. (Não suportado)

000000 = Tamanho dos blocos em bytes. (Não suportado)

000000 = Número da ordem de geração. (Não suportado)

01 = Transmissão sem segmentação.

00 = Função de backup de dados (Não suportado).

0512 = Comprimento máximo do bloco em bytes.

0006 = Ponto de partida predeterminado em bytes.

000001 = Informação do ponto de partida. Nota: A Informação do ponto de

partida = 000001 é apenas para ilustrar o tamanho da posição o indicado é

000000.

0000 = Comprimento de inicialização dos dados.

Alguns elementos do protocolo não são suportados pelo FIS, porém a

documentação cedida pela Volkswagen exige que estes elementos estejam

presentes no protocolo, por este motivo, a implementação destes e essencial e como

padrão eles estão setados com 0 „zero‟. Para mais detalhes sobre o elemento de

protocolo SO verificar Tabela 13 no apêndice C.

O receptor responde com a estrutura de reconhecimento (AO), com o canal

de submissão do emissor Sender Submission Number (SSNR) = 0002 e o canal de

submissão do receptor Receiver Submission Number (RSNR) = 0011. Dentro do

telegrama têm-se as seguintes informações:



____________________________________________________ 54

AO = elemento do protocolo.

00 = informações da confirmação, mais informações na Tabela 14 no

apêndice D.Erro! Fonte de referência não encontrada.

00 = tamanho do objeto de identificação.

000000 = Número da ordem de geração. (Não suportado)

01 = Transmissão sem segmentação.

00 = Função de backup de dados (Não suportado).

0512 = Comprimento máximo do bloco em bytes.

0006 = Ponto de partida predeterminado em bytes.

0000 = Comprimento de inicialização dos dados.

0001 = Informação do ponto de partida. Nota: A Informação do ponto de

partida = 000001 é apenas para ilustrar o tamanho da posição o indicado é

000000.

O Acknowledge será dado como um touch-000123, com um comprimento de

6 bytes.

5.5 TELEGRAMAS SD-AD

O exemplo a seguir mostra uma transmissão de dados (SD) e a confirmação

da recepção dos dados (AD).

Emissor:

00110002SD00010057APR3 - V001 - 11-2005-1234567 = 0-03000321 **

WVWZZZ1KZ6W123456

Destinatário:

00020011AD00000001

O emissor envia um telegrama (SD) com os dados contidos no exemplo,

com o canal de submissão do emissor Sender Submission Number (SSNR) = 0011 e

o canal de submissão do receptor Receiver Submission Number (RSNR) = 0002.

Para maiores detalhes do conteúdo do telegrama verificar Tabela 17 no apêndice G.

Veja abaixo as informações do conteúdo do telegrama;


____________________________________________________ 55


SD = elemento do protocolo.

0001 = contador do bloco.

0057 = tamanho do bloco que será transmitido sem o cabeçalho.

APR3 - V001 - 11-2005-1234567 = 0-03000321 ** WVWZZZ1KZ6W123456

mensagem transmitida.

O destinatário envia a confirmação dos dados recebidos (AD), com o canal de

submissão do emissor (SSNR) = 0002 e o canal de submissão do receptor (RSNR) =

0011. A seguir estão descritos todos os campos do telegrama.



AD = elemento do protocolo.

00 = informações da confirmação.

00 = checksum.

0001 = contador do bloco.

Para maiores informações sobre o elemento de protocolo „AD‟ verificar

Tabela 18 no apêndice H.

5.6 TELEGRAMAS SC-AC

O exemplo a seguir mostra uma solicitação de desconexão (SC) e a

confirmação da solicitação (AC).

Emissor: 00110002SC01

Destinatário: 00020011AC

O Emissor envia um pedido de fechamento de conexão (SC), com o canal de

submissão do emissor (SSNR) = 0011 e o canal de submissão do receptor (RSNR) =

0002. Por ultimo o campo 01 representa a causa do pedido de desconexão para

mais detalhes sobre os códigos do elemento SC verificar Tabela 15 presente no

apêndice F.

O receptor responde com uma confirmação de desconexão (AC), com o canal

de submissão do emissor (SSNR) = 0002 e o canal de submissão do receptor

____________________________________________________ 56

(RSNR) = 0011. Mais detalhes do elemento de protocolo AC estão presentes na

Tabela 16 apêndice G.

____________________________________________________ 57

6 IMPLANTAÇÃO

O sistema será testado usando um software desenvolvido pela Volkswagen

México chamado FENIXPMON. Este aplicativo foi criado com a finalidade de

executar uma comunicação compatível com o protocolo PMON. O FENIXPMON foi

inteiramente desenvolvido pela Gedas2 México e aprovado pela KDOB3 na

Alemanha.

Uma das vantagens do FENIXPMON é sua facilidade e simplicidade de uso:

para enviar e receber as informações é necessário apenas uma estrutura simples,

um arquivo de texto. O remetente e o receptor devem concordar com a estrutura

interna deste arquivo texto.

O FENIXPMON simula o ambiente de trabalho onde é possível testar todos

os elementos de protocolo suportados pelo protocolo PMON. Seu funcionamento é

relativamente simples, somente é cadastrado os canais de submissão, IP e porta. Ao

iniciar a conexão os telegramas já podem ser trocados entre os sistemas.

6.1 RESULTADOS DA IMPLANTAÇÃO

A Figura 30 presente no apêndice I mostra o programa Wireshark

capturando um telegrama enviado pelo sistema desenvolvido pela equipe ao sistema

FENIXPMON contendo o elemento de protocolo SD. Os apêndices J, K e L

representam a confirmação da sequencia enviada pelo FHUDP, o encapsulamento

de um telegrama AO preparado pelo FENIXPMON e por fim a confirmação do

FHUDP do sistema desenvolvido par ao telegrama AO. Esta sequencia de imagens

representa a o processo completo na troca de um telegrama.

2 Empresa de Suporte de TI; em meados de 2007 foi vendida para a T-Systems que faz parte

do grupo Deutsche Telekom

3 KDOB é uma empresa de TI que faz parte da Volkswagen Alemanha. Especializada no ramo

de desenvolvimento de softwares para a fábrica.

____________________________________________________ 58

7 CONCLUSÃO

Durante o desenvolvimento do projeto verificou-se algumas dificuldades, a

principal delas está relacionada ao conteúdo informativo liberado pela Volkswagen

que é muito limitado e ainda está quase que totalmente descrito em alemão, língua

que nenhum dos integrantes deste projeto domina muito bem.

Outra dificuldade que se pode listar está na obtenção de detalhes de erros

durante a execução de envio e recebimento de mensagens, nos arquivos de logs

presentes nos servidores, retratam somente do erro que está acontecendo, mas as

ações que o sistema toma para contornar o erro não são descritas. Essa dificuldade

mostrou-se complexa de ultrapassar, pois o sistema deve interpretar, por exemplo, o

motivo que levou uma mensagem a não ser entregue e tomar uma decisão se esta

mensagem deve ser descartada ou armazenada para envio posterior (spool) e o

tempo que se deve aguardar para tentar o envio novamente.

Este problema deve ser tratado com extrema importância, pois há

informações que não podem deixar de ser entregues ao FIS e as configurações de

como o sistema desenvolvido deve interpretar este erro devem condizer com as

exigências do protocolo PMON do FIS.

Para contornar estes problemas, realizo-se uso do sistema FenixPmon

cedido pela Volkswagen México e de um Sniffer de rede e então consegui-se simular

um ambiente de testes com os tipos e as maneiras que as informações são

transitadas entre os equipamentos.

Através da metodológica citada no parágrafo anterior conseguiu-se

aproximar o máximo possível as exigências que o sistema FIS tem com o sistema

que implementa o protocolo.

Após diversos levantamentos, conclui-se que o desenvolvimento do sistema

compatível com o protocolo exigido pelo grupo Volkswagen é viável. Dentre algumas

análises pode-se constatar que o sistema é relativamente simples, porém com um

nível de controle de erros bem desenvolvido.

Para total implantação do sistema que desenvolvemos há muito para se

melhorar e implementar. O principal tópico que se deve ter a atenção é em relação

aos logs para eventuais erros, um arquivo de log completo e bem detalhado é crucial

para o suporte do produto. Certamente um sistema instável e com registros de log

pobres não será aceito pela Volkswagen.

____________________________________________________ 59

7.1 CONTRIBUIÇÕES

A nossa contribuição fica a cargo da documentação detalhada que

desenvolvemos com diagramas e estudos de caso detalhando o processo de

transmissão de dados. Com está documentação é possível finalizar todos os

módulos do sistema e deixá-lo em pleno acordo com todas as exigências da

Volkswagen.

7.2 TRABALHOS FUTUROS

Para trabalhos futuros sugerimos a implementação de módulos de

comunicação como o Java RMI (Remote Method Invocation) e o JMS (Java

Message Service).

____________________________________________________ 60

8 REFERÊNCIAS

Autor Indisponível, Descrição: TCP-IP, Disponível em:<

http://www.voipbra.com.br/definicao/tcpip.htm>. Acesso em: Janeiro de 2010.

FRANCHI, Claiton M.; CAMARGO, Valter L. A. de. Controladores Lógicos

Programáveis: Sistemas Discretos. 1. ed. São Paulo: Érica, 2008.

PRUDENTE, Francisco. Automação Industrial: PLC Teoria e Aplicações. 1. ed. Rio

de Janeiro: LTC, 2007.

MORAES, Alexandre F. de. Redes de Computadores: Fundamentos. 6. ed. São

Paulo: Érica, 2008.

TITTEL, Ed. Rede de Computadores. 1. ed. Rio de Janeiro: Bookman, 2003.

TANENBAUN, Andrew S. Redes de Computadores. 4. ed. Rio de Janeiro: Campus,

2003.

http://www.voipbra.com.br/definicao/tcpip.htm

____________________________________________________ 61

APÊNDICE A – DIAGRAMA DE CLASSE.

Abaixo está descrito o diagrama de classe do sistema proposto pela equipe.

Figura 19: Diagrama de Classe

____________________________________________________ 62

APÊNDICE A – MÉTODOS POSSÍVEIS DE SOLICITAÇÃO DE CONEXÃO

As imagens apresentadas abaixo representam as maneiras possíveis de

solicitação de abertura ou fechamento de conexão.

Figura 20: Conexão via emissor

Figura 21: Conexão via receptor

Figura 22: Transmissão dos dados

1 - Conexão via remetente.

Pedido para abrir conexão.

ReceptorEmissor

Confirmação de Conexão.

A Submissão está aberta para transferência.

Pedido para abrir conexão.ReceptorEmissor

Confirmação de conexão.

A Submissão está aberta para transferência.

2 - Conexão via receptor.


Bloco de dados.

ReceptorEmissor

Confirmação da transmissão.

3 - Transmissão dos dados.

____________________________________________________ 63

Figura 23: Fechar conexão via emissor

Figura 24: Fechar conexão via receptor

Pedido para fechar.

ReceptorEmissor

Confirmação de fechamento.

4 – Fechar conexão via emissor.

Pedido para fechar conexão.ReceptorEmissor

Confirmação de conexão fechada.

5 – Fechar conexão via receptor.

Pedido para fechar conexão.

____________________________________________________ 64

APÊNDICE B – CASOS DE CONFLITO AO SOLICITAR ABERTURA

OU FECHAMENTO DE CONEXÃO

O emissor sempre tem prioridade e o receptor tem que reconhecer os

elementos de protocolo deste. Como consequência da transmissão, o emissor pode

decidir sobre o pedido do receptor, abrir ou fechar conexão, e deve ser respondido

com o elemento do protocolo correspondente.

Figura 25: Conflito no pedido da conexão

Figura 26: Conflito no envido do bloco de mensagem

Figura 27: Conflito no pedido de fechamento de conexão


ReceptorEmissor

Confirmação de conexão.

* Remetente sempre tem prioridade.

Send Bloco de Dados

ReceptorEmissor

Confirmação de recebimento

* Remetente sempre tem prioridade.


Pedido para Fechar

conexão.

ReceptorEmissor


fechada.

Remetente sempre tem prioridade.

Pedido para Fechar

conexão.

____________________________________________________ 65

Figura 28: Elemento desconhecido no telegrama

Figura 29: Elemento desconhecido no telegrama

ReceptorEmissor


Pedido para Fechar

conexão.

Elemento inesperado no

protocolo


fechada.

Send Bloco de Dados

ReceptorEmissor

Confirmação de recebimento.


Elemento inesperado no

protocolo

____________________________________________________ 66

APÊNDICE C – TELEGRAMA: PEDIDO PARA ABRIR SUBMISSÃO

A estrutura de telegrama apresentada na Tabela 13: Pedido para abrir

submissão deve ser gerada para o pedido de abertura de submissão.

Tabela 13: Pedido para abrir submissão

Identificação Posição Tamanho Conteúdo

Número da Submissão do Emissor

1 - 4 4 Exemplo: "0012"

Número da Submissão do Receptor

5 - 8 4 Exemplo: "0002"

Elemento do protocolo 9 - 10 2 "SO"

Tamanho do Objeto de Identificação

11 -12 2 "00"

Objeto de Identificação Não suportado PMON_DAE até o momento.

Número de blocos que serão transmitidos.

13 - 18 6 "000000" Não suportado pelo PMON_DAE até o momento.

Tamanho dos blocos em bytes 19 - 24 6 "000000" Não suportado pelo PMON_DAE até o momento.

Número da ordem de geração. 25 - 30 6 "000000" Não suportado pelo PMON_DAE até o momento.

Tipo da transmissão. 31 - 32 2 "01" -> Transmissão não segmentada. "02" -> transmissão segmentada. "04" -> Transferência de arquivo; Não suportado pelo PMON_DAE até o momento.

Função de backup de dados


Tamanho máximo do bloco. 35 - 38 4 Tamanho máximo de bloco permitido pelo emissor em bytes. Exemplo: "0512"

Tamanho do ponto de partida 39 - 42 4 "0000" -> Sem ponto de partida. ou exemplo. "0006" -> 6 byte do ponto de partida.

Informação do ponto de partida 43 - (43+m-1) m Exemplo: "000567"

Comprimento de inicialização dos dados

(43+m) - (43+m+3)

4 "0000"

Dados de inicialização

Não suportado pelo PMON_DAE até o momento.

____________________________________________________ 67

APÊNDICE D - TELEGRAMA: ACKNOWLEDGE PARA CRIAR

SUBMISSÃO

Este telegrama e formado quando a conexão é criada com sucesso, após

isso uma mensagem de confirmação acknowledge é encaminha ao parceiro da

submissão. Abaixo segue a Tabela 14: Acknowledge para abertura de submissão

contendo o conteúdo para este telegrama.

Tabela 14: Acknowledge para abertura de submissão

Identificação Posição Tamanho Identificação


1 - 4 4 Número da Submissão do Emissor


5 - 8 4 Número da Submissão do Receptor

Elemento do protocolo 9 - 10 2 “AO”

Acknowledgement informação.

11 - 12 2 "00" -> Nenhum erro. "01" -> Bloqueado "02" -> Objeto encaminhado "03" -> Erro "04" -> Informação já recebida "05" -> Não há dados disponíveis "06" -> Tamanho do ponto de partida. "11" -> Destino da submissão incorreta. "12" -> Elemento do protocolo incorreto. "13" -> Objeto ID incorreto. "14" -> falta o tipo de transmissão. "15" -> Tamanho do bloco incorreto "16" -> Estrutura de arquivo incorreta.

Tamanho do Objeto de Identificação

13 -14 2 "00"

Objeto de Identificação Não suportado PMON_DAE até o momento.

Numero da ordem de geração.


Tipo da transmissão. 21 - 22 2 "01" -> Transmissão não segmentada.

"02" -> transmissão segmentada.

"04" -> Transferência de arquivo;

Não suportado pelo PMON_DAE até o

momento.

Função de backup de dados

23 - 24 2 "00"

Não suportado pelo PMON_DAE até o

____________________________________________________ 68

momento.

Tamanho máximo do bloco. 25 - 28 4 Tamanho máximo de bloco permitido pelo

emissor em bytes. Exemplo: "0512"

Tamanho do ponto de partida 29 - 32 4 "0000" -> Sem ponto de partida. ou exemplo. "0006" -> 6 byte do ponto de partida.

Informação do ponto de partida

33 - (33+m-1)

m Exemplo.: "000567"

Length of initialization data (33+m) - (33+m+3)

4 "0000"

Dados de inicialização

Não suportado pelo PMON_DAE até o momento.

____________________________________________________ 69

APÊNDICE E – TELEGRAMA: PEDIDO PARA FECHAR SUBMISSÃO

A Tabela 15: Pedido para fechar submissão mostra os elementos que devem

existir no telegrama que faz o pedido para fechar uma conexão.

Tabela 15: Pedido para fechar submissão






Elemento do protocolo 9 - 10 2 “SC”

Causa do pedido para desconexão .

11 - 12 2 "00" -> Fim da transferência de arquivo. "01" -> Bloqueado "02" -> Erro ao acessar objeto. "03" -> Falha. "05" -> Iniciado pelo receptor. "12" -> Elemento do protocolo incorreto.

____________________________________________________ 70

APÊNDICE F – TELEGRAMA: ACKNOWLEDGE AO FECHAR

SUBMISSÃO

A Tabela 16: Acknowledge ao fechar submissãoErro! Fonte de referência

não encontrada. mostra os elementos que devem existir no telegrama que faz a

confirmação de conexão fechada com sucesso.

Tabela 16: Acknowledge ao fechar submissão






Elemento do protocolo 9 - 10 2 “AC”

Causa do pedido para desconectar.

11 - 12 2 "00" -> Fim da transferência de arquivo. "01" -> Bloqueado "02" -> Erro ao acessar objeto. "03" -> Falha. "05" -> Iniciado pelo receptor. "12" -> Elemento do protocolo incorreto.

____________________________________________________ 71

APÊNDICE G – TELEGRAMA: ENVIAR BLOCO DE DADOS.

A Tabela 17 mostra os elementos que devem existir no telegrama para o

envio de dados.

Tabela 17: Enviar bloco de dados






Elemento do protocolo 9 - 10 2 “SD”

Contador de blocos transferidos.

11 - 14 4 Contador de blocos de dados transferidos, de acordo com a submissão aberta varia de 0001 a 9999;

Tamanho do bloco 15 - 18 4 O tamanho do bloco que será transmitido sem o cabeçalho.

Tamanho restante (somente com transmissão tipo2)

19 - 24 6 Comprimento total indicado no primeiro bloco, tamanho restante do bloco seguinte.

Dados enviados 19 - (19+x -1) ou 24 - (24+x-1)

X X variável de acordo com o tamanho do telegrama.

Backup dos dados. 19 + x ou 24 + x

Não suportado pelo PMON_DAE, até o momento.

____________________________________________________ 72

APÊNDICE H – TELEGRAMA: ACKNOWLEDGE AO ENVIAR UM BLOCO DE DADOS

Este telegrama é enviado como confirmação do recebimento de um bloco de

dados, os elementos citados na Tabela 18 fazem parte deste telegrama.

Tabela 18: Acknowledge ao enviar um bloco de dados






Elemento do protocolo 9 - 10 2 “AD”

Acknowledgement informação.

11 - 12 2 "00" -> Positivo acknowledgement. "01" -> Submissão bloqueada. "11" -> Submissão destino incorreta. "12" -> Elemento do protocolo incorreto. "13" -> Irregularidades na sequência. "14" -> Erro durante transmissão.

Informação do receptor 13 - 14 2 Checksum

Contador do bloco 15 - 18 4 Contador para do acknowledgement da transmissão.

____________________________________________________ 73

APÊNDICE I – IMAGEM SEND DATA.

Na Figura 30: Imagem SendData utilizou-se o programa Wireshark para

capturar o tráfego de informações trocadas entre os programas FenixPmon e o

software proposto pela equipe. O ambiente de testes foi criado com uma máquina

virtual Windows Xp e os softwares FenixPmon e Wireshark instalados nela. Como é

possível observar pela imagem abaixo o telegrama trocado contém o elemento SD.

Figura 30: Imagem SendData

____________________________________________________ 74

APÊNDICE J – IMAGEM CONFIRMAÇÃO DA SEQUÊNCIA FHUDP.

Na Figura 32: Imagem Send Data é possível observar a resposta de

confirmação de recebimento pelo fhudp da mensagem apresentada na imagem

anterior.

Figure 30 - Imagem Send Data Figura 31: Imagem Send Data Figura 32: Imagem Send Data

____________________________________________________ 75

VEJA EM APÊNDICE K – IMAGEM ACKNOWLEDGE DATA. A Figura 33: Imagem Send Data representa a confirmação do recebimento

do telegrama pelo FenixPmon, este programa reconhece o telegrama encaminhado

pelo sistema criado e em seguida monta o telegrama de Acknowledge e o retorna.

Figura 33: Imagem Send Data

____________________________________________________ 76

VEJA EM APÊNDICE L – IMAGEM CONFIRMAÇÃO ACKNOWLEDGE

DATA FHUDP.

Finalizando a sequência de mensagens trocadas entre os sistemas está a

confirmação de recebimento de telegrama enviada pelo fhudp do sistema proposto

pela equipe (ver Figura 34: Acknowledge fhudp).

Figure 1 - Acknowledge fhudp Figura 34: Acknowledge fhudp

____________________________________________________ 77

AUTORIZAÇÃO

Autorizamos a reprodução e/ou divulgação total ou parcial da presente obra,

por qualquer meio convencional ou eletrônico, desde que citada a fonte.

Nome do autor: Cristian de Conto e Leonardo Becher Souza

Assinatura do autor: ____________________________

Cristian de Conto

Assinatura do autor: ____________________________

Leonardo Becher Souza

Instituição: Universidade Tecnológica Federal do Paraná

Local: Curitiba, Paraná

E-mail: [email protected]

[email protected]

modelo de dissertação/tese - dainfcristina/pmon.pdf · porque amigo não se pede, não se compra,...

Documents