Modelo Final Revisado

UNIÃO EDUCACIONAL DE CASCAVEL - UNIVEL
FACULDADE DE CIÊNCIAS SOCIAIS APLICADAS DE CASCAVEL

CURSO TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ALEXANDRE SCHVIDERSKI
SOLUÇÃO DE HARDWARE E SOFTWARE PARA AUTOMAÇÃO DE

FUNÇÕES AUTOMOTIVAS: ARDUINO EM VEÍCULOS DESPROVIDOS DE
ELETRÔNICA
Cascavel
2015
Solução de Hardware e Software para Automação de Funções

Automotivas: Arduino em Veículos Desprovidos de Eletrônica
Monografia apresentada ao Curso de

Graduação em Tecnologia em
Análise e Desenvolvimento de
Sistemas da Faculdade de Ciências
Sociais Aplicadas de Cascavel para
obtenção do Grau Tecnólogo.
Orientador: Fernando D’Agostini, Me.
Cascavel
2015
Solução de Hardware e Software para Automação de Funções

Automotivas: Arduino em Veículos Desprovidos de Eletrônica
Esta monografia foi julgada e aprovada para a

obtenção do grau de Tecnólogo em Análise e Desenvolvimento de
Sistemas do Curso de Graduação em Análise e Desenvolvimento de
Sistemas da
Faculdade de Ciências Sociais Aplicadas de Cascavel - UNIVEL
Cascavel, XX de xxxxxxx de 2015.
COMISSÃO EXAMINADORA
__________________________
Prof. Me. Fernando D’Agostini
Univel
(Orientador)
__________________________
Prof. Esp. Jean Piere Moretto
Univel
__________________________
Prof. Me. Anselmo Battisti
Univel
DEDICATÓRIA
Dedico este trabalho aos meus pais

e minha irmã, que sempre me
apoiaram a estudar e não desistir.
AGRADECIMENTOS
Primeiramente agradeço a Deus pela sabedoria e capacidade que me deu

para realizar este trabalho;
Agradeço ao professor orientador Fernando D’Agostini, pelo auxílio no
desenvolvimento do trabalho, pelos conselhos fornecidos;
Juntamente com os demais professores do curso, que contribuíram no
desenvolvimento do trabalho, mesmo que indiretamente, cada um com sua
matéria, mas todas com sua grande importância;
Também aos colegas de curso que apoiaram a ideia do trabalho e pelo
incentivo para continuar.
“Até um tolo pode passar por
sábio e inteligente se ficar calado.”
Provérbio de Salomão (17:28)
RESUMO
Schviderski, Alexandre. Solução de Hardware e Software para Automação de

Funções Automotivas: Arduino em Veículos Desprovidos de Eletrônica. 2015,
69. (Graduação do Curso de Tecnologia em Análise e Desenvolvimento de
Sistemas) Faculdade de Ciências Sociais Aplicadas de Cascavel – Univel.
Orientação Fernando D’Agostini. O presente trabalho tem por finalidade
apresentar uma solução de hardware aliada ao desenvolvimento de um código
de programação para modernizar funções de um automóvel desprovido de
tecnologia eletrônica contida em veículos atuais. Através da plataforma de
prototipagem Arduino foi feita a integração ao veículo de algumas
funcionalidades escolhidas para serem modernizadas, como controle remoto de
acionamento de luzes, buzina, partida e bloqueio do veículo. Também houve a
adição de novos recursos, como um módulo de GPS para aquisição de dados
sobre localização e um módulo RFID, para efetuar o desbloqueio do veículo com
uma chave específica caso o veículo seja bloqueado remotamente. Os
comandos para controlar o automóvel remotamente são enviados via Bluetooth,
e para bloquear o veículo ou saber sua localização, através de SMS. O veículo
escolhido para ser o objeto de estudo é do ano de 1973, época em que ainda
não haviam os recursos atuais de tecnologia automotiva, sendo ideal para que o
trabalho possa ser testado e representa uma boa parte da frota paranaense de
veículos. Porém foi preciso realizar uma revisão dos componentes elétricos do
automóvel, pois por se tratar de um veículo antigo, pode haver o risco de
acidentes envolvendo eletricidade. As funcionalidades que foram adicionadas
não devem interferir no funcionamento normal do veículo, salvo a opção de
bloquear o veículo, que faz com que ele desligue independentemente da vontade
do condutor. Após a implantação do sistema no veículo serão apresentados os
resultados obtidos e a conclusão sobre a viabilidade e funcionamento do
sistema.
Palavras-chave: Arduino, automação veicular, veículo antigo.

ABSTRACT
Schviderski, Alexandre. Hardware and Software Solution for the Automation of

Automotive Functions: Arduino in Vehicles Devoid of Modern Tecnology. 2015,
69. (Graduation of the Curso de Tecnologia em Análise e Desenvolvimento de
Sistemas) Faculdade de Ciências Sociais Aplicadas de Cascavel – Univel. Under
orientation of Fernando D’Agostini. This work has the purpose to present a
solution of hardware allied with the development of programming a code to
modernize some functions of an automobile devoid of the electronic technology
contained in nowadays vehicles. Through the prototyping platform Arduino was
made the modernization of some functions of the vehicle, like remote control of
actuation of lights, honk, start and vehicle lock.There was also the addiction of
new resources, like a GPS module, for the acquisition of data about the
localization and a RFID module, to unlock the vehicle with a specific key, in the
case of a remote lock. The commands to control the car remotely are sent via
Bluetooth, and to lock the vehicle or get the location, via SMS. The chosen vehicle
to be the study object is from the year 1973, epoch when there was no actual
automotive technology, being ideal so that the work can be tested, and represents
a good part of Paraná vehicles fleet. However, it was necessary to perform a
revision of electric components of the automobile, because it is an old vehicle,
and can occur the risk of accidents. The added functions cannot interfere in the
normal operation of the vehicle, except the option of vehicle lock, which makes
him turn off regardless of the driver’s wish. After the system deployment, will be
presented the results obtained and the conclusion about the viability and behavior
of the system.
Keywords: Arduino, vehicle automation, old vehicle.

LISTA DE FIGURAS
Figura 1 – Representação do Arduino UNO ..................................................... 21

Figura 2 – Modelos de Arduino ........................................................................ 22
Figura 3 - Relé.................................................................................................. 24
Figura 4 – Ligação de um Relé ........................................................................ 25
Figura 5 – Módulo de relés ............................................................................... 25
Figura 6 – Módulo Bluetooth para Arduino ....................................................... 27
Figura 7 – Satélites GPS .................................................................................. 28
Figura 8 – Triangulação da localização ............................................................ 29
Figura 9 – Shield GPRS para Arduino .............................................................. 31
Figura 10 – Módulo RFID para Arduino ............................................................ 32
Figura 11 - Incidente na parte elétrica .............................................................. 45
Figura 12 - Fiações sob o capô ........................................................................ 46
Figura 13 - Nova fiação sob o capô.................................................................. 48
Figura 14 - Caixa de fusíveis ............................................................................ 49
Figura 15 - Réguas de borne............................................................................ 50
Figura 16 - Parte principal do código do Arduino 1 .......................................... 55
Figura 17 - Parte principal do código do Arduino 2 .......................................... 58
LISTA DE QUADROS
Quadro 1 – A evolução da tecnologia embarcada nos automóveis .................. 19

Quadro 2 – Classes de Bluetooth..................................................................... 26
LISTA DE DIAGRAMAS
Diagrama 1 – Diagrama de casos de uso ........................................................ 35

Diagrama 2 – Diagrama de ligação dos componentes ..................................... 38
Diagrama 3 - Diagrama de atividade ................................................................ 41
Diagrama 4 - Diagrama de Estados do Arduino 1 ............................................ 42
Diagrama 5 - Diagrama de Estados do Arduino 2 ............................................ 43
SUMÁRIO
1 INTRODUÇÃO ................................................................................... 13
1.1 Objetivos........................................................................................... 14
1.1.1 Objetivo geral ..................................................................................... 14
1.1.2 Objetivos específicos ......................................................................... 15
1.2 Delimitação do Estudo .................................................................... 15
1.3 Estrutura do Trabalho...................................................................... 15
2 FUNDAMENTAÇÃO TEÓRICA......................................................... 17
2.1 Referencial teórico ........................................................................... 17
2.1.1 Histórico ............................................................................................. 17
2.1.2 Reserva de mercado de informática .................................................. 17
2.1.3 Tecnologia embarcada em automóveis ............................................. 18
2.2 Referencial tecnológico................................................................... 20
2.2.1 Plataforma Arduino ............................................................................ 20
2.2.2 Módulo de Relé .................................................................................. 23
2.2.3 Módulo Bluetooth ............................................................................... 26
2.2.4 Módulo GPS....................................................................................... 27
2.2.5 Shield GPRS ...................................................................................... 30
2.2.6 Módulo RFID ...................................................................................... 31
2.2.7 Smartphone ....................................................................................... 33
3 PROTOTIPAGEM DA SOLUÇÃO ..................................................... 34
3.1 Funcionamento do sistema............................................................. 34
3.1.1 Diagrama de casos de uso ................................................................ 35
3.1.2 Requisitos do sistema ........................................................................ 38
3.1.3 Diagrama de Atividade ....................................................................... 40
3.1.4 Diagrama de Máquina de Estados ..................................................... 41
3.2 Ligações Físicas .............................................................................. 44
3.2.1 Veículo, problemas na parte elétrica .................................................. 44
3.2.2 Veículo, revisão elétrica ..................................................................... 47
3.2.3 Ligações nos Arduinos ....................................................................... 51
3.3 Ligações lógicas .............................................................................. 53
3.3.1 Código do Arduino 1 .......................................................................... 55
3.3.2 Código do Arduino 2 .......................................................................... 57
4 CONSIDERAÇÕES FINAIS ............................................................... 61
4.1 Dificuldades encontradas ............................................................... 61
4.2 Sugestões de melhoria .................................................................... 63
4.3 Conclusão......................................................................................... 64
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................ 66
13
1 INTRODUÇÃO
Atualmente sistemas automatizados estão presentes em muitas áreas de

nossas vidas, trazendo praticidade e conforto à muitas pessoas. É possível citar como
exemplo os veículos modernos, que são fabricados com muitos recursos tecnológicos,
com sistemas para auxiliar o motorista em sua condução e também para supervisão
e controle do veículo.
Os automóveis modernos, fabricados durante esse estudo, possuem
tecnologia embutida suficiente para por exemplo: permitir que um carro estacione
sozinho, o que era impensável há somente alguns anos atrás; fazer com que a tração
e frenagem sejam controladas automaticamente, um item de série em muitos veículos;
permitir a partida eletrônica sem chave, uma comodidade conseguida em alguns
casos até à distância; sistema GPS (Global Positioning System ou Sistema de
Posicionamento Global), que disponibiliza a posição do veículo em qualquer local do
globo terrestre e pode ser utilizado para encontrar o veículo caso seja roubado ou
precise ser resgatado; também a comunicação Bluetooth está se tornando cada vez
mais comum nos carros atuais, comumente utilizado em conjunto com o sistema de
áudio, sincronizando um smartphone para atender ligações ou ouvir músicas. Porém,
mesmo com tantos veículos modernos transitando com estas tecnologias, os carros
mais antigos compõem uma grande parte da frota brasileira.
Um veículo fabricado há 20 anos, por exemplo, não conta com estes recursos
modernos. A tecnologia da época não custava tão barato a ponto de inserir estes
recursos em qualquer veículo, e nos dias atuais muitas destas máquinas automotivas
continuam em circulação. Somente no estado do Paraná 21,77% da frota de veículos
cadastrados no DETRAN tem mais de 21 anos (DETRAN PARANÁ, 2013).
Por ser uma parcela considerável da frota, é possível explorá-la utilizando
recursos que possam trazer benefícios a estes veículos, como a inserção de recursos
tecnológicos que foram criados muito tempo após a fabricação deles. Muitos
proprietários desse tipo de automóvel possuem valor sentimental pelo seus carros, o
que dificulta ou proíbe a alteração de sua originalidade visual. Por atribuir novos
recursos nessa frota se torna um desafio. Um meio de conseguir realizar este feito, é
através do Arduino, uma plataforma desenvolvida para criar protótipos de forma rápida
e fácil, com hardware e software open source e de custo acessível.
14
O Arduino é resultado de um desafio apresentado a Massimo Banzi (2011,

tradução nossa): “ensinar aos designers o mais básico sobre eletrônica para que eles
possam construir protótipos interativos dos objetos que estarão desenvolvendo”, que
resultou na criação do Arduino para facilitar a prototipagem das ideias de seus alunos
designers. A pequena placa eletrônica funcionou tão bem que acabou se espalhando
rapidamente e é usada para “pôr em prática as mais variadas ideias em prática, de
forma rápida e desenvolvimento ágil” (MARGOLIS, 2011, tradução nossa), inclusive a
proposta por este trabalho: incluir componentes eletrônicos modernos em veículos
sem nenhum componente eletrônico.
Já foi utilizado em outros projetos relacionados a veículos, como o de
Automação Veicular com Arduino e Android (BARROS, 2012); em um Modelo de
aplicação para rastreadores (SELLIACH, 2013); e também um Sistema Antifurto
Integrado ao Monitoramento de Presença de Crianças no interior de veículos
utilizando GPRS (General Packet Radio Services ou Serviço Geral de Pacotes por
Rádio) (MARTINS, 2010) desenvolvido como projeto final de graduação; porém feito
em veículo moderno em relação ao tipo de veículo utilizado no presente trabalho, um
Toyota Corola ano 2004, que já contém uma ECU (Electronic Control Unit ou Unidade
Eletrônica de Controle) de fábrica.
Por se tratar de um artefato idealizado para o ensino didático, o Arduino foi feito
para ser descomplicado, o que o torna uma ferramenta poderosa para poder fazer o
papel de um protótipo de módulo de controle para a modernização de um veículo, e
atende prontamente a necessidade abordada neste trabalho, de automatizar funções
e adicionar recursos tecnológicos em um veículo desprovido de eletrônica embarcada.
1.1 Objetivos
Para elaborar o presente trabalho é apresentado a seguir um objetivo geral que

