1 o Ten RAQUEL LAMPAÇA VIEIRA RADOMAN SISTEMA MULTI-PROTOCOLO PARA TRANSFERÊNCIA DE DADOS. Rio de Janeiro

Transcrição

1 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) 1 o Ten RAQUEL LAMPAÇA VIEIRA RADOMAN SISTEMA MULTI-PROTOCOLO PARA TRANSFERÊNCIA DE DADOS Rio de Janeiro 2013

2 INSTITUTO MILITAR DE ENGENHARIA 1 o 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

3 c2013 INSTITUTO MILITAR DE ENGENHARIA Praça General Tibúrcio, 80 Praia Vermelha Rio de Janeiro - RJ CEP: 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 Radoman, Raquel Lampaça Vieira R131s Sistema Multiprotocolo para transferência de Dados; orientado por Marcus Vinícius dos Santos Fernandes. - Rio de Janeiro: Instituto Militar de Engenharia, p.: il. Projeto de Final de Curso - Instituto Militar de Engenharia Rio de Janeiro, 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

4 INSTITUTO MILITAR DE ENGENHARIA 1 o 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

5 SUMÁRIO 1. Introdução Objetivo Justificativa Metodologia Estrutura Revisão de Literatura Tecnologia GSM/GPRS Módulo GSM/GPRS GM862-QUAD Comandos AT A rede de comunicação O reed-switch O relé Funcionamento do relé Circuito do Relé O LDR (Light Dependent Resistor) Protocolo Modbus Estrutura mestre / escravo Formato da mensagem Endereço do escravo Função Parâmetros ou dados Checagem de erro Modos de transmissão Modo de transmissão ASCII Arquitetura OSI Camada de Aplicação Protocolo FTP Protocolo SMTP A Base Processo de autenticação Camada de Transporte Protocolo TCP versus UDP Camada de Rede Protocolo IP GPS NMEA formato RMC EasyPIC Descrição dos projetos Casa Inteligente Rastreamento de veículo Implementação Casa Inteligente: Hardware: Dispositivos controlados Acionamento do alarme

6 Acende / apaga lâmpada Controle de luminosidade Software Comunicação cliente/servidor Comunicação modem/ PIC Sistema de rastreamento de veículo Hardware Software Testes realizados com SMTP Teste do funcionamento do protocolo FTP Elaboração do código Funções Considerações sobre o código Funcionamento do projeto Casa inteligente Rastreamento de um veículo frigorífico Dificuldades e limitações do projeto Casa Inteligente Rastreamento de veículo frigorífico Trabalhos futuros Conclusão Referências Bibliográficas ANEXO

7 LISTA DE FIGURAS Figura 1 - Modem GSM/GPRS 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/RS Figura 4 - Funcionamento do reed-switch Figura 5 - Tipos de relé Figura 6 - Estrutura do relé Figura 7 - Circuito do relé Figura 8 - Contatos do relé Figura 9 LDR Figura 10: Arquitetura OSI de redes e a função de cada camada Figura 11: Protocolo FTP Figura 12: Exemplo de conversão de ASCII em base64 e a tabela de correspondência aos índices Figura 13: EasyPIC Figura 14 - Pinos do conector DB Figura 15 - Projeto do circuito do PIC16F628 mestre Figura 16 - Montagem do circuito em protoboard Figura 17 - Fresadora Lpkf Figura 18 - Esquemático do circuito do MAX Figura 19: Comunicação modem/ PIC Figura 20 - Esquemático do circuito do PIC 16F Figura 21 - Esquemático do circuito do alarme Figura 22: Montagem do circuito do alarme Figura 23 - Esquemático do circuito da lâmpada Figura 24: Circuito de acionamento da lâmpada Figura 25 - Esquemático do circuito do LDR Figura 26 - Esquemático do PIC 16F877A escravo Figura 27 - Configuração da conexão cliente Figura 28 - Conexão cliente Figura 29 - Conexão na rede GPRS Figura 30 - Configuração da conexão servidor Figura 31 - Socket full duplex Figura 32 - Rotina de recepção de caracteres Figura 33 - Caractere 'VT' Figura 34 - Envio de comandos ao Modem Figura 35 - Comunicação bidirecional Figura 36: Display de LCD acompanhando o envio dos comandos AT Figura 37: Conexão com o servidor SMTP "gmail" Figura 38: Conexão SMTP com o "gmail" bem sucedida por Telnet Figura 39: Função TX para transferência de caracteres Figura 40: Primeira parte da função RX Figura 41: Segunda parte da função RX Figura 42: Função codetxt_to_ramtxt Figura 43: Separação das strings de dados na função GPS

