MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
(Real Academia de Artilharia, Fortificação e Desenho, 1792)
1o Ten RAQUEL LAMPAÇA VIEIRA RADOMAN
SISTEMA MULTI-PROTOCOLO PARA TRANSFERÊNCIA DE DADOS
Rio de Janeiro
2013
INSTITUTO MILITAR DE ENGENHARIA
1o Ten RAQUEL LAMPAÇA VIEIRA RADOMAN
SISTEMA MULTI-PROTOCOLO PARA TRANSFERÊNCIA DE DADOS
Projeto de Fim de Curso apresentado ao Curso de Graduação
em Engenharia Eletrônica do Instituto Militar de Engenharia.
Orientador: Cel R/1 Marcus Vinícius dos Santos Fernandes –
D.C.
Rio de Janeiro
2013
2
c2013
INSTITUTO MILITAR DE ENGENHARIA
Praça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro - RJ
CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, que poderá incluí-lo em base de
dados, armazenar em computador, microfilmar ou adotar qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entre bibliotecas deste trabalho,
sem modificação de seu texto, em qualquer meio que esteja ou venha a ser fixado, para pesquisa
acadêmica, comentários e citações, desde que sem finalidade comercial e que seja feita a referência
bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade dos autores e do orientador.
623.043
R131s
Radoman, Raquel Lampaça Vieira
Sistema Multiprotocolo para transferência de Dados; orientado por
Marcus Vinícius dos Santos Fernandes. - Rio de Janeiro: Instituto
Militar de Engenharia, 2013.
88 p.: il.
Projeto de Final de Curso - Instituto Militar de Engenharia –
Rio de Janeiro, 2013.
1. Engenharia Eletrônica. 2. Controle remoto. 3. Rastreamento. 4.
Microcontrolador. 5. GPRS. 6. AT. 7. Domótica. 8. Protocolos
I. Fernandes, Marcus Vinícius dos Santos. II. Título. III. Instituto
Militar de Engenharia.
CDD 623.043
3
INSTITUTO MILITAR DE ENGENHARIA
1o Ten RAQUEL LAMPAÇA VIEIRA RADOMAN
SISTEMA MULTI-PROTOCOLO PARA TRANSFERÊNCIA DE DADOS
Projeto de Fim de Curso apresentado ao Curso de Graduação em Engenharia Eletrônica do Instituto
Militar de Engenharia.
Orientador: Cel R/1 Marcus Vinícius dos Santos Fernandes- D.C.
Aprovada em 25 de outubro de 2013 pela seguinte Banca Examinadora:
__________________________________________________________________
Marcus Vinícius dos Santos Fernandes - Cel R/1
___________________________________________________________________
Mauro Cezar Rebello Cordeiro – Maj
___________________________________________________________________
Amarildo Teodoro da Costa – D.Sc
Rio de Janeiro
2013
4
SUMÁRIO
1. Introdução ............................................................................................................................. 12
1.1 Objetivo ............................................................................................................................. 12
1.2 Justificativa........................................................................................................................ 12
1.3 Metodologia ...................................................................................................................... 13
1.4 Estrutura ............................................................................................................................ 13
2. Revisão de Literatura ............................................................................................................ 14
2.1 Tecnologia GSM/GPRS .................................................................................................... 14
2.2 Módulo GSM/GPRS GM862-QUAD ............................................................................... 14
2.3 Comandos AT ................................................................................................................... 15
2.4 A rede de comunicação ..................................................................................................... 15
2.5 O reed-switch .................................................................................................................... 17
2.6 O relé ................................................................................................................................. 17
2.6.1 Funcionamento do relé ............................................................................................... 18
2.6.2 Circuito do Relé ......................................................................................................... 18
2.7 O LDR (Light Dependent Resistor) .................................................................................. 19
2.8 Protocolo Modbus ............................................................................................................. 20
2.8.1 Estrutura mestre / escravo .......................................................................................... 20
2.8.2 Formato da mensagem ............................................................................................... 21
2.8.2.1 Endereço do escravo ........................................................................................... 21
2.8.2.2 Função ................................................................................................................ 21
2.8.2.3 Parâmetros ou dados ........................................................................................... 21
2.8.2.4 Checagem de erro ............................................................................................... 22
2.8.3 Modos de transmissão ................................................................................................ 22
2.8.3.1 Modo de transmissão ASCII ............................................................................... 23
2.9 Arquitetura OSI ................................................................................................................. 23
2.9.1 Camada de Aplicação ................................................................................................ 25
2.9.1.1 Protocolo FTP ..................................................................................................... 26
2.9.1.2 Protocolo SMTP ................................................................................................. 26
2.9.1.2.1 A Base 64 .................................................................................................... 27
2.9.1.2.2 Processo de autenticação ............................................................................. 28
2.9.2 Camada de Transporte ............................................................................................... 29
2.9.2.1 Protocolo TCP versus UDP ................................................................................ 29
2.9.3 Camada de Rede ........................................................................................................ 30
2.9.3.1 Protocolo IP ........................................................................................................ 30
2.10 GPS ................................................................................................................................. 30
2.10.1 NMEA formato RMC .............................................................................................. 30
2.11 EasyPIC5 ......................................................................................................................... 31
3. Descrição dos projetos ........................................................................................................... 32
3.1 Casa Inteligente ................................................................................................................. 32
3.2 Rastreamento de veículo ................................................................................................... 32
4. Implementação ....................................................................................................................... 33
4.1 Casa Inteligente: ................................................................................................................ 33
4.1.1 Hardware:................................................................................................................... 33
4.1.1.1 Dispositivos controlados..................................................................................... 36
4.1.1.1.1 Acionamento do alarme .............................................................................. 37
5
4.1.1.1.2 Acende / apaga lâmpada .............................................................................. 38
4.1.1.1.3 Controle de luminosidade............................................................................ 39
4.1.2 Software ..................................................................................................................... 41
4.1.2.1 Comunicação cliente/servidor ............................................................................ 41
4.1.2.2 Comunicação modem/ PIC ................................................................................. 45
4.2 Sistema de rastreamento de veículo .................................................................................. 49
4.2.1 Hardware .................................................................................................................... 49
4.2.2 Software ..................................................................................................................... 51
4.2.2.1 Testes realizados com SMTP.............................................................................. 51
4.2.2.2 Teste do funcionamento do protocolo FTP ........................................................ 53
4.2.2.3 Elaboração do código ......................................................................................... 54
4.2.2.3.1 Funções........................................................................................................ 54
4.2.2.3.2 Considerações sobre o código ..................................................................... 59
5. Funcionamento do projeto .................................................................................................... 65
5.1 Casa inteligente ................................................................................................................. 65
5.2 Rastreamento de um veículo frigorífico ............................................................................ 66
6. Dificuldades e limitações do projeto .................................................................................... 70
6.1 Casa Inteligente ................................................................................................................. 70
6.2 Rastreamento de veículo frigorífico .................................................................................. 71
7. Trabalhos futuros .................................................................................................................. 71
8. Conclusão ............................................................................................................................... 71
9. Referências Bibliográficas .................................................................................................... 72
ANEXO ....................................................................................................................................... 74
6
LISTA DE FIGURAS
Figura 1 - Modem GSM/GPRS ............................................................................................................................. 15
Figura 2 - Ligação do CI MAX232 na interface RS232 para conversão TTL/ RS232 (Autor:
Rogercom.com) ............................................................................................................................................ 16
Figura 3 - Ligação do CI MAX485 para conversão de TTL/RS485 ..................................................................... 16
Figura 4 - Funcionamento do reed-switch ............................................................................................................. 17
Figura 5 - Tipos de relé ......................................................................................................................................... 17
Figura 6 - Estrutura do relé.................................................................................................................................... 18
Figura 7 - Circuito do relé ..................................................................................................................................... 18
Figura 8 - Contatos do relé .................................................................................................................................... 19
Figura 9 – LDR ..................................................................................................................................................... 19
Figura 10: Arquitetura OSI de redes e a função de cada camada .......................................................................... 25
Figura 11: Protocolo FTP ...................................................................................................................................... 26
Figura 12: Exemplo de conversão de ASCII em base64 e a tabela de correspondência aos índices .................... 28
Figura 13: EasyPIC5 ............................................................................................................................................. 31
Figura 14 - Pinos do conector DB9 ....................................................................................................................... 33
Figura 15 - Projeto do circuito do PIC16F628 mestre .......................................................................................... 34
Figura 16 - Montagem do circuito em protoboard ................................................................................................ 34
Figura 17 - Fresadora Lpkf .................................................................................................................................... 35
Figura 18 - Esquemático do circuito do MAX232 ................................................................................................ 35
Figura 19: Comunicação modem/ PIC .................................................................................................................. 36
Figura 20 - Esquemático do circuito do PIC 16F628 ............................................................................................ 36
Figura 21 - Esquemático do circuito do alarme..................................................................................................... 37
Figura 22: Montagem do circuito do alarme ......................................................................................................... 38
Figura 23 - Esquemático do circuito da lâmpada .................................................................................................. 38
Figura 24: Circuito de acionamento da lâmpada ................................................................................................... 39
Figura 25 - Esquemático do circuito do LDR ....................................................................................................... 40
Figura 26 - Esquemático do PIC 16F877A escravo .............................................................................................. 40
Figura 27 - Configuração da conexão cliente ........................................................................................................ 41
Figura 28 - Conexão cliente .................................................................................................................................. 42
Figura 29 - Conexão na rede GPRS ...................................................................................................................... 43
Figura 30 - Configuração da conexão servidor ..................................................................................................... 44
Figura 31 - Socket full duplex ............................................................................................................................... 45
Figura 32 - Rotina de recepção de caracteres ........................................................................................................ 46
Figura 33 - Caractere 'VT' ..................................................................................................................................... 47
Figura 34 - Envio de comandos ao Modem........................................................................................................... 48
Figura 35 - Comunicação bidirecional .................................................................................................................. 49
Figura 36: Display de LCD acompanhando o envio dos comandos AT ............................................................... 50
Figura 37: Conexão com o servidor SMTP "gmail".............................................................................................. 51
Figura 38: Conexão SMTP com o "gmail" bem sucedida por Telnet ................................................................... 52
Figura 39: Função TX para transferência de caracteres ........................................................................................ 54
Figura 40: Primeira parte da função RX................................................................................................................ 55
Figura 41: Segunda parte da função RX................................................................................................................ 56
Figura 42: Função codetxt_to_ramtxt ................................................................................................................... 56
Figura 43: Separação das strings de dados na função GPS ................................................................................... 57
7
Figura 44: Reordenação dos caracteres de Data .................................................................................................... 58
Figura 45: Parte da função "leitura_botoes" .......................................................................................................... 58
Figura 46: Uso do contador auxiliar na função leitura_botoes .............................................................................. 59
Figura 47: Especificação de registradores e baud rate .......................................................................................... 60
Figura 48: Exemplo de envio de comando para o modem e análise da resposta................................................... 60
Figura 49: Nomeação do arquivo salvo no servidor FTP ...................................................................................... 61
Figura 50: Envio da sequência de escape "+++" ................................................................................................... 62
Figura 51: Abertura de socket TCP ....................................................................................................................... 62
Figura 52: Recebimento dos comandos do servidor TCP ..................................................................................... 63
Figura 53: Programa terminal HDC-Control......................................................................................................... 64
Figura 54: HDC-Creator........................................................................................................................................ 65
Figura 55: Comunicação bidirecional servidor TCP - modem .............................................................................. 66
Figura 56: Início da simulação do funcionamento do sistema .............................................................................. 67
Figura 57: Arquivos salvos no servidor FTP......................................................................................................... 68
Figura 58: Comunicação bidirecional no servidor TCP ........................................................................................ 69
Figura 59: Confirmação do recebimento do comando "1" .................................................................................... 69
Figura 60: Mensagem visualizada pelo condutor do veículo e confirmação de recebimento do
comando "3" ................................................................................................................................................. 70
8
LISTA DE TABELAS
Tabela 1 - Estrutura do framing ............................................................................................................................ 21
Tabela 2 - Tipos de erro ........................................................................................................................................ 21
Tabela 3: Funcionalidade dos botões e LEDs ....................................................................................................... 50
9
RESUMO
As áreas de sistemas de controle e rastreamento remoto tem se tornado cada vez mais
populares, pois oferecem ao usuário maior segurança e facilidade de operação. A comunicação de
dados entre dispositivos, ou entre o cliente e servidor, é um dos fatores mais importantes para o
funcionamento de projetos nessas áreas. A transferência mútua de dados nesses sistemas se dá por
meio de protocolos de comunicação, funcionando à base da conexão com a rede GPRS. Uma
maneira eficaz e de baixo custo de tornar isso possível é abordada nesse trabalho, que explora os
padrões de rede serial RS485 e o microcontrolador PIC, para comunicação entre os dispositivos, e os
protocolos FTP e TCP, para registrar informações do sistema em um servidor e permitir o envio de
comandos. A comunicação foi realizada via modem GSM/GPRS da Telit.
Palavras-chave: protocolos, GPRS, AT, modem, microcontrolador, controle remoto,
rastreamento, domótica.
10
ABSTRACT
The fields of control systems and remote tracking has become increasingly popular because they
offer the user more safety and ease of operation. The data communication between devices, or
between a client and a server, is one of the most important factors for the operation of projects in
these areas. The mutual transfer of data in these systems is by means of communication protocols,
operating on the basis of the connection to the GPRS network. An effective and low cost way to
make this possible is discussed in this paper, which exploits network standards RS485 and PIC
microcontroller for communication between devices, and FTP and TCP protocols to record system
information on a server and allow sending commands. The modem GSM/GPRS Telit was used to
establish the communication with the servers.
Keywords: protocols, GPRS, modem, AT, remote control, microcontroller, home automation,
tracking.
11
1. Introdução
Ao longo do tempo, a computação vem ajudando pessoas comuns a fazerem seus trabalhos
de forma cada vez mais rápida e eficiente. Com o advento da automação, tarefas repetitivas podem
ser realizadas por máquinas. Ao mesmo tempo, com o avanço das telecomunicações, principalmente
da comunicação sem fio, os dispositivos móveis vem ganhando espaço considerável no mercado de
transmissão de dados. O controle remoto de dispositivos envolve automação e comunicação sem fio,
com transferência de dados.
Gradativamente, a automação vem se tornando comum nas instalações residenciais, visando
o conforto, entretenimento, economia e segurança, resultando no que pode ser chamado de domótica.
Os sistemas domóticos permitem a gestão de todos os recursos habitacionais, através da utilização de
computadores, controle remoto, aparelhos celulares, e outros dispositivos fixos e móveis capazes de
realizar tarefas complexas e interagir com o usuário e com o meio físico. Em outras palavras,
remotamente, permitem ligar ou desligar uma televisão, abrir ou fechar uma persiana, aumentar ou
diminuir a temperatura de um ar-condicionado, entre outros.
Outro sistema que explora bastante o uso da automação com a comunicação sem fio é o de
rastreamento de carros. O rastreamento vem se tornando a nova tendência no controle e segurança de
veículos, sejam eles leves ou pesados. Permite ao usuário interagir com seu veículo direta ou
indiretamente, possibilitando controlar diversas funções e obter informações à distância. Os
servidores de centrais de monitoramento recebem diretamente de cada veículo diversas informações
de localização, através de transmissão em tempo real via internet móvel GPRS (General Packet
Radio Service). Com a ampliação dos sistemas de telefonia celular GSM e seu protocolo de
comunicação GPRS, os sistemas de rastreamento passaram a ter seus custos bastante reduzidos. A
qualquer momento podem ser enviados remotamente comandos específicos aos veículos. Pode-se
solicitar bloqueio de combustível e alarme, como exemplo. Os comandos podem ser enviados ao
mesmo tempo em que se rastreia o veículo. Assim, ele para de funcionar ao mesmo tempo em que é
localizado.
O presente trabalho visa mostrar uma solução de baixo custo para dois projetos: um de
automação residencial e outro de rastreamento e monitoramento remoto de veículos. Usando chips
microcontroladores e uma rede RS-485 para comunicação entre eles e um modem GSM/GPRS, será
desenvolvido um sistema capaz de controlar a iluminação e equipamentos elétricos de uma
residência, através da rede GPRS. No outro projeto, será desenvolvido um sistema que lê os dados de
sensores presentes no veículo, assim como informações de um GPS, e guarda essas informações em
um servidor FTP, além de também permitir que o usuário envie comandos ao seu veículo
remotamente. Para tal, também serão utilizado o modem GPRS e microcontrolador PIC 16F877A.
1.1 Objetivo
Este trabalho tem como objetivo realizar o estudo de protocolos de comunicação e suas
aplicações em sistemas de rastreamento de veículos e controle remoto de dispositivos residenciais.
1.2 Justificativa
Uma casa inteligente contém um sistema capaz de gerenciar todo o tráfego de informações, bem
como o controle de equipamentos, permitindo um conforto maior com o menor gasto possível de
energia. Os sistemas de segurança, os sistemas de aquecimento, ventilação e ar-condicionado, e
entretenimento tendem a beneficiar as novas construções, mas os projetos de reforma também podem
12
ser contemplados com esta nova tecnologia. Com isso, a centralização dos sistemas de controle tende
a diminuir o tempo gasto com o projeto e a facilitar a manutenção. Permite também a busca de
possíveis erros, de forma rápida, assim como o disparo das ações necessárias para solucioná-los.
Com a aplicação certa das técnicas, pode-se conseguir atingir altos níveis de conforto e segurança a
custos relativamente baixos.
A busca pela praticidade e segurança não se restringe a residências, também pode acompanhar o
usuário em seu veículo. O índice de roubos de carros nas grandes metrópoles é bastante alto. Mesmo
com seguro, as consequências de um roubo não são nada agradáveis. O carro é encontrado em estado
ruim e o seguro não reembolsa o prejuízo. Para evitar problemas, existem vários tipos de
equipamentos contra roubos e furtos. Rastreadores, bloqueadores e alarmes são as principais ofertas
para a segurança de um veículo.
Para uma boa parte da população, o conforto, comodidade e a segurança providos pela
domótica, não passam de um sonho de consumo inatingível. No entanto, esta realidade pode ser
modificada com soluções que proporcionem tais benefícios, aliando também, um projeto de baixo
custo. Outro sistema que é altamente desejado, mas que necessita de progresso, é o de rastreamento e
controle de veículos. Aliando o conforto da residência com a segurança de seu veículo, o usuário se
sente mais livre para usufruir de seus bens e se deslocar para onde desejar. Dentro deste cenário, este
trabalho tem o desafio de apresentar uma solução simples de domótica, que possui baixo custo, com
o objetivo de desmistificar a ideia de que a automação residencial não é uma tecnologia palpável, e
de representar de uma maneira simples e prática o funcionamento de um sistema de rastreamento e
controle de veículos.
1.3 Metodologia
O trabalho foi constituído por duas partes: na primeira, foi feito um modelo de casa inteligente,
cujo funcionamento é baseado em controle remoto de dispositivos. Na segunda, foi realizada a
simulação de um sistema de rastreamento de veículos. Ambas as etapas fazem uso de protocolos de
comunicação. Para tal, primeiramente foi feito um estudo sobre o modem utilizado e os comandos
AT necessários para o projeto. Depois, realizou-se a comunicação entre dois modems (um deles
ligado a um computador de IP fixo e outro, a um computador conectado à rede GPRS, provida por
empresa de telefonia celular). Em seguida, foi proposto um modelo de casa inteligente e
desenvolveram-se o hardware e o software de controle necessários à sua implementação. Após isso,
foi feito o estudo dos protocolos SMTP e FTP, seguido pela aplicação dos mesmos na realização da
simulação de um sistema de rastreamento de veículo.
1.4 Estrutura
O trabalho está estruturada da seguinte forma: no item 2, é feita uma revisão da literatura
utilizada. No item 3, é feita uma descrição dos projetos. No item 4, é descrita a implementação dos
projetos (hardware e software). No item 5, são apresentados os testes e a fase final do projeto. O item
6 mostra as principais dificuldades enfrentadas. No item 7, são citados os possíveis trabalhos
futuros. No item 8 é feita a conclusão. A bibliografia está disponível no item 9. Por fim, são
apresentados em anexo os códigos utilizados nos projetos.
13
2. Revisão de Literatura
2.1 Tecnologia GSM/GPRS
A tecnologia GSM/GPRS é uma integração das redes GSM com GPRS (General Packet Radio
Service), ou seja, é a junção de uma rede GPRS em cima da outra rede celular GSM, que possui
abrangência global. Com a popularização do uso da internet e de outros serviços de dados, observouse que as redes GSM não comportariam grandes quantidades de dados nos diferentes estágios do
sistema. Por esse motivo, as redes GPRS foram desenvolvidas para aceitar serviços de dados, pois
foram criadas com base em transmissão por comutação de pacotes, que utiliza a fonte de rádio para
tráfego em rajadas. Para que as operadoras possam utilizar os serviços GSM e GPRS, os dois
sistemas compartilham características entre si, tais como as bandas de freqüência, a estrutura de
frames e técnicas de modulação. Mas, no entanto, a cobrança pelo uso do sistema GPRS é feita pela
quantidade de dados transmitidos, enquanto que no sistema GSM, é feita por tempo de conexão. A
tecnologia GSM/GPRS explora as redes celulares e internet, e esta integração com a internet é umas
das grandes vantagens do sistema GPRS, porque permite a conexão com qualquer ponto do mundo
em diferentes equipamentos. Essa versatilidade do sistema é algo importante em qualquer sistema de
monitoramento remoto de dados. O sistema possui também recursos de segurança, chaves de
autenticação, código de identificação pessoal (Código PIN – Personal Identification Number), etc.,
que podem ser usados para controlar e proteger conexões entre os dispositivos. A transmissão de
dados pode ser feita através de duas maneiras: via GPRS- Internet ou via SMS (Short Message
Services). A transmissão de dados via GPRS – Internet é feita na forma de protocolos em camadas.
A rede GPRS utiliza dois tipos de protocolos para a transferência de dados, o IP e o X.25.
2.2 Módulo GSM/GPRS GM862-QUAD
O módulo de comunicação usado no projeto é o modelo GM862 (Telit), que é utilizado em
larga escala no mercado. O módulo GSM/GPRS GM862 (Figura 1) é uma interface compacta que
apresenta as seguintes características:
 Baixo consumo;
 Possui memória flash e RAM;
 Alimentação 12 Volt;
 Possui conector de antena GSM;
 Possui entrada para cartão SIM;
 Possui saída serial.
 Formato de comunicação de alto nível (comandos AT);
 SMS (Short Message Service);
 Pilha TCP/IP interna;
 Acesso à rede GSM/GPRS.