direciona todas as etapas a serem realizadas, que por sua vez é decomposto em
quatro objetivos específicos como segue nos próximos itens.
1.1.1 Objetivo geral

15
Modernizar funções já existentes e adicionar recursos em um veículo antigo

utilizando e integrando a plataforma Arduino.
1.1.2 Objetivos específicos
a) Escolher um carro antigo e realizar uma revisão em seus componentes que

serão utilizados nesse trabalho;
b) Avaliar e escolher as funções que são possíveis de serem modernizadas;
c) Projetar e construir um protótipo de automação utilizando a plataforma
Arduino.
d) Instalar o protótipo no veículo escolhido e revisado para avaliar o resultado;
1.2 Delimitação do Estudo
As tecnologias a serem implementadas serão de partida e desligamento remoto

do veículo, através de um smartphone com Bluetooth ou via mensagem de texto,
também o acionamento da buzina e faróis remotamente. Adicionalmente o projeto
contará com um módulo GPS para aquisição da localização do veículo via SMS (Short
Message Service ou Sistema de Mensagens Curtas) e um equipamento de RFID
(Radio Frequency Identification ou Identificação por Radiofrequência) para segurança
na partida do veículo.
O sistema a ser projetado não tem a finalidade de fazer o veículo ser totalmente
automático, nem auxiliar o motorista durante a condução. O carro não irá se
movimentar sozinho e não haverá a supervisão sobre a condição do veículo (se está
realmente ligado, quantia de combustível, se precisa trocar o óleo, se está com
marcha engatada), pois a finalidade do trabalho não é alterar bruscamente os
equipamentos do veículo, somente inserir tecnologias sem impactar visualmente os
componentes originais.
1.3 Estrutura do Trabalho
No capítulo 2, serão abordadas as tecnologias que serão utilizadas no projeto,

com uma breve explanação sobre cada uma delas. No capítulo 3, será apresentado o
16
desenvolvimento da solução do trabalho, a exposição de diagramas, uma breve

explicação sobre a modelagem do sistema. Também será apresentada a forma como
o projeto será montado, como será a comunicação entre os componentes envolvidos
e a lógica implementada para que o sistema funcione.
No capítulo 4 serão apresentadas as considerações finais sobre o trabalho
realizado, se houveram dificuldades, sugestões propostas e sugestões futuras.
17
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é apresentado um breve histórico sobre a tecnologia veicular no

Brasil, bem como as tecnologias que são utilizadas durante o projeto. Também há
alguns diagramas para demonstrar como ocorre a interação entre os componentes
principais.
O capítulo está dividido em referencial teórico, tecnológico e diagramas do
projeto.
2.1 Referencial teórico
No decorrer deste tópico é abordado um panorama geral sobre a tecnologia

veicular no país.
2.1.1 Histórico
O primeiro exemplar automobilístico a desembarcar no país, um Peugeot Type

15, foi trazido de Paris em 1895 por Alberto Santos Dumont. Até então, o transporte
individual era feito por carruagens para os mais abastados e para os demais havia o
bonde. A partir daquele momento, pessoas com alto poder aquisitivo passaram a
importar seus veículos, que se tornou objeto de desejo e símbolo de status.
A montagem do primeiro veículo motorizado no Brasil teve início em 1919,
época em que montadoras como Ford e General Motors começaram a se instalar no
país. Porém, somente em 1956 foi que as multinacionais começaram a produzir os
automóveis (ESTADÃO, 2015). Quando os carros começaram a ser comumente
encontrados nas ruas na década de 70, o país implementou uma política de reserva
de mercado, e afetou muitos segmentos da indústria, incluindo a automobilística.
2.1.2 Reserva de mercado de informática
Segundo IKEHARA (1997), entre 1977 e 1991 o Brasil formulou e implementou

uma política de informática baseada num mercado reservado, exclusivo para
18
empresas de capital nacional em vários segmentos da indústria. O objetivo era que o

país se desenvolvesse tecnologicamente e criar uma indústria local competitiva.
Para a implementação da Política Nacional de Informática (PNI), o setor de
informática foi dividido em sete segmentos, que são: Processamento de Dados,
Teleinformática, Automação Industrial (que inclui eletrônica automotiva),
Microeletrônica e Instrumentação Digital. Apesar do objetivo nobre de desenvolver a
tecnologia no país, a própria Lei de informática (artigo 22 da Lei número 7.232/84)
obrigava as empresas estrangeiras a exportar parcela de sua comercialização para
poder fabricar bens de informática no país, o que desestimulava a chegada de novas
tecnologias e acabou atrasando o país nesta área. (IKEHARA, 1997)
Os produtos de tecnologia nacional não conseguiram conquistar o mercado
interno, pois os usuários exigiam padrões melhores, compatíveis com os
internacionais. Quando a nova Lei de informática (número 8.248/91) foi implantada,
retirou a restrição ao capital estrangeiro, acabou com a reserva de mercado em 1992,
e tentou estimular novamente o desenvolvimento e pesquisa de tecnologias no país.
E com o advento da internet, o compartilhamento de conhecimento ficou muito mais
fácil, e a indústria se desenvolveu trazendo novas tecnologias.
2.1.3 Tecnologia embarcada em automóveis
Com a evolução da eletrônica no mundo, desde a década de 70 os

componentes eletrônicos estão ganhando cada vez mais espaço no mundo
automotivo, que até então era dominado somente pela mecânica. No início dos anos
90 no Brasil os veículos tinham uma, duas ou três unidades de controle embarcadas,
que para a época já era um grande avanço.
Nos primórdios, os componentes eletrônicos eram utilizados para auxiliar a
redução de gases poluentes na atmosfera. Com o passar do tempo foram ganhando
papéis importantes dentro de sistemas de conforto, conveniência, entretenimento,
segurança, interatividade e outros sistemas dentro de um automóvel, tanto que
atualmente existem veículos com mais de cem módulos de controle eletrônico em seu
interior. (OFICINA, 2015)
Conforme estudo de Marinho (2015), estima-se que até 2024, 89% dos carros
19
novos serão comercializados com dispositivos conectados à internet. Mas toda esta
evolução percorreu um longo caminho até chegar no estado atual, em uma linha do
tempo demonstrada pelo quadro 1 a seguir:
Quadro 1 – A evolução da tecnologia embarcada nos automóveis

1965 O rádio toca fitas passou a ocupar os painéis dos automóveis no Brasil.
Antes disso o equipamento que teve a primeira versão lançada em 1930,
transmitia apenas a programação das emissoras.
1970 O sensor de estacionamento foi criado.
1981 Modelos de carros com vidros e travas elétricas começaram a ser
comercializados no País.
1990 Com a abertura do mercado para importações, chegaram novas tecnologias
ao Brasil e, entre elas, estava o rádio com leitor de CD.
1990 Alarmes com controle remoto passaram a ser utilizados no mercado
nacional.
1996 Início da aplicação da tecnologia GSM em veículos, que entre outras
funções, é utilizada em sistemas GPS.
1998 O som automotivo ganhou a função de leitura de arquivo MP3 e porta USB.
2000 Um novo sistema de entretenimento foi lançado. A primeira tela de DVD foi
instalada no encosto dos bancos dianteiros.
2008 Estacionar ficou mais fácil com o auxílio da câmera de ré.
2009 A novidade foi o som automotivo com a tecnologia Bluetooth.
2010 A década da conectividade. Sugre o MirrorLink, função que integra
smartphones ao sistema de som do automóvel. Isso tornou possível o
acesso aos aplicativos e funcionalidades do dispositivo móvel por meio do
sistema multimídia do carro.
2015 A tecnologia V2X, em desenvolvimento, permite que veículos sejam
controlados eletronicamente e interajam com outros carros, pessoas e
mecanismos. Nos Estados Unidos, testes estão sendo realizados a fim de
tornar a rede wireless mais confiável para o uso comercial em um futuro
próximo.
Fonte: MARINHO, 2015
Como pode-se perceber, após a liberação de importações na década de 90

20
começou a trazer novas tecnologias aos veículos. E atualmente a concorrência entre

as montadoras de automóveis também aumentou, pois a tecnologia aplicada no
veículo pesa na decisão dos motoristas quando adquirem um carro, e ela varia de
acordo com as fabricantes.
Contudo, os veículos que foram fabricados anteriormente ou durante o período
de reserva de informática ficaram de fora do avanço tecnológico natural, mas ainda
há meios de os inserir no contexto atual da tecnologia. E alguns dispositivos modernos
que podem fazer parte dos automóveis e que serão utilizados neste projeto serão
referenciados tópicos seguintes.
2.2 Referencial tecnológico
Nesta etapa são apresentados cada um dos componentes utilizado no projeto.

O que fazem, como funcionam e qual a utilidade de cada um no sistema a ser
implementado.
2.2.1 Plataforma Arduino
O Arduino é composto basicamente de duas partes principais: a placa Arduino,

que é o hardware onde serão conectados os outros componentes do sistema ou objeto
a ser desenvolvido; e o Ambiente de Desenvolvimento Integrado, ou simplesmente
IDE, que é a parte de software onde será desenvolvido um pequeno programa que
será carregado para a placa do Arduino. Esse programa é quem dirá a placa o que
ela deve fazer, e a linguagem de programação é baseada em C/C++.
Na prática, o Arduino funciona da seguinte forma: seu microcontrolador, um
chip com 28 pernas chamado de ATMEGA328P, fica lendo suas portas de entrada e
saída, processando-as conforme o software que o programador gravou em sua
memória flash, e retorna o resultado em suas portas conforme foi programado. Este
chip é o coração da placa (SENA, 2013).
A definição se uma porta é de entrada ou saída, fica a cargo do programador
do software, que define isso no código. Se alguma ligação for feita de forma errada e
21
causar um curto circuito, pode danificar o microcontrolador. Dependendo do modelo

do Arduino, é fácil trocar o CI controlador por outro e tudo volta a funcionar, desde que
outro componente da placa não tenha sido afetado.
Segue uma figura representando a localização e funções de cada parte do
Arduino modelo UNO, utilizado no projeto.
Figura 1 – Representação do Arduino UNO
Fonte: SENA, 2013
Tanto o hardware como o software do Arduino são open-source, o que permite

que toda a comunidade de interessados possa aprimorar seu hardware ou software
originais conforme a necessidade e possa compartilhar livremente seu resultado.
Dessa forma, há várias pessoas ou empresas que desenvolvem sua própria
placa Arduino, como por exemplo a empresa Robocore, que desenvolveu a
BlackBoard, que não passa de um Arduino um pouco mais robusto, que suporta ligar
um pouco mais de componentes ao mesmo tempo sem perder a eficiência.
Também há vários modelos de placa Arduino diferentes, mas servem para o
mesmo propósito, de criar protótipos de forma ágil. Na figura 2 a seguir são
demonstrados alguns modelos diferentes.
22
Figura 2 – Modelos de Arduino
Fonte: SENA, 2013
Já na parte de software, os desenvolvedores podem criar novas bibliotecas

para facilitar a comunicação de seus componentes eletrônicos dentro do código. A
biblioteca pode ser entendida como uma classe externa a o projeto, que pode ser
importada e utilizada como um objeto. Geralmente são criadas para funcionarem
como drivers dos componentes eletrônicos, abstraindo as funções do componente em
métodos para uma pessoa utilizar no código de seu programa.
Uma pessoa pode estar utilizando uma biblioteca padrão do Arduino para
receber a leitura de algum componente por exemplo, mas percebe que precisa que a
leitura seja um pouco mais refinada, ou que seja feita de forma diferente. Então ela
mesmo pode criar uma biblioteca nova, para interpretar a leitura do componente da
maneira que precisa para seu projeto.
Um exemplo é a biblioteca de GPS, a TinyGPS, que recebe a leitura do GPS
de forma mais simplificada, que acaba utilizando menos processamento do Arduino,
consequentemente consumindo menos energia, mas possui uma variação, a
TinyGPS++, que é mais robusta, exige mais do processador, por isso a escolha deve
ser feita com cuidado, pois se o seu projeto for ser alimentado por baterias, escolher
23
bibliotecas que sejam mais “leves” é o ideal.

