planeamento de aplicações distribuídas de tempo real...
TRANSCRIPT
INSTITUTO SUPERIOR DE ENGENHARIA DO PORTODepartamento de Engenharia Informática
5º ANO
Disciplina de Projecto
PPllaanneeaammeennttoo ddeeAApplliiccaaççõõeess DDiisstt rr iibbuuííddaass
ddee TTeemmppoo RReeaall SSuuppoorr tt aaddaassppoorr RReeddeess PPRROOFFIIBBUUSS ccoomm
EExxtteennssõõeess WWiirreelleessss
Projecto realizado sob a orientação doEng. Eduardo Tovar
Luis Miguel Marques
Setembro de 2002
i
Índice
1. Introdução ............................................................................................................1
2. Objectivos do Projecto RFieldbus ......................................................................3
3. O PROFIBUS como Plataforma Básica de Comunicação ...............................5
3.1. Características Básicas do PROFIBUS.........................................................5
3.2. Compatibilidade com os Requisitos do RFieldbus ........................................6
4. O Sistema RFieldbus – Aspectos da Arquitectura............................................8
5. Mecanismo de Gestão da Mobilidade ..............................................................11
5.1. O Mobility Master e o Beacon Trigger........................................................11
5.2. Cálculo da Duração do Período de Gestão da Mobilidade ........................13
5.3. Cálculo do Número de Beacons a Transmitir por cada Estação ................16
5.4. Localização do Mobility Master ..................................................................18
5.5. Funcionalidades Restritas do Mobility Master............................................19
6. Exemplo de Aplicação........................................................................................20
6.1. Parâmetros das Camadas Físicas Wired e Wireless ...................................20
6.2. Parâmetros Relacionados com a Gestão da Mobilidade ............................22
6.3. Cálculo da Duração da Gestão da Mobilidade...........................................23
6.4. Cálculo do Número de Beacons a Enviar por cada Estação Base..............24
7. Ferramenta de System Planning Desenvolvida ...............................................26
7.1. Funcionalidades...........................................................................................26
7.2. Ilustrações Breves sobre a Ferramenta Desenvolvida ................................27
7.3. Considerações Finais...................................................................................28
8. Conclusões e Trabalho Futuro..........................................................................29
9. Referências / Bibliografia..................................................................................30
ii
Índice de FigurasFigura 1: Exemplo de uma rede RFieldbus 10
Figura 2: A estação móvel S1 movendo-se de CH1 para CH2 (exemplo de
mobilidade inter célula) 11
Figura 3: Diagrama exemplo do procedimento de gestão da mobilidade 12
Figura 4: Exemplo de um cenário possível 13
Figura 5: Diagrama temporal da gestão da mobilidade para o exemplo da topologia
apresentada na Figura 4 14
Figura 6: Pior caso na avaliação do sinal de um canal 14
Figura 7: Diagrama temporal da gestão da mobilidade 16
Figura 8: Exemplo de um cenário a evitar 18
Figura 9: Cenário corrigido (optimizado) 18
Figura 10: Visão global da ferramenta de system planning 27
Figura 11: Diálogo de configuração de parâmetros 27
Figura 12: Diálogo de resultados da gestão da mobilidade 28
Índice de TabelasTabela 1: Parâmetros para o tamanho e duração do PDU 21
Tabela 2: Valores de alguns parâmetros no RFieldbus 21
Tabela 3: Tamanho e duração da trama 22
Tabela 4: Parâmetros relacionados com a gestão da mobilidade 22
1
1. Introdução
Hoje em dia, um crescente número de sistemas de automação industrial requer o uso de
dispositivos móveis. Aplicações como transporte e armazenamento automático, controle
de processo e fabrico discreto, beneficiam com a utilização de veículos autónomos
guiados e outro equipamento informático móvel. A utilização eficiente destes
equipamentos móveis requer o uso de comunicações wireless (sem fio). Além disso, os
sistemas de comunicação wireless providenciam uma redução significativa nos custos de
cablagem e manutenção, facilitam a instalação de equipamento em ambientes sujeitos a
muita interferência electromagnética, aumentam a flexibilidade e permitem ainda uma
fácil evolução do sistema. Contudo, existem várias restrições ao uso de tecnologias wireless
em ambientes industriais, tais como a baixa performance, o baixo nível de confiança no
funcionamento (dependability) e a inexistência de um protocolo de controlo de acesso ao
meio (MAC) wireless apropriado para assegurar o comportamento de tempo real da rede.
O ISEP, através do grupo de investigação IPP-HURRAY
(http://www.hurray.isep.ipp.pt/) tem vindo desde Janeiro de 2000 a participar
activamente no projecto Europeu RFieldbus (IST-1999-11316 [3]). O projecto RFieldbus
tem como principal objectivo o de dotar redes de comunicação industrial tradicionais
(wired) com extensões wireless. Adicionalmente o referido projecto Europeu visa a
integração dos mecanismos necessários ao suporte de tráfego com características
multimédia (e.g. imagens, vídeo e som), sem contudo penalizar as características de
tempo real do tráfego de controle nativo das referidas redes de comunicação industrial.
Este relatório aborda questões relacionadas com o suporte às extensões wireless de redes
de comunicação industrial do tipo PROFIBUS [4], nomeadamente no que diz respeito à
parametrização da rede e particularmente de ferramentas informáticas adequadas a esse
processo de engenharia.
O relatório está estruturado da seguinte forma. No Capítulo 2 é feita uma breve
descrição do sistema RFieldbus, nomeadamente dos seus objectivos e dos requisitos que
ele deve suprir.
2
No Capítulo 3 é feita uma ligeira abordagem à plataforma de comunicações industriais
PROFIBUS, que é a plataforma escolhida para integrar o sistema RFieldbus. São
descritas algumas das suas características e como satisfaz alguns dos requisitos
pretendidos para o sistema RFieldbus.
No Capítulo 4 são apresentados alguns detalhes funcionais do sistema RFieldbus. Em
particular, são descritos os tipos de estações que podem coexistir no sistema e são feitas
algumas considerações referentes à mobilidade das estações (ou segmentos de rede)
wireless.
O Capítulo 5 descreve o mecanismo de gestão da mobilidade e as abordagens analíticas
que permitem calcular alguns parâmetros da rede fundamentais ao suporte dos
mecanismos de gestão de mobilidade, tais como a duração do período de gestão da
mobilidade (importante para o mobility master) e o número de beacons (tramas especiais do
Rfieldbus) a transmitir por cada base station (estação base), entre outros parâmetros.
No Capítulo 6 é feita a demonstração dos métodos apresentados no Capítulo 5,
recorrendo a um pequeno exemplo de topologia de rede. São calculados alguns
parâmetros auxiliares e são calculados os parâmetros da gestão da mobilidade para a rede
RFieldbus dada como exemplo.
No Capítulo 7 é sucintamente referida uma ferramenta computacional de system planning
(planeamento do sistema) desenvolvida pelo autor deste relatório para o RFieldbus, que
incorpora as ideias e abordagens descritas neste relatório. O objectivo dessa ferramenta é
o de permitir parametrizar qualquer tipo de rede RFieldbus, de uma forma simples,
rápida e fiável, dada a complexidade inerente à parametrização.
Finalmente no Capítulo 8 são tiradas algumas conclusões e tecidas considerações sobre o
trabalho futuro.
3
2. Objectivos do Projecto RFieldbusAs redes de comunicação industrial do tipo fieldbus são normalmente optimizados para
interligar dispositivos computacionais de automação industrial por intermédio de
tecnologia cablada (e.g. EN50170 [4]), isto é, tecnologia wired. A utilização deste tipo de
redes locais industriais conduz a importantes economias (em cabo) e aumento de
flexibilidade das instalações, por comparação com os sistemas “centralizados”. No
entanto, as actuais redes locais industriais (RLI) não são apropriados para a utilização de
sistemas computacionais móveis. Daí a necessidade de dotar as RLI de extensões wireless.
Para além disso, a utilização de comunicações wireless pode ser vantajosa na interligação a
dispositivos não móveis, devido à redução na cablagem (vantagem económica) e
aumento de flexibilidade de distribuição de informação. Assim, há potencialmente um
grande mercado para tecnologias wireless baseadas em rádio na automação industrial.
Existe um vasto conjunto de tecnologias de rádio já disponíveis para o uso em diferentes
domínios das telecomunicações. No entanto, elas não são projectadas (ou adequadas)
para aplicações industriais, e nenhuma tentativa foi, até agora, bem sucedida no sentido
de as integrar apropriadamente em arquitecturas de comunicação industriais avançadas.
O projecto Europeu RFieldbus visa precisamente estender os sistemas existentes de
fieldbus para o suporte de tecnologias wireless baseadas em rádio, e simultaneamente
acrescentar mecanismos de suporte a aplicações multimédia. Estas novas funcionalidades
terão de satisfazer os seguintes requisitos:
- comportamento de tempo real;
- confiabilidade;
- segurança;
- flexibilidade e interoperabilidade;
- suporte de aplicações multimédia normalizadas.
Para mais detalhes sobre estes requisitos, o leitor deverá consultar [3].
4
Para que os objectivos do projecto RFieldbus pudessem ser cumpridos, chegou-se à
conclusão de que a rede de fieldbus base (originalmente wired) deveria satisfazer os
seguintes requisitos:
- topologia de rede com mais do que um segmento físico;
- topologia de rede que permita mais do que uma Link Base Station (dispositivo
que estabelece a ligação entre um segmento de rede wired e um dispositivo
wireless) num segmento físico;
- comunicações transparentes entre estações (wired ou wireless) numa rede com
uma ou várias estações master;
- mobilidade para masters e slaves wireless (terminais de mão, PDAs, etc.) e
mobilidade também para segmentos físicos (ex: veículos móveis com vários
nós de rede);
- suporte a tráfego periódico com tempos de resposta limitados;
- suporte a tráfego esporádico com tempos de resposta limitados;
- suporte a tráfego multimédia com largura de banda variável (através do
encapsulamento de tráfego TCP/IP na rede fieldbus escolhida);
- suporte a diferentes classes de tráfego;
- facilidade em controlar a inserção e remoção de nós de rede;
- integração de mecanismos de detecção e recuperação de erros na transmissão
de mensagens.
A rede escolhida foi o PROFIBUS [4], por ser a que melhor satisfazia este conjunto de
requisitos para o sistema RFieldbus. No seguinte capítulo (Capítulo 3) podemos ver de
que forma o PROFIBUS preenche estes requisitos.
5
3. O PROFIBUS como Plataforma Básicade Comunicação
3.1. Características Básicas do PROFIBUS
PROFIBUS é uma rede de fieldbus normalizada para aplicações industriais. Permite a
interoperabilidade entre dispositivos de diferentes fabricantes, sem a necessidade de
ajustes significativos de interface.
O PROFIBUS distingue entre dois tipos de dispositivos – masters e slaves (mestres e
escravos) - e suporta sistemas com apenas um (sistema mono-master) ou com vários
masters (sistema multi-master). O mecanismo de acesso ao meio é baseado num protocolo
simplificado de passagem de token (testemunho) temporizado, que é uma solução já
comprovada para sistemas de comunicação em tempo real (por ex., FFDI, IEEE 802.H
Token Bus).
Uma estação master pode efectuar transacções durante o tempo em que possui o token.
Uma transação consiste do pedido de uma estação master a uma estação master ou slave, e a
respectiva resposta, que é “imediatamente” emitida pela estação que recebeu o pedido. A
estação master que detém o token, apenas processa uma nova transacção ou passa o token
depois de completar a transacção em curso, e de ter esperado um tempo predefinido. Se
uma resposta errónea é recebida, ou ocorre um timeout (esgota o tempo máximo que pode
esperar pela resposta), a estação pode repetir o pedido. A estação master pode também
enviar um pedido de cancelamento. Neste caso não existe uma resposta associada e a
estação master pode iniciar uma nova transacção ou passar o token depois de esperado o
tempo de inactividade predefinido (idle time). Os tempos de inactividade entre as
transacções são necessários devido aos requisitos da camada física, nomeadamente para
sincronização.
6
O token, que representa o direito de aceder ao meio, circula num anel lógico composto
por todos os masters na rede.
O PROFIBUS permite distinguir entre mensagens de alta e baixa prioridade. As
mensagens de baixa prioridade podem ainda ser divididas em três sub-tipos:
- transacções periódicas de baixa prioridade, que representam a execução dos
pedidos contidos numa lista de transacções periódicas;
- transacções esporádicas, que compreendem pedidos de aplicações e serviços
de gestão remota;
- transacções de manutenção, que permitem determinar o estado das outras
estações de modo a suportar mudanças dinâmicas na rede (por exemplo, a
reconfiguração do anel lógico).
3.2. Compatibilidade com os Requisitos do RFieldbus
O PROFIBUS é a norma de fieldbus mais usada em automação industrial, com uma
grande diversidade de dispositivos compatíveis, além de já contar com mais de 10 anos
de desenvolvimento. Por isso, o PROFIBUS é uma norma madura e estável. Para além
disso, apresenta a maior velocidade de transmissão disponível num sistema fieldbus (12
Mbit/s), o que o torna a plataforma adequada para suportar aplicações multimédia
(usualmente exigentes em termos de largura de banda). De todos os sistemas fieldbus, o
PROFIBUS também é um dos que permite uma maior transferência de informação na
camada de ligação de dados (246 bytes), o que diminui a necessidade de fragmentação de
pacotes (no caso do suporte IP), levando a uma maior eficiência da rede. Outra
característica importante é o suporte para mensagens de alta e baixa prioridade, o que
permite a coexistência de tráfego de tempo real com tráfego sem requisitos de tempo
real. Como o mecanismo de acesso ao meio é baseado num protocolo de passagem de
token temporizado, o tempo de rotação do token pode ser controlado, permitindo às
transacções um comportamento temporal bem definido. Assim o PROFIBUS pode
suportar tráfego de tempo real com tempos de resposta pré determinados.
7
O PROFIBUS possui ainda mecanismos de manutenção apropriados à resolução dos
problemas gerados pela existência de estações móveis, que devido à sua natureza podem
mudar de célula de rádio, sair da rede, etc. O caso mais importante é quando uma estação
master móvel deixa a rede. Como fazia parte do anel lógico de passagem do token, este
anel necessita de ser reestruturado, o que o PROFIBUS faz automaticamente,
transparentemente, e sem perder informação. Por último, mas não menos importante, o
mecanismo de detecção e correcção de erros da camada de ligação de dados do
PROFIBUS é apropriado para assegurar um nível de confiabilidade aceitável da
informação transmitida.
8
4. O Sistema RFieldbus – Aspectos daArquitectura
As soluções para dispositivos de interligação baseados no uso de tecnologias de rede
wireless como o Bluetooth[5] ou o IEEE802.11b[6] não podem ser consideradas
simplesmente substituindo as duas camadas inferiores da pilha de comunicações do
PROFIBUS. De facto, de maneira a obter uma rede do tipo broadcast (exigência do
PROFIBUS), os dispositivos de ligação (que interligam componentes wired e wireless)
devem funcionar como repetidores. Logo, estes dispositivos têm que suportar
funcionalidades como encapsulamento, devido aos diferentes formatos dos PhL PDU
(Physical Layer Protocol Data Unit – unidade de dados do protocolo na camada física) nos
meios wired e wireless, e receber/transmitir a diferentes velocidades. É necessário ainda
garantir que uma estação móvel opere transparentemente (como se fosse uma estação
estacionária) e que nenhuma mensagem é perdida.
As estações podem ser dos tipos listados a seguir.
Master (mestre) – estação que está responsável por uma ou mais tarefas.
Slave (escravo) – estação subordinada a estações master para ajuda na realização de
tarefas (por vezes são simples sensores).
Mobile master (mestre móvel) – estação portátil que está responsável por uma ou
mais tarefas.
Mobile slave (escravo móvel) – estação portátil subordinada a estações master para
ajuda na realização de tarefas (por vezes são simples sensores).
TCP/IP master (mestre TCP/IP) – estação igual ao master, mas com necessidade
de enviar e/ou receber tráfego TCP/IP.
9
TCP/IP slave (escravo TCP/IP) – estação igual ao slave, mas com necessidade de
enviar e/ou receber tráfego TCP/IP.
TCP/IP mobile master (mestre móvel TCP/IP) – estação igual ao mobile master,
mas com necessidade de enviar e/ou receber tráfego TCP/IP.
TCP/IP mobile slave (escravo móvel TCP/IP) – estação igual ao mobile slave, mas
com necessidade de enviar e/ou receber tráfego TCP/IP.
TCP/IP master gateway (mestre gateway TCP/IP ) – estação que permite a ligação
da rede PROFIBUS a uma rede TCP/IP.
Base station (estação base) - dispositivo que cria uma célula rádio, permitindo
transmissões wireless aos dispositivos móveis que se encontrarem dentro do
alcance dessa célula. Possui canais diferentes para transmissão e recepção.
Link station (estação de ligação) – dispositivo que estabelece a ligação entre um
domínio wired e um domínio wireless.
Link base station (estação de base de ligação) - dispositivo que é uma junção das
características das base stations e das link stations. A vantagem é a redução do
número de estações necessárias. A desvantagem é que como está ligada por fio,
não é muito fácil a sua colocação em alguns sítios, nomeadamente nos tectos das
plantas fabris.
Mobility master (mestre da mobilidade) – estação responsável pelo procedimento
de gestão da mobilidade.
De salientar que os dispositivos de interligação (base stations, link stations e link base stations)
comportam-se como repetidores store-and-forward, ou seja, armazenam completamente a
trama antes de a enviar.
10
Na Figura 1 podemos ver um exemplo de rede RFieldbus, incluindo diversos tipos de
estações.
Figura 1: Exemplo de uma rede RFieldbus
Os conectores denominados “wireless” e “TCP/IP” representam ligações wireless e
TCP/IP entre as estações. A ligação TCP/IP é usada (por exemplo) para a transmissão
da imagem de uma câmara que se encontra na estação TCP/IP slave ( ) para a estação
TCP/IP master ( ), quando essa imagem é pedida. As estações móveis têm uma ligação
wireless para a estação base que estão a usar no momento, podendo ir mudando de
estação base (mobilidade inter célula) ao longo do tempo.
Mas para que essa mobilidade inter célula seja possível, é necessário que periodicamente
seja accionado um mecanismo que faça a gestão da mobilidade, efectuando uma
reestruturação da rede de forma a reflectir as trocas de estação base por parte das
estações móveis. No próximo capítulo (Capítulo 5) iremos ver mais em detalhe como
funciona o mecanismo de gestão da mobilidade.
11
5. Mecanismo de Gestão da Mobilidade
5.1. O Mobility Master e o Beacon Trigger
Uma estação específica – o mobility master ( ) – é responsável por activar o procedimento
de gestão da mobilidade. Este procedimento é activado através do envio de uma trama
especial – o beacon trigger – com uma periodicidade que depende da velocidade máxima
permitida às estações móveis (quanto maior a velocidade das estações móveis maior terá
de ser a frequência do procedimento de gestão da mobilidade).
Figura 2: A estação móvel S1 movendo-se de CH1 para CH2 (exemplo demobilidade inter célula)
Como a rede é do tipo broadcast, o beacon trigger vai chegar a todas as estações na rede e
assim estas ficam a saber que teve inicio o procedimento de gestão da mobilidade.
Durante um determinado período de tempo (beacon period), as estações base enviam um
certo número de beacons no seu canal de rádio, e as estações móveis escutam esses beacons
e usam-nos para avaliar a qualidade do sinal de todos os canais rádio.
Depois de concluída a avaliação da qualidade do sinal dos canais rádio, cada estação
móvel passa a usar o canal que no seu caso obteve melhor resultado.
12
Concluído o procedimento de gestão da mobilidade, o mobility master pode passar o token
para a estação master seguinte.
Tomando em consideração o cenário apresentado na Figura 2, onde a estação móvel S1
se move para a zona de alcance da LBS2 (canal CH2), podemos observar a evolução da
gestão da mobilidade (Figura 3) supondo que a avaliação dos canais de rádio por parte da
estação móvel 1 resultaria em 50% para Ch1, 90% para Ch2 e 10% para Ch3.
Figura 3: Diagrama exemplo do procedimento de gestão da mobilidade
Obviamente, as estações móveis têm de avaliar todos os canais rádio existentes na rede,
podendo acontecer que não seja captado qualquer sinal de um ou mais canais devido a se
estar fora do alcance da estação emissora. Quando isto acontece, estes canais terão 0% de
qualidade e nunca serão seleccionados.
BT
1
BT Ch1 Ch1 Ch1
2
BT Ch1 Ch1 Ch1
3
BT Ch2 Ch2 Ch2
1
BT Ch1 Ch2 Ch3
50% 90% 10%
Tok
Ch1
Ch2
Ch3
Ch2
Procedimento de gestão da mobilidade
Período de Beacons
13
5.2. Cálculo da Duração do Período de Gestão da Mobilidade
É fundamental calcular a duração máxima do procedimento de gestão da mobilidade, de
modo a que o mobility master possa aguardar um tempo de inactividade apropriado antes
de passar o token (parâmetro correspondente ao inserted idle time). De facto, como o beacon
trigger é uma trama que não necessita de confirmação (unacknowledge), o comportamento
normal seria passar o token depois de aguardar um tempo fixo. Em vez disso, o mobility
master tem de manter o token até que o processo 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) esteja concluído. De facto, o mobility master deve garantir que a última estação
móvel a receber o beacon trigger tem ainda tempo suficiente para efectuar o processo de
handoff.
Para clarificar isto, um cenário considerando três células e três diferentes canais de rádio
vai ser usado:
Figura 4: Exemplo de um cenário possível
Neste exemplo a transmissão do beacon trigger do mobility master para uma estação no
domínio WL3 teria que passar três dispositivos de interligação (LBS2, LS e LBS3),
enquanto que para os domínios WL1 e WL2 só teria de passar um dispositivo (LBS1 e
LBS2, respectivamente). Logo, a duração máxima do procedimento de gestão da
mobilidade pode ser determinado considerando uma estação wireless ( ) no domínio
WL3, pois este é o pior caso.
A Figura 5 apresenta o diagrama temporal do procedimento de gestão da mobilidade
para o cenário descrito na Figura 4.
14
Figura 5: Diagrama temporal da gestão da mobilidade para o exemplo da topologia apresentada na Figura 4
A estação móvel inicia o procedimento de handoff imediatamente depois de receber o
beacon trigger, iniciando a avaliação da qualidade do sinal no canal rádio actual (CH3 neste
exemplo). Depois a estação muda para outro canal (CH2) e faz a mesma avaliação, muda
para o outro canal (CH1) e avalia também a qualidade do sinal, e finalmente muda para o
melhor canal. Na avaliação de CH2 e CH1, o pior caso deve ser considerado, que é
quando a estação móvel começa a avaliar o canal imediatamente após o inicio de um
beacon, uma vez terá que esperar pelo beacon seguinte para poder ter um beacon completo
(Figura 6). Isto implica um período de avaliação máximo para esses canais de
2 * Cbeacon + tbgap, onde Cbeacon é a duração do beacon e tbgap é o intervalo entre beacons (estas
variáveis estão descritas na Figura 5).
Figura 6: Pior caso na avaliação do sinal de um canal
WR2
WL3
Estação em WL3 (neste caso)
WL2
WL1
WR1
Estação em WL3 (pior caso)
tmob
tsw tsw
tsw tsw tsw
tbt tho
CbtWL Cbeacon tbgap
15
Para garantir o processamento correcto por uma estação móvel no caso de falhar um
beacon, um temporizador irá monitorizar este tempo. Considerando que o número de
canais rádio a avaliar é representado por m e o tempo de mudança de canal é definido por
tsw, a duração máxima do processo de handoff na estação móvel é:
( 1).(2. )
(2. 1). .( )
ho bgap beacon sw beacon bgap sw
ho beacon bgap sw
t t C t m C t t
t m C m t t
= + + + − + + ⇔⇔ = − + +
(1)
No caso da Figura 5 em que o número de canais é 3 (m = 3), o tempo de handoff é:
5. 3. 3.ho beacon bgap swt C t t= + + (2)
Mas, a duração do procedimento de handoff é apenas um dos dois componentes do
período de gestão da mobilidade. Também é necessário determinar o tempo necessário
para o beacon trigger chegar à estação móvel mais longínqua, tempo esse que é definido por
tbt. Este tempo pode então ser calculado como:
2
( )n
bt bd bti
i
t t C=
= +∑(3)
Onde i representa os domínios desde o domínio do mobility master até ao domínio mais
longínquo do mobility master e Cbti é a duração do beacon trigger no domínio i. Também é
necessário considerar que um dispositivo de interligação possui um atraso desde o
momento em que recebe o último bit da trama até que é capaz de enviar o primeiro bit
da trama, atraso esse representado por tbd (buffering delay - atraso de armazenamento).
No caso expresso pelas figuras anteriores, a LBS3 vai ser a última estação a receber o
beacon trigger. Então, a soma resulta em:
3. 2.
bt bd btWL bd btWR bd btWL
bd btWL btWR
t t C t C t C
t C C
= + + + + += + +
(4)
16
5.3. Cálculo do Número de Beacons a Transmitir por cadaEstação
Para que o procedimento de gestão da mobilidade funcione correctamente, é necessário
que as estações base saibam o número exacto de beacons que é necessário transmitir após
a recepção do beacon trigger. Obviamente, este número de beacons pode variar de estação
base para estação base, pois as estações base podem receber o beacon trigger em diferentes
instantes (devido a atrasos de propagação). Além disso, considerando que a transmissão
de um beacon não é preemptiva (ou seja, assim que uma estação começa a transmitir um
beacon, ela tem de completar a transmissão até ao fim sem poder interromper essa
transmissão), vai haver a necessidade de ajustar o tempo do período de gestão da
mobilidade em função desse efeito. Assim, é necessário computar o número de beacons
para cada estação base na rede, e então fazer o ajuste necessário na duração do
procedimento de gestão da mobilidade. Considere a seguinte figura:
Figura 7: Diagrama temporal da gestão da mobilidade
A duração mínima do beacon period para a estação base correspondente é:
1 1( ) ( )bp mob btLBS LBSt t t= − (5)
O número de beacons ( bn ) que têm de ser enviados pela estação base é ( é usado para
denotar uma ceiling function):
11
( )( )
bpb
bgap beacon
LBSLBS
tn
t C = +
(6)
WL1
WR1
tmob
t’mob
tbt tbp
t’bp
17
A duração do beacon period é então:
1 1' ( ) ( ).( )bp b bgap beaconLBS LBSt n t C= + (7)
o que implica um tempo de gestão da mobilidade mínimo de:
1 1 1' ( ) ( ) ' ( )mob bt bpLBS LBS LBSt t t= + (8)
Este procedimento deve ser usado para calcular t’mob em todas as estações base na rede, e
o maior t’mob deve ser considerado. Então no mobility master, ao parâmetro TID (bits de
inactividade) deve ser atribuído o valor mínimo de:
' .ID mob WRT t r= bits (9)
Por exemplo, se t’mob = 500µs e a velocidade da rede for rWR = 1 Mbit/s, então
500IDT = bits
18
5.4. Localização do Mobility Master
Como a duração da gestão da mobilidade depende da localização do mobility master, o
desenho do sistema deve garantir que este tempo seja o menor possível. Como regra
geral, a funcionalidade de mobility master deve ser da responsabilidade de um master
localizado num domínio wired central, ou seja, num domínio que é equidistante para os
domínios wireless mais distantes. Assim, a situação descrita na figura seguinte é um cenário
a evitar.
Figura 8: Exemplo de um cenário a evitar
Em alternativa deveria ser considerado um cenário em que o master no domínio wired
central desempenhasse as funções de mobility master. O cenário resultante seria:
Figura 9: Cenário corrigido (optimizado)
De salientar que a correcta localização do mobility master pode ser a diferença entre o
sucesso e o insucesso do sistema, pois um maior tempo gasto em handoff resulta num
menor tempo para tráfego de controlo e de multimédia.
Mobility master
Mobility master
19
5.5. Funcionalidades Restritas do Mobility Master
No RFieldbus, o mobility master vai ser exclusivamente dedicado à gestão da mobilidade.
Isto é devido a uma limitação no valor máximo do parâmetro de tempo de inactividade
(TID2) nas implementações PROFIBUS. Isto significa que quando o token é recebido, o
mobility master executa o procedimento de gestão da mobilidade (se já tiver expirado o
temporizador), e então passa o token para outra estação. A vantagem é a de não haver
transacção de mensagens (apenas recepção do token) antes de enviar o beacon trigger, o que
implica que este não vai sofrer atrasos por aguardar nas filas de espera dos dispositivos
de interligação. Isto simplifica bastante o cálculo da duração do procedimento de gestão
da mobilidade.
20
6. Exemplo de Aplicação
6.1. Parâmetros das Camadas Físicas Wired e Wireless
Um caracter (char) é definido como a menor unidade de informação na camada de ligação
de dados. Um PhL PDU é um conjunto de caracteres enviados para a camada física para
transmissão.
De modo a proceder a uma transmissão, a camada física pode ter que acrecentar
informação adicional (cabeçalho) ou bits de sincronização (preambulo, delimitador de
início de trama) ao DLL PDU (Data Link Layer PDU - PDU na camada de ligação de
dados). Além disso, um caracter tem tamanhos diferentes em cada tipo de camada física:
na wired cada caracter tem 11 bits (caracteres UART), 8 normais e 3 extra, e na wireless
cada caracter tem apenas os 8 bits normais.
Nos domínios wired vai ser usada a versão assíncrona (RS485) do PROFIBUS, e é
esperado que a velocidade da rede seja de 1,5 Mbit/s. Cada PhL PDU consiste de um
número de caracteres que são compostos de 11 bits cada (8+3). A camada física wired não
adiciona qualquer overhead (cabeçalho extra). Quando queremos enviar um PhL PDU
wired para um domínio wireless, o dispositivo de interligação remove os 3 bits extra de
cada caracter e encapsula todo esse PDU na parte de dados do PhL PDU wireless,
adicionando um cabeçalho específico. Além disso, há a necessidade de inserir um
preâmbulo e um delimitador de inicio de trama (start frame delimiter - SFD) no PhL PDU
wireless, de modo a permitir a sua correcta recepção. Uma velocidade de 2 Mbit/s é
esperada para as comunicações wireless.
Os dispositivos de interligação interligam domínios que usam o mesmo protocolo de
camada de ligação de dados (data link layer - DLL), mas que têm diferentes camadas
físicas. Assim sendo, temos que definir alguns parâmetros para cada domínio.
21
Parâmetro Descrição Unidades
L Tamanho do PDU na DLL Chars
ka Tamanho de um caracter na
camada física do domínio a
Bits/char
la+ Overhead no domínio a
(header, preamble, SFD)
Bits
ra Largura de banda no
domínio a
Mbits/s
Tabela 1: Parâmetros para o tamanho e duração do PDU
Tendo em consideração os parâmetros delineados na Tabela 1, podemos definir Ca como
sendo a duração de um PDU no domínio a.
. a aa
a
L k lC
r
++=
(10)
Considerando que no RFieldbus temos um cabeçalho de 10 bytes seguido de um
preambulo de 53 µs e um delimitador de inicio de trama no PDU wireless (resultando num
overhead total de 186 bits com rede a 2 Mbits/s), usando a Tabela 1 obtemos:
Descrição Domínio wired Domínio wireless
Tamanho do caracter kwr = 11 bits/char kwl = 8 bits/char
Tamanho do overhead lwl+ = 0 bits lwl+ = 186 bits
Largura de banda rwl = 1,5 Mbit/s rwl = 2 Mbit/s
Tabela 2: Valores de alguns parâmetros no RFieldbus
Podemos então calcular a duração dos PDUs wired e wireless as seguintes fórmulas:
.11 22. ( s)
1,5 3 wr
LLC µ= =
(11)
.8 1864. 93 ( s)
2wl
LLC µ
++= =
(12)
22
A seguinte tabela (Tabela 3) apresenta a duração da PDU na camada física para alguns
tamanhos do PDU na camada de ligação de dados:
Tipo de PDU L (chars) Cwr (µs) Cwl (µs)
Sem dados (beacon) 0 0 93
Acknowledge 1 7,3 97
Token 3 22 105
Tamanho fixo sem dados 6 44 117
246 octetos de dados 255 1870 1113
Tabela 3: Tamanho e duração da trama
Da Tabela 3 podemos facilmente constatar que tramas pequenas têm uma maior duração
nos domínios wireless enquanto que as tramas maiores demoram mais tempo a ser
transmitidas nos domínios wired.
6.2. Parâmetros Relacionados com a Gestão da Mobilidade
No RFieldbus, é permitido apenas um máximo de 3 canais de rádio diferentes, e a
velocidade máxima dos nós móveis é de 6 m/s. Alguns valores adicionais relacionados
com a mobilidade estão representados na seguinte tabela:
Descrição Símbolo Valor
Tamanho do beacon Lbeacon 0 chars
Tempo de troca de canal tsw 100 µs
Número de bits entre
beacons
Tbgap 50 bits
Tempo de espera em buffer tbd 25 µs
Tabela 4: Parâmetros relacionados com a gestão da mobilidade
23
Considerando que a PDU beacon trigger é uma trama PROFIBUS do tipo “tamanho fixo
sem dados” (fixed length no data), e usando a Tabela 3, podemos definir a duração do PDU
beacon trigger nas camadas físicas dos domínios wired e wireless:
117btWL sC µ= (13)
44btWR sC µ= (14)
Tomando em consideração que o beacon só é relevante nos domínios wireless, e que não
precisa de incluir parte de dados (L=0), a sua duração é:
93beacon sC µ= (15)
Finalmente, tomando em consideração a velocidade de 2 Mbit/s nos domínios wireless e
que Tbgap = 50 bit, então o tempo entre beacons será de:
25bgap st µ= (16)
6.3. Cálculo da Duração da Gestão da Mobilidade
Considerando o cenário descrito nas Figuras 4 e 5, como m = 3 o processo de handoff
demora:
5. 3. 3. = 5 * 93 + 3 * 25 + 3 * 100 = 840 sho beacon bgap swt C t t µ= + +
O tempo do beacon trigger é:
3. 2. 3*25 2*117 44 353bt bd btWL btWRt t C C sµ= + + = + + =
Portanto a duração da gestão da mobilidade é no mínimo:
353 840 1193mob bt hot t t sµ= + = + =
24
6.4. Cálculo do Número de Beacons a Enviar por cadaEstação Base
O tempo do beacon trigger para a estação LBS1 é:
1 25 117 142( )bt bd btWLLBS st t C µ+ == + =
Por isso temos uma duração mínima do beacon period de:
1 1 1193 142 1051( ) ( )bp mob btLBS LBS st t t µ− == − =
O número de beacons (nb) que devem ser enviados pela estação base é:
1 10511 9
118
( )( )
bpb
bgap beacon
LBSLBS
tn
t C = = = +
Então a duração do beacon period é pelo menos:
1 1 9 * 118 1062' ( ) ( ).( )bp b bgap beaconLBS LBS st n t C µ== + =
O que implica uma duração da gestão da mobilidade no mínimo de:
1 1 1 142 1062 1204' ( ) ( ) ' ( )mob bt bpLBS LBS LBS st t t µ+ == + =
Para a estação base LBS2 os resultados são os mesmos que para LBS1, pois ambas
usufruem das mesmas características.
Para LBS3, já não é assim. Neste caso a duração mínima do beacon period é obviamente:
3 840( )bp LBS st µ=
25
O número de beacons (nb) que devem ser enviados por LBS3 é:
3 8403 8
118
( )( )
bpb
bgap beacon
LBSLBS
tn
t C = = = +
O que nos conduz a uma duração do beacon period de:
3 3 8*118 944' ( ) ( ).( )bp b bgap beaconLBS LBS st n t C µ== + =
O que implica uma duração da gestão da mobilidade no mínimo de:
3 3 3 353 944 1297' ( ) ( ) ' ( )mob bt bpLBS LBS LBS st t t µ+ == + =
E assim obtemos o valor real da duração do gestão da mobilidade, que é o máximo t’mob
de entre todas as estações:
1297mob st µ=
Assim, no mobility master, o tempo de inactividade (TID2) deve ser definido com o valor
mínimo de:
2 1297 *1,5 1946' .ID mob WET t r= = =
26
7. Ferramenta de System PlanningDesenvolvida
7.1. Funcionalidades
A ferramenta de system planning desenvolvida permite o projectar de uma rede RFieldbus
de uma forma simples, rápida e fiável. Simples, pela facilidade em usar, rápida pela
possibilidade de criar novos cenários a partir de outros já existentes e porque também
efectua os cálculos da gestão da mobilidade, e fiável porque também permite fazer a
validação da rede.
Com a ferramenta podemos guardar e ler de ficheiros os cenários que vamos
construindo, podendo ainda fazer alterações aos cenários guardados ou usá-los para criar
cenários novos de uma maneira fácil e rápida. Os cenários podem inclusive ser impressos
numa vulgar impressora, para que possam ser debatidos, demonstrados ou
implementados sem a necessidade de computador. A ferramenta permite também
configurar os parâmetros relativos às estações, além de podermos configurar os
parâmetros globais da rede, como poderemos ver mais à frente na Figura 11.
A ferramenta faz também a validação da rede. Isto consiste na detecção de loops (vários
caminhos possíveis para um mesmo destino - o que não é permitido pois o tráfego
gerado iria propagar-se indefinidamente por toda a rede até esgotar a capacidade da rede)
e na negação ao utilizador de efectuar operações inválidas (por ex., o utilizador não pode
definir mais do que um mobility master).
Para além disso, a ferramenta também calcula os parâmetros da gestão da mobilidade,
seguindo os passos descritos nos Capítulos 5 e 6, ou seja, calcula o número de beacons a
ser transmitido por cada estação e por fim calcula o tempo de inactividade necessário e a
respectiva tradução em bits de inactividade. Os resultados obtidos podem então ser
usados para configurar as respectivas estações.
27
7.2. Ilustrações Breves sobre a Ferramenta Desenvolvida
Na figura seguinte podemos ver como a ferramenta foi usada para desenhar o sistema
descrito na Figura 4.
Figura 10: Visão global da ferramenta de system planning
Na Figura 11 podemos ver alguns dos parâmetros que podemos configurar, e na Figura
12 podemos ver os resultados da gestão da mobilidade para este sistema e actualizar a
configuração das estações:
Figura 11: Diálogo de configuração de parâmetros
28
Figura 12: Diálogo de resultados da gestão da mobilidade
7.3. Considerações Finais
Os resultados obtidos pela ferramenta foram os já demonstrados no Capítulo 6 de forma
analítica. A grande diferença reside na celeridade e fiabilidade com que a ferramenta dá
os resultados e indica eventuais erros, o que a torna muito vantajosa no desenho da rede
pois esta é uma tarefa crucial no seu bom funcionamento.
As suas vantagens são particularmente evidentes para topologias mais complexas, onde a
parametrização “manual” seria extremamente morosa, complexa e mais sujeita a erros.
29
8. Conclusões e Trabalho FuturoO mecanismo de gestão da mobilidade permite as extensões wireless adequadas às redes
de comunicação industrial PROFIBUS, pois o determinismo do processo de gestão da
mobilidade permite continuar a satisfazer os requisitos de tempo real existentes.
A ferramenta de system planning desenvolvida permite as operações necessárias ao desenho
e validação de uma rede RFieldbus. A sua grande parametrização permite também ajustar
a aplicação a evoluções no RFieldbus (por ex., ao se chegar à conclusão de que a largura
de banda disponível é insuficiente para as aplicações multimédia e for aumentada a
largura de banda nos domínios wired e wireless, a ferramenta permite configurar os novos
valores).
Contudo, à medida que novas tecnologias ou novos requisitos forem surgindo, pode ser
necessária uma alteração mais profunda à ferramenta para suportar as novas
funcionalidades, sejam elas quais forem (por ex., se fosse necessário permitir a existência
de loops na rede, estando as ligações alternativas inactivas, passando uma delas a ser a
activa quando a anteriormente activa apresentasse problemas, seria necessário efectuar as
respectivas alterações na ferramenta). Por isso, o trabalho futuro será além de prováveis
afinações e melhoramentos visuais da ferramenta, o de estudar e desenvolver novos
métodos para auxílio à gestão das novas funcionalidades.
30
9. Referências / Bibliografia[1] Alves M., Tovar E., Vasques F., Hammer G., Röther K. (2002). Real-Time
Communications over Hybrid Wired/Wireless PROFIBUS-based Networks. Proc. of the
14th Euromicro Conference on Real-Time Systems - ECRTS'02, Vienna, Austria, pp.
142-150.
[2] Koulamas C., Lekkas A., Kalivas G., Koubias S., Roether K., Hammer G., Alves M.,
Ferreira L., Tovar E., Vasques F. (2001b). Mobility Management in RFieldbus. White
Paper of the RFieldbus Project. Version 1.0. January 2001.
[3] Alves M., Bangemann T., Batista B., Breithaupt R., Ferreira L., Haehniche J., Hammer
G., Heidel R., Kalivas G., Kalogeras A., Kapsalis V., Koubias S., Koulamas C.,
Kutschenreuter M., Monforte S., Pacheco F., Roether K., Speckmeier P., Tovar E.,
Vasques F. (2000d). General System Architecture of the RFieldbus. Deliverable D1.3.
RFieldbus project IST-1999-11316. July 2000.
[4] EN 50170 (1996). General Purpose Field Communication System. Volume 2 -
PROFIBUS, European Norm EN 50170.
[5] http://www.bluetooth.com/
[6] http://grouper.ieee.org/groups/802/11/main.html