Análise e Configuração de um Sistema Distribuído Baseado ...paf/proj/Set2003/RFieldBus.pdf ·...
Transcript of Análise e Configuração de um Sistema Distribuído Baseado ...paf/proj/Set2003/RFieldBus.pdf ·...
Instituto Superior de Engenharia do Porto
Departamento de Engenharia Informática
5º Ano Licenciatura em Engenharia Informática Ramo de Computadores e Sistemas
Disciplina de projecto 2002/2003
Análise e Configuração de um Sistema Distribuído Baseado na Tecnologia RFieldbus
- Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia -
Setembro 2003
(Versão 1.0) Autor: Marco Paulo dos Santos Alves Orientador: Prof. Eduardo Tovar
Análise e Configuração de um Sistema Distribuído Baseado na Tecnologia Rfieldbus
II
Índice Índice de tabelas ..............................................................................................................III
Índice de figuras ..............................................................................................................III
Objectivo ........................................................................................................................... 1
1 Introdução ................................................................................................................. 2
2 PROFIBUS (PROcess FIeld BUS) ........................................................................... 4
2.1 Camada física................................................................................................ 7
2.2 Camada de ligação lógica de dados .............................................................. 7
2.3 Camada de aplicação .................................................................................... 8
3 TCP/UDP/IP ............................................................................................................. 9
3.1 Camada de aplicação .................................................................................. 10
3.2 Camada de transporte ................................................................................. 10
3.3 Camada de rede ou de interligação ............................................................. 11
3.4 Camada de subrede ..................................................................................... 12
3.5 Características relevantes do TCP/UDP/IP ................................................ 12
3.6 Conclusão ................................................................................................... 13
4 Integração wireless no RFieldbus ........................................................................... 14
4.1 Implementação da plataforma rádio ........................................................... 14
4.2 Mobilidade .................................................................................................. 15
4.3 Mecanismos de suporte à mobilidade ......................................................... 15
5 Integração TCP/UDP/IP no RFieldbus ................................................................... 18
5.1 DP/IP Dispatcher ........................................................................................ 19
5.2 ACS (Access Control and Scheduling)....................................................... 20
5.3 IP MAPPER................................................................................................ 21
5.4 DP MAPPER .............................................................................................. 23
5.5 Aspectos Gerais de Integração.................................................................... 23
6 Configuração de um sistema RFieldbus ................................................................. 26
7 Conclusão ............................................................................................................... 34
8 Referencias ............................................................................................................. 35
Análise e Configuração de um Sistema Distribuído Baseado na Tecnologia Rfieldbus
III
Índice de tabelas Tabela 3-1: Quadro das variações de um datagrama IP. ................................................ 13
Tabela 6-1: Requisitos do tráfego IP. ............................................................................. 29
Tabela 6-2: Resumo das tramas a transmitir por ciclo. .................................................. 30
Tabela 6-3: Tabela de escalonamento............................................................................. 30
Tabela 6-4: Parâmetros referentes à gestão da mobilidade. ........................................... 32
Índice de figuras Figura 2-1: Exemplo de uma rede PROFIBUS. ............................................................... 4
Figura 2-2: Comparação da pilha OSI com a pilha PROFIBUS. ..................................... 7
Figura 3-1: Comparação da pilha OSI com a pilha TCP/IP. ............................................ 9
Figura 4-1: Exemplo do procedimento de handoff......................................................... 16
Figura 5-1: Pilha RFieldbus. ........................................................................................... 19
Figura 5-2: Exemplo de um escalonamento. .................................................................. 21
Figura 6-1: Modelo do sistema implementado. .............................................................. 26
Figura 6-2: Topologia da rede wireless. ......................................................................... 32
Análise e Configuração de um Sistema Distribuído Baseado na Tecnologia Rfieldbus
1
Objectivo
Este trabalho enquadra-se num projecto mais amplo, que reuniu um significativo
número de pessoas e meios, tendo por finalidade a criação de uma arquitectura de
comunicações industriais apta a suportar comunicações wireless e multimédia, num
ambiente “profissional”, mais exigente, como é o caso de um ambiente industrial.
Este relatório, em particular, tem por objectivo sintetizar os aspectos mais relevantes
desse desenvolvimento tecnológico, âmbito do projecto Europeu RFieldbus [1] e,
essencialmente, ilustrar a utilização dessa tecnologia numa aplicação concreta. Este
último aspecto é de primordial importância, já que constitui um importante contributo
para a compreensão da correcta abordagem de parametrização da rede RFieldbus, por
forma a que esta proporcione a qualidade de serviço adequada aos requisitos das
aplicações suportadas.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
2
1 Introdução
Os sistemas de automação industrial mais recentes utilizam arquitecturas fortemente
distribuídas, suportadas por redes de comunicações vocacionadas para aquisição de
informação e funções de controlo e comando. A performance e a confiança exigidas a
um sistema de automação industrial dependem fortemente das características das redes
que o suportam.
As redes locais (LAN – Local Area Network) tornaram-se muito populares nestes
ambientes, possibilitando a ligação de diversos dispositivos, como sensores, actuadores
e controladores, a baixo custo. As redes de comunicação que interligam este tipo de
dispositivos são conhecidas por redes fieldbus.
Tipicamente uma rede fieldbus assenta numa estrutura de camadas, que derivam da
pilha Open System Interconnection (OSI). Embora só utilizem três das sete que
compõem a pilha OSI, as funcionalidades que são implementadas pelas camadas
“suprimidas” encontram-se, de certa forma, distribuídas pelas três camadas
implementadas. Mas, formalmente, diz-se que uma rede fieldbus implementa apenas as
camadas física, de ligação de dados e da aplicação.
Existem muitos protocolos e serviços que podem ser usados para implementar cada uma
dessas três camadas. Algumas das arquitecturas fieldbus mais comuns são: o Factory
Implementation Protocol (FIP) conhecido actualmente como WorldFIP; Process
Networks (P-NET); Controller Area Network (CAN); PROcess FIeld BUS
(PROFIBUS).
Este trabalho foca particularmente o PROFIBUS, nomeadamente no que toca às suas
evoluções a nível de novos serviços. São eles o suporte à multimédia e às comunicações
wireless, especificados e desenvolvidos no âmbito do projecto Europeu RFieldbus [1].
Este relatório está assim organizado:
Capítulo 2: descrição dos aspectos essenciais da arquitectura PROFIBUS.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
3
Capítulo 3: breve descrição dos protocolos TCP/UDP/IP. Atendendo ao contexto actual
da multimédia, a consideração destes protocolos nas extensões a uma rede industrial é
quase um requisito. Neste capítulo discute-se ainda o impacto da sua integração na
arquitectura original do PROFIBUS.
Capítulo 4: descrição de como as comunicações wireless são incorporadas no
RFieldbus. A tecnologia wireless permite a mobilidade dos nós. Para que essa
mobilidade seja possível há que implementar alguns mecanismos. Neste capítulo serão
descritos os mecanismos desenvolvidos para o Rfieldbus e que permitem, de forma
eficiente, suportar a mobilidade de nós.
Capítulo 5: descrição da integração do TCP/UDP/IP no PROFIBUS. É feita uma
apresentação da pilha protocolar e uma descrição das novas subcamadas. Descrevem-se
ainda as situações de conflito entre os dois protocolos, e os mecanismos utilizados na
sua resolução.
Capítulo 6: apresentação e configuração de um sistema industrial que utiliza a
tecnologia RFieldbus. Depois de explanada a teoria que envolve o RFieldbus, nos
capítulos anteriores, faz-se uma abordagem à sua utilização prática.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
4
2 PROFIBUS (PROcess FIeld BUS)
O PROFIBUS é um protocolo normalizado da família dos fieldbus. Fornece suporte
para a interligação de dispositivos de diversos fabricantes, sem que seja necessário
proceder a modificações significativas ao nível das interfaces, sendo por isso
considerado uma norma aberta (open standard).
O PROFIBUS apresenta três variantes aplicacionais, dependendo do uso pretendido [2]:
• PROFIBUS-FMS (Fieldbus Message Specification):
o Comunicação ao nível da célula e nível instrumentação da hierarquia
CIM (Computer Integrated Manufacturing).
• PROFIBUS-DP (Decentralized Periphery):
o É uma versão simplificada e optimizada da arquitectura PROFIBUS,
dedicada especificamente para comunicações críticas no tempo entre
sistemas de automatização e periféricos distribuídos (por exemplo Figura
2-1).
• PROFIBUS-PA (Process Automation):
o É uma versão utilizada tipicamente na indústria de processos.
Figura 2-1: Exemplo de uma rede PROFIBUS.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
5
O RFieldbus considera a utilização do PROFIBUS-DP, pelo que é esta a versão descrita
no âmbito deste relatório quando mencionadas as características essenciais da
tecnologia PROFIBUS.
Passemos então a descrever algumas das características mais relevantes do PROFIBUS.
O PROFIBUS divide o tráfego em duas categorias: a de alta prioridade e a de baixa
prioridade (incluí mensagens cíclicas, não-cíclicas e de gestão). Estas duas categorias de
mensagens usam duas pilhas de saída independentes ao nível da camada de ligação de
dados. Estas duas categorias são relevantes na maneira como é feita a gestão
temporizada do token, como se verá adiante.
O PROFIBUS assenta na filosofia de masters e slaves. A rede pode ser constituída por
um único master (mono-master) ou por vários masters (multi-master). O acesso ao meio
é controlado por um protocolo de token passing temporizado entre os masters.
Só o master que detém o token é que pode tomar a iniciativa de comunicação. Os outros
nós da rede, quer sejam masters ou slaves, apenas respondem aos pedidos. A este
processo de envio de pedido e recepção de resposta damos o nome de transacção (ou
message cycle).
Como já foi dito, a passagem do token é temporizada. Há um parâmetro essencial para o
correcto funcionamento deste mecanismo: o TT R (Target Rotation Time). O TT R é um
parâmetro específico dos masters (igual em todos) e é configurado na fase de setup da
rede.
Quando o token chega ao master, autorizando-o a comunicar, este começa uma
contagem que só termina aquando da próxima recepção do token. Esta contagem
fornece o TRR (Real Rotation Time), o tempo real de rotação do token. Estes dois valores
permitem o cálculo do tempo de posse do token, o TTH (Token Holding Time), que é a
diferença entre o TT R e o TRR. É este tempo que vai condicionar o número de mensagens
que o master pode enviar. Enquanto o TTH for positivo (é um temporizador
decrescente), o master pode enviar mensagens, caso contrário, o master tem de passar o
token ao próximo master. Esta regra não se aplica no caso do master receber o token
atrasado, isto é, TRR > TTR. Neste caso só pode enviar uma mensagem de alta
prioridade.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
6
Este protocolo funciona da seguinte forma: as estações estão à escuta de pedidos,
excepto o master que detém o token, pois é este que pode efectuar o pedido. Quando
uma estação recebe um pedido, a si dirigido, deve efectuar um acknowledgment ou
retorno de dados (resposta), esta resposta deve ser efectuada dentro de um período de
tempo especifico. Se isto não acontecer, o master, responsável pelo pedido, deve emitir
um novo pedido.
O master trata as mensagens pela seguinte ordem:
1. Ciclos de mensagens de alta prioridade não-cíclicas;
2. Ciclos de mensagens “poll list”;
3. Ciclos de mensagens de baixa prioridade não-cíclicas;
4. Gestão da lista GAP (manutenção do anel lógico).
O protocolo refere que as mensagens do tipo baixa prioridade, cíclicas e GAP devem ser
tratadas com regras específicas.
Um master PROFIBUS usa o parâmetro TSL (Slot Time), também configurado na fase
de setup da rede, para saber o tempo que deve esperar aquando do envio de um pedido,
até à recepção da resposta (caso acknowledge). Este parâmetro é máximo entre o TSL1 e
o TSL2. O TSL1 representa o tempo a esperar aquando do envio de um pedido com
acknowledge, se a resposta não chegar dentro deste período de tempo, o master pode
reenviar o pedido. O TSL2 representa o tempo a esperar aquando do envio de um pedido
sem acknowledge.
Como outros fieldbuses, o PROFIBUS usa apenas três camadas da pilha de referência
OSI, embora as camadas excluídas estejam repartidas pelas existentes. Assim as
camadas são:
• Física;
• Ligação lógica de dados (FDL - Field Bus Data Link);
• Aplicação.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
7
Figura 2-2: Comparação da pilha OSI com a pilha PROFIBUS.
2.1 Camada física
A camada física define o meio físico, incluindo comprimentos máximos de cablagem e
topologias, número máximo de estações e a velocidade de transmissão máxima.
2.2 Camada de ligação lógica de dados
Nesta camada são usados dois protocolos. O Medium Access Control (MAC) é do tipo
token temporizado. Faz o controlo de acesso ao meio, bem como o controlo do tempo de
ciclo do token, como descrito anteriormente. O Fieldbus Data Link (FDL) faz o controlo
e o envio das tramas.
O FDL suporta quatro serviços básicos de transmissão de dados. São eles:
1. Send Data with No acknowledge (SDN) ;
Este fornece ao utilizador (a camada de aplicação) a possibilidade de enviar
informação a uma (unicast), várias (multicast) ou a todas (broadcast) as estações
remotas, não havendo lugar à recepção de uma resposta.
2. Send Data with Acknowledge (SDA);
Possibilita o envio da informação a outra estação e obter, da parte desta, a
respectiva confirmação. Em caso de erro (ou timeout – ver TSL) será efectuada
uma retransmissão.
Pilha OSI Pilha PROFIBUS
Aplicação AL
Apresentação
Secção
Transporte
Rede
LLI DDLM
Lógica DLL Física Física
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
8
3. Request Data with Reply (RDR);
Possibilita o pedido de informação a uma única estação remota de uma forma
cíclica. Em caso de erro (ou timeout – ver TSL) será efectuada uma
retransmissão.
4. Cyclic Send and Request Data with Reply (CSRD);
Possibilita o envio e pedido de informação a outra estação. Em caso de erro, é
efectuada uma retransmissão. Em caso de erro (ou timeout – ver TSL) será
efectuada uma retransmissão.
O SDN é usado principalmente para broadcast, a partir de uma estação activa para uma
estação passiva (slave) ou activa (master) que não detém o token. Nos outros serviços
existe uma relação bilateral, todos os pedidos têm de ter uma resposta, quer seja de
acknowledge ou de dados (resposta). Se a resposta não chegar antes de expirar o tempo
configurado no TSL é efectuada uma retransmissão.
O PROFIBUS permite “polling list” que é criada ao nível da camada FDL, através dos
serviços de RDR e CSRD.
2.3 Camada de aplicação
A camada de aplicação define três serviços diferentes: FMS, DP e PA, descritos
anteriormente. No caso particular deste trabalho só os serviços DP são relevantes.
É exemplo desse serviço o envio do tráfego DPH, em que, de forma automática, as
mensagens de alta prioridade são enviadas a cada chegada do token.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
9
3 TCP/UDP/IP
Estes protocolos são dos mais populares a nível de redes. São os mais usados quer a
nível de redes domésticas, quer a nível mundial na mais famosa rede – a Internet.
Nasceram, não de uma norma internacional, mas sim, a partir da investigação na área de
comutação de pacotes de uma agência do governo Americano, para possibilitar a
interligação de redes heterogéneas, sem que o nível de funcionalidades sofra alterações
nos dispositivos envolvidos.
Este protocolo baseia-se num modelo conceptual de quatro camadas, denominado de
modelo DARPA (referenciando a agência que o desenvolveu inicialmente).
As quatro camadas do modelo são:
• Aplicação;
• Transporte;
• Interligação de rede;
• Subrede.
Figura 3-1: Comparação da pilha OSI com a pilha TCP/IP.
Mas, implicitamente, o modelo comporta as sete camadas do modelo de referência OSI,
uma vez que há camadas que implementam os serviços de mais do que uma camada.
Pilha OSI Pilha TCP/IP
Aplicação
Apresentação Aplicação
Secção
Transporte Transporte
(TCP / UDP)
Rede Interligaçõ de rede (IP)
Lógica Física subrede
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
10
3.1 Camada de aplicação
Fornece serviços às aplicações, através de sockets e ports, para que estas possam aceder
às camadas inferiores, e estabelece os protocolos que estas podem usar para troca de
informação. São exemplos o:
• HTTP (HyperText Transfer Protocol) – protocolo usado no acesso a páginas
Web.
• FTP (File Transfer Protocol) – protocolo usado para a transferência de ficheiros
entre dois dispositivos.
• DNS (Domain Name Service) – protocolo usado para traduzir endereços
alfanuméricos (por exemplo: www.hurray.isep.ipp.pt) em endereços IP
(195.23.79.205).
3.2 Camada de transporte
Fornece serviços de comunicação, à camada de aplicação, quer orientados à conexão,
TCP (Transmission Control Protocol), quer não orientadas à conexão, UDP (User
Datagram Protocol). Estes protocolos terão uma descrição mais pormenorizada neste
relatório pelo seu relevo no âmbito da arquitectura RFieldbus.
TCP (Transmission Control Protocol)
O TCP fornece conexões fiáveis ponto-a-ponto e orientadas à conexão. Devido a estas
características este protocolo impõe um overhead significativo às comunicações. Tem a
seu cargo a criação da conexão, sequenciamento, controlo de fluxo, geração de
confirmação e a recuperação de erros que possam ocorrer nos pacotes enviados.
O TCP permite enviar grandes blocos de informação através de técnicas de
fragmentação e concatenação dos datagramas. Este processo baseia-se na atribuição de
um número sequencial a cada pacote (ou fragmento). Depois de enviado o pacote é
aguardado, da parte do receptor, um acknowledge. Se este não chegar é enviado
novamente o pacote. O número sequencial é usado para reordenar ou descartar os
pacotes. Note-se ainda que a confirmação dos pacotes pode ser feita por grupo de
pacotes, dependendo do tamanho da janela de confirmação (window size).
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
11
UDP (User Datagram Protocol).
Basicamente é uma interface de aplicação para o IP. É simplesmente usado como
multiplexer/desmultiplexer para envio e recepção de datagramas, usando ports e sockets.
É usado quando a quantidade de informação é pequena ou quando a fiabilidade da
comunicação está a cargo da camada superior, pois não garante a entrega, nem
implementa controlo de fluxo ou recuperação de erros.
Este protocolo também é usado para broadcast, uma vez que este serviço não requer
confirmação por parte dos destinatários.
3.3 Camada de rede ou de interligação
Esta camada dá uma imagem “virtual da rede”, e cria o isolamento entre as camadas
superiores e as inferiores. Não implementa mecanismos de controlo de fluxo, nem de
confiança uma vez que não é orientada à conexão. Estas funcionalidades são
implementadas na camada superior, caso seja usado o TCP. Caso contrário (caso UDP)
serão implementadas a um nível superior.
É ao nível desta camada que se faz o endereçamento, empacotamento e
encaminhamento dos pacotes vindos das camadas superiores.
Estes serviços são suportados recorrendo aos seguintes protocolos:
IP – Internet Protocol
Faz o encaminhamento, fragmentação/reconstrução dos datagramas e o endereçamento
IP. Possui uma característica muito importante, que é a de fazer com que uma
mensagem possa ser encaminhada através de redes heterogéneas. Para tal, é efectuada
conversão dos dados, para que eles continuem perceptíveis na rede a que se destinam.
ARP – Address Resolution Protocol
Tem por função a conversão do endereço de rede (IP) no endereço físico da rede
(MAC).
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
12
ICMP – Internet Control Message Protocol
Efectua o diagnóstico e controlo de erros, bem como o estado dos datagramas enviados
pela rede.
IGMP – Internet Group Management Protocol
Proporciona a participação em Multicast, e o seu cancelamento [3]. Só pode ser usado
com o UDP (devido ao Multicast e Broadcast).
3.4 Camada de subrede
Esta camada tem por função receber e colocar na rede (no meio físico) os datagramas.
Tem como característica o facto de ser independente do método de acesso ao meio,
formato das tramas e do meio propriamente dito.
Na pilha de referência OSI, esta camada corresponde à camada de ligação de dados e
física.
3.5 Características relevantes do TCP/UDP/IP
Este protocolo tem subjacentes dois conceitos muito conhecidos: o de cliente/servidor e
o de peer-to-peer. Conceitos que no TCP/UDP/IP se revelam transparentes, mas que no
PROFIBUS levantam alguns problemas. O primeiro, usado continuamente, por exemplo
num acesso Internet, no PROFIBUS não se apresenta de solução fácil. Conforme
descrito no capitulo 2, podemos dizer que o PROFIBUS é, de certa forma, um “tirano”
uma vez que se baseia na filosofia do master/slave. Esta filosofia leva a que os slaves
estejam dependentes de quando o master lhes quer comunicar. Esta exposição também
se pode aplicar ao conceito peer-to-peer, onde dois dispositivos pretendem comunicar
directamente entre si. No PROFIBUS como é o master que controla as comunicações
este conceito levanta alguns problemas. Como por exemplo, quando dois slaves
pretendem trocar mensagens entre si.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
13
Outro aspecto a ter em conta é o tamanho dos datagramas IP, que depende do meio onde
vão ser propagados. Assim temos [4]:
Norma Tamanho mínimo para dados Tamanho máximo para dados Ethernet II 46 1500 802.3 43 1497 802.2 SNAP 38 1492
Tabela 3-1: Quadro das variações de um datagrama IP.
Como podemos verificar, pela tabela acima, os datagramas IP podem variar num
intervalo bastante alargado. Mas pela norma do IP este tem de usar um tamanho mínimo
de 576 bytes e máximo de 65535 bytes. Se se utilizar o PROFIBUS como subrede, o
tamanho máximo, para dados, é de 244 (imposto pelo PROFIBUS). No caso particular
do RFieldbus assume-se o comprimento Ethernet, para o tamanho dos datagramas IP.
Evita-se desta forma que seja o IP a efectuar a fragmentação requerida pelo PROFIBUS,
proporcionando um overhead de comunicações relativamente reduzido, uma vez que o
header IP (máximo de 60 bytes) é maior do que o do RFielbus (2 bytes).
3.6 Conclusão
Atendendo às características apresentadas, pode-se dizer que a integração destes
protocolos num sistema de comunicações de tempo real traz os seus desafios.
O conceito de comunicação entre os dispositivos nos dois protocolos é antagónico. Se
no TCP/UDP/IP os dispositivos podem comunicar livremente, o mesmo já não se passa
no PROFIBUS. Os conceitos cliente/servidor e peer-to-peer do TCP/IP, chocam com o
conceito master/slave do PROFIBUS. As soluções para estes obstáculos à integração
são sucintamente descritos no capítulo 5.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
14
4 Integração wireless no RFieldbus
Tradicionalmente, uma rede fieldbus é constituída por vários dispositivos
(controladores, sensores, etc.) ligados entre si através de um cabo – wired. Com o
advento de novos dispositivos (tais como, os AGV’s – Automation Guided Vehicle, os
PDAs, ou os Hand Held Terminals), surge a necessidade de serem criadas extensões
wireless.
O RFieldbus é o exemplo de uma rede híbrida wired/wireless com inter-operabilidade
com a rede nativa (wired) PROFIBUS. A comunicação wireless usada no RFieldbus é
do tipo rádio.
O RFieldbus tinha como requisito usar uma norma wireless existente no mercado. Para
isso foram estudadas as seguintes normas: UMTS, DECT, HIPERLAN, IEEE 802.11 e
Bluetooth. Dos estudos saiu a conclusão que a melhor, atendendo aos requisitos
temporais e fiabilidade, era o IEEE 802.11 (MAC-less 802.11b usando Direct Sequence
Spread Spectrum).
Esta tecnologia apresenta uma grande maturidade e algumas características adicionais
que se encaixam bem nos requisitos do RFieldbus. Por exemplo, incorpora técnicas de
recepção responsáveis por uma performance robusta em sistemas industriais (que
ultrapassa os problemas resultantes dos ecos).
4.1 Implementação da plataforma rádio
A plataforma rádio consiste nos elementos básicos implementados na interface física do
PROFIBUS. Esta interface tem duas componentes: Radio Functionality e Radio Front-
End.
O radio Front-End consiste no transmissor/receptor, também chamado de Radio
Modem.
O Radio Functionality incorpora todo um conjunto de funções que vão suportar a
arquitectura proposta. Estas funções estão implementadas no Radio Adaption Element
(RAE), que define a interface do PROFIBUS Physical Layer no Radio Physical Layer.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
15
O Radio Adaption Element é uma unidade de hardware, que implementa a interface
RFieldbus. As suas principais valências são: interface física de rádio, interface
PROFIBUS, funções de controlo de rádio, encriptação, detecção de erros, elemento de
identificação rádio e controlo de acesso do canal de rádio.
4.2 Mobilidade
Dado que o RFieldbus terá de suportar diferentes topologias, estas poderão ser
constituídas por segmentos wired fixos e móveis, e nós wireless que podem operar
como master ou slave.
Como os ambientes industriais são complexos, é usual dividir a área, caso se justifique,
em células (rádio). Desta forma temos áreas de cobertura mais pequenas e assim cada
estação (wireless) comunica dentro de uma determinada área. Somente os nós em que a
área de cobertura se sobrepõe é que podem comunicar directamente entre si. Cada célula
utiliza frequências diferentes.
4.3 Mecanismos de suporte à mobilidade
Os protocolos wireless têm o suporte à mobilidade como uma das características mais
avançadas. A área de cobertura é um elemento que influência a arquitectura do sistema,
bem como os mecanismos de mobilidade. As áreas a cobrir são divididas em células.
Com esta divisão dá-se origem à mobilidade inter-cell, ou seja, a capacidade dos nós
poderem passar de uma célula para outra. O que faz com que seja necessária a
existência de um mecanismo que permita a um nó de se “desligar” de uma célula e se
“ligar” a outra. Este mecanismo é conhecido como o handoff. Este mecanismo deve
funcionar de forma transparente e rápida, possibilitando desta forma que não haja perda
de pacotes, e que estes sejam encaminhados de forma eficiente. Também deve detectar a
qualidade do canal e efectuar a mudança.
No RFieldbus há uma estação específica – o Mobility Master (MobM) – que é o
responsável por iniciar o procedimento de gestão de mobilidade. Durante um período de
tempo (beacon period) as estações móveis podem proceder à avaliação do sinal que
recebem dos diferentes (Link) Base Stations (LBS) e desta forma comutar para o canal
que tiver melhor sinal.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
16
O Mobility Master (o master que tem por função iniciar o procedimento de handoff)
emite, em broadcast, uma frame especial (beacon trigger). Com uma periodicidade que
depende da máxima velocidade das estações móveis. Quando as Base Stations (BS)
recebem esta frame, emitem uma série de frames (beacons) através dos seus canais de
rádio. As estações móveis recebem estas frames e aferem da qualidade de todos os
canais, mudando para o melhor. As (Link) Base Stations ao receberem o beacon trigger,
retransmitem-no e iniciam a transmissão de beacons (frames especiais) na sua
frequência. As estações móveis ao receberem estes beacons iniciam o processo de
handoff. Este consiste em avaliar todos os canais e comutar para o melhor.
As LBS e as BS operam em diferentes canais rádio (LBS no canal 1 e BS no canal rádio
2) [6], de forma a se obter uma rede wireless estruturada suportando mobilidade inter-
cell.
Figura 4-1: Exemplo do procedimento de handoff.
O processo de gestão da mobilidade é iniciado a partir do mobility master. Após o seu
início o mobility master deve aguardar um período de tempo antes de passar o token,
este período é definido pelo beacon period. Deve ser definido tendo em conta o tempo
que demora o beacon trigger a chegar à estação mais distante, mais o tempo de handoff
(nome pelo qual se designa o processo de avaliação e posterior troca de canal de rádio
por parte de uma estação móvel) da estação.
Cada estação emite um número de beacons próprios. Este número é calculado em
função do tempo que a estação detém para emitir beacons e do tempo de duração de um
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
17
beacon. O tempo de duração resulta da soma do tempo que o beacon demora a percorrer
a rede e do intervalo entre dois beacons.
Quando as estações móveis recebem o primeiro beacon iniciam o processo de handoff,
que consiste na escuta de todos os canais e opta por aquele que tiver melhor sinal [7].
Como se pode observar na figura 4-1, a estação móvel optaria pelo canal 2.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
18
5 Integração TCP/UDP/IP no RFieldbus
Observando o mercado, em particular o da multimédia, podemos constatar o imenso
número de aplicações disponibilizadas. Algumas delas vocacionadas para o uso em
rede, nomeadamente para a Internet, que como se sabe usa o protocolo TCP/IP como
forma de transmissão dos dados.
Num ambiente industrial, um protocolo como o TCP/IP não pode ser utilizado
directamente, pois as suas características não se enquadram num sistema de tempo real,
em que o protocolo usado é o PROFIBUS. E, se por um lado temos o PROFIBUS com
requisitos temporais, por outro, temos as aplicações multimédia com requisitos de
Qualidade de Serviço. Atendendo às características dos dois protocolos, podem ser
realçadas algumas contrariedades na coabitação:
Ø O esquema master/slave do PROFIBUS e do cliente/servidor do TCP/IP;
Ø O tamanho dos datagramas IP é superior ao suportado pelo PROFIBUS
(tamanho e endereçamento);
Ø Escalonamento e controlo de admissão, processo necessário para que o tráfego
IP possa “coabitar” com o tráfego nativo, sem prejudicar este último mas
conferindo qualidade de serviço ao IP.
No RFieldbus foram desenvolvidos e implementados mecanismos que permitem esta
coabitação. Por um lado à que controlar o tráfego IP, pois este não foi pensado para ser
usado em ambientes que exijam tempo real, de forma a não “prejudicar” o tráfego
PROFIBUS (tempo real). Este controlo é feito através do ACS (Admission Control and
Scheduling) e do IP MAPPER.
A junção dos dois protocolos deu origem ao protocolo RFieldbus, cuja pilha dual é
apresentada na figura seguinte:
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
19
Figura 5-1: Pilha RFieldbus.
A zona a sombreado representa as novas sub-camadas, as quais se descrevem de uma
forma simplificada a seguir.
5.1 DP/IP Dispatcher
Está situado por debaixo das camadas ACS e DP MAPPER. A sua principal função é a
de escolonar e colocar o tráfego IP e o DP na camada de ligação de dados PROFIBUS.
O Dispatcher implementa 5 filas para pedidos.
Ø A DPH, para o tráfego PROFIBUS de alta prioridade.
Ø A DPL, para o tráfego PROFIBUS de baixa prioridade.
Ø A IPH, para o tráfego IP que requer QoS.
Ø A IP/DPBE, para o tráfego sem requisitos de QoS do IP, e para mensagens
acíclicas do DP.
Estas pilhas são controladas através de parâmetros que informam o dispatcher do modo
que tem de operar. O parâmetro TMA (Master Allocation Time) contém o tempo que o
master pode deter o token. O TMC (Message Cycle Time) define o tempo que uma
mensagem demora a percorrer a rede, inclui tempo de pedido, tempo de espera e, se for
caso disso, tempo de resposta. A conjugação destes dois parâmetros permite ao
dispatcher controlar o envio de mensagens para a camada de ligação de dados. Pois
aquando do envio de uma mensagem o dispatcher decrementa o valor do TMC ao TMA e
obtém o valor que resta para colocação de mensagens. O dispatcher só coloca
Transporte TCP/UDP
IP
PROFIBUS DP
IP MAPPER
ACS DP MAPPER
DP/IP Dispacher FDL DIS
DCE
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
20
mensagens na camada de ligação de dados se o TMA for superior ou igual ao TMC.
Evitando desta forma o atraso na passagem do token. Todo este processo é efectuado a
cada TDCY (Dispatcher Cycle Time), este parâmetro define o tempo que o token demora
a percorrer todos os masters. Como não existe sincronização entre as camadas de
ligação de dados e o dispatcher, este parâmetro funciona nesse sentido.
Existem quatro parâmetros que permitem controlar o número de mensagens que será
enviado a partir de cada fila, eles são:
Ø O TDPH – define o tempo que o dispatcher pode usar para tráfego PROFIBUS de
alta prioridade.
Ø O TDPL – define o tempo que o dispatcher pode usar para tráfego PROFIBUS de
baixa prioridade.
Ø O TIPH – define o tempo que o dispatcher pode usar para tráfego IP de alta
prioridade (com QoS).
Ø O TDP/IPBE – define o tempo que o dispatcher pode usar para tráfego IP e
PROFIBUS não prioritário, caso sobre tempo dos outros tipos de tráfego este
pode ser adicionado a este parâmetro.
As camadas de ligação de dados e física são as do PROFIBUS, uma vez que já
implementam os mecanismos de acesso a uma rede industrial física.
5.2 ACS (Access Control and Scheduling)
Está situada sob a camada IP MAPPER. Tem por função o controlo/limitação da
utilização dos recursos da rede por parte das aplicações TCP/UDP/IP. A limitação
assenta em políticas de escalonamento específicas, capazes de distinguir entre o tráfego
gerado pelas diferentes aplicações TCP/UDP/IP. Esta pode ser implementada usando
filtros que aplicados aos endereços IP, ports ou a outras características dos dados pode
distinguir as aplicações TCP/UDP/IP. Estas políticas devem atender à QoS requerido
pela aplicação multimédia, bem como respeitar os requisitos temporais.
O IP MAPPER efectua a identificação do tráfego e coloca-o em filas, que depois irão
ser usadas pelo ACS na criação do escalonamento on-line. Estas filas são do tipo FIFO
(First In First Out) e é suportado um tamanho máximo (também parametrizável).
Quando este é atingido alguns pedidos começam a ser descartados.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
21
O ACS pode “encher” as filas IPH e IPBE do Dispatcher. Este usa uma interface para
obter informação sobre quando é que pode passar os dados para essas filas [5].
Figura 5-2: Exemplo de um escalonamento.
O escalonamento é executado periodicamente e pode ser feito de duas formas:
Ø Off-line – é fornecida uma tabela predefinida, que acautela os requisitos
necessários para garantir a QoS. Neste caso o Scheduler funciona como um
dispatcher de tráfego IP.
Ø On-line – é fornecido uma tabela com os parâmetros (temporais) que permitem
ao algoritmo de escalonamento escalonar o tráfego TCP/IP em run-time.
O escalonador usa os parâmetros TDCY e o TIPH para efectuar o escalonamento.
Resumindo, o ACS recebe os pacotes do IP MAPPER e efectua o controlo de os colocar
no DP/IP Dispacher.
5.3 IP MAPPER
É esta camada que interage com o IP. Esta camada é responsável pela conversão dos
pacotes IP em tramas PROFIBUS e vice-versa. O tráfego é classificado segundo duas
categorias, IPH (IP High), tráfego IP que requer QoS (Quality of Service), e IPBE (IP
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
22
Best Effort), tráfego IP sem necessidade de QoS. Estes são depois colocados nas
respectivas filas do Dispatcher.
O IP MAPPER utiliza diferentes entidades para efectuar esta interface. Essas entidades
são:
Ø Fragmentação;
Ø Reconstrução;
Ø Identificação e encaminhamento;
Ø Comutação;
Ø Geração de ID’s.
A entidade de fragmentação é responsável por receber o pacote IP e de o fragmentar em
tramas PROFIBUS, respeitando as limitações impostas pelas camadas inferiores.
Atendendo a isto, o IP MAPPER pode receber um pacote IP já fragmentado (pelo IP),
mas refragmenta o pacote tendo em conta essas limitações.
A entidade de reconstrução é responsável por reconstruir os pacotes IP a partir das
tramas PROFIBUS (processo inverso ao da fragmentação). Estas chegam através da
entidade de comutação ou de identificação e encaminhamento.
A entidade de identificação e encaminhamento trata dos fragmentos provenientes da
entidade de fragmentação ou de comutação. O fragmento é identificado e pode
acontecer uma das seguintes acções:
Ø é transferido para a respectiva pilha, isto acontece quando o fragmento vem da
entidade de fragmentação ou vem das camadas inferiores tendo como destino
outra estação (routing);
Ø é descartado;
Ø é enviado para a entidade de reconstrução.
A entidade de comutação recebe os fragmentos vindos da camada IP, e atendendo ao
serviço usado pela DLL, coloca o fragmento na entidade de identificação e
encaminhamento ou na entidade de reconstrução.
A entidade de geração de ID’s gera, para todos os fragmentos relacionados com um
pacote IP, um identificador numérico único. Os identificadores são usados pela entidade
de fragmentação ou pela entidade de identificação e encaminhamento para os
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
23
fragmentos que se destinam a outras estações. Quando é descartado ou é efectuada a
última transmissão de um fragmento, o ID gerado é libertado para ser re-utilizado
noutro pacote IP.
5.4 DP MAPPER
É esta camada que comunica com o PROFIBUS DP. Para alem das funcionalidades do
PROFIBUS DDLM, introduz mais algumas funcionalidades de forma a possibilitar a
integração do DP com o IP. Essas funcionalidades são:
Ø Efectuar a identificação do tráfego PROFIBUS DP. O tráfego DP é classificado
em DP de alta prioridade (DPH), DP de baixa prioridade (DPL) e DP Best Effort
(DPBE),
Ø Colocar o tráfego na pilha correspondente no DP/IP Dispatcher.
5.5 Aspectos Gerais de Integração
Do ponto de vista do TCP/UDP/IP, esta integração é transparente. Não conhece o
acesso ao meio, não precisa, apenas implementa as camadas de rede e de transporte,
coloca os datagramas na camada de ligação de dados e é esta que se encarrega de as
colocar no meio físico.
Do ponto de vista do PROFIBUS, a pilha TCP/UDP/IP, não passa de mais um cliente da
camada de ligação de dados. Pois, através das camadas adicionadas, o tráfego que é
colocado na camada de ligação de dados tem características de tráfego nativo
PROFIBUS.
Todo o que foi descrito aborda a integração no que diz respeito aos novos componentes,
mas há uma série de problemas relevantes na integração. Tais como:
Ø Suportar a característica ponto-a-ponto do TCP/IP quando ambos são escravos;
Ø O mecanismo de endereçamento IP;
Ø A fragmentação dos datagramas IP;
Ø Gestão de erros;
Ø Os serviços do tipo Broadcast e Multicast.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
24
No PROFIBUS a circulação da informação é feita numa filosofia de master/slave, em
que o slave só pode responder ao seu master, o TCP/UDP/IP, por seu lado, usa a
filosofia ponto-a-ponto, em que os dispositivos são “livres” de comunicar.
Quando a transacção envolve pelo menos um mestre, neste caso podemos ter
(master/master ou master/slave) podem ser usados os serviços da camada de ligação de
dados PROFIBUS.
O problema põe-se quando um slave tem de efectuar um pedido, uma vez que os slaves
não podem solicitar, directamente, informação para alem do seu master. Assim podem
surgir duas situações: slave/master, o slave solicita informação a outro master, e
slave/slave, em que os pedidos têm de ser feitos através do respectivo master, que vai
mediar a comunicação.
Outro problema, é o esquema de endereços IP, que através do protocolo ARP é feita a
correspondência com o endereço MAC (endereço físico).
Aqui trata-se de suportar algo que “alimente” o modelo ARP, isto é, algo dinâmico, que
vai actualizando a tabela ARP à medida das necessidades, ou algo estático, fornecida
previamente.
A identificação dos dispositivos é diferentes (entre o TCP/IP e o PROFIBUS), assim há
necessidade de encontrar um esquema que permita conjugar as duas arquitecturas. O
uso de uma rede de classe C, em que o último octeto corresponde ao endereço
PROFIBUS, foi a solução adoptada. Tem a vantagem de uma conversão simples e
directa, como desvantagem, o uso de subredes é difícil e pouco flexível. Os dispositivos
são identificados por um endereço classe C, com a seguinte nomenclatura X1.X2.X3.Y,
em que X1, X2, X3 representam o endereço de rede e Y o endereço PROFIBUS.
A fragmentação e encapsulação de datagramas IP em RFieldbus levanta algumas
dificuldades. O PROFIBUS (protocolo base do RFieldbus) tem como tamanho máximo
de transmissão (MTU) 244 bytes, por isso, todos os datagramas IP com tamanho
superior a este valor têm de ser fragmentados.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
25
A fragmentação é suportada pelo protocolo IP, mas coloca muito overhead, já que
apresenta um cabeçalho de 60 bytes, devido a isto a fragmentação não pode ser feita
pelo IP.
Esta é feita da seguinte forma:
Ø Fragmentação do datagrama IP com base nas características da rede, pelo IP
MAPPER;
Ø Adição de um cabeçalho com a identificação do fragmento e do datagrama.
A integração do TCP/UDP/IP levanta alguns problemas. Como podemos verificar
houve necessidade de criar mecanismos que solucionassem tais problemas. A criação
das subcamadas IP MAPPER, ACS, DP MAPPER e Dispatcher, foi o maior contributo
para a solução dos problemas levantados.
O protocolo IP fornece o serviço de envio de mensagens para todos os dispositivos
ligados através do mesmo endereço de rede (broadcast). Uma vez que o slave não pode
ter a iniciativa, são utilizados dois tipos de emissores (o master e o slave), em que o
tratamento é diferenciado.
Parte deste problema está resolvido de raiz, uma vez que o PROFIBUS implementa este
serviço, através do serviço SDN, e este pode ser utilizado pelo TCP/UDP/IP.
Quando o broadcast é feito a partir de um dispositivo master o serviço SDN pode ser
usado pelo TCP/UDP/IP. Por outro lado, quando o broadcast é feito a partir de um
dispositivo slave tem de usar um mestre como intermediário. A técnica usada é a
seguinte: o escravo quando contactado, envia, como retorno, o pedido de broadcast, o
mestre ao receber tal pedido efectua um broadcast, como sendo “seu”.
O protocolo IP, também, fornece um serviço de envio de mensagens para um grupo de
dispositivos. Este serviço surgiu para satisfazer, principalmente, as aplicações
multimédia pela Internet.
Este serviço é suportado nos mesmos moldes que o serviço de broadcast.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
26
6 Configuração de um sistema RFieldbus
Depois da abordagem à parte teórica do protocolo, vai ser descrito um sistema de
automação industrial e sua configuração. A descrição que se apresenta mostra os tipos
de desafios a que este protocolo pretende responder. Inclui sistemas móveis (por
exemplo AGV´s, PDAs), sistemas de multimédia (reconhecimento de objectos através
de imagens) e o mais importante num sistema industrial, processos com requisitos
temporais (classificação e separação de peças).
Figura 6-1: Modelo do sistema implementado.
O sistema implementado contém três tapetes rolantes, dois dos quais funcionam em
paralelo, estando ligados ao mesmo servomotor. Desta forma mantêm a mesma
velocidade. O terceiro tapete encontra-se ligado a um outro servomotor. O sistema é
alimentado através de um dispositivo (C1) que contém as peças (pretas, brancas e
cinzentas, estas últimas representam as peças com defeito) a serem colocadas para
identificação e separação. Quando, ou por defeito da peça ou porque as estações de
descarga estão cheias, há necessidade de fazer circular as peças entre os tapetes
paralelos, existem dois braços (SA1 e SA2) com ventosas para comutar as peças. A
separação é feita para as estações de descarga (B2, B3, B4, B5) que se encontram
colocados em posições pré-definidas. Estas são transportadas por AGV’s (AGV1,
AGV2) e por um operador. Os AGV’s movem-se de forma autónoma ou auxiliados por
uma linha. Existe ainda uma estação em que a descarga do AGV é feita por um braço
robótico (R2). O ajustamento do AGV, em relação ao braço, é feito através do
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
27
reconhecimento da sua posição, usando um sistema de câmara para recolha de imagens
[8].
O sistema impõe requisitos de tempo real. Esses requisitos são
Após o estudo do sistema apresentado, concluiu-se que de todos os subsistemas de
tempo real, o subsistema que condiciona os requisitos de tempo real mais crítico é o
conjunto velocidade dos tapetes, mecanismo de reconhecimento da cor e os "braços", o
que logo será este a impor os requisitos de tempo real.
Para implementar tais requisitos existem parâmetros que devem ser configurados. O TT R
(Target Rotation Time) é um desses parâmetros e define o tempo que o token leva a
percorrer todos os masters. Este valor em conjunto com o TRR, tempo que o master
calcula entre duas chagadas consecutivas do token, vão definir o tempo que o master vai
dispor para enviar mensagens, que é o TTH. O valor do TTH será o tempo efectivo que o
master dispõe para enviar mensagens. Este processo encontra-se descrito mais
detalhadamente com capitulo 2. Atendendo à restrição descrita esta variável terá de ter
um valor máximo de 100ms.
Outro aspecto a ter em conta é o tipo de rede, neste caso temos uma rede híbrida
(wired/wireless). O que introduz condicionantes à circulação das mensagens, como
sendo a passagem entre domínios. Sempre que há uma passagem de domínio wired para
o wireless à necessidade de converter a informação. O que introduz tempos de latência,
a propagação da mensagem pode encontrar obstáculos o que introduz tempos extra nas
comunicações. Por tudo isto há necessidade de configurar o TID (Idle Time). Que é o
máximo de dois sub-parametros, o TID1, valor a esperar aquando do envio de mensagens
com confirmação (acknowledge), e o TID2, valor a esperar aquando do envio de
mensagens sem confirmação (unacknowledge).
Ao nível do dispatcher temos o parâmetro TMA (Master allocation Time) que é definido
com o tempo que o master pode usar para enviar mensagens. E o TMC (Time Message
Cycle) que é definido com o tempo que uma mensagem demora a percorrer a rede. Cada
vez que é enviada uma mensagem é decrementado o TMC ao TMA. Desta forma o
dispatcher consegue controlar o envio das mensagens e evita o atraso do token. O TMC é
constituído pelo tempo do pedido, tempo de espera e tempo de resposta. O tempo de
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
28
espera é devido ao meio de propagação do sinal, mas principalmente, pelo tipo de
domínios existentes e a topologia da rede. Se uma mensagem tiver de ser comutada
entre domínios wired/wireless vai demorar mais tempo, à necessidade de conversão das
tramas de wired/wireless e wireless/wired. Isto implica que o tempo de ciclo da
mensagem seja maior.
O TMA resulta da soma de quatro parâmetros, que são:
Ø TDPH – tempo atribuído ao tráfego DP de alta prioridade;
Ø TDPL – tempo atribuído ao tráfego DP de baixa prioridade;
Ø TIPH – tempo atribuído ao tráfego IP de alta prioridade;
Ø TBE – tempo atribuído ao tráfego best effort.
Se o primeiro parâmetro (TDPH) tem uma configuração rígida, já os dois seguintes (TDPL,
TIPH) são configurados em função das necessidades do sistema, o último (TBE) poderá
existir ou não. Caso sobre tempo da configuração dos anteriores ou caso estes não
necessitem de todo o tempo que lhes foi atribuído, este pode ser usado pelo TBE.
Estes parâmetros são configurados à custa do TMC (Time Message Cycle) e do número
de mensagens que é necessário enviar por ciclo. No caso do TDPH o número de
mensagens a enviar depende do número de slaves, no caso do TIPH depende dos
requisitos de QoS das aplicações.
Passando à prática, e recordando os valores vem: TTH = 100ms, o TT R tem de ser igual a
200ms, isto pelo facto de pretendermos ter 100ms de tempo útil para o master.
Desprezando o tempo de passagem do token. Outro valor que é desprezado, pois não é
muito significativo, é da gestão da mobilidade. Caso esta se torne mais frequente o seu
valor terá de ser tido em conta. O TMC é de 1.5ms, e o TMA = 100ms . Com estes dados
os parâmetros TDPH, TDPL, TIPH, TBE podem ser configurados. Assim, para que os 10
slaves sejam “consultados” cada vez que o master receba o token o TDPH deve ser
configurado com o seguinte valor 15ms (10 * 1.5ms). O aumento de slaves implica uma
diminuição do tempo para os outros 3 parâmetros.
Como foi mencionado, os outros parâmetros são configurados em função das
necessidades. Assim, como o tráfego DPL não é significativo, o TDPL pode ser
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
29
configurado para permitir o envio de duas mensagens, o que dá 3ms. Para os restantes
parâmetros o cenário seguinte ilustra a sua configuração.
Traffic Block Size / Bandwidth Periodicity Bits/s
IPH: Image Color Detection (x2) 3 Kbyte each 3 s 8000bps IPH: Remote Image Stream (x2) 3 Kbyte each 1s 24000bps IPH: Voice Connection 16 Kbps 16000bps IPH: Remote 16 Kbyte each 30 s 4237bps
Tabela 6-1: Requisitos do tráfego IP.
Todos os protocolos têm um cabeçalho, os protocolos envolvidos nestas transacções
também os detêm, o cabeçalho IP tem um tamanho de 60 bytes (480 bits) e o RFieldbus,
usa para a fragmentação dos pacotes IP, 2 Bytes (16 bits).
Dados comuns a todos os cálculos:
Tamanho do pacote IP (sem cabeçalho): 11520 bits (1440 * 8)
Tamanho da trama PROFIBUS (sem cabeçalho): 1952 bits (244 * 8)
Numero de ciclos por segundo: 10
IPH: Image Color Detection (*2).
Tráfego a transmitir: 8000 bps
Numero de pacotes IP: 8000 / 11520 = 0.7
Numero de tramas PROFIBUS: 8480 / 1952 = 4.3 ˜ 5
Tráfego a transmitir: 8480 + 16 * 5 = 8560
Numero de tramas PROFIBUS: 8560 / 1952 = 4.4 ˜ 5
Tramas por ciclo: 5 * 10 = 0.5
IPH: Remote Image Stream (*2).
Tráfego a transmitir: 24000 bps
Numero de tramas IP: 24000 / 11520 = 2.1
Tráfego IP a transmitir: 24000 + 180 = 24180
Numero de tramas PROFIBUS: 24180 / 1952 = 12.4 ˜ 13
Tráfego a transmitir: 24180 + 16 * 13 = 24388
Numero de tramas PROFIBUS: 24388 / 1952 = 12.5 ˜ 13
Tramas por ciclo: 13 * 10 = 1.3
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
30
IPH: Voice Connection.
Tráfego a transmitir: 16000 bps
Numero de tramas IP: 16000 / 11520 = 1.4
Tráfego IP a transmitir: 16000 + 120 = 16120
Número de tramas PROFIBUS: 16120 / 1952 = 8.3 ˜ 9
Tráfego a transmitir: 16120 + 16 * 9 = 16264
Numero de tramas PROFIBUS: 16264 / 1952 = 8.3 ˜ 9
Tramas por ciclo: 9 * 10 = 0.9
IPH: Remote
Tráfego a transmitir: 4237 bps
Numero de tramas IP: 4237 / 11520 = 0.37
Tráfego IP a transmitir: 4237 + 60 = 4297
Número de tramas PROFIBUS: 4297 / 1952 = 2.2 ˜ 3
Tráfego a transmitir: 4297 + 16 * 3 = 4345
Numero de tramas PROFIBUS: 4345 / 1952 = 2.2 ˜ 3
Tramas por ciclo: 3 * 10 = 0.3
Tráfego Tramas por ciclo Tramas por Segundo
IPH: Image Color Detection (x2) IPH1 0.5 5 IPH: Remote Image Stream (x2) IPH2 1.3 13 IPH: Voice Connection IPH3 0.9 9 IPH: Remote IPH4 0.3 3
Tabela 6-2: Resumo das tramas a transmitir por ciclo.
Calculo do valor do TIPH, a partir da tabela.
(1 + 4 + 1 + 1) * 1.5ms = 10.5ms
Tabela de escalonamento
1 2 3 4 5 6 7 8 9 10 IPH1 1 0 1 0 1 0 1 0 1 0 IPH1 0 1 0 1 0 1 0 1 0 1 IPH2 2 1 2 1 2 1 1 1 1 1 IPH2 1 2 1 2 1 2 1 1 1 1 IPH3 1 1 1 1 1 1 1 1 1 0 IPH4 1 0 0 1 0 0 1 0 0 0
Tabela 6-3: Tabela de escalonamento.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
31
A cada passagem do token dá-se o nome de um micro ciclo, cada coluna da tabela
representa um micro ciclo, a totalidade das 10 colunas representa o macro ciclo, que vai
ser repetido, após cada 10 micro ciclos. Com este escalonamento podemos constatar que
pode haver a redução de tempo em uma mensagem, passando o tempo a ser de 9ms.
Neste altura e somando todos os valores, encontra-se atribuído 27ms, o que sobra uma
larga fatia para o tráfego BE (Best Effort), 73ms.
Este tempo pode ser redistribuído, de forma a garantir que os outros tipos de tráfego
possam efectuar o envio das suas mensagens com alguma margem de segurança, assim
fica:
• TDPH = 16.5ms (11 mensagens)
• TDPL = 6ms (4 mensagens)
• TIPH = 12ms (8 mensagens)
• TBE = 65.5ms (43 mensagens)
A partir destes valores podemos constatar que o tráfego BE é servido com uma largura
de banda elevada, levando a que as aplicações que usam este tipo de tráfego tenham um
bom desempenho. Por outro lado mostra que a margem para adicionar slaves e/ou novos
serviços com QoS é grande.
Gestão da mobilidade Tal como já foi descrito no capítulo 4, o RFieldbus está dotado de suporte wireless. O
wireless permite a mobilidade das estações. Esta mobilidade traduz-se, em termos de
topologia de rede, na possibilidade de as estações trocarem de domínio de célula. Para
que esta mobilidade seja possível há necessidade de efectuar a sua gestão, para tal existe
o mecanismo de handoff. Este mecanismo permite que as estações “escutem” e
seleccionem o melhor canal nesse momento. Todo este processo deve ser
parameterizado para que funcione.
A tabela que se segue mostra uma listagem desses parâmetros.
Parâmetro Descrição Valor CBeacon Duração do beacon 93µs tbgap Intervalo entre 2 beacons 25µs tsw Tempo de mudança de canal 100µs Lbt Tamanho do beacon 10 chars nch Número de canais 3
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
32
tbd Atraso de armazenamento (buffer delay) 25µs Cbtwl Duração do beacon no domínio wireless 117µs Cbtwr Duração do beacon no domínio wired 44µs
Tabela 6-4: Parâmetros referentes à gestão da mobi lidade.
Estes parâmetros vão ser usados no cálculo do tempo de handoff, número de beacons
que cada estação vai emitir.
Figura 6-2: Topologia da rede wireless.
Ø Tempo de handoff
Tho = (2 * nch -1) * Cbeacon + nch * (tbgap + tsw)
= (2 * 3 – 1) * 93 + 3 * (25 + 100)
= 840µs
Ø Tempo de beacon trigger
)(2
∑=
+=n
ibtidb cttbt
Tbt = 25 + 44 + 25 + 117 + 25 + 44 + 25 + 117 = 422µs
Ø Período de gestão da mobilidade
Tmob = tho + tbt
= 840 + 422 = 1262µs
Com estes valores podemos efectuar o cálculo para cada LBS.
LBS1:
Tbt(LBS1) = 25 + 44 + 25 + 117 = 211µs
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
33
Tbp(LBS1) = 1262 – 211 = 1051µs
beaconsLBSN b 92593
1051)1( =
+=
LBS2:
Tbt(LBS2) = 25 + 44 + 25 + 117 = 211µs
Tbp(LBS2) = 1262 – 211 = 1051µs
beaconsLBSN b 92593
1051)2( =
+=
LBS3:
Tbt(LBS3) = 25 + 44 + 25 + 117 + 25 + 117 = 353µs
Tbp(LBS3) = 1262 – 353 = 909µs
beaconsLBSN b 82593
909)3( =
+=
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
34
7 Conclusão
Atendendo às movimentações do mercado e das tecnologias surgiu este projecto que
visa implementar um protocolo que conjugue as tecno logias wired e wireless, bem
como o tráfego multimédia.
Neste contexto surgiu o RFieldbus que agrupa todas estas características de uma forma
transparente.
Este relatório teve como objectivo estudar a configuração de um sistema industrial em
que se utilizasse este protocolo. Após este estudo pode-se concluir que o protocolo
responde às expectativas que inicialmente se colocaram, bem como aos objectivos que
estiveram na base da sua criação.
Tratando-se de um protocolo recente, padece dos problemas inerentes a esta área,
precisa de maturação e consequentemente da correcção de alguns aspectos.
Quanto ao seu futuro adivinha-se promissor, atendendo às suas características de incluir
tecnologias como o wireless e a suporte à multimédia, muito em uso. Por outro lado
pode ser ainda objecto de investigação e melhoramentos.
Arquitecturas de Comunicação sem Fios e com Suporte a Tecnologias Multimédia
35
8 Referencias
[1] High Performance Wireless Fieldbus in Industrial Multimedia-Related Environment
(IST-1999-11316) www.rfieldbus.de.
[2] Pasadas, Maria de Fátima Charneca, “Protocolos de Comunicação em Redes Locais
para Ambientes Industriais: Tráfego aperiódico em redes de terreno”, dissertação para
obtenção do Grau de Mestre em Engenharia Mecânica – Perfil de Sistemas, Dezembro
de 1996, documento provisório.
[3] Pereira, Nuno Alexandre Magalhães, “Estudo de device drivers para Windows
NT/2000® com requisitos de Tempo Real” dissertação para obtenção do grau de
licenciatura.
[4] Http://www.geocities.com/SiliconValley/Vista/8672/network.
[5] Ferreira, Luís L.; Machado, Sandra; Tovar, Eduardo; ”Scheduling IP Traffic in
Multimedia-Enabled PROFIBUS Networks”.
[6] Marques, Luís Miguel. “Planeamento de Aplicações Distribuídas de Tempo Real
Suportadas por Redes PROFIBUS com Extensões Wireless” dissertação para obtenção
do grau de licenciatura.
[7] Alves, Mário Jorge de Andrade Ferreira. “Real-Time Communications over Hybrid
Wired/Wireless PROFIBUS-Based Networks”, dissertação para obtenção do grau de
doutor, Fevereiro de 2003.
[8] RFIELDBUS Deliverable D5.2, “Report on field trials”, Technical Report, Mar.
2003.