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

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
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.
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
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 é
P=4, M=1, T=0, R=2
maior do que a da sua mensagem, então “C” reserva o
próximo token
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.
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
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;
Carro com falhas
 Eficiência;
no sistema de
 Diagnóstico
cabo (sem de falhas;
diagnóstico)
 Robustez.

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
Endereçamento baseado em
conteúdo
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
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
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

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

CAN-Kingdom
Usado 1ª vez na
indústria têxtil
O tempo máximo de
latência de qualquer
mensagem pode ser
previsto
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
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 CANKingdom
PROTOCOLO CAN
VANTAGENS










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.
DESVANTAGENS




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/Webcoursecontents/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