PROTOCOLOS DE COMUNICAÇÃO EM TEMPO REALDaniel BritoIgor MoraisOnildo FerrazThiago Menezes

INTRODUÇÃO RTC vêm sendo implementados cada vez

mais em plataformas distribuídas Baratas Tolerantes a falhas

Todos os sistemas distribuídos de tempo real Têm como base uma rede de comunicação

Entrega as mensagens no tempo certo

DEFINIÇÃO Em Comunicação de Tempo Real, as aplicações que a

utilizam têm requisitos de qualidade de serviço (Quality of Service – QoS) Latência máxima (maximum delay) Mínima largura de banda Delay jitter Máxima taxa de perda de pacotes

LATÊNCIA(DELAY) Tempo contado desde que o pacote sai do adaptador

de rede do nó remetente até quando chega no adaptador de rede do nó destinatário.

O sucesso da transmissão depende não só da integridade, mas de o pacote chegar no tempo certo. Em caso de fracasso, pode acontecer uma

catástrofe (hard), ou degradação (soft)

JITTER Máxima variação do delay

Um jitter suficientemente alto causa degradação em uma aplicação de streaming de vídeo (soft real time). Para combater o jitter se usa um buffer no nó de

recepção Para um vídeo com um bitrate de 60MBps, e uma transmissão

streaming com Jitter de 1s, usaria-se um buffer de 60MB.

LARGURA DE BANDA A banda obviamente deve ser larga o suficiente para

garantir a vazão de dados do sistema.

TAXA DE PERDA DE PACOTES Percentagem de pacotes que são perdidos ou

descartados em sua chegada (seja por atraso, corrompimento, ou buffer overflow)

Aplicações de controle (hard real time) não admitem perda de pacotes

Aplicações multimídia (soft real time) admitem perdas

OS REQUISITOS QOS VARIAM Cada aplicação é um caso

Um sistema fly-by-wire é muito sensível a delay (não admite delay maior que 1ms), e perdas de pacote são inaceitáveis

Sistema de streaming de voz é pouco sensível a delay, e mantem uma performance razoável mesmo com certa perda de pacotes

Um jogo online de tiro em primeira pessoa é bastante sensível a delay e a perda de pacotes

PROTOCOLOS DE ENLACE TRADICIONAIS São de máximo esforço (ex.: Ethernet)

Não dão garantias

São utilizadas em situações onde alta latência e alta perda de pacotes (resolvida com retransmissões) são aceitáveis.

Portanto, não servem para Aplicações de Tempo Real

APLICAÇÕES NON REAL TIME Preocupam-se bastante com perda de pacotes

(integridade da informação)

Não preocupam-se muito com delay, jitter, largura de banda.

APLICAÇÕES DE RTC

Robôs de uma linha de produção Trocam informações com o controlador

Hard Real Time: controle, dados de sensores Soft Real Time: logs

APLICAÇÕES DE RTC

Planta Química

APLICAÇÕES DE RTC

Jogos Online Multiplayer

TIPOS DE REDES Três tipos de redes são relevantes

Controller Area Network (CAN)

Local Area Network (LAN)

Internet

CONTROLLER AREA NETWORK

Surgiu nos automóveis Comunicação entre sistemas embarcados Antes de CAN, se usava ligações ponto-a-ponto Robusta, funciona sob forte ruído

Expandida para outras aplicações Aviões, navios, controle industrial, etc.

LOCAL AREA NETWORK Rede privada que conecta computadores e

compartilha recursos como impressoras e scanners

Operam tipicamente a 10 ou 100Mbps.

Broadcast

INTERNET

CATEGORIZAÇÃO DE TRÁFEGO O tipo de tráfego deve ser conhecido em tempo de

projeto para a rede poder garantir a QoS

Há três categorias importantes Constant Bit Rate traffic Variable Bit Rate traffic Sporadic traffic

CONSTANT BIT RATE TRAFFIC Fonte gera dados a uma taxa constante Em aplicações de Tempo Real, o tráfego costuma ser

constante Ex.: Informações periódicas de sensores

VARIABLE BIT RATE TRAFFIC Fonte gera dados a diferentes taxas em diferentes

momentos. Há dois tipos de VBR: Fonte alterna entre CBRs diferentes Fonte não gera dados a taxas constantes

