Análise e Configuração de um Sistema Distribuído Baseado ...paf/proj/Set2003/RFieldBus.pdf · número de pessoas e meios, tendo por finalidade a criação de uma arquitectura

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


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


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.


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.


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.


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.


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.


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


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.


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


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).


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).


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.


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.


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.


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.


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


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.


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:


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


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.


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


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


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.


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.


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.


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


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


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


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


Tramas por ciclo: 5 * 10 = 0.5

IPH: Remote Image Stream (*2).


Numero de tramas IP: 24000 / 11520 = 2.1

Tráfego IP a transmitir: 24000 + 180 = 24180






30

IPH: Voice Connection.




Número de tramas PROFIBUS: 16120 / 1952 = 8.3 ˜ 9




IPH: Remote




Número de tramas PROFIBUS: 4297 / 1952 = 2.2 ˜ 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.


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


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


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( =

+=


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.


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.

Documents

Análise e Configuração de um Sistema Distribuído Baseado ...paf/proj/Set2003/RFieldBus.pdf · número de pessoas e meios, tendo por finalidade a criação de uma arquitectura