PROTOCOLOS DE COMUNICAÇÃO EM TEMPO REAL Daniel Brito Igor Morais Onildo Ferraz Thiago 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

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

LAN Local 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

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

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

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.

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

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”

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

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

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

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

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

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

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

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

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.

IEEE 802.4 Suponha uma rede com 3 nós usando IEEE 802.5. 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.

CAN Controller 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 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

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

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

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

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

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

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

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

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

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

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.

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

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.

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

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.

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%20time%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_middlew 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