PROTOCOLOS DE COMUNICAÇÃO EM TEMPO REAL

Apresentação em tema: "PROTOCOLOS DE COMUNICAÇÃO EM TEMPO REAL"— Transcrição da apresentação:

1 PROTOCOLOS DE COMUNICAÇÃO EM TEMPO REAL
Daniel Brito Igor Morais Onildo Ferraz Thiago Menezes

2 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

3 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

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

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

6 Largura de banda A banda obviamente deve ser larga o suficiente para garantir a vazão de dados do sistema.

7 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

8 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

9 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

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

11 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

12 APLICAÇÕES DE RTC Planta Química

13 APLICAÇÕES DE RTC

14 APLICAÇÕES DE RTC Jogos Online Multiplayer

15 Tipos de Redes Três tipos de redes são relevantes
Controller Area Network (CAN) Local Area Network (LAN) Internet

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

17 Local Area Network Rede privada que conecta computadores e compartilha recursos como impressoras e scanners Operam tipicamente a 10 ou 100Mbps. Broadcast

18 Internet

19 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

20 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

21 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

22 Sporadic traffic Rajadas de pacotes entre intervalos mínimos de silêncio Exemplo: despertador

23 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

24 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

25 Arquitetura de Barramento
Ponto positivo: Fail silent Ponto negativo: política de acesso baseada em colisão (não serve para Tempo Real Hard)

26 Arquitetura de Anel Nesta arquitetura, cada nó transmite na sua vez durante um intervalo de tempo pré-determinado.

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

28 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

29 LAN Local Area Network

30 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”

31 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

32 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

33 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

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

35 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

36 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

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

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

39 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

40 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

41 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

42 CountDown Protocol 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

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

44 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 Access-Control Byte—Contains the Priority field (the most significant 3 bits) and Reservation field (the least significant 3 bits), as well as a token bit (used to differentiate a token from a data/command frame) and a monitor bit (used by the active monitor to determine whether a frame is circling the ring endlessly). Frame-Control Bytes—Indicates whether the frame contains data or control information. In control frames, this byte specifies the type of control information. Data—Length of field is limited by the ring token holding time, which defines the maximum time a station can hold the token.

45 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

46 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

47 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

48 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. Access-Control Byte—Contains the Priority field (the most significant 3 bits) and Reservation field (the least significant 3 bits), as well as a token bit (used to differentiate a token from a data/command frame) and a monitor bit (used by the active monitor to determine whether a frame is circling the ring endlessly). Frame-Control Bytes—Indicates whether the frame contains data or control information. In control frames, this byte specifies the type of control information. Data—Length of field is limited by the ring token holding time, which defines the maximum time a station can hold the token.

49 IEEE 802.5 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”

50 IEEE 802.5 Evento 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 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

51 IEEE 802.5 Evento Campo ACToken/Frame
Token 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. Frame chega em “B”, que repassa o Frame. 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

52 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

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

54 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

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

56 RETHER Real-Time ETHERnet Usa de Técnica baseada em tokens.
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

57 RETHER Modo CSMA/CD: Mudando para o modo RETHER:
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

58 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

59 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:

60 RETHER

61 RETHER Modo RETHER: Nesse modo é usado um esquema de “timed token-passing” Cada Requisição de Tempo Real tem que ter especificado: A quantidade de dados que ele precisa enviar durante um determindado intervalo de tempo (MTRT, Maximu Token Rotation Time) MTHT – Maximus Token Holding Time, o máximo de tempo que um nó pode segurar um Token é definido por: A qualquer momento, só pode haver uma requisição de tempo real por nó 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 por um tempo igual MTHT

62 RETHER Requisição de mudança para modo RETHER
Broadcast “Switch-to-RETHER” Recebe confirmações (aknowledgment) Cria Token Casos Especiais: Duas requisições ao mesmo tempo Não recebimento de ack -> timout

63 RETHER Nós divididos em: RTS e NRTS Token visita todos RTS
Token só visita NRTS se há tempo MTRT – Maximum Token Rotation Time

64 IEEE 802.4 a THT Token Holding Time
Tempo máximo que o “token” pode estar retido num nó para que este emita dados de prioridade máxima (classe 6). TRT4 Token Rotation Time (Class 4) Tempo máximo que o “token” pode demorar a circular para ainda permitir a emissão de dados de classe 4. TRT2 Token Rotation Time (Class 2) Tempo máximo que o “token” pode demorar a circular para ainda permitir a emissão de dados de classe 2. TRT0 Tempo máximo que o “token” pode demorar a circular para ainda permitir a emissão de dados de classe 0.

65 IEEE 802.4 Suponha uma rede com 3 nós usando IEEE Nó 1 precisa transmitir 1MB de dados a cada 300ms, nó 2, 1,2MB a cada 500ms e Nó 3 1,2MB a cada 500ms.

66 CAN Controller Area Network

67 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”

68 CAN Car Area Network Confiabilidade; 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

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

70 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