Um programa do Arduino é dividido em três partes principais. A estrutura é a
primeira delas, composta de um método setup(), que define as configurações para o
hardware: quais portas serão utilizadas, se são entradas ou saída, se haverá alguma
comunicação serial e qual velocidade será; e um método loop(), que é o método que
o microcontrolador ficará executando infinitamente enquanto estiver ligado e
funcionando (ARDUINO, 2015, tradução nossa).
A segunda parte são os valores, que não passam das variáveis e funções que
serão utilizadas no programa. O software também poderá utilizar bibliotecas externas,
como se fosse um import de uma classe da linguagem Java, criar um objeto dessa
biblioteca e utilizar suas funções.
O que nos leva a terceira parte da estrutura do programa, que são as funções.
Elas podem ser criadas no corpo do programa, fora do escopo do setup() e do loop()
e serem invocadas dentro do loop() por exemplo.
Por fim, o Arduino é a base do projeto apresentado neste trabalho, funciona
interligando os componentes que foram instalados no veículo e também interpretando
o que o usuário do sistema (no caso o dono do carro) comandar, seja manualmente
ou via smartphone.
2.2.2 Módulo de Relé
Um relé é um componente eletromecânico que serve para fechar ou abrir um

contato, um interruptor. Eletromecânico porque envolve a atuação de uma força
elétrica juntamente com uma mecânica para realizar seu funcionamento.
Basicamente, ele funciona com uma bobina elétrica interna e um jogo de
contatos elétricos. Quando sua bobina é energizada, forma um campo magnético que
atrai o contato elétrico, fazendo-o abrir ou fechar, dependendo da construção do rele.
Quando a bobina é desligada, o contato volta a sua posição original, o que afeta
novamente o contato elétrico, alguns relés possuem uma mola que faz o contato
retornar a posição normal. Essa mola não pode ser mais forte que a atração da bobina,
se não o contato não se moveria (BRAIN, 2014).
O relé utilizado no projeto, é representado na figura abaixo:
24
Figura 3 - Relé
Fonte: RON, 2015
Na figura 3, a COIL é a bobina elétrica, que ao receber alimentação atuará no

POLE, que é a parte comum do contato. O contato NC (Normal Closed) significa que
quando a bobina não está alimentada, ele está normalmente fechado e quando a
bobina for alimentada, o contato será aberto até que a bobina seja desligada. Se o
relé for NO (Normal Open) significa que quando está em repouso, o contato será
normalmente aberto. Alguns relés trazem a notação NA para normal aberto, NF para
normal fechado. Outra notação que não está representada na figura 3 que pode surgir
é que onde está escrito POLE, também pode ser representado como contato comum
ou NC, estas diferenças surgem devido a diferença de fabricação do relé.
Este relé traz a possibilidade de poder escolher qual a posição será a normal
de funcionamento (se será normalmente fechado ou normalmente aberto). O conceito
de circuito aberto ou fechado pode ser entendido como se um equipamento será ligado
ou desligado, conforme a bobina seja energizada ou não.
No projeto será utilizado um módulo com vários relés ligados em uma placa,
que facilita a conexão com o Arduino. A ligação de algum equipamento no relé se dá
da seguinte forma: interrompe-se fisicamente o circuito que faz com que o
equipamento seja ligado e nessa interrupção coloca-se o relé, ligando a ponta comum
do contato do relé em uma extremidade da interrupção e a outra extremidade será
ligada no contato normal aberto ou fechado, conforme o funcionamento desejado. A
figura 4 exemplifica a instalação de um relé:
25
Figura 4 – Ligação de um Relé
Fonte: ENGENHEIRANDO, 2011.
Os relés foram utilizados para interagir diretamente com as partes elétricas do

veículo, pois suportam voltagem e corrente maiores do que as portas de entrada e
saída do Arduino. Farão a ponte de ligação da bateria do veículo com o componente
a ser ligado.
O Arduino é quem energizará a bobina do relé para fazer a comutação dos
contatos. Em resumo, é ele quem vai decidir se algum componente do veículo será
ligado ou desligado controlando o funcionamento dos relés. Abaixo a figura demonstra
o módulo de relés utilizado no projeto.
Figura 5 – Módulo de relés
Fonte: FILIPEFLOP, 2015

26
2.2.3 Módulo Bluetooth
Segundo BLUETOOTH SIG (2015), Bluetooth é uma tecnologia de

comunicação wireless via rádio que é simples, segura e está praticamente em todos
os lugares. Atualmente bilhões de dispositivos possuem essa tecnologia, desde
smartphones, computadores até equipamentos médicos e produtos de
entretenimento. Foi desenvolvida com a intenção de substituir os cabos para conectar
aparelhos, enquanto mantém um alto nível de segurança.
Quando dois dispositivos com Bluetooth estão habilitados para se conectarem,
isto é chamado de pareamento. As conexões entre eles permite que se comuniquem
através de uma rede wireless ad hoc (rede de ligação temporária entre os dispositivos,
que se comunicam diretamente um com o outro) de curta distância, conhecidas como
piconet.
As piconets são estabelecidas dinamicamente e automaticamente quando os
dispositivos que compõem a rede estão dentro do alcance do rádio. Cada dispositivo
da piconet pode se comunicar simultaneamente com sete outros, e cada um pode
pertencer a várias outras piconets, quando for conveniente ao usuário.
A especificação diz que o alcance mínimo deve ser de 10 metros, mas não há
limite máximo, depende da tecnologia que cada fabricante utilizar para definir o
alcance máximo de seu dispositivo Bluetooth. São divididos em classes de acordo
com o alcance como demonstrado no quadro 1:
Quadro 2 – Classes de Bluetooth

Rádios de classe 3 Alcance até 1 metro
Rádios de classe 2 Comumente encontrados nos
dispositivos móveis, alcance de 10
metros
Rádios de classe 1 Usado primariamente em casos
industriais, alcance de 100 metros
Fonte: BLUETOOTH SIG, 2015, tradução nossa.
A frequência de operação do Bluetooth é faixa de 2,4 a 2,485 GHz, usando

sinal full-duplex, com salto de frequência a uma taxa nominal de 1600 saltos por
segundo. Pode ser utilizado em aplicações que exijam transporte tanto de dados como
27
de voz (BLUETOOTH SIG, 2015, tradução nossa).

O módulo de Bluetooth utilizado no projeto foi desenvolvido para facilitar a
comunicação com o Arduino. Ele possui pinos para ser alimentado pelo Arduino e
também pinos para transmissão e recebimento de dados, que trafegam via serial entre
as placas. O Arduino pode tanto enviar como receber dados através do módulo
Bluetooth, interpretá-los e realizar alguma ação, conforme seu programa.
Figura 6 – Módulo Bluetooth para Arduino
2.2.4 Módulo GPS
O sistema GPS foi criado em 1978 pelo Departamento de Defesa dos Estados
Unidos, que detém os direitos até hoje. Tanto que se eles quiserem, podem deixar
todo o resto do mundo sem sinal.
O exército dos Estados Unidos possuem um aparelho de GPS especial, que
recebe um sinal secreto, exclusivo para o uso militar. No início, quando o país decidiu
liberar o sinal para os civis, em 1989, resolveram que o seria liberado um sinal piorado,
com erro de localização de cerca de 100 metros.
28
Porém, quando foi preciso usar o GPS pela primeira vez no campo de batalha,
na Guerra do Golfo (1990-1991), o exército tinha poucos receptores do tipo militar.
Isso os levou a comprar milhares de aparelhos civis para distribuir aos soldados, e o
Departamento de Defesa acabou liberando o sinal mais preciso para todos os
aparelhos, afim de não prejudicar os soldados. Após a guerra as restrições voltaram,
duraram até o ano 2000, quando os Estados Unidos liberaram o sinal exclusivo para
todos (VERSIGNASSI, 2014).
O que está por trás do GPS é um conjunto de 24 satélites que giram em torno
da terra a cerca de 20 mil km de altitude. Assim, sempre há ao menos quatro satélites
ao alcance de qualquer aparelho receptor no planeta; três deles ajudam a calcular a
localização e o outro ajusta o relógio do receptor. O sistema é baseado na sincronia
entre o receptor e o satélite (que carrega relógios atômicos), por isso o relógio simples
do receptor precisa ser calibrado o tempo todo.
Figura 7 – Satélites GPS
Fonte: COOKSEY, 2015?
Para o cálculo da localização é preciso a distância entre o aparelho receptor e

três satélites, para fazer a triangulação entre os pontos. A distância de cada satélite
para o receptor é vista como o raio de um círculo, e quando os três círculos são
interseccionados, sobram dois pontos em que os três círculos se sobrepõem. Um
destes pontos é descartado, pois fica sempre no espaço, sobrando o ponto da
29
localização do receptor no globo terrestre, o esquema é exemplificado na figura 8.
Figura 8 – Triangulação da localização
Fonte: adaptado de COOKSEY, 2015
O receptor sabe a distância entre ele e cada satélite ao alcance da seguinte

forma: o satélite envia um sinal codificado ao receptor na Terra, receptor que está
programado para enviar um sinal sozinho, no mesmo momento que sinal do satélite é
transmitido. O receptor calcula a distância entre ele o satélite pela diferença do tempo
que leva entre ele enviar o seu sinal e receber o do satélite. Por isso a importância
dos relógios estarem sincronizados (COOKSEY, 2015, tradução nossa).
O módulo GPS utilizado no projeto serve para o dono do veículo saber qual a
posição do carro em tempo real. Foi utilizado em conjunto com o próximo componente
a ser descrito, o Shield GPRS, para poder solicitar e receber a localização via SMS.
A comunicação do módulo com o Arduino ocorre via serial, e foi utilizada a
biblioteca TinyGPS para poder manipular os dados recebidos. O Arduino faz a
interpretação do SMS recebido, e conforme for programado, faz a requisição das
informações do GPS para formular a mensagem de resposta para o usuário, enviada
30
através de SMS pela placa de GPRS.
2.2.5 Shield GPRS
Esta placa provê meios de utilizar a rede GSM de telefones celulares para
receber ou enviar dados. Pode ser utilizado para envio e recebimento de mensagens
SMS, fazer ou receber ligações de voz ou ainda utilizar o GPRS para dados através
de internet móvel. Para ser utilizada, a placa exige um chip de celular que esteja
desbloqueado e que possa efetuar as operações a que será proposto, no caso deste
trabalho, será utilizado um chip pré pago com créditos inseridos. (LINKSPRITE, 2014,
tradução nossa).
Para que o shield possa ser utilizado sem problemas, é preciso ser ligado a
uma fonte de energia que disponibilize corrente suficiente para seu funcionamento.
Durante picos de utilização, ela consome energia além do que o Arduino utiliza
normalmente, atingindo um pico de corrente que uma porta USB padrão não consegue
prover se estiver alimentando o Arduino ligado ao shield. Por isso será utilizada uma
fonte externa para alimentar esta placa e também o módulo GPS, que pode ser a
própria bateria do carro ou uma bateria a parte.
O uso deste módulo GPRS no projeto é para poder receber os comandos do
usuário, seja para bloquear, desbloquear ou requisitar a localização do veículo, via
mensagem SMS de um smartphone. No momento que receber a mensagem, o
Arduino faz a verificação da mesma, para poder comunicar-se com os outros
componentes do sistema e efetuar a ação desejada. A figura 9 mostra a representação
de um Shield GPRS/GSM.
31
Figura 9 – Shield GPRS para Arduino
2.2.6 Módulo RFID
“RFID é uma tecnologia que consiste em colocar tags em objetos para

identifica-los por radiofrequência. Funcionam como se fosse um código de barras, mas
não precisam estar visíveis para serem lidos” (IGOE, 2012, tradução nossa).
O leitor de RFID envia um sinal curto de rádio, que é recebido pelo tag que
estiver ao alcance. O alcance depende do tamanho e da sensibilidade da antena do
leitor, e também da força da transmissão. Este conjunto de fatores pode fazer com
que a distância entre o tag e o leitor seja de apenas alguns centímetros ou até 10
metros.
Existem dois tipos de sistemas RFID: ativo e passivo. Os tags passivos são
compostos de um circuito integrado que contém um transceptor – conjunto de
transmissor e receptor – e uma memória ROM. O circuito é alimentado pela corrente
induzida do aparelho leitor do tag, e quando ele recebe a energia no circuito, envia ao
leitor o conteúdo de sua memória. Exemplo disso são os códigos de crachás para
leitura de cartão ponto, porteiros automáticos em prédios, ou ainda o sistema anti furto
32
nas lojas e mercados, onde os produtos possuem um tag instalado na embalagem ou