Exemplos: Áudio MP3 (codificado em VBR): em trechos de

silêncio no áudio, nenhuma informação é enviada Vídeo: ocorre muita redundância de informação

entre um frame e outro

SPORADIC TRAFFIC Rajadas de pacotes entre intervalos mínimos de

silêncio

Exemplo: despertador

COMUNICAÇÃO DE TEMPO REAL EM LAN LAN Broadcast

Canal compartilhado por todos Apenas um nó pode transmitir por vez Protocolo de Controle de Acesso ao Meio

As duas arquiteturas LAN mais usadas: Barramento Anel

ARQUITETURA DE BARRAMENTO Todos os computadores conectados ao mesmo

barramento

Protocolo MAC mais comum é o CSMA/CD Nós devem estar próximos por causa do atraso de

propagação

Ethernet é o padrão mais usado no mundo Por isso, houve tentativas de se criar protocolos

RTC baseados em Ethernet

ARQUITETURA DE BARRAMENTO Ponto positivo: Fail silent Ponto negativo: política de acesso baseada em colisão

(não serve para Tempo Real Hard)

ARQUITETURA DE ANEL Nesta arquitetura, cada nó transmite na sua vez

durante um intervalo de tempo pré-determinado.

ARQUITETURA DE ANEL Ponto positivo: Mais vantajosa do que Barramento,

devido à sua política de acesso determinista e arbitrária (serve para Tempo Real Hard)

Ponto negativo: Se um nó falhar, a rede toda falha Ponto negativo: Difícil de instalar em uma indústria,

por ex.

TOKEN BUS Os pesquisadores encontraram uma arquitetura que

reúne benefícios de ambas

Usa barramento, mas implementa anél lógico

Não existe a dificuldade de instalação (não importa a ordem física com que os computadores se ligam ao barramento).

O protocolo de acesso pode adicionar ou remover nós

LANLocal Area Network

COMUNICAÇÕES REAL TIME SOFT EM LAN Não garante nenhum limite em QoS

Dá apenas “garantias estatísticas”

Tratamento prioritário a mensagens RT para manter a taxa de deadlines ultrapassados dentro do “garantido”

COMUNICAÇÕES REAL TIME SOFT EM LAN Mensagens RT e non-RT trafegam no mesmo meio

Mensagens RT são CBR ou VBR

Mensagens non-RT são aperiódicas e chegam em rajadas

As rajadas são o problema. É preciso amenizá-las

Fixed-rate Traffic Smoothing Adaptive-rate Traffic Smoothing

FIXED-RATE TRAFFIC SMOOTHING Kweon e Shin

Algoritmo que suaviza as rajadas

Credit Bucket Depth (CBD)

Baseia-se no limite de transmissão da rede

Impõe um limite de transmissão média non-RT para cada fonte

CREDIT BUCKET DEPTH Cada fonte tem um balde

Cada balde contém créditos que serão usados para a transmissão de mensagens non-RT

Dois parâmetros (estáticos): CBD (profundidade do balde) RP (Refresh Period)

A razão CBD/RP é a vazão média garantida para mensagens non-RT

CREDIT BUCKET DEPTH O saldo de créditos em um balde se chama CNS

O CNS determina se a mensagem non-RT que chega será enviada ou não

A cada refresh, o balde é enchido com mais CBD créditos CNS = min (CBD, CNS + CBD)

FIXED-RATE SMOOTHING Desvantagem:

A vazão de fontes non-RT considera o pior caso de uso da rede.

O limite de vazão das fontes diminui a cada nó que é adicionado à LAN

ADAPTIVE-RATE SMOOTHING Kweon e Shin

Os nós podem aumentar sua vazão média se o barramento estiver livre (ou diminuí-los, caso esteja ocupado) O número de colisões por unidade de tempo é

usado como critério CBD/RP

Resultados experimentais demonstraram que a vazão para non-RT melhorou, sem prejudicar as “garantias estatísticas” para mensagens RT

ADAPTIVE-RATE SMOOTHING Não serve para Tempo Real Hard

Por que? Se parte da taxa de transmissão é reservada para RT.

Razão simples: colisões ocorrem (com frequência)

COMUNICAÇÕES EM HARD-REAL TIME EM LAN Previsibilidade determinística de atrasos

