DESENVOLVIMENTO DE UMA REDE MODBUS PARA O ... - Fei

fei.edu.br

DESENVOLVIMENTO DE UMA REDE MODBUS PARA O ... - Fei

X SBAI – Simpósio Brasileiro de Automação Inteligente

18 a 21 de setembro de 2011

São João del-Rei - MG - Brasil

DESENVOLVIMENTO DE UMA REDE MODBUS PARA O CONTROLE DE UM

VEÍCULO AUTÔNOMO

Tiago A. Arruda ∗ , Érica R. Campedelli† , Guilherme A. S. Pereira †

∗ Programa de Pós-Graduação em Engenharia Elétrica,

† Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos,

Universidade Federal de Minas Gerais, Av. Antônio Carlos, 6626, 31270-901,

Belo Horizonte, MG, Brasil.

Emails: tiagoaa@cpdee.ufmg.br, erica@cpdee.ufmg.br, gpereira@ufmg.br

Abstract— This paper presents the development of a real time network based on Modbus over RS-485 for

aplications in autonomous vehicles. The main objective of this network is to replace the current USB based

communication system in an autonomous car that has been developed by the Grupo de Pesquisa e Desenvolvimento

de Veículos Autônomos (PDVA) at UFMG. The experiments presented in the paper show the feasibility

of this network and its potential to fulfill the communication requirements needed for sensing and control in a

autonomous vehicle.

Keywords— InstrumentationNetwork; Modbus; SensorNetwork; DeterministicNetwork; EmbeddedSystems;

Real-Time.

Resumo— Este artigo mostra o desenvolvimento de uma rede de tempo real baseada em Modbus sobre a

camada física RS-485 para aplicação em veículos autônomos. O objetivo da rede é substituir o modelo de

comunicação via conexão USB, atualmente utilizado no carro autônomo desenvolvido pelo Grupo de Pesquisa e

Desenvolvimento de Veículos Autônomos (PDVA) da UFMG. O artigo apresenta experimentos que mostram a

viabilidade desta rede e seu potencial para cumprir os requisitos de comunicação necessários para o controle e

sensoriamento de um veículo autônomo.

Palavras-chave— Rede de Instrumentação; Modbus; Rede de Sensores; Tempo Real; Rede Determinística;

Sistemas Embutidos.

1 Introdução

Em controle realimentado existem três blocos

principais definidos como sensor, controlador e

atuador. Além de um bom funcionamento individual

de cada um destes blocos é necessária uma

comunicação confiável de forma a permitir a interação

entre os mesmos.

Parasistemasindustriais, existemdiversassoluções

já em uso que resolvem os problemas de comunicação

entre os dispositivos dispostos ao longo

da planta. Via de regra grande parte dos equipamentos

e softwares de controle possuem recursos

de comunicação que permitem interligá-los e

fazê-los trabalhar conjuntamente (de Souza and

Pereira, 2008). Para sistemas robóticos, em geral

são necessárias estratégias que atendam a uma série

de requisitos inerentes deste tipo de aplicação,

como energia e processamento limitado, tipos de

dados trafegados e restrições de tempo.

Este trabalho apresenta a pesquisa e implementação

de uma rede baseada do protocolo Modbus

sob camada física RS-485, avaliando o uso da

mesma em relação à sua utilidade para trafegar

dados de diversos sensores, e/ou outros equipamentos,

espalhados ao longo de um veículo autônomo.

Este protocolo mostrou-se uma boa alternativa

para atender especificações que garantem

um sistema de comunicação confiável e determinístico

de modo que a informação seja válida para

estimação de modelos, levantamento de parâmetros

e fornecimento de dados confiáveis ao bloco

controlador do veículo.

Experimentalmente, o sistema de comunicação

foi construído e testes foram realizados inicialmente

em bancada, para obtenção das métricaspertinentes,eposteriormentenoVeículoAutônomo

da UFMG (CADU) para validar o seu funcionamento.

Este veículo é mostrado na Figura 1.

Mais detalhes sobre a robotização do veículo podem

ser encontrados em (Freitas et al., 2009).