presos ao produto, que ativam o alarme caso passem pelo leitor na porta da loja.
No sistema ativo, o tag contém sua própria fonte de energia e transceptor de
rádio, e transmite o sinal em resposta à mensagem recebida do leitor. Por possuírem
alimentação própria, conseguem um alcance maior que o sistema passivo, mas
também são muito mais caros (IGOE, 2012). Um exemplo de utilização dos sistemas
RFID ativos, é o sistema de pagamento automático pedágio, onde o leitor perto da
cancela lê o tag instalado no carro e permite sua passagem.
No trabalho desenvolvido, foi utilizado um módulo passivo de RFID para
Arduino. A intenção é fazer com que o veículo seja liberado para uso quando o usuário
passar o tag com forma de chaveiro no leitor, como se fosse um sistema de partida
automática de um veículo moderno. Mas também será dele a função de reativar o
sistema caso esteja bloqueado para uso. A figura 10 mostra um módulo de RFID para
ser utilizado com o Arduino.
Figura 10 – Módulo RFID para Arduino

33
2.2.7 Smartphone
O smartphone atualmente é uma comodidade da vida moderna, para muitos,

algo indispensável, e não precisa de apresentação formal, pois virou algo normal no
cotidiano das pessoas, e é vulgarmente chamado de celular. Apesar de possuir
telefone no nome, essa virou apenas mais uma das funções que o aparelho possui, e
uma das menos utilizadas. Com tantos recursos adicionais para realizar a
comunicação entre as pessoas, com SMS e mensagens instantâneas de áudio, texto
e vídeo através da internet, a função de telefonia geralmente fica como última opção
de comunicar-se com alguém, sem contar que smartphones atuais top de linha
possuem um poder computacional maior que alguns computadores da década
passada.
Os aparelhos atuais possuem três sistemas operacionais principais: o IOS para
aparelhos exclusivos da Apple; o Windows Phone, disponível em aparelhos Nokia; e
o mais popular, Android, sistema open-source liderado pela Google e difundido em
outras marcas de smartphones. Por ser o mais popular, foi o escolhido para ser
utilizado neste trabalho, pois há um aplicativo disponível nesta plataforma que será
utilizado para realizar os testes com Bluetooth do trabalho, o ArduDroid.
O aplicativo desenvolvido por Hazim Bitar é gratuito e disponibiliza uma
interface para controlar o Arduino através da comunicação Bluetooth entre o
smartphone e o módulo do controlador. A interface não é tão agradável a um usuário
que não conhece o funcionamento do Arduino, porém, para o propósito do trabalho a
ser desenvolvido atende as necessidades satisfatoriamente. Por essa razão um
smartphone com Android foi utilizado durante o desenvolvimento do trabalho, tanto
para testar a tecnologia Bluetooth como também o serviço de mensagens curtas, o
SMS.
34
3 PROTOTIPAGEM DA SOLUÇÃO
Para o sistema funcionar, é necessário um smartphone com sistema

operacional Android, com um aplicativo para comunicação com o Arduino via
Bluetooth e possibilidade de envio SMS; quando houver sinal de torre disponível tanto
para o smartphone como para o módulo SMS e crédito disponível para envio de
mensagens.
O aplicativo utilizado para os testes foi o ArduDroid, encontrado gratuitamente
na loja de aplicativos, ele é quem faz a comunicação via Bluetooth do smartphone
com Módulo Bluetooth conectado ao Arduino. Para SMS o próprio aplicativo padrão
do smartphone já é o suficiente, e o usuário também precisará de pelo menos uma
tag de RFID para ser cadastrada no código do Arduino para validação do desbloqueio.
O usuário pode comandar algumas funcionalidades do veículo através do
aplicativo via Bluetooth, a uma distância de até 10 metros. Foram selecionados os
componentes do veículo: buzina, faróis, partida do veículo e bloqueio antifurto. A parte
de bloqueio também poderá ser acionada via SMS. O veículo também será revisado
na parte elétrica para poder atender aos requisitos que o sistema necessita para
funcionar.
Componentes modernos foram adicionados ao veículo para incrementar as
funcionalidades, como um GPS para o usuário requisitar o posicionamento do veículo
através de SMS e também um leitor RFID para o reset de comandos e habilitação do
veículo caso esteja bloqueado.
O sistema tem sua base em dois Arduinos modelo UNO, um atendendo as
solicitações de SMS e GPS, e outro para Bluetooth, RFID e acionamento dos relés.
Eles estão conectados entre si para caso algum comando recebido via SMS precise
atuação de relés.
Estas são as funcionalidades básicas do sistema, grande parte do trabalho se
dará em realizar a integração de todos estes componentes logicamente, no código de
programação dos Arduinos. A parte de desenvolvimento, lógica aplicada e códigos
serão apresentados no próximo capítulo do trabalho.
3.1 Funcionamento do sistema

35
Foram utilizados dois Arduinos do modelo UNO do trabalho. Um dos

controladores irá interpretar os sinais do módulo GPS e também do módulo GPRS,
enquanto o outro estará controlando o módulo de relés para o acionamento dos
componentes do veículo. Os dois estão ligados entre eles para caso receba algum
comando de acionamento do veículo via SMS.
O módulo de RFID é o responsável por limpar todos os comandos recebidos e
fazer o sistema reiniciar caso esteja bloqueado, também é ele que habilitará comandos
enviados do interior do veículo caso existam, como dar a partida por um botão físico,
ou desligar o veículo retirando a tag de perto do leitor. Já o módulo Bluetooth é quem
recebe os comandos do smartphone quando estiverem pareados, comandos de curta
distância, como ligar o veículo, acionar luzes ou buzina. O módulo GPRS recebe os
comandos a longa distância via SMS, como o de solicitação da localização do veículo
e pedido de bloqueio.
Abaixo, uma proposta inicial de como os componentes se comportarão,
segundo um diagrama de casos de uso.
Diagrama 1 – Diagrama de casos de uso
Fonte: Elaborado pelo autor
3.1.1 Diagrama de casos de uso
Representa de maneira geral como os componentes do sistema interagem e a

função de cada um. Cada componente é representado por um ator, seja hardware
36
pessoa ou veículo, e as funções que cada um desempenha são descritos nos casos
de uso. Basicamente o sistema pode ser dividido em duas partes que comunicam-se
entre si: uma recebendo comandos via SMS e a outra via Bluetooth e comando direto.
Seja via SMS ou Bluetooth, os comandos sempre partem da ação do usuário
através de um smartphone. O meio de comunicação é que vai definir qual Arduino vai
interpretar a mensagem e gerar uma resposta, comando ou ação. Embora cada um
utilize um meio de comunicação com o usuário, os Arduinos possuem um canal de
comunicação entre si, pois somente um deles é que vai comandar o veículo
diretamente.
As opções que o usuário tem para interagir com o veículo são as seguintes:
Bloqueio ou desbloqueio do veículo via SMS: o usuário envia a mensagem pelo
smartphone, o Módulo SMS irá receber o SMS, e o Arduino 1 a que está conectado
irá interpretar a mensagem em determinado ponto de sua rotina programada através
do monitoramento de SMS. Identificando que é um pedido para bloquear o veículo, o
Arduino 1 gera um comando de bloqueio e envia para o Arduino 2, que da mesma
forma, irá interpretar o comando em determinado ponto de sua rotina e quando
confirmar o comando, irá gerar a ação no relé que bloqueia o veículo; o processo é o
mesmo para o desbloqueio e reset de comandos, o que muda é a interpretação lógica
da mensagem.
Solicitação da localização do veículo: o usuário envia a mensagem via SMS
através do smartphone, o Arduino 1 interpretará a mensagem que receber através do
Módulo SMS, e solicitar as coordenadas ao Módulo GPS. Recebendo as
coordenadas, redige a resposta no formato de texto, montando um link com as
coordenadas conforme for programado. Envia a mensagem de resposta pronta para
o Módulo de SMS solicitando que envie ao usuário, que quando receber, poderá
acessar o link através pela internet no smartphone e saber a localização do veículo.
Neste caso de uso os Arduinos não se comunicam, pois todos os componentes
envolvidos já estão conectados ao Arduino 1.
Desbloqueio e habilitação de comandos através de cartão ou chaveiro RFID:
quando o usuário aproximar o seu cartão ou chaveiro RFID do leitor, a rotina do
Arduino 2 irá detectar o leitor de RFID leu uma tag e recebeu alguma informação.
Segundo a lógica programada, irá definir se o código do cartão é válido ou não. Caso
não seja, não terá ação nenhuma e continuará sua rotina; caso o código seja válido,
o Arduino 2 irá modificar o estado de bloqueio para desbloqueio e gerar a ação para
37
o relé específico, o que compreende o caso de uso de desbloquear o veículo. Também

apagará as luzes caso estejam acesas e desligará a buzina caso estejam acionadas
através dos relés; tudo isso faz parte do caso de uso de resetar comandos, que o
Arduino 2 terá em sua lógica de programação, e quando detectar a leitura de uma tag
RFID válida irá gerar ações nos relés especificados. Após desbloquear o veículo ou
resetar os comandos, irá deixar os componentes habilitados a receber novos
comandos.
Comandos de ligar e desligar veículo, acionar e desacionar luzes e buzina via
Bluetooth: o usuário vai fazer o uso de um aplicativo no smartphone para selecionar
qual ação deseja que o veículo faça. O aplicativo vai fazer o smartphone se conectar
ao Módulo Bluetooth e vai enviar o comando do usuário ao Arduino 2. O Módulo
Bluetooth vai receber o comando, e a rotina do Arduino 2 vai estar monitorando o
módulo. Quando perceber que chegou um comando, irá interpretá-lo para saber qual
relé que o usuário quer acionar ou desacionar e então gerar uma ação para o relé
correspondente. Então o Arduino 2 irá gerar a resposta ao comando recebido para
devolver ao aplicativo, enviando a resposta para o smartphone através do Módulo
Bluetooth. A lógica de intepretação de comandos do Arduino 2 é que vai fazer a
diferenciação para qual relé irá gerar a ação, de acordo com o parâmetro que receber
do Módulo Bluetooth.
Os componentes do sistema serão ligados como representados no diagrama 2,
onde os fios amarelo e azul representam a recepção e transmissão de dados
respectivamente, vermelho alimentação elétrica positiva, preto alimentação negativa
e verde para comando dos relés. Um dos relés é alimentado pelo Arduino 1 por falta
de portas de alimentação no Arduino que o controla, mas o comando de todos os relés
é feito somente pelo Arduino 2.
38
Diagrama 2 – Diagrama de ligação dos componentes
O diagrama 2, representado acima, foi elaborado com a ferramenta de

modelagem eletrônica Fritzing, que faz parte de uma iniciativa de hardware open
source, que visa fazer a eletrônica acessível a todos na forma de material criativo.
A iniciativa disponibiliza um software, atualmente na versão 0.9.2b que foi
utilizado para elaborar o diagrama 2, também dispõe de um website comunitário e
oferece serviços, como fabricação de placas eletrônicas, auxílio na criação de
projetos, workshops sobre Arduino e venda de produtos, para manter a organização
sem depender somente de doações (FRITZING, 2015).
No próximo tópico será descrito como o projeto será desenvolvido fisicamente,
tanto na parte do veículo e do Arduino.
3.1.2 Requisitos do sistema
Como se trata de um sistema desenvolvido para uma plataforma embarcada,

os requisitos são um tanto diferentes dos de um software. Alguns pontos devem ser
39
levados em consideração para que o dispositivo funcione corretamente, um exemplo