Prever deterministicamente o tempo necessário para o envio de um mensagem

Geralmente envolve tráfico CBR

São normalmente suportados pelos os seguintes protocolos: Escalonamento baseado em agenda(Calendar Based

Scheduling)

Protocolos de prioridade global(Global Priority Protocols)

Escalonamento de acesso limitado(Bounded Acess Scheduling)

ESCALONAMENTO BASEADO EM AGENDA Mantém uma Agenda

Tempo e o intervalo de tempo que cada nó tem para transmissão

Cada nó mantem uma copia da Agenda

Pode haver alocações dinâmica via broadcasting

Algoritimamente Simples

Eficiente quando todas as mensagens são periódicas

PROTOCOLOS BASEADO EM PRIORIDADE GLOBAL Cada mensagem tem um valor que representa sua

prioridade

Tentar garantir que o canal esteja sempre com a tarefa de maior prioridade

Exemplos: CountDown Protocol

IEEE 802.5

COUNTDOWN PROTOCOL A linha do tempo é dividida em intervalos de tempos

fixos chamados slots. No começo de cada intervalo uma arbitragem de

prioridade é realizada

A Arbitragem de Prioridades: Dividida em slots de tamanho fixos.

Cada slots é o tempo necessário para o envio de um bit

Cada nó envia uma mensagem binária com sua prioridade, começando pelo o bit de maior ordem.

No final de cada slot é feita uma verificação onde o nó averigua a sua prioridade diante a dos outros nó, se sua prioridade é menor então ele deixa de enviar

O nó que enviar toda a mensagem por completo, é o nó que tem maior prioridade

COUNTDOWN PROTOCOL

Exemplo: 3 nós na Lan N1 = 10(01010) , N2 = 16(10000) , N3 = 20(10100) N3 > N2 > N1

COUNTDOWN PROTOCOL

IEEE 802.5 Protocolo baseado em redes token ring Evoluiu da rede “IBM token-ring network” Esquema de prioridade para adquiri o Token 8 níveis de prioridade Tipos de Pacote:

Token Frame

IEEE 802.5 Token

1 Byte para determinar começo do pacote 1 Byte para Controle de Acesso

Campo de prioridade Token bit identifica se é frame ou token Monitor ring bit ( Monitorar o token ) Reservation Bits, campo para determinar prioridade do

proximo token 1 Byte para determinar o fim do pacote

IEEE 802.5 Frame

1 Byte para determinar começo do pacote 1 Byte para Controle de Acesso 1 Byte controle de frame

Determina se o frame tem informações de controle ou dados

6 Bytes para endereçamento de destino 6 Bytes para endereçamento de fonte 4 Bytes para CheckSum 1 Byte para determinar o fim do pacote

IEEE 802.5 Frame

1 Byte para determinar começo do pacote 1 Byte para Controle de Acesso 1 Byte controle de frame

Determina se o frame tem informações de controle ou dados

6 Bytes para endereçamento de destino 6 Bytes para endereçamento de fonte 4 Bytes para CheckSum 1 Byte para determinar o fim do pacote

IEEE 802.5 Funcionamento Básico:

Token circula pela rede O nó que precisa enviar uma mensagem “segura” o token e

envia um frame para o destino O nó destino recebe o frame captura os dados e repassa o

frame Quando o nó de origem recebe o frame, caso não tenha

mais pacotes a enviar, libera o token.

Exemplo: 4 nós: “A”, “B”, “C”, “D”. “B” tem um 1 frame de prioridade 3 para enviar para “A” “C” tem um 1 frame de prioridade 2 para enviar para “A” “D” tem um 1 frame de prioridade 4 para enviar para “A” Token começa com “A”

IEEE 802.5

IEEE 802.5Evento Campo AC

Token/Frame“A “gera token P=0, M=0, T=0,

R=0“B” segura o token e envia frame com destina a “A”

P=3, M=0, T=1, R=0

Frame chega em “C”, “C” reserva o token com prioridade 2

P=3, M=1, T=1, R=2

Frame chega em “D”, “D” reserva o token com prioridade 4

P=3, M=1, T=1, R=4

Frame chega em “A” e “A” extrai os dados P=3, M=1, T=1, R=4

Frame retorna para “B”, “B” o destrói e lança um novo Token