8 Figura 44: Reordenação dos caracteres de Data Figura 45: Parte da função "leitura_botoes" Figura 46: Uso do contador auxiliar na função leitura_botoes Figura 47: Especificação de registradores e baud rate Figura 48: Exemplo de envio de comando para o modem e análise da resposta Figura 49: Nomeação do arquivo salvo no servidor FTP Figura 50: Envio da sequência de escape "+++" Figura 51: Abertura de socket TCP Figura 52: Recebimento dos comandos do servidor TCP Figura 53: Programa terminal HDC-Control Figura 54: HDC-Creator Figura 55: Comunicação bidirecional servidor TCP - modem Figura 56: Início da simulação do funcionamento do sistema Figura 57: Arquivos salvos no servidor FTP Figura 58: Comunicação bidirecional no servidor TCP Figura 59: Confirmação do recebimento do comando "1" Figura 60: Mensagem visualizada pelo condutor do veículo e confirmação de recebimento do comando "3"

9 LISTA DE TABELAS Tabela 1 - Estrutura do framing Tabela 2 - Tipos de erro Tabela 3: Funcionalidade dos botões e LEDs

10 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

11 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

12 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

13 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

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

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

16 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

17 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

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

19 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

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

21 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 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 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 ( ), que foi enviada, o escravo retornará 85h ( ) 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 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

22 Código Identificação Significado 01h Função inválida A função solicitada pelo mestre não está implementada no escravo. 02h Sensor ou registrador Inválido O escravo não possui o sensor ou registrador especificado no comando enviado pelo mestre. 03h Valor de dados inválido Algum valor no campo de dados é inválido. 04h Falha no dispositivo Erro por parte do escravo durante a execução solicitada pelo mestre. 05h Estado de espera O escravo reconheceu o comando do mestre, mas o notifica que o mesmo será processado num período maior que o normal. 06h Dispositivo ocupado O escravo está atendendo outro comando. 07h Não reconhecimento O escravo não conseguiu executar o comando. 08h Checagem de erro Erro de paridade de memória O escravo detectou erro de paridade. 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 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

23 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

24 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

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

26 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 Protocolo SMTP O protocolo SMTP (Simple Mail Transfer Protocol) é o protocolo que permite transferir o de um servidor a outro em conexão ponto a ponto. Trata-se de um protocolo que funciona em modo conectado. O é entregue diretamente ao servidor de do destinatário. O protocolo funciona por meio de comandos textuais enviados ao servidor SMTP. Cada um dos comandos 26

27 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 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 do remetente. Se o comando for aceito, o servidor devolve a mensagem "250 OK" O comando seguinte é "RCPT TO: " seguido do 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" 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 . 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 2 6 = 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

28 Figura 12: Exemplo de conversão de ASCII em base64 e a tabela de correspondência aos índices Processo de autenticação A maioria dos servidores SMTP tem exigido um protocolo de autenticação para realizar o envio de . 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 s. 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 . Normalmente, o SSL está associado à porta 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

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

30 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 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 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 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 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, ,N, ,E,022.4,084.4,230394,003.1,W*6A Onde: 30