disto é a dissipação de calor e o consumo de potência.
A potência está diretamente ligada à geração de calor que do sistema, pois
quanto mais energia ele consome, mais os seus componentes eletrônicos vão
esquentar, e se não houver alguma forma de dissipar este calor, pode ocorrer danos
graves não só no dispositivo, mas também onde estiver instalado. Então um requisito
que o sistema deve atender, é funcionar utilizando o mínimo de potência possível,
onde parte pode ser controlada via código, deixando alguns módulos em standby para
não ficarem ligados o tempo todo ou ainda, se não tiver esta opção, preferir
componentes modernos que tenham um consumo de energia eficiente.
O consumo de energia também afeta a bateria, podendo causar desgaste
desnecessário caso os componentes consumam muita potência por muito tempo.
Inevitavelmente o módulo Bluetooth, o GPRS e RFID irão ficar ligados o tempo todo
para monitorar os novos comandos ou desbloqueio do veículo, então deve-se atentar
para não deixar os outros módulos ligados sem necessidade.
Outro requisito importante é o desempenho, pois em todo tipo de sistema, há as
entradas, um processamento que gera as saídas, e este processamento não deve ser
tão demorado a ponto do usuário ter que esperar muito tempo para obter uma resposta
do dispositivo. Então o sistema deve atender as requisições do usuário rapidamente
dentro da sua capacidade de processamento, que no Arduino modelo UNO é de 12
MHz.
Também é importante assegurar que o usuário consiga utilizar as funções do
dispositivo através de alguma interface. O dispositivo foi programado para atender
requisições específicas de comandos através de SMS e Bluetooth, e para enviar os
comandos Bluetooth deve-se parear os dispositivos, e após isto, utilizar o aplicativo
ArduDroid para enviar os comandos para o Arduino, nas portas específicas, ou enviar
através de texto o comando específico da função que desejar utilizar.
Por SMS o usuário pode bloquear o veículo e solicitar a localização, enviando o
comando de qualquer celular que consiga enviar SMS para o número de telefone do
chip da operadora que estiver inserido no módulo GPRS. O usuário irá receber pelo
SMS o link indicando a localização do veículo, a velocidade em que o veículo estiver
andando, juntamente com o horário e data da requisição.
Para efetuar o desbloqueio do veículo deverá ser utilizado o módulo RFID, que
estará dentro da caixa em que os Arduinos forem instalados no interior do veículo.
40
Através do código da tag que o usuário passar perto do módulo, o sistema irá
desbloquear o veículo e resetar os comandos que estiverem ativos através do
Bluetooth.
3.1.3 Diagrama de Atividade
O diagrama de atividade preocupa-se em descrever os passos a serem

percorridos para a conclusão de uma atividade específica; concentra-se na
representação do fluxo de controle de uma atividade (GUEDES, 2011). A utilização
do diagrama de atividade serve para demonstrar o funcionamento de forma geral do
sistema, como um fluxograma.
O ponto inicial é o comando do usuário, ou dependendo da situação, uma
mensagem recebida do outro Arduino. Representado abaixo, o diagrama de atividade
demonstra a interação entre os componentes de forma genérica, para que se obtenha
uma noção de como o sistema funciona.
41
Diagrama 3 - Diagrama de atividade
O diagrama mostra de forma geral o fluxo de um comando qualquer enviado

pelo usuário, e como os componentes do sistema se comportam com a mensagem.
No próximo tópico, será apresentado os diagramas de estado de cada Arduino, sendo
mais específico que o diagrama de atividade na forma que os processos acontecem
dentro do Arduino.
3.1.4 Diagrama de Máquina de Estados
Segundo GUEDES (2011), este diagrama demonstra o comportamento de um

elemento por meio de um conjunto finito de transições de estado, e também pode ser
42
usado para expressar o protocolo de uso de parte de um sistema. Este diagrama será
utilizado para representar o comportamento dos Arduinos conforme o meio de
transmissão dos comandos que o usuário desejar enviar ao veículo, ou seja, um
diagrama para comandos via Bluetooth, e outro para comandos via SMS.
Começando pelo Arduino 1, que está ligado ao módulo GPRS, segue o diagrama
de estados representando os comandos que podem ser enviados através de SMS,
tanto requisitando a localização ou bloqueio do veículo.
Diagrama 4 - Diagrama de Estados do Arduino 1
Como o Arduino 1 só interpreta os comandos SMS e gerencia o módulo GPS,

quando há a solicitação de bloqueio do veículo, delega esta ação ao Arduino 2, que
se encarregará de atuar no relé correspondente. Por isso o diagrama termina em dois
estados diferentes, um deles envia ação para o Arduino 2 e o outro indica o fim das
ações e retorno ao loop.
Já o Arduino 2 contempla mais funções que o Arduino 1; além de monitorar os
comandos que chegarem via Bluetooth, também atua nos relés de ação do veículo e
gerencia o módulo RFID para desbloqueio do automóvel.
Segue abaixo o diagrama de estados do Arduino 2, de quando recebe um
comando de ação no veículo através de Bluetooth, ou seja, partida ou desligamento
do automóvel, acionamento de buzina ou luzes. Para realizar o desbloqueio do veículo
43
o processo é diferente, não depende do módulo Bluetooth, somente da comunicação

com o módulo leitor de RFID. Quando perceber a presença do tag autorizado, reseta
os comandos que estiverem ativos e atua no relé de bloqueio, deixando-o desativado
para que o veículo possa voltar a funcionar. Segue o diagrama de estados do
funcionamento do Arduino 2:
Diagrama 5 - Diagrama de Estados do Arduino 2
Como pôde ser visto, os diagramas de estado são de fácil entendimento, já que o
Arduino funciona de forma simples; e também complementam o diagrama de
atividades, que mostra os estados de uma forma generalizada. Foram escolhidos os
diagramas comportamentais da UML (Unified Modeling Language – Linguagem de
Modelagem Unificada) para representar o projeto pois podem ser usados em
processos genéricos e não precisam de um sistema orientado a objetos para serem
construídos, ao contrário dos diagramas estruturais – diagrama de classes, diagrama
44
de objetos, e outros – que são melhores para representar uma aplicação orientada a
objetos, ao contrário do Arduino que faz uso de uma linguagem estruturada.
O diagrama de componentes da UML não foi apresentado por já existir o diagrama
de ligação de componentes (diagrama 2) feito na ferramenta Fritzing, que demonstra
os componentes que foram utilizados e como estão ligados fisicamente.
O próximo tópico irá demonstrar como as ligações físicas entre os componentes e
também no veículo foram realizadas, para que atenda aos requisitos descritos
anteriormente.
3.2 Ligações Físicas
Neste tópico são descritos os processos e procedimentos que foram feitos para
efetuar as ligações físicas entre os componentes, tanto na parte do veículo quanto do
Arduino. Começando pelo veículo, o próximo item descreve o que foi realizado no
mesmo para que o projeto se concretize.
3.2.1 Veículo, problemas na parte elétrica
Desde que o projeto foi idealizado sempre houve a preocupação com a parte
de instalação elétrica do mesmo, não só porque o sistema proposto irá interagir
diretamente com essa parte do veículo, mas também pela segurança do mesmo. Por
se tratar de um veículo muito antigo, ainda não existia instalado nele um item básico
de segurança da parte elétrica, uma caixa de fusíveis, que é o que impede que uma
falha acabe se tornando um acidente grave no veículo. Outra questão que poderia
interferir no projeto, é a fiação elétrica muito antiga, com muitos remendos e até
ligações desnecessárias, situações que colocam em risco os condutores e
passageiros do veículo e também podem interferir no projeto.
Um exemplo destes fatores somados está exposto na figura 11 apresentada a
seguir, um incidente que houve na parte elétrica e um dos motivos para que fosse feita
uma revisão completa na parte elétrica do veículo.
45
Figura 11 - Incidente na parte elétrica
Para que se entenda a figura 11, o que ocorreu foi um curto circuito entre os
fios positivo e negativo que alimentavam o acionamento dos vidros elétricos, logo atrás
do botão que comandam a abertura e fechamento dos vidros. Como pode-se notar na
figura, um terminal do fio estava quebrado por ser muito velho, e por isso não
encaixava corretamente no botão, o que fez com que ele se soltasse e encostasse no
outro fio causando o curto circuito. Um curto circuito que não for impedido aumenta a
corrente que circula no condutor, o que aumenta a temperatura do fio até chegar ao
ponto extremo que derrete a sua proteção externa, como a figura demonstra, e pode
até incendiar o veículo se chegar a encostar em algo facilmente inflamável.
Se houvesse a proteção de um fusível neste circuito dos vidros elétricos,
quando a corrente aumentasse, o fusível iria realizar seu trabalho de conter a corrente
muito alta, se rompendo e cortando a alimentação para evitar que o curto circuito
chegasse ao ponto demonstrado na figura 11. E o fato do conector dos vidros estar
velho e quebradiço também é preocupante, pois se o vidro elétrico, que é algo
46
“moderno” que foi instalado depois da fabricação do veículo já encontra-se neste

estado, a situação da fiação interna do veículo poderia estar muito pior.
Como se pode perceber, um item tão simples como um fusível pode evitar uma
tragédia, e a situação elétrica do veículo pode-se perceber que também precisava de
uma revisão completa. O incidente foi um fator relevante para que a revisão fosse
feita, mas também o estado em que se encontrava as fiações saindo da bateria era
preocupante, como demonstrado na figura 12.
Figura 12 - Fiações sob o capô
A figura 12 mostra a situação em que se encontrava a parte de alimentação

que saía da bateria, cheia de relés e até fusíveis instalados precariamente com cola
quente, diretamente na saída da bateria. Alguns dos relés e fiações dispostas já não
eram mais utilizadas, pois o antigo dono do veículo provavelmente as utilizavam para
um sistema de som, que já havia sido retirado antes de vender o automóvel. E da
mesma forma como ocorreu o incidente com o vidro elétrico, fios soltos sem utilização
nem proteção adequadas podem acabar contribuindo para um acidente de graves
proporções.
47
Ainda um último fator a ser citado é a questão de emendas nos fios, que
também pode afetar o projeto. Uma emenda mal feita em um condutor elétrico age
como uma resistência ao fluxo da corrente que passa por ele, o que faz com que
naquele ponto surja aquecimento. Se houver aquecimento, o condutor diminui sua
capacidade de condutividade e acaba afetando o circuito, que já não será alimentado
corretamente. Um exemplo encontrado no veículo eram os faróis de neblina, enquanto
um deles acendia normalmente, o outro quando acendia, demorava para acender, e
quando aceso não ficava com a mesma intensidade do outro. Tudo isto graças a uma
emenda, que aquecia o fio que chegava na lâmpada e impedia que os 12 volts da
bateria circulassem completos em todo o circuito daquela lâmpada.
Portanto, motivos não faltavam para que uma revisão completa na parte elétrica
fosse realizada, primeiramente pela segurança dos ocupantes do veículo, depois pelo
bom funcionamento do carro, para que o projeto pudesse ser realizado conforme
planejado. O estado que o veículo ficou após a revisão é descrito no próximo item.
3.2.2 Veículo, revisão elétrica
Para sanar os problemas encontrados e descritos no tópico anterior, foi feita

uma revisão completa na parte elétrica do veículo. Para isto, foi preciso levar o veículo
até um profissional capacitado e experiente de uma auto elétrica, e após explicar os
motivos da revisão e a finalidade do veículo para o projeto a ser desenvolvido, o
eletricista aceitou fazer a revisão elétrica para o projeto. O processo e resultado será
descrito a seguir.
O eletricista refez totalmente a parte elétrica do veículo, tirou todos os fios que
haviam, mesmo os que estavam funcionando e refez totalmente utilizando fios novos.
Retirou o que não estava sendo utilizado, repassou cada componente para ver se
funcionavam com a nova fiação e onde fosse preciso fazer emenda para desconectar
futuramente, utilizou plugues de encaixe, que evitam emendas e instalações erradas.
A figura 13 mostra como ficou a instalação sob o capô, onde antes havia
silicone perto da bateria agora não há mais. Ficou visualmente mais limpa a parte ao
redor da bateria e também mais segura.
48
Figura 13 - Nova fiação sob o capô
Também foi feita uma caixa de fusíveis, para proteger cada circuito do veículo,
algo que antes não existia. Agora o risco de ocorrer outro incidente como houve com
o vidro elétrico foi eliminado, não só para os vidros, mas para os outros componentes
que são alimentados dentro do automóvel. A caixa de fusíveis fica localizada no
interior do veículo, lado esquerdo, no espaço entre a porta do motorista e os pedais
do veículo, como mostra a figura 14.
49
Figura 14 - Caixa de fusíveis
Além da parte de segurança, aproveitando que a revisão contemplaria a troca

de toda a fiação, foi explicado ao eletricista sobre a proposta deste projeto de
comandar remotamente alguns componentes do veículo, para saber se seria possível
que ele puxasse a fiação destes componentes para o interior do veículo e deixar
disponível ao projeto.
Apesar do eletricista não entender inteiramente o projeto, conseguiu fazer o
que foi explicado a ele, e fez ainda mais. Foi deixado no interior do veículo duas régua
de bornes, com os contatos de praticamente todos os componentes disponíveis no
veículo, desde faróis alto e baixo, buzina, pisca alerta de esquerda e direita, ignição,
50
partida, até o contato para bloquear o veículo e controlar os vidros elétricos. As réguas
estão demonstradas na figura 15, abaixo.
Figura 15 - Réguas de borne
Com a revisão da parte elétrica e as réguas com os contatos dos componentes,

51
o projeto ficou se tornou viável e seguro para ser instalado no veículo. O Arduino
utilizará estas réguas para interagir com o veículo, através dos relés ligados a estes
contatos. Os fios da régua foram numerados após a revisão ser feita, para facilitar a
identificação dos componentes a que se relacionam. A parte de ligação do veículo
com o Arduino é explanada no próximo tópico.
3.2.3 Ligações nos Arduinos
O módulo de relés é o responsável por fazer a interligação entre os