71 CAN Quantidade de CAN vendidos(milhões)

72 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

73 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

74 Protocolo CAN Endereçamento baseado em conteúdo Troca de dados
Fácil de adicionar nós sem realizar alterações Recepção de múltiplos dados Sincronização de processos distribuídos Upgrade da rede -Oferece um alto

75 Protocolo CAN Suporta 2 formatos do frame
CAN base frame – 11 bits identificador CAN extended frame – 29 bits identificador -Em tempo real a urgencia do processamento de mensagens serem Trocadas na rede pode diferir muito

76 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. Decisão de cada nó se aceita ou não o quadro Bits dominante ou recessivo Se vários nós tentam transmitir uma mensagem para o CAN, ao mesmo tempo, o nó com a maior prioridade (menor ID arbitragem) recebe automaticamente o acesso do barramento Todos os nós podem ouvir e transmitir ao mesmo tempo Transmissões ininterruptas quando uma colisão é detectada

77 Protocolo CAN Broadcasting Message Request -Nó A transmite
-Nó B , C e D recebem a mensagem -Nós B e D aceitam a mensagem , nó C rejeita

78 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). -cada nó transmissor monitora o nível de transmissão dos bits No barramento, compara ele com o nivel transmitido -Usado durante a arbitração de processo -Provê detecção imediata de toda largura do barramento e erros Na transmissão local -Se vários nós tentam transmitir uma mensagem para o CAN, ao mesmo tempo, o nó com a maior prioridade (menor ID arbitragem) recebe automaticamente o acesso do barramento

79 Protocolo CAN -cada nó transmissor monitora o nível de transmissão dos bits No barramento, compara ele com o nivel transmitido -Usado durante a arbitração de processo -Provê detecção imediata de toda largura do barramento e erros Na transmissão local -Se vários nós tentam transmitir uma mensagem para o CAN, ao mesmo tempo, o nó com a maior prioridade (menor ID arbitragem) recebe automaticamente o acesso do barramento

80 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 -Se 6 bits consecutivos com a mesma polaridade são detectadas Entre o SOF(Start of frame) e o CRC delimiter , a regra do bit stuffing Foi violada.Um erro stuff ocorre e frame erro é gerado. A mensagem é Entao repetida -Stuff bit inserido depois de 5 bits consecutivos com o mesmo estado.Usado Para sincronizacao dos nós -Se um nó no barramento recebe uma mensagem corrompida, ele envia um quadro de erro para alertar os outros nós para descartar a mensagem e o transmissor para reenviar a mensagem -Erros detectados tornam-se publicos para todos os outros nós via Error Frames.A Transmissão da mensagem errada é abortada e o frame é repetida o mais rapido Possivel

81 Protocolo CAN Tolerância a falhas Ex: Probabilidade de erro:
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

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

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

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

85 Protocolo CAN Taxa de transmissão X Distância do barramento
-Nó D envia a mensagem solicitada -Nós A,B e C recebem a mensagem solicitada -Nós A, B aceitam a mensagem solicitada, nó C rejeita

86 Protocolo de camada superior para CAN
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.

87 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 -Em um situação em que uma mensagem tem que ser dirigida a um nó específico, o endereço de destino é incluído na mensagem de identificador das mensagens enviadas -Se uma mensagem é um pedido de destinação específica, ou de comando, um nó verifica se a mensagem foi dirigida ao próprio nó. Em caso afirmativo, o nó verifica se a mensagem está certa e envia de volta um ack -Utilização de uma ponte tem a vantagem que as redes de cada lado da ponte não precisa ser compatíveis entre si, usada para dividir a rede em segmentos diferentes -As mensagens que são mais longas, maior que 8 bytes podem ser enviadas como mensagens multi-empacotadas

88 Protocolo de camada superior para CAN
CAL (CAN Camada de Aplicação) / CANopen 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) 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 Serviços da camada de aplicação: 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.

89 Protocolo de camada superior para CAN
Usado 1ª vez na indústria têxtil Baseado na idéia de que os módulos são para servir a rede Nenhum conhecimento do sistema deverá ser necessário em um único nó O projetista decide quais identificadores CAN serão usados no sistema O tempo máximo de latência de qualquer mensagem pode ser previsto Extensão de identificadores CAN pode ser usado Método de gestão de barramento, um relógio mundial e identificador de atribuições CAN MESTRE → durante a fase de inicialização atribui identificadores adequados a todas as mensagens utilizadas no sistema O mestre é capaz de verificar quais nós estão conectados à rede É possível ligar qualquer módulo seguindo a especificação do protocolo CAN (ISO 11898) a uma rede CAN-Kingdom CAN-Kingdom

90 Protocolo CAN VANTAGENS DESVANTAGENS 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.

91 DÚVIDAS

92 REFERÊNCIAS www.md.kth.se/RTC/MSc-theses/RT-Com-Evaluation-Waern.pdf
contents/IIT%20Kharagpur/Real%20time%20system/pdf/module6.pdf ar_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