INSTITUTO SUPERIOR DE ENGENHARIA DO PORTOpaf/proj/Julho2003/Ethernet-IP.pdf · FCFS First Come...
-
Upload
nguyenkiet -
Category
Documents
-
view
214 -
download
0
Transcript of INSTITUTO SUPERIOR DE ENGENHARIA DO PORTOpaf/proj/Julho2003/Ethernet-IP.pdf · FCFS First Come...
INSTITUTO SUPERIOR DE ENGENHARIA DO PORTO
Departamento de Engenharia do Porto
5º Ano Disciplina:Projecto
Arquitectura de Comunicações Baseadas em Ethernet/IP
(Ethernet /Industrial Protocol)
Projecto realizado sob a orientação do
Eng.º Eduardo Tovar
Paulo Manuel Baltarejo de Sousa
Julho de 2003
II
Agradecimentos
Gostaria de agradecer às pessoas cujo o apoio foi determinante à realização deste relatório.
Agradeço a todos os professores que, ao longo do curso, ajudaram na aquisição do
conhecimento e das aptidões necessárias para o desenvolvimento deste relatório.
Em especial, ao meu orientador, Eng.º Eduardo Tovar pelo apoio dado através das suas
sugestões e também por permitir a realização deste relatório no âmbito do grupo de
investigação IPP-HURRAY.
Aos colaboradores do IPP-HURRAY que se mostraram sempre disponíveis, em particular Luís
Miguel Pinho e Nuno Pereira.
Aos meus amigos e colegas pelas sugestões dadas.
Finalmente agradeço a todos os meus familiares, em especial à minha mulher Elisa Cristina e à
minha filha Bárbara Rita, pela compreensão e carinho, se os quais não teria conseguido
realizar este relatório.
III
Acrónimos ATM Asynchronous Transfer Mode
Attribute ID Atribute Identifier
CID Connection ID
CIP Control Information Protocol
Class ID Class Identifier
CLNP ConnectionLess Network Protocol
COTS Commercial Of The-Self
CRC Cyclic Redundancy Check
CSMA/CD Carrier sense Multiple Access with Collision Detection
DHCP Dynamic Host Configuration Protocol
DM Deadline Monotonic
DNS Domain Name Server
DQDB Distributed Queue Dual Bus
EDF Earliest Deadline First
Ethernet/IP Ethernet/Industrial Protocol
FCFS First Come First Served
FDDI Fiber Distributed Data Interface
FTP File Transfer Protocol
HTTP HyperText Transfer Protocol
IEEE Institute of Electrical and Electronic Engineers
IETF Internet Engeneering Task Force
INDEPTH Industrial Ethernet Protocols Under Holistic Analysis
Instance ID Instance Identifier
IPP-HURRAY Intstituto Politécnico do Porto-HUgging Real-time and Reliable Architecture
IPv4 Intenet Protocol versão 4
IPv6 Intenet Protocol versão 6
IPX Internet Packet Exchange
ISDN Integrated Services Digital Network
ISEP Instituo Superior de Engenharia do Porto
ISO International Organization for Standardization
LAN Local Area Network
LPC Link Consumer Object
LPO Link Producer Object
MAC Medium Access Control
MAC ID Media Acess Control Identifier
MAN Metropolitam Area Network
IV
NIC Network Interface Card
ODVA/CI Open DeviceNet Vendor Association / Controlnet International
OSI Open Systems Interconnection
PC Personal Computer
RM Rate Monotonic
SMTP Simple Mail Transport Transfer Protocol
SNMP Simple Network Management Protocol
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol/internet Protocol
UCMM UnConnected Message Manager
UDP User Datagram Protocol
VLAN Virtual Local Area Network
WAN Wide Area Network
V
Índice geral Agradecimentos................................................................................................................ II
Acrónimos........................................................................................................................ III
Índice geral........................................................................................................................ V
Índice de figuras............................................................................................................. VIII
Índice de tabelas .............................................................................................................. IX
Objectivos ..........................................................................................................................1
1. Introdução ..................................................................................................................2
2. Sistemas de Tempo Real............................................................................................4
2.1. Introdução ..............................................................................................................4
2.2. A tarefa ...................................................................................................................4
2.3. Pre-empção............................................................................................................5
2.4. Tempo de resposta .................................................................................................5
2.5. Escalonamento.......................................................................................................6
2.6. Rate Monotonic (RM) – Análise de Escalonabilidade .............................................6
2.7. Análise de escalonabilidade em sistemas distribuídos (tarefas comunicantes) ....9
3. Arquitecturas de rede...............................................................................................13
3.1. Introdução ............................................................................................................13
3.2. Modelo de referência OSI .....................................................................................13
3.3. A arquitectura TCP/IP ...........................................................................................14
3.3.1. Camada Data link..............................................................................................15
3.3.2. Camada Internet ...............................................................................................15
3.3.3. Camada Transport............................................................................................16
3.3.4. Camada Application .........................................................................................17
4. IEEE 802.3 Ethernet ..................................................................................................19
4.1. Introdução ............................................................................................................19
4.2. Controlo do acesso ao meio físico .......................................................................20
4.3. Equipamentos ......................................................................................................20
4.3.1. Repeaters .........................................................................................................20
VI
4.3.2. Hubs .................................................................................................................21
4.3.3. Bridges .............................................................................................................22
4.3.4. Switches ...........................................................................................................23
4.3.5. Routers.............................................................................................................26
5. Tempo Real e IEEE 802.3 Ethernet ...........................................................................28
5.1. O tráfego...............................................................................................................28
5.2. IEEE 802.3 Ethernet e a Ethernet/IP ......................................................................30
6. Control Information Protocol (CIP) ...........................................................................32
6.1. Introdução ............................................................................................................32
6.2. Modelo de objectos..............................................................................................32
6.3. Estrutura do sistema ............................................................................................32
6.3.1. Topologia .........................................................................................................32
6.3.2. Lógica...............................................................................................................33
6.4. Endereçamento ....................................................................................................33
6.5. Os identificadores ................................................................................................34
6.6. Rede CIP...............................................................................................................35
6.6.1. I/O Connections................................................................................................35
6.6.2. Explicit Messaging Connections ......................................................................35
6.7. Modelo de Objectos de um produto CIP ...............................................................36
6.8. Protocolo para envio de mensagens ....................................................................37
6.8.1. Estabelecimento de uma conexão....................................................................37
6.8.2. Acesso aos dados do objecto ..........................................................................40
6.8.3. Comportamento das I/O Connections ..............................................................42
6.8.4. Comportamento das Explicit Messaging Connection .......................................43
7. Modelo de rede Produtor/Consumidor .....................................................................46
7.1. Introdução ............................................................................................................46
7.2. O modelo de rede Origem/Destino .......................................................................46
7.3. O novo paradigma................................................................................................47
8. Ethernet/Industrial Protocol (Ethernet/IP).................................................................49
8.1. Introdução ............................................................................................................49
VII
8.2. Protocolo de Encapsulamento .............................................................................50
8.2.1. Uso do TCP e UDP ............................................................................................50
8.2.2. Encapsulamento de mensagens.......................................................................50
8.2.3. Formato comum ...............................................................................................52
8.2.4. Fases de uma sessão TCP ...............................................................................52
8.3. Mapeamento das Explicit e I/O Messaging no TCP/IP..........................................53
8.4. Visão geral do encapsulamento ...........................................................................53
9. Conclusões..............................................................................................................55
Referências ...................................................................................................................... XI
Índice remissivo ............................................................................................................. XIII
VIII
Índice de figuras
Figura 1: Dados das tarefas (fonte [12]). ................................................................................5
Figura 2: Análise gráfica - sistema escalonável. .....................................................................7
Figura 3: Análise gráfica – Sistema não escalonável...............................................................8
Figura 4: Envio de uma mensagem entre dois nós................................................................10
Figura 5: Conceitos do método token-passing. .....................................................................11
Figura 6: Tráfego necessário para as três transacções. ........................................................12
Figura 7: Camadas do modelo OSI (fonte [18]). ....................................................................14
Figura 8: Arquitectura protocolar TCP/IP em relação ao modelo de referência OSI (fonte [3]). .15
Figura 9: Formato de um pacote IPv4 (fonte [3]). ..................................................................16
Figura 10: Formato dos segmentos do protocolo UDP (fonte [3]). ..........................................16
Figura 11: Formato dos segmentos do protocolo TCP (fonte [3]). ..........................................17
Figura 12: Posicionamento de vários protocolos da arquitectura TCP/IP(fonte [3]). .................18
Figura 13: Trama Ethernet(fonte [17]). .................................................................................19
Figura 14: Colisão numa rede CSMA/CD(fonte [3]). ..............................................................20
Figura 15: Posicionamento de um repeater em relação à arquitectura TCP/IP(fonte [3])..........21
Figura 16: Interligação de host com um hub(fonte [3]). ..........................................................22
Figura 17: Posicionamento funcional das pontes face ao modelo OSI (fonte [3]). ....................22
Figura 18: Diagrama de blocos de uma bridge (fonte [3]). .....................................................23
Figura 19: Várias comunicações simultâneas numa rede Ethernet com um switch(fonte [3]). ..24
Figura 20: Exemplo de configuração de VLANs numa LAN (fonte [3]). ...................................25
Figura 21: Cenário de interligação de redes de diferentes tecnologias e âmbitos (fonte [3]). ....26
Figura 22: Posicionamento funcional dos routers face à arquitectura TCP/IP (fonte [3]). .........27
Figura 23: Configuração de uma rede com uma única VLAN(fonte [5])...................................29
Figura 24: Configuração de uma rede com duas VLANs (fonte [5]). .......................................29
Figura 25: Exemplo de Routing Multicast (fonte [5]). ............................................................30
Figura 26: Arquitectura Ethernet/IP(fonte [5]). .......................................................................31
Figura 27: Estrutura de rede – topologia (fonte [1]). ..............................................................33
Figura 28: Estrutura de rede – lógica(fonte [1]). ....................................................................33
Figura 29: Exemplo de endereçamento de um objecto(fonte [1]). ...........................................34
IX
Figura 30: I/O Connection(fonte [1]). ....................................................................................35
Figura 31: Explicit Messaging Connections (fonte [1]). ..........................................................36
Figura 32: Modelo de objectos de um produto CIP(fonte [1]). ................................................36
Figura 33: Conexões e Connections IDs(fonte [1]). ...............................................................37
Figura 34: Estabelecimento de uma Explicit Messaging Connections(fonte [1]).......................38
Figura 35: Criação e configuração de uma I/O Connection(fonte [1]). .....................................39
Figura 36: Connection Object(fonte [1]). ...............................................................................39
Figura 37: Connections Path(fonte [1]). ................................................................................40
Figura 38: Acesso aos objectos por I/O Connections(fonte [1]). .............................................41
Figura 39: Diagrama de transições de uma I/O Connection (fonte [1]). ...................................42
Figura 40: Diagrama de transições de estado de uma instância de um objecto Explicit Messaging Connection (fonte [1]). ...............................................................................44
Figura 41: Relação eventos / estado de Explicit Messaging Connection. ................................45
Figura 42: Mensagem típica do modelo Origem/Destino(fonte [14]). ......................................47
Figura 43: Mensagem típica do modelo Produtor/Consumidor(fonte [14]). ..............................47
Figura 44: Arquitectura TCP/IP e a Ethernet/IP(fonte [1]). .....................................................50
Figura 45: Passos para o encapsulamento de uma mensagem. ............................................54
Índice de tabelas Tabela 1: Dados das tarefas..................................................................................................6
Tabela 2: Tempo de resposta da análise gráfica – sistema Escalonável...................................7
Tabela 3: Dados das tarefas..................................................................................................8
Tabela 4: Tempo de resposta da análise gráfica – sistema não escalonável.............................8
Tabela 5: Dados das tarefas do nó 3. ..................................................................................11
Tabela 6: Resposta temporal das tarefas do nó 3. ................................................................11
Tabela 7: Intervalos de valores aplicáveis aos Class ID(fonte [1]). .........................................34
Tabela 8: Relação eventos / estado de I/O Connection. ........................................................43
Tabela 9: Estrutura de encapsulamento de um pacote. .........................................................50
Tabela 10: Formato comum dos pacotes de encapsulamento................................................52
X
Tabela 11: Formato do campo Endereço e Dados do pacote comum.....................................52
Tabela 12: Formato do pacote de encapsulamento de uma mensagens implícita ou explicita. .53
1
Objectivos
O objectivo final deste trabalho é o estudo de uma nova arquitectura de comunicações para
ambientes industriais. Ethernet/Industrial Protocol (Ethernet/IP) é a designação dessa nova
arquitectura que surgiu em 2000.
Com este trabalho pretende-se fazer uma compilação dos conceitos e das tecnologias base
assim como outros aspectos considerados relevantes.
Este trabalho insere-se por um lado, num projecto do grupo I&D IPP-HURRAY do Instituto
Superior de Engenharia do Porto (ISEP), por outro lado, num trabalho curricular da cadeira de
Projecto do 5ºano da licenciatura em Engenharia Informática do mesmo estabelecimento de
ensino.
2
1. Introdução Em Setembro de 1980 surgiu a primeira norma comercial da Ethernet . Em 1985 o Institute of
Electrical and Electronic Engineers (IEEE) publicou o primeiro conjunto de normas da Ethernet
com o título: 802.3 Carrier sense Multiple Access with Collision Detection(CSMA/CD). Esta
norma foi mais tarde adoptada pelo International Organization for Standardization (ISO). Isto
fez com que esta tecnologia seja o meio mais utilizado nas Local Area Network (LAN). Estas
redes não têm, geralmente, necessidades prementes em termos de requisitos temporais.
Em Janeiro de 1998 Eric Byres afirmou “I think we may see completely take over the industrial
bus and network market in the next ten years” [13].
Hoje em dia cada vez mais existem dispositivos que necessitam de informação em tempo útil.
Nomeadamente os Sistemas de Tempo Real. Será que é possível utilizar a tecnologia Ethernet
em ambientes cujas as aplicações tem estas necessidades? O Ethernet/IP (Ethernet/ Industrial
Protocol) pretende dar resposta a esta questão.
O Instituto Superior de Engenharia do Porto (ISEP), através do grupo I&D IPP-HURRAY
(http://www.hurray.isep.ipp.pt/) tem vindo desde 2003 a participar activamente no projecto
Industrial Ethernet Protocols Under Holistic Analysis (INDEPTH), em parceria com a Rockwell
AutomationTM, no âmbito do qual se insere este trabalho.
O relatório está estruturado da seguinte forma. No capítulo 2 é feita uma breve descrição dos
dos conceitos e definições aos Sistemas de Tempo Real.
No capítulo 3 é feita uma abordagem às arquitecturas de rede, nomeadamente uma breve
descrição do modelo Open Systems Interconnection (OSI) e da arquitectura Transmission
Control Protocol/internet Protocol (TCP/IP).
No capítulo 4 é feita uma descrição da evolução da tecnologia IEEE 802.3 Ethernet assim
como das suas principais características.
O capítulo 5 faz a ponte entre a tecnologia IEEE 802.3 Ethernet e a pilha de protocolos
Ethernet/IP. Neste capítulo é abordado como é possível a utilização do standard Ethernet
(IEEE 802.3) em ambientes com restrições temporais, isto é, em Sistemas de Tempo Real.
No capítulo 6 faz-se uma descrição do que é o Control Information Protocol (CIP). Não
pretendendo ser muito exaustivo também não se pretende uma abordagem muito superficial.
No capítulo 7 é descrito um novo paradigma importante associado a este tipo de redes: o
modelo de rede Produtor/Consumidor.
O capítulo 8 trata do que dá título a este relatório, Ethernet/IP. Não é muito exaustivo porque
ainda não existe muita informação. Neste capítulo é descrito como é feito o encapsulamento
das mensagens.
Finalmente, no capítulo 9 são descritas as conclusões e são feitas algumas comparações com
tecnologias concorrentes.
Em algumas situações são usados estrangeirismos. Este facto deve -se essencialmente a dois
motivos. Por um lado, por vezes, é complicado traduzir para português mantendo o significado.
Por outro lado, como nas figuras e em algumas tabelas aparecem as expressões em inglês,
manteve-se as expressões em inglês nos textos para permitir uma melhor e mais rápida
3
relação entre eles. Em relação as figuras, na legenda é colocada a fonte. Nalgumas figuras
houve necessidade de fazer algumas alterações ou mesmo criá-las. Mesmo as que foram
criadas é referida a fonte.
4
2. Sistemas de Tempo Real
2.1. Introdução Na medida em que o uso de sistemas informáticos prolifera na sociedade actual, as aplicações
com requisitos de tempo real tornam-se cada vez mais comuns [12]. Essas aplicações variam
muito em relação à complexidade e às necessidades de garantia de restrições temporais. Entre
os sistemas mais simples, estão os controladores inteligentes inseridos nos electrodomésticos
comuns, tais como máquinas de lavar, fogões, frigoríficos, etc..
Na outra extremidade do espectro de complexidade estão os sistemas militares e defesa, os
sistemas de controlo de fábricas industriais (químicas, nucleares, e outras) e o controlo de
tráfego aéreo e/ou ferroviário.
Algumas aplicações de tempo real apresentam restrições de tempo mais rigorosas do que
outras. Entre essas, encontram-se os sistemas responsáveis por monitorizar pacientes em
hospitais, sistemas de supervisão e controlo em fábricas industriais e os sistemas inseridos em
robôs e veículos (desde automóveis até aviões e sondas espaciais). Entre as aplicações que
não apresentam restrições tão críticas, normalmente, são citadas as consolas de jogos, as
teleconferências através da Internet e as aplicações multimédia. Todas as aplicações que
apresentam a característica adicional de estarem sujeitas a restrições temporais, são
consideradas como Sistemas de Tempo Real.
Um sistema computacional de tempo real depende não só da correcção do resultado lógico
mas também da produção atempada do resultado.
Geralmente pensa-se que os Sistemas de Tempo Real têm que ser computacionalmente muito
rápidos. A rapidez de cálculo aumenta o desempenho do sistema, minimizando o tempo de
resposta médio de um conjunto de tarefas (o conceito de tarefa será explicado com mais
detalhe a seguir). No entanto, o principal objectivo não é o desempenho médio mas sim o
global. Isto é, pretende-se que todas as tarefas cumprem as restrições temporais associadas.
Para estes sistemas, mais importante que a rapidez é a previsibilidade. E para prever é
necessário conhecer a priori o comportamento do sistema, nomeadamente os tempos de
máximos de execução das tarefas. A arquitectura de hardware, o sistema operativo e as
linguagens de programação são importantes para determinar o tempo máximo de execução.
Por exemplo, o mecanismo de memória cache, as funções recursivas e o garbage collector do
Java são elementos que dificultam o determinismo. Ora se é difícil determinar qual o tempo
máximo de execução de uma tarefa, então torna-se complicado fazer previsões com alguma
exactidão.
De seguida, vamos abordar conceitos básicos de Sistemas de Tempo Real para
escalonamento de processos num sistema computacional multi-processo e uni-processador
[15].
2.2. A tarefa Neste contexto, uma tarefa é uma entidade que pode ser implementada como um processo ou
thread para a execução de uma determinada funcionalidade.
5
As propriedades mais importantes das tarefas são (figura 1):
o C – Máximo tempo de computação de uma tarefa;
o T – Periodicidade de uma tarefa (ou o menor intervalo entre duas activações
consecutivas de uma tarefa);
o D –- Deadline (meta temporal) relativo da tarefa;
o O – Offset (instante da primeira activação da tarefa no sistema).
Figura 1: Dados das tarefas (fonte [12]).
Num sistema computacional podem existir N tarefas, t1, t2,..., tN, sendo então cada uma delas
caracterizada da seguinte forma (geralmente não se coloca o Offset):
t i =(C i, T i ,D i)
As tarefas, quanto à periodicidade, podem ser de três tipos:
o Periódicas – aquelas que tem um T associado;
o Esporádicas – aquelas que apresentam como característica um intervalo mínimo
conhecido entre duas activações consecutivas;
o Espontâneas – aquelas que tem como característica a aleatoriedade das activações,
uma vez que são activadas por eventos internos ou externos.
As tarefas, quanto à utilização de recursos, podem ser de dois tipos:
o Independentes – que não utilizam recursos que são partilhados por outras tarefas;
o Dependentes – que utilizam recursos que são partilhados por outras tarefa.
2.3. Pre-empção No caso de o ambiente ser pre-emptivo, a tarefa pode ser interrompida por uma outra de maior
prioridade (interferência) até ao fim da sua execução. Num ambiente não pre-emptivo uma
tarefa não pode ser interrompida enquanto não terminar a sua execução. Isto pode provocar
bloqueio nas tarefas de maior prioridade.
2.4. Tempo de resposta O tempo de resposta de uma tarefa corresponde ao intervalo de tempo desde que ela é
lançada no sistema até acabar a sua execução.
6
2.5. Escalonamento Rate Monotonic (RM), Deadline Monotonic (DM), Earliest Deadline First (EDF) e First Come
First Served (FCFS) são nomes de políticas de escalonamento de processos (ou tarefas). O
escalonamento FCFS, como o próprio nome indica (primeiro a chegar primeiro a ser servido),
consiste numa política de escalonamento em que a sequência de execução a ordem de
chegada da instância da tarefa ao sistema. Além de não permitir pre-empção não tem em
atenção outros pormenores como T ou D, o que faz com que não seja apropriado para
sistemas de tempo real. Ao contrário, as outras políticas de escalonamento referidas atrás são
apropriadas para estes sistemas.
O RM consiste num esquema em que as prioridades são estáticas. Neste caso as prioridades
mais altas são para as tarefas mais frequentes, isto é, aquelas que tem o T mais baixo. Tal
como o RM, o escalonamento DM consiste num esquema em que as prioridades são estáticas.
No entanto, as prioridades mais altas são para as tarefas que tem o D mais baixo. O EDF ao
contrário do RM e do DM, o escalonamento é feito com base em prioridades dinâmicas. As
prioridades alteram-se em tempo de execução. A prioridade mais alta é atribuída às instâncias
das tarefas que têm o D absoluto mais próximo. Isto é, a instância da tarefa que tem que
terminar mais cedo em relação ao instante actual é aquela que é atribuída a prioridade mais
alta.
Destas só a política RM irá ser descrita com pormenor na secção seguinte, por ser a mais
utilizada em sistemas Commercial Of The-Self (COTS ). Para que um sistema seja escalonável
é necessário, para cada tarefa, que o Tempo de Resposta seja inferior ou igual ao respectivo
D.
2.6. Rate Monotonic (RM) – Análise de Escalonabilidade Por forma do problema a simplificar o problema da análise de escalonabilidade de tarefas
ignoram-se algumas latências como sendo o tempo de mudança de contexto, acessos à
memória, etc. Considere um conjunto de quatro tarefas, caracterizadas da seguinte forma:
Tarefa C T D A 5 15 11 B 4 16 15 C 2 20 20 D 6 30 29
Tabela 1: Dados das tarefas. O escalonamento RM consiste num esquema em que as prioridades são estáticas. Neste caso
as prioridades mais altas são para as tarefas mais frequentes, isto é, aquelas que tem o T mais
baixo. Portanto, no conjunto de tarefas apresentado, a tarefa de maior prioridade é a tarefa A, e
a de menor prioridade a tarefa D.
Para analisar a priori se um conjunto de tarefas é escalonável de acordo com o RM, podem
utilizar-se métodos analíticos ou gráficos.
7
De forma analítica temos duas possibilidades: através da análise da utilização do processador;
ou através da análise da resposta temporal da tarefa. Estas análises têm que ser feitas em
função do ambiente, se pre-emptivo ou não, e se as tarefas são ou não independentes. Caso
não sejam independentes qual a política de prioridades em relação aos recursos – Herança de
prioridades ou Tecto de prioridades. A seguir é apresentada a análise gráfica para um
ambiente pre-emptivo e tarefas independentes.
Para efectuar análise gráfica e determinar o tempo de resposta (R) de uma tarefa temos que
considerar a pior situação (instante crítico) para o sistema. A pior situação para este método
acontece quando todas as tarefas chegam ao mesmo tempo ao sistema.
Figura 2: Análise gráfica - sistema escalonável.
Para que um sistema seja escalonável todas as tarefas têm que apresentar:
ii DR ≤
Como se pode ver pela tabela seguinte, nenhuma tarefa perdeu o D. Então este conjunto de
tarefas é escalonável para um ambiente pre-emptivo com tarefas independentes e cuja politica
de escalonamento é o RM.
Tarefa C T D R A 5 15 11 5 B 4 16 15 9 C 2 20 20 11 D 6 30 29 28
Tabela 2: Tempo de resposta da análise gráfica – sistema Escalonável.
8
Considere a seguinte alteração em relação à tabela 1:
Tarefa C T D A 5 15 11 B 4 16 15 C 2 20 20 D 6 25 25
Tabela 3: Dados das tarefas.
Só se alterou a periodicidade (T) e o deadline (D) da Tarefa D para 25 unidades de tempo.
Como se pode ver pela análise gráfica, este conjunto de tarefas deixa de ser escalonável .
Figura 3: Análise gráfica – Sistema não escalonável.
De facto, a Tarefa D perde o D, isto é, o tempo de resposta é maior que o respectivo D. A
tabela 4 apresenta os resultados.
Tarefa C T D R A 5 15 11 5 B 4 16 15 9 C 2 20 20 11 D 6 25 25 28
Tabela 4: Tempo de resposta da análise gráfica – sistema não escalonável.
Ora, caso o sistema tenha muitas tarefas, como é normal, torna-se complicado fazer a análise
de escalonabilidade desta forma. Para tal o mais simples e com menos probabilidade de erro é
fazer a análise de escalonabilidade de forma analítica. Relembra-se que estamos perante um
ambiente pre-emptivo com tarefas independentes e a politica de escalonamento é o RM. O
objectivo é verificar se existe alguma tarefa cujo o R seja maior do que o D:
ii DR ≤
Para tal é necessário efectuar uma série de cálculos. De seguida descreve-se todo o processo
para chegar ao resultado:
9
iii ICR +=
em que R corresponde à resposta temporal da tarefa i e I corresponde à interferência que a
tarefa i pode sofrer. A interferência total corresponde ao somatório das interferências causadas
por todas as tarefas j com prioridade maior ou igual à da tarefa i (j ∈ hp (i)):
∑∈
×
=
)( ihpjj
j
ii C
TR
I
Então, substituindo Ii na equação (2) tem que, para o RM, caso pre-emptivo e tarefas
independentes, o tempo de resposta de uma tarefa i é dado pela equação seguinte:
∑∈
×
+=
)(ihpjj
j
iii C
TR
CR
O que se pretende determinar Ri, aparece dos dois lados da equação, e não é possível
reformular a equação de forma a ter Ri só do lado esquerdo (a função de ceiling não é uma
função linear...).
Estamos por isso perante uma equação recorrente (incógnita está dos dois lados da equação).
Daí que a equação passa a ser a seguinte:
∑∈
+
×
+=
)(
1
ihpjj
j
ni
in
i CTR
CR
Começam-se as iterações com :
ii CR =0
e quando:
ni
ni RR =+1
está encontrada a solução.
Para que o número de iterações seja finito é necessário que a utilização do processador seja:
11
≤∑=
N
i i
i
TC
2.7. Análise de escalonabilidade em sistemas distribuídos (tarefas comunicantes) Se considerarmos os Sistemas de Tempo Real em ambiente distribuídos, como é normal em
sistemas industriais, a comunicação desempenha um papel importantíssimo nos tempos de
resposta das tarefas nestes sistemas. Os objectivos de protocolos de comunicação em
Sistemas de Tempo Real são diferentes dos sistemas que não são de tempo real. Em sistemas
convencionais, não de tempo real, o aumento do desempenho é feito com base no aumento
das taxas de transferência (bit rate). Na comunicação em sistemas de tempo real o que se
procura é a obtenção de altas probabilidades que uma mensagem será entregue dentro de um
10
deadline específico. Para que seja possível determinar se um determinado conjunto de tarefas
é ou não escalonável, será necessário conhecer qual a latência máxima que uma mensagem
pode sofrer. A figura 4 ilustra o envio de uma mensagem.
Figura 4: Envio de uma mensagem entre dois nós.
A comunicação entre processos em diferentes nós num sistema distribuído requer o envio e a
recepção de mensagens sobre o meio que permite a interligação do sistema. Para enviar uma
mensagem os nós têm que competir pelo acesso ao meio. Vamos assumir que o modelo de
rede é composto por N nós ligados por um bus. Para controlar o acesso ao meio, é utilizado o
método Token-passing. Neste método existe um token que permite, a quem o possuir, efectuar
uma transacção (enviar um pedido e receber a resposta). O token passa de nó em nó mediante
uma qualquer heurística.
Assuma que sempre que um nó tem o token pode efectuar, no máximo, uma transacção. Se C
é o tempo necessário para efectuar uma transacção (em função do tamanho em bits da
transacção e do bit rate da rede), então o tempo entre duas posses consecutivas do token,
geralmente designado de visita, por um determinado nó é dado pela fórmula:
CNV ×=
A figura 5 ilustra os conceitos associados ao envio de mensagens com o método token-
passing.
11
Figura 5: Conceitos do método token-passing.
Admita uma rede de comunicações na qual existem três nós. Cada transacção pode
corresponder, no máximo, à transferência de 2000 bits. No nó 3 existem três tarefas cujas as
características são apresentadas na tabela 5:
Tarefa C (ms) T=D(ms) A 2 5 B 1 7 C 2 9
Tabela 5: Dados das tarefas do nó 3.
Estas tarefas são escalonadas de acordo com o RM pre-emptivo. Os pedidos gerados são
colocados numa fila de pedidos pendentes do tipo FCFS. Os pedidos são sempre gerados
pelas tarefas no início da sua execução. Qual seria o bit rate mínimo da rede para que em
nenhum instante existam mais de três pedidos na fila (um pedido referente a cada tarefa) de
pedidos pendentes. Considera-se desprezível o tempo de rotação do token.
Para resolver este problema seria necessário determinar os tempos de resposta de cada
tarefa. Como já foi referido, pode-se calcular o tempo de resposta de duas formas: analítica e
gráfica. Uma vez que já foi demonstrado com se efectuam, apresentam-se os resultados
(tabela 6).
Tarefa C T=D R A 2 5 2 B 1 7 3 C 2 9 5
Tabela 6: Resposta temporal das tarefas do nó 3.
Como se pode ver pelos resultados o conjunto de tarefas é escalonável. E para que não
existam mais do que três pedidos na fila é necessário que o nó possua o token com um
intervalo inferior a 5 ms. Isto porquê. Porque se o nó receber o token com essa frequência é
garantido que nunca existiram mais do que três pedidos na fila. Então qual será o bit rate
mínimo para que isto aconteça. O gráfico da figura 6 permite visualizar o processo. Salienta-se
que se deve considerar a pior situação, que neste caso será quando o nó possui o token e
12
começa uma transacção referente a um pedido que está na fila, e chegam os três pedidos em
simultâneo.
Como se pode ver pelo gráfico é necessário um tráfego de 20000 bits para que o nó 3 consiga
efectuar as transacções referentes às tarefas. Ora para que não existam mais de três tarefas
na fila o bit rate da rede deve ser de forma a permitir a transferência de 20000 bits em menos
de 5 ms. Fazendo os cálculos o bit rate deve ser superior a 4Mbps.
Figura 6: Tráfego necessário para as três transacções.
Importa referir que este modelo apresentado neste exercício está muito simplificado para
facilitar a compreensão dos problemas associados à análise de escalonabilidade em ambiente
distribuído.
13
3. Arquitecturas de rede
3.1. Introdução A interligação de sistemas abrange um leque alargado de aspectos, alguns dos por si só,
comportando um considerável nível de complexidade [3]. Os principais problemas relativos à
comunicação entre sistemas relacionam-se, directa ou indirectamente, com os seguintes
aspectos:
o Comunicação entre processos – possibilitar a troca de informação e a sincronização
de várias actividades entre tarefas;
o Representação de dados – definição da forma de representação da informação
trocada entre sistemas, estabelecendo uma sintaxe comum aos sistemas
comunicantes;
o Armazenamento de dados – estabelecimento das formas de armazenamento,
temporário ou não, e as formas de acesso remoto a dados;
o Gestão de recursos e de processos – controlo da aquisição, inicialização e utilização
de recursos nos sistemas origem/destino de informação e no sistema de comunicação;
o Segurança – definição de procedimentos para autenticação, integridade,
confidencialidade e não repúdio da comunicação entre entidades.
A definição destes e de outros aspectos para a interligação de sistemas constitui um modelo ou
arquitectura de comunicação. Uma arquitectura de comunicação define e descreve um
conjunto de conceitos – como, por exemplo, camadas, serviços, protocolos, modos de
comunicação, identificadores, nomes e endereços – aplicáveis à comunicação entre sistemas
reais, compostos por hardware, processos físicos, software de comunicação, processos de
aplicação e utilizadores humanos.
3.2. Modelo de referência OSI O modelo de referência OSI resulta de um projecto de grande envergadura conduzido ISO
durante os anos 70 e 80.
O objectivo inicial do projecto era o de desenvolver um enquadramento que permitisse a
elaboração de normas para a interligação de sistemas abertos, isto é, de sistemas modulares
totalmente independentes de fabricantes. Este objectivo não foi totalmente atingido por várias
razões. No entanto tornou-se um modelo de referência.
O modelo de referência OSI agrupa as funcionalidades de comunicação em sete camadas, de
acordo com critérios de afinidade, abrangendo aspectos que vão desde o equipamento de
interface com os meios físicos, até aos protocolos de aplicação.
A figura 7 representa as diversas camadas constituintes do modelo.
14
Figura 7: Camadas do mode lo OSI (fonte [18]).
3.3. A arquitectura TCP/IP Curiosamente, a arquitectura TCP/IP - a arquitectura protocolar da Internet - atingiu, com
enorme êxito, os objectivos primordiais inicialmente estabelecido para o modelo OSI da ISO:
independência relativamente a fabricantes de equipamento, abertura e universalidade. A sua
concepção, no entanto, seguiu uma metodologia totalmente diversa da metodologia utilizada no
desenvolvimento modelo OS [3] I. No caso da arquitectura TCP/IP, privilegiou-se uma
abordagem simples, pragmática e, normalmente, precedida de experimentação e comprovação
em ambiente real. Deste modo, a arquitectura TCP/IP conduziu a soluções despidas de
complexidade que não fosse justificado por necessidades concretas. Esse mesmo facto é
patente na arquitectura protocolar resultante, que é composta por apenas cinco níveis ou
camadas (em alguma documentação aparece quatro camada porque não consideram a
camada do nível físico), em vez das sete camadas preconizadas pelo modelo OSI da ISO. A
figura 8 representa a arquitectura protocolar TCP/IP, ao lado da arquitectura OSI, sendo visível
a correspondência entre camadas.
15
Figura 8: Arquitectura protocolar TCP/IP em relação ao modelo de referência OSI (fonte [3]).
A seguir, não considerando o nível physical irá ser abordado as principais características de
cada camada.
3.3.1. Camada Data link Esta camada é a que lida com os aspectos da tecnologia subjacente (estrutura das tramas,
endereçamento físico, acesso ao meio físico, etc.), tornando as camadas superiores
independentes da tecnologia de rede utilizada.
Esta camada abrange o hardware de interface com a rede e os correspondentes device drivers
do sistema operativo.
Algumas das funções de relevo desta camada são o encapsulamento dos pacotes do protocolo
Internet Protocol (IP) nas tramas a transmitir para a rede e a tradução de endereços da camada
de Internet em endereços da camada physical.
3.3.2. Camada Internet A camada Internet é, também, designado camada Network , corresponde a um dos protocolos
que dá o nome à arquitectura protocolar: o protocolo IP.
Esta camada é o responsável pela circulação dos pacotes - também designados datagramas
(datagrams) - na rede, executando o seu encaminhamento com base nos endereços de
destino. Neste nível também podem ser executadas acções de fragmentação (subdivisão) e de
reassemblagem (junção, reconstituição) de pacotes, operações essas que têm em vista o
ajuste do tamanho dos pacotes ao tamanho máximo dos quadros suportados pela tecnologia
de rede subjacentev(por exemplo Ethernet ).
16
O routing processa-se, assim, salto-a-salto e pacote-a-pacote, com base em tabelas de routing
armazenadas nos routers e actualizadas por acção de um gestor de rede ou de protocolos de
routing. A figura 9 representa um pacote IP versão 4 (IPv4), sendo visíveis os diversos campos
necessários para o routing e as outras operações desta camada.
Figura 9: Formato de um pacote IPv4 (fonte [3]).
O rápido crescimento da Internet e o esgotamento de endereços provocado pelo desperdício
decorrente do esquema de endereçamento hierárquico adoptado na arquitectura TCP/IP está,
precisamente na base, do desenvolvimento de uma nova versão do protocolo IP o protocolo
IPv6. Nesta versão do protocolo IP, os endereços passam a ter 128 bits, em vez dos 32 do
IPv4.
3.3.3. Camada Transport A camada Transport é uma camada de comunicação end-to-end (host-to-host), sendo os
protocolos User Datagram Protocol (UDP) e Transmission Control Protocol (TCP) os seus
protocolos mais importantes.
O protocolo UDP é - tal como o protocolo IP - um protocolo que funciona em modo de ausência
de ligação, não garantindo, portanto, a transferência fiável de informação end-to-end. O
formato dos segmentos UDP é representado na figura 10, sendo patente a sua simplicidade.
Figura 10: Formato dos segmentos do protocolo UDP (fonte [3]).
A ausência de fiabilidade não significa que este seja um protocolo que não deva ser usado.
Pelo contrário, para aplicações que garantam, elas próprias, a fiabilidade da comunicação,
17
deve ser este o protocolo de transporte a utilizar, já que introduz uma sobrecarga protocolar
mínima.
O protocolo TCP - que, em conjunto com o protocolo IP, dá o nome à arquitectura protocolar - é
o protocolo funcionalmente mais rico desta camada, funcionando em modo de ligação e,
portanto, garantindo a transferência livre de erros de qualquer fluxo de bytes entre o emissor e
o receptor.
O formato dos segmentos do protocolo TCP é representado na figura 11, sendo patente a sua
maior complexidade em relação ao protocolo UDP.
Figura 11: Formato dos segmentos do protocolo TCP (fonte [3]).
A maior complexidade do TCP é necessária para suportar as funções de estabelecimento das
ligações, controlo de sequência, controlo de erros, controlo de fluxo e terminação das ligações,
sem as quais não seria possível garantir a transferência de dados.
3.3.4. Camada Application A camada Application é a camada que está no topo da arquitectura, oferecendo serviços que
interessam directamente os utilizadores ou às tarefas das aplicações. Existe uma grande
variedade de protocolos nesta camada, correspondendo à grande variedade de necessidades
dos utilizadores. Alguns dos protocolos de aplicação mais conhecidos são:
o File Transf er Protocol (FTP ) – protocolo para acesso e transferência de ficheiros;
o Simple Mail Transport Transfer Protocol (SMTP) – protocolo de correio electrónico;
o HyperText Transfer Protocol (HTTP ) – protocolo de hipertexto/hipermédia.
Para além destes, outros protocolos de aplicação são de extrema importância para o
funcionamento em ambiente distribuído, apesar de, normalmente, serem invisíveis para o
utilizador. Alguns destes são:
o Domain Name Server (DNS) – aplicação de directório, incluindo mapeamento de
nomes e endereços; o Simple Network Management Protocol (SNMP) – protocolo para suporte de
aplicações de gestão de redes;
o Dynamic Host Configuration Protocol (DHCP) – protocolo para partilha de ficheiros
em rede.
18
A figura 12 ilustra o posicionamento destes e de outros protocolos de outros níveis da
arquitectura TCP/IP, dando uma panorâmica geral da relação entre eles.
Figura 12: Posicionamento de vários protocolos da arquitectura TCP/IP(fonte [3]).
19
4. IEEE 802.3 Ethernet
4.1. Introdução A tecnologia Ethernet foi desenvolvida pela Xerox, lntel e DEC, nos meados da década de 70
tendo sido posteriormente normalizadas pelo Institute of Electrical and Electronics Engineers
(norma IEEE 802.3) e pela ISO (ISO 8802-3) [3]. Trata-se de uma tecnologia de grande
aceitação e divulgação, abrangendo a esmagadora maioria do parque implantado de redes
locais.
A enorme divulgação desta tecnologia levou a um baixo custo e a uma grande maturidade, que
se tornaram, por sua vez, no principal factor para a manutenção do domínio do mercado.
A tecnologia Ethernet utiliza a técnica CSMA/CD, explicada na secção seguinte, para controlo
do acesso ao meio. Tendo sido inicialmente desenvolvida para redes com topologia em bus
físico utilizando cabo coaxial, esta tecnologia foi sofrendo uma grande evolução suportando,
presentemente, uma grande variedade de meios físicos. Também a topologia deixou de ser um
bus físico, para passar a ser um bus lógico, normalmente correspondendo a uma topologia
física em estrela ou árvore. O próprio mecanismo CSMA/CD tem sofrido alterações, para que a
rede possa funcionar eficientemente a débitos elevados (100Mbps e 1 Gbps). Pode afirmar-se
que a tecnologia Ethernet de hoje apenas têm em comum com a tecnologia Ethernet inicial o
nome.
O suporte de diferentes meios físicos e diferentes velocidades levou ao aparecimento de
diversas variantes de Ethernet, genericamente designadas por x-Base-y, em que x é um
número que identifica o débito binário em Mbps, Base significa que a transmissão é feita em
banda de base (isto é, não é usada modulação de qualquer portadora) e y um número ou letras
que identificam o tipo para de meio físico utilizado. Este método de acesso ao meio é bastante
eficiente em redes com carga relativamente baixa, podendo sofrer uma degradação acentuada
se a carga da rede ultrapassar os 60%.
A figura 13 apresenta a estrutura de uma trama Ethernet.
Figura 13: Trama Ethernet(fonte [17]).
A Ethernet distingue um computador dos outros através de um endereço único associado a
cada Network Interface Card (NIC)[17]. Cada NIC é simultaneamente emissor e receptor de
tramas Ethernet. Quando os dados são empacotados, é colocada informação de routing no
início e no fim da informação original. A partir do momento em que o routing é feito com
sucesso, a informação desnecessária é descartada. Uma trama Ethernet tem uma capacidade
máxima de 1500 octetos. Quando se pretende transmitir grandes quantidades de informação, a
solução passa pela partição desta em blocos de dimensão apropriada, transmitir cada um em
separado e na recepção reagrupar os blocos de modo a obter-se a informação original. A
informação de uma trama Ethernet é transmitida bit a bit. Além destas operações, também é
realizada a validação da trama. Para tal o campo Frame check sequence contém um valor
20
chamado de Cyclic Redundancy Check (CRC) que o NIC receptor utiliza para validar a
recepção da trama.
4.2. Controlo do acesso ao meio físico Na técnica CSMA/CD, usado nas redes de tecnologia Ethernet, cada nó da rede monitoriza a
actividade no meio físico para determinar se este está ou não ocupado. Se um nó pretender
transmitir, deverá aguardar que o meio físico esteja livre. Poderão, no entanto, ocorrer colisões
se duas ou mais estações estiverem à espera de um período de silêncio para iniciarem uma
transmissão (figura 14). Se tal ocorrer, as estações prolongam a colisão durante algum tempo
(para garantir que todas as estações envolvidas a detectaram), interrompem a transmissão e
esperam um período de tempo aleatório antes de tentarem a retransmissão.
Figura 14: Colisão numa rede CSMA/CD(fonte [3]).
4.3. Equipamentos Uma rede de computadores é composta por um conjunto muito variado de componentes
(cabos, conectores, distribuidores e etc.) destinados ao suporte físico das infra-estruturas de
comunicações [3]. Este conjunto de equipamentos - normalmente designado por equipamento
passivo – deve permitir a interligação de todo equipamento informático, nomeadamente
daqueles que são necessários para o funcionamento da rede – equipamento activo - como é o
caso dos seguintes dispositivos: repeaters; hubs; bridges; switches; routers.
4.3.1. Repeaters Toda e qualquer rede de comunicação - e, em especial, as redes de área local - estão sujeitas
a limitações de carácter físico que condicionam a sua extensão máxima ou o número máximo
de dispositivos que a ela podem estar ligadas. De forma a estender a área de acção de uma
rede, podem ser utilizados repeaters cuja função é a de e/ou regenerar os sinais físicos que
21
recebem de um dos segmentos de rede que interligam, retransmitindo-os para o outro
segmento.
Os repeaters são dispositivos bidireccionais, sem qualquer funcionalidade de armazenamento
de bits (que seria indesejável, pois levaria a atraso de armazenamento e retransmissão) e sem
“inteligência” (não reconhecem a estrutura informação que os atravessa), limitando-se a repetir
os símbolos físicos que aparecem num dos seus portos para o outro. Trata-se, portanto, de
dispositivos que operam na camada Physical da arquitectura TCP/IP, tal como ilustrado na
figura 15.
Figura 15: Posicionamento de um repeater em relação à arquitectura TCP/IP(fonte [3]).
Tratando-se de dispositivos que se limitam a repetir os símbolos físicos de e para os seus
portos, não têm qualquer capacidade de isolamento ou filtragem de tráfego entre segmentos.
Por exemplo, numa rede Ethernet, isto significa que uma colisão num segmento é propagada
para outros que a ele estejam ligados por simples repetidores.
4.3.2. Hubs Um hub pode ser visto como um repeater com múltiplos portos (por exemplo, 8, 12, 24 ou
mesmo 48), todas da mesma tecnologia (Ethernet,Token Ring, etc.), cada um podendo
suportar a ligação de um dispositivo qualquer, por exemplo um host, numa topologia em
estrela.
Os dispositivos ligados ao hub comunicam com outros dispositivos de forma transparente,
transmitindo a informação para o meio físico. O hub encarrega-se de amplificar e repetir o sinal,
transmitindo-o para os restantes portos. Na sua configuração mais simples, os hubs não
efectuam qualquer filtragem ou routing da informação entre portos, fornecendo uma
funcionalidade semelhante à funcionalidade de uma rede com um meio físico partilhado. A
figura 16 uma rede de vários hosts, suportada num hub.
22
Figura 16: Interligação de host com um hub(fonte [3]). A interligação de diversos hubs permite a constituição de configurações mais elaboradas - e
também mais frequentes - com topologia em árvore.
4.3.3. Bridges A interligação de dois ou mais segmentos de LANs pode ser efectuada por dispositivos
designados bridges. Ao contrário do que se passa com os repeaters, que só abrangem
funcionalidade da camada Physical, as bridges desempenham funções da camada Data link ,
mais propriamente do Medium Access Control (MAC). Isto significa que, por um lado, a ligação
de uma bridge a um segmento de rede local é feita tal como a ligação de um host (isto é,
através de uma placa de interface com a rede, ou seja, de um NIC) e, por outro, que as bridges
recebem tramas, processam-nos e retransmitem-nos para outro segmento, se for caso disso. A
figura 17 ilustra o posicionamento funcional das bridges à arquitectura TCP/IP.
Figura 17: Posicionamento funcional das pontes face ao modelo OSI (fonte [3]).
As bridges funcionam, em geral, em modo promíscuo (promiscuous mode). Isto é, são
recebidos e processados todos os quadros recebidos em todas as suas interfaces,
independentemente do seu endereço de destino. O processamento de um quadro recebido é,
em essência, bastante simples, (figura 18) consistindo no seguinte:
23
o é verificado a existência de erros no quadro, caso existam, é simplesmente eliminado;
o endereço MAC do dispositivo destino é analisado, para verificar em que segmento LAN
se encontra essa estação;
o se o dispositivo destino se encontrar no mesmo segmento de onde o quadro foi
recebido, este é eliminado, pois não há necessidade da sua retransmissão por parte da
ponte;
o caso o dispositivo destino esteja noutro segmento que não o de origem, a bridge
retransmitirá o quadro para o segmento determinado pela sua base de dados de
retransmissão (forwarding database).
Figura 18: Diagrama de blocos de uma bridge (fonte [3]).
4.3.4. Switches Os switches são dispositivos de interligação de equipamento, que têm semelhanças com os
hubs e com as bridges. As semelhanças com os hubs residem no facto de serem dispositivos
com vários portos, permitindo a interligação de dispositivos numa topologia física em estrela.
As semelhanças com as bridges residem no facto de isolarem o tráfego entre os diversos
segmentos, fazendo o bridging e comutação da informação apenas para o segmento onde se
encontra a máquina destino.
Tal como as bridges, os switches memorizam o endereço da estação que se encontra ligada a
cada um dos seus portos e usam protocolos de bridging para encaminhamento. Sempre que
um dispositivo envia um quadro, o switch analisa o endereço de destino e comuta o quadro
apenas para o porto onde se encontra o dispositivo de destino.
Isto significa que, numa rede Ethernet, as colisões são fortemente reduzidas, já que podem
existir várias comunicações simultâneas para diferentes estações (o que corresponde a um
aumento efectivo da largura de banda utilizável). Essa situação é ilustrada na figura 19. Por
24
outro lado, as colisões passam a estar limitadas à situação em que um dispositivo e o switch
começam a transmitir um para o outro em simultâneo, o que acontece muito mais raramente do
que numa rede com meio partilhado, em que as colisões podem ocorrer entre N dispositivos.
Figura 19: Várias comunicações simultâneas numa rede Ethernet com um switch(fonte [3]).
As colisões poderão mesmo ser eliminadas se for possível o funcionamento em full-duplex.
Neste caso, é utilizado um par de condutores para transmissão e outro par para recepção,
estando os dispositivos da rede e o switch preparados para receber e transmitir
simultaneamente. Nestas condições, a largura de banda utilizável numa rede a C Mpbs
suportada num switch de N portos será N*C Mbps, dado que cada uma dos N dispositivos pode
transmitir a um débito de C Mbps, em simultâneo com os restantes N-1 dispositivos.
Cut-through ou store- and-forward
Os switches podem funcionar num de dois modos possíveis: cut-through ou store- and-forward.
No modo cut-through, logo depois da recepção do cabeçalho do quadro (que permite ao switch
determinar qual o porto para onde deve ser encaminhado o quadro), o switch começa a
retransmitir o quadro pelo porto correspondente ainda antes de ele ter sido recebido na
totalidade. Isto é, o switch não armazena o quadro para o transmitir posteriormente. Este modo
de operação tem claros benefícios em termos de atraso de trânsito. No entanto, em rede muito
sobrecarregada (isto é, sujeitas a um elevado número de colisões) ou em redes com muitos
erros, este modo de operação leva a que sejam comutados quadros que vêm posteriormente a
revelar-se corrompidos, o que é desnecessário.
No modo store-and-forward, o switch recebe integralmente o quadro antes de o começar a
retransmitir para o porto de destino. Há, portanto, um atraso adicional imposto pelo switch. No
entanto, dado que os quadros são recebidos completamente antes do seu reenvio, pode fazer-
se uma verificação da integridade dos quadros, descartando-os se estes tiverem qualquer erro.
Este modo de funcionamento tem que ser usado em redes com segmentos a débitos diferentes
(por exemplo, Ethernet a 10 e a 100 Mbps), dado que é necessário receber integralmente um
quadro antes de o poder começar a retransmitir a um débito mais elevado. Os switches que
detectam automaticamente a velocidade de transmissão são designados por auto-sensing.
25
Virtual Local Area Networks (VLANs)
Vários switches disponíveis no mercado possibilitam o estabelecimento VLANs [3] [17].
Utilizando o conceito de VLAN, é possível a definição de vários grupos de dispositivos que
comunicam exclusivamente entre si, constituindo redes virtuais distintas, com isolamento de
tráfego Unicast e Broadcast (será explicado mais à frente), existindo essas redes dentro da
mesma rede física. As máquinas pertencentes a uma dada VLAN não necessitam de estar
todas ligadas ao mesmo comutador, podendo abranger diversos comutadores espalhados pela
rede. A figura 20 ilustra o conceito de VLAN.
Figura 20: Exemplo de configuração de VLANs numa LAN (fonte [3]). Para além do isolamento de tráfego entre partes da rede - partes essas que não precisam de
estar geograficamente concentradas sob um mesmo equipamento, como no caso das bridges,
havendo uma grande flexibilidade na localização dos equipamentos que integram uma dada
VLAN. Ao definir uma VLAN, os seus utilizadores ficam limitados à comunicação com
dispositivos da mesma rede virtual, a menos que o tráfego passe por um router (que facilmente
poderá ser configurado para impedir o acesso dos utilizadores de uma sub-rede a recursos de
outra).
O isolamento e controlo do tráfego também podem ser encarado como uma desvantagem.
Sempre que é necessária a interacção entre máquinas de VLANs diferentes, o tráfego tem que
passar por um router (apesar de os dispositivos estarem na mesma LAN física), o que
representa uma degradação de desempenho.
Para além deste facto negativo, é ainda de referir que a configuração e manutenção de VLANs
exige um nível de conhecimento elevado para gestão do equipamento, nem sempre disponível
em pequenas e médias organizações.
26
4.3.5. Routers A interligação de redes de diferentes tecnologias e de diferentes âmbitos - por exemplo, LANs,
Metropolitam Area Network (MAN), Wide Area Network (WAN) - é feita com recurso a
equipamentos denominados routers. Os routers permitem a interligação de redes distintas e
totalmente autónomas, fazendo o routing e a comutação dos pacotes entre as sub-redes às
quais estão directamente ligados. A figura 21 ilustra um cenário de interligação de redes com
recurso a routers.
Figura 21: Cenário de interligação de redes de diferentes tecnologias e âmbitos (fonte [3]). Dado que a interligação de redes pertencentes a organizações/operadores distintos é feita, em
regra, com recurso a dispositivos deste tipo, os routers são frequentemente designados
gateways. No entanto, esta designação é tecnicamente incorrecta, dado que os gateways
operam acima da camada de Internet (fazendo a conversão entre diferentes protocolos e
ambientes aplicacionais), enquanto que os routers operam na camada de Internet, tal como
ilustrado na figura 22.
A operação a este nível protocolar é necessária, dado que é na camada de Internet que se
situam as funções de endereçamento universal (identificação única das sub-redes e dos
sistemas terminais na rede global) e de encaminhamento entre quaisquer sub-redes.
Sendo equipamentos para interligação de redes distintas, os routers têm, normalmente,
capacidade para interligar redes de diferentes tecnologias para ambientes LAN, MAN e WAN.
Assim, é possível encontrar no mercado equipamentos com portos/interfaces/módulos para
redes Ethernet (nas suas variantes), Token Ring, FDDI, DQDB, Frame Relay, ISDN, ATM ou
outras.
Para além do suporte de diferentes tecnologias, é frequente os routers suportarem protocolos
de diferentes arquitecturas. Esse suporte é desejável, pois é frequente que as redes
interligadas sejam utilizadas por uma variedade de ambientes aplicacionais baseados em
diferentes conjuntos protocolares. Como exemplo de protocolos vulgarmente suportados
27
referem-se os protocolos IP (arquitectura TCP/IP), IPX (arquitectura Novell NetWare), CLNP
(arquitectura OSI da ISO), X.25 (arquitectura OSI da ISO) e outras.
Figura 22: Posicionamento funcional dos routers face à arquitectura TCP/IP (fonte [3]). Mais recentemente, apareceram no mercado equipamentos que combinam a funcionalidade de
switches e de routers, designados switch routers ou layer 3 switches. Um switch router
combina as vantagens de um switch comutação extremamente rápida, por hardware, com base
em endereços MAC, com possibilidade de estabelecimento de VLANs - como as de um router-
funcionamento na camada de Internet , possibilidade de interligar redes distintas (por exemplo
VLANs), capacidade de suporte de múltiplos protocolos.
28
5. Tempo Real e IEEE 802.3 Ethernet Os argumentos contra a tecnologia IEEE 802.3 Ethernet em ambientes com requisitos de
tempo real, nomeadamente ambientes industriais, estão a desaparecer[11]. Hoje em dia esta
tecnologia tem condições para que a sua implementação em ambientes industrias se torne
muito forte. Isto porque está dotada de mecanismo que permitam determinar qual o pior tempo
para entrega de uma mensagem e também porque apresenta taxas de transferência muito
satisfatórias.
Quando existe um meio que é partilhado, os dispositivos têm que competir para aceder ao
meio, que para esta tecnologia é o CSMA/CD. A utilização de switch Ethernet com full duplex
evita esta necessidade de competição, porque cada dispositivo tem uma ligação própria para
enviar e outra para receber directamente do switch. Além de eliminar a necessidade de
competição de acesso ao meio evita as colisões pelos mesmos motivos.
O switch conhece os endereços dos dispositivos que estão conectados as suas portas e
entrega somente ao destinatário, ao contrário dos hubs que entregam a todos os dispositivos.
Desta forma é possível tratar várias conexões em “simultâneo”. No entanto, o que acontece se
ao mesmo tempo forem enviados várias mensagens para o mesmo dispositivo? Estas são
armazenadas na fila da porta pelo switch e serão enviadas assim que possível. Isto traz alguns
problemas em relação aos requisitos de tempo real. O standard IEEE 802.1p introduziu
melhoramentos nas características das filas dentro dos switches. Nomeadamente a
possibilidade de atribuir prioridades às mensagens, o que permite um tratamento idêntico ao do
escalonamento de tarefas num sistema computacional.
5.1. O tráfego Para perceber melhor as características necessárias da infra-estrutura de rede para ambientes
industriais é preciso caracterizar o seu tráfego [5]. O tráfego gerado durante a configuração,
programação e diagnóstico dos dispositivos assim como o tráfego de aplicações
convencionais, sem requisitos de tempo real, é baixo o que tem um pequeno impacto no
desempenho da rede. Pelo contrário o tráfego com características de tempo real é gerado a
uma taxa de dezenas de milhares de pacotes por segundo, dependendo do número de
dispositivos e de aplicações. Alguns dispositivos geram mais de 5000 pacotes por segundo. O
tamanho dos pacotes é tipicamente inferior a 100 bytes. Além destas características importa
realçar que este tráfego é gerado com uma base contínua, ao contrário de outros ambientes
em que existem oscilações de tráfego.
O envio dos pacotes pode ser feito por Broadcast, Multicast ou Unicast. Um pacote enviado
usando a tecnologia Broadcast, todos os dispositivos ligados na rede recebem o pacote. Se for
por Multicast, só determinados dispositivos é que o recebem. Com Unicast só um é que o
recebe.
O tráfego em ambientes com requisitos de tempo real é essencialmente Multicast ou Unicast.
Um switch layer 2 normalmente retransmite os pacotes Broadcast, Multicast ou Unicast com
endereço desconhecido por todas as portas. No exemplo da figura 23 o tráfego Multicast
29
produzido pelo dispositivo I/O11 para o Controller 1 será enviado a todos os dispositivos
conectados ao switch.
Figura 23: Configuração de uma rede com uma única VLAN(fonte [5]).
A utilização de recursos que permitam eliminar o tráfego indesejado terá grande impacto no
desempenho da rede. Por exemplo a utilização de switches que suportem VLANs e Multicast. A
figura 24 apresenta uma configuração com duas VLAN’s. A VLAN 1 é composta pelas portas
1,3,4,5 e 6 e a VLAN 2 pelas portas 2,7 e 8.
Figura 24: Configuração de uma rede com duas VLANs (fonte [5]).
Desta forma o tráfego Multicast enviado só será retransmitido para dentro da respectiva VLAN.
Com as VLANs pode-se fazer divisões lógicas da rede para obter um melhor desempenho. Por
exemplo separar os dispositivos com necessidades de tempo real dos outros.
A figura 25 apresenta uma configuração hierárquica. A VLAN está configurada no switch layer
3 e consiste nos três switch layer 2. Se estes não suportarem a tecnologia Multicast então os
pacotes Multicast gerados são enviados a todos dispositivos da VLAN.
30
Figura 25: Exemplo de Routing Multicast (fonte [5]).
Se os switches layer 2 suportarem Internet Group Management Protocol (IGMP) isto pode ser
eliminado. Com o IGMP é possível criar grupos dentro das VLANs. E desta forma eliminar
tráfego indesejado. Por exemplo, se o Controller B enviar um pacote Multicast ao Controller C,
o tráfego fica confinado ao switch layer 2 ao qual estão ligados.
5.2. IEEE 802.3 Ethernet e a Ethernet/IP A tecnologia Ethernet IEEE 802.3 está fortemente implantada, mesmo nos ambientes
industriais, embora como suporte essencialmente a aplicações sem requisitos de tempo real.
Embora ainda existam alguns aspectos a ter em conta que o estado actual desta tecnologia
não contempla. Os ambientes industriais são muito exigentes. Será necessário seleccionar
cuidadosamente os componentes electrónicos e definir o layout que permite resistir às gamas
de temperatura necessárias, imunidade ao ruído e ao mesmo tempo garantir a especificação
eléctrica da Ethernet .
Não existirão grandes dúvidas de que é possível a utilização da tecnologia Ethernet em
ambientes industriais, isto é, ambientes cujas as aplicações têm requisitos de tempo real. È
neste contexto que está a surgir um novo protocolo o Ethernet/IP (Ethernet / Industrial
Protocol). A figura 26 apresenta a arquitectura Ethernet/IP relacionando-a com a arquitectura
TCP/IP.
31
Figura 26: Arquitectura Ethernet/IP(fonte [5]).
É sobre esta arquitectura que incidirão os próximos capítulos. No capítulo 6 será abordado o
Control Information Protocol(CIP). O capítulo 7 descreve o modelo de rede associado a esta
arquitectura: o modelo Produtor/Consumidor. No capítulo 8 será abordado o Ethernet/Industrial
Protocol (Ethernet/IP).
32
6. Control Information Protocol (CIP)
6.1. Introdução O CIP (Control Information Protocol) [1] é um protocolo muito versátil, que foi projectado com a
automação industrial em mente. Porém, devido à sua natureza muito aberta, pode ser aplicado
a muitas mais áreas.
Este protocolo é orientado a objectos e permite estabelecer ligações entre dispositivos
industriais (sensores, actuadores, controladores, Programable Logicals Controllers(PLCs),e
etc.). Também é independente do meio físico.
6.2. Modelo de objectos Um objecto é uma representação abstracta de um componente constituinte de um produto.
Têm atributos, fornecem serviços e implementam comportamentos. Interessa distinguir os
objectos de comunicação e de aplicação. Os de comunicação são aqueles que permitem em
run-time a troca de mensagens. Os de aplicação referem-se aos objectos que implementam as
características específicas dos produtos. Um conjunto de objectos em que todos representam o
mesmo tipo de componente designa-se por classe. Uma classe é uma generalização de um ou
vários objectos. As Instâncias são ocorrências (físicas) de um objecto. As instâncias de uma
determinada classe têm os mesmos serviços, comportamentos e atributos, mas os valores
destes podem ser diferentes. Os atributos permitem caracterizar um objecto, geralmente
fornecem informação de estado (status) ou auxiliam os serviços e comportamentos que o
objecto fornece ou implementa. Os Comportamentos são uma especificação de como um
objecto actua mediante um determinado evento. Os Serviços são funcionalidades suportadas
por um determinado objecto. O CIP define um conjunto de serviços básicos.
6.3. Estrutura do sistema
6.3.1. Topologia A estrutura do sistema modelizável em CIP obedece ao seguinte esquema:
o System = { Domain (s) } - Sistema contem um ou mais domínios;
o Domain = { Network (s) } - Um domínio é uma colecção de uma ou mais redes. Um
domínio pode conter redes dos mais variados tipos;
o Network = { Subnet (s) } -Uma rede é uma colecção de uma ou mais sub-redes;
o Subnet = { Nodes (s) } - Uma sub-rede é uma colecção de nós. Uma sub-rede pode
ter múltiplos segmentos físicos e pode conter repetidores;
o Segment = { Nodes (s) } - Um segmento é uma colecção de nós ligados a uma secção
ininterrupta do meio físico;
o Node = { Object (s) } - Um nó é uma colecção de objectos. Um dispositivo pode conter
um ou mais nós.
Um exemplo de um sistema de redes encontra-se ilustrado na figura 27. Nesta é possível ver
representados os vários componentes de uma rede.
33
Figura 27: Estrutura de rede – topologia (fonte [1]).
6.3.2. Lógica A estrutura lógica de um sistema modelizável em CIP é composta pelos Clusters, cuja definição
se apresenta a seguir:
o Cluster = { Node(s) } - um Cluster é uma colecção de nós que estão logicamente
ligados. Um nó pode pertencer a um ou mais Cluster. Um Cluster pode “atravessar”
subredes, redes ou dominios.
A figura 28 exemplifica várias configurações de Clusters.
Figura 28: Estrutura de rede – lógica(fonte [1]).
6.4. Endereçamento Os objectos e os seus componentes são endereçáveis por um esquema uniforme de
endereçamento. Desse esquema de endereçamento fazem parte o Media Access Control
Identifier (MAC ID) que é um número inteiro que identifica cada nó na rede CIP. O Class
Identifier (Class ID) é um número inteiro associado a cada classe acessível da rede. O Instance
Identifier (Instance ID) é um número inteiro que identifica uma instância entre todas da mesma
classe. Caso seja necessário, também se pode identificar a classe com este identificador, para
34
tal usamos o zero. O CIP reserva o zero para nos referirmos à classe de uma determinada
instância. O Atribute Identifier (Attribute ID) é um número inteiro que identifica um atributo
dentro de uma classe ou instância. O Service Code é um número inteiro que identifica uma
função (ou métodos) de uma classe ou instância.
A figura 29 exemplifica como os vários componentes são endereçáveis.
Figura 29: Exemplo de endereçamento de um objecto(fonte [1]).
6.5. Os identificadores Existem regras para a atribuição de identificadores. As condições seguintes são usadas para
definir as gamas de identificadores:
o Open - refere-se a uma gama de valores cujo o significado é definido por Open
DeviceNet Vendor Association / Controlnet International (ODVA/CI) [1] e são comuns a
todos os objectos;
o Específicos do fabricantes - gama de valores especificas para os fabricantes dos
dispositivos;
o Específicos dos objectos - gama de valores cujo o significado é definido pela classe
do objecto.
A título de exemplo apresenta-se uma tabela que define os intervalos de valores aplicáveis aos
Class IDs.
Intervalo Significado 00-63hex CIP 64-C7hex Fabricantes C8-FFhex Reservado para ODVA/CI para uso futuro F0-2FFhex CIP 300-4FFhex Fabricantes 500-FFFFhex Reservado para ODVA/CI para uso futuro
Tabela 7: Intervalos de valores aplicáveis aos Class ID(fonte [1]).
35
6.6. Rede CIP O CIP define um esquema para facilitar a comunicação entre todas as aplicações. A base
deste esquema são os objectos de comunicação. Estes objectos representam as conexões. As
conexões são identificadas pelo Connection ID (CID). Os objectos de conexão estabelecem
uma relação end – to – end. São dois os tipos de conexão possíveis. As I/O Connections e as
Explicit Messaging Connections.
6.6.1. I/O Connections As I/O Connections permitem a comunicação entre a aplicação produtora e uma ou mais
aplicações consumidoras. No capítulo 7 o modelo Produtor/Consumidor utilizado no CIP irá ser
especialmente focado. As mensagens enviadas através de uma I/O Connections designam-se
de I/O Messages, geralmente designadas de mensagens implícitas. Uma mensagem implícita
consiste num CID mais os dados associados. O significado dos dados dentro da mensagem
implícita é “explicitado” pelo CID. É assumido que os end – point têm conhecimento do que se
pretende ou do significado da mensagem. Um end – point representa o destinatário final de
uma mensagem. A figura 30 apresenta uma I/O Connection.
Figura 30: I/O Connection(fonte [1]).
6.6.2. Explicit Messaging Connections As Explicit Messaging Connections permitem estabelecer uma comunicação entre dois
dispositivos. As mensagens enviadas através das Explicit Messaging Connections designam-se
Explicit Messages, geralmente designadas de mensagens explícitas. As mensagens explícitas
são usadas para executar comandos, tarefas, ou para informar dos resultados da execução de
uma tarefa. Estas fornecem os meios necessários para executar um típico pedido/resposta,
bastante utilizados na configuração de módulos e outros. Uma mensagem explícita consiste
numa CID e na informação associada à mensagem. A figura 31 exemplifica uma Explicit
Messaging Connection.
36
Figura 31: Explicit Messaging Connections (fonte [1]).
6.7. Modelo de Objectos de um produto CIP A figura 32 ilustra o modelo de objecto de um produto CIP.
Figura 32: Modelo de objectos de um produto CIP(fonte [1]).
37
Este modelo é constituído pelos seguintes componentes:
o UnConnected Message Manager (UCMM) - Processa as mensagens sem conexão;
o Connection Class – Aloca e administra recursos internos associados com as I/O
Connections e com as Explicit Messaging Connections;
o Connection Object – Administra os aspectos associados às comunicações, sobretudo
na relação aplicação – a – aplicação;
o Message Router – Distribuição das mensagens pelos objectos;
o Application object – Implementam os dispositivos ou produtos.
6.8. Protocolo para envio de mensagens O CIP possibilita ligações entre múltiplas aplicações. Quando uma conexão é estabelecida, as
transmissões associadas com esta conexão são identificadas com o Connection ID (CID). Se a
conexão envolve trocas bi-direcionais, então são associados dois CID (figura 33).
Figura 33: Conexões e Connections IDs(fonte [1]).
6.8.1. Estabelecimento de uma conexão O UCMM é responsável por processar pedidos e respostas sem conexão. Isto inclui o
estabelecimento de Explicit Messaging e I/O Connections . A rede subjacente define como o
UCMM é acedido e pode limitar o tráfego que pode ocorrer através do UCMM.
Explicit Messaging Connection
Quando o UCMM é usado para estabelecer uma ligação explícita, o objecto usado é o
Message Router. A figura 34 ilustra os passos necessários para estabelecer uma Explicit
Messaging Connection.
As Explicit Messaging Connections são incondicionalmente ponto-a-ponto. As ligações a ponto-
a-ponto existem somente entre dois dispositivos. O dispositivo que faz o pedido para que a
conexão seja estabelecida (Requester) é uma aplicação, o módulo que recebe e responde ao
pedido (Responder) é outra aplicação.
38
Figura 34: Estabelecimento de uma Explicit Messaging Connections(fonte [1]).
I/O Connections
Em relação ás I/O Connections o CIP não determina qualquer regra em relação a quem pode
efectuar a configuração destas. Pode ser feito através do UCMM ou de outra forma, como por
exemplo, com uma ferramenta, um computador, poder-se-á ligar dois dispositivos e
criar/configurar uma I/O Connection. Estas conexões também se podem fazer por processos
dinâmicos. A figura 35 ilustra a criação e configuração de uma I/O Connection.
Cada conexão CIP é representada por um Connection Object. A criação desta conexão pode
ser feita de duas formas. Cada sub-rede define qual o método que deve ser usado. Os dois
métodos possíveis são:
o Usar o serviço Create do Connection Object;
o Usar o serviço Forward Open do Connection Manager Object.
Quando a sub-rede define que a conexão é criada através do Connection Object, o dispositivo
CIP deve suportar o serviço Create dessa classe. O serviço Create cria uma instância desse
com os valores por omissão dos atributos. Esta é configurada para acessos individuais a cada
atributo. Para que a conexão passe ao estado de estabelecida é necessário requerer um
serviço.
Quando a sub-rede define que a conexão é criada por Connection Manager Object, o
dispositivo CIP deve suportar o serviço Forward Open desta classe. Se isto acontecer, o
Connection Manager cria uma instância da classe Connection Object. Esta instância é
39
configurada com os valores enviados no serviço Forward Open e a conexão passa ao estado
de estabelecida.
Figura 35: Criação e configuração de uma I/O Connection(fonte [1]).
Cada instância da classe Connection Object contém um Link Producer Object (LPO) ou Link
Consumer Object (LPC) ou ambos. Isto porque as I/O Connections podem conter só um,
enquanto que as Explicit Messaging Connections contêm sempre os dois.
O Link Producer Object é o componente respons ável pela transmissão dos dados, o Link
Consumer Object é responsável pela recepção dos dados.
Figura 36: Connection Object(fonte [1]).
Além do LPO e LPC existem outros atributos que definem o estado da conexão e quais as
acções que podem acontecer. Em particular como são activadas as mensagens (da aplicação,
por mudança de estado ou de mudança de dados, por eventos cíclicos, ou através de eventos
de rede) e o timing das conexões (acções definidas quando o timeout associada a uma
40
determinada conexão ou evento termina). O CIP permite múltiplas conexões em simultâneo
sobre o mesmo dispositivo.
6.8.2. Acesso aos dados do objecto Na definição de uma classe deve ser indicado como os dados da classe são acedidos
externamente. Como já foi referido existem dois tipos de conexões as I/O e Explicit Messaging
Connections. Esta secção fornece uma visão de como estes tipos de conexões relacionam-se
com os objectos das aplicações e como podem ser usadas para aceder aos dados dos
objectos da classe. A figura 37 ilustra como é feita a interacção entre Application Objects e
Connections Class (Connections Path).
Figura 37: Connections Path(fonte [1]).
Acesso por Explicit Messaging Connection
As mensagens explícitas podem ser usadas para vários serviços, incluindo para escrever e ler
os atributos dos objectos. Quando uma Explicit Messaging Connection recebe uma mensagem
explícita entrega-a ao Message Router. O Message Router, por sua vez, entrega-a ao handler
apropriado. No caso de ser um pedido, o handler é o objecto especificado como destino nesse
pedido. No caso de uma resposta, o handler é o objecto que previamente emitiu o respectivo
pedido.
41
Acesso por I/O Connection
As I/O Connections contêm atributos que apontam (point to) ou referenciam os objectos aos
quais tem que entregar ou receber dados.
Figura 38: Acesso aos objectos por I/O Connections(fonte [1]).
Os Application Objects podem ser directamente referenciadas por uma I/O Connection. Isto é
ilustrado na figura 38 pela I/O Connection 1. Neste exemplo, o Attribute #3 dentro do
Application Object Class#8/Instance#2 é directamente acedida por uma I/O Connection. Se
esta referência fosse feita pelo atributo produced_connection_path da I/O Connection, então o
Attribute#3 seria a informação produzida pelo I/O Connection 1. Se esta referência fosse feita
pelo atributo consumed_connection_path do I/O Connection 1, então o Attribute#3 seria o
buffer para colocar os dados consumidos pelo I/O Connection.
É possível aceder a múltiplos atributos com uma I/O Connection. Isto é realizado usando um
Application Object especial, chamado de Assembly Object.
Como é que o Assembly Object funciona:
o Na emissão, junta partes separadas de classes, Instâncias ou atributos e assim podem
ser tratadas por uma I/O Connection.
42
o Na recepção, recebe os dados de uma I/O Connection que estão associados a classes,
a instancias e/ou atributos separados e distribuiu-os adequadamente.
Os Assembly Object permitem aceder a vários dados ao mesmo tempo. A I/O Connection 2 usa
um Assembly que agrupa os Atributos Attribute#1 e Attribute#2 da Class#8 Instance#2, assim
eles podem ser acedidos por uma I/O Connection. Um Assembly Object é capaz de referenciar
elementos, dentro de mais do que uma classe.
6.8.3. Comportamento das I/O Connections A figura 39 ilustra o comportamento associado a uma I/O Connection.
Figura 39: Diagrama de transições de uma I/O Connection (fonte [1]).
A tabela 8 apresenta uma breve descrição do comportamento de uma instância de uma I/O
Connection:
Estado
Evento Non-Existent Configuring
Waiting for Connection
ID Established Timed Out
Create Request
Instancia um Objecto
Não Aplicável Não Aplicável Não Aplicável Não Aplicável
Delete Request
Erro:Objecto não existe
Liberta todos os recursos e passa ao estado de Non-Existent
Liberta todos os recursos e passa ao estado de Non-Existent
Liberta todos os recursos e passa ao estado de Non-Existent
Liberta todos os recursos e passa ao estado de Non-Existent
Set_Attribute_Single
Erro:Objecto não existe
Valida o pedido baseado na lógica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
43
Get_Attribute_Single
Erro:Objecto não existe
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Reset Erro:Objecto não existe
Retorna erro, não pode executar neste modo
Retorna erro, não pode executar neste modo
Cancela o corrente Inactivity/Watchdog
Passa ao estado de Established
Apply_Atributes
Erro:Objecto não existe
Atribui os valores aos respectvos atributos
Se qualquer dos atributos do connection_id necessita de ser configurado e não pode ser por este modúlo então retorna sucesso e espera. O facto de não poder gerar o o valor do ID não é considerado erro.
Retorna erro, não pode executar neste modo
Retorna erro, não pode executar neste modo
Receive_Data
Não Aplicável Descarta a mensagem
Descarta a mensagem
Recebe os dados
Descarta a mensagem
Send_Message
Não Aplicável Retorna erro-não envia a mensagem
Retorna erro-não envia a mensagem
Transmite a mensagem
Retorna erro-não envia a mensagem
Inactivity/Watchdog
Não Aplicável Não Aplicável Não Aplicável Examina o atributo watchdog_timeout_action e executa a acção
Não Aplicável
Tabela 8: Relação eventos / estado de I/O Connection.
6.8.4. Comportamento das Explicit Messaging Connection A figura 39 ilustra o comportamento associado a uma Explicit Messaging Connection.
44
Figura 40: Diagrama de transições de estado de uma instância de um objecto Explicit Messaging Connection
(fonte [1]).
A tabela 9 apresenta uma breve descrição do comportamento de uma instância de uma Explicit
Messaging Connection:
Estado
Evento Non-
Existent Configuring Deferred Delete
O UCMM recebe um Open Explicit Messaging Connection Request/Response e invoca o serviço Create do Connection Class
Instancia um Objecto
Não Aplicável Não Aplicável
O UCMM recebe um Close Request e invoca o serviço Delete do Connection Class
Erro:Objecto não existe
Liberta os recursos e passa ao estado de Non-Existent
Liberta os recursos e passa ao estado de Non-Existent
O Connection Class recebe Delete Request
Erro:Objecto não existe
Liberta os recursos e passa ao estado de Non-Existent
Liberta os recursos e passa ao estado de Non-Existent
Set_Atribute_Single Erro:Objecto não existe
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Get_Atribute_Single Erro:Objecto não existe
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Valida o pedido baseado na logica de acesso aos dados e retorna a resposta
Reset Erro:Objecto não existe
Cancela o corrente Inactivity/Watchdog Timer
Reinicializa o Inactivity/Watchdog Timer
45
Apply_Attributes Erro:Objecto não existe
Erro:Serviço não suportado
Erro:Serviço não suportado
Receive_Data Não Aplicável
Se mensagem válida então faz reajusta Inactivity/Watchdog Timer
Se mensagem válida então faz reinicializa Inactivity/Watchdog Timer
Send_Message Não Aplicável
Examina o tamanho da mensagem e se necessário fragmenta e envia os fragmentos, senão envia a mensagem completa
Examina o tamanho da mensagem e se necessário fragmenta e envia os fragmentos, senão envia a mensagem completa
Figura 41: Relação eventos / estado de Explicit Messaging Connection.
46
7. Modelo de rede Produtor/Consumidor
7.1. Introdução Cada vez mais os utilizadores exigem mais dos sistemas computacionais e por conseguinte
das redes que os suportam [14]. Querem tempos e custos baixos na manutenção e instalação,
e ao mesmo tempo melhor e mais processamento. Com as funcionalidades das aplicações
aumentadas, geralmente, significa mais tráfico sobre a rede.
Infelizmente, as discussões acerca das redes, tem focado essencialmente o bit rate e
eficiência dos protocolos. O bit rate é muitas vezes usado como medida de desempenho de
uma rede. Hoje em dia dadas as taxas de transferência praticadas não é um determinante.
A Eficiência dos protocolos, os bytes de dados (payload) versus o total de bytes no pacote –
tipicamente expresso como percentagem é a medida de overhead do protocolo de rede.
Obviamente que estes aspectos são importantes numa rede, mas o mais importante é o
método de envio das mensagens, isto é, o modelo de rede.
Nos ambientes industriais, as redes têm que ter capacidade para permitir o controlo, a
configuração e monitorização do sistema de uma forma eficiente. Para haver controlo entre
outros aspectos, é necessário que as mensagens sejam entregues em tempo útil, a todos os
dispositivos que dela precisam. Por outro lado por vezes é necessário que essas mensagens
sejam entregues ao mesmo tempo a vários dispositivos. As redes têm que permitir a
configuração dos dispositivos, que geralmente é feita através de operações de upload e
download. A monitorização é fundamental em ambientes industriais, isto é, é importante saber
qual o estado do sistema num determinado instante e ser alertado em tempo útil. Além da
capacidade de alertar para eventuais falhas, é imperativo que quando estas acontecem o resto
do sistema continue em funcionamento.
7.2. O modelo de rede Origem/Destino O modelo de rede Origem/Destino já existe há muitos anos e tem várias implementações. Uma
delas é a implementação Master/Slave. Nesta implementação os masters são a única origem
de dados e todas as respostas dos slaves são para os respectivos masters . Este esquema
consiste, essencialmente, numa ligação entre dois dispositivos para troca de informação de
controlo. Portanto são limitadas aquelas função. As implementações Peer – to – Peer,
geralmente, vão mais além da implementação Master/Slave, permitindo maior flexibilidade.
Além do controlo permitem também a configuração e programação dos dispositivos. Estas
implementações são do tipo Token-passing. Isto é, para enviar uma mensagem é necessário
possuir um token, ora isso pode ser problemático devido essencialmente a administração do
token. O modelo de rede Origem/Destino desperdiça largura de banda quando pretende enviar
o mesmo conjunto de dados para muitos nós diferentes, uma vez que tem de enviar para todos
individualmente. Além disso, enviar dados para vários dispositivos de forma sincronizada é
47
bastante complicado e difícil. Necessariamente a informação vai chegar com tempos diferentes
a cada dispositivo.
As mensagens associadas a este modelo caracterizam-se essencialmente por indicarem a
Source e o Destination (figura 42).
Figura 42: Mensagem típica do modelo Origem/Destino(fonte [14]).
7.3. O novo paradigma O novo paradigma é o modelo Produtor/Consumidor. Neste modelo as mensagens são
identificadas pelo conteúdo, através de um identifier (figura 43) e enviadas usando o Multicast.
Figura 43: Mensagem típica do modelo Produtor/Consumidor(fonte [14]).
As mensagens usadas são de dois tipos: explícitas e implícitas. As mensagens explícitas são
usadas para configuração e monitorização dos dispositivos. Por exemplo, são usadas para
fazer upload e download de programas, executar comandos, fazer logs e funções de
diagnóstico. Para tal os nós devem interpretar cada mensagem executar a tarefa pedida e
gerar a resposta. Isto é possível porque estas mensagens explícitas usam uma estrutura de
dados muito flexível.
As mensagens implícitas por outro lado, são implícitas por natureza. Isto é, o significado de
cada mensagem está predefinido e geralmente são pequenas. Isto faz com que o tempo de
processamento no nó seja baixo. Daí serem usadas essencialmente para aplicações de tempo
real porque provocam pouco overhead e mudam frequentemente.
Como já foi referido as mensagens são identificadas pelo conteúdo e são enviadas usando o
Multicast. Desta forma consegue-se enviar uma mensagem que pode ser consumida por vários
nós ao mesmo tempo. Por outro lado consegue-se obter sincronismo de uma forma mais
precisa. Tudo isto é conseguido com um melhor aproveitamento da largura de banda usada. A
origem só tem que produzir os dados uma vez. Por outro lado pode produzir mais do que um
conjunto de dados, cada um usando um identificador único.
O modelo Produtor/Consumidor tem dois mecanismos I/O Triggers mais eficientes: mudança
de estado e produção cíclica de dados de input e output.
Na mudança de estado, só há produção de dados (envio de mensagens) quando os dados
forem alterados. Quando isso acontecer os dados são entregues a todos os consumidores.
Portanto não há nenhum evento cíclico temporizado para envio de mensagens e desta forma
pode reduzir drasticamente o tráfego na rede.
48
A produção cíclica de dados é feita a uma determinada taxa definida não pela rede mas pelos
nós ou aplicações que sobre essa rede actuam. Isto é, os dados são alterados a uma taxa
apropriada para os nós ou para as aplicações.
O modelo Produtor/Consumidor não significa a morte do modelo Origem/Destino. Apesar de
limitado já existe a alguns anos e irá, certamente, continuar. É um modelo bastante satisfatório
para ambientes que não tenham requisitos muito complexos de coordenação, sincronização e
partilha de dados.
49
8. Ethernet/Industrial Protocol (Ethernet/IP)
8.1. Introdução Ethernet/Industrial Protocol (Ethernet/IP) [1] utiliza o modelo CIP, o modelo
Produtor/Consumidor, a arquitectura TCP/IP e o IEEE 802.3 Ethernet . É um sistema de
comunicação satisfatório para ambientes industriais e Sistemas de Tempo Real. Pois permite a
troca de informação entre dispositivos industriais cumprindo os requisitos necessários para
aplicações de tempo real. Estes dispositivos tanto podem ser simples, como dispositivos de
Input e Output, como também complexos, tais como robots, PLCs, soldadores, controladores
de processos, PCs e etc.
O modelo base para a troca de informação é o modelo Produtor/Consumidor, descrito no
capítulo 7. Este modelo define duas entidades: o produtor, emissor da mensagem; e o
consumidor, receptor da mensagem. Este modelo usa a tecnologia Multicast para o envio de
uma mensagem para vários consumidores em simultâneo. As mensagens são identificadas
pelo conteúdo. Se uma mensagem é recebida por um determinado nó que precisa desses
dados consome-os. Desta forma é possível alcançar um sincronismo mais preciso e um melhor
aproveitamento da largura de banda disponível.
Este protocolo utiliza o standard Ethernet (IEEE 802.3) e não é introduzida nenhuma
funcionalidade extra para melhorar o desempenho. Antes pelo contrário, é recomendado o uso
desta tecnologia a 100 Mbps, full duplex e topologia hierárquica em estrela baseada em switch.
Além da tecnologia IEEE 802.3, este protocolo usa a arquitectura protocolar TCP/IP e o
protocolo designado Control Information Protocol (CIP). A figura 44 apresenta a arquitectura
Ethernet/IP relacionando com a arquitectura TCP/IP.
50
Figura 44: Arquitectura TCP/IP e a Ethernet/IP(fonte [1]).
8.2. Protocolo de Encapsulamento Esta secção descreve qual o protocolo usado para o encapsulamento das mensagens do CIP
numa rede TCP/IP.
8.2.1. Uso do TCP e UDP O protocolo de encapsulamento define um número de porto TCP e UDP que deve ser
suportada por todos os dispositivos Ethernet/IP. Todos os dispositivos Ethernet/IP devem
aceitar pelo menos duas conexões TCP pelo porto 0xAF12 (44818) e aceitar pacotes UDP pelo
porto 0xAF12 (44818). O UDP, ao contrário do TCP, não consegue reordenar pacotes, logo a
mensagem tem que ser toda incluída num único pacote UDP.
8.2.2. Encapsulamento de mensagens Todas as mensagens enviadas pelo porto 0xAF12 via TCP ou UDP, devem ser compostas de
um cabeçalho de 24 bytes seguido de um campo opcional. O comprimento máximo da
mensagem (incluindo o cabeçalho) é limitado a 65535 bytes.
A tabela 9 apresenta a estrutura encapsulamento de um pacote:
Estrutura Nome do Campo
Tipo de dados Descrição
Command UINT Comando
Length UINT Tamanho em bytes dos dados da mensagem, isto é, o numero de bytes a seguir ao cabeçalho.
Session handle UDINT Identificador da sessão
Status UDINT Código de estado
Sender Context ARRAY de octectos
Informação importante somente para o remetente da mensagem.
Cabeçalho
Options UDINT Opções
Dados Encapsulated data
ARRAY de 0 a 65511 USINT
Dados da mensagem
Tabela 9: Estrutura de encapsulamento de um pacote.
A ordenação dos bytes deve ser little-endian.
Embora o cabeçalho não contenha nenhuma informação explícita para distinguir entre um
pedido e uma resposta, estas informações serão determinadas da seguinte forma:
o implicitamente , pelo comando e pelo contexto em que mensagem é gerada;
o explicitamente, pelo conteúdo dos dados da mensagem.
A seguir apresenta-se uma breve descrição de alguns dos comandos que podem ser utilizados:
o NOP – quer o emissor quer o receptor podem enviar este comando. Nenhuma resposta
deve ser gerada;
51
o ListIdentity – o emissor da conexão pode usar este comando para localizar e
identificar potenciais receptores. Este comando deve ser enviado em broadcast usando
o UDP e não requer uma sessão;
o ListInterfaces – este comando deve ser usado pelo “originador” da conexão para
identificar pot enciais interfaces não CIP associadas com os receptores. Não é
necessário estabelecer uma sessão para enviar este comando;
o RegisterSession – “originador” da conexão deve enviar um comando RegisterSession
ao receptor para iniciar a sessão;
o UnRegisterSession – todos os intervenientes na conexão, origem e destino, podem
enviar este comando para terminar a sessão;
o ListServices – este comando deve determinar quais os serviços suportados pelo
dispositivo;
o SendRRData – este comando permite o envio de mensagens entre os dispositivos;
o SendUnitData – este comando pode ser usado quando o protocolo de
encapsulamento tiver o seu próprio mecanismo de transporte end-to-end subjacente.
Nenhuma resposta deve ser retornada. Este comando pode ser enviado por qualquer
dos intervenientes da conexão.
Os outros campos do cabeçalho:
o Length – este campo especifica o tamanho em bytes da parte de dados da mensagem;
o Session Handle – o Session Handle deve ser gerado pelo receptor e enviado ao
emissor como reposta ao pedido RegisterSession. O emissor deve-o inserir em todas
as mensagens enviadas ao receptor e vice-versa;
o Status – este campo indicará se o receptor está ou não capaz de executar o comando
enviado. Se o retorno for zero significa que a execução teve sucesso. Todos os
pedidos enviados pelo emissor deve ter este campo a zero. Se o receptor receber uma
mensagem com este campo com um valor diferente de zero deve ignora-lo e nenhuma
resposta deve ser gerada;
o Sender Context – o emissor deve colocar um valor neste campo. O receptor deve
retornar esse valor na resposta, sem alteração. Os comandos que não necessitem de
respostas podem ignorar este campo;
o Options – o emissor deve colocar neste campo o valor zero. O receptor deve verificar
se o valor deste campo é zero. Caso o valor seja diferente de zero o receptor deve
descartar esta mensagem.
Os dados propriamente ditos são encapsulados no campo:
o Encapsulated data – a estrutura deste campo depende do comando a executar. A
maioria dos comandos suporta ou um formato específico ou um formato comum ou
ambos.
52
8.2.3. Formato comum A tabela 10 apresenta o formato comum dos pacotes usado no encapsulamento de mensagens
obedece à seguinte estrutura:
Nome do Campo Tipo de dados Descrição Item Count UINT Numero de elementos (devem ser pelo
menos dois) Item Address Estrutura (ver tabela seguinte) Informação de endereçamento do
pacote. Item Data Estrutura (ver tabela seguinte) Dados encapsulados Campo opcional
Tabela 10: Formato comum dos pacotes de encapsulamento.
A tabela 11 mostra qual a estrutura dos campos Item Address e Item Data do formato comum
do pacote usado no encapsulamento de mensagens.
Nome do Campo Tipo de dados Descrição Type ID UINT Tipo do elemento encapsulado Length UINT Tamanho em bytes do campo de dados Data Variável
Tabela 11: Formato do campo Endereço e Dados do pacote comum.
8.2.4. Fases de uma sessão TCP Uma sessão deve ter três fases:
o Estabelecimento da sessão;
o Manutenção da sessão;
o Fecho da sessão.
Passos para o estabelecimento de uma sessão:
o O remetente deve abrir uma conexão TCP/IP com o destinatário, usando um porto
reservado TCP (0xAF12)
o O remetente deve enviar um comando RegisterSession ao destinatário;
o O destinatário deve verificar se suporta a mesma versão do protocolo que o remetente.
Se não deve retornar um comando RegisterSession com o valor correspondente à
versão mais alta do protocolo suportado no campo Status;
o O destinatário deve determinar um novo e único Session ID e deve-o enviar ao
remetente.
Uma vez estabelecida a conexão, esta permanecerá até que um dos seguintes factos ocorra:
o Um dos intervenientes termine a conexão;
o A conexão TCP seja interrompida por qualquer outro motivo.
Para terminar uma sessão, ou o destinatário ou o remetente podem fazê-lo. As sessões podem
ser fechadas de duas formas:
o Um dos intervenientes fecha a conexão TCP subjacente. Quando o outro detectar que
a conexão foi fechada deve também fechar a conexão;
53
o Um dos intervenientes envia um comando UnRegisterSession e espera que o outro
feche a conexão, quando detectar que o outro fechou conexão, fecha também (este
método é preferível).
8.3. Mapeamento das Explicit e I/O Messaging no TCP/IP Quando é necessário enviar um pacote de CIP através de uma rede de Ethernet-TCP/IP, o
pacote, será transmitido usando o protocolo de TCP/IP e o protocolo de encapsulamento dos
pacotes definido no capítulo anterior.
A tabela 12 apresenta o formato de um pacote de encapsulamento:
Estrutura Nome do campo Tipo de dados Command UINT Length UINT Session handle UDINT Status UDINT Sender Context ARRAY de 8 USHORT
Cabeçalho
Options UDINT Interface handle UINT Timeout UINT
Item Count UINT Address Type ID UINT Address length UINT
Endereço
Data Variável Data Type ID UINT Data lenght UINT
Dados
Data ARRAY
Dados
Formato comum de encapsulamento (descrito na secção 8.2.3)
Campo Opcional ARRAY of USINT
Tabela 12: Formato do pacote de encapsulamento de uma mensagens implícita ou explicita.
A parte que está sombreado refere-se ao encapsulamento das mensagens implícitas ou
explícitas do CIP. Referia-se que é possível encapsular mais do que uma mensagem para tal
basta indicar no campo Item Count o número de mensagens.
8.4. Visão geral do encapsulamento Nesta secção pretende-se dar uma visão mais geral de como é feito o encapsulamento das
mensagens desde um objecto CIP até à interface de rede. A figura 45 apresenta os passos
para o encapsulamento de uma mensagem. Ao longo do relatório são apresentados os
formatos de cada pacote de cada nível do protocolar.
55
9. Conclusões Uma arquitectura de comunicação para ambientes industriais deve fornecer 3 serviços básicos.
O primeiro e o mais importante é o controlo. Este serviço envolve a troca de informação entre
dispositivos, em tempo útil. De salientar que nestes ambientes os requisitos temporais são
muito restritos. O segundo é a configuração. A arquitectura deve fornecer mecanismos para
que se possa efectuar a configuração de uma forma rápida e eficiente. Por fim, deve fornecer
ferramentas que permitam monitorizar o estado do sistema num determinado instante. Ora o
protocolo Ethernet/IP tem todas estas características. Assenta numa estrutura de
comunicações que permite rapidez na transferência e essencialmente garantia de entrega das
mensagens. Desta forma o controlo está assegurado. O facto dos dispositivos serem
logicamente representados por objectos permite que as actividades de configuração sejam
relativamente fáceis e eficientes. Além disso, estes objectos têm atributos que reflectem o seu
estado e por conseguinte o estado do sistema, uma vez que o sistema está logicamente
representado pelos objectos. Este aspecto facilita a monitorização do sistema.
Além do protocolo Ethernet/IP, o DeviceNet e o ControlNet também fazem parte dos protocolos
que usam o CIP. Ao contrário destes a Ethernet/IP é um protocolo aberto. Além disso tem uma
associação muito forte com a arquitectura TCP/IP e IEEE 802.3 Ethernet . Esta associação tem
muitas vantagens: baixo custo dos equipamentos Ethernet; conhecimento da tecnologia
Ethernet por parte dos utilizadores; o TCP/IP é independente do sistema de comunicação
subjacente e é composto por vários protocolos, o que permite por um lado a integração de
outros serviços e por outro a coexistência entre aplicações de tempo real e aplicações
convencionais; as redes IP são escaláveis; universalidade, fornece a possibilidade de uma
forma segura misturar vários protocolos numa única linha de comunicação e a interligação
entre componentes de fabricantes diferentes; a segurança; e outros.
Apesar de ser recente, a especificação ainda está no início, já existe uma série de empresas,
como por exemplo a Cisco SystemsTM, RockwellAutomationTM, a LantronixTM e outras que têm
produtos que obedecem à especificação Ethernet/IP. Penso que num futuro relativamente
próximo esta tecnologia ira estar fortemente implantada nos ambientes industriais. No entanto,
existe ainda muito trabalho para realizar. E pretende-se com este trabalho, de estudo do
Ethernet/IP dar um passo importante para a obtenção de modelos que permitam a análise
holística (tem em atenção todos os subsistemas que compõem o sistema: rede, hosts, sistema
operativo, modelo de aplicações e outros) da performance (por exemplo, comportamento
temporal) da arquitectura Ethernet/IP. Esse é o objectivo do projecto INDEPTH no âmbito do
qual este trabalho foi efectuado. Isto é uma tarefa complexa, já que os modelos em causa são
muito mais complexos do que o modelo distribuído simplificado que foi apresentado na secção
2.7 do capítulo 2.
XI
Referências
[1] Especificação Ethernet/IP disponível em www.odva.org
[2] www.rockwellautomation.com.
[3] Engenharia de redes informáticas, Edmundo Monteiro, Fernando Boavida, ISBN 972-722-
203-X.
[4] Real-Time whit Ethernet , R. Messerschimdt, Otto-v. -Guerice-Universitat, Magdeburg,
Germany.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
[5] Utilization of Modern Switching Technology in Ethernet/IP Networks, A. Moldovansky,
Rockewell Automation, EUA.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
[6] Ethernet based Realtime for Automation Applications , M. Buchwitz, Jetter AG, Germany.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
[7] SBM protocol for providing real-time QoS in Ethernet LANs, A. Koubaa, A. Jarraya, Y.-
Q.Song, Loria, France.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
[8] Deadline First Scheduling in Switched Real-Time Ethernet – Deadline Partitioning Issues
and Software Implementation experiments, H. Hoang, M.Jonsson, A.Larsson, R. Olsson, C.
Bergenhem, Halmstad University, Sweden.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
[9] Designing, Modelling and Evaluating of Switched Ethernet Networks in Factory
Communications Systems, N. Krommenacker, J. P. Georges, E. Rondeau, T. Divoux, CRAN-
CNRS, France.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
XII
[10] Real Time on Ethernet using off-the self Hardware, J. Loser, H. Hartig, TU Dresden,
Germany.
Proceedings of the 2002 International Workshop on Real-Time LANs in the Internet Age,
ISBN 972-8688-06-7.
[11] Real Industrial Ethernet: Building Blocks for a Holistic Approach, Berta Batista, ISEP-IPP,
Portugal.
WFCS 2002 Work-in-Progress Proceedings ISRN MDH-MRTC—61—SE.
[12] www.real-time.org
[13] Real-time Control on Ethernet , By Bill Moss,Executive Director,ControlNet International.
Copyright 2000 by Dedicated Systems Magazine - 2000 Q2 (www.dedicated-systems.com)
[14]The Next Generation Networking Paradigm: Producer/Consumer Model, By Patricia A.
Murphy, Manager Emerging Technology and Standards, Rockwell Automation Control Systems.
Copyright 2000 by Dedicated Systems Magazine - 2000 Q1 (www.dedicated-systems.com)
[15] Apontamentos das aulas práticas de Sistemas de Tempo Real, Eduardo Tovar.
[16] Scheduling and Synchronization in Embedded Real-Time Operating Systems, Sanjeev Khushu and Johnathan Simmons,CSE 221, March 5, 2001
[17] Configuring Ethernet,FDDI, and Token Ring Services, Part No. 305259-A Rev 00, November 1998,BayRS Version 13.10, Site Manager Software Version 7.10,BCC Version 4.10, Copyright © 1998 Bay Networks, Inc. [18] Cisco CCNA Exam #640-507 Certification Guide, Wendell Odom, Copyright© 2000 Lacidar Unlimited, Inc.
XIII
Índice remissivo ambiente distribuídos, 9 Application, 17 Assembly Object, 41 Attribute ID, 34 auto-sensing, 24 bridges, 22 Broadcast, 28 CIP, 2, 32 Class ID, 33 CLNP, 27 configuração, 39 Connections Path, 40 COTS, 6 CRC, 19 CSMA/CD, 2, 20 cut-through, 24 Data link, 15 datagrams, 15 DHCP, 18 DM, 6 DNS, 17 DQDB, 26 EDF, 6 escalonável, 7, 8 estado, 43, 45 Ethernet, 2, 19, XII Ethernet/IP, 2, 49 Explicit Messaging Connections, 35 FCFS, 6 FTP, 17 gráfica, 7, 8 HTTP, 17 hub, 21 I/O Connections, 35 IEEE, 2 INDEPTH, 2 Instance ID, 33 IP, 15 IPX, 27 ISO, 2
LAN, 2, 26 LPC, 39 LPO, 39 MAC, 22 MAC ID, 33 MAN, 26 mensagem, 10 Message Router, 37 Multicast, 28 Network, 15 NIC, 19 objecto, 32 ODVA/CI, 34 Origem/Destino, 46 OSI, 13, 14 PLCs, 32 Produtor/Consumidor, 46 rede, 29 redes, XI repeaters, 20 RM, 6 routers, 26 Sistemas de Tempo Real, 4, XII SMTP, 17 SNMP, 17 store-and-forward, 24 switches, 23 TCP, 16 TCP/IP, 14 tempo de resposta, 5 token, 10 Token-passing, 10 Topologia, 32 Transport, 16 UCMM, 37 UDP, 16 Unicast, 28 VLAN, 29 VLANs, 25 WAN, 26