Figura1: VeículoAutônomo CADU, desenvolvido

pelo PDVA-UFMG.

O restante do artigo está dividido da seguinte

forma: A próxima seção apresenta o protocolo

Modbus. A Seção 3 apresenta uma análise teórica

dos atrasos envolvidos na rede com o intúito

deavaliarsuacapacidadedetransmissãodedados.

A Seção 4 apresenta o desenvolvimento e a análise

ISSN: 2175-8905 - Vol. X 1179


X SBAI – Simpósio Brasileiro de Automação Inteligente

18 a 21 de setembro de 2011

São João del-Rei - MG - Brasil

experimental da rede Modbus desenvolvida neste

trabalho. Os resultados práticos onde esta rede

é usada no controle longitudinal de velocidade do

carro autônomo CADU são mostrados na Seção 5.

Finalmente, conclusões e sugestões para trabalhos

futuros são apresentados na Seção 6.

2 O Protocolo Modbus

Modbus é um protocolo de comunicação Mestre/Escravo

desenvolvido pela MODCON nos

anos 80 para ser usado como meio de comunicação

entre diferentes sistemas de automação. Devido a

sua simplicidade e sua especificação aberta, ele é

utilizado como padrão de comunicaçãoentre diversos

dispositivos como PLC’s, Interfaces Homem-

Máquina (IHM), controladores, sensores e atuadores

remotos. Sua utilização reduz o número

de cabos e consequentemente a necessidade de

manutenção e redução de erros (Téllez-Anguiano

et al., 2009).

Existem dois modos de transmissão no protocolo

Modbus. No modo ASC-II os bytes enviados

sãoconvertidosparacaracterescompreendidosentre

0-9 e A-F. Este modo é normalmente utilizado

quando há restrições no meio em relação aos bytes

habilitados a trafegar na rede. No modo RTU (do

inglês Remote Terminal Unit) os bytes enviados

estão compreendidos entre 0x00 e 0xFF e tanto o

início de frame quanto o fim de frame são determinados

por um silêncio na linha de transmissão

conforme será explicado a frente. Como o modo

RTU é mais interessante para sistemas de tempo

real, o foco deste trabalho será neste modo, detalhado

a seguir.

2.1 O Modbus-RTU

O protocolo de Linha Serial Modbus-RTU é do

tipo Mestre-Escravo (Mod, 2011b), onde somente

um Mestre por vez pode ser conectado ao barramento,

enquanto que até 31 nós Escravos são

permitidos. A comunicação Modbus-RTU é sempre

iniciada pelo Mestre, enquanto que os nós Escravos

nunca transmitirão dados sem receber uma

solicitação do nó Mestre. Ao Mestre é permitido

iniciar somente uma transação por vez.

Há dois tipos de transmissão. No modo unicast

o Mestre endereça um nó Escravo e após o

envio da requisição aguarda por um determinado

tempoaresposta. No modobroadcast arequisição

é enviada a todos os Escravos simultaneamente e

nenhuma resposta é esperada.

UmamensagemModbus-RTUécolocadapelo

dispositivo transmissor em um quadro que tem

seu início e fim conhecidos. Isto permite aos

dispositivos que recebem um novo quadro descobrir

quando uma mensagem começa e quando

ela é completada. No modo RTU, os quadros

de mensagem são separados por um silêncio prédeterminado.

A detecção de erro é baseada no Erro de

Redundância Cíclica CRC (Cyclical Redundancy

Checking) (e Bruce S. Davie, 2004) (Mod, 2011a)

e é utilizada para detectar se a mensagem é válida

ou não.

2.2 A Camada Física RS-485 para Modbus

AimplementaçãofísicadoModbusemRS-485utiliza

uma série de normas e padrões estabelecidos

tanto pela EIA/TIA/RS485 quanto pelos padrões

exigidos numa comunicação Modbus para alcançar

os requisitos necessários e relevantes para um

bom funcionamento da rede (Mod, 2011b). Este

sistema é baseado em barramento e portanto há

diversasmaneirasdeseligarumdispositivoarede.

De acordo com a norma EIA/TIA/RS485 o modelo