P=4, M=0, T=0, R=0

Token chega em “C” mas a prioridade do token é maior do que a da sua mensagem, então “C” reserva o próximo token

P=4, M=1, T=0, R=2

IEEE 802.5Evento Campo

ACToken/FrameToken chega em “D”, “D” segura o Token e envia uma msg para “A”

P=4, M=0, T=1, R=2

Frame chega em “A” e “A” copia esse. P=4, M=0, T=1, R=2

Frame chega em “B”, que repassa o Frame. P=4, M=0, T=1, R=2

Frame chega em “C”. P=4, M=1, T=1, R=2

Frame retorna a “D” que remove esse e gera o novo Token com Prioridade 2

P=2, M=0, T=0, R=0

ESCALONAMENTO DE ACESSO LIMITADO Limita o tempo de acesso de cada nó ao canal

Cada nó tem um tempo fixo para transmissão

Exemplos:

RETHER

IEEE 802.4

IEEE 802.4 Timed token protocol

Usados em redes token bus e token ring

Foi usado no MAP (Manufacturing Automation Protocol) desenvolvido pela GM

Foi incorporado no protocolo Fiber Distributed Data Interface(FDDI)

IEEE 802.4 Cada nó tem um tempo limitado para segurar o Token TTRT( Target Token Rotation Time) é usado como

parâmetro de projeto. O tempo esperado entre duas visitas consecutivas

do token ao nó. Cada nó reserva uma porção do TTRT, Tempo para

segura o Token( Holding Time, H) Então o TTRT pode ser definido por:

Onde θ é o tempo de propagação

IEEE 802.4 Quando um nó recebe um token

primeiramente é enviado todas as mensagens de tempo real, então o token é repassado

Quando o nó recebe novamente o token, se ele chega mais cedo do que o TTRT então é enviado as mensagens de tempo real + as mensagens de tempo não real.

RETHER Real-Time ETHERnet

Baseada na ETHERNET Usa de Técnica baseada em tokens. Rede essencialmente token-bus Dois modos de operação:

RETHER Quando há mensagens em tempo real a serem

transmitidas CSMA/CD

Quando não há mensagens em tempo real a serem transmitidas

RETHER Modo CSMA/CD:

Nesse modo não há mensagens em tempo real Os nós competem o canal baseado no protocolo original do

CSMA/CD Todos os nós ficam nesse modo até chegar uma requisição

para uma mensagem de tempo real Mudando para o modo RETHER:

O nó, que possui a msg de tempo real, envia um requisição via Broodcasting para mudar para o RETHER

Todos os nós que recebem essa requisição, envia um mensagem de confirmação(ACK) para o nó iniciante.

Quando o nó iniciante recebe todos os ACK começa a transmissão em tempo real gerando um token que irá circular pela rede

RETHER Modo RETHER:

Nesse modo é usado um esquema de “timed token-passing” Cada Requisição de Tempo Real é especificado:

O MTRT, Maximu Token Rotation Time , Tempo máximo de circulação do token na rede

MTHT – Maximus Token Holding Time, o máximo de tempo que um nó pode segurar um Token é definido por:

O token circula entre dois conjuntos diferentes (RT e Non-RT). Circula em todos os nós RT Caso haja tempo circula pelos os nós Non-RT

Quando um nó RT recebe o Token, ele segura o token e envia a mensagem de tempo real durante um tempo igual MTHT. Depois de enviar a mensagem, ele envia o Token para o proximo nó RT

RETHER Modo RETHER:

Depois do ultimo nó RT enviar a mensagem, o Token é passado para os nós Non-RT

Os nós Non-RT tem um tempo de:

A cada nova requisição de tempo real é recalculado o MTRT, que dever satisfazer a equação:

RETHER

CANController Area Network

CAN

“Rede de barramento baseado em protocolo de mensagens, desenvolvida para permitir microcontroladores e dispositivos comunicarem-se entre si para aplicações de controle tempo real”

http://en.wikipedia.org/wiki/Controller_area_network

CAN

Car Area NetworkConfiabilidade;Segurança;Eficiência;Diagnóstico de falhas;Robustez.

Carro com falhas no sistema de

cabo (sem diagnóstico)

Religação de todo o veículo

tão cara quanto um novo