31 RMC " Recommended Minimum sentence C" Dado colhido às 12:35:19 UTC A Status A=ativo ou V=Void ,N Latitude 48 graus ' N ,E Longitude 11 graus ' E Velocidade em relação à terra em nós Direção de movimento em graus Data - 23 de Março de ,W Variação Magnética *6A Checksum, sempre inicia com * Esse foi o formato adotado para a simulação do projeto 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

32 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

33 A ideia inicial era utilizar também o protocolo SMTP, visando enviar os dados do sistema ao 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: 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

34 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 Figura 16 - Montagem do circuito em protoboard 34

35 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

36 Figura 19: Comunicação modem/ PIC Dispositivos controlados Figura 20 - Esquemático do circuito do PIC 16F628 36

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

38 Acende / apaga lâmpada Figura 22: Montagem do circuito do alarme 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

39 Figura 24: Circuito de acionamento da lâmpada 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

40 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

41 4.1.2 Software 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

42 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

43 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 Em seguida, conecta-se o servidor. 43

44 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

45 Figura 31 - Socket full duplex 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

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

47 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

48 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

49 4.2 Sistema de rastreamento de veículo Hardware Figura 35 - Comunicação bidirecional 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

50 Figura 36: Display de LCD acompanhando o envio dos comandos AT Tabela 3: Funcionalidade dos botões e LEDs Botão RC0 - Acende/ Apaga o LED RD0 - Simula a atuação sobre a porta do frigorífico (Abrir/ Fechar) Botão RC1 - Acende/ Apaga o LED RD1 - Simula a atuação sobre o capô do motor (Abrir/ Fechar) Botão RC2 - Acende/ Apaga o LED RD2 - Simula a atuação sobre a tampa do combustível (Abrir/ Fechar) Botão RC3 - Acende/ Apaga o LED RD3 - Simula a atuação sobre a ignição(ligando/ desligando) LED RD0 Simula um sensor na porta do frigorífico (Ligado = Aberta, Desligado = Fechada) LED RD1 Simula um sensor no capô do motor (Ligado = Aberto, Desligado = Fechado) LED RD2 Simula um sensor na tampa do combustível (Ligado = Aberta, Desligado = Fechada) LED RD3 Simula um sensor no sistema de ignição (Ligado = Motor acionado, Desligado = Motor desligado) LED RD4 Simula um sensor no controle da temperatura (Ligado = Temperatura baixa, Desligado = Temperatura acima da mínima) LED RD5 Simula um sensor no controle da temperatura (Ligado = Temperatura alta, Desligado = Temperatura abaixo da máxima) LED RD6 Simula um sensor no controle do nível de combustível (Ligado = Combustível acabando, Desligado = Nível normal) LED RD7 Simula o sistema de bloqueio do veículo (Ligado = Ativado, 50

51 Desligado = Desativado) Software 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 . 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

52 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: < da pessoa que envia>", aguarda-se o "OK" do servidor; "rcpt to: < do destinatário>", aguarda-se o "OK" e "Go ahead"; escreve-se "subject: <título do >", 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

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

54 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 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). - Função TX: Figura 39: Função TX para transferência de caracteres 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

55 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

56 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. - Função gps: Figura 42: Função codetxt_to_ramtxt 56

57 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

58 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

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

60 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

61 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 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, ,N, ,E,022.4,211013,W*6A ", tem-se o seguinte formato no arquivo salvo: txt: "101;0;BT;NN; ;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

62 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

63 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

64 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

65 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 explica como foram obtidas essas respostas (entre a Figura 34 e Figura 35). 65

66 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

67 servidor TCP (para verificar se há comandos) e fechamento desse socket, completando um ciclo. Ao término do primeiro ciclo, o arquivo " 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

68 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

69 Figura 58: Comunicação bidirecional no servidor TCP Figura 59: Confirmação do recebimento do comando "1" 69

70 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