485 pode ser implementado em quatro configurações

diferentes sendo elas Daisy chain, Árvore,

Estrela e Branch mostradas na Figura 2.

Figura 2: Topologias Modbus

A topologia Daisy Chain é a configuração

fortemente recomendada pela especificação (Mod,

2011b) dado que nessa configuração efeitos de reflexão,

isolamento de terra e interferências diversas

são minimizados.

3 Análise da Rede Modbus sob camada

Física RS-485

As redes industriais podem ter diferenciadas aplicações

dependendo de onde e como as mesmas serão

implementadas. Para a rede Modbus desenvolvida

neste trabalho levantou-se uma série de

parâmetros importantes para se determinar a viabilidade

ou não de sua utilização para a aplicação

em veículos autônomos. Na sequência são feitas

as devidas considerações em relação aos atrasos

da rede e da carga máxima suportada utilizando

um sistema operacional de tempo real.

ISSN: 2175-8905 - Vol. X 1180


X SBAI – Simpósio Brasileiro de Automação Inteligente

18 a 21 de setembro de 2011

São João del-Rei - MG - Brasil

3.1 Atrasos de Rede

Uma característica importante a ser analisada do

ponto de vista da redes em geral, são os atrasos

envolvidos na comunicação.

Em trabalhos como os de (Jeon et al., 2001),

(Godoy et al., 2010) e (Xiaodong and Yanjun,

2002) são desenvolvidos modelos de atrasos para

análise da rede CAN. A rede CAN é multimestre

e é baseada no modelo produtor consumidor

(Farsi et al., 1999). O que propomos aqui é uma

adaptação dos modelos de atrasos desenvolvidos

por estes autores ao protocolo Modbus que é do

tipo Mestre-Escravo e permite somente um Mestre

por barramento. A Equação (1) mostra que

o atraso total da mensagem (Tdelay) equivale ao

tempopercorridonoiníciodatransmissãodemensagem

(Tstart) até a completa interpretação, processamento

e envio de resposta pelo nó de destino

(Tend).

Tdelay = Tstart −Tend

(1)

Podemos dividir os atrasos em algumas partes

para melhor analisarmos suas dependências com

os elementos da rede. Eles são:

Atraso de Geração – O atraso de geração

(AG) é o tempo gasto entre o início da tarefa e

o momento efetivo em que a mesma é enviada ao

barramento pelo mestre. Este valor é tipicamente

pequeno e depende do hardware e do modo como

o software foi implementado. Os valores deste parâmetro

são usualmente obtidos por meio de experimentos.

Atraso de Transmissão – O atraso de

transmissão (AT) corresponde ao atraso no momento

do envio dos bytes pelo mestre, considerando

o overhead causado pelos bits de start bit,

stop bit e paridade. No protocolo Modbus não há

stuff bits sendo assim o número de bits por byte

fixados em determinado valor. A Equação (2) fornece

o atraso de transmissão.

AT = τ ×(bHeader +bData+bError)

×(starB +stopB +parityB +8), (2)

onde bHeader é o cabeçalho do quadro Modbus

RTU que possui dois bytes correspondentes ao endereço

e a função do nó, bData corresponde aos

bytes de dados que podem variar entre 0 e 247 e

os bytes bError correspondem a dois bytes para

cálculo do CRC16. Os parâmetros starB, stopB

e parityB são respectivamente o start bit, stop bit

e a paridade. A variável τ corresponde ao tempo

de transmissão de um bit, e pode ser obtido por

τ = 1

Baudrate .

Atraso de Entrega – O atraso de entrega

(AE), assim como o atraso de geração equivale ao

tempo necessário para que o nó escravo processe

por completo a mensagem recebida. Este valor

também depende tanto do hardware quanto do

software envolvidos. Quanto mais rápido o processamento

da informação, menor é o tempo de

entrega.

Atraso de Controle – O Atraso de Controle

(AC) equivale a um atraso somado do tempo

de envio da resposta do escravo ao mestre e o silêncio

necessário indicado na norma Modbus que

exige que um intervalo mínimo de 1,75ms entre a

transmissão de mensagens consecutivas para que