O módulo trabalha com banda Quad-Band EGSM 850/900/1800/1900 MHz e classe B de
estação móvel. O multiplexador GSM 7.10 permite a aquisição de dados via porta serial, com
integração à internet via arquitetura TCP/IP. Oferece um desempenho de voz, SMS, dados e fax. A
Figura 1 mostra o modem GSM/GPRS externamente e a antena GSM. O modem possui os seguintes
conectores de interfaceamento: conector da antena, da fonte de alimentação, entrada serial e entrada
para o chip SIM.
14
Figura 1 - Modem GSM/GPRS
2.3 Comandos AT
Os modems são módulos largamente divulgados, com ligação à rede telefônica, e cuja interface
com computadores pessoais seguem as normas standard. A troca de informações entre um
computador e um modem ligado via porta serial utiliza geralmente um protocolo, designado como
comandos AT. O padrão AT é uma linguagem de comandos orientados por linha. Cada comando é
constituído por três elementos: o prefixo, o corpo de comando, e o caractere de fim de comando ou
terminação. O prefixo consiste nos caracteres “AT”. O corpo de comando é constituído por
caracteres individuais. E o caractere de fim de comando é o “<CR>”.
Segundo Arthut (2007), uma linha de comando AT pode conter um ou mais comandos, usando
delimitadores para separar cada comando. Esse delimitador pode ser um ponto e vírgula ou um
espaço para comandos básicos.
Quando um comando é enviado, o modem responde com uma mensagem (Result Code), ou
“Código Resultante”, que avisa para o modem o resultado do comando que foi requisitado. Os
comandos AT são projetados de acordo com a ITU (International Telecommunication Union).
2.4 A rede de comunicação
A rede de comunicação escolhida para a implementação do sistema de controle remoto foi a
rede RS485, por ser uma rede robusta e bastante utilizada, por poder operar no modo multiponto,
possuir capacidade de comunicação com cabos de grandes comprimentos e facilidade de conversão
do padrão RS232 para o padrão RS485, características essenciais para a rede deste protótipo. Para
que os dispositivos pudessem se comunicar por esta rede, foram necessários circuitos integrados
conversores, que serviram para converter os sinais do padrão RS232 do modem para o padrão TTL e
os sinais TTL do microcontrolador para RS485. A seguir, pode ser visto o modo de ligação destes
circuitos integrados na rede de comunicação. A Figura 2 mostra a ligação do CI MAX232 para
converter os sinais da interface RS232 do modem para os sinais TTL. Já a Figura 3, mostra a ligação
do CI MAX485 para converter os sinais TTL dos microcontroladores para os sinais do padrão
RS485.
15
Figura 2 - Ligação do CI MAX232 na interface RS232 para conversão TTL/ RS232 (Autor:
Rogercom.com)
Figura 3 - Ligação do CI MAX485 para conversão de TTL/RS485
(Autor: Rogercom.com)
O RS-485 é um padrão elétrico utilizado para comunicação de dados de alta velocidade, em
distâncias de até 1200 metros, sendo adequado para ambientes expostos a elevados níveis de
distúrbios. Suas principais características são:
• Transmissão diferencial balanceada;
• Característica multiponto;
• Apenas uma fonte simples de +5V para alimentar os circuitos de transmissão e recepção;
• Transmissão de dados em modo comum com tensões de -7V até +12V;
• Suporta até 32 dispositivos.
A distância do cabo depende da taxa de transmissão utilizada. Por exemplo, uma taxa de
transmissão de dados de 10Mbps pode ocorrer até uma distância máxima de 12 metros, enquanto
taxas de transmissão de até 100kbps podem ocorrer em distâncias de até 1200 metros.
16
2.5 O reed-switch
O reed-switch é composto de uma cápsula de vidro e de duas lâminas de um material
ferromagnético (ligas de níquel e ferro). As duas lâminas são colocadas muito próximas, sem que
haja contato entre elas (com uma extremidade afixada no vidro) e mergulhadas num gás inerte, para
não sofrerem oxidação ou deformação mecânica (para durarem mais).
- Para acionar o reed-switch, isto é, para haver contato elétrico entre as lâminas, é necessário
induzir a magnetização delas, fazendo com que elas se atraiam magneticamente. Basta aproximar um
pequeno ímã do reed-switch, como mostra a Figura 4.
- São usados para acionar, magneticamente, dispositivos eletro-eletrônicos como alarmes,
trancas elétricas, portas, circuitos eletrônicos de partida.
Figura 4 - Funcionamento do reed-switch
2.6 O relé
Os relés são dispositivos comutadores electromecânicos. Representam-se pelo símbolo:
Relé Simples
Relé duplo
Figura 5 - Tipos de relé
Uma bobina ao ser percorrida por uma corrente, gera um campo magnético no seu núcleo que
atrai um ou vários contatos elétricos, permitindo ligar, desligar ou comutar um circuito elétrico
externo.
17
Figura 6 - Estrutura do relé
No exemplo da imagem, uma bobina, ao receber uma tensão nos seus terminais, cria um campo
magnético que, através do seu núcleo, atrai o induzido, fechando os contatos entre os pontos A e B.
2.6.1 Funcionamento do relé
No funcionamento de um relé, na sua forma mais comum de aplicação permite três tipos básicos
de funcionamento.



