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.

54

Figura 45: Passos para o encapsulamento de uma mensagem.

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