as mesmas sejam corretamente identificadas pelos

nós escravos como sendo duas mensagens diferentes

(Mod, 2011b). O tempo de resposta do escravo

varia de nó para nó dependendo do número

de bytes transmitidos e do atraso na transmissão

de cada byte, sendo portanto obtido por meio de

experimentos ou cálculos explícitos de tempo do

firmware do escravo.

Atraso de Fila – Uma rede que se utiliza

o paradigma Mestre-Escravo não possui fila pois

somente o Mestre pode iniciar uma comunicação.

Uma vez que haja somente um mestre, não existe

risco de colisão neste protocolo. O Modbus também

especifica que cada mensagem do mestre só

pode ser direcionada a um escravo, que pode ou

não responder a solicitação. Em mensagens do

tipo broadcast, nenhum nó escravo pode responder.

Deste modo, podemos considerar o Atraso

de Fila (AF) igual a zero para o protocolo Modbus.

A Figura 3 mostra os tempos encontrados

desde a sua inicialização até o momento final no

qual o escravo recebe e interpreta e responde a

mensagem do mestre.

O atraso total Tdelay pode ser resumido como:

Tdelay = AT +AG +AE +AC; (3)

Figura 3: Diagrama temporal do envio de mensagem

Modbus

3.2 Carga máxima da rede e taxa de utilização

A carga máxima da rede equivale a quantidade

máxima mensagens por segundo possíveis de serem

geradas pelo mestre sem que haja problemas

na comunicação. A carga máxima pode ser calculada

como:

Cmax = 1

. (4)

TDelay

Obtida a carga máxima da rede, sua taxa de

utilização pode ser calculada como:


fa

Tx =

Cmax ,

ISSN: 2175-8905 - Vol. X 1181


X SBAI – Simpósio Brasileiro de Automação Inteligente

18 a 21 de setembro de 2011

São João del-Rei - MG - Brasil

onde fa é a frequência de amostragem do nó em

questão.

A frequência máxima de mensagens por nó

(fM) é inversamente proporcional ao número de

nós sendo esta proporção dada por:

fM = Cmax

n

, (5)

onde n é o número de nós escravos da rede.

Os parâmetros apresentados nesta seção serão

utilizados para analisar a rede desenvolvida neste

trabalho. Esta rede é apresentada na próxima seção.

4 Desenvolvimento da Rede Modbus

Na rede desenvolvida, os nós escravos foram construídos

em uma placa-protótipo que contém um

MicrocontroladorPICmodelo18F2550, umRegulador

de Tensão para alimentação, conector USB

para programação in-circuit do PIC e interface

de entrada e saída dos dados RS-485. Esta placa

pode ser vista na Figura 4.

Figura 4: Placa Protótipo para desenvolvimento

da Rede

As configurações escolhidas para a rede foram

limitadas aos componentes utilizados tendo sua

velocidade de transmissão definida em 115,2Kbps

e sem paridade. A transmissão é Half-Duplex e o

modo de ligação das placas é Daisy-Chain.

O nó Mestre corresponde a um PC Mini-

ITX com processador Intel Atom 330 Dual Core

de 1,6GHz. Para que este nó atendesse aos requisitos

temporais, optou-se por escolher um sistema

operacional de tempo real. Em (Barbalace

et al., 2008) são comparados quatros sistemas,

sendo eles o RTAI, o Linux, VxWorks do Windows

e o Xenomai, e seus respectivos tempos de

latência, jitter e reescalonamento. Baseado nos

resultadosdesteartigo, aescolhapeloRTAIsedeu

por ele ser open-source, por ser melhor em termos

temporais que o Xenomai e para manter a compatibilidade

com outros sistemas desenvolvidos no

laboratório. O sistema operacional utilizado foi o

Ubuntu 10.04.1 com kernel 2.6.31.8 e patch RTAI.

Figura 5: Quadro de Mensagem Modbus/RTU.

As mensagens do Mestre trafegadas pela rede

estão conforme o quadro de mensagem Modbus

RTU mostrado na Figura 5, onde o Endereço e a

Função possuem um byte cada uma, os bytes de

dados foram fixados em dois e o CRC possui também

dois bytes totalizando um quadro Modbus de

6 bytes.

Com base neste desenvolvimento, foram levantados

os valores experimentais para as equações

propostas na seção anterior que têm como

base a rede utilizada no veículo autônomo como

será mostrado na próxima seção. Os resultados

mostramqueoAtrasodeGeraçãoémenorque1µs

e varia junto com o schedule e o jitter do sistema

operacionaldetemporeal(Barbalaceetal.,2008).

O Atraso de Transmissão é calculado considerando

que tem-se um quadro Modbus do Mestre

composto por dois bytes de cabeçalho contendo o

endereço e a função (bHeader), dois bytes de dados

(bData) e dois bytes de CRC (bError). Cada

byte contém um start bit (starB) e um stop bit

(stopB) pois não há bit de paridade (parityB).

A Velocidade de comunicação de 115,2Kbps que

fornece um tempo τ de 8,6805µs. O valor encontradoparaoatrasodetransmissão,

utilizando-sea

Equação (2) é de 521µs. O valor obtido no osciloscópio,

dadas as limitações de medição do mesmo,

foide520µsqueébempróximoaovalorcalculado.

OAtrasodeEntregaéumvalorobtidoexperimentalmente.

Nesta rede, o maior valor para este

atraso foi de 355µs nas rotinas necessárias para

interpretação da mensagem enviada por parte do

nó escravo.

O Atraso de Controle utilizado foi de 2,75ms

valor este que comporta o envio de resposta por

parte do escravo com o maior quadro Modbus da

rede e o silêncio de 1,75ms necessário para uma

correta comunicação.

Os valores indicados acima foram obtidos por

meio de medições com um osciloscópio digital. A

Figura6mostraoformatodasmensagensModbus

no barramento 485 como visto na tela do osciloscópio.

Combasenestesvaloresobtidos, acapacidade

suportada pela rede, de acordo com a Equação

(4) é de 275 mensagens por segundo. Em experimentos

realizados com nós escravos mais simples,

foram obtidas taxas de até 380 mensagens por segundo.

ISSN: 2175-8905 - Vol. X 1182


Tensão Normalizada(V)

1.2

1

0.8

0.6

0.4

0.2

X SBAI – Simpósio Brasileiro de Automação Inteligente

18 a 21 de setembro de 2011

São João del-Rei - MG - Brasil

Solicitação do Mestre

Resposta do Escravo

0

0 0.005 0.01 0.015

Tempo(s)

Figura 6: Sequência de Mensagens da Comunicação

Modbus.

5 Utilização da Rede em um Veículo

Autônomo

O CADU (Carro Autônomo Da UFMG) é um veículo

Chevrolet Astra 2003/2004 equipado com sistema

de direção hidráulica, marcha automática,

acelerador eletrônico e freios ABS controlados por

Unidades de Controle Eletrônica (ECU - Electronic

Control Units) e interconectadas por um barramento

CAN (Santos et al., 2008).

Os sistemas atualmente presentes no carro

para controle da velocidade (Freitas et al., 2009)

utilizam-se de comunicação USB e são: Acelerador,

Freio e Sensor de Velocidade das rodas. Estes

sistemas se comunicam com computador rodando

Windows Vista, que também executa o controlador

de velocidade. Neste trabalho, para avaliação

experimental da rede desenvolvida, este sistema

foi substituído por uma rede com um nó mestre

e três nós correspondentes aos sistemas de Acelerador,

Freio e Sensor de Velocidade. De fato,

os subsistemas atualmente instalados no veículo

foram adaptados para que a sua comunicação anteriormente

feita por USB fosse substituída pela

rede Modbus. A adaptação envolveu o uso de novos

conectores e cabos sem contudo ser necessário

a troca do hardware de interface com o veículo.

Um quarto nó foi inserido na rede de modo a permitirumamudançadinâmicadosetpoint

pormeio

de acionamento de botões. Esta abordagem é interessante

pois mostra a capacidade do Mestre de

receber informações ou comandos de outros nós

com a uma latência máxima igual a um período

de amostragem.

Em (Freitas, 2010) foi mostrado que a dinâmica

de aceleração do CADU possui uma constante

de tempo τ próxima de três segundos. As

dinâmicas envolvidasno freioeno aceleradortambém

são lentas o suficiente para que os atrasos

máximos da rede se tornem desprezíveis para os

comandos responsáveis pelo atuador de freios e o

atuador de aceleração. Deste modo, a taxa de

amostragem escolhida de 50Hz para o sensor de

velocidade e os demais nós escravos satisfaz as necessidades

do controlador.

O programa rodando no mestre consistiu em:

(i)obterpormeiodemensagensavelocidadeatual

do veículo medida pelo nó Sensor de Velocidade

das Rodas; (ii) obter o valor da referência fornecido

pelo nó de Setpoint; (iii) Fazer o processamento

com base em um algoritmo de controle

Fuzzy; (iv) enviar a mensagem de atuação para

o nó Freio e (v) enviar a mensagem de atuação

para o nó Acelerador. Com base nesta sequência,

escolheu-se período da tarefa de tempo real igual

20ms no qual serão executados os passos de (i) a

(v), cumprindo-se assim a taxa de amostragem de

50Hz para cada um dos nós presentes na rede.

O Gráfico da Figura 7(a) mostra o comportamento

da velocidade do veículo ao longo do tempo

em relação aos valores de setpoints especificados

enquanto que a Figura 7(b) mostra o comportamento

dos comandos de controle para o freio e

para o acelerador. Observa-se que o controlador

não apresenta um comportamento adequado devido

ao grande overshoot e também à oscilação

na velocidade sendo necessário ajustes para um

controle mais suave. No entanto, o experimento

serviu para validar a rede construída. Ao longo

de 120 segundos foram enviadas 6.000 mensagens

para cada um dos nós com período médio 20ms

e desvio padrão de 0,36ns. O total de mensagens

trafegadas na rede neste intervalo foram de 48.000

sendometadedelasrequisiçõesdomestreeaoutra

metade a resposta dos escravos. Neste intervalo os

nós responderam corretamente a todas as mensagens.

Os valores apresentados na Figura 7 foram

obtidos diretamente do log de mensagens enviadas

e recebidas.

0

0 20 40 60 80 100 120

ISSN: 2175-8905 - Vol. X 1183

Velocidade (Km/h)

Comando do Atuador (%)

30

20

10

100

50

Freio

Acelerador

(a)

(b)

Referência

Velocidade

0

0 20 40 60

Tempo(s)

80 100 120

Figura 7: Controle de Velocidade do CADU

usandoaredeimplementada. (a)Comportamento

da velocidade do veículo. (b) Comandos enviados

aoaceleradoreaofreiodoveículo. Osdadosforam

obtidos por meio das mensagens da rede Modbus.


X SBAI – Simpósio Brasileiro de Automação Inteligente

18 a 21 de setembro de 2011

São João del-Rei - MG - Brasil

6 Conclusões e Trabalhos Futuros

Foi desenvolvida uma rede com base no protocolo

Modbus sobre a camada física RS-485 que

mostrou-se viável para uso em controle e sensoriamento

de veículos autônomos. Do ponto de vista

de uso de recursos de hardware do microcontrolador,

foi verificado que a rede demanda pouca

memória, tanto de programa, quanto de RAM.

O Modbus, de modo geral, mostrou-se uma

alternativa de rede mais simples em comparação

como outras redes, como a CAN, para aplicações

de controle. Dentre as características relevantes

da rede Modbus-485 estão a capacidade de ser implementada

em qualquer dispositivo com interface

serial, bastando a introdução de um transceptor

Max485; a possibilidade de longas distâncias entre

os nós, podendo chegar a até 1.200 metros e taxas

de comunicação que, dependendo do equipamento

utilizado, podem chegar a até 1Mbps; a alta rejeição

à ruído provida pela especificação da comunicação

RS485; a baixa utilização de hardware do

microcontrolador, sendo necessários apenas 3 pinos

para realizar a comunicação; e o determinismo

proveniente da comunicação Mestre-Escravo, permitindoaintegraçãocomsistemasoperacionaisde

tempo real.

As principais limitações da rede desenvolvida

sãorelativasàfrequênciamáximaobtidanacomunicação,

sendo necessário no futuro a substituição

de alguns componentes de modo a se alcançar taxas

de transmissão mais altas. Outro trabalho futuro

será a criação de níveis mais altos de software

no mestre que permitam ao usuário interagir com

o sistema sem a necessidade de conhecimento profundodaredeModbusedesistemasdetemporeal,

conhecimento este necessário na solução atual.

Agradecimentos

O presente trabalho é financiado pela FAPEMIG

e foi realizado com o apoio financeiro da CAPES

- Brasil. Tiago Arruda e Guilherme Pereira são

bolsistas do CNPq.

Érica Campedelli é bolsista

PET/CAPES. Os autores agradecem ao colega

Victor Costa pela ajuda com os experimentos.

Referências

Barbalace, A., Luchetta, A., Manduchi, G., Moro,

M., Soppelsa, A. and Taliercio, C. (2008).

Performance comparison of vxworks, linux,

rtai, and xenomai in a hard real-time application,

Nuclear Science, IEEE Transactions

on 55(1): 435 –439.

de Souza, M. and Pereira, S. L. (2008). Proposta

de um sistema de gestão empregando instrumentação

inteligente e redes de campo na automação

do processo de tratamento de água,

XVII Congresso Brasileiro de Automática.

e Bruce S. Davie, L. L. P. (2004). Redes de computadores

: uma abordagem de sistemas, second

edn, LTC - Livros Técnicos e Científicos.

Farsi, M., Ratcliff, K. and Barbosa, M. (1999).

An overview of controller area network,

Computing & Control Engineering Journal

10(3): 113–120.

Freitas, E. J. R. (2010). Controle longitudinal de

um veículo autônomo, Disponível em http:

//coro.cpdee.ufmg.br/.

Freitas, E. J. R., Vinti, M. N. W., Santos, M. M.,

Iscold, P., Torres, L. A. B. and Pereira, G.

A. S. (2009). Desenvolvimento de automação

embarcada para um robô móvel baseado em

um carro de passeio, IX Simpósio Brasileiro

de Automação Inteligente, pp. 1–6.

Godoy, E. P., Lopes, W. C., Sousa, R. V., Porto,

A. J. V. and Inamasu, R. Y. (2010). Modelagem

e simulação de redes de comunicação

baseadasnoprotocoloCAN-ControllerArea

Network, Sba: Controle & Automação Sociedade

Brasileira de Automatica 21: 425 – 438.

Jeon, J. M., Kim, D. W., Kim, H. S., Cho,

Y. J. and Lee, B. H. (2001). An analysis of

network-basedcontrolsystemusingcan(controller

area network) protocol, Proceedings of

the IEEE International Conference on Robotics

and Automation, pp. 3577 – 3581.

Mod(2011a). MODBUS Application Protocol Specification

v1.1b. Disponivelem, http://www.

modbus.org/. Acessado em 01/2011.

Mod (2011b). Modbus Over Serial Line Especification.

Disponível em http://www.modbus.

org/. Acessado em 01/2011.

Santos, M. M., Freitas, E. J. R., Vinti, M. N. W.,

Iscold, P., Torres, L. A. B. and Pereira, G.

A. S. (2008). Automation and localization of

a robotic car, Proceedings of the 3rd Applied

Robotics and Collaborative Systems Enginnering

(Robocontrol’08).

Téllez-Anguiano, A., Rivas-Cruz, F., Astorga-

Zaragoza, C.-M., Alcorta-García, E. and

Juárez-Romero, D. (2009). Process control

interfacesystemforadistillationplant, Computer

Standards & Interfaces 31(2): 471 –

479.

Xiaodong, N. and Yanjun, Z. (2002). Determining

message delivery delay of controller area

networks,Proceedings. of the IEEE Region 10

Conference on Computers, Communications,

Control and Power Engineering, pp. 767 –

771.

ISSN: 2175-8905 - Vol. X 1184

More magazines by this user
Similar magazines