Fig.1- O relé fecha o circuito entre os terminais A e B.
Fig.2- O relé abre o circuito entre os terminais A e B.
Fig.3- O relé comuta a tensão que entra no terminal A comutando entre o terminal B e C.
2.6.2 Circuito do Relé
A figura abaixo mostra o circuito de funcionamento de um relé:
Figura 7 - Circuito do relé
A estrutura do relé permite, ao ser energizado com correntes muito pequenas, em relação à
corrente do circuito controlado, o controle de circuitos de altas correntes (motores, lâmpadas,
18
máquinas industriais...), diretamente a partir de dispositivos eletrônicos fracos, (transistores, circuitos
integrados, fotorresistores, etc).
Figura 8 - Contatos do relé
2.7 O LDR (Light Dependent Resistor)
LDR é um componente eletrônico passivo do tipo resistor variável, mais especificamente, é um
resistor cuja resistência varia conforme a intensidade da luz que incide sobre ele. Tipicamente, à
medida que a intensidade da luz aumenta, a sua resistência diminui. O LDR é construído a partir de
material semicondutor com elevada resistência elétrica. Quando a luz que incide sobre o
semicondutor tem uma frequência suficiente, os fótons que incidem sobre o semicondutor libertam
elétrons para a banda condutora que irão melhorar a sua condutividade e assim diminuir a
resistência. Os resultados típicos para um LDR poderão ser:


Escuridão: resistência máxima, geralmente mega ohms.
Luz muito brilhante: resistência mínima, geralmente dezenas de ohms.
Figura 9 – LDR
19
2.8 Protocolo Modbus
O protocolo Modbus foi desenvolvido em 1979 pela empresa MODICON, Inc., Industrial
Automation System, que define um protocolo de aplicação do tipo cliente/ servidor entre os
dispositivos conectados, independentes do meio físico utilizado. A estrutura de comunicação
Modbus atualmente pode ser implementada em:
• TCP/IP sobre Ethernet
• Mestre / Escravo em transmissão serial assíncrona sobre vários meios (EIA/TIA 232-E, EIA-422,
EIA/TIA-485; fibra óptica, rádio, etc.) e
• Modbus Plus em rede token pass de alta velocidade.
2.8.1 Estrutura mestre / escravo
O sistema desenvolvido utiliza o protocolo Modbus na estrutura mestre / escravo, que
basicamente é constituída por uma estrutura de mensagens compostas por bytes e que determina
como cada dispositivo:
• Identifica seu endereço na rede;
• Reconhece uma mensagem endereçada a ele;
• Determina o tipo de ação a ser executada;
• Obtém toda a informação necessária para executar a ação.
Havendo necessidade de responder ao comando recebido, o dispositivo envia uma
mensagem, mesmo ocorrendo erro na ação a ser executada. Apenas um dispositivo (mestre) pode
iniciar a comunicação (chamada query) e os outros dispositivos (escravos) respondem enviando os
dados requisitados pelo mestre ou realizando uma ação solicitada pela query. O mestre pode
endereçar um escravo individualmente ou iniciar uma mensagem broadcast para todos os escravos.
Apenas o escravo endereçado retorna uma mensagem (chamada response) a uma query. Responses
nunca são retornadas para query do tipo broadcast.
O protocolo Modbus estabelece o formato para a query definindo:
• O endereço do escravo (ou broadcast);
• Código da função que define a ação a ser realizada pelo escravo;
• Parâmetros ou dados pertencentes à função;
• Checagem de erro.
As responses são construídas também nos mesmos moldes da query, obedecendo ao formato
correspondente à função enviada pelo mestre, definindo:
• A confirmação da ação realizada;
• Parâmetros ou dados pertencentes à função solicitada;
• Checagem de erro para verificar a integridade da mensagem enviada.
Se o escravo for incapaz de executar a ação pedida, o escravo construirá uma mensagem de
erro e irá emiti-la na resposta. Se um erro ocorrer no recebimento da mensagem, o escravo não
responde à query, pois no erro de comunicação, dois ou mais escravos poderiam responder à query
ao mesmo tempo.
20
2.8.2 Formato da mensagem
Na mensagem do protocolo Modbus mestre / escravo, há identificadores de início e fim de
framing. Este recurso permite aos dispositivos da rede detectarem o início de uma mensagem, ler o
campo de endereço e determinar qual dispositivo está sendo endereçado (ou todos, se a mensagem é
broadcast), e reconhecer quando a mensagem é completada. As mensagens poderão ser detectadas
parcialmente podendo gerar erros de acordo com o resultado. O formato do framing Modbus mestre /
escravo, como mostra a Tabela 1 é constituído de seis campos: início do framing, o endereço do
escravo que deve receber a mensagem, o código da função a ser executada, os parâmetros ou dados
da função, um campo para checagem de erro e, por último, indicação do fim do framing.
Tabela 1 - Estrutura do framing
Início da
mensagem
Endereço
escravo
Função
Parâmetros ou
dados
Checagem de
erro
Fim da
mensagem
2.8.2.1 Endereço do escravo
A faixa de endereços válidos para os escravos é de 0 a 247. Individualmente os dispositivos
escravos são endereçados de 1 a 247. O mestre endereça o escravo colocando o seu endereço no
campo de endereço da mensagem e quando o escravo envia uma response, ele coloca o seu próprio
endereço no campo de endereço da mensagem para que o mestre reconheça qual escravo está
respondendo. O endereço 0 é utilizado para acesso tipo broadcast, em que todos os escravos
reconhecem, mas não realizam responses.
2.8.2.2 Função
O código da função varia de 0 a 255, sendo o número 0 reservado para a função de
broadcast, e os números 128 a 255 reservados para representação de erro. Quando um escravo
responde a uma requisição, ele usa o campo de função para indicar execução normal ou erro. Em
caso de erro, o sétimo bit do campo função estará em nível 1. Em caso de execução normal, o código
da função é deixado intacto e é ecoado na resposta. Por exemplo, se ocorrer algum tipo de erro, ao
invés do escravo retornar a função 05h (0000 0101), que foi enviada, o escravo retornará 85h (1000
0101) no campo de função, indicando a ocorrência de erro e juntamente com esta sinalização, o
escravo coloca no campo de dados um código que indica o tipo de erro.
2.8.2.3 Parâmetros ou dados
O campo de dados é usado para transportar informações adicionais que o escravo pode usar
para execução da ação especificada no campo de função pelo mestre. Este campo é constituído por
conjuntos de 2 dígitos hexadecimais na faixa de 00h a FFh. Se nenhum erro ocorrer, o campo de
dados do escravo conterá as informações requisitadas pelo mestre. Se algum erro ocorrer, o campo
conterá o código do tipo de erro, como mostra a Tabela 2, juntamente com o sétimo bit do campo
função em nível 1.
Tabela 2 - Tipos de erro
21
Código
Identificação
Significado
01h
Função inválida
02h
Sensor ou registrador
Inválido
03h
Valor de dados inválido
04h
Falha no dispositivo
05h
Estado de espera
06h
Dispositivo ocupado
07h
Não reconhecimento
08h
Erro de paridade de
memória
A função solicitada pelo mestre
não está implementada no
escravo.
O escravo não possui o sensor ou
registrador
especificado
no
comando enviado pelo mestre.
Algum valor no campo de dados
é inválido.
Erro por parte do escravo durante
a execução solicitada pelo mestre.
O escravo reconheceu o comando
do mestre, mas o notifica que o
mesmo será processado num
período maior que o normal.
O escravo está atendendo outro
comando.
O escravo não conseguiu executar
o comando.
O escravo detectou erro de
paridade.
2.8.2.4 Checagem de erro
Há dois tipos de métodos para checagem de erro para o protocolo Modbus mestre / escravo:
o LRC (Longitudinal Redundancy Check) e o CRC (Cyclical Redundancy Check). Estes métodos
dependem do tipo do modo de transmissão utilizado. O sistema desenvolvido utiliza como método
para a checagem de erro o LRC, que consiste na soma dos valores dos campos da mensagem,
excluindo o início de mensagem, “:” (3Ah), e fim de mensagem, CRLF (0Dh 0Ah). O dispositivo
que recebe a mensagem recalcula um LRC durante o recebimento do framing, e compara o valor
calculado ao valor real que recebeu no campo de LRC. Se os dois valores não forem iguais, há
ocorrência de erro.
2.8.3 Modos de transmissão
A estrutura Modbus mestre / escravo pode trabalhar em dois modos de transmissão serial:
ASCII (American Standard Code for Information Interchange) ou RTU (Remote Terminal Unit). O
modo de transmissão determina a configuração binária das mensagens que trafegam na rede e como
os dados serão empacotados na mensagem e decodificados. Estabelecido o modo de transmissão,
devem-se definir os parâmetros da porta serial (baud rate, paridade, etc.). O modo e os parâmetros da
serial devem ser os mesmos para todos os dispositivos da rede. O modo ASCII foi utilizado como
modo de transmissão porque permite
intervalos de até 1 segundo entre a transmissão de caracteres consecutivos sem que um erro de
timeout seja gerado. Entretanto, no modo ASCII, cada byte é enviado como 2 caracteres ASCII
usando os caracteres “0 - 9” e “A - F”.
22
2.8.3.1 Modo de transmissão ASCII
Neste modo, as mensagens são iniciadas com o caractere“:”, valor ASCII 3Ah, e terminadas
com os caracteres de retorno – avanço de linha (CR - LF), valores ASCII 0Dh e 0Ah
respectivamente. Os caracteres permitidos na transmissão para os outros campos da mensagem são
“0” a “9” e “A” a “F” correspondentes aos caracteres ASCII 30h a 39h e 41h a 46h, respectivamente.
Quando os dispositivos são configurados para comunicar em modo ASCII, em cada byte da
mensagem são enviados dois caracteres ASCII (0 a 9 ou A a F). A principal vantagem deste modo é
que ele permite um grande intervalo de tempo entre caracteres sem causar erro. Porém, o tamanho da
mensagem em bytes é aumentado significativamente. Como a perda de dados é um fator a se evitar,
então este modo de transmissão, tolerante a tempos longos entre bytes de comunicação, foi o modo
escolhido para o projeto. O formato de cada byte em modo ASCII é:
Sistema de codificação:
Caractere ASCII 0-9 (30h a 39h), A a F (41h a 46h)
Cada byte é enviado como 2 caracteres ASCII
Endereçamento (1 byte):
0: usado para “broadcast”
1 a 247: usados pelos escravos
Código da função (1 byte):
Estabelece a ação a ser efetuada.
0 a 127: funções
128 a 255: informe de erro na transmissão
Bytes de dados:
Informações adicionais necessárias;
Endereços de memória;
Quantidade de itens transmitidos;
Quantidade de bytes de campo.
Checagem de erro:
Longitudinal Redundancy Check (LRC)
Os dispositivos da rede monitoram continuamente o barramento e quando é detectado o
caractere“:” (3Ah), tem-se o início da decodificação do próximo campo, que indica para qual
dispositivo a mensagem está sendo transmitida. Intervalos de até 1 segundo podem ocorrer entre o
envio de caracteres dentro da mesma mensagem. Se ocorrer em intervalos maiores (timeout), o
dispositivo assume ocorrência de erro.
2.9 Arquitetura OSI
Com o objetivo de facilitar o processo de padronização e obter interconectividade entre
máquinas de diferentes fabricantes, a Organização Internacional de Normalização (ISO International Standards Organization), uma das principais organizações no que se refere à elaboração
de padrões de comunicação de âmbito mundial, aprovou, no início da década de 1980, um modelo de
arquitetura para sistemas abertos, visando permitir a comunicação entre máquinas heterogêneas e
definindo diretivas genéricas para a construção de redes de computadores independente da
tecnologia de implementação. Esse modelo foi denominado OSI (Open Systems
Interconnection), servindo de base para a implementação de qualquer tipo de rede, seja de curta,
média ou longa distância.
23
A arquitetura de uma rede é formada por camadas (ou níveis), interfaces e protocolos. As
camadas são processos, implementados por hardware ou software, que se comunicam com o
processo correspondente na outra máquina. Cada camada oferece um conjunto de serviços ao nível
superior, usando funções realizadas no próprio nível e serviços disponíveis nos níveis inferiores.
Em uma estrutura baseada em camadas, os dados transferidos em uma comunicação de um
nível específico não são enviados diretamente ao processo do mesmo nível em outra estação, mas
descem, através da cada camada adjacente da máquina transmissora até o nível inicial, onde é
transmitido, para depois subir através de cada nível adjacente da máquina receptora.
Os protocolos são conjuntos de regras e formatos que permitem a comunicação entre as
camadas nas diferentes máquinas. Em cada camada podem ser definidos um ou mais protocolos. Já
as interfaces representam o limite entre cada nível adjacente onde uma camada compreende as
informações vindas de outra camada.
Dentro dessa filosofia, o modelo OSI define uma arquitetura genérica de sete camadas para o
sistema computacional (Figura 10). Com exceção da camada mais alta, cada camada é usuária dos
serviços prestados pela camada imediatamente inferior (n-1) e presta serviços para a camada
imediatamente superior (n+1). Esta troca de informações entre as camadas adjacentes ocorre por
meio da troca de primitivas de serviços (funções que um nível oferece ao nível imediatamente
superior de forma a prover a comunicação entre os mesmos) nas interfaces entre as camadas.
Apesar da divisão em sete níveis, pode-se considerar genericamente que as três camadas
mais baixas do modelo cuidam dos aspectos relacionados à transmissão propriamente dita, a quarta
camada lida com a comunicação fim-a-fim, enquanto que as três camadas superiores se preocupam
com os aspectos relacionados à aplicação, já ao nível de usuário.
Uma maneira bastante simples de se enxergar a funcionalidade do modelo OSI é imaginar
que cada camada tem como função adicionar um cabeçalho aos dados do usuário a serem
transmitidos para outro sistema. Deste modo, a função de cada camada do outro sistema é
exatamente a inversa, ou seja, retirar os cabeçalhos dos dados que chegam e entregá-los ao usuário
em sua forma original.
24
Figura 10: Arquitetura OSI de redes e a função de cada camada
Os protocolos utilizados nos projetos foram TCP, IP e FTP, pertencentes às camadas de
transporte, rede e aplicação, respectivamente. Serão abordadas as funcionalidades das camadas
citadas.
2.9.1 Camada de Aplicação
Esta camada fornece uma interface ao usuário que permite acesso a diversos serviços de
aplicação, convertendo as diferenças entre fabricantes distintos para um denominador comum. Por
esse motivo, é o nível que possui o maior número de protocolos existentes. Por exemplo, em uma
transferência de arquivos entre máquinas de diferentes fabricantes pode haver convenções de nomes
diferentes (DOS tem uma limitação de somente 8 caracteres para o nome de arquivo, UNIX não),
formas diferentes de representar as linhas, e assim por diante. Transferir um arquivo entre os dois
sistemas requer uma forma de trabalhar com essas incompatibilidades, e essa é a função da camada
de aplicação. O dado entregue pelo usuário à camada de aplicação do sistema recebe a denominação
de SDU (Service Data Unit). A camada de aplicação, então, junta a SDU (no caso, os dados do
usuário) um cabeçalho chamado PCI (Protocol Control Information). O objeto resultante desta
junção é chamado de PDU (Protocol Data Unit), que corresponde à unidade de dados especificada de
um certo protocolo da camada em questão.
25
2.9.1.1 Protocolo FTP
Figura 11: Protocolo FTP
O FTP (File Transfer Protocol - Protocolo de transferência de arquivos) oferece um meio de
transferência
e
compartilhamento
de
arquivos
remotos.
O
protocolo
FTP
disponibiliza interatividade entre cliente e servidor (Figura 11), de forma que o cliente possa acessar
informações adicionais no servidor, não só ao próprio arquivo em questão. Como exemplo de
facilidades podemos citar a lista de arquivos, onde o cliente lista os arquivos existentes no diretório,
ou até mesmo de outros diretórios. O protocolo FTP permite que o cliente especifique o tipo e o
formato dos dados armazenados. Como exemplo, se o arquivo contém texto ou inteiros binários,
sendo que no caso de texto, qual o código utilizado (USASCII, EBCDIC,etc). Como segurança
mínima o protocolo FTP implementa um processo de autenticação e outro de permissão. A
autenticação é verificada através de um código de usuário e senha, já a permissão, é dada em nível de
diretórios
e
arquivos.
O servidor de FTP possibilita acessos simultâneos para múltiplos clientes. O servidor
aguarda as conexões TCP, sendo que para cada conexão cria um processo cativo para tratá-la.
Diferente de muitos servidores, o processo cativo FTP não executa todo o processamento necessário
para cada conexão. A comunicação FTP utiliza uma conexão para o controle e uma (ou várias) para
transferência de arquivos. A primeira conexão (chamada de conexão de controle "Ftp-control") é
utilizada para autenticação e comandos, já a segunda (chamada de conexão de dados "Ftp-data"), é
utilizada para a transferência de informações e arquivos em questão. No projeto desenvolvido nesse
trabalho, foi explorada apenas a conexão FTP-data.
2.9.1.2 Protocolo SMTP
O protocolo SMTP (Simple Mail Transfer Protocol) é o protocolo que permite transferir o
email de um servidor a outro em conexão ponto a ponto. Trata-se de um protocolo que funciona em
modo conectado. O email é entregue diretamente ao servidor de email do destinatário. O protocolo
funciona por meio de comandos textuais enviados ao servidor SMTP. Cada um dos comandos
26
enviados pelo cliente é seguido de uma resposta do servidor SMTP, composta de um número e de
uma mensagem descritiva.
Segue um exemplo de pedido de envio de email a um servidor SMTP:

A partir da abertura da sessão SMTP, o primeiro comando a enviar é o comando HELO seguido
de um espaço (notado <SP>) e o nome de domínio da sua máquina. Desde abril de 2001, as
especificações do protocolo SMTP, definidas no RFC 2821, impõem que o comando HELO seja
substituído pelo comando EHLO.

Em seguida, é feito o pedido de autenticação com o comando AUTH LOGIN; o servidor
solicita, com comandos na base 64, o nome de usuário e a senha, os quais devem ser enviados
também na base 64.
 O segundo comando é "MAIL FROM" seguido do email do remetente. Se o comando for aceito,
o servidor devolve a mensagem "250 OK"
 O comando seguinte é "RCPT TO: " seguido do email do destinatário. Se o comando for aceito,
o servidor devolve a mensagem "250 OK"
 O comando DATA é a terceira etapa do envio. É relativo ao o início do corpo da mensagem. Se
o comando for aceito, o servidor responde com uma mensagem intermédia numerada 354, que
indica que o envio do corpo da mensagem pode começar, considerando como conteúdo o conjunto
das linhas seguintes até uma linha que contém unicamente um ponto (final da mensagem). Se o
comando for aceito, o servidor devolve a mensagem "250 OK".
2.9.1.2.1 A Base 64
É um método de codificação de dados para transferência na Internet. É utilizado
frequentemente para transmitir dados binários por meios de transmissão que lidam apenas com texto,
como por exemplo para enviar arquivos anexos por email.
A conversão de caracteres em ASCII para base 64 ocorre da seguinte maneira: um caractere em
ASCII é representado por 8 bits, enquanto que na base 64 por 6 bits. Grupos de 6 bits (6 bits tem o
máximo de 26 = 64 valores binários diferentes ) são feitos a partir dos correspondentes binários dos
caracteres em ASCII, de forma que 3 desses caracteres (24 bits) geram 4 caracteres na base 64.
Quando o número de bytes a ser codificado para base 64 não é divisível por três, faz-se o seguinte:
caso dê resto 1 na divisão por 3, adiciona-se '=='; caso dê resto 2, adiciona-se "=".
27
Figura 12: Exemplo de conversão de ASCII em base64 e a tabela de correspondência aos
índices
2.9.1.2.2 Processo de autenticação
A maioria dos servidores SMTP tem exigido um protocolo de autenticação para realizar o
envio de email. Isso se faz necessário pois a porta 25 tem sido alvo de propagação de vírus e spans.
Esses protocolos garantem a segurança no envio de emails. Os mais comuns são TLS e SSL.
- SSL:
SSL significa Secure Sockets Layer. Quando o SMTP é usado, esse modo SSL geralmente
indica a necessidade de uma conexão segura, desde o momento em que se conecta com os servidores
de e-mail. Normalmente, o SSL está associado à porta 465.
- TLS (formalmente conhecido como STARTTLS)
TLS significa Transport Layer Security. Quando o SMTP é usado, esse tipo de protocolo
de autenticação começa com uma conexão não segura com o servidor, seguida por um comando
STARTTLS e, em seguida, atualiza para uma conexão segura quando efetivamente começa a
transmitir dados. Normalmente, o TLS está associado às portas 25 e 587.
Ambos são protocolos de segurança válidos que garantem que os dados, como nome de
usuário, senha e mensagens, sejam criptografados. Isso significa que uma linguagem comum é
transformada em código para que ninguém possa ler o que você é enviado.
28
2.9.2 Camada de Transporte
Os serviços prestados pelo IP (Internet Protocol, camada de rede) não oferecem
confiabilidade. Problemas comuns, como congestionamento, perda ou ordenação de pacotes não são
tratados.Porém, as aplicações (SMTP,FTP, HTTP) necessitam prover um serviço de qualidade ao
usuário.Essa é a finalidade da camada de transporte, fornecer um serviço confiável a essas
aplicações. Os principais serviços oferecidos pela camada de transporte são:

Controle de conexão: A camada de transporte tem protocolos orientados ou não para
a conexão. Para os que são orientados, primeiramente é estabelecida a comunicação entre os
usuários finais, e só depois é iniciada a transmissão.

Fragmentação: dividir os pacotes em segmentos menores para que sejam
encapsulados pela camada de rede.

Endereçamento: conexão entre servidor e cliente é feita com o auxílio de "sockets",
ou seja, estruturas que auxiliam no endereçamento, compostas por IP e porta de comunicação
utilizada. Os sockets podem ser abertos entre pontos pertencentes à mesma rede e que utilizam o
mesmo protocolo.

Confiabilidade: controle de fluxo, erros, congestionamento e qualidade de serviço.
Os principais protocolos da camada de transporte são TCP e UDP. A seguir, são
apresentadas algumas diferenças entre eles.
2.9.2.1 Protocolo TCP versus UDP
Transmission Control Protocol é um protocolo voltado à conexão, ou seja, requer um
processo de " handshaking" (ou confirmação de recebimento) para as comunicações ponto-a-ponto.
Uma vez estabelecida a conexão, os dados podem ser transmitidos de maneira bidirecional entre os
pontos.
Principais características:



Confiável – TCP controla o processo de confirmação de recebimento, retransmissão e timeout,
além do controle de congestionamento.
Ordenada – Garante que múltiplas mensagens transmitidas em sequência cheguem no receptor
na ordem correta.
Pesada – TCP requer três pacotes para inicar uma comunicação socket.
User Datagram Protocol é um protocolo de comunicação baseado na simplicidade de envio
da mensagem. Não é dedicada à comunicação ponto-a-ponto, portanto não é voltado à conexão. A
comunicação é estabelecida ao se transmitir informação para o destinatário (unidirecional) sem sem
verificar o estado do mesmo (se está em condições de receber). Um benefício do UDP sobre TCP é a
aplicação VoIP (voice over internet protocol), pois preocupa-se mais em reduzir o atraso no envio do
dado que com a precisão com a qual os mesmos chegam no receptor.
Principais caracterísitcas:

Não confiável – Quando a mensagem é enviada, não tem como saber se ela realmente chegou no
destino.
29



Não ordenada– Não há garantia de que mensagens enviadas em sequência cheguem na mesma
ordem.
Leve – Não há ordenação de mensagens, preocupação com a confirmação de recebimento.
Não há controle de congestionamento –a UDP não realiza esse controle, podendo gerar colapsos
de congestionamento, a não ser que esse controle seja feito na camada de Aplicação.
2.9.3 Camada de Rede
A camada de rede recebe os serviços providos da camada de enlace e presta serviços à
camada de transporte. As principais finalidades da Camada de Rede são:





Interconexão: prover conexão lógica entre diversas redes físicas heterogêneas.
Endereçamento: prover, de forma única, a identificação de um host na rede à qual faz
parte
Roteamento: escolher a rota por onde os pacotes irão trafegar a fim de que cheguem ao
destino.
Encapsulamento: encapsular pacotes recebidos de camadas superiores em um
datagrama.
Fragmentação: permite que pacotes viajem por diferentes redes, independente da
tecnologia utilizada.
2.9.3.1 Protocolo IP
O IP(Internet Protocol) é um protocolo da camada de redes responsável pelo
encaminhamento de dados em uma rede, fornecendo o endereço virtual do host na rede. Presta todos
os serviços dessa camada para as camadas superiores. É o protocolo base da internet, sendo utilizado
por todos os serviços de aplicação.
2.10 GPS
GPS (Global Positioning System) é um sistema de posicionamento global baseado na
navegação por satélite, que fornece a um aparelho receptor móvel a posição do mesmo e o horário
que está sendo realizada a medida, assim como outras informações complementares. Pode ser feita
sob qualquer condição atmosférica, a qualquer momento, desde que o receptor se encontre no campo
de visão de quatro satélites GPS. Existem diversos padrões de recebimento
2.10.1 NMEA formato RMC
NMEA (National Marine Electronics Association) é um padrão de recebimento de dados de
posição em tempo real. A NMEA possui uma versão própria para recebimento de PVT (position,
velocity, time) proveniente de GPS, a chamada RMC (Recommender Minimum). A maior parte dos
softwares que fazem interface com GPS esperam que os dados recebidos estejam no formato NMEA
RMC. Esse formato apresenta-se da seguinte maneira:
$GPRMC,123519,A,4807.038,N,01131.000,E,022.4,084.4,230394,003.1,W*6A
Onde:
30
RMC
123519
A
4807.038,N
01131.000,E
022.4
084.4
230394
003.1,W
*6A
" Recommended Minimum sentence C"
Dado colhido às 12:35:19 UTC
Status A=ativo ou V=Void.
Latitude 48 graus 07.038' N
Longitude 11 graus 31.000' E
Velocidade em relação à terra em nós
Direção de movimento em graus
Data - 23 de Março de 1994
Variação Magnética
Checksum, sempre inicia com *
Esse foi o formato adotado para a simulação do projeto.
2.11 EasyPIC5
Figura 13: EasyPIC5
EasyPIC5 é uma placa de desenvolvimento da MikroElektronica para diversos
microcontroladores PIC. Permite a engenheiros e estudantes testar facilmente e explorar a
capacidade dos microcontroladores PIC. Também possibilita que seja interfaceado com diversos
periféricos e circuitos externos. Essa placa permite ao usuário se concentrar no desenvolvimento
softwares, pois já provê grande parte de hardware necessário para a realização de projetos. Para esse
31
trabalho, foi utilizada a saída serial RS232, a entrada USB (para alimentação e gravação do código
implementado no PIC), os botões, LEDs e LCD.
3. Descrição dos projetos
3.1 Casa Inteligente
O projeto tem como objetivo permitir que o usuário envie comandos a dispositivos e receba
dados de um alarme remotamente. O usuário envia os comandos por meio de um servidor TCP, que
possui IP fixo, sendo os mesmos recebidos por um modem. Esse, por sua vez, se conecta à rede
GPRS através do chip de uma empresa de telefonia, obtendo IP dinâmico. Apesar de o modem
também poder trabalhar com UDP, optou-se por realizar a comunicação com TCP porque esse
protocolo é voltado para conexão e é confiável, ou seja, fornece maior segurança de que os dados
serão efetivamente transmitidos, com menores ocorrências de erros; o UDP é mais útil quando é
preferível obter os dados em menor tempo, mesmo que haja perdas, como no caso de transferência
de voz.
O modem é conectado a um microcontrolador PIC via rede RS232. O PIC processa e repassa
os comandos aos respectivos dispositivos pela rede RS485. As ações testadas nesse projeto são:
acender ou apagar uma lâmpada remotamente, controlar a luminosidade de um ambiente e acionar
um alarme, informando o seu acionamento ao usuário.
3.2 Rastreamento de veículo
O projeto consiste na simulação do rastreamento de um veículo frigorífico. É constituído
pelo usuário, que possui acesso direto a uma interface de servidor TCP, com IP fixo, e pode enviar
comandos ao sistema; pelo servidor FTP, onde são salvos arquivos no formato ".txt" com os estados
do sistema em uma determinada data e horário, e ao qual o usuário tem acesso; e pelo veículo
propriamente dito, composto por circuito com microcontrolador e modem. O usuário do sistema
pode ser, por exemplo, o proprietário do veículo e deseja monitorar como o motorista, seu
funcionário, está conduzindo o frigorífico. É feita a simulação da leitura do estado de sete sensores
(capô do motor, porta da carga, tampa do combustível, ignição, temperatura da carga baixa,
temperatura da carga alta e nível de combustível baixo) e da leitura de dados provenientes de um
GPS seguindo o formato NMA RMC. Esses dados são salvos na página do servidor por meio do
protocolo FTP, sendo a conexão realizada pela rede GPRS, de maneira semelhante à descrita no
projeto da casa inteligente. Em seguida, é feita a conexão com o usuário (abertura de um socket
TCP) para verificar se há comandos a serem enviados pelo mesmo, como acionar o bloqueador (em
caso de roubo, por exemplo), desativar o bloqueador e enviar mensagens (pedir para o motorista
reduzir a velocidade, por exemplo, sendo esse valor um dado do GPS). O período que o sistema
permanece em "escuta" é limitado a no máximo 3 minutos, pois é custoso para a operadora de
telefonia manter uma conexão. Após o fechamento dessa conexão, o processo se reinicia
continuamente (leitura dos sensores e GPS, registro desses valores no servidor e posterior escuta de
algum comando proveniente do usuário).
Optou-se por utilizar o protocolo FTP pois o mesmo permite que arquivos sejam salvos em
um servidor e possam ser acessados a qualquer instante, não apenas no momento em que a conexão
está ocorrendo. Dessa maneira, o usuário do sistema pode verificar o status de seu caminhão quando
convier. Porém, para o envio de comandos é necessário que ambos estejam conectados, pois desejase que os comandos sejam realizados naquele instante.
32
A ideia inicial era utilizar também o protocolo SMTP, visando enviar os dados do sistema ao
email do usuário além de salvar no servidor FTP. Porém, para realizar a abertura de uma
comunicação SMTP é preciso passar por um processo de autenticação que é consideravelmente
complexo (TLS). Alguns modelos de modem mais modernos já possuem esse processo embarcado,
porém esse não é o caso do modem utilizado no projeto. Diante dessa dificuldade, optou-se por
utilizar apenas o FTP.
4. Implementação
A implementação da primeira parte do projeto, a da casa inteligente, consistiu do
desenvolvimento do hardware, do software e da integração entre eles. A segunda parte, simulação do
sistema de rastreamento de veículo, consistiu da elaboração do software e integração desse com a
placa de desenvolvimento EasyPIC5, da MikroElektronica.
4.1 Casa Inteligente:
4.1.1 Hardware:
O hardware foi implementado numa estrutura mestre – escravo, em que o microcontrolador
mestre recebe os comandos do modem e os transmite aos escravos (PIC 16F628). O pinos rx e tx do
conector DB9 do modem (Figura 14) são ligados ao MAX232 para que seja feita a conversão de
níveis de tensão RS232/TTL do PIC. Cada um dos microcontroladores possui um MAX485
conectado a si e o MAX485 do mestre se comunica com cada MAX485 ligado a um escravo. Cada
escravo está ligado a um dispositivo a ser controlado. As atividades remotamente executadas são:
acender e apagar uma lâmpada, controlar a luminosidade de uma lâmpada e acionar um alarme. O
projeto do hardware começou com um esboço do circuito do escravo, conforme mostra a Figura 15.
Figura 14 - Pinos do conector DB9
Fonte : (Messias, 2006)
33
Figura 15 - Projeto do circuito do PIC16F628 mestre
Inicialmente, o circuito foi montado em protoboard (Figura 16). Depois, foram
confeccionadas placas de circuito impresso, para garantir maior mobilidade e menor interferência de
ruídos ao projeto. Para a confecção das placas de circuito impresso na fresadora para circuitos Lpkf
(Figura 17), foram feitos os esquemáticos dos circuitos do mestre e dos escravos e, posteriormente, o
layout, no software EAGLE 6.4.0.
Figura 16 - Montagem do circuito em protoboard
34
Figura 17 - Fresadora Lpkf
O circuito da Figura 18 realiza a conversão de níveis de tensões para que diferentes
dispositivos possam se comunicar entre si. Converte +12V em zero (GND) e -12V em +5V. O
modem que estará conectado à entrada DB9 entende -12V como nível lógico 1 e +12V como nível
lógico zero. O microcontrolador entende +5V como nível lógico 1, e zero como nível lógico zero.
Figura 18 - Esquemático do circuito do MAX232
A Figura 19 mostra a montagem da comunicação do modem com o PIC 16F628, composta
pela placa do MAX232, modem, placa do PIC 16F628 e fonte de 12V para o modem. O intuito desse
circuito é de fazer a comunicação serial do microcontrolador mestre com modem, a fim de que o
mesmo se conecte com o servidor TCP.
35
Figura 19: Comunicação modem/ PIC
4.1.1.1 Dispositivos controlados
Figura 20 - Esquemático do circuito do PIC 16F628
36
A Figura 20 mostra o esquemático do PIC16F628, utilizado para os microcontroladores
escravos e pelo mestre. Os microcontroladores escravos serão ligados ao mestre através da rede
RS485 e também aos dispositivos controlados. Foram necessárias três unidades desta placa, uma
para o mestre e duas para os dispositivos, com exceção do LDR, que utilizou o PIC 16F877A.
4.1.1.1.1 Acionamento do alarme
O circuito funciona da seguinte forma: quando a porta da residência é aberta, o reed switch
aproxima-se de um campo magnético produzido por um imã fazendo com que suas lâminas entrem
em contato, fechando o circuito. O acionamento é feito por uma chave de pull-up. O
microcontrolador monitora (realiza um polling) a tensão na porta em que está conectado o reed
switch. Enquanto o reed switch permanece aberto, a tensão verificada é aproximadamente 5V (nível
alto) e quando ocorre o fechamento do dispositivo, esta tensão cai a zero (nível baixo). Nesse
momento, o alarme é acionado, ou seja, o microcontrolador disponibiliza nível alto em sua saída, a
qual se encontra conectada a um transistor. A corrente de base aumenta, assim como a de coletor, e a
tensão entre coletor e base torna-se negativa, o que indica a saturação do transistor.
Consequentemente, o alto falante é acionado.
Figura 21 - Esquemático do circuito do alarme
A Figura 22 mostra a placa do PIC 16F628, ligada à do reed switch pela rede RS485. O
buzzer está conectado à placa do reed switch.
37
Figura 22: Montagem do circuito do alarme
4.1.1.1.2 Acende / apaga lâmpada
O circuito funciona da seguinte forma: quando o microcontrolador disponibiliza nível alto na
porta em que o transistor está conectado, este é saturado, assim o relé fecha devido à indução de um
campo magnético que provoca a atração de sua chave. Existe a necessidade do diodo (diodo de roda
livre) para que haja um caminho de condução da corrente do relé quando o transistor parar de
conduzir, pois o relé tem caráter indutivo nos terminais da bobina.
Figura 23 - Esquemático do circuito da lâmpada
A Figura 24 mostra a placa do PIC 16F628, conectada à do reed switch pela rede RS485. A
lâmpada está ligada à placa do relé.
38
Figura 24: Circuito de acionamento da lâmpada
4.1.1.1.3 Controle de luminosidade
No circuito da Figura 25, o microcontrolador, através da expansão, lê o nível de tensão em
uma de suas portas analógicas e, de acordo com esse nível, muda o Duty Cicle da onda quadrada
gerada em sua saída PWM. A mudança no nível de tensão é proporcionada por um simples divisor
de tensão, pois o LDR altera o valor de sua resistência de acordo com a luminosidade incidente sobre
ele. Assim, pode-se realizar a dimerização de uma lâmpada DC de baixa tensão, por exemplo.
39
Figura 25 - Esquemático do circuito do LDR
A Figura 26 mostra o esquemático do PIC escravo que envia o comando ao circuito do LDR.
Esse foi o único escravo a utilizar PIC16F877A.
Figura 26 - Esquemático do PIC 16F877A escravo
40
4.1.2 Software
4.1.2.1 Comunicação cliente/servidor
O primeiro teste de comunicação (software HDC Terminal) ocorreu entre dois modems, cada
um ligado a um computador. O servidor tem um IP fixo, podendo ser acessado em qualquer lugar do
mundo, e o cliente (aquele que fica na casa remotamente controlada) se conecta à rede GPRS,
provida por empresa de telefonia celular através do chip inserido no modem. A figura abaixo mostra
a configuração da conexão no modo cliente, em que são configurados o tipo de conexão (serial), a
porta COM e a velocidade de transferência de bits.
Figura 27 - Configuração da conexão cliente
Após a conexão, são preenchidos os campos “APN”, “User Id” e “Senha”, de acordo com o
chip da operadora inserido no modem. É informado também o IP do servidor (fixo), conforme
mostra a figura abaixo.
41
Figura 28 - Conexão cliente
A conexão na rede GPRS (Figura 29) ocorreu através dos seguintes comandos:
AT#SGACT: ativação do contexto PDP (Packet Data Protocol)
AT&K0: sem controle de fluxo no RS232
AT+CGDCONT: configurações do contexto PDP
AT#SCFG: configurações do socket
A seguir, o programa fornece o IP que o dispositivo possui na rede GPRS.
42
Figura 29 - Conexão na rede GPRS
Após a conexão na rede GPRS, são feitas as configurações do modo servidor. O tipo de
conexão é TCP e a porta escolhida foi “1234”.
Em seguida, conecta-se o servidor.
43
Figura 30 - Configuração da conexão servidor
O próximo passo é a abertura do socket no modo cliente através do seguinte comando:
AT#SD: abre uma conexão remota via socket
Quando o socket é efetivamente aberto, o programa imprime “CONNECT” na tela do
cliente. Com isso, o que for escrito no campo “Comando” do cliente, aparece na tela do servidor e
vice-versa, pois a comunicação é bidirecional. Assim, quando o cliente enviar um comando de
acender uma lâmpada, por exemplo, o servidor poderá responder com uma mensagem de
confirmação ou erro.
44
Figura 31 - Socket full duplex
4.1.2.2 Comunicação modem/ PIC
Após o teste de funcionamento do Modem, prosseguiu-se para a conexão do mesmo ao PIC,
de forma que o envio desses comandos para estabelecer a comunicação seja realizada pelo
microcontrolador, e não mais por um usuário. O código foi desenvolvido no software "MikroC for
PIC". Como as portas de comunicação serial RX/TX do PIC já estavam sendo utilizadas para a
aplicação do protocolo Modbus, e o PIC utilizado possui apenas um par RX/TX, foi necessário
utilizar duas outras portas I/O para transmissão e recepção de dados via RS232. O software em
questão possui uma biblioteca "SoftUART" que contém comandos para tornar isso viável. Desses
comandos, foi utilizado apenas o "Soft_UART_Init", que inicializa as portas I/O como TX/RX a uma
dada baud rate, e o" Soft_UART_Write ", que transmite o caractere desejado. Para o projeto, foi
escolhidas as portas RA2 e RA3 como RX e TX, respectivamente. Existe também uma função
"Soft_UART_Read ", porém a mesma não estava realizando a recepção dos caracteres de maneira
devida, acusando erro de stop bit. Diante disso, foi criada uma rotina própria de recepção (Figura
32). Inicialmente, é feito um while de forma que o programa só dê prosseguimento caso haja o start
bit, que deixa a porta RA2 em baixa. Detectado o start bit, é aguardado um tempo de meio bit para
que, a partir de então, os bits relativos ao dado fossem lidos no meio do pulso, e não nas bordas, a
fim de evitar erro de processamento. A identificação dos bits ocorre da seguinte maneira: para
guardar o valor do bit[i], onde i varia de 0 a 7, é feito, primeiramente, uma máscara para o bit 3 da
porta A, relativo à saída RA2. O bit resultante é deslocado dentro do byte que recebeu o valor da
máscara em RA2, de forma que ocupe a posição "i". Esse valor fica retido em "BYTE", que, após
guardar o valor dos bits de 0 a 7, possui o dado relativo ao caractere como um todo. Após a recepção
dos bits, é enviado o stop bit, devendo o mesmo estar em nível alto. O valor do período do bit é
calculado a partir da taxa de transmissão. No caso, a baud rate é de 9600 bits/s, o que implica 104 µs
por bit.
45
Figura 32 - Rotina de recepção de caracteres
A Figura 33 mostra um exemplo de caractere recebido pelo PIC na comunicação serial. O
gráfico foi medido pelo osciloscópio na porta RA2 do PIC. A escala temporal é de 100 µs, portanto
há um bit por quadro. Percebe-se, no início, a mudança do nível alto (5.40V) para nível baixo (1V),
caracterizando o start bit. A partir de então, tem-se a sequência 11010000, seguida por um 1 (stop
bit), pois nessa transmissão optou-se por não trabalhar com bit de paridade. Os bits são transmitidos
do menos significativo para o mais significativo, ou seja, esse caractere é, em binário, 00001011.
Consultando-se a tabela ASCII, tem-se que esse byte se refere ao caractere 'VT', responsável pelo
salto para a próxima linha.
46
Figura 33 - Caractere 'VT'
A Figura 34 mostra a parte do código relativa ao envio de comandos ao Modem através da
função Soft_UART_Write. Essa função só permite enviar caractere por caractere. Os caracteres '\n' e
'\r' são necessários para que o Modem reconheça como término do envio de um comando. O "for"
realiza a leitura dos bytes recebidos pelo PIC, sendo necessário ler apenas os três primeiros
caracteres, que são '\n','\r' e o primeiro caractere do tipo de resposta que o modem envia ao PIC. Por
exemplo, caso tenha dado erro, o Modem responde: '\n', \r' e 'ERROR'. Caso não haja erro, o Modem
responde '\n', \r' e 'OK'. Como o desejado é 'OK', é feito um loop em que, caso o terceiro bit lido não
seja 'O', o PIC envia o comando novamente ao Modem, até responder como resposta 'OK', para,
então, dar prosseguimento nos demais comandos. É importante ressaltar que inicialmente deve ser
desabilitada a função de Eco do Modem, responsável por repetir o comando recebido e apenas após
isso retornar a resposta. O eco dificulta a leitura do caractere, em especial porque o Modem inicia o
retorno do comando antes do término do envio desse por parte do PIC. para tal, deve ser enviado o
comando "ATE".
47
Figura 34 - Envio de comandos ao Modem
O código utiliza os mesmos comandos do teste feito com o Modem descrito inicialmente
para estabelecimento da conexão. Portanto, foi dividido em oito partes, das quais sete são para o
envio de cada comando especificado, e a oitava é para a comunicação bidirecional (Figura 35). No
código, foi feito um teste para verificar se a comunicação ocorre em ambos os sentidos. Caso o
servidor envie '1', o PIC deveria retornar 'LED ACESO', e caso envie '2' retorna 'LED APAGADO'.
Esse teste de confirmação pode facilmente se tornar um comando. Por exemplo, caso o servidor
envie '1', o circuito pode ativar, através do ModBus, um dos dispositivos, além de retornar a
confirmação.
Após realização de testes, percebeu-se que a comunicação ocorreu com sucesso. O código
completo encontra-se no Anexo.
48
Figura 35 - Comunicação bidirecional
4.2 Sistema de rastreamento de veículo
4.2.1 Hardware
O hardware do projeto foi composto pelo kit de desenvolvimento EasyPIC5 e o modem
GSM/GPRS GM862. Os componentes do kit utilizados foram: painel de LCD, botões RC0 a RC3,
LEDs RD0 a RD7, saída para comunicação serial e saída USB por onde é realizada a alimentação do
sistema e gravação no PIC. A funcionalidade dos LEDs e botões encontra-se na Tabela 3. O LCD foi
utilizado para permitir o acompanhamento do envio de comandos AT e as respectivas respostas do
modem, permitindo detecção de falhas, conforme a Figura 36. Os comandos enviados aparecem na
primeira linha, enquanto que o primeiro caractere da resposta encontra-se na segunda linha. "O"
significa "OK".
49
Figura 36: Display de LCD acompanhando o envio dos comandos AT
Tabela 3: Funcionalidade dos botões e LEDs
Botão RC0
Botão RC1
Botão RC2
Botão RC3
LED RD0
LED RD1
LED RD2
LED RD3
LED RD4
LED RD5
LED RD6
LED RD7
- Acende/ Apaga o LED RD0
- Simula a atuação sobre a porta do frigorífico (Abrir/ Fechar)
- Acende/ Apaga o LED RD1
- Simula a atuação sobre o capô do motor (Abrir/ Fechar)
- Acende/ Apaga o LED RD2
- Simula a atuação sobre a tampa do combustível (Abrir/ Fechar)
- Acende/ Apaga o LED RD3
- Simula a atuação sobre a ignição(ligando/ desligando)
Simula um sensor na porta do frigorífico (Ligado = Aberta, Desligado
= Fechada)
Simula um sensor no capô do motor (Ligado = Aberto, Desligado =
Fechado)
Simula um sensor na tampa do combustível (Ligado = Aberta,
Desligado = Fechada)
Simula um sensor no sistema de ignição (Ligado = Motor acionado,
Desligado = Motor desligado)
Simula um sensor no controle da temperatura (Ligado = Temperatura
baixa, Desligado = Temperatura acima da mínima)
Simula um sensor no controle da temperatura (Ligado = Temperatura
alta, Desligado = Temperatura abaixo da máxima)
Simula um sensor no controle do nível de combustível (Ligado =
Combustível acabando, Desligado = Nível normal)
Simula o sistema de bloqueio do veículo (Ligado = Ativado,
50
Desligado = Desativado)
4.2.2 Software
4.2.2.1 Testes realizados com SMTP
Inicialmente, foi realizado o teste do uso do protocolo com o modem conectado a um
computador (porta COM). O software utilizado foi o HyperTerminal. Os comandos para conexão na
rede GPRS são os mesmos apresentados na Figura 29. Após a obtensão do IP, envia-se o comando
AT#SD=1,0,587,"gmail.com.br",0. A porta "587" é a utilizada pelo gmail, e exige autenticação por
meio de TLS. Cabe ressaltar que a porta "25" encontra-se bloqueada pela maioria dos servidores
SMTP, visto que, por não exigir autenticação, acabou se tornando um canal para envio de spans e
vírus. Após receber o "CONNECT" do modem, tudo o que é escrito é recebido pelo servidor. É
importante que o a opção de eco esteja ativada, pois ele torna possível ver o que está sendo escrito
para o servidor (lembrando que par acionar o eco basta usar o comando "ATE=1" antes de iniciar a
conexão ).
Figura 37: Conexão com o servidor SMTP "gmail"
Iniciada a comunicação com o servidor, deve ser seguido um procedimento em etapas para
poder efetivamente enviar o email. Os números do início da mensagem do servidor indicam o status
da operação (por exemplo: se o comando foi recebido e realizado com sucesso, se houve erro, se o
servidor está em condições de estabelecer conexão). Primeiramente, o servidor retorna a mensagem
"220", indicando que está em condições de iniciar o serviço. Deve-se responder "ehlo", para que o
servidor identifique com quem está operando. Em seguida, responde com "250" (ação concluída com
51
sucesso) e solicita que inicie o "TLS", portanto deve-se responder com "starttls". A partir desse
ponto, seria necessário realizar um procedimento complexo de autenticação. Seria necessário
bastante tempo de pesquisa para compreender o processo, já que o modem utilizado não possui esse
sistema pronto. Por esse motivo, decidiu-se não trabalhar mais com o SMTP.
A critério de conhecimento (ou caso estivesse disponível um modem com esse processo de
TLS pronto), foi feito um exemplo da conexão SMTP por meio de Telnet (Figura 38).
Figura 38: Conexão SMTP com o "gmail" bem sucedida por Telnet
Na Figura 38, nota-se que o servidor não solicitou a realização do processo de TLS
(aparece "AUTH LOGIN PLAIN (...) PLAIN CLIENTTOKEN" no lugar de "STARTTLS"), pois já
obteve a resposta desse procedimento realizado pelo Telnet. Em seguida, deve-se enviar "auth login",
a fim de solicitar o início da identificação do login e senha. O servidor ,então, solicita o "username"
com o comando na base 64 "WXNIcm5hbWU6". Deve-se responder o nome de usuário também na
base 64. Em seguida, solicita a senha ("UGFzc3dvcmQ6", em base 64). Responde-se, então, com a
senha na base 64. Após a confirmação da senha e do usuário, o servidor envia "Accepted". Em
seguida, seguem-se os seguintes comandos: "mail from: <email da pessoa que envia>", aguarda-se o
"OK" do servidor; "rcpt to: <email do destinatário>", aguarda-se o "OK" e "Go ahead"; escreve-se
"subject: <título do email>", aperta "ENTER" no teclado e digita-se o corpo da mensagem; o término
da mensagem é indicado por um ponto (".") em uma linha abaixo da última com conteúdo. Após o
envio correto, indicado por "OK" do servidor, encerra-se a conexão com o comando "quit". Na
52
Figura 38 os campos relativos ao envio da senha e do nome de usuário foram apagados da figura
propositalmente por razões de segurança .
4.2.2.2 Teste do funcionamento do protocolo FTP
Primeiramente foi feito o teste da conexão com o servidor FTP com o modem ligado ao
computador (porta serial), pois é mais fácil de ter o controle sobre os comandos enviados e recebidos
pelo modem (aparecem na tela do programa terminal, em vez de LCD, por exemplo). Foi utilizada a
ferramenta de comunicação serial USART Terminal do software MikroC PRO for PIC. Percebeu-se
que é importante enviar ao modem os comandos que especificam a taxa de transferência, tipo de
transferência de bytes e controle de fluxo nulo, pois a detecção automática desses parâmetros por
parte do modem não funcionou corretamente em alguns testes (não recebia o "CONNECT" do
servidor). Os comandos para especificar esses parâmetros são:
AT+IPR=9600: especifica a taxa de transferência
AT+ICF=3: 8 bits de dados, 1 stop bit e 1 start bit
AT+FLO=0,0: sem controle de fluxo
Para estabelecer a conexão com o servidor FTP, deve-se inicialmente receber um IP da rede
GPRS (fornecido pela operadora telefônica), processo esse já realizado no projeto anterior. Em
seguida, especifica-se o tempo de "timeout" da conexão e busca-se a abertura da conexão:
AT#FTPTO=1000;
AT#FTPOPEN="<endereço do host>","<nome de usuário>","<senha>",0
Iniciada a conexão, é possível pedir para listar os arquivos presentes no servidor, deletar
arquivos, mudar de diretório e inserir arquivos no mesmo, mas para o projeto somente serão usados
os comandos de mudança de diretório e inserção de arquivos:
AT#FTPLIST
AT#FTPDELE=""<Nome do arquivo que se deseja deletar>"
AT#FTPCWD = "<Nome do diretório que se deseja acessar>"
AT#FTPPUT = "<Nome do arquivo que vou incluir>"
Após o envio do comando "FTPPUT", o servidor responde "CONNECT". A partir de então,
tudo o que é escrito é salvo nesse arquivo até que seja escrita a sequência de escape "+++" (é normal
acontecer de o servidor não entender essa sequência de primeira, portanto deve-se enviá-la até
receber "NO CARRIER" como resposta do servidor).
Para encerrar a conexão, basta enviar o seguinte comando:
AT#FTPCLOSE
O software utilizado para acessar o servidor e observar os arquivos presentes foi o FileZilla
Client.
53
4.2.2.3 Elaboração do código
Após se compreender os comandos e sequenciamento para realizar a conexão com o servidor
FTP, foi realizada a elaboração do código do programa.
4.2.2.3.1 Funções
Inicialmente foram criadas funções de auxílio na recepção e transferência de caracteres.
Essas são as funções mais importantes do programa, visto que o projeto consiste em basicamente
tráfego de dados. Em seguida, foram feitas funções auxiliares (codetxt_to_ramtxt) e de
processamento de dados para fins específicos (leitura_botoes e gps).
Figura 39: Função TX para transferência de caracteres
- Função TX:
A função TX faz a transmissão de uma string byte a byte. A flag "TRMT_BIT" indica
quando o buffer do registrador de transmissão do PIC encontra-se vazio, o que acontece quando não
há caractere sendo transmitido. Estando o buffer vazio, escreve-se no registrador TXREG o próximo
caractere que se deseja transmitir. Prossegue-se da mesma maneira até que todos os caracteres da
string sejam enviados (inclusive o de terminação 'NULL'). A função "strlen", presente na biblioteca
de strings, calcula o comprimento da string, sem contar o 'NULL'. Cabe ressaltar que todos os
comandos enviados ao modem devem ser terminados por "\r\n", pois é a maneira que o mesmo usa
para reconhecer o término do pedido do comando.
- Função RX:
A função RX é a responsável por realizar a recepção de caracteres. Já havia sido observado
através da ferramenta USART Terminal do MikroCPro que o modem inicia e termina a resposta a
um comando com ambos os caracteres '\r' e '\n', conforme o exemplo abaixo:
PIC: AT\r\n
MODEM: \r\nOK\r\n
O conteúdo da resposta encontra-se entre essa sequência. Para captar apenas esse conteúdo,
dividiu-se a função em duas partes: a primeira (Figura 40) lê todos os caracteres enviados até o
primeiro '\n' (10, em ASCII); a segunda (Figura 41) salva o valor do primeiro caractere efetivo em
uma variável auxiliar (aux1), e continua recebendo os caracteres até o '\r'(13, em ASCII), que
representa o término da mensagem. A primeira parte é importante para o caso em que o sistema está
com eco, pois antes de retornar '\r''\n' o modem ecoa a mensagem enviada, ou seja, repete o que foi
54
passado para ele a fim de ser transmitido. Sem essa primeira parte, a repetição poderia ser
confundida com uma resposta do modem. Além disso, permite que o primeiro caractere recebido na
segunda parte seja de conteúdo, e não '\r\n'.
Para a recepção foram utilizadas funções próprias do compilador. A UART1_Data_Ready
verifica se o registrador de recepção está pronto para receber o caractere e se há dados a serem
recebidos, e a UART1_Read salva o caractere em uma variável do programa. Nesse caso não houve
a necessidade de usar Soft_UART, como ocorreu no projeto da casa inteligente, pois faz uso de
apenas uma saída serial.
A variável auxiliar aux1 será útil para o microcontrolador identificar a resposta do modem.
Não é necessário gravar o restante da resposta em uma string, pois as iniciais das mesmas já as
diferenciam (podem ser CONNECT, NO CARRIER, OK, ERROR, #SGAT(...) ). Isso evita o
desperdício de memória RAM.
Foi criado um sistema de contagem dentro da condição de espera de caractere (loop
while(!UART1_Data_Ready())). A finalidade disso é evitar que o programa fique travado
aguardando resposta do modem, de forma que após aproximadamente sete segundos o PIC saia desse
loop e envie o comando novamente.
Figura 40: Primeira parte da função RX
55
Figura 41: Segunda parte da função RX
- Função codetxt_to_ramtxt:
Essa função tem por finalidade receber uma string pré-definida e copiar caractere por
caractere para uma outra. Funciona de maneira semelhante à função srtcpy. Por exemplo: o
comando texto = codetxt_to_ramtxt("TESTE") faz com que texto[0] = 'T', texto[1] = 'E', texto[2] =
'S', texto[3] = 'T', texto[4] = 'E', texto[5] = NULL. Também teve grande importância no projeto, pois
evitou a necessidade de definir uma string para cada comando, economizando consideravelmente
memória RAM.
Figura 42: Função codetxt_to_ramtxt
- Função gps:
56
Simula a recepção de uma string de um GPS no formato NMA RMC. Realiza a separação
dos dados em strings Data, direção, velocidade. Essa separação é feita da seguinte maneira: como o
formato da string original é conhecido, contou-se o número de vírgulas até o dado desejado e
copiaram-se os caracteres presentes a partir dessa vírgula até a próxima (Figura 43). A contagem das
vírgulas é feita pela variável k. A cada contagem de vírgula, a variável j (posição dentro da string
principal) também é incrementada, pois deseja-se apenas o dado que se inicia após essa vírgula. É
importante fazer o último elemento da string de cada dado igual a 'NULL', pois esse caractere
representa o final da string quando é realizada a transmissão da mesma.
Os dados referentes à string Data são inicialmente salvos no formato
hora/minuto/segundo/dia/mês/ano.
Porém,
é
interessante
deixar
no
formato
ano/mês/data/hora/minuto/segundo, pois essa string será utilizada posteriormente para dar o nome do
arquivo ".txt" que será salvo no servidor FTP com os status do veículo, e essa maneira facilita a
ordenação dos mesmos. Portanto, a inversão da ordem foi feita conforme a Figura 44.
Figura 43: Separação das strings de dados na função GPS
57
Figura 44: Reordenação dos caracteres de Data
- Função botões:
Essa função tem por finalidade representar nos LEDs RA0 a RA3 os estados dos botões RC0
a RC3, considerando que o estado do LED só é alterado nas bordas de subida dos botões. Ou seja,
apertando-se o botão acende-se o LED, permanecendo nesse estado até que o botão seja apertado
novamente, o que o fará apagar.
Figura 45: Parte da função "leitura_botoes"
58
Na Figura 45, percebe-se que foram criadas duas variáveis para cada botão, uma relativa ao
estado anterior e outra ao estado atual. Isso é necessário para poder verificar se houve alteração de
estado. Caso os valores sejam distintos, é aguardado 1ms e é feita a comparação novamente. A
inserção desse delay é importante para evitar o efeito de "bouncing", ou seja, detecção dos ruídos
instantâneos produzidos ao apertar um botão. Caso após 1ms seja confirmada a alteração, o valor
anterior assume o valor atual. Dentro da situação de alteração de estado do botão, caso o novo valor
seja 1, o LED muda de estado. Esse processo descreve a detecção de pico de subida. Embora a figura
só mostre até o botão/LED1, o mesmo código foi usado para os demais botões/LEDs.
Figura 46: Uso do contador auxiliar na função leitura_botoes
Também foi utilizado um contador nessa função (Figura 46), pois a ideia é fazer com que a
leitura dos status dos sensores do sistema seja feita por um dado período (em torno de 10s), a fim de,
em seguida, poder ser feita a atualização no servidor.
4.2.2.3.2 Considerações sobre o código
Inicialmente, foram definidas algumas variáveis globais, pois as mesmas seriam utilizadas
em mais de um ponto ao longo do programa, além de muitas vezes poderem ser reutilizadas, tendo o
cuidado de não prejudicar o funcionamento em outras partes.
Na função main, atentou-se primeiramente para a especificação de alguns registradores e da
baud rate utilizada, a fim de obter coerência no funcionamento do sistema (Figura 47).
59
Figura 47: Especificação de registradores e baud rate
Em seguida, iniciou-se um loop infinito, dando a ideia de continuidade do sistema.
O loop é iniciado pela sequência de comandos que definem a desativação do eco, baud rate,
formato do caractere (8 bits de dados 1 stop bit, 1 start bit), sem controle de fluxo e demais
comandos para conexão na rede GPRS (Figura 29) já apresentados anteriormente.
Figura 48: Exemplo de envio de comando para o modem e análise da resposta
A Figura 48 mostra como é feito o envio de comandos e análise da resposta. Primeiro é
definida a string que deve ser enviada, sendo essa salva na variável global "texto" através da função
codtxt_to_ramtxt. Depois, dentro do loop é feito o envio dessa string caractere por caractere e
posterior recepção da resposta do modem, sendo guardada na variável aux1 apenas o primeiro
caractere, conforme mencionado anteriormente. Caso a variável recebida seja "O", relativo a "OK",
dá-se prosseguimento com as demais etapas. Caso seja distinta, retorna ao primeiro passo do loop.
60
Lembrando que com o contador na função RX, caso seja passado um tempo sem resposta a função
retorna aux1=NULL, portanto também retornando ao primeiro passo do loop.
A partir da obtenção de IP, são enviados os comandos relativos à conexão com o servidor
FTP. Para tal, seguem-se os passos descritos no teste inicial referido no item 4.2.2.2.
No comando AT#FTPPUT, o nome do arquivo a ser salvo é dado pela string com a data
ordenada Data. Para tal, foi utilizada a função strcat , que serve para concatenar strings, de forma que
o texto enviado seja: AT#FTPPUT="<Data>.txt" (Figura 49)
Figura 49: Nomeação do arquivo salvo no servidor FTP
Após o recebimento do "CONNECT", tudo que é escrito é salvo no arquivo, até que seja
enviada a sequência "+++". Para enviar os dados desse arquivo, é feita a concatenação dos dados do
GPS com os estados dos sensores, de forma que o conteúdo do arquivo fique da seguinte maneira:
<estados dos três primeiros LEDs, em 1 ou 0>;<estado do quarto LED, 1 ou 0 >;<"AT" caso o LED
RD5 esteja aceso, ou "BT", caso o LED RD4 esteja aceso>;<"BN", caso RD6 esteja aceso, ou "NN",
caso esteja apagado>;<Data>;<velocidade>;<direcão>. "AT" significa alta temperatura, "BT" baixa
temperatura, "NN" nível normal de combustível, "NB" nível baixo de combustível. Por exemplo, em
uma situação em que os LEDs acesos eram RD0, RD2, RD4 e a string do GPS era: "
$GPRMC,173020,4807.038,N,01131.000,E,022.4,211013,W*6A ", tem-se o seguinte formato no
arquivo salvo:
131021173020.txt: "101;0;BT;NN; 131021173020;022.4;NE"
Para detectar a sequência de escape, foi feito um processo semelhante ao de envio de
comando (Figura 50). É importante fazer esse teste de recebimento do "NO CARRIER" pois muitas
vezes o servidor não consegue identificar a sequência "+++" como de escape, sendo preciso reenviála. Percebe-se novamente a importância do contador na função RX, pois como o servidor não
identificou o "+++" como escape, e sim como informação a mais a ser escrita no arquivo, não retorna
nada. Ou seja, se não houvesse um contador para sair do loop de espera de caracteres após algum
tempo sem resposta, o programa ficaria travado.
61
Figura 50: Envio da sequência de escape "+++"
Após o arquivo ser salvo com sucesso, fecha-se a conexão FTP. Em seguida, é feita a
abertura de um socket TCP com o servidor de IP fixo, por onde o usuário envia os comandos ao
sistema.
Figura 51: Abertura de socket TCP
A variável m presente na Figura 51 é um contador que tem como finalidade controlar a
quantidade de vezes que o servidor não responde à solicitação de abertura de socket. Isso pode
ocorrer por falha na tentativa de conexão (o que devido ao número de tentativas aceitáveis, 5, é
menos provável) ou porque o servidor TCP não encontra-se conectado, o que significa que o usuário
não deseja enviar comandos naquele instante.
62
Figura 52: Recebimento dos comandos do servidor TCP
Caso a conexão seja bem sucedida, inicia-se uma comunicação bidirecional entre o servidor
TCP e o PIC presente no veículo. O modem envia ao servidor uma mensagem "CONECTADO", e
fica aguardando comandos do mesmo. Nessa aplicação, o servidor pode pedir para acender/apagar o
LED RD7 ou fazer aparecer no display do LCD do motorista "REDUZIR VEL", sendo que para cada
aplicação o modem responde ao servidor com "BLOQUEIO ATIVADO", "BLOQUEIO
DESATIVADO" ou "MENSAGEM ENVIADA" Figura 52. Cada comando é representado por um
número, ou seja, na realidade o servidor envia o número relativo à ação que deseja fazer. Isso facilita
a transferência do comando e evita erros.
Como manter aberto um socket TCP é custoso para a operadora (pois o protocolo TCP
possui uma série de atributos que garantem a confiabilidade da conexão), a conexão não dura mais
que 3 minutos (observado empiricamente), após esse tempo a operadora retira o IP que era dedicado
63
ao cliente. Portanto, o envio de comandos deve ser feito antes desse tempo. Quando a conexão cai,
seja essa interrompida pelo servidor ou pela operadora, o socket TCP é fechado (pois o IP de uma
das partes, ou de ambas, não estaria mais disponível para essa conexão) e o modem retorna "NO
CARRIER". Isso faz com que saia do loop apresentado na Figura 52.
Figura 53: Programa terminal HDC-Control
A Figura 53 mostra a interface do servidor TCP com o usuário. A opção "Conectar" faz com
que o servidor seja iniciado e fique aguardando cliente, ou seja, aguarda o pedido de conexão com o
modem. Quando a conexão já foi iniciada, esse botão aparece como "Desconectar". "Configurar
Conexão" permite que o programa atue como servidor ou cliente, conectado via TCP ou porta serial
(Figura 30). Ao abrir o programa, o primeiro procedimento a ser tomado nessa aplicação é configurar
a conexão como TCP e servidor na porta "1234". Os botões "Ativa o bloqueador", "Desativa o
bloqueador"e "Diminuir velocidade" são possíveis comandos a serem enviados para o modem. Essa
interface é criada a partir de um programa auxiliar, HDC-Creator (Figura 54), que permite, dentre
outras possibilidades, criar botões relativos a determinados comandos, de forma que o usuário não
precise conhecer os comandos AT e escrevê-los para se comunicar com o modem.
64
Figura 54: HDC-Creator
Tanto no caso de sair do loop da Figura 52 ou de não ter obtido resposta do servidor (caso
m=5), o ciclo se reinicia: é dado um tempo de leitura dos LEDs, seguido da conexão à rede GPRS
(obtenção de IP), conexão com o servidor FTP (para atualizar os dados dos sensores e do gps),
fechamento da conexão FTP e abertura de socket com o servidor TCP (verifica se há comandos a
serem executados). No início de cada ciclo, o valor de m é zerado.
5. Funcionamento do projeto
5.1 Casa inteligente
Primeiramente, foi feito um teste em cada placa com microcontrolador escravo, sem utilizar
a rede RS485. A lâmpada AC e o alarme funcionaram corretamente (circuitos da Figura 24 e da
Figura 22, respectivamente). A placa do LDR não foi concluída (faltou soldar alguns componentes,
incluindo a lâmpada DC), portanto não houve teste de sua funcionalidade.
Em seguida, foi testada a integração do circuito do microcontrolador mestre com o circuito
de cada microcontrolador escravo, separadamente. O teste consistia em enviar um comando para o
escravo especificado e verificar se esse respondia ao mesmo devidamente. O circuito da lâmpada AC
funcionou corretamente, porém o do alarme não respondeu (o buzzer do alarme não acionava quando
solicitado).
Paralelamente aos testes nos dispositivos, foram realizados outros testes com o circuito do
MAX232 integrado ao PIC 16F628 mestre (Figura 19). O PIC conseguiu enviar os comandos e
receber as respostas do modem corretamente, fazendo com que a parte de comunicação do projeto
(conexão com o servidor TCP) funcionasse efetivamente. O resultado do teste pode ser visto na
Figura 55, retirada do vídeo do funcionamento da comunicação. O item 4.1.2.2 explica como foram
obtidas essas respostas (entre a Figura 34 e Figura 35).
65
Figura 55: Comunicação bidirecional servidor TCP - modem
O último teste realizado seria a integração do sistema de comunicação modem-servidor com
o RS485, aplicado sobre o circuito da lâmpada (por ter sido o único escravo a responder
positivamente até então). Porém, ao juntar os códigos relativos à comunicação e à interação mestreescravo, notou-se que o PIC 16F628 não apresentava memória ROM suficiente. Portanto, o ideal
seria ter trabalhado com o PIC877A como mestre. Como não havia mais tempo para adaptar o
sistema para esse PIC, esse último teste não foi realizado.
A complexidade desse sistema estava no fato de integrar software, hardware e comunicação.
Portanto, quando havia alguma falha no funcionamento do sistema era necessário avaliar se isso era
devido a um problema de hardware (ruídos, solda mal feita, alimentação de corrente insuficiente,
componente queimado), no software (alguma incoerência no código, tanto na sintaxe quanto na
semântica) ou na comunicação propriamente dita (problemas devido à comunicação serial, taxas e
modos de envio de caracteres distintos, comandos incorretos, rede GPRS sem sinal).
5.2 Rastreamento de um veículo frigorífico
Para testar o funcionamento do sistema, foi imaginada uma situação a ser simulada:
O proprietário do veículo frigorífico acessou o servidor FTP a fim de verificar o estado do
mesmo e percebeu que estava da seguinte maneira: a temperatura da carga estava acima do limite
superior permitido; a porta do frigorífico estava mal fechada; e o veículo estava em movimento
(ignição ligada); a velocidade estava alta (43.2 nós, equivalente a 80Km/h). Além disso, não
conseguia entrar em contato com o motorista para averiguar o que estava ocorrendo. Suspeitando de
que se tratava de um roubo, imediatamente conectou o servidor TCP, aguardou o veículo se conectar
a ele e enviou os comandos de "Ativar o bloqueador" e "Diminuir a velocidade", a fim de que a
pessoa que estivesse conduzindo o veículo visse a mensagem e já fosse reduzindo a velocidade, pois
o bloqueador faria o carro parar em instantes. O GPS acusaria, então, a posição em que o carro
parou, permitindo que o proprietário pudesse recuperar o veículo.
Para representar essa situação no circuito, seguem-se as funcionalidades dos LEDs/Botões
apresentadas na Tabela 3. Essa situação é simulada da seguinte maneira: no início, durante o tempo
que é dedicado à leitura dos sensores (em torno de 10s), apertam-se os botões RC0 e RC3 uma vez a
fim de acionar os LEDs RD0 e RD3, e o LED RD5 já é inicializado como "1" (simula a entrada de
um sensor que não depende de atuadores), (Figura 56). Após esse tempo, é feito o processo
automático de envio de comandos AT para o modem, a fim de realizar a conexão à rede GPRS,
seguido pela conexão com o servidor FTP, gravação dados dos sensores e do GPS em um arquivo
.txt nesse servidor, fechamento da conexão com o servidor FTP, abertura de um socket com o
66
servidor TCP (para verificar se há comandos) e fechamento desse socket, completando um ciclo. Ao
término do primeiro ciclo, o arquivo "131024140015.txt" é gerado no servidor (Figura 57). Nessa
figura, nota-se a seguinte sequência: “100;1”, o que é coerente com o estado dos LEDs apresentado
na Figura 56. Antes das informações, percebe-se que o comando "AT#FTPPUT" também foi salvo,
representando uma falha no processo de conexão.
Figura 56: Início da simulação do funcionamento do sistema
67
Figura 57: Arquivos salvos no servidor FTP
No segundo ciclo, é feita a conexão do servidor TCP, de forma a simular a atuação do
usuário. Logo após a conexão ser estabelecida, o modem envia uma mensagem de confirmação
"CONECTADO". Quando o servidor envia o comando "3" e "1", o modem responde com
"MENSAGEM ENVIADA" e "BLOQUEIO ATIVADO", simulando os comandos enviados pelo
proprietário do veículo (Figura 58). A Figura 59 mostra a confirmação do recebimento do comando
enviado pelo servidor para o modem "Ativar bloqueador", que é simulado pelo acendimento do LED
RD7. A Figura 60 mostra como o condutor do veículo veria a mensagem enviada pelo servidor TCP.
.
68
Figura 58: Comunicação bidirecional no servidor TCP
Figura 59: Confirmação do recebimento do comando "1"
69
Figura 60: Mensagem visualizada pelo condutor do veículo e confirmação de recebimento do
comando "3"
Como a simulação foi coerente com o problema proposto, conclui-se que o funcionamento
da simulação do sistema de rastreamento do veículo frigorífero foi realizada com êxito.
6. Dificuldades e limitações do projeto
6.1 Casa Inteligente

Por uma questão de tempo, não foi possível a implementação, na prática, do circuito de
controle de luminosidade.

O programador do PIC nem sempre atualiza o programa após a compilação, o que gera a
desconfiança de que o programa continua apresentando problemas.

A alimentação do circuito do relé, do reed switch e da comunicação serial (entre modem e
PIC), enquanto fornecida pelo computador (corrente pequena), através do programador do
PIC, gerava um reset no programa. Quando a alimentação passou a ser feita por uma fonte
externa (corrente maior), o problema cessou.

O pino MCLR/ do PIC deve ser desativado no mikroC Pro para que o programa não sofra
reset.

O reed switch, por ser de vidro, é muito frágil.
70

O modem, quando se desconecta da rede GPRS, só envia essa informação após um delay, o
que impede que o servidor TCP envie dados ou mesmo comandos.

O programa Hyperterminal somente funciona como cliente.

A operadora Claro não permite que o modem opere como cliente.

Como o projeto não foi, de fato, implementado em uma casa, não foram encontradas
algumas dificuldades reais, como instalações elétricas (altas potências que o circuito poderia
não suportar) e uma possível interferência de ruídos.

Não foi desenvolvida uma interface mais elaborada com o usuário.

Não foi realizada a integração entre o circuito de comunicação e o de cada um dos
dispositivos.
6.2 Rastreamento de veículo frigorífico

Algumas vezes o comando "AT#FTPPUT="<Data.txt>"" é repetido dentro do próprio
arquivo, o que representa uma falha no início da conexão com o servidor.

O compilador utilizado (MikroC PRO for PIC v5.4) não faz a troca do IRP (dado que
identifica o banco de memória em que são salvas as variáveis do código), o que gera
problemas em termos de memória RAM. Como o código em questão apresenta grande uso
de variáveis, esse problema se tornou um grande limitante do projeto. Por exemplo, não foi
possível salvar mais dados do GPS no servidor FTP por falta de memória RAM.
7. Trabalhos futuros
7.1 Casa Inteligente
Para o projeto da casa inteligente, propõe-se que seja feito um robustecimento dos circuitos
de cada dispositivo, inclusive concluindo-se a placa do LDR, a fim de que os mesmos possam
funcionar devidamente. Após isso, fazer a junção dos programas relativos à comunicação com o
modem e à rede RS485, e aplicá-los ao sistema. Em seguida, seria interessante detalhar mais o
projeto a fim de aplicá-lo efetivamente a uma residência.
7.2 Rastreamento de veículos
A próxima etapa do projeto seria inserir os sensores e um GPS no sistema, em vez de simular
um resultado, como foi feito no trabalho. Após isso, criar um hardware próprio a fim de instalar o
sistema em um veículo.
8. Conclusão
Neste trabalho, foi apresentado o uso da rede GPRS para sistemas de automação residencial
e rastreamento de veículos. Foi realizado também um estudo sobre os principais protocolos de
comunicação envolvidos na funcionalidade desses sistemas.
71
Apesar de o projeto do sistema de controle remoto de dispositivos, base para automação
residencial, não ter funcionado conforme esperado, o trabalho foi bastante válido por ter servido
como grande fonte de aprendizado.
A segunda parte do trabalho, a simulação de um sistema de rastreamento de veículo
frigorífico, teve sucesso na aplicação prática. A fim de permitir o estudo de outros protocolos, como
o SMTP e FTP, foi utilizado uma placa de desenvolvimento em vez de construir um hardware
próprio. O uso dessa placa auxiliou bastante, pois a maior complexidade do projeto anterior estava na
elaboração do hardware. Há ainda, porém, alguns refinamentos a serem feitos, ficando os mesmos
para trabalhos futuros.
Para finalizar, ambos projetos agregaram bastante conhecimento teórico e prático, e
ressaltaram a importância de protocolos de comunicação em diferentes áreas.
9. Referências Bibliográficas
DA SILVA , Ivan Vieira Ferreira. DE CARVALHO, Sérgio Silva. Automação residencial de baixo
custo:
um
protótipo
com
acesso
web.
Disponível
em:
<http://semanaacademica.org.br/system/files/artigos/revistasemanaacademicadomoticaii.pdf>.
Acesso em: 19 fevereiro 2013.
FERNANDES, Bruno Coutinho. Construção de um sistema eletrônico de monitoramento de
consumo
de
água
residencial.
Vitória,
2007.
Disponível
em:
<http://www2.ele.ufes.br/~projgrad/documentos/PG2006_1/brunocoutinhofernandes.pdf>. Acesso
em: 14 março 2013.
JUCÁ, Sandro. Aplicações práticas de Eletrônica e microcontroladores em sistemas
computacionais.
Disponível
em:
<
http://www.maracanau.ifce.edu.br/~sandrojuca/Microcontroladores1.pdf>. Acesso em: 19 fevereiro
2013.
DE OLIVEIRA, Victor Hugo Freitas. Desenvolvimento de um sistema de telemetria remota.
Natal, 2009. Disponível em: < http://www.engcomp.ufrn.br/publicacoes/TCC-2009-1-1.pdf>.
Acesso em: 5 março 2013.
DOS SANTOS, Ricardo Antônio Silva. Domótica via dispositivos móveis. Ouro Preto, 2010.
Disponível
em:
<
http://www.em.ufop.br/cecau/monografias/2010/Ricardo%20A.%20S.%20Santos.pdf>. Acesso em:
3 março 2013.
BEZERRA, Romildo Martins. A Camada de Rede. Disponível em:
< http://www.ifba.edu.br/professores/romildo/downloads/ifba/rede.pdf>. Acesso em: 20 de outubro
de 2013.
ANTONIOUS, Stelius. TCP, UDP, TCP/IP and OSI Model. Disponível em:
< http://www.trainsignal.com/blog/networking-basics-tcp-udp-tcpip-osi-models>. Acesso em: 9 de
outubro de 2013.
72
DOS SANTOS, Thassia Lopes Correia. DE ANDRADE, Leonardo Ghidetti Moraes. Sistema de
Controle de dispositivos remotos via rede GSM/GPRS.
MikroElektronica, EasyPIC5 Manual.
Telit, AT Commands Reference Guide.
Telit, Easy GPRS User Guide.
Microship, 2003. Data Sheet PIC16F87XA.
Microship, 2009. Data Sheet PIC16F627A/628A/648.
MAXIM. +5V-Powered, Multichannel RS-232 Drivers/Receivers.
MAXIM. Low-Power, Slew-Rate-Limited RS-485/RS-422 Transceivers.
LDR. Disponível em: <http://pt.wikipedia.org/wiki/LDR>. Acesso em: 16 junho 2013.
Reed-switch. Disponível em: <http://www.if.ufrgs.br/mpef/mef004/20061/Cesar/SENSORES-Reedswitch.html>. Acesso em: 16 junho 2013.
Relé. Disponível em: <http://www.electronica-pt.com/index.php/content/view/179/37/>. Acesso em:
16 junho 2013.
Base 64 decoder-encoder. Disponível em:
<http://www.motobit.com/util/base64-decoder-encoder.asp>. Acesso em: 14 de agosto de 2013
Conceitos de email. Disponível em:
<http://technet.microsoft.com/pt-br/library/cc737894(v=ws.10).aspx>. Acesso em: 15 de agosto de
2013.
RFC 3207 - SMTP. Disponível em: <http://tools.ietf.org/html/rfc3207>. Acesso em: 25 de agosto de
2013.
Rastreamento. Disonível em: <http://www.controlando.com.br/quanto_custa.php>. Acesso em: 10
de outubro de 2013.
Arquitetura OSI. Disponível em:
<https://support.google.com/mail/answer/1074635?hl=pt-BR>. Acesso em: 10 de outubro de 2013.
NMEA Data. Disponível em: < http://www.gpsinformation.org/dale/nmea.htm>. Acesso em: 5 de
outubro de 2013.
73
ANEXO:
- Código referente à comunicação entre o servidor TCP e o modem (projeto da casa inteligente);
- Código referente à comunicação RS485 (Mestre e Escravo);
- Código referente à comunicação entre o servidor TCP, servidor FTP e o modem (projeto do
rastreamento de veículos).
74