componentes do veículo escolhidos para serem controlados e o Arduino. Os relés
foram ligados diretamente aos contatos da régua de borne, onde cada contato
corresponde a um componente do veículo. O quadro 3 relaciona os contatos
identificados da régua principal e seus respectivos componentes.
Quadro 3 – Contatos das réguas

Contato 1 12 volts (positivo) da bateria
Contato 2 Ignição
Contato 3 Motor de Partida
Contato 4 Meia luz (faróis menores)
Contato 5 Luz baixa
Contato 6 Luz alta
Contato 7 Buzina
Contato 8 Farol de milha
Contato 9 Pisca alerta esquerdo
Contato 10 Pisca alerta direito
Contato 11 Negativo da bobina de ignição
Contato 12 Negativo da bateria
Os contatos que foram utilizados no projeto são os seguintes:

- Contato 1, para alimentar os circuitos que serão fechados pelos demais
contatos;
- Contato número 2, simulando a meia volta na chave no carro;
- Contato 3, para dar a partida remota no veículo;
52
- Contato 6 que aciona a luz alta para sinalização visual;

- Contato 7 da buzina, uma sinalização sonora;
- Contato 11 em conjunto com o 12 para efetuar o bloqueio do veículo.
Para fechar ou abrir estes contatos através do Arduino, serão necessários 5
relés. Quatro deles serão compostos pelo módulo de relés apresentado no referencial
teórico, e o outro será um módulo com um único relé. Este módulo de relé único será
o que fará o bloqueio do veículo, enquanto o outro será utilizado para os acionamentos
do veículo.
Os módulos de relé serão ligados ao Arduino 2 utilizando as portas 8 à 12, o
módulo Bluetooth que também irá interagir no funcionamento dos relés, nas portas 2
e 3 e também o módulo RFID, nas portas 4 e 5. Os módulos de RFID precisam de
duas portas para realizar a comunicação, uma porta para transmissão e outra para
recepção dos dados. A forma que estão ligados está disposta no diagrama 2,
apresentado anteriormente.
Além da ligação com os módulos, o Arduino 2 também estará ligado ao Arduino
1, mas utilizará as portas analógicas para fazer a comunicação. As portas analógicas
do Arduino geralmente são utilizadas para fazer leitura de sensores analógicos, mas
também podem ser utilizadas como portas de entrada e saída pra propósitos
genéricos, ou pinos GPIO (General purpose input/output).
Esta característica permite que seja feita a comunicação entre os Arduinos
através do protocolo I2C (Inter-Integrated Circuit), que utiliza dois fios – um para definir
o clock e outro para transmitir dados – em uma comunicação bidirecional utilizando
duas portas analógicas. Funciona como um sistema mestre-escravo, onde só há um
mestre, que é quem gera o clock e inicia a comunicação com os escravos, que
respondem ao mestre quando recebem a requisição (NXP, 2014).
A interface de desenvolvimento do próprio Arduino disponibiliza uma biblioteca
específica para utilizar este protocolo, a WIRE (2015), que traz métodos e exemplos
de como realizar esta comunicação. Foi definido o Arduino 1 como mestre e o Arduino
2 como escravo, já que o Arduino 1 trabalhará de forma independente, atendendo as
requisições de SMS e GPS, e quando for preciso, se comunicará com o Arduino 2.
O Arduino 1 não é ligado a nenhum relé para comandá-lo, somente aos
módulos GPRS e GPS, e com o Arduino 2 para comunicação. O Módulo GPRS é
acoplado ao Arduino, cobrindo-o inteiramente, sem a necessidade de utilizar fios,
dessa forma, o Módulo GPS ficará ligado ao Módulo GPRS com fios, mas a
53
comunicação será diretamente com o Arduino.

Ambos os Arduinos foram alimentados pela bateria do veículo, pois suportam
tensões de 7 a 12 volts. Serão utilizados os contatos 1 e 12 da régua de bornes para
fornecer esta alimentação. Isso facilita a ligação dos componentes, pois tudo fica muito
próximo, sem haver a necessidade de utilizar fios muito longos.
O Arduino 1 recebe a alimentação direta da bateria, e através do seu pino de 5
volts alimentará o Arduino 2 e seus componentes. Além da alimentação, também terão
o fio de aterramento compartilhados, uma exigência para que a comunicação entre os
Arduinos ocorra corretamente. Já no Arduino 2 serão utilizados jumpers para que os
módulos de relé, Bluetooth e RFID sejam alimentados com as tensões necessárias ao
seu funcionamento, e todos os jumpers terão como fonte os pinos de 5 e 3.3 volts do
Arduino 2.
No próximo tópico é explanada a ligação lógica entre os componentes, ou seja,
o código utilizado para fazer o sistema funcionar.
3.3 Ligações lógicas
Mesmo com o trabalho sendo baseado grande parte em hardware, o Arduino,

que é o que faz o sistema realmente funcionar necessita de um software desenvolvido
especificamente para a finalidade que será utilizado. E software, segundo
FERNANDES (2002), é uma sentença escrita em uma linguagem computável, para
qual existe uma máquina capaz de interpretá-la, sendo composta por uma sequência
de instruções e declarações de dados. E ao interpretar o software, a máquina
computável é direcionada a realizar as tarefas especificamente planejadas.
E para realizar o desenvolvimento deste software da forma correta, foram
levados em consideração os métodos descritos pelo RUP (Rational Unified Process),
que segundo RATIONAL (1998), divide a construção de um software em quatro fases
principais, a concepção, elaboração, construção e transição.
Durante a fase de concepção do projeto, foi feita a modelagem do sistema e
também elaborado o diagrama de casos de uso, para ter uma visão geral do que o
sistema e o software precisariam ter de acordo com os requisitos funcionais. Nesta
fase é que foram delimitadas as funções que o sistema deve ter ou não, e também
onde foi identificado cada componente necessário para compor o sistema.
Definida a modelagem do sistema e passada a primeira fase, a elaboração e
54
construção do sistema acabaram se mesclando, pois ao mesmo tempo em que era

elaborado um pedaço de código fonte, o mesmo já era testado na hora, para garantir
que os componentes relacionados àquele trecho de código iriam responder
corretamente e se poderia ocorrer algum erro, tanto em razão do software ou do
hardware. Quando foi possível chegar a uma solução de software estável, então foram
documentados com os diagramas de atividade e de estado, tendo como base o código
fonte desenvolvido. Apesar do código não ter sido elaborado com orientação a
objetos, o que ocuparia muita memória, foi possível desenvolver orientado a eventos,
dividindo o código em procedimentos que são relacionados a cada caso de uso
previsto para o sistema.
Mesmo com a fase de elaboração – que é onde deveriam feitas todas as
análises do projeto e também construídos os diagramas e artefatos – e construção do
código fonte misturadas, foi possível desenvolver o sistema sem grandes problemas,
pois a primeira fase, de concepção foi muito bem elaborada. Tendo a visão geral do
sistema e como cada componente deveria se comportar, ficou muito mais fácil
desenvolver o código necessário para os Arduinos funcionarem.
Na última fase do RUP, a transição, que é onde o software é disponibilizado ao
usuário, pode ser encarada como o uso do sistema como um todo pelo usuário,
utilizando as funções com o Arduino e os componentes do sistema devidamente
instalados no veículo.
Mesmo sendo voltado para o desenvolvimento de grandes projetos de software,
que envolvem várias pessoas, equipes de desenvolvimento, metodologias e métricas
de desenvolvimento de software, o RUP também pode ser adaptado para o
desenvolvimento de software para um sistema embarcado. A seguir serão explicados
um pouco melhor como foi desenvolvida a lógica dos códigos desenvolvidos.
As ligações lógicas serão feitas através da programação do código que será
gravado nos Arduinos. Como dito anteriormente, o microcontrolador ficará executando
o código como um loop infinito, enquanto o hardware continuar ligado ou até que seja
resetado, mas quando voltar a ligar ou após o reset, continuará executando sua rotina
normalmente caso não seja alterada.
A estrutura do código é simples, dividida em dois métodos fundamentais: um é
o método setup e o outro loop. A parte do setup serve para definir algumas
configurações do microcontrolador, como por exemplo a velocidade que se dará uma
comunicação serial, se um pino será definido como entrada ou saída, iniciar variáveis.
55
Este método é executado somente uma vez cada vez que o Arduino é ligado ou
resetado, ao contrário do loop, que como o próprio nome diz, é executado
consecutivamente após ser executado o setup, e é o que permite o código ser alterado
dinamicamente conforme alguma condição que foi programada seja modificada.
Os códigos são exibidos e separados conforme o microcontrolador em que
foram gravados, nos próximos tópicos.
3.3.1 Código do Arduino 1
A seguir são apresentado os pontos principais do código gravado no

microcontrolador que é o mestre durante a comunicação entre os dois Arduinos e faz
o controle dos módulos GPRS e GPS.
Figura 16 - Parte principal do código do Arduino 1
Primeiramente, antes do método setup é feita a importação de bibliotecas e

instanciação das variáveis. As bibliotecas Wire e TinyGPS são utilizadas,
respectivamente, para a comunicação entre os microcontroladores e aquisição dos
dados do módulo GPS. As demais bibliotecas sms e SIM900 são utilizadas para a
56
comunicação e controle do módulo GPRS, e a SoftwareSerial é a responsável pelo

protocolo de comunicação entre o Arduino e os módulos de GPS e GPRS.
A variável gps é utilizada em um método chamado getCoordinates, que é onde
é feita a requisição dos dados atualizados do módulo GPS para formar o SMS de
resposta ao usuário. Estes dados são lidos pelo Arduino através da variável serialGps,
que estabelece a comunicação serial com o módulo. A variável gps organiza as
informações recebidas e no método getCoordinates a mensagem é montada e
armazenada na variável global sms_buffer, para ser enviada através do
sendResponse.
O método verifyNewSMS() se responsabiliza por se comunicar com o módulo
GPRS e verificar se há alguma mensagem nova. Caso haja, os dados desta
mensagem são armazenados nas variáveis sms_position, sms_text e phone_number.
Estas variáveis são reiniciadas no método loop(), para que o Arduino não fique
enviando SMS sem parar por estar respondendo uma mensagem antiga que já foi
respondida no loop anterior através do método sendResponse.
O sendResponse, onde é feita a requisição para o módulo GPRS de enviar o
SMS, toma como parâmetro a resposta do método verifyMessage. Após a variável
sms_text ser atualizada pelo verifyNewSMS(), a mensagem é verificada para o
Arduino saber se a mensagem é um pedido de bloqueio do veículo ou de localização
e retorna um char específico no método verifyMessage. Com base nesse char
retornado o sendResponse manda a resposta adequada à mensagem recebida do
usuário.
A maior dificuldade encontrada foi para fazer os módulos funcionarem em
conjunto, pois a biblioteca SoftwareSerial só consegue fazer a comunicação com um
módulo por vez, não consegue sustentar duas transações simultâneas. Se isto não for
tratado, sempre a última comunicação instanciada é que continua, o que tomou
bastante tempo até uma solução ser encontrada. A solução foi utilizar a variável
started, para indicar que a comunicação com o módulo GPRS foi iniciada.
A biblioteca SIM900 possui uma constante chamada GSM que pode acessar
seus métodos sem precisar instanciar uma variável, e um dos métodos desta
biblioteca é o begin. Este método faz a verificação do módulo para saber se está
ligado, cria a comunicação com o Arduino via SoftwareSerial e retorna verdadeiro se
tudo funcionar e o módulo estar pronto para uso. Caso o método retorne verdadeiro,
a variável started é alterada para true, e passa a ser a última conexão serial ativa.
57
Esta variável só é alterada para false no código quando após ser feita uma conexão
com o módulo GPS, para indicar que a conexão com o módulo GPRS foi perdida e
precisa ser reiniciada caso o módulo precise ser acessado novamente.
Então com a variável started é possível saber se a comunicação com o módulo
GPRS está ativa, e poder continuar sua rotina de verificar se há novas mensagens, e
também retomar a conexão com ele quando o módulo GPS for acessado. A rotina
para montar uma mensagem de resposta à localização já foi descrita, mas quando a
mensagem é para requisitar o bloqueio do veículo, é utilizada a biblioteca Wire.
Esta biblioteca, como já foi explicada, faz uma comunicação entre os dois
Arduinos. Quando a mensagem é verificada como bloqueio, inicia a comunicação com
o Arduino 2 e envia um char para indicar o pedido e fazer com que ele acione o relé
de bloqueio do veículo. O código completo gravado no Arduino 1 é maior, possui
métodos mais complexos para funcionar, e pode ser encontrado no Apêndice A. Já o
Arduino 2 possui um código mais simples, como pode ser visto no próximo tópico.
3.3.2 Código do Arduino 2
Como exemplificado no Diagrama 1, de casos de uso, o Arduino 2 é

responsável por atuar os relés, atender a comunicação via Bluetooth e RFID. São
necessárias quatro bibliotecas para que o conjunto funcione, como demonstrado a
seguir:
58
Figura 17 - Parte principal do código do Arduino 2
Seguindo do início do código, a biblioteca Wire serve para comunicação com o

Arduino 1, a SoftwareSerial para comunicação com o módulo Bluetooth e as
bibliotecas SPI e MFRC522 são responsáveis pelo protocolo de comunicação e
aquisição de dados com o módulo RFID. Em seguida vem as definições dos pinos do
Arduino que serão ligados aos módulos RFID, Bluetooth (dois pinos para cada um) e
59
relés, um para cada função do veículo que será automatizada.

Logo após, a instanciação das variáveis da biblioteca MFRC522, e
SoftwareSerial, indicando quais os pinos que serão utilizados para que a comunicação
seja efetuada. A variável keyCode é para identificação do cartão RFID que será
utilizado para resetar os comandos, verificar se é um cartão válido para fazer o reset,
e a variável command é para armazenar os comandos que chegam do outro Arduino
via Wire ou através da comunicação serial com o Bluetooth. Finalmente, as demais
variáveis globais são para armazenar o estado em que se encontram os pinos da
ignição, luzes, buzina e bloqueio do veículo, iniciando todas como desligados. Apesar
de algumas começarem com o estado HIGH, não quer dizer que esteja ligando o
componente, isto é uma característica do módulo de relés que depende da construção
do componente, no módulo com quatro relés, o HIGH quer dizer desligado, e no
módulo que tem somente um relé, o HIGH indica ligado.
Dentro do método setup, que é executado somente uma vez quando o Arduino
é ligado ou resetado, são iniciadas as comunicações com o outro Arduino e com os
módulos, e definidos os pinos dos relés como OUTPUT, pois é o Arduino que enviará
o sinal para os relés, e também já é enviado para o Arduino gravar o estado em que
os pinos devem estar, com o método digitalWrite. A biblioteca Wire é iniciada de modo
diferente do que o Arduino 1, pois o Arduino 2 é o escravo da comunicação, então
recebe um número de identificação quando é iniciado e também é definido um evento
para quando ele receber alguma informação do mestre, no caso, do Arduino 1. Dentro
do método receiveEvent a variável command pode ser alterada, mas também pode
ser modificada quando receber algum comando via serial, como será visto no método
loop.
Dentro do método loop, é feita a verificação dos comandos que chegam via
serial através do computador conectado ao Arduino 1 com baud rate de 4800 ou da
comunicação serial com o módulo Bluetooth. A verificação é simples, através de
estruturas seletivas compara se há alguma informação chegando via serial e caso
chegue o que se espera, atribuir à variável command.
Depois de passar pela leitura das portas seriais, faz a verificação do comando
recebido, através do método verifyCommand. Neste método a ação devida é tomada,
de acordo com o valor da variável command aciona outro método específico à ação
pretendida, seja para ligar o carro, acender ou apagar luzes ou buzina, desligar,
bloquear ou desbloquear o veículo. Estes outros métodos somente alteram o valor do
60
estado dos pinos e enviam o valor do estado para o pino específico, como pode ser
visto no código completo disponível no Apêndice B.
Após verificar o comando e realizar a ação específica, o método verifyKey é
que faz a leitura do cartão RFID caso esteja ao alcance do módulo. Neste método é
feita a validação do cartão apresentado, comparando seu valor com o da variável
keyCode, se o cartão for válido, então o desbloqueio do veículo e reset das variáveis
de estado são realizados, deixando o carro desligado, desbloqueado e se luzes ou
buzina estiverem acionadas remotamente, são desligadas também.
Toda esta verificação dentro do método loop é realizada a cada 500
milisegundos, como pode ser visto através do método delay. Com isto é encerrada a
parte lógica do sistema, onde tudo é realizado através dos códigos gravados nos
Arduinos. No próximo tópico são relatadas as dificuldades encontradas na realização
do trabalho.
61
4 CONSIDERAÇÕES FINAIS
Neste capítulo são apresentadas as considerações finais sobre o trabalho,

como as dificuldades encontradas, sugestões futuras e uma conclusão sobre o que
foi realizado.
4.1 Dificuldades encontradas
Cada módulo utilizado no projeto foi testado individualmente, para verificar se

o tanto o hardware como a biblioteca funcionavam corretamente. Assim, cada um foi
testado utilizando a própria alimentação vinda da porta USB do computador, e
funcionaram corretamente.
Porém, quando começaram a ser unidos começaram a surgir alguns
problemas, como o que ocorreu com os módulos GPRS e GPS. O que ocorreu foi uma
questão de software, que interferia no funcionamento físico dos módulos. A biblioteca
SoftwareSerial, apesar de fácil de ser utilizada, tem a característica de suportar
somente uma comunicação por vez, e isto causou um pequeno contratempo na
utilização dos módulos, até que fosse descoberta esta característica.
O desenvolvedor da biblioteca do módulo GPRS utilizou a SoftwareSerial para
estabelecer a comunicação com o módulo, e o módulo GPS também precisa de uma
instância da SoftwareSerial para aquisição dos dados. Então, sempre a última que foi
iniciada é a que continuava funcionando; por exemplo, se a comunicação com o GPS
fosse iniciada antes, durante os testes a mensagem com as coordenadas era enviada
via SMS com valores nulos, e se fosse iniciada depois, a mensagem era montada
corretamente, mas não era enviada.
Como quem deve ficar funcionando sempre é o módulo GPRS, ele deveria
manter uma comunicação sempre ativa, mesmo depois que fosse montada a
mensagem com as coordenadas do GPS – o que interrompe a comunicação anterior.
Para saber quando a comunicação fosse interrompida foi criada a variável booleana
started no código do Arduino 1, onde cada vez que o módulo GPS fosse requisitado
tinha seu valor alterado para falso, indicando que seria necessário reiniciar a
comunicação com o GPRS.
Assim, cada vez que for preciso voltar a rotina de verificação de novos SMS ou
enviar alguma mensagem, é feita a verificação desta variável, e caso tivesse com o
62
valor falso, é iniciada novamente a comunicação com o módulo GPRS. Isto resolveu
o problema da perda de comunicação com o módulo, mas ainda surgiram outros
problemas com o Arduino 1.
Outro ponto a se cuidar quando é feita a programação para o Arduino, é atentar
para o uso de memória disponível. Atualmente, desenvolver programas para
computadores, smartphones não requer tanto cuidado com a criação de muitas
variáveis, tamanho do código ou capacidade de processamento necessários. Mas
com o Arduino é preciso ter este cuidado, pois sua memória e capacidade de
processamento são limitados, e não se pode desenvolver um código sem ter esta
noção de capacidade do hardware.
O Arduino 1 ficou com um código bem carregado, pois as bibliotecas utilizadas
para funcionar o módulo GPRS ocupam um espaço razoavelmente grande, e ainda
precisa utilizar as bibliotecas para comunicar-se com o módulo GPS e com o outro
Arduino. A IDE de desenvolvimento alerta o uso de memória do código, quanto fica
disponível e se a capacidade de memória utilizada passar de 75% alerta que o código
poderá não funcionar direito.
Então, foi preciso alterar algumas variáveis para que o Arduino funcionasse
corretamente, por exemplo, o tamanho do array de char que recebe as mensagens
novas, ou o buffer para montar o SMS com as coordenadas teve que ter seu tamanho
reduzido. Também foi preciso eliminar a parte do código utilizada para debug do
código, que enviava mensagens para a tela do computador via serial. Dessa forma foi
possível liberar memória para o Arduino, porém a mensagem que o usuário recebe
quando solicita a localização do veículo também ficou mais enxuta, com menos
informações.
Ainda houve outro problema: após juntar os dois Arduinos e ligá-los para testar,
o Arduino 1 não respondia às mensagens de localização. Após rever os códigos e
certificar-se que tudo estava correto, continuava sem resposta, respondia somente a
mensagem de bloqueio. Após receber uma mensagem, bem atrasada e com
informações erradas sobre a localização, percebeu-se que o problema não era no
código, mas sim na alimentação.
Os testes estavam sendo feitos com os Arduinos alimentados pela porta USB
do computador, porém ela não consegue fornecer corrente suficiente para alimentar
todos os módulos, e a informação do GPS, quando veio, acabou veio errada devido a
alimentação insuficiente. Com isto em mente, foi utilizado outra fonte de energia, sem
63
modificar nada nas ligações ou no código dos Arduinos, e realizado outro teste, desta
vez, obtendo êxito.
Estes foram os problemas encontrados que eram mais relevantes. Outras
questões como dúvidas no código, ou sobre a linguagem de programação foram
facilmente sanadas com pesquisas na internet. O conteúdo sobre Arduino é vasto, e
muitas dúvidas acabam sendo sanadas sem muita dificuldade. No próximo tópico
serão apresentadas algumas sugestões para melhoria futura deste trabalho.
4.2 Sugestões de melhoria
Primeiramente, uma boa sugestão é utilizar algum outro modelo de Arduino,

que tenha capacidade tanto física como lógica maior que o modelo utilizado, o UNO,
pois dessa maneira, pode-se adicionar mais funções para controlar remotamente, o
que não foi possível neste trabalho devido ao limite de portas físicas e memória que o
modelo UNO apresentou.
Outra sugestão, caso o sistema seja utilizado para fins comerciais, é
desenvolver uma aplicação própria para smartphone, com uma interface mais
amigável. Neste projeto foi utilizado o aplicativo ArduDroid para comunicação
Bluetooth, o que foi suficiente para realizar os testes e atender a necessidade do
projeto, pois sua interface atende aos desenvolvedores, mas dificilmente agradará um
usuário final do sistema. O ArduDroid também não envia mensagens SMS, tendo que
utilizar o aplicativo padrão do sistema para fazê-lo, então um aplicativo que englobe
tanto o envio de SMS como a comunicação Bluetooth em uma interface única é uma
boa melhoria para o projeto.
Também é possível melhorar a parte das ligações físicas, caso seja um produto
comercial. Como o Arduino é feito para criar protótipos e também é open source, seria
possível criar uma placa própria, uma versão definitiva, onde os módulos que forem
utilizados já fiquem soldados diretamente nela, sem a necessidade de utilizar cabos
para conectá-los. Isto deixaria um visual menos poluído e proporcionaria uma melhor
organização no interior do veículo.
Uma questão que pode ser aprimorada é utilizar melhor os componentes do
sistema. O módulo GPS por exemplo disponibiliza outras informações que não
chegaram a ser utilizadas neste projeto, mas poderiam ser aproveitadas para
incrementar outras funções. O RFID também pode ser utilizado para outras
64
finalidades, assim como o módulo GPRS, que não teve todos seus recursos utilizados
porque o Arduino UNO não possui capacidade suficiente para habilitar mais funções
do módulo.
Também seria muito interessante colocar o sistema alimentado por uma bateria
própria, sem depender da bateria do automóvel. Isto garante que, se por alguma razão
a bateria do veículo seja desconectada por algum motivo, o sistema não pare de
funcionar. Além de eliminar a necessidade de adquirir um regulador de tenção,
também faz com que o equipamento instalado não acabe esgotando a bateria do
veículo e faça com que ele não dê a partida corretamente, já que fica ligado o tempo
todo para monitorar os comandos que serão recebidos.
Dispostas as sugestões, o que resta é apresentar uma conclusão sobre o
trabalho, que segue no próximo tópico.
4.3 Conclusão
Todas as funcionalidades do sistema funcionam corretamente, porém

dependem muito do ambiente em que o veículo se encontra. Após instalar o protótipo,
as funções de localização e bloqueio via SMS deixaram de funcionar, dependendo do
local que o veículo estava, pois não havia sinal de torre de celular disponível ou o GPS
não conseguia adquirir a localização.
Isso foi comprovado pois em alguns locais, não era recebida nenhuma
mensagem nem quando o Arduino 1 era reiniciado, e outras vezes, recebia a
mensagem de localização com o valor da localização vazio. Porém, quando testados
em ambiente controlado todas as funções funcionaram corretamente, com o GPS
pegando a localização correta e o módulo GPRS com sinal da torre enviando as
mensagens.
O sistema funcionou satisfatoriamente dentro do possível, mas se os
componentes fossem instalados em um melhor local dentro do veículo. Por exemplo,
se a antena do módulo GPRS e o GPS ficasse mais perto do ambiente externo, sem
muita interferência, o sinal de captação de ambos seria melhorado, e o sistema ficaria
mais confiável, porém deixa o sistema exposto. Ou outra alternativa seria a aquisição
de componentes melhores, mais potentes, porém inviabilizaria o desenvolvimento do
projeto.
Outra situação constatada, é que não se deve enviar um comando de bloqueio
65
sem ter a certeza que o Arduino recebeu e bloqueou o veículo, pois é muito perigoso
enviar a mensagem, e enquanto estiver andando com o veículo o Arduino receber a
mensagem atrasada e bloquear enquanto se estiver trafegando. Isso pode causar
sérios acidentes, como parar em um cruzamento movimentado, desligar durante uma
curva perigosa. Deve-se ter certeza que não há nenhum comando pendente de
bloqueio antes de trafegar com o veículo.
Fora a parte de SMS, o Bluetooth funciona corretamente, assim como o
desbloqueio via RFID também. O método de construção do código gravado no
Arduino, separado em eventos para analisar os comandos, simplificou bastante o
método de comunicação através de Bluetooth.
Enfim, os objetivos do projeto foram atingidos, pois as funcionalidades foram
adicionadas e funcionaram corretamente, embora seja influenciado pelos diversos
fatores já citados anteriormente. O veículo pode continuar funcionando normalmente,
sem a automação atrapalhar, tirando a parte do bloqueio, que atende o requisito de
transpassar o funcionamento normal, ou seja, mesmo se tiver ligado pela chave, o
carro é bloqueado e não liga enquanto não for desbloqueado. O trabalho foi muito útil
para aplicar o conhecimento adquirido durante o curso, tanto na parte de
programação, como na lógica de funcionamento.
66
REFERÊNCIAS BIBLIOGRÁFICAS
ARDUINO, arduino.cc. Language Reference. 2015. Disponível em:

<http://arduino.cc/en/reference/homePage>. Acesso em: 28 de mar de 2015.
BANZI, Massimo. Getting Started with Arduino. 2. Ed. U.S.A: O’Reilly Media,
2011.130 p. Disponível em: <http://it-ebooks.info/book/1338/>. Acesso em: 01 de
mar de 2015.
BARROS, Wagner Rocha. Automação Veicular com Arduino e Android. 2012. 59 f.

Trabalho de Conclusão de Curso (Graduação) – Curso de Tecnologia em Sistemas
para Internet, Centro Universitário Adventista de São Paulo, Engenheiro Coelho,
2012.
BLUETOOTH SIG, Bluetooth Special Interest Group. Bluetooth Basics, 2015.

Disponível em: <http://www.bluetooth.com/Pages/Basics.aspx>. Acesso em: 28 de
mar de 2015.
BRAIN, Marshall. Como funciona o relê. 2014. Disponível em:

<http://tecnologia.hsw.uol.com.br/rele.htm>. Acesso em: 28 de mar de 2015.
COOKSEY, Diana. Understanding the Global Positioning System (GPS). [2015 ?].
MSU GPS Laboratory – Department of Land Resources and Enviromental Sciences,
Montana State University, Bozeman. Disponível em:
<http://www.montana.edu/gps/understd.html>. Acesso em: 29 de mar de 2015.
DETRAN Paraná. Coordenadoria de veículos. Anuário Estatístico de 2013. [2014 ?].

Idade da frota de veículos do Paraná. Disponível em:
<http://www.detran.pr.gov.br/arquivos/File/estatisticasdetransito/anuario/anuario_atu
alizado_2013_X.pdf>. Acesso em: 01 de mar de 2015.
ENGENHEIRANDO, engenheirando.com. Automação Residencial, 2011. Disponível

em: <http://engenheirando.com/projetos/automacao/>. Acesso em: 04 de mai de
2015.
ESTADÃO, Jornal do Carro. 140 anos: evolução do transporte individual, 2015.

Disponível em: <http://www.estadao.com.br/jornal-do-carro/noticias/mercado,140-
anos-evolucao-do-transporte-individual,22837,0.htm>. Acesso em: 25 de mai de
2015.
FERNANDES, Dr. Jorge Henrique Cabral. O que é um Programa (Software)?. 2002.

Disponível em:
<http://www.cic.unb.br/~jhcf/MyBooks/iess/Software/oqueehsoftware.html>. Acesso
em: 06 de set de 2015.
67
FILIPEFLOP. GSM GPRS Shield para Arduino EFCom SIM 900 + Antena, 2015.
Disponível em: < http://www.filipeflop.com/pd-77833-gsm-gprs-shield-para-arduino-
efcom-sim900-antena.html?ct=41d98&p=1&s=1>. Acesso em: 04 de mai de 2015.
FILIPEFLOP. Kit Módulo Leitor Rfid Mfrc 522 Mifare, 2015. Disponível em:
<http://www.filipeflop.com/pd-6b883-kit-modulo-leitor-rfid-mfrc522-
mifare.html?ct=41d96&p=1&s=1>. Acesso em: 04 de mai de 2015.
FILIPEFLOP. Módulo Bluetooth RS232 HC-05, 2015. Disponível em:

<http://www.filipeflop.com/pd-b4742-modulo-bluetooth-rs232-hc-
05.html?ct=41d98&p=1&s=1>. Acesso em: 04 de mai de 2015.
FILIPEFLOP. Módulo Relé 5V 4 Canais, 2015. Disponível em:

<http://www.filipeflop.com/pd-c0ce5-modulo-rele-5v-4-
canais.html?ct=41d96&p=1&s=1>. Acesso em 04 de mai de 2015.
FRITZING. Fritzing – Electronics made easy. Disponível em:

<http://fritzing.org/home/>. Acesso em 04 de jul de 2015.
GUEDES, Gilleanes Thorwald. Araujo. UML 2: Uma abordagem prática. 2. Ed. São
Paulo: ed. Novatec, 2011. 488p.
IGOE, Tom. Getting Started with RFID. 1. Ed. U.S.A: O’Reilly Media, 2012. 42 p.
Disponível em: <http://it-ebooks.info/book/1963/>. Acesso em: 20 de abr de 2015.
IKEHARA, Hideharu Carlos. A Reserva de Mercado de Informática no Brasil e

seus Resultados. Estudo de mestrado em economia, Unipar, 1997. Anais...
Akrópolis – Revista de Ciências Humanas da UNIPAR, v.5, n. 18,1997. Disponível
em <http://revistas.unipar.br/akropolis/article/view/1694>. Acesso em: 25 de mai de
2015.
LINKSPRITE, LinkSprite. SIM 900 GPRS/GSM Shield. 2014. Disponível em:

<http://linksprite.com/wiki/index.php5?title=SIM900_GPRS/GSM_Shield>. Acesso
em: 19 abr de 2015.
MARGOLIS, Michael. Arduino Cookbook. 2. Ed. U.S.A: O’Reilly Media, 2011. 724
p. Disponível em: <http://it-ebooks.info/book/1982/>. Acesso em: 01 de mar de 2015.
MARINHO, André. Evolução tecnológica dos carros, 2015. Disponível em:

<http://blogs.diariodonordeste.com.br/automovel/servico/evolucao-tecnologica-dos-
carros/>. Acesso em: 25 de mai de 2015.
MARTINS, Leandro Borges. Sistema Antifurto Integrado ao Monitoramento de

Presença de Crianças no interior de veículos utilizando GPRS. 2010. 65 f.
Monografia (Bacharelado) – Curso de Engenharia da Computação, Faculdade de
68
Tecnologia e Ciências Sociais Aplicadas do UniCEUB (Centro Universitário de

Brasília), Brasília, 2010.
NXP Semiconductors. UM10204 – I2C-bus specification and user manual.Rev. 6.

2014. Disponível em: <http://www.nxp.com/documents/user_manual/UM10204.pdf>.
Acesso em 09 de jul de 2015.
OFICINA, Notícias da Oficina Volkswagen. Capítulo 1: A evolução das redes de

comunicação dentro dos veículos. 2015. Disponível em:
<http://www.noticiasdaoficinavw.com.br/v2/2014/11/capitulo-1-a-evolucao-das-redes-
de-comunicacao-dentro-dos-veiculos/>. Acesso em: 25 de mai de 2015.
RATIONAL, the software development company. Rational Unified Process – Best

Practices for Software Development Teams. Rational Software White Paper
TP026B, Rev 11/01. 1998. Disponível em:
<http://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251
_bestpractices_TP026B.pdf>. Acesso em: 06 de set de 2015.
RON. Relay Pin Configuration, 2015. Disponível em:

<http://www.zen22142.zen.co.uk/ronj/cpr.html>. Acesso em: 04 de mai de 2015.
SELLIACH, Lucas Alves. Modelo de Aplicação para Rastreadores utilizando

Protótipo criado com Arduino Due. 2013. 87 f. Trabalho de Conclusão de Curso
(Graduação) – Curso de Ciência da Computação, Centro de Ciências Tecnológicas
da Terra e do Mar, Universidade do vale do Itajaí, Itajaí, 2013.
SENA, Hamilton. Curso Arduino Básico. In: CURSO ARDUINO BASICO, 1., out
2013, Cascavel. Anais… Toledo. Mobhis Automação Urbana Ltda, 2013. 209 p.
VERSIGNASSI, Alexandre. Como funciona o GPS?. O segredo das máquinas e

das indústrias. Coleção mundo estranho. Por dentro das coisas, p. 98-99. São
Paulo: ed. Abril, 2014.
WIRE library. Master Writer/Slave Receiver. 2015. Disponível em:

<https://www.arduino.cc/en/Tutorial/MasterWriter>. Acesso em 09 de jul de 2015.

Modelo Final Revisado

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelo Final Revisado

Enviado por

Direitos autorais:

Formatos disponíveis

UNIÃO EDUCACIONAL DE CASCAVEL - UNIVEL

FACULDADE DE CIÊNCIAS SOCIAIS APLICADAS DE CASCAVEL

SOLUÇÃO DE HARDWARE E SOFTWARE PARA AUTOMAÇÃO DE

Solução de Hardware e Software para Automação de Funções

Monografia apresentada ao Curso de

Solução de Hardware e Software para Automação de Funções

Esta monografia foi julgada e aprovada para a

Cascavel, XX de xxxxxxx de 2015.

Dedico este trabalho aos meus pais

Primeiramente agradeço a Deus pela sabedoria e capacidade que me deu

Schviderski, Alexandre. Solução de Hardware e Software para Automação de

Palavras-chave: Arduino, automação veicular, veículo antigo.

Schviderski, Alexandre. Hardware and Software Solution for the Automation of

Keywords: Arduino, vehicle automation, old vehicle.

Figura 1 – Representação do Arduino UNO ..................................................... 21

Quadro 1 – A evolução da tecnologia embarcada nos automóveis .................. 19

Diagrama 1 – Diagrama de casos de uso ........................................................ 35

Atualmente sistemas automatizados estão presentes em muitas áreas de

O Arduino é resultado de um desafio apresentado a Massimo Banzi (2011,

Para elaborar o presente trabalho é apresentado a seguir um objetivo geral que

1.1.1 Objetivo geral

Modernizar funções já existentes e adicionar recursos em um veículo antigo

1.1.2 Objetivos específicos

a) Escolher um carro antigo e realizar uma revisão em seus componentes que

1.2 Delimitação do Estudo

As tecnologias a serem implementadas serão de partida e desligamento remoto

1.3 Estrutura do Trabalho

No capítulo 2, serão abordadas as tecnologias que serão utilizadas no projeto,

desenvolvimento da solução do trabalho, a exposição de diagramas, uma breve

Neste capítulo é apresentado um breve histórico sobre a tecnologia veicular no

2.1 Referencial teórico

No decorrer deste tópico é abordado um panorama geral sobre a tecnologia

O primeiro exemplar automobilístico a desembarcar no país, um Peugeot Type

2.1.2 Reserva de mercado de informática

Segundo IKEHARA (1997), entre 1977 e 1991 o Brasil formulou e implementou

empresas de capital nacional em vários segmentos da indústria. O objetivo era que o

2.1.3 Tecnologia embarcada em automóveis

Com a evolução da eletrônica no mundo, desde a década de 70 os

Quadro 1 – A evolução da tecnologia embarcada nos automóveis

Como pode-se perceber, após a liberação de importações na década de 90

começou a trazer novas tecnologias aos veículos. E atualmente a concorrência entre

2.2 Referencial tecnológico

Nesta etapa são apresentados cada um dos componentes utilizado no projeto.

2.2.1 Plataforma Arduino

O Arduino é composto basicamente de duas partes principais: a placa Arduino,

causar um curto circuito, pode danificar o microcontrolador. Dependendo do modelo

Figura 1 – Representação do Arduino UNO

Fonte: SENA, 2013

Tanto o hardware como o software do Arduino são open-source, o que permite

Figura 2 – Modelos de Arduino

Fonte: SENA, 2013

Já na parte de software, os desenvolvedores podem criar novas bibliotecas

bibliotecas que sejam mais “leves” é o ideal.

2.2.2 Módulo de Relé

Um relé é um componente eletromecânico que serve para fechar ou abrir um

Fonte: RON, 2015

Na figura 3, a COIL é a bobina elétrica, que ao receber alimentação atuará no

Figura 4 – Ligação de um Relé

Fonte: ENGENHEIRANDO, 2011.

Os relés foram utilizados para interagir diretamente com as partes elétricas do

Fonte: FILIPEFLOP, 2015

2.2.3 Módulo Bluetooth

Segundo BLUETOOTH SIG (2015), Bluetooth é uma tecnologia de