CAN Aumento da quantidade de equipamentos eletrônicos; Muitas comunicações de cabo(pesados e caros); Substituição dos sistemas ponto-a-ponto; Redes internas no veículo, surgindo a CAN.

CAN Indústria automotiva adotou o CAN como o padrão

internacionalmente reconhecido ISO 11898 Uso em indústrias onde a imunidade a ruídos e tolerância a

falhas são mais importantes que a velocidade Velocidade para desenvolver e reconfigurar a rede Automação industrial Equipamento médico

Gerenciamento de salas de operação Aplicações ferroviárias

Controladores de freio, unidades de contagem de passageiros

Aeronaves Sensores de estado de voo, sistemas de navegação

Aplicações aeroespacial

CAN Quantidade de CAN vendidos(milhões)

CAN Equivalente ao alfabeto latino na comunicação humana; Seus usuários definem a linguagem e as palavras para se

comunicarem; Hierarquia multi-master; Comunicação broadcast; Mecanismos sofisticados de detecção de erro e

retransmissão de mensagens com defeitos; Plug and play; NRZ bit coding; Provê 2 serviços de comunicação:

Envio de mensagens Requisição de mensagens

CAN As unidades de controle(ECU) podem ter uma única

interface CAN em vez de entradas analógicas e digitais para cada dispositivo no sistema

Cada um dos dispositivos na rede tem um chip controlador CAN

PROTOCOLO CAN Troca de dados

PROTOCOLO CAN Suporta 2 formatos do frame

CAN base frame – 11 bits identificador CAN extended frame – 29 bits identificador

PROTOCOLO CAN Todos os dispositivos na rede veem todas as mensagens

transmitidas;

Não existe esquema de endereçamento(diferentemente do Ethernet);

Quando um nó CAN está pronto para transmitir dados, ele faz uma verificação para ver se o barramento está ocupado, e então simplesmente escreve um quadro CAN para a rede;

Usa-se um ID de arbitragem que é único em toda a rede de rótulos do quadro para reconhecimento do nó que receberá o dado.

PROTOCOLO CAN Broadcasting Message Request

PROTOCOLO CAN Arbitração do barramento:

Uso do protocolo de distribuição de acesso à mídia chamado CSMA/CA (Carrier Sense acesso múltiplo / Collision Avoidance);

A prioridade da mensagem é definida por identificador, um "0" é de maior prioridade, em seguida, um "1“;

Mais de uma mensagem com "0" como o primeiro bit do identificador → o procedimento continua por todos os bits;

O nó que não tem acesso ao barramento, em determinado momento, tentará enviar a mensagem novamente (run-time scheduling).

PROTOCOLO CAN

PROTOCOLO CAN Tolerância a falhas

ACK Error Stuff Error – Mais que 5 bits

de mesma polaridade CRC Error Form Error – Violação dos

bits do campo fixado Mensagens corrompidas são

automaticamente retransmitidas

Velocidade do barramento abaixo de 125Kbps → pode usar um modo tolerante a falhas, onde o barramento vai funcionar se um dos dois fios é cortado

PROTOCOLO CAN Tolerância a falhas

Ex: 1 erro no bit a cada 0.7 segundos 500 kbit/segundo 8 h/dia 365 dias/ano

Probabilidade de erro: 1 erro não detectado a cada 1000 anos

PROTOCOLO CAN Tolerância a ruídos

A informação é transportada no barramento como uma diferença de tensão entre as duas linhas;

Se ambas as linhas estão na mesma tensão, o sinal é um bit recessivo. Se a linha CAN_H é maior do que a linha CAN_L de 0.9V, a linha de sinal é um bit dominante;

O barramento é, portanto, imune a qualquer ruído de fundo pois não há nenhum ponto de referência independente do terreno para essas duas linhas;

Imune a interferências eletromagnéticas.

PROTOCOLO CAN Mensagens sem estado

Se dois nós estão se comunicando, é comum para o nó de recepção solicitar que uma mensagem deve ser repetida se a primeira tentativa foi corrompida;

É possível que um nó não seja afetado por uma falha local, enquanto os outros tenham recebido com êxito a mensagem;

Deve-se evitar usar as mensagens que dependem do estado anterior ou que contenham informações relativas;

Considerando uma mensagem que indica que a velocidade do veículo aumentou de 10 km/h;

Se um nó reinicia, tem-se que garantir que essas informações de estado podem ser recuperadas após cada reinicialização.

PROTOCOLO CAN Orientada a eventos e time-triggered

A arquitetura de barramento não impõe quaisquer restrições sobre quando os nós estão autorizados a colocar mensagens no barramento;

Uma abordagem alternativa é o uso de protocolo time-triggered onde as mensagens têm intervalos de tempo pré-alocados. Ex: FlexRay;

O protocolo Time-Triggered CAN(TTCAN), que fica em cima de hardware CAN, fornece um mecanismo de agendamento de mensagens;

Comunicações time-triggered encaixam-se bem com o projeto de malhas de controle de processo.

PROTOCOLO CAN Taxa de transmissão X Distância do barramento

Transporta dados maiores que 8 bytes; Sistemas embarcados requerem comunicação apropriada

baseado em master/slave; Gerenciamento da rede(Monitoramento, sincronização,

inicialização...);

Implementa serviços como: Controle de fluxo; Endereços de nó; Estabelecimento de comunicação; Comportamento inicial; Distribuição de mensagens.

CAN Hardware nas camadas 1 e 2; Softwares nas outras camadas.

PROTOCOLO DE CAMADA SUPERIOR PARA CAN

PROTOCOLO DE CAMADA SUPERIOR PARA CAN J1939

Comunicação especificada para caminhões(scania) e ônibus Broadcasting Cada nó tem pelo menos um nome específico(funcionalidade) e

endereço(localização) Cada nó contém uma lista de endereços existentes na rede Um novo nó pede um endereço, ele irá transmitir uma

"mensagem de identificação" no barramento Todos os nós transmitem sua tabela de endereços, para que o

"novo nó" possa encontrar um endereço disponível Se a mensagem é um pedido global, todos os nós devem

verificar a mensagem e responder com os dados solicitados Utilização de pontes

PROTOCOLO DE CAMADA SUPERIOR PARA CAN

CAL (CAN Camada de Aplicação) / CANopen

Serviços da camada de aplicação:

Os parâmetros definem nos nós de controle o comportamento de comunicação(quais dados serão enviados, em qual mensagem e quando essa mensagem vai ser enviada)

CMS (CAN Message Specification) define um protocolo para transferência de dados entre os módulos CAN; NMT (Network Management) define um protocolo para o sistema start-up e shutdown, erro de logging, etc; DBT-master (Identificador Distribuidor) define um protocolo para a distribuição de identificadores para os diferentes módulos em um sistema; LMT-master (Layer Management) define um protocolo para configurações e camada de identificação dos parâmetros.

Implementa serviços como a auto-configuração do sistema, a sincronização entre nós e acesso a todos os parâmetros dos dispositivos

PROTOCOLO DE CAMADA SUPERIOR PARA CAN

CAN-Kingdom

PROTOCOLO CAN

Simples; Flexível; Barato; Fácil de adicionar novos nós; Comunicação em tempo real; Boa tolerância a interferências

eletromagnéticas; Altas velocidades a baixo custo; Desenvolvido para controle; Baixo custo de implementação; Confiável.

Carga de pico → vários nós querem enviar mensagens ao mesmo tempo;

O protocolo sem proteção contra nós, que ocupam o barramento, enviando mensagens ininterruptas;

Prazos de transmissão devem ser calculados com o pior caso de atraso para as mensagens.Do contrário, não podem ser detidos com carga de pico;

Procedimento com bit ack → tempo extra.

VANTAGENS DESVANTAGENS

DÚVIDAS

REFERÊNCIAS www.md.kth.se/RTC/MSc-theses/RT-Com-Evaluation-Waern.pdf http://en.scientificcommons.org/43181965 http://nptel.iitm.ac.in/courses/Webcourse-contents/IIT%20Kharagpur/Real%2

0time%20system/pdf/module6.pdf http://en.wikipedia.org/wiki/Controller_area_network http://reference.kfupm.edu.sa/content/r/t/rtc__a_real_time_communication_m

iddlewar_94860.pdf Real-time Communication Protocols: An Overview. Ferdy Hanssen and Pierre

G. Jansen Real-time Communication. UCI DREAM Lab Real-time Systems: Theory and Practice. Rajib Mall