View
215
Download
0
Category
Preview:
Citation preview
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 32: Imagem Send Data ..................................................................... 73
Figura 33: Imagem Send Data ..................................................................... 73
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é
Armação Pintura Montagem
10 12 43
Total = 65
Tabela 3: Levantamento equipamentos Anchieta
Unidade de produção Anchieta
Armação Pintura Montagem
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.
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 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
{Verificar o tamanho do telegrama} A1
{Verifica o tipo do cabeçalho} A1
{Verifica SSNR e RNSR} A1
{Verificar o telegrama do equipamento e
reconhecer o elemento de protocolo AO} A1
FLUXOS ALTERNATIVOS
A1: em { Verificação de telegrama }
Todos os processos descritos por A1 devem estar
de acordo com o especificado, 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.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.
Atores envolvidos Equipamentos do chão de fábrica e Sistema de
____________________________________________________ 30
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 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.
{Verificar o tamanho do telegrama} A1
{Verifica o tipo do cabeçalho} A1
{Verifica SSNR e RNSR} A1
{Verificar o telegrama do equipamento e
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.
{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
condição não seja atendida a submissão não é
aberta e uma mensagem de erro é retornada ao
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.
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 e a conexão entre os
equipamentos deve estar ativa.
Pós-condições O receptor deve enviar a confirmação do
recebimento dos dados.
FLUXO BÁSICO
Emissor Receptor
Prepara um telegrama com os parâmetros
necessários para confirmação das informações
recebidas.
{Verificar o tamanho do telegrama} A1
{Verifica o tipo do cabeçalho} A1
{Verifica SSNR e RNSR} A1
{Verificar o telegrama do equipamento e
reconhecer o elemento de protocolo AO} A1
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.
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 e a conexão entre os
equipamentos deve estar ativa.
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.
{Verificar o tamanho do telegrama} A1
{Verifica o tipo do cabeçalho} A1
{Verifica SSNR e RNSR} A1
{Verificar o telegrama do equipamento e
reconhecer o elemento de protocolo SC } A1
Executa sub-fluxo finalizar conexão.
{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
condição não seja atendida a submissão não é
aberta e uma mensagem de erro é retornada ao
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.
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 e a conexão entre os
equipamentos deve estar ativa.
Pós-condições A conexão entre os equipamentos deve ser
finalizada.
FLUXO BÁSICO
Emissor Receptor
Prepara um telegrama com os parâmetros
necessários para enviar ao equipamento que
solicitou o fechamento da conexão.
{Verificar o tamanho do telegrama} A1
{Verificar o tipo do cabeçalho} A1
{Verificar SSNR e RNSR} A1
{Verificar o telegrama do equipamento e
reconhecer o elemento de protocolo AC} A1
FLUXOS ALTERNATIVOS
A1: em {Verificação de telegrama }
Todos os processos descritos por A1 devem estar
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
Confirmação de conexão
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:
SSNR = 02 canal de submissão do emissor.
RSNR = 11 canal de submissão do receptor.
____________________________________________________ 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;
SSNR = 0011 canal de submissão do emissor.
____________________________________________________ 55
RSNR = 0002 canal de submissão do receptor.
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.
SSNR = 02 canal de submissão do emissor.
RSNR = 11 canal de submissão do receptor.
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.
____________________________________________________ 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.
Pedido para abrir conexão.
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
Pedido para abrir 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 abrir conexão.
Pedido para Fechar
conexão.
ReceptorEmissor
Confirmação de conexão
fechada.
Remetente sempre tem prioridade.
Pedido para Fechar
conexão.
____________________________________________________ 65
Figura 28: Elemento desconhecido no telegrama
Figura 29: Elemento desconhecido no telegrama
ReceptorEmissor
Remetente sempre tem prioridade.
Pedido para Fechar
conexão.
Elemento inesperado no
protocolo
Confirmação de conexão
fechada.
Send Bloco de Dados
ReceptorEmissor
Confirmação de recebimento.
Remetente sempre tem prioridade.
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
33 - 34 2 "00" Não suportado pelo PMON_DAE até o momento.
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
Número da Submissão do Emissor
1 - 4 4 Número da Submissão do Emissor
Número da Submissão do Receptor
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.
15 - 20 6 "000000" Não suportado pelo PMON_DAE até o momento.
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
Identificação Posição Tamanho Identificação
Número da Submissão do Emissor
1 - 4 4 Número da Submissão do Emissor
Número da Submissão do Receptor
5 - 8 4 Número da Submissão do Receptor
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
Identificação Posição Tamanho Identificação
Número da Submissão do Emissor
1 - 4 4 Número da Submissão do Emissor
Número da Submissão do Receptor
5 - 8 4 Número da Submissão do Receptor
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
Identificação Posição Tamanho Identificação
Número da Submissão do Emissor
1 - 4 4 Número da Submissão do Emissor
Número da Submissão do Receptor
5 - 8 4 Número da Submissão do Receptor
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
Identificação Posição Tamanho Identificação
Número da Submissão do Emissor
1 - 4 4 Número da Submissão do Emissor
Número da Submissão do Receptor
5 - 8 4 Número da Submissão do Receptor
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: cristian1110@terra.com.br
leonardo.bsouza@gmail.com
Recommended