ESTAC˘AO DE MONITORAMENTO DE POLUENTES~fabro/IF66J/Relatorios_Finais/2013_1/... · 3 Resumo Este...
181
UNIVERSIDADE TECNOL ´ OGICA FEDERAL DO PARAN ´ A ENGENHARIA DE COMPUTAC ¸ ˜ AO ALESANDRO ALESSI AMANDA MICOSKI LINS BRUNO EDUARDO DE OLIVEIRA MENEGUELE JONATHAN PONTES MORAIS DO NASCIMENTO TIAGO GREGIO DE AVEIRO ESTAC ¸ ˜ AO DE MONITORAMENTO DE POLUENTES MONOGRAFIA CURITIBA 2013
Transcript of ESTAC˘AO DE MONITORAMENTO DE POLUENTES~fabro/IF66J/Relatorios_Finais/2013_1/... · 3 Resumo Este...
UNIVERSIDADE TECNOLOGICA FEDERAL DO PARANA
ENGENHARIA DE COMPUTACAO
ALESANDRO ALESSI
AMANDA MICOSKI LINS
BRUNO EDUARDO DE OLIVEIRA MENEGUELE
JONATHAN PONTES MORAIS DO NASCIMENTO
TIAGO GREGIO DE AVEIRO
ESTACAO DE MONITORAMENTO DE POLUENTES
MONOGRAFIA
CURITIBA
2013
ALESANDRO ALESSI
AMANDA MICOSKI LINS
BRUNO EDUARDO DE OLIVEIRA MENEGUELE
JONATHAN PONTES MORAIS DO NASCIMENTO
TIAGO GREGIO DE AVEIRO
ESTACAO DE MONITORAMENTO DE POLUENTES
Monografia apresentada a disciplina Oficina de
Integracao 3, no curso de Engenharia de Com-
putacao da Universidade Tecnologica Federal do
Parana, como requisito parcial a aprovacao.
Professores: Joao A. Fabro
Heitor S. Lopes
CURITIBA
2013
3
Resumo
Este projeto consiste na construcao de uma Estacao de Monitoramento de Poluentes. Ela
e composta por tres partes: estacao base, sistema de comunicacao e sistema embarcado.
O sistema embarcado e uma estacao remota microcontrolada, composta por sensores e
um modulo de comunicacao. A Estacao de Monitoramento Remota e a responsavel pela
aquisicao de dados dos sensores e enviar estes a estacao base atraves do modulo de co-
municacao GPRS, o qual proporciona acesso a rede GPRS. A estacao base e composta
por uma estacao servidor e por estacoes cliente. O usuario podera ter acesso aos dados
obtidos via um website hospedado na estacao base servidor e acessado por uma estacao
base cliente.
Palavras-chave: Estacao de Monitoramento Remota. Sistema embarcado. Comu-
nicacao sem fio GPRS. GPS. Servidor. Gases Poluentes.
4
Abstract
This project consists on the construction of an monitoring station of pollutants. It is com-
posed of three parts: base station, communication system and embedded system. The
embedded system is a microcontrolled remote station, composed by many sensors and a
GPRS communication module. This remote station is responsible for capturing sensors
values and send these values to base station through the GPRS communication module,
which provides access to GPRS network. The base station is composed of a server and
the interface to the clients. The user may access/visualize all the captured data through
a website, which is hosted on the server.
Keywords: Remotely Monitoring Station. Embedded system. Wireless GPRS commu-
nication. GPRS. Server. Pollutants.
5
Lista de Figuras
1.1 Visao geral do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 Prototipo do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Diagrama de Funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1 Arquitetura da rede GSM/GPRS. . . . . . . . . . . . . . . . . . . . . . . . 23
3.1 Sensor de temperatura DS18B20 . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Sensor de umidade HS1101 . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Serie de sensores MQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4 LPCXpresso (LPC1769) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1 Visao Geral da EMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Acoplamento e alimentacao do sensor DS18B20 . . . . . . . . . . . . . . . 54
6.3 Organizacao de memoria do sensor DS18B20 . . . . . . . . . . . . . . . . 55
6.4 Transmisao de dados via I2C . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.5 Acoplamento e alimentacao do sensor BH1750 . . . . . . . . . . . . . . . . 57
6.6 Relacao entre a capacitancia do sensor e umidade . . . . . . . . . . . . . . 58
6.7 Circuito especificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.8 Pinos do sensor MQ-7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.9 Estrutura do sensor MQ-7 comprado pela equipe . . . . . . . . . . . . . . 60
6.10 Grafico de monitoramento sensor MQ-7 . . . . . . . . . . . . . . . . . . . 62
6.11 Grafico de monitoramento sensor MQ-135 . . . . . . . . . . . . . . . . . . 63
6.12 Fluxograma dos sensores de gas . . . . . . . . . . . . . . . . . . . . . . . . 70
6.13 Circuito montado para o sensor de umidade . . . . . . . . . . . . . . . . . 71
6.14 Fluxograma do sensor de umidade . . . . . . . . . . . . . . . . . . . . . . . 72
6.15 Fluxograma de interface com o sensor DS18B20 . . . . . . . . . . . . . . . 74
6.16 Fluxograma Interface com o sensor BH1750 . . . . . . . . . . . . . . . . . 77
7.1 Casos de Uso do Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.2 Diagrama de Caso de Uso do Website - Consultar Dados Antigos . . . . . 84
7.3 Diagrama de Caso de Uso do Website - Plotar Graficos . . . . . . . . . . . 86
6
7.4 Diagrama de Caso de Uso do Website - Visualizar Dados em um Mapa . . 87
7.5 Diagrama de Caso de Uso do Website - Remover EMR . . . . . . . . . . . 88
7.6 Diagrama de Caso de Uso do Website - Mudar Frequencia . . . . . . . . . 90
7.7 Diagrama de Caso de Uso do Website - Logar-se . . . . . . . . . . . . . . . 91
7.8 Diagrama de Caso de Uso do Website - Listar EMRs . . . . . . . . . . . . 92
7.9 Diagrama de Caso de Uso do Website - Listar Administradores . . . . . . . 94
7.10 Diagrama de Caso de Uso do Website - Remover/Adicionar Administradores 95
7.11 Diagrama de Atividades do Website - Opcoes . . . . . . . . . . . . . . . . 97
7.12 Diagrama de Atividades do Website - Logar-se . . . . . . . . . . . . . . . . 98
7.13 Diagrama de Atividades do Website - Exibir Informacoes em um Mapa . . 99
7.14 Diagrama de Atividades do Website - Consultar Dados Antigos . . . . . . 100
7.15 Diagrama de Atividades do Website - Plotar Graficos . . . . . . . . . . . . 101
7.16 Diagrama de Atividades do Website - Mudar Frequencia EMR . . . . . . . 102
7.17 Diagrama de Atividades do Website - Remover EMR . . . . . . . . . . . . 103
7.18 Diagrama de Atividades do Website - Opcoes para Administrador . . . . . 104
7.19 Diagrama ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.20 Tela Inicial do Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.21 Tela Consulta do Website 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.22 Tela Consulta do Website 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.23 Tela Configuracoes do Website . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.24 Tela Configuracoes do Usuario do Website . . . . . . . . . . . . . . . . . . 117
7.25 Tela com a Lista de EMR do Website . . . . . . . . . . . . . . . . . . . . . 118
7.26 Tela Alterar da EMR do Website . . . . . . . . . . . . . . . . . . . . . . . 118
8.1 Diagrama de estados para transmissao de pacotes em ambos lados da co-
municacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.2 Diagrama de estados para recepcao de pacotes de ambos lados da comu-
nicacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.3 Diagrama de sequencia bem sucedido na transmissao e recepcao de um
pacote em ambos lados da comunicacao. . . . . . . . . . . . . . . . . . . . 123
8.4 Diagrama de sequencia bem sucedido com a ultrapassgem do tempo de
limite de espera. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.5 Diagrama de sequencia mal sucedido por erro de CRC Invalido. . . . . . . 124
7
8.6 Diagrama de casos de uso geral do daemon. . . . . . . . . . . . . . . . . . 125
8.7 Diagrama de casos de uso “Mudar frequencia”. . . . . . . . . . . . . . . . . 126
8.8 Diagrama de casos de uso “Adicionar EMR”. . . . . . . . . . . . . . . . . . 127
8.9 Diagrama de casos de uso “Aquisicao de dados”. . . . . . . . . . . . . . . . 128
8.10 Diagrama de casos de uso “Atualizar IP”. . . . . . . . . . . . . . . . . . . 130
8.11 Diagrama de Atividade do Daemon - Inicial . . . . . . . . . . . . . . . . . 132
8.12 Diagrama de Atividades do Daemon - Recepcao . . . . . . . . . . . . . . . 133
8.13 Diagrama de Atividades do Daemon - Transmissao . . . . . . . . . . . . . 134
8.14 Diagrama de casos de uso gerais do sistema embarcado. . . . . . . . . . . . 141
8.15 Diagrama de caso de uso “Aquisicao dos dados” . . . . . . . . . . . . . . . 142
8.16 Diagrama de caso de uso “Mudar frequencia” . . . . . . . . . . . . . . . . 144
8.17 Diagrama de caso de uso “Atualizar IP” . . . . . . . . . . . . . . . . . . . 145
8.18 Registros do log de recebimento de pacotes do daemon. . . . . . . . . . . . 147
9.1 Troca de pacotes entre EMR e servidor . . . . . . . . . . . . . . . . . . . . 152
9.2 Website atualizado com os novos valores dos sensores da EMR de ID igual
a 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
8
Lista de Tabelas
3.1 Requisitos e especificacoes tecnicas da EMR - Parte 1 . . . . . . . . . . . . 25
3.2 Requisitos e especificacoes tecnicas da EMR - Parte 2 . . . . . . . . . . . . 26
3.3 Requisitos e especificacoes tecnicas da comunicacao . . . . . . . . . . . . . 27
3.4 Comparacao entre sensores de temperatura . . . . . . . . . . . . . . . . . . 28
3.5 Comparacao entre sensores de umidade . . . . . . . . . . . . . . . . . . . . 29
3.6 Comparacao entre sensores de intensidade luminosa . . . . . . . . . . . . . 30
3.7 Comparacao entre sensores de CO . . . . . . . . . . . . . . . . . . . . . . . 31
3.8 Comparacao entre sensores VOC . . . . . . . . . . . . . . . . . . . . . . . 32
3.9 Comparacao entre modulos GPRS . . . . . . . . . . . . . . . . . . . . . . . 33
3.10 Comparacao entre modulos GPS . . . . . . . . . . . . . . . . . . . . . . . . 34
3.11 Caracterısticas fısicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.12 Consumo em diversos modos de operacao . . . . . . . . . . . . . . . . . . . 35
3.13 Kits de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.14 Requisitos e especificacoes tecnicas da EBC - Parte 1 . . . . . . . . . . . . 37
3.15 Requisitos e especificacoes tecnicas da EBC - Parte 2 . . . . . . . . . . . . 38
3.16 Requisitos e especificacoes tecnicas da EBS - Parte 1 . . . . . . . . . . . . 38
3.17 Requisitos e especificacoes tecnicas da EBS - Parte 2 . . . . . . . . . . . . 39
3.18 Sistema Operacional para EBC . . . . . . . . . . . . . . . . . . . . . . . . 40
3.19 Browser Compatıvel com o Website . . . . . . . . . . . . . . . . . . . . . . 41
3.20 Comparacao de Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . 41
3.21 Comparacao de APIs de Mapas . . . . . . . . . . . . . . . . . . . . . . . . 42
3.22 Comparacao de APIs para Graficos . . . . . . . . . . . . . . . . . . . . . . 43
3.23 Comparacao de bibliotecas C++ e Java . . . . . . . . . . . . . . . . . . . . 44
3.24 Comparacao de linguagens WEB . . . . . . . . . . . . . . . . . . . . . . . 45
3.25 Comparacao de servidores WEB . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1 Orcamento detalhado de componentes . . . . . . . . . . . . . . . . . . . . 50
5.2 Orcamento final real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.1 Tabela de sentencas NMEA-0183 suportadas pelo modulo GM862-GPS . . 65
7.1 Dicionario de dados da Tabela Administradores . . . . . . . . . . . . . . . 106
7.2 Dicionario de dados da Tabela EMR . . . . . . . . . . . . . . . . . . . . . 107
7.3 Dicionario de dados da Tabela Dados . . . . . . . . . . . . . . . . . . . . . 108
7.4 Dicionario de dados da Tabela Queue . . . . . . . . . . . . . . . . . . . . . 109
10
Lista de Siglas
R Requisitos
EB Estacao Base
ET Especificacoes Tecnicas
EBC Estacao Base Cliente
EBS Estacao Base Servidor
EMR Estacao de Monitoramento Remota
GSM Global System for Mobile Communication
GPRS General Packet Radio Services
11
Sumario
1 Introducao 15
1.1 Objetivos e metas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Premissas e Restricoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3 Visao Geral do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4 Trabalhos Semelhantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Fundamentacao Teorica 21
2.1 Estacoes de monitoramento remotas . . . . . . . . . . . . . . . . . . . . . . 21
2.2 Redes GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Analise Tecnologica 24
3.1 Estacao de Monitoramento Remota . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 Requisitos da EMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.2 Requisitos do sistema de comunicacao . . . . . . . . . . . . . . . . . 27
3.1.3 Opcoes Tecnologicas EMR . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 Estacao Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.1 Requisitos da EBC . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Requisitos EBS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.3 Opcoes Tecnologicas EBC . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.4 Opcoes Tecnologicas EBS . . . . . . . . . . . . . . . . . . . . . . . 41
4 Plano de Execucao 46
4.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2 Cronograma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Primeiro Entregavel (07/08) . . . . . . . . . . . . . . . . . . . . . . 46
4.2.2 Segundo Entregavel (21/08) . . . . . . . . . . . . . . . . . . . . . . 47
4.2.3 Terceiro Entregavel (04/09) . . . . . . . . . . . . . . . . . . . . . . 48
4.2.4 Quarto Entregavel (18/09) . . . . . . . . . . . . . . . . . . . . . . . 48
5 Orcamento Detalhado 50
12
6 Sistema Embarcado 52
6.1 Detalhes de funcionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.1 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.2 Sensor de temperatura . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.3 Sensor de luminosidade . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1.4 Sensor de umidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1.5 Sensores de gases poluentes . . . . . . . . . . . . . . . . . . . . . . 59
6.1.6 Modulo de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . 63
6.2 Acoplamento dos componentes da EMR . . . . . . . . . . . . . . . . . . . 68
6.2.1 Acoplamento ao microcontrolador . . . . . . . . . . . . . . . . . . . 68
6.2.2 Descricao da implementacao da interface com os sensores . . . . . . 68
6.2.3 Sensor de Umidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3 Diagramas eletricos para acoplamento dos sensores e do modulo GM862-GPS 78
6.4 Integracao dos componentes da EMR . . . . . . . . . . . . . . . . . . . . . 79
6.4.1 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4.2 Modulo de comunicacao GM862-GPS . . . . . . . . . . . . . . . . . 81
6.4.3 Placa de circuito impresso . . . . . . . . . . . . . . . . . . . . . . . 81
7 Estacao Base 82
7.1 Casos de Uso do website . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
7.1.1 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
7.1.2 Especificacao dos casos de uso . . . . . . . . . . . . . . . . . . . . . 84
7.1.3 Diagrama de Atividades Website . . . . . . . . . . . . . . . . . . . 97
7.2 Banco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.2.1 Diagrama entidade-relacionamento do banco de dados . . . . . . . . 105
7.2.2 Dicionario de informacoes: Tabela Administradores . . . . . . . . 105
7.2.3 Dicionario de informacoes: Tabela EMR . . . . . . . . . . . . . . . 106
7.2.4 Dicionario de informacoes: Tabela Dados . . . . . . . . . . . . . . 107
7.2.5 Dicionario de informacoes: Tabela Queue . . . . . . . . . . . . . . 109
7.3 Google Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.3.1 Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.4 Google Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
13
7.4.1 Dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.4.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.5 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.5.1 Instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.5.2 Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.6 Interface do usuario (Website) . . . . . . . . . . . . . . . . . . . . . . . . . 115
8 Sistema de Comunicacao 119
8.1 Protocolo de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.1.1 Diagrama de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.1.2 Diagrama de Sequencia . . . . . . . . . . . . . . . . . . . . . . . . . 122
8.2 Diagrama de casos de uso do daemon . . . . . . . . . . . . . . . . . . . . . 125
8.2.1 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.2.2 Especificacao dos casos de uso . . . . . . . . . . . . . . . . . . . . . 126
8.3 Diagrama de atividades do daemon . . . . . . . . . . . . . . . . . . . . . . 131
8.4 Programacao Daemon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.4.1 Sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.4.2 Conexao com o Banco de Dados . . . . . . . . . . . . . . . . . . . . 138
8.4.3 Verificacao de Integridade . . . . . . . . . . . . . . . . . . . . . . . 139
8.4.4 Resposta as requisicoes da EMR e do website . . . . . . . . . . . . 140
8.5 Diagrama de casos de uso da EMR . . . . . . . . . . . . . . . . . . . . . . 141
8.5.1 Atores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.5.2 Especificacao dos casos de uso . . . . . . . . . . . . . . . . . . . . . 142
8.6 Pacote de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8.6.1 Estacao remota . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8.6.2 Estacao base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9 Resultados e Conclusao 148
9.1 Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.1.1 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
9.1.2 Sistema de comunicacao . . . . . . . . . . . . . . . . . . . . . . . . 149
9.1.3 Concretizacao dos riscos previstos . . . . . . . . . . . . . . . . . . . 150
9.2 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
14
9.3 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
9.4 Consideracoes Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A Esquematicos - Parte 1: LPC1769 e modulo GM862 156
B Esquematicos - Parte 2: Sensores 157
C Prototipo da placa de circuito impresso 158
D Comandos e pacotes aceitos para o sistema de comunicacao 159
E Cronograma Detalhado - Microsoft Project 160
F Plano de resposta aos riscos 162
15
1 — Introducao
Este projeto foi desenvolvido para a disciplina de Oficina de Integracao 3 (IF66J-
S71), no curso de Engenharia de Computacao da Universidade Tecnologica Federal do
Parana, campus Curitiba.
O projeto escolhido foi o desenvolvimento de uma estacao de monitoramento
voltada a captacao de dados referente a alguns indicadores de poluicao do ar.
O projeto inclui um sistema embarcado, o sistema de comunicacao e o sistema
da estacao base. O sistema embarcado consiste em sensores de gases ligados a um mi-
crocontrolador. O sistema de comunicacao e composto por um modulo de comunicacao
GSM/GPRS, para se comunicar com a estacao base, e o mesmo modulo e utilizado para
localizacao GPS. A estacao base e a responsavel pela apresentacao dos dados recebidos
da sistema embarcado ao usuario/cliente por meio de um website.
1.1 Objetivos e metas
OBJETIVOS: A EMP tem por objetivo captar dados dos sensores, sendo estes de
temperatura, umidade, presenca de gases poluentes e luz, e tambem captar a localizacao
da estacao de monitoramento via tecnologia GPS, e envia-los via rede GPRS a estacao
base, que estara em outra localidade. Estes dados serao apresentados a estacao base em
um website, acessıvel via internet.
METAS: Desenvolver e finalizar o projeto no prazo maximo de dez semanas, projetando-
o de forma concisa e expansıvel para projetos futuros. O custo em equipamentos nao
devera ultrapassar o orcamento inicial apresentado neste documento.
1.2 Premissas e Restricoes
PREMISSAS:
1. O microcontrolador, a estacao de comunicacao e o sistema de localizacao ficarao
fixos e acoplados em uma estrutura que os protegerao da chuva.
16
2. Os sensores estarao conectados via cabo ao microcontrolador.
3. A estacao sera alimentada por uma bateria.
4. A estacao base devera estar situada em um local com acesso a internet para dispo-
nibilizar os dados recebidos da estacao de monitoramento ao cliente/usuario atraves
de um website.
5. A estacao de monitoramento devera estar situada em locais com cobertura GPRS
para transmissao dos dados a estacao base.
6. A equipe podera contar com o emprestimo de componentes para reduzir os custos
do projeto. Caso nao exista possibilidade de emprestimo de um ou mais componen-
tes, sera feito o possıvel para que os mesmos sejam comprados no paıs, para evitar
problemas com data de entrega, consequentemente, com o tempo para o desenvol-
vimento do projeto.
RESTRICOES:
1. O tempo para realizar o projeto e de apenas dez semanas, sendo um prazo nao
negociavel, exigindo uma maior atencao da equipe ao planejamento e cumprimento
das datas preestabelecidas.
2. A estacao de monitoramento nao sera movel, ou seja, nao tera movimentacao
autonoma ou controlada.
3. Apenas o perıodo de amostragem dos dados dos sensores a estacao base sera pro-
gramavel remotamente (da estacao base em direcao a estacao de monitoramento).
1.3 Visao Geral do Projeto
A Figura 1.1 mostra uma visao geral do sistema proposto, o qual e composto por
tres partes fısicas: Estacao Base Cliente (EBC), Estacao Base Servidor (EBS) e Estacao
de Monitoramento Remota (EMR).
A EMR e uma estacao microcontrolada composta por um conjunto sensores de
caracterısticas ambientais e um modulo GPS e de comunicacao GPRS. Ela e responsavel
17
por adquirir dados do ambiente e enviar, quando requisitado pela EBS, via GPRS estes
dados obtidos.
A EBS e um servidor que hospeda um website acessıvel para usuarios e adminis-
tradores. Neste e possıvel ver os dados obtidos de uma EMR, requisitar novas medicoes.
O website e acessıvel de qualquer estacao que possua acesso a internet, chamadas de EBC.
Neste documento sera feito um relatorio da implementacao de cada parte do
projeto, escolha de tecnologia, planejamento e resultados.
18
Fonte: Autoria propria
Figura 1.1: Visao geral do projeto
19
1.4 Trabalhos Semelhantes
Embedded system for Hazardous Gas detection and Alerting
O projeto “Embedded system for Hazardous Gas detection and Alerting”, com
artigo publicado no International Journal of Distributed and Parallel Systems (Ramya
and Palaniappan, 2012), teve como objetivo desenvolver um sistema de deteccao de gases
toxicos que pudesse ser utilizado em empresas e residencias. O sistema desenvolvido
detecta concentracoes de LPG e propano. Quando as concentracoes desses gases excedia
um nıvel estipulado, um alarme era acionado e uma mensagem de texto via tecnologia
GSM era enviada para o pessoal autorizado. O prototipo pode ser obsevado na Figura
1.2.
Fonte: Ramya, Palaniappan
Figura 1.2: Prototipo do Sistema
As semelhancas com o projeto proposto neste documento sao: deteccao de gases
toxicos utilizando sensores da serie MQ e o uso da tecnologia GSM, mesmo que para
outros objetivos. As diferencas estao nos gases detectados e no uso da tecnologia GSM
para enviar mensagens de texto, que nao sera utilizada na EMP, mas sim a tecnologia
GPRS para enviar maior quantidade de dados a EBS.
A Mobile GPRS-Sensors Array for Air Pollution Monitoring
O projeto desenvolvido (Al-Ali et al., 2010) consistia em um sistema composto por
uma estacao remota detectora de poluentes (CO, NO2, SO2), um servidor para armazenar
20
e publicar os dados obtidos e varias estacoes clientes podendo requisitar esses dados. O
diagrama de funcionamento pode ser observado na Figura 1.3.
Fonte: Al-Ali, Zualkernan, Aloul
Figura 1.3: Diagrama de Funcionamento
A estacao remota (Mobile-DAQ) consistia em um grupo de sensores, um modulo
GPRS, um modulo GPS e um microcontrolador. Os sensores faziam a deteccao das
concetracoes e da localizacao (GPS), enviavam ao microcontrolador que, por sua vez,
fazia o envio de dados para a estacao base-servidor (Pollution-Server) atraves do modulo
GPRS.
Este artigo mostra um trabalho com uma estrutura semelhante ao proposto
(estacao remota, servidor e cliente), monitora poluentes e utiliza a tecnologia GPRS.
No entanto, os gases detectados, sensores e modulos sao distintos.
21
2 — Fundamentacao Teorica
2.1 Estacoes de monitoramento remotas
Hoje em dia muitos projetos podem ser feitos sem mesmo sair de casa, alguns des-
ses trabalhos incluem o monitoramento de eventos em locais remotos, as vezes localizados
em areas de difıcil acesso e/ou em outros paıses.
A ideia basica de uma estacao de monitoramento remota e possibilitar ao operador
de um sistema a visualizacao dos estados atuais das variaveis de interesse, estejam elas
relacionadas a meteorologia ou seguranca.
Porem, para todo sistema remoto deve existir um sistema base ao qual se co-
munica e, para esta comunicacao existir, e necessario adotar alguma tecnologia de comu-
nicacao cabeada (ethernet, USB, entre outras) ou wireless (WiFi, GPRS, entre outras).
A tecnologia adotada para este projeto sera apresentada na secao seguinte (2.2)
com alguns detalhes de seu funcionamento.
2.2 Redes GPRS
Logo que a segunda geracao (2G) de comunicacao de dispositivos moveis surgiu,
algumas operacoes como mensagem de voz, informacoes de notıcias, entre outras coisas,
que ate entao eram possıveis apenas a partir de computadores conectados a internet, pas-
saram a poder ser realizadas diretamente de um aparelho celular atraves das redes GSM,
porem, com uma velocidade e quantidade de dados muito limitadas. Com o aumento da
utilizacao deste tipo de informacao, tanto em computadores quanto em celulares, surgiu
a necessidade de evoluir a troca informacoes entre o mundo e a rede de celulares GSM.
As redes GSM trabalham com comutacao de circuito, ou seja, a conexao estabe-
lecida entre as extremidades (transmissor e receptor do sinal) tera garantia da taxa de
transmissao e a informacao de voz chegara na mesma ordem desde o transmissor ate o
receptor (Teleco, 2013), porem, a internet foi totalmente estruturada sobre a comutacao
de pacotes e sobre protocolos como TCP, UDP e IP, o que impossibilita as redes GSM ter
acesso a qualquer tipo de dado dentro da internet.
22
A comutacao de pacotes difere da comutacao de circuitos grandemente, ja que a
primeira nao da nenhuma garantia de taxa de transmissao (ocorre a alocacao dinamica
de banda) e da ordem em que os dados serao recebidos pelos dispositivos de destino. A
grande vantagem disso e que nao ha um tempo de espera para se estabelecer uma conexao
e a conexao nao se torna invalida caso um de seus nos venham a cair (se desligar da rede),
como acontece com a comutacao de circuitos.
Para solucionar essa diferenca de comutacao foi criada a tecnologia GPRS (co-
nhecida como uma evolucao da segunda geracao de comunicacao movel, a 2.5G), a qual
trabalha de forma complementar a rede GSM, possibilitando o acesso dos dispositivos que
operam sobre a rede GSM de acessar a internet, necessitando apenas que estes dispositivos
tenham suporte a redes GPRS (Santos, 2013).
A arquitetura GSM/GPRS pode ser representada pela figura 2.1 e o fluxo dos
pacotes destinados a rede GPRS pode ser explicado pelos seguintes passos (Rysavy, 2004):
1. Assim que o dispositivo movel transmite uma quantidade de dados ocorre a se-
paracao dos dados entre os que pertencem a rede GPRS e aqueles que pertencem a
rede GSM, sendo isto feito por um controlador (Base Station Controller, BSC) logo
apos aos dispositivos, sendo que os dados que se destinavam a rede GSM irao tra-
balhar sobre a comutacao de circuito e os demais dados (destinados a rede GPRS)
sobre a comutacao de pacotes;
2. Os dados da rede GPRS serao adquiridos pelo no de servico para rede GPRS (Service
GPRS Support Node, SGSN), no qual ocorrera a verificacao dos servicos disponıveis
para o cliente que transmitiu os dados, dependendo da conta que ele possuı e, caso o
servico requisitado pelo cliente estiver disponıvel, o servico requisitado e armazenado
no registrado local (Home Location Register, HLR);
3. Assim que todos os dados do cliente forem checados e o servico que esta sendo
solicitado se tornar disponıvel, o proximo passo e transferir o pacote a uma rede
externa (i.e. internet), passo esse efetuado pelo no gateway de GPRS (Gateway
GPRS Support Node, GGSN).
O bloco Mobile Switching Center (MSC) na figura 2.1 entre o BSC e o HLR faz
o mesmo papel que o SGSN faz para os pacotes da rede GPRS, porem, para os dados da
rede GSM.
23
Fonte: (Rysavy, 2004)
Figura 2.1: Arquitetura da rede GSM/GPRS.
Com surgimento desta nova tecnologia muitas aplicacoes puderam ser desenvol-
vidas para o mundo da comunicacao movel, como por exemplo e-commerce, envio e rece-
bimento de e-mails, web browsers, entre outras centenas de aplicativos ja existentes para
computadores pessoais, que puderam ser desenvolvidos e utilizados em aparelhos celulares
e outros dispositivos que utilizavam a tecnologia GPRS para acessar a internet.
24
3 — Analise Tecnologica
Neste documento serao apresentadas as opcoes tecnologicas (Secoes 3.1.3, 3.2.3
e 3.2.4) passıveis de escolha para o desenvolvimento do projeto. Porem, as escolhas
definitivas foram feitas visando o cumprimento dos requisitos do projeto (Secoes 3.1.1,
3.1.2, 3.2.1 e 3.2.2) e a relacao custo-benefıcio dos equipamentos.
A organizacao deste documento foi feita dividindo-se o projeto em duas grandes
areas: a Estacao de Monitoramento Remota (EMR) e a Estacao Base (EB). A EB se
subdivide em outras duas subareas, sendo estas a Estacao Base Cliente (EBC) e a Estacao
Base Servidor (EBS).
A analise feita sobre a EMR contempla a analise dos sensores, do modulo de
comunicacao e do microcontrolador. A EBC e simplesmente o lado do cliente, ou seja, a
maquina utilizada pelo cliente para acessar a plataforma web que contem as informacoes
presentes na EBS, a qual tera funcao de captar os dados da EMR, armazenar estes em um
banco de dados e hospedar o site que o cliente acessara, funcionando como web server.
3.1 Estacao de Monitoramento Remota
A Estacao de Monitoramento Remota (EMR) e constituıda por um microcontro-
lador, um modulo de comunicacao e sensores de poluentes.
O objetivo dessa estacao e captar a presenca de poluentes no ar, registrar o local
fısico da aquisicao dos dados, enviar os dados brutos (sem tratamento algum) e receber
comandos de configuracao da estacao base.
3.1.1 Requisitos da EMR
Para que fosse possıvel a EMR realizar sua funcao de forma correta foram defini-
dos os Requisitos (R) e Especificacoes Tecnicas (ET) desta, os quais estao apresentados
nas Tabelas 3.1 e 3.2.
25
R1. A EMR devera ter o menor consumo possıvel de energia.ET1. Por ser uma estacao remota, em um local muitas vezes longe do alcance de umoperador, e necessario que esta estacao consuma o mınimo possıvel para obter melhorautonomia possıvel.
R2. A EMR devera conter um microcontrolador com suporte ao modo “standby”deoperacao.ET2. Como havera um intervalo entre uma captacao e outra dos dados dos sensores,e necessario que o microcontrolador fique em modo “stand by”neste intervalo, minimi-zando o consumo.
R3. A EMR devera ter uma autonomia de 12 horas, no mınimo.ET3. As EMRs deverao funcionar em locais a uma longa distancia da EBS e, por estemotivo, devem funcionar sem necessidade de frequente supervisao humana por pelomenos 12h. Para isso sera necessario que a bateria utilizada forneca essa autonomia defuncionamento.
R4. A EMR devera se comunicar com a estacao base por meio de uma tecnologia semfio.ET4. A comunicacao entre a EMR e a EBS sera feita a distancias maiores que 1km,desta forma ficando totalmente inviavel uma comunicacao cabeada.
R5. A EMR devera ter suporte a localizacao por satelite.ET5. A EMR nao sera fixa a somente um ponto, podendo ser carregada enquantorealiza sua funcao, com isso sua localizacao varia com o tempo. Como a proposta doprojeto e armazenar informacoes de um determinado local, e necessario uma tecnologiade localizacao automatica para definir de qual local sao tais informacoes, nao exigindointerferencia humana para esta interacao.
R6. A EMR devera conter um microcontrolador com um numero suficiente de inter-faces para captar os dados dos sensores.ET6. Na escolha do microcontrolador deve-se levar em conta o numero de interfacespresentes neste para ser possıvel se comunicar com todos os sensores desejados.
R7. A EMR devera conter um microcontrolador com suporte a todas as interfaces decomunicacao necessarias para os sensores.ET7. Cada sensor ou modulo possui um tipo de protocolo de comunicacao, sendoassim necessario escolher um microcontrolador com suporte a todas estas interfaces,evitando a implementacao ou construcao de dispositivos, externos ao microcontrolador,que facam este papel.
Tabela 3.1: Requisitos e especificacoes tecnicas da EMR - Parte 1
26
R8. A EMR devera conter todos os sensores conectados ao microcontrolador via cabo.ET8.Devido as limitacoes de bateria e autonomia de funcionamento, os sensores de-verao se comunicar com o microcontrolador via cabo, deixando a comunicacao sem fio,a qual e responsavel por grande consumo de energia, apenas para o envio e recebimentode dados da EBS.
R9. A EMR devera conter um microcontrolador com um numero suficiente de pinospara conectar todos os sensores.ET9. O microcontrolador utilizado na EMR devera ter pinos de entrada e saıda sufici-entes para permitir o acoplamento de todos os sensores e modulos utilizados de acordocom seus requisitos de funcionamento dependendo, assim, da escolha dos mesmos.
R10. A EMR devera conter um microcontrolador com frequencia mınima de operacaolimitada pela frequencia de operacao mınima necessaria dentre os sensores e modulosutilizados.ET10.O microcontrolador utilizado na EMR devera possuir uma frequencia mınima defuncionamento que permita o acoplamento de todos os sensores e modulos utilizadosde acordo com seus requisitos de funcionamento dependendo, assim, da escolha dosmesmos. Limite mınimo de 9600bps (para a comunicacao UART com modulo GPRS).
R11. A EMR nao devera conter nenhum tipo de navegacao autonoma.ET11.As EMRs serao fixas no sentido de nao possuırem capacidade de movimentacaoautonoma, mas poderao ser movidas e transportadas atraves de acoes humanas.
R12. A EMR devera estar sob a protecao de alguma estrutura que a proteja de fatoresmeteorologicos.ET12. Como as EMRs serao implantadas em ambientes abertos, estarao expostas aacoes ambientais com a chuva, umidade e luz solar. A estrutura mecanica da EMRdeve proteger seus componentes eletronicos de condicoes que possam afetar seu funcio-namento, sendo impermeavel e impedindo a incidencia direta de luz solar nos sensoressensıveis a ela.
R13. A EMR devera receber e executar configuracoes vindas da EBS quanto afrequencia de captacao dos dados dos sensores.ET13. A EMR recebera da EBS em algum instante a informacao de quanto deve sero perıodo de captacao dos dados dos sensores, sendo necessario ser configurado estainformacao em algum Timer ou Real Time Clock.
R14. O microcontrolador da EMR devera sair do estado ocioso sempre que atingir otempo de captacao dos dados dos sensores.ET14. O microcontrolador recebera comandos da EBS indicando o perıodo com quedevera captar os dados dos sensores e o microcontrolador devera sair do estado ociosoa partir dele mesmo (interrupcao do Real Time Clock, por exemplo).
Tabela 3.2: Requisitos e especificacoes tecnicas da EMR - Parte 2
27
3.1.2 Requisitos do sistema de comunicacao
R1. O sistema de comunicacao devera suportar distancias maiores que 1000m.ET1. Para esta distancia estao disponıveis as tecnologias de RF e GPRS. O RF temum alcance de 800-1000 metros e o GPRS tem um alcance maior, mas e dependenteda disponibilidade sinal da operadora na regiao.
R2. O sistema de comunicacao devera ser bidirecional entre as EMR e a EBS.ET2. Ambos os dispositivos devem receber ou enviar dados, desta forma e necessarioque o sistema de conexao possibilite tal feito. O sistema RF e o GPRS sao full-duplexpossibilitando o envio e recebimento simultaneos.
R3. O modulo da comunicacao devera verificar se uma das extremidades da comu-nicacao (EMR ou EBS) nao esta respondendo.ET3. Este requisito sera sanado com a construcao do protocolo de comunicacao e auniao de um timeout ao mesmo. O protocolo sera desenvolvido pela equipe durante odecorrer do projeto.
R4. O sistema de comunicacao devera garantir a integridade dos dados.ET4. Para sanar este requisito pode ser aplicado um checksum aos dados enviados aodesenvolver o protocolo de comunicacao e dos dados. Este checksum sera verificado pelaunidade que recebeu o pacote e aprovado ou nao, se nao aprovado o sistema recipientedevera pedir que o pacote seja reenviado.
R5. O sistema de comunicacao devera ter baixo consumo de energia, principalmentena extremidade da EMR.ET5. As opcoes que satisfazem o alcance tem o seguinte consumo: 1.Modulo GPRS:Telit GM862-GPS: tensao recomendada de 3.8v, trabalha de 3.22V a 4.5 VDC, Des-ligado <26uA, Ocioso 2.6mA, modo dedicado: 200mA no maximo, GPRS classe 10:370mA 2.Modulo RF: KYL 500S: tensao de 3.3v - 6v, padrao de 5V, corretes de:<40mA para transmissao, <20mA para recepcao, <20uA quando ocioso.
R6. O sistema de comunicacao devera garantir a taxa de 1kb/s para a distanciaescolhidaET6. Taxa de transmissao para a distancia escolhida: 1. GPRS classe 10: ate 236.8kbits/s de download e 59.2 kbits/s de upload, dependendo do desempenho e da rededa operadora 2. RF: a 1000m: 1200bps.
Tabela 3.3: Requisitos e especificacoes tecnicas da comunicacao
28
3.1.3 Opcoes Tecnologicas EMR
Apos a definicao dos requisitos, foram encontradas opcoes tecnologicas para cada
componente utilizado na EMR. Os detalhes e comparacoes sao descritos a seguir.
Sensores
Nesta secao sao descritas as opcoes tecnologicas para os sensores de gases, umi-
dade relativa e temperatura.
Sensores de temperatura
Foram analisados alguns sensores disponıveis no mercado e, levando em conta
a disponibilidade, tempo de entrega, faixa de preco e precisao, a equipe chegou a duas
opcoes. Os sensores sao comparados na Tabela 3.4.
Sensores de TemperaturaDHT11 DS18B20
Alimentacao 3V - 5.5V 3V - 5.5VCorrente 0.5mA - 2.5mA 1.5mA
Resolucao ±1C 0.0625 C - 0.5 C8 Bits 12 bits - 9 Bits
Precisao ±1C - ±2C ±0.5C - ±2C(configuravel)
Faixa de medicao (range) 0C - 50C -55C - 125CTemperatura de operacao 0C - 50C -55C - 125C
Saıda/ Digital DigitalComunicacao (1-Wire) (1-Wire)
Preco R$ 25,00 R$ 15,00
Tabela 3.4: Comparacao entre sensores de temperatura
Apos essa comparacao detalhada, a escolha pode ser feita baseada na grande dife-
renca de precisao entre os sensores. A medicao da temperatura e de extrema importancia
para este projeto pois as medicoes de alguns gases poluentes dependem deste dado para
serem devidamente calculados. Como o sensor DS18B20 (Figura 3.1 ) apresenta uma re-
solucao e precisao maior, um custo menor e tambem pode ser operado a maiores variacoes
de temperatura, a equipe optou por utiliza-lo.
29
Fonte: Robot-italy
Figura 3.1: Sensor de temperatura DS18B20
Sensores de umidade relativa
A mesma analise foi feita para os sensores de umidade relativa. A Tabela 3.5
compara os dois modelos escolhidos.
Sensores de umidadeDHT11 HS1101
Alimentacao 3V - 5.5V ate 10VPrecisao ±4% ±2%
Faixa de medicao (range) 20 - 90%RH 1 - 99%RHTemperatura de operacao 0C - 50C -40C - 100C
Tempo de resposta 6s - 30s 5 sSaıda/ Digital Analogica
Comunicacao (1-Wire)Preco R$ 25,00 R$ 13,50
Tabela 3.5: Comparacao entre sensores de umidade
Fonte: Microeletronica
Figura 3.2: Sensor de umidade HS1101
A precisao dos dados adquiridos foi o fator principal da escolha neste caso. A
medicao da umidade e de extrema importancia para o projeto pois as medicoes dos gases
30
poluentes dependem desse dado para o seu calculo. O sensor HS1101 (Figura 3.2 )oferece
alem de maior precisao, uma maior faixa de medicao e um custo menor, explicando assim
a sua escolha.
O sensor DHT11 pode exercer tanto a funcao de sensor de temperatura quanto
de umidade relativa, mas devido aos fatores ja citados este nao foi escolhido, ate mesmo
porque a diferenca do preco entre este sensor e a utilizacao dos outros dois separadamente
e muito pequena.
Sensor de intensidade luminosa
Para este fim poderia ser utilizado o sensor resistivo bastante conhecido, o LDR,
porem, este necessitaria de calibracao e a conversao da unidade de saıda, ‘tensao’ para
‘lux’.
Alguns integrantes da equipe possuı certa experiencia nessa conversao, porem,
como o foco deste trabalho e totalmente outro foram escolhidos sensores digitais em que
a saıda ja e dada em Lux.
Na Tabela 3.6 esta presente a comparacao entre duas possıveis opcoes tecnologicas.
Sensores de intensidade luminosaBH1750 TSL2561
Alimentacao 2V - 3.6V 2.7V - 3.6VI2C Clock 400kHz 735kHzResolucao 16 bits 16 bits
Temperatura de operacao -40C - 85C -30C - 70CConsumo Max. 190µA 600µA
Saıda/ Digital DigitalComunicacao I2C I2C
Preco R$ 30,00 R$ 18,00
Tabela 3.6: Comparacao entre sensores de intensidade luminosa
Dois fatores foram decisivos para a escolha deste componente, primeiramente o
consumo apresenta uma grande diferenca entre os dois, sendo o BH1750 melhor. Porem, o
mais determinante foi o preco do frete para a compra destes componentes, pois ambos sao
importados. Por mais que o TSL2561 seja mais barato o frete necessario para importa-lo
e muito maior que o BH1750, ja que este ultimo possuı frete gratuito.
Sendo assim, a escolha foi utilizar o sensor BH1750 como sensor de intensidade
de luz.
31
Sensores de gases
Para deteccao de gases poluentes foi selecionada a serie de sensores MQ (Figura
3.3) devido ao seu baixo custo, disponibilidade no mercado nacional e internacional e a
falta de concorrentes que encaixassem no orcamento permitido do projeto.
Fonte: Autoria Propria
Figura 3.3: Serie de sensores MQ
Sensores de CO
A concentracao de CO (monoxido de carbono) no ar e um dado de extrema
importancia na analise de poluentes, pois e um dos gases mais toxicos e de emissao mais
comum. Os sensores escolhidos sao avaliados na Tabela 3.7.
Sensores de COMQ-7 MQ-9
Alimentacao 5V 5VComponentes CO CO e gases
detectados combustıveisTemperatura -20C - 50C -20C - 50Cde operacao
Umidade < 95% < 95%de operacao
Faixa de 20ppm-2000ppm 20ppm-2000ppmdeteccao CO
Faixa deteccao - 500ppm-10000ppmmetano e LPG
Saıda Analogica AnalogicaPreco R$24,50 R$ 37,00
Tabela 3.7: Comparacao entre sensores de CO
32
Por apresentarem caracterısticas semelhantes tanto em condicoes de operacao,
como em faixa de deteccao, os sensores foram escolhidos com base em seu preco, sendo o
modelo MQ-7 considerado o mais adequado.
Sensores VOC
Outro dado importante a ser analisado pela EMR e a concentracao de compostos
organicos volateis, conhecidos como VOCs. Os sensores encontrados sao descritos na
Tabela 3.8.
Sensores de VOCMQ-135 MQ-138
Alimentacao 5V 5VComponentes Amonia, n-Hexano, CO,
detectados benzeno, Benzeno, NH3,hidrogenio, alcool,fumaca
Temperatura -20C - 50C -20C- 50Cde operacao
Umidade < 95% < 95%de operacao
Faixa de deteccaoBenzeno 10-10000ppm 10-1000ppm
alcool - 10-1000ppmamonia 10-10000ppm -
hidrogenio 10-10000ppm -Saıda Analogica AnalogicaPreco R$24,50 R$ 37,00
Tabela 3.8: Comparacao entre sensores VOC
Considerando que os sensores tambem sao semelhantes nesse caso, a equipe optou
pelo sensor MQ-135 devido a sua faixa de deteccao de benzeno ser maior e ao fato de
detectar amonia, outro componente importante na analise de poluentes.
Modulos
Modulo de comunicacao GPRS
A comunicacao e essencial neste projeto, e se trata da forma como a estacao
base ira interagir com a estacao de monitoramento remota. Foi pre-definido que para
o projeto ser relevante, seria preciso certa flexibilidade da EMR em relacao a distancia,
33
para o mesmo se tornar uma opcao viavel para um monitoramento em qualquer, ou na
maioria, dos locais desejados. Pensando nisso, e dentro do teto financeiro definido a este
projeto, a equipe escolheu a princıpio o metodo de comunicacao GPRS (General Packet
Radio Service) , por este ter uma maior area de cobertura, sendo o mais adequado para
a proposta da Estacao de Monitoramento de Poluentes. Foram analisadas duas opcoes
de modulos GPRS, o Telit GM862-GPS (integrado GPRS e GPS no mesmo modulo) e o
Telit GL865 (apenas modulo GPRS). A tabela 3.9 demonstra as informacoes de ambos
modulos.
Modulo GPRSGM862 GL865
Alimentacao 3.8V 3.8VFrequencia 850/900 MHz, 850/900 MHz
de operacao 1800/1900 MHz 1800/1900 MHzConsumo (GSM) Power off (uA) < 26 < 5
Idle (mA) 2.6 1.5Dedicated(mA) 200 230
GPRS (mA) 370 360Sensibilidade (dBm) 107 108
Dimensoes (mm) 43.9 × 43.9 × 6.9 24.4 × 24.4 × 2.7Peso (g) 20 2.8
Preco R$203,00 R$ 95,00
Tabela 3.9: Comparacao entre modulos GPRS
Apesar do modulo GL865 levar uma pequena vantagem em relacao ao GM862
em relacao a consumo e sensibilidade, e tambem o mesmo se mostrar com tamanho e
peso menores (devido a ser apenas modulo GPRS e nao conter GPS como o GM862), o
escolhido para o projeto foi o GM862, devido ao custo: o preco do modulos GPRS e GPS
(Tabela 3.10), quando utilizados separadamente, ultrapassa significantemente o preco do
modulo GM862, justificando sua escolha.
Modulo de localizacao GPS
O modulo GPS (Global Positioning System) tera como sua principal funcao forne-
cer a posicao de onde a EMR estara captando os dados. Foram analisados pela equipe dois
modulos GPS, o ja citado anteriormente Telit GM862-GPS e o D2523T GPS Receiver. A
tabela 3.10 mostra as informacoes relevantes de ambos.
34
Modulo GPSGM862 D2523T
Alimentacao (V) 3.8 3.3Sensibilidade (dBm) -159 -160
Precisao (m) < 2.5 < 2.5Inicializacao (s) Hot Start 3 < 1
Warm Start 35 35Cold Start 200 230
Suporte de canais GPS 20 50Consumo (mA) 55 43
Dimensoes (mm) 43.9 × 43.9 × 6.9 25 × 22.9 × 3Peso (g) 20 4
Preco R$203,00 R$ 180,00
Tabela 3.10: Comparacao entre modulos GPS
Como se pode ver, o modulo D2523T nao possui tantas vantagens em relacao ao
GM862, mesmo tendo mais opcao de canais e consumo menor, pelas razoes citadas ante-
riormente, para o grupo sera mais pratico utilizar o modulo GM862 por ja ter integrado
em si a comunicacao GPRS, que tambem sera utilizado neste projeto. Nao obstante, a
diferenca entre os modulos sao pequenas, podem ser relevadas em detrimento da vanta-
gem que se obtera utilizando apenas um modulo para dois requisitos do projeto e tambem
pelo preco reduzido quando analisado os modulos separados. Portanto, a escolha para o
sistema de comunicacao foi a do modulo Telit GM862-GPS.
Microcontroladores
A escolha do microcontrolador sera baseada nos requisitos apresentados anterior-
mente na Secao 3.1.1 e, em caso de mais de uma possıvel escolha, sera escolhido a opcao
com menor custo.
Primeiramente serao apresentados as caracterısticas fısicas dos microcontrolado-
res que estao como opcao (Tabela 3.11), depois o consumo em cada modo de operacao
possıvel dos microcontroladores (Tabela 3.12) e, por fim, sera apresentado as opcoes de
plataformas de desenvolvimento que contenham um dos microcontroladores tidos como
opcao (Tabela 3.13).
Uma das partes mais importantes das caracterısticas fısicas de cada um dos micro-
controladores, para este projeto, e a quantidade de interfaces de comunicacao suportadas,
pois cada sensor e modulo utilizara de uma ou mais destas interfaces.
35
Outro detalhe importante e quantidade de GPIOs, pois somente o modulo de
comunicacao GPRS utilizara mais de 20 destes.
MicrocontroladoresLPC1769 ATMega328P PIC24FJ256GB106
GeralArquitetura ARM Cortex-M3 AVR PICBarramento 32 bits 8 bits 16 bitsFrequencia de operacao ate 120MHz ate 20MHz ate 32MHz
MemoriaFlash 512kB 32kB 256kBSRAM 64kB 2kB 16kBEEPROM - 1024B -
InterfacesUART 4 1 4SPI 1 2 3I2C 3 1 3Canais ADC/DAC 8 8 16Saıda PWM 6 6 9
OutrosTimers 4 3 5Real Time Clock Sim Sim SimGPIOs 70 23 52
Tabela 3.11: Caracterısticas fısicas
O consumo e um fator muito importante para a escolha do microcontrolador
tambem, principalmente pelo fato da quantidade de horas de autonomia, especificado nos
requisitos.
LPC1769 ATMega328P PIC24FJ256GB106(Vcc = 3.3V , 12MHz) (Vcc = 5V , 12MHz) (Vcc = 3.3V , 8MHz)
Modo Tıpico Modo Tıpico Modo TıpicoActive 7mA Active 7.5mA Active 18.2mASleep 2mA Idle 1.8mA Idle 4.4mA
Deep sleep 250µA Power-save 900nA Power-down 10µAPower-down 31µA Power-down 100nA - -
Tabela 3.12: Consumo em diversos modos de operacao
Para finalizar os fatores determinantes para escolha do microcontrolador, serao
apresentadas as plataformas de desenvolvimento para cada um dos processadores citados
nesta secao. A utilizacao de uma plataforma e importante pois o tempo disposto para
o desenvolvimento do projeto requer alta produtividade e estes kits de desenvolvimento
ajudam a economizar certo tempo que seria gasto em trabalho manual.
36
LPCXpresso Arduino Duemilanove MPLAB(LPC1769) (ATMega328P) (PIC24FJ256GB106)
Dimensao 35×140mm 68×55mm Nao informadoProgramacao USB ou JTAG USB (c/ bootloader) JTAGDebug Sim Nao SimIDE Propria Sim Sim SimPreco R$54,00 R$69,00 R$135,00
Tabela 3.13: Kits de desenvolvimento
Balanceando os fatores de numero de interfaces, quantidade de GPIOs, consumo
em modo Active e Idle ou Sleep e os precos dos kits de desenvolvimento, a equipe op-
tou pelo microcontrolador LPC1769, sendo assim, o kit utilizado sera o LPCXpresso
(Figura 3.4).
Fonte: Embedded Artists.
Figura 3.4: LPCXpresso (LPC1769)
Alimentacao
A EMR podera estar localizada em locais remotos ou ate mesmo fixa em um
carro em movimento, em ambas situacoes a estacao estara impossibilitada de se conectar
a rede eletrica por meio de cabos. Devido a este motivo a equipe optou por utilizar a
alimentacao atraves de baterias. Com isso, foi definido como requisito do projeto uma
autonomia mınima de 12 horas e para se chegar a esta quantia de tempo a bateria escolhida
foi a de polımero de lıtio (Li-Po) de 2200mAh a 11.1V .
Com os perıodos de Idle ou Sleep predominantes sobre o perıodo de Active, esta
autonomia podera ser atingida desde que o requisito de tempo mınimo de atualizacao dos
dados na EBS (Secao 3.2.2, requisito 2) seja cumprida.
37
3.2 Estacao Base
Para a definicao das opcoes tecnologicas da estacao base optou-se pela divisao em
dois subsistemas: Estacao Base Servidor (EBS) e Estacao Base Cliente (EBC). A EBC
sera a responsavel por mostrar ao usuario final os dados presentes na EBS que foram
captados pela EMR. Atraves da interface do cliente sera possıvel ao usuario especial
(administrador) mudar algumas opcoes no EBS como, por exemplo, a frequencia em que
os dados dos sensores na EMR sao captados. A EBS sera a responsavel por comunicar-se
com a EMR atraves do protocolo de comunicacao e fornecer os dados numa interface
para o cliente (website). Para ambos os sistemas, EBC e EBS, foi definido os seguintes
requisitos:
3.2.1 Requisitos da EBC
R1. O cliente devera possuir acesso a internet independente da tecnologia utilizada.ET1. O cliente podera acessar as informacoes apenas atraves da internet, ja que estasestarao em uma plataforma web.
R2. O cliente devera ter uma maquina com sistema operacional instalado.ET2. O cliente deve utilizar uma maquina com algum sistema operacional instaladopois as informacoes que serao apresentadas ao cliente utilizam ferramentas do sistemaoperacional, como gerenciador de tarefas, gerenciamento de pacotes da rede, entreoutras.
R3. O cliente devera utilizar um sistema operacional com suporte a acesso a internet.ET3. O sistema operacional escolhido pelo cliente deve ter suporte a conexao a internetpelo fato das informacoes estarem em plataforma web e nem todos sistemas operacionaisdao este suporte. O recomendado e utilizar sistemas operacionais de desktops ouservidores, como por exemplo: Windows, Linux, MacOS, FreeBSD, OpenBSD, entreoutros.
Tabela 3.14: Requisitos e especificacoes tecnicas da EBC - Parte 1
38
R4. O cliente devera utilizar um sistema operacional com suporte a um browser.ET4. As informacoes apresentadas ao cliente estarao presentes em uma plataformaweb (site), o qual necessita de algumas ferramentas particulares de browsers, comosuporte a algumas linguagens de programacao (Javascript, PHP, HTML e CSS).
R5. O cliente devera utilizar um browser atualizado e compatıvel com as tecnologiasusadas no site.ET5. Algumas informacoes que serao apresentadas no site utilizam tecnologias es-pecıficas, como por exemplo, Google Maps API, a qual requer a linguagem de pro-gramacao JavaScript, sendo assim, o browser deve conter suporte a esta tecnologia.Para facilitar a utilizacao e minimizar os erros de visualizacao das informacoes e re-comendado utilizar a ultima versao dos browsers: Internet Explorer (para Windows),Firefox (para Windows, Linux, MacOS e *BSD), Safari (para MacOS e Windows) eGoogle Chrome (para Windows, Linux, MacOS).
Tabela 3.15: Requisitos e especificacoes tecnicas da EBC - Parte 2
3.2.2 Requisitos EBS
R1. A EBS devera receber requisicoes da EBC.ET1. A EBS devera receber e atender a pedidos GET e POST enviados pela EBC,para isso devera ter suporte ao protocolo HTTP, tendo instalada alguma aplicacao webserver como Apache, IIS, nginx, GWS.
R2. A EBS devera receber dados coletados das EMRs.ET2. A EBS devera receber os dados das EMRs de acordo com a frequencia definidapelo administrador, com um limite mınimo de cinco minutos e um limite maximo deum dia (24 horas).
R3. A EBS devera armazenar os dados recebidos das EMRs.ET3. A EBS devera armazenar os dados recebidos das EMRs, permitindo ate 50000entradas de dados. Para isso EBS devera ter instalado algum software gerenciador debanco de dados como: PostgreSQL, MySQL, SQL Server, entre outros.
R4. A EBS devera tratar os dados recebidos das EMRs.ET4. A EBS devera decodificar as informacoes recebidas e armazena-las no Banco deDados. Devera, tambem, permitir a analise desses dados atraves de graficos e mapasdevendo, portanto, ter instaladas bibliotecas que permitam tal visualizacao via webcomo Google Maps e Bing Maps (para mapas) e JFreeChart, JpGraph, Scipy e GoogleCharts (para graficos).
Tabela 3.16: Requisitos e especificacoes tecnicas da EBS - Parte 1
39
R5. A EBS devera permanecer online para que o cliente tenha acesso.ET5. A EBS devera possuir uma conexao estavel a internet e permanecer ligada comgarantia de funcionamento ao menos durante o horario comercial (das 8h as 18h) paraque os usuarios possam acessar as informacoes.
R6. A EBS devera disponibilizar as informacoes na internet para a EBC, atraves deum website, comportando-se com um web server.ET6. A EBS devera permitir interface web, para isso deverao estar instaladas fer-ramentas para programacao e desenvolvimento Web como: PHP, ASP, Python, Perl,Java e suas repectivas IDEs.
R7. A EBS devera possuir sistema operacional que permita desenvolvimento de variaslinguagens e instalacao de uma aplicacao web server.ET7. A EBS devera ter instalado um sistema operacional com suporte a conexao ainternet, desenvolvimento em varias linguagens e permitir instalacao de web servers.Exemplos: Windows, Linux, MacOS, FreeBSD, OpenBSD, entre outros.
R8. A EBS devera suportar o protocolo de comunicacao preestabelecido para se co-municar com as EMRs.ET8. A transmissao das informacoes dos sensores entre a EBS e as EMRs seraofeitas atraves de pacotes da internet, mas sera necessario um protocolo que defina aorganizacao do conteudo desses pacotes, a fim de se diferenciar o dado de cada sensordas EMRs e organizar estes no banco de dados.
Tabela 3.17: Requisitos e especificacoes tecnicas da EBS - Parte 2
3.2.3 Opcoes Tecnologicas EBC
Para EBC sera necessario apenas um computador com acesso a internet e com
um browser compatıvel com as tecnologias presentes no site disponibilizado ao cliente
pelo EBS.
Sistema Operacional
Todos os sistemas para desktops tem a opcao de conectar-se a internet e instalar
algum browser, alguns sistemas ja possuem por padrao instalado, desta forma todos os
Sistemas Operacionais para desktops cumprem o requisito, deste modo, na estacao base
cliente nao ha a necessidade de um SO (sistema operacional) especıfico. Ha a vantagem
para o sistema Linux, pois o mesmo e livre, nao sendo necessario a compra de uma licenca
de uso, alem de ser menor e mais leve, facilitando para pessoas possuem computadores
mais antigos.
40
Sistema OperacionalOpcoes Microsoft Windows Apple MacOS Linux e DerivadosRequisitos Para Windows 7: - Para Ubuntu 12.04:
Processador de 1 gigahertz (GHz)ou superior de 32 bits (x86) ou 64bits (x64)
Processador: Pen-tium 4, 1GHz
1 gigabyte (GB) de RAM (32bits) ou 2 GB de RAM (64 bits)
Memoria RAM:512MB
16 GB de espaco em disco dis-ponıvel (32 bits) ou 20 GB (64bits)
Disco: 5GB
Download 2.2GB (32 bits) - 700mb3.5GB (64 bits)
Tabela 3.18: Sistema Operacional para EBC
Browser
Todos os browsers possuem a capacidade de entrar no website fornecido pela EBS,
porem, recomenda-se as versoes atualizadas dos mesmos. Para a API de Mapas, tem-se o
seguintes requisitos de versoes: Microsoft Internet Explorer 8.0 ou posterior, Firefox 3.6
ou posterior, Safari 3.1 ou posterior, Google Chrome 20 ou posterior. Ha a preferencia
pelo navegador Firefox por ser livre e de facil acesso a todos os sistemas operacionais.
Browser para o EBCOpcoes Google Chrome Apple Safari Mozilla Firefox Microsoft Inter-
net ExplorerRequisitos Safari 5.1.7: Firefox 3.6: IE 8:
Windows XPService Pack2+,WindowsVista, Windows7, Windows8, Mac OS X10.6 ou poste-rior, Ubuntu12.04+, Debian7+, OpenSuSE12.2+, FedoraLinux 17+
Windows XPSP2 ou superior
Windows 2000,Windows XP,Windows Server2003, WindowsVista, Windows7, Mac OS X10.4 ou maisrecente, Linux:Bibliotecas:GTK+ 2.10 ousuperior, GLib2.12 ou superior,Pango 1.14 ousuperior, X.Org1.0 ou superior
Windows XPde 32 bits comService Pack2 (SP2) ousuperior
41
Processador: In-tel Pentium 4 ouposterior
Processador 233Mhz (Recomen-dado: Pentium500MHz ou su-perior)
Memoria RAMde 64 MB
Disco de 100MB 52 MB de espacoem disco
Disco de 150 MB
RAM de 128 MB 64 MB de RAM(Recomendado:128 MB RAMou superior)
Disco de 150 MB
Tabela 3.19: Browser Compatıvel com o Website
3.2.4 Opcoes Tecnologicas EBS
Apos a analise dos requisitos da EBS foi possıvel definir os seguintes recursos
necessarios para a execucao do projeto: banco de dados, responsavel por guardar os da-
dos mais antigos captados pelos sensores da EMR, API para desenvolvimento de mapas,
necessaria para informar ao usuario final a posicao do sistema remoto, API para graficos,
para melhorar a visualizacao dos dados pelo usuario, programacao web, para o desen-
volvimento do website e programacao do deamon, que estara diretamente conectado ao
sistema embarcado recebendo e enviando informacoes e atualizando o banco de dados.
Banco de Dados
Banco de DadosPostgreSQL MySQL SQL Server
Licenca BSD GLP ProprietarioRequisitos Instalacao do Servidor
na Maquina.Instalacao do Servidorna Maquina.
Utilizacao da Plata-forma Windows.
Nenhuma limitacao deSO.
Nenhuma limitacao deSO.
Utilizacao dos pacates.NET.Maior necessidade deespaco livre em disco,cerca de 1.7 GB contra150MB do MySQL,por exemplo.
Tabela 3.20: Comparacao de Banco de Dados
Para a definicao do banco de dados a ser utilizado descarta-se a opcao do SQL
Server, pois esta possui licenca privada e tem um maior requisito de espaco, de bibliotecas
42
e da framework .NET, ficando restrita ao sistema operacional Microsoft Windows. As
duas opcoes restantes sao PostgreSQL e MySQL, os quais sao de licenca livre e tem
praticamente as mesmas caraterısticas, destacando-se a maior robustez do PostgreSQL e
a maior rapidez e facilidade de programacao do MySQL.
Deste modo optou-se por MySQL, pois este componente e a alta produtividade
e a administracao do banco de dados atraves do MySQL e simplificada e rapida, fazendo
com a opcao do mesmo seja a mais adequada.
API de Mapa
Para a apresentacao de mapas no projeto buscou-se as duas APIs mais conhecidas
para este tipo de desenvolvimento, a descricao de ambas esta presente na Tabela 3.21.
A API do Google implica maiores restricoes de uso a usuarios gratuitos, como o limite
de resolucao e a escala, mas por sua vez apresenta interface para teste facilitando a
programacao e testes.
APIs de MapaGoogle Maps Bing Maps
Licenca Proprietaria. Proprietaria.Livre se o site for abertoe de acesso publico, mascom uma quantidade li-mitada de acessos.
Gratuito para Aplicacoesque nao visam lucro.
Resolucao (Pixels) 600x600 Sem RestricaoTamanho do Mapa 1200x1200 pixels, re-
solucao multiplicada 2(Escala maxima parausuarios gratuıtos) .
Sem Restricao
Interface para Testes Sim NaoBrowser Recomendados IE7+, Firefox 2.0.0.8+,
Safari 3+, Mozilla 1.7+,Opera 8.02+, Google Ch-rome 1+
IE7+, Mozilla Firefox3.5+, Google Chrome 4+,Safari 4+
Tabela 3.21: Comparacao de APIs de Mapas
A escolhida para ser utilizada no projeto sera a Google Maps API pois, apesar de
apresentar algumas restricoes quanto ao tamanho do mapa, e mais completa em regioes
fora do Estados Unidos e ainda contem um pequeno SandBox para testes.
43
API de Graficos
As APIs de graficos que cumprem os requisitos estao listadas na Tabela 3.22,
todas podem desenhar uma quantidade suficiente de graficos. A versao da Google nao
possui mais suporte, deste modo para obter-se versoes com suporte recomenda-se versoes
modificadas da mesma e que tenham o ponto positivo de possuırem licencas gratuitas,
facilitando uma possıvel distribuicao do projeto no futuro. A versao escolhida sera Google
Charts, pois e mais completa e ainda e disponibilizada em AJAX o que diminuiria a carga
de processamento da EBS.
API para GraficosJFreeChart Google Chart Api JpGraph
Licenca GLPL Proprietaria QLP 1.0Compatıvelcom
Java Ajax. PHP
Versoes de terceiros:Java, C#, Ruby,Python, PHP, Pearl
Tipo deGraficosDis-ponıveis
Torta, tabelas, dis-persao, geologia, li-nha, barras, colunas,area
Torta, tabelas, dis-persao, geologia, li-nha, barras, colunas,area
Na versao basica:Linha/Area, torta,barras, impulso,mapas de geologia,polar, erro, balao,radar, curva de nıvel,dispersao
Tabela 3.22: Comparacao de APIs para Graficos
Servidor
Para a programacao do deamon no servidor, a equipe verificou duas opcoes: C++
e Java. A utilizacao desta linguagem sera para a programacao do sistema que tera de
capturar os pacotes enviados pela EMR, atraves do protocolo a ser desenvolvido, do
tratamento destes dados e seu armazenamento no banco de dados.
C++ e uma linguagem orientada a objetos, sucessora do C, a qual e uma das
linguagens mais usadas no mundo, desta forma, esta linguagem possui uma grande co-
munidade de suporte, incluindo grande numero de bibliotecas. C++ tambem possui uma
gama de bibliotecas e codigos disponıveis para a realizacao de varios requisitos, como
acesso ao banco de dados ou a captura dos pacotes via web. A programacao em C++
44
pode ser realizada tanto em ambiente Windows, MacOS ou Linux, porem o codigo C++
devera sempre ser recompilado ao ser transportado para outra plataforma. C++ possui
varios ambientes de desenvolvimento (IDEs) como CodeBlocks e DEV-C++, que sao de
uso livre.
Java e concorrente de C++ na questao de ser uma das linguagens de orientacao a
objetos mais utilizadas no mundo e, assim como C++, possui vasto suporte pela internet,
com um grande numero de bibliotecas disponıveis para as necessidades do projeto, como
a conexao a web e a conexao com o banco de dados. A principal vantagem da linguagem
Java e o fato da mesma utilizar uma maquina virtual para a execucao dos seus programas,
desta forma um programa desenvolvido em Linux pode ser executado em Windows, sem
necessidade de uma nova compilacao. Outro fator importante no desenvolvimento Java
sao suas ferramentas de desenvolvimento (IDEs), tanto Eclipse e NetBeans proporcionam
ao programador uma grande facilidade na hora de administrar seus programas, com a
vantagem de ambas serem livres.
Bibliotecas Necessarias C++ e JavaBliblioteca C++ JavaCriacao de Sockets Sim, documentacao e
exemplos disponıveisSim, nativa a bibliotecapadrao
Conexao com o Banco dedados PostgreSql
Sim, libpq C++ Sim, JDBC
Conexao com o Banco dedados MySQL
Sim, MySQL Connec-tor/C++
Sim, MySQL Connector/J
Nativa Linux? Sim Nao
Tabela 3.23: Comparacao de bibliotecas C++ e Java
A equipe optou pela linguagem C++. O servidor estara sob uma plataforma
Linux, que possui suporte nativo a C++, nao necessitando da instalacao de programas
de terceiros e possuindo uma gama de bibliotecas sem a necessidade de adquiri-las na
internet, por exemplo, deste modo a programacao do servidor e facilitada ganhando-se
tempo.
Linguagem das Paginas Web
Para o desenvolvimento das paginas que serao hospedadas em um servidor web
foi realizada a comparacao entre duas linguagens, apresentadas na tabela 3.24. As duas
linguagens sao amplamente utilizadas atualmente, mas o PHP foi escolhido, pois o mesmo
45
e livre e apresenta maior compatibilidade com a grande maioria de servidores de hospe-
dagem.
Linguagem da Pagina WebPHP ASP
Licenca Livre ProprietariaHospedagem Apache Microsoft IISCompatibilidade Windows, e Padrao PO-
SIX (Unix e Linux)Windows
Tabela 3.24: Comparacao de linguagens WEB
Servidor de hospedagem da pagina web
Para o servidor web foi realizada a comparacao entre dois servidores e apresentada
na tabela 3.25. Os dois servidores tem boas caracterısticas, mas o servidor Apache foi
escolhido, pois o mesmo e livre e apresenta maior compatibilidade com os varios sistemas
operacionais e tambem pelo fato de a linguagem escolhida para o desenvolvimento do
website ter sido o PHP e o Microsoft IIS nao suportar esta linguagem.
Servidor para Host da Pagina WebApache Microsoft IIS
Licenca Apache (Livre) ProprietariaCompatibilidade Windows, e Padrao PO-
SIX (Unix e Linux)Windows
Tabela 3.25: Comparacao de servidores WEB
Sistema Operacional EBS
Assim como na EBC se faz necessario a utilizacao de um sistema operacional na
EBS, mesmo que este sera invisıvel ao cliente final. De acordo com a Tabela 3.18 e possıvel
verificar que os sistemas basedos em Linux impoem uma carga menor aos requisitos de
maquina e internet. Assim optou-se pelo Linux, ou algum de seus derivados, para a
utilizacao na EBS, e alem de ser mais leve proporciona a capacidade da programacao
nativa a C++, sem necessidade de adquirir outros programas.
46
4 — Plano de Execucao
Nesta secao esta presente a metodologia de desenvolvimento, o cronograma, o
orcamento, os gastos e o plano de riscos. Devido as decisoes tomadas na analise tecnologica
foi possıvel elaborar esses documentos com maior rigor.
4.1 Metodologia
A metodologia de desenvolvimento utilizada foi a do modelo em espiral. Nas
primeiras semanas da disciplina foi elaborado o plano de projeto que envolveu: analise
tecnologica, cronograma, orcamento e o plano de resposta aos riscos. O plano de projeto
orientou a definicao das metas e dos documentos a serem entregues em quatro Deliverables,
descritos na secao a seguir.
4.2 Cronograma
Para que os sponsors possam fazer o acompanhamento do projeto e tambem para
que este tenha um bom andamento, foram definidas datas para a entrega de deliverables
(entregaveis). Os deliverables sao partes do projeto e sao entregues a cada duas semanas.
A seguir sao apresentados os deliverables a serem cumpridos durante o perıodo
de desenvolvimento do projeto. Como anexo deste documento de planejamento esta o
cronograma mais detalhado de todas as fases do desenvolvimento.
4.2.1 Primeiro Entregavel (07/08)
• Subgerente: Alesandro Alessi
• Hardware:
– Objetivo:
1. Estudo teorico de todos componentes.
– Entregavel:
47
1. Relatorio de checagem de funcionamento dos componentes adquiridos.
• Software:
– Objetivo:
1. Estudo das opcoes escolhidas e planejamento parcial das solucoes.
– Entregavel:
1. Implementacao de exemplos do Google Charts e Maps ;
2. Prototipacao inicial do website.
4.2.2 Segundo Entregavel (21/08)
• Subgerente: Tiago Gregio de Aveiro
• Hardware:
– Objetivo:
1. Teste de aquisicao dos dados dos sensores;
2. Modos de operacao do microcontrolador;
3. Teste das funcoes do modulo GM862-GPS.
– Entregavel:
1. Relatorio dos resultados dos testes dos sensores;
2. Demonstracao de teste do modulo GM862-GPS conectado a um computa-
dor via USB;
3. Documentacao do sistema de comunicacao entre EMR e EBS.
• Software:
– Objetivo:
1. Conclusao do planejamento e inicio do desenvolvimento dos softwares da
EBS.
– Entregavel:
1. Diagrama entidade-relacionamento do banco de dados;
2. Diagrama de casos de uso do website;
48
3. Diagrama de atividades do website;
4. Diagrama de casos de uso do deamon;
5. Diagrama de atividades do deamon (C++).
4.2.3 Terceiro Entregavel (04/09)
• Subgerente: Jonathan Pontes Morais do Nascimento
• Hardware:
– Objetivo:
1. Estudo e confeccao da estrutura mecanica.
– Entregavel:
1. Demonstracao de testes de envio de pacotes UDP atraves do modulo GPRS
ja acoplado ao microcontrolador para a EBS;
2. Demonstracao de testes com o GPS ja acoplado ao microcontrolador;
3. Diagramas eletricos para acoplamento dos sensores e do modulo GM862-
GPS.
• Software:
– Objetivo:
1. Desenvolvimento do deamon e conlusao do website.
– Entregavel:
1. Demonstracao das funcoes de comunicacao do deamon;
2. Website parcialmente funcionando (prototipacao final).
4.2.4 Quarto Entregavel (18/09)
• Subgerente: Amanda Micoski Lins
• Hardware:
– Objetivo:
1. Estabelecer e realizar testes com o protocolo de comunicacao com a EBS;
49
2. Realizar testes com o GPS;
3. Confeccao da PCI para acoplamento do modulo GM862-GPS.
– Entregavel:
1. Demonstracao de envio do pacote de dados dos sensores ja acoplados na
EMR e das coordenadas GPS para a EBR atraves do modulo de GPRS.
• Software:
– Objetivo:
1. Conclusao do deamon;
2. Integracao de todo o projeto.
– Entregavel:
1. Deamon integrado ao o website;
2. Testes de comunicacao entre EMR e EBS.
50
5 — Orcamento Detalhado
A Tabela 5.1 apresenta os gastos obtidos com os componentes eletronicos ne-
cessarios para desenvolver o projeto, contando com a compra de componentes adicionais,
do mesmo modelo, para eventuais problemas que possam danificar algum componentes
que esta sendo utilizado.
Componente Modelo Qtd. Valor un. Frete TotalMicrocontrolador* LPCXpresso LPC1769 2 54,00 0,00 108,00Comunicacao e Lo-calizacao*
Telit GM862-GPS 2 203,00 20,40 426,40
Sensores
DS18B20 2 15,00 14,10 44,10HS1101 2 13,50 14,10 41,10BH1750 2 30,00 0,00 60,00MQ-7 2 24,50 6,95 55,95MQ-135 2 14,20 6,95 35,35
Alimentacao* Bateria Li-Po 2200mAh11.1V
2 44,90 13,90 103,70
Total (R$) 874,60
Tabela 5.1: Orcamento detalhado de componentes
Aqueles marcados com ‘*’ sao modelos que a equipe ja possuıa, nao sendo ne-
cessario efetuar a compra de um componente adicional.
Nao foi feita a compra de nenhum microcontrolador, pois a equipe ja possuıa dois
deste.
A Tabela 5.2 apresenta o orcamento real do projeto.
Componente Qtd. Custo TotalMicrocontroladores 0 0,00Comunicacao e Localizacao 1 223,40Sensores 8 236,40Alimentacao 1 58,80Software (EB) 0 0,00Total (R$) 518,60
Tabela 5.2: Orcamento final real
O gasto com software e justificavel pois todos os programas, linguagens e biblio-
tecas definidas pela equipe sao de licenca livre, acarretando nenhum custo ao projeto. O
51
servidor de hospedagem do sistema web sera realizado por um servidor proprio da equipe,
nao acarretando gasto algum tambem.
52
6 — Sistema Embarcado
O sistema embarcado possui tres principais componentes: o conjunto de sensores,
modulo de comunicacao e localizacao e o microcontrolador. Neste capıtulo serao apresen-
tados os detalhes de funcionamento e implementacao referentes a EMR. Os componentes
da EMR sao descritos na Figura 6.1.
Figura 6.1: Visao Geral da EMR
Este capıtulo foi divido em secoes, de acordo com a ordem em que o projeto foi
desenvolvido, para que fiquem claros os passos de implementacao e possam ser repetidos
por trabalhos futuros. As secoes sao descritas a seguir:
• Detalhes de funcionamento, na qual sera feita um descricao de cada componente e
suas caracterısticas;
• Acoplamento dos componentes, na qual serao descritos os passos para o acoplamento
dos componentes da EMR ao microcontrolador e explicacao dos circuitos eletricos
e componentes necessarios
• Integracao dos Componentes da EMR, na qual sera feita uma descricao da integracao
de todos componentes
53
6.1 Detalhes de funcionamento
Nesta secao sera feita uma descricao do funcionamento e implementacao do aco-
plamento de cada componente da EMR (sensores, modulo de comunicacao e outras partes
necessarias).
6.1.1 Sensores
Cada sensor foi estudado separadamente e foi desenvolvido um software e hard-
ware de acoplamento separadamente para cada de forma paralela.
Apos os testes com cada sensor, houve o processo de integracao de todos em um
mesmo hardware e software, formando a estrutura final da EMR.
6.1.2 Sensor de temperatura
O sensor de temperatura utilizado e o DS18B20 da Maxim’s IC (anteriormente
chamada Dallas Semiconductor). E um sensor digital que utiliza o protocolo 1-wire e
possui opcao de configuracao de precisao de 9 a 12 bits, medindo de −55C a 125C.
Detalhes do funcionamento
• Alimentacao e esquema para acoplamento
O sensor DS18B20 possui duas possıveis formas de alimentacao. A primeira e
chamada de alimentacao ”parasita”, na qual o sensor recebe alimentacao e faz a
comunicacao utilizando o mesmo pino. A segunda forma utiliza outro pino para
alimentacao, utilizando alimentacao externa.
A equipe decidiu utilizar a segunda forma de alimentacao por ser mais segura com-
parada ao outro modo, o qual pode apresentar altas quedas de tensao que prejudicar
o funcionamento do circuito, segundo o datasheet. O esquema utilizado foi o suge-
rido tambem pelo datasheet do componente, como pode ser visto na figura 6.2.
• Protocolo 1-wire
O protocolo de comunicacao 1-wire e um sistema de barramento que utiliza apenas
um fio para envio e recepcao dos dados. Foi desenvolvido pelo fabricante do sensor,
54
Fonte: DS18B20 datasheet (adaptado)
Figura 6.2: Acoplamento e alimentacao do sensor DS18B20
tem a caracterıstica de transferir dados em menor velocidade (comparado outros
protocolos) e ter um sistema de sinalizacao permitindo ate 127 dispositivos no mesmo
barramento.
O protocolo possui a seguinte ordem de funcionamento:
1. Envio de sinal de reset pelo mestre.
2. Resposta do dispositivo escravo com um pulso de presenca.
3. Comando ROM, utilizado para enderecar um dipositivo especıfico do barra-
mento.
4. Envio do codigo de funcao do sensor utilizado, podendo ser uma escrita ou
leitura de dados, por exemplo.
E importante lembrar que o protocolo possui time slots (um tempo reservado) para
escrita e leitura dos dados de, no mınimo, 60 microsegundos para cada bit com 1
microsegundo de recuperacao entre cada envio. Para determinar se o dado recebido
e valido, pode-se calcular o Cyclic Redundancy Check (CRC) dos bytes recebidos e
compara-lo com o CRC enviado pelo sensor.
• Funcoes do sensor DS18B20
O sensor DS18B20 possui codigos de funcao proprios para auxiliar no seu funcio-
namento. O sensor possui uma memoria RAM denominada scratchpad que possui
todas informacoes de funcionamento atualizadas do sensor (possuindo 8 bytes, no
total). Ele tambem possui uma memoria EEPROM que pode guardar informacoes
de configuracao (salvas em um registrador). Essa organizacao de memoria pode ser
observada melhor na Figura 6.3. A seguir sao descritas as funcoes do sensor:
– Convert T (44h): Iniciar conversao de temperatura, o sensor transmite o status
de conversao para o mestre.
55
– Read Scratchpad (BEh): Leitura do scratchpad (memoria RAM) inteira do
sensor.
– Write Scratchpad (4Eh) : Escrita na memoria do sensor, nos registradores
correspondentes a sua configuracao.
– Copy Scratchpad (48h) : Copia dos registradores de configuracao do scratchpad
para a EEPROM do sensor.
– Recall E2 (B8h) : Copia dos registradores de configuracao da EEPROM do
sensor para o scratchpad.
– Read Power Supply (B4h): Leitura do modo de alimentacao do sensor.
Fonte: DS18B20 datasheet (adaptado)
Figura 6.3: Organizacao de memoria do sensor DS18B20
Apos o envio do codigo da funcao desejada, o mestre deve fazer a validacao dos dados.
No caso de uma leitura visando obter o resultado de conversao de temperatura, o
mestre deve ler os bytes 0 e 1 (LSB e MSB, respectivamente) do scratchpad, fazer
o deslocamento dos bits e multiplicar pelo fator de conversao adequado, de acordo
com a configuracao escolhida (0.0625 para precisao de 12 bits, por exemplo).
Resultados Iniciais
Para que fosse feita uma analise mais rapida do funcionamento do sensor, primei-
ramente foram realizados testes com um kit Arduino. O sensor foi ligado ao microcontro-
lador atraves do esquema apresentado na Figura 6.2, ou seja, conectado a um pino digital
e a uma fonte externa de alimentacao de 5V. A mesma configuracao pode ser aplicada
utilizando o microcontrolador LPC1769, mudando apenas a tensao utilizada para 3.3V.
Apos o acoplamento do sensor, foi desenvolvido um codigo de teste (baseado em
exemplos) e foram realizados alguns experimentos. A temperatura obtida pelo sensor foi
56
proxima da indicada por termometros digitais simples e a sites de meterologia quando
testado em ambientes externos. Foi possıvel observar variacoes de temperatura quando
colocado em condicoes diferentes, proximo a um aquecedor, por exemplo.
No primeiro dia de testes, por exemplo, os websites de meteorologia indicavam
13 graus para as 20h em Curitiba e a temperatura medida foi de 14 graus, o que esta
dentro do aceitavel, sabendo que a temperatura indicada no site e uma media e pode
variar muito de local para local na cidade.
6.1.3 Sensor de luminosidade
O sensor de iluminacao utilizado e o BH1750, o qual mede intensidade iluminosa
em ambientes. Ele e um sensor digital (possui um AD de 16 bits internamente). Sua
saıda e a medida de intensidade luminosa ja calculada em Lux (lx).
O BH1750 utiliza a interface I2C para comunicacao e possui um resolucao de 1
a 65535 lx.
Detalhes do funcionamento
• Protocolo I2C
O protocolo I2C e um protocolo de barramento serial multi-mestre. O protocolo foi
desenvolvido pela Philips e seu nome significa circuito inter-integrado.
O I2C utiliza dois fios bidirecionais para comunicacao e sincronizacao: Serial Data
Line (SDA) e textit Serial Clock (SCL), possuindo tambem um espaco de en-
derecamento para utilizacao de mais de um dispositivo escravo.
Neste protocolo ha dois tipos de papeis que podem ser exercidos pelos dispositivos:
mestre e escravo. O mestre e quem inicia a comunicacao e o responsavel pela geracao
dos pulsos na linha SCL. O escravo recebe os pulsos da linha SCL e responde as
requisicoes do mestre quando requisitado. Ambos dispositivos devem alternar entre
modo de envio e modo de recepcao de dados.
O protocolo possui a seguinte ordem de funcionamento:
1. O mestre inicia a comunicacao em modo de envio, envia um start bit, o bit de
inicializacao, seguido do endereco do dispositivo e o bit de operacao que deseja
realizar no escravo(0 para escrita e 1 para leitura).
57
2. Se o escravo receber corretamente a mensagem ele responde com um bit de
ACK, bit de confirmacao.
3. A seguir os dispositivos se comunicam segundo a operacao escolhida pelo mestre
(leitura ou escrita do escravo), enviando/recebendo mensagens de 1byte + ACK
(9 pulsos de clock na linha SCL) como na Figura 6.4.
4. Para encerrar a comunicacao o mestre deve enviar um stop bit, bit de encerra-
mento. Para iniciar mais uma transmissao de dados o mestre deve enviar um
novo start bit.
Fonte: Robot Electronics
Figura 6.4: Transmisao de dados via I2C
• Alimentacao e acoplamento
O sensor BH1750 ja vem em uma PCI desenvolvida pela empresa DF-Robot, pos-
suindo a vantagem de nao necessitar de nenhum componente externo para o acopla-
mento do sensor a um microcontrolador, bastando conectar pinos de entrada/saıda
(GPIO) aos pinos SDA e SCL (Figura 6.5).
Fonte: DF-Robot (adaptado)
Figura 6.5: Acoplamento e alimentacao do sensor BH1750
58
Resultados Iniciais
Para que fosse feita uma analise mais rapida do funcionamento do sensor, primei-
ramente foram realizados testes com um kit Arduino. O sensor foi ligado ao microcontro-
lador diretamente em seus pinos. Para os pinos SDA e SCL foram escolhidos dois pinos
digitais, foram tambem conectados os pinos de alimentacao diretamente ao microcontro-
lador. A mesma configuracao pode ser aplicada utilizando o microcontrolador LPC1769,
mudando apenas a tensao utilizada.
Apos o acoplamento do sensor, foi desenvolvido um codigo de teste (baseado em
exemplos) e foram realizados alguns experimentos. Os resultados obtidos foram condizen-
tes com as tabelas de intesidade em lux apresentadas pelos exemplos e artigos. Quando
testado em um ambiente interno, durante o dia, mas com pouca abertura para o Sol, foi
obtido o valor de 40lx, o que fica dentro da faixa de 5 a 50lx apresentada. Ao abrir as
cortinas do ambiente esse valor subiu para 700, num dia de sol, ficando tambem dentro
da faixa esperada de 100 a 1000lx.
6.1.4 Sensor de umidade
O sensor de umidade escolhido pela equipe foi o HS 1101, da fabricante Humirel.
Este sensor se trata de um capacitor, onde sua capacitancia e diretamente proporcional a
umidade relativa do ar. A figura 6.6 mostra esta relacao.
Fonte: HS 1101 datasheet (adaptado)
Figura 6.6: Relacao entre a capacitancia do sensor e umidade
O calculo da umidade relativa pode ser feita de diversas formas, dentre as citadas
59
no datasheet temos a relacao entre umidade e capacitancia, relacao entre a umidade e a
tensao de saıda e relacao entre a umidade e a frequencia, este ultimo com auxılio de um
temporizador. Cada relacao possui uma formula especificada no datasheet para encontrar
a variavel da umidade relativa, e para a relacao entre a umidade e frequencia, foi montado
o circuito da figura 6.7.
Fonte: HS 1101 datasheet (adaptado)
Figura 6.7: Circuito especificado
Os testes realizados com este sensor apresentaram valores dentro do esperado.
6.1.5 Sensores de gases poluentes
Um dos principais objetivos da EMR e o monitoramento de gases nocivos aos
seres humanos. Dentre muitos sensores disponıveis no mercado, foram escolhidos os sen-
sores MQ-7 para deteccao de monoxido de carbono e MQ-135 para deteccao de gases
VOC. Ambos sensores possuem saıda analogica, sendo seu interfaceamento com o micro-
controlador realizado atraves das portas AD, que convertera o sinal analogico em digital,
para que sua informacao seja tratada e usada pelo microcontrolador.
60
MQ-7
Este sensor e utilizado para deteccao de gas monoxido de carbono (CO). Este
sensor e analogico, e utiliza um conversor analogico-digital do microcontrolador como
metodo de comunicacao.
O sensor MQ-7 possui uma estrutura composta por um tubo ceramico de oxido
de alumınio, uma camada de dioxido de estanho, e um eletrodo e calefator fixados em sua
base feita de aco inoxidavel e plastico. A figura 6.8 mostra a pinagem do sensor MQ-7 e
a figura 6.9 como e a aparencia deste sensor.
Fonte: MQ-7 datasheet (adaptado)
Figura 6.8: Pinos do sensor MQ-7
Fonte: Autoria Propria
Figura 6.9: Estrutura do sensor MQ-7 comprado pela equipe
Sua estrutura fısica proporciona baixa condutividade no ar em condicoes normais,
sem a presenca de CO, ou com uma presenca ınfima do mesmo. Quando ha presenca
deste, aumenta a condutividade do sensor, podemos notar isso com o aumento da tensao
de saıda, o que esta atrelado ao aumento da concentracao deste gas.
61
Este sensor e o proximo citado, possuem seu funcionamento de forma muito
parecida, ambos sao feitos com um material similar, e funcionam de maneira similar
tambem. Estes possuem uma tensao de aquecimento (Vh) e uma tensao de teste (Vc).
Vh e usado para ajustar a temperatura correta de trabalho do sensor, enquanto o Vc, e o
VCC, quem alimenta o sensor para que este opere. Ambos os sensores utilizam a mesma
tensao (5 Volts) para ambas. Outro fator determinante para o bom funcionamento do
sensor e a sua resistencia de carga (RL), a sua tensao (VRL) e equivalente a tensao de
saıda do sensor, e ela varia em funcao da concentracao dos gases. No datasheet temos
aconselhado utilizar RL entre 5 kΩ e 47 kΩ.
Para o bom funcionamento do MQ-7, o mesmo utiliza um ciclo de alta e baixa
temperatura. Em baixa temperatura (quando seu VH e 1,5V) a condutividade do sensor
se torna menor, e o mesmo se torna mais sensıvel a CO. No ciclo de alta temperatura,
onde sua condutividade se torna maior (quando o VH e 5V), o sensor faz a limpeza de
outros gases absorvidos quando estava em temperatura baixa, refinando a sua deteccao
de CO.
Em relacao a calibracao, e necessario que o sensor fique ligado durante 48 horas,
para que suas medidas se tornem mais precisas. E ainda em relacao a calibracao, e
recomendado pelo datasheet que se faca em um ambiente com a presenca de 200 ppm de
concentracao de CO no ar.
O sensor comprado pela equipe, ja veio soldado em uma placa de circuito impresso
com alguns componentes, dentre eles um potenciometro para a resistencia de carga, e pinos
de entrada para VCC e GND e a tensao analogica de saıda do sensor.
MQ-135
O sensor MQ-135 e o responsavel por colher informacoes, tambem em ppm, de
gases volateis organicos compostos (VOC), dentre eles amonia (NH3), etanol, benzeno,
fumaca, dioxido de carbono (CO2), oxido nitroso (NOx), entre outros.
Como dito anteriormente, este sensor tem sua estrutura muito semelhante ao
do MQ-7 (ate por serem do mesmo fabricante) e tambem tem sua condutividade e por
consequencia tensao de saıda aumentada quando esta em exposicao aos gases a que o
sensor e sensıvel.
A diferenca para o sensor MQ-7 esta na calibracao e na resistencia de carga
62
recomendada. Para este sensor recomenda-se uma resistencia de carga entre 10 kΩ e 47
kΩ, e para sua calibracao recomenda-se colocar o sensor em uma area que tenha 100 ppm
de concentracao de NH3 ou 50 ppm de concentracao de etanol no ar.
O sensor comprado pela equipe, igualmente ao MQ-7, ja veio soldado em uma
placa de circuito impresso com alguns componentes, dentre eles um potenciometro para
a resistencia de carga, e pinos de entrada para VCC e GND e a tensao analogica de saıda
do sensor.
Testes Iniciais
Foram realizados simples testes com ambos sensores de gas. Estes foram ligados
a um Arduıno, e foi monitorado o seu comportamento atraves do valor da tensao de saıda.
Os graficos 6.10 e 6.11 demonstram o monitoramento deste valor.
Como pode-se notar, a saıda se manteve constante ate um determinado momento
onde ela apresentou um pico. Este pico deve-se ao teste que foi realizado para estes senso-
res, onde para o sensor MQ-7, de maneira muito simples, foi colocado um papel pegando
fogo (emitindo CO) perto do sensor, e podemos notar uma mudanca de comportamento
da tensao de saıda, confirmando a teoria de que este sensor tem sua condutividade aumen-
tada quando esta exposta a este tipo de gas. De maneira similar, foi realizado o mesmo
teste para o sensor MQ-135, que tambem e sensıvel a fumaca, e como demonstra o grafico
6.11, obteve-se um aumento de sua tensao de saıda quando o sensor esteve exposto.
Fonte: Autoria propria
Figura 6.10: Grafico de monitoramento sensor MQ-7
63
Fonte: Autoria Propria
Figura 6.11: Grafico de monitoramento sensor MQ-135
6.1.6 Modulo de Comunicacao
O modulo de comunicacao e localizacao utilizado possui uma placa de acopla-
mento (Eletronics, 2005) com interface RS232 ou USB (dependendo apenas da escolha na
hora da compra) para facilitar nos testes iniciais, nao sendo necessario o conectar ao mi-
crocontrolador para estudar, entender e testar os comandos internos, a fim de estabelecer
uma conexao com o servidor ou captar a localizacao via GPS.
Primeiramente foram utilizados alguns comandos ATs para identificar o modulo,
apenas para ativar o modo de insercao de comandos AT e verificar o funcionamento inicial
do modulo. A lista de comandos utilizados, juntamente com alguns comentarios e seus
respectivos resultados, pode ser observada em 6.1. Os demais comandos utilizados para
testar a localizacao via GPS e a conexao com o servidor via GPRS serao apresentados
nas secoes posteriores.
Codigo 6.1: Comandos ATs gerais para teste do funcionamento do GM862-GPS.
1 // Inicializacao dos comandos AT
2 > AT
3 OK
4
5 // Tipo de saida de erros (1 = numeros)
6 > AT+CMEE=1
7 OK
8
9 // Identificao do fabricante
10 > AT+GMI
11 Telit
12 OK
64
13
14 // Modelo do modulo
15 > AT+GMM
16 GM862−GPS
17 OK
18
19 // Versao do firmware
20 > AT+GMR
21 07.03.401
22 OK
Resultados dos testes iniciais com a localizacao via GPS
Para o teste da obtencao da localizacao via GPS foi inicialmente utilizado a
captacao no formato padrao do modulo, sendo este o formato SiRF (especıfico do modulo).
Uma vez que o modulo esta ativo e funcionando e necessario conferir se a antena GPS esta
conectada ao modulo, para isso pode ser utilizado o comando que retorna a quantidade
de corrente transferida a antena. Assim que a presenca da antena for confirmada resta
apenas o passo de receber a localizacao de pelo menos um satelite.
Os comandos ATs utilizados para esse fim de localizacao via GPS estao apresen-
tados na lista de comandos 6.2.
Codigo 6.2: Comandos ATs para ativacao do GPS e captacao da localizacao.
1 // Detectando corrente consumida, em mA, pelo circuito responsavel
2 // por conectar a antena
3 > AT$GPSAI?
4 $GPSAI: 7
5 OK
6
7 // Recebimento no em algum formato NMEA (opcional)
8 > AT$GPSNMUN=1,0,0,0,0,1,0
9 $GPSNMUN: $GPRMC,212652.999,A,2526.3925,S,04916.4260,W,0.62,62.88,200813,,,A∗54
10
11 // O comando acima gera uma saida a cada segundo, para interromper
12 // basta enviar o mesmo comando mas com a opcao para desabilitar
13 > AT$GPSNMUN=0
14 OK
65
15
16 // Aquisicao da posicao no formato padrao do modulo (nucleo SiRF)
17 > AT$GPSACP
18 $GPSACP: 212957.999,2526.3945S,04916.4293W,2.8,945.8,3,225.68,0.10,0.05,200813,06
19 OK
Uma forma de conferir o local para o qual as coordenadas se referem e utilizando a
ferramente do Google Maps, onde sera possıvel observar que as coordenadas sao referentes
a posicao de onde o modulo GPS foi testado para a confeccao desta secao do documento.
Outra forma de se obter as coordenadas via GPS e a partir do formato padrao
originalmente utilizado para aparelhos eletronicos marıtimos, mas que posteriormente se
tornou o padrao em que todos fabricantes de modulos GPS precisam ter suporte, este e o
formato NMEA-0183 (National Marine Electronics Association). Este padrao consiste em
varios tipos de sentencas, sendo que cada uma pode apresentar dado repetido de outra,
porem, sempre ha algum dado diferenciado/novo, ficando a criterio da aplicacao decidir
qual sentenca interpretar. Vale observar tambem que dependendo para qual proposito o
modulo GPS foi desenvolvido algumas sentencas nao sao suportadas.
As sentencas suportadas pelo modulo GM862-GPS estao descritas na Tabela 6.1,
dentre as quais apenas as informacoes da sentenca RMC foram escolhidas, pois nesta se
encontram todos os dados desejados pela equipe: horario e data da captura, longitude
e latitude. Mais informacoes sobre o conteudo de cada uma das sentencas podem ser
encontradas em (DePriest, 2013).
GGA Global Positioning System Fix DataGLL Geographic position, Latitude and LongitudeGSA Satellite statusGSV Satellites in view
RMC Recommended Minimum sentence CVTG Track made good and ground speed
Tabela 6.1: Tabela de sentencas NMEA-0183 suportadas pelo modulo GM862-GPS
Resultados dos testes iniciais com a comunicacao GPRS
Para estabelecer uma conexao estavel entre o modulo e a rede GPRS da operadora
escolhida e necessario passar por algumas configuracoes dependentes da operadora ao qual
o chip GSM pertence. Porem, primeiramente algumas verificacoes sao necessarias, como a
66
de qualidade de sinal e a conectividade com a operadora (para envio de dados via GPRS).
Os comandos necessarios para essas verificacoes iniciais estao descritas na lista 6.3.
Codigo 6.3: Comandos ATs para verificacao de qualidade de sinal e conectividade com a
operadora escolhida.
1 // Qualidade do sinal (em atenuacao dBm).
2 > AT+CSQ
3 +CSQ: 25,0
4 OK
5
6 // Verifica se esta conectado a rede −> 0,1 = conectado.
7 > AT+CREG?
8 +CREG: 0,1
9 OK
Apos ser verificado que a qualidade de sinal e a conexao estao corretas, as confi-
guracoes referentes a operadora escolhida devem ser feitas. Configuracoes estas que irao
possibilitar o uso da rede GPRS para transmissao de dados, provendo um endereco IP
unico na Internet para o modulo. Os comandos ATs referentes a estas configuracoes estao
apresentados na lista 6.4.
Codigo 6.4: Comandos ATs para estabelecer conexao com rede GPRS.
1 // Configuracoes da rede de banda larga da claro .
2 > AT+CGDCONT=1,"IP","bandalarga.claro.com.br","0.0.0.0",0,0
3 OK
4
5 // Usuario e senha para acessar a rede.
6 > AT#USERID="claro"
7 OK
8
9 > AT#PASSW="claro"
10 OK
11
12 // Conectar GPRS a rede.
13 > AT#GPRS=1
14 +IP: 187.70.44.30
15 OK
16
17 // Tamanho do pacote a ser enviado/recebido em bytes.
67
18 > AT#PKTSZ=50
19 OK
20
21 // Tempo de timeout de inatividade do socket (nao envia/recebe nada) em
22 // segundos.
23 > AT#SKTTO=30
24 OK
Com o endereco IP estabelecido e possıvel efetuar a troca de informacoes entre
o modulo e o servidor. Porem, para isso ainda e necessario efetuar mais algumas confi-
guracoes, principalmente quando o modulo esta a espera de um pacote, pois neste caso
sera necessario configurar o firewall e ativar a aceitacao automatica do pacote. Ja para
enviar um pacote ao servidor e aguardar sua resposta para este e algo mais simples, ne-
cessitando apenas enviar um socket com a informacao desejada ao servidor (atraves de
seu IP ou endereco DNS).
Quando se tratando da espera por recebimento de novos pacotes, os comandos
ATs necessarios para realizar as configuracoes previamente mencionadas estao apresenta-
das na lista de comandos 6.5. Para o envio do socket com as informacoes desejadas os
comandos estao presentes na lista 6.6.
Codigo 6.5: Comandos ATs necessarios para habilitar a escuta de portas UDP para a recepcao
de pacotes.
1 // Firewall libera recebimento de pacotes de todos os ips .
2 > AT#FRWL=1,"1.1.1.1","0.0.0.0"
3 OK
4
5 // Todo pacote que receber gera um evento na porta serial.
6 > AT#SCFGEXT=2,1,1,0,0,0
7 OK
8
9 // Escuta porta 1500 A espera de pacotes UDP com socket 2.
10 > AT#SLUDP=2,1,1500
11 OK
Codigo 6.6: Comandos ATs para envio do socket com a informacao desejada.
1 // Configuracao para envio do pacote em modo de comando.
2 > AT#SD=1,1,1500,"oficinas3.tk"0,0,1
68
3
4 // Envia pacote pelo socket 1
5 > AT#SSEND=1
6 >> texto qualquer <ctrl+Z>
7 OK
8
9 // Caso nenhum dado seja transmitido durante o tempo especificado
10 // no comando AT#SKTTO o socket encerra a conexao.
11 NO CARRIER
6.2 Acoplamento dos componentes da EMR
6.2.1 Acoplamento ao microcontrolador
O acoplamento do modulo GPS foi realizado utilizando uma das interfaces UART
ja disponıveis no LPC1769. Os pinos do microcontrolador utilizados para comunicacao
foram P0.2 (Tx) e P0.3 (Rx) e foram assim escolhidos pela possibilidade de trabalhar com
interface UART, a interface UART0 deste microcontrolador. Esses pinos foram ligados aos
pinos TXD e RXD do modulo GM862, o que e uma configuracao nao usual, sabendo que
geralmente o pino Tx de um dispositivo e ligado ao Rx do outro e vice-versa. Sendo assim,
o barramento Tx indica a transmissao de dados no sentido microcontrolador-modulo e o
barramento Rx indica o sentido oposto. Alem dos pinos utilizados para comunicacao,
o pino P2.13 (pino de entrada e saıda) do microcontrolador foi utilizado para ligar e
desligar o modulo, visto que o mesmo consumira muita energia e sera necessario desativa-
lo quando seu uso nao for necessario. Ha ainda um LED indicador do status do modulo
(STAT LED), que indica se o modulo esta ligado e se esta conectado. Todas essas ligacoes
e configuracoes podem ser observadas nos esquematicos apresentados na secao de anexos.
6.2.2 Descricao da implementacao da interface com os sensores
Nesta secao sera feito um detalhamento do interfaceamento com os sensores da
EMR, complementando a descricao feita na secao anterior.
69
Sensores de Gas
Os sensores de gas nao necessitam de um protocolo de comunicacao proprio,
conforme foi citado anteriormente, ambos sensores possuem saıdas analogicas, desta forma
precisando apenas de um conversor Analogico-Digital para que se possa trabalhar com os
seus valores e fazer a leitura adequada da concentracao dos gases.
O microcontrolador LPC1769 disponibiliza ate 8 canais de conversao analogico-
digital, destes apenas dois foram utilizados, conforme explicado anteriormente. Foi de-
senvolvido um algoritmo para a conversao e leitura destes dados, com os seguintes passos:
1. Configurar os ports do microcontrolador: Inicializar os ports que serao usados no
modo conversor analogico-digital;
2. Selecionar canal a ser convertido: Sera feita uma conversao de cada vez, sera pre-
ciso entao escolher qual dos canais configurados ira realizar a conversao do valor
analogico para digital por primeiro, para depois passar a vez para o proximo;
3. Inicializar conversao: A conversao sera feita bit a bit e acionara uma flag para avisar
que a conversao terminou;
4. Tratamentos para verificar a integridade do valor convertido: O registrador AD
possui uma outra flag que indica se houve erros na conversao, caso tenha acontecido
algum erro, sera exibido um valor que indicara este erro;
5. Imprime valor: O valor do resultado da conversao sera mostrado ao usuario.
A figura 6.12 mostra o diagrama de fluxo para estes eventos.
70
Fonte: Autoria Propria
Figura 6.12: Fluxograma dos sensores de gas
6.2.3 Sensor de Umidade
A exemplo dos sensores de gas, o sensor de umidade tambem nao necessita de um
protocolo de comunicacao proprio. O mesmo se trata de um capacitor variavel, que possui
diversas formas para ser extraıdo a informacao necessaria, ou seja, o valor da umidade
relativa do ar.
Para o microcontrolador LPC1769 conseguir extrair o valor da umidade deste
sensor, foram cogitadas diversas hipoteses, ate chegarmos a solucao que sera implemen-
tada. Foi montado o circuito da figura 6.13 e a saıda (OUT) foi conectada a um pino do
microcontrolador que foi configurado como interrupcao externa. Foi entao desenvolvido
um algoritmo que contabilizava dentro de um perıodo pre-determinado a frequencia emi-
tida pelo capacitor, e depois de colhido este valor, ele foi tratado e convertido para o valor
na unidade desejada para o projeto. Foram seguidos os seguintes passos:
1. Configurar o port do microcontrolador: Inicializar o port 2.10 do microcontrolador
71
Fonte: Autoria Propria
Figura 6.13: Circuito montado para o sensor de umidade
como uma interrupcao externa;
2. Aguarda um tempo pre-estabelecido: O microcontrolador ficara pausado por 1 se-
gundo;
3. Faz a contagem da quantidade de pulsos emitidos pelo circuito do sensor: No tempo
que o microcontrolador estiver pausado, havera um contador para fazer a contagem
de quantos pulsos o sensor de umidade lancou neste tempo, para que seja realizado
o calculo da frequencia;
4. Termina a contagem e reseta os contadores: Apos o fim da contagem, o valor e
salvo em uma varıavel auxiliar e os contadores sao zerados para uma possıvel nova
amostragem;
5. Converte a frequencia obtida em unidade de umidade relativa: O valor salvo sera
convertido para a unidade desejada atraves de uma formula especificada no da-
tasheet;
72
6. Imprime valor final: O valor, ja convertido, sera mostrado ao usuario.
A figura 6.14 mostra o fluxograma para estes eventos.
Fonte: Autoria Propria
Figura 6.14: Fluxograma do sensor de umidade
OneWire
O protocolo de comunicacao OneWire, como explicado anteriormente, utiliza ape-
nas um fio para envio e recepcao dos dados. Ele foi utilizado para o interfaceamento com
o sensor de temperatura DS18B20.
Para que o microcontrolador LPC1769 pudesse comunicar-se com o sensor, foi
desenvolvido um algoritmo de comunicacao com os seguintes passos:
1. Enviar Pulso de Reset: O microcontrolador envia um pulso indicando o inıcio de
um novo processo de comunicacao
2. Aguardar Resposta: O LPC1769 aguarda um pulso do sensor, indicando que esta
disponıvel. Ha um timer ativo para checar se o sensor responde dentro do tempo
esperado.
3. Enviar Comando ROM: Envia o comando que seleciona com qual sensor o micro-
controlador quer se comunicar. Quando ha apenas um sensor no barramento, pode
ser utilizado o comando ”Skip ROM”, no qual nao e necessario informar o codigo
ROM do sensor, economizando tempo.
73
4. Enviar Funcao “Converter T”: Enviar para o sensor a funcao que requisita uma
conversao de temperatura
5. Aguardar Fim de Conversao: Aguardar que o sensor converta os dados, geralmente,
num tempo de 750ms para a mais alta resolucao
6. Enviar Pulso de Reset: O microcontrolador envia um pulso indicando o inıcio de
um novo processo de comunicacao
7. Aguardar Resposta: O LPC1769 aguarda um pulso do sensor, indicando que esta
disponıvel. Ha um timer ativo para checar se o sensor responde dentro do tempo
esperado.
8. Enviar Comando “Ler Memoria”: Enviar para o sensor a funcao que requisita uma
leitura de sua memoria, onde estao salvos os dados convertidos
9. Receber Dados: Receber os dados do sensor, sem necessitar de nenhuma confirmacao
ou finalizacao de comunicacao com o mesmo.
A ordem dos eventos pode tambem ser observado no fluxograma apresentado na
Figura 6.15.
74
Fonte: Autoria Propria
Figura 6.15: Fluxograma de interface com o sensor DS18B20
75
I2C
O protocolo de comunicacao I2C, como explicado anteriormente, utiliza apenas
um fio para envio e recepcao dos dados e um fio para sincronizacao entre os dispositivos.
Ele foi utilizado para o interfaceamento com o sensor de luz BH1750.
Para que o microcontrolador LPC1769 pudesse comunicar-se com o sensor, foi
desenvolvido um algoritmo de comunicacao com os seguintes passos:
1. Iniciar Comunicacao: Envia bit de inicializacao Start Bit
2. Enviar Endereco + Bit de Escrita: Utilizar referencia do datasheet para determinar
endereco do sensor de acordo com o modo escolhido, 0x23 no caso da resolucao alta.
Enviar mais um bit, indicando que o processo e de escrita.
3. Aguardar ACK: Se for recebido um ACK do dispositivo, o envio teve sucesso e
podemos continuar. Caso contrario, temos um erro.
4. Enviar Comando de Modo de resolucao: Enviar o comando que indique o modo
adequado da resolucao escolhida (0x11, no caso da alta resolucao)
5. Encerrar comunicacao: Enviar Stop Bit
6. Aguardar conversao: Esperar o sensor realizar a medicao e conversao para lux, delay
de 180ms
7. Iniciar Comunicacao: Envia bit de inicializacao Start Bit
8. Enviar Endereco + Bit de Escrita: Utilizar referencia do datasheet para determinar
endereco do sensor de acordo com o modo escolhido, 0x23 no caso da resolucao alta.
Enviar mais um bit, indicando que sera realizada uma leitura.
9. Aguardar ACK: Se for recebido um ACK do dispositivo, o envio teve sucesso e
podemos continuar. Caso contrario, temos um erro.
10. Receber byte mais significativo: Recebe o byte mais significativo da medicao
11. Envia ACK: Confirma o recebimento dos dados enviando um ACK
12. Receber byte menos significativo: Recebe o byte menos significativo da medicao
76
13. Envia NACK: Indica para o sensor que ja recebeu todos bytes que precisa, enviando
um NACK
14. Encerra Comunicacao
A ordem dos eventos pode tambem ser observado no fluxograma apresentado na
Figura 6.16.
77
Fonte: Autoria propria
Figura 6.16: Fluxograma Interface com o sensor BH1750
78
6.3 Diagramas eletricos para acoplamento dos senso-
res e do modulo GM862-GPS
Apos a implementacao da interface com os sensores e modulo GPRS/GPS com
o microcontrolador, foi definido o circuito final de montagem da EMR. Nesta secao os
detalhes desse circuito, justificativas e explicacoes de funcionamento.
Os sensores de gas, MQ-7 (sensor de CO) e MQ-135 (sensor de VOC), foram
comprados soldados em uma PCI que nos fornece 3 pinos, sendo dois para alimentacao
(VCC e GND) e o outro corresponde a saıda analogica (em Volts) dos sensores, nao
sendo assim necessario o uso de outros componentes. O LPC1769 dispoe de 8 pinos para
realizar conversoes Analogicas-Digitais, sendo assim foram escolhidos os pinos P0.23, que
sera utilizado para o sensor de CO, e o pino P0.24 sera utilizado para acoplamento do
sensor de VOC. Foram ligados os pinos de saıda analogica dos sensores aos pinos separados
do microcontrolador para cada sensor.
O sensor de umidade, que e um capacitor variavel, possui diversar formas de uso,
foi escolhido ler o valor da umidade atraves da frequencia de saıda. Para este modo,
segundo o datasheet do sensor, era necessario um CI gerador de pulsos, e para isso foi uti-
lizado o CI NE555, um temporizador que foi utilizado no modo monoestavel e mais alguns
resistores de 47kΩ, 560kΩ, 910kΩ e 1kΩ, todos estes valores foram recomendados pelo
datasheet para o tipo de CI que foi utilizado. A saıda do CI foi acoplada ao pino P2.10,
este configurado no modo de interrupcao externa, necessario para a leitura adequada das
informacoes do sensor.
O sensor de luz, BHT1750 ,o qual utiliza o protocolo I2C, possui 4 pinos que
podem ser ligados diretamente aos pinos do microcontrolador, sem necessidade de outros
componentes, pois semelhante aos sensores de gas, este foi comprado ja com uma PCI
com os resistores de pull-up e capacitores necessarios elaborada pela DFRobot. Os pi-
nos de alimentacao sao ligados aas saıdas correspondentes de VCC e GND. Os pinos de
comunicacao escolhidos, para SDA e SCL, foram P0.27 e P0.28 por possuırem um modo
de configuracao I2C com um interfaceamento ja preparado para o protocolo, tendo regis-
tradores especiais para essa funcao e ter ja implementada uma maquina de estados para
controle da comunicacao atraves dele.
O sensor de temperatura DS18B20, necessita apenas de um resistor pull-up de
79
4.7kΩ para seu acoplamento, sendo que seus outros pinos podem ser ligados diretamente
as saıdas de alimentacao. O pino P0.4 foi escolhido para acoplar o barramento 1-wire deste
sensor, sabendo-se que qualquer pino de GPIO pode ser utilizado nesse acoplamento.
Os diagramas sao apresentados na secao de anexos deste documento.
6.4 Integracao dos componentes da EMR
Desde o inıcio deste projeto os testes realizados, em todas as etapas, foram feitos
separadamente em cada componente ou bloco de sistema, ou seja, na estacao remota
foram executados testes com o modulo GPRS utilizando dados fictıcios dos sensores, e
esses ultimos foram testados sem mesmo estarem acoplados no mesmo circuıto (estando
um circuito separado para cada sensor) e sem estarem conectados ao mesmo tempo no
microcontrolador. Na estacao base, o mesmo metodo foi utilizado para a implementacao
do website e do daemon (o qual desde o inıcio foi desenvolvido juntamente com o banco
de dados).
A integracao ocorreu apenas no final, quando houve a certeza de como cada
parte do sistema funciona, como por exemplo, como cada sensor se comunica com o
microcontrolador para obter os resultados desejados, quanta corrente consome, quanto
tempo leva para converter os dados e quais as dificuldades de uso de cada um. Sendo
assim, pode-se dizer que o projeto foi desenvolvido sobre a arquitetura bottom-up, onde
as folhas de uma arvore foram desenvolvidas primeiro, antes de serem ligadas aos seus
respectivos ramos e galhos e, consequentemente, a arvore como um todo.
Nesta secao sera apresentada como foi feita a integracao de todo o sistema embar-
cado, ou seja, a integracao entre os sensores, microcontrolador e modulo de comunicacao.
6.4.1 Sensores
A variedade de sensores levou a necessidade de um estudo aprofundado do micro-
controlador, ja que praticamente cada sensor utiliza uma interface diferente para trans-
missao dos dados: para os dois sensores de gas foi necessaria a utilizacao de conversores
analogico-digital; para o sensor de luz foi utilizada a interface I2C; o sensor de tempe-
ratura utiliza da 1-wire e, para finalizar, para o sensor de umidade foi utilizada apenas
uma interrupcao externa como contador.
80
Felizmente, todas as interfaces necessarias para conectar os sensores ja estavam
disponıveis no microcontrolador em pinos especıficos, nao sendo necessario o desenvol-
vimento de nenhum projeto eletronico adicional, como por exemplo, a utilizacao de um
circuito integrado com funcao de conversor analogico-digital.
Apos os resultados positivos do funcionamento de cada sensor separadamente, a
integracao dos circuitos pode ser feita facilmente, tendo apenas uma atencao maior para
o consumo de corrente total, ja que no momento em que todos estao em sua fase de maior
consumo a corrente total necessaria e de aproximadamente 1A.
Por causa deste valor, a equipe separou os sensores em tres grupos que sao contro-
lados (ligados e/ou desligados) por chaves eletronicas, sendo o primeiro grupo composto
pelos sensores de umidade, luz e temperatura, outro grupo composto apenas pelo sensor
de monoxido de carbono e outro apenas pelo sensor de gases volateis. A separacao foi feita
desta forma pois o primeiro grupo abrange os sensores com menor consumo, podendo uti-
lizar um transistor mais simples como o BC556; ja os outros dois grupos possuem apenas
um sensor cada pois sao os que mais consomem, sendo necessario utilizar um transistor
de potencia como o TIP32 para controla-los.
No apendice B e apresentado o esquematico eletronico da disposicao dos sensores
e suas respectivas chaves.
As interfaces utilizadas para o sensor de temperatura (1-wire) e para o sensor de
umidade nao sao interfaces padroes (com um comportamento fixo para todos componentes
que utilizam esta interface), com isso foi necessario utilizar pinos GPIO (General Purpose
Input/Output) para a implementacao dos mesmos.
No que se trata a integracao no software embarcado dos sensores, foi utilizada a
tecnica mais simples: leitura sequencial de cada um deles, ou seja, em nenhum momento
mais de um sensor estara sendo monitorado pelo microcontrolador ao mesmo tempo. Se
um sensor leva um segundo para fazer a conversao do seu resultado para ser transmi-
tido, entao o microcontrolador ficara este segundo aguardando o recebimento do dado,
consequentemente, os demais sensores ficarao inativos por este perıodo de tempo.
Este metodo foi adotado pela simplicidade de implementacao e para evitar que a
corrente requerida pelos sensores a bateria seja muito alta, mesmo que em um perıodo de
tempo curto. Apesar da perda de desempenho neste metodo, visto que o microcontrolador
ficara ocioso na espera do resultado de cada sensor, como a duracao bateria e um fator de
81
grande importancia em sistemas embarcados, optou-se pela sua economia visando diminuir
a frequencia de recarga da bateria, o que reduz tambem a frequencia da necessidade de
interacao humana com a EMR, fator tambem importante nesse projeto.
6.4.2 Modulo de comunicacao GM862-GPS
O modulo de comunicacao foi ligado ao microcontrolador atraves da interface se-
rial UART (Universal Asynchronous Receiver/Transmitter), a qual ja possuıa pinos e re-
gistradores especıficos no microcontrolador, facilitando a sua utilizacao e a implementacao
das tarefas necessarias para tal comunicacao com o modulo. Este ultimo tambem dispunha
de um controle de fluxo por hardware, sendo estes os sinais CTS/RTS (Clear to Send/Re-
quest to Send), os quais nao foram utilizados ja que sua utilizacao e de grande importancia
para transmissao de pacotes de dados em tempo real, como no caso de chamadas de voz,
mas desnecessaria no escopo deste projeto.
Apenas tres pinos foram necessarios para fazer a comunicacao entre o microcon-
trolador e o modulo de comunicacao GM862-GPS, sendo estes os pinos de RX, TX da
comunicacao serial UART e um pino para controle de energia (ligar e desligar) do modulo.
No apendice A esta apresentado o esquematico eletronico de acoplamento do
modulo ao microcontrolador, porem, e possıvel observar tambem em quais pinos do micro-
controlador os sensores foram acoplados, em outras palavras, neste esquematico e possıvel
ver a disposicao de todos os pinos do microcontrolador utilizados, para os diversos obje-
tivos.
A separacao da alimentacao tambem foi necessaria pois o microcontrolador deve
ser alimentado ou com 5V ou com 3.3V dependendo qual pino sera utilizado para essa
finalidade, ja o modulo de comunicacao trabalha com no maximo 4.2V e no mınimo 3.6V ,
sendo assim, foi optado por utilizar 5V para o microcontrolador e 3.8V para o modulo
de comunicacao, sendo necessaria a utilizacao de dois novos reguladores de tensao, como
pode ser visto no mesmo esquematico do apendice A.
6.4.3 Placa de circuito impresso
A integracao de todas as partes do sistema embarcado resultou em um projeto
para a placa de circuito impresso como a do apendice C, a qual foi confeccionada pelos
proprios integrantes da equipe.
82
7 — Estacao Base
Neste capıtulo estarao descritos itens referentes a execucao dos software da Estacao
Base, esta e composta por tres partes: o banco de dados, o website e o daemon de co-
municacao com a EMR. Desta forma nesta secao estarao descritos apenas a execucao e
o planejamento referentes ao website e ao banco de dados, o daemon sera explicado no
capıtulo de Comunicacao (8.2).
7.1 Casos de Uso do website
Casos de uso ajudam a verificar quais sao os requisitos do sistema e como resolve-
los, entao para os requisitos do website foram propostos os seguintes casos de uso:
1. Consultar dados antigos;
2. Plotar Graficos de dados selecionados;
3. Visualizar dados atraves de uma mapa;
4. Remover EMR;
5. Adicionar/Remover Administrador;
6. Trocar Frequencia da EMR;
7. Listar Administradores;
8. Logar-se;
9. Listar EMRs;
83
Fonte: Autoria Propria
Figura 7.1: Casos de Uso do Website
7.1.1 Atores
Para o Website sao os seguintes atores:
84
• Usuario: usuario comum do Website que tem acesso as areas mais basicas, como
verificar dados antigos, plotar graficos destes dados;
• Administrador: usuario mais avancado que tem acesso por senha e pode realizar
acoes a mais do que as disponibilizadas para o Usuario, como mudar a frequencia
de certa EMR e o cadastrado de uma nova EMR, tem acesso protegido por senha;
• Banco de dados: ator que representa o software banco de dados onde estao as
informacoes das posicoes das EMR e os dados adquiridos por cada estacao.
7.1.2 Especificacao dos casos de uso
Fonte: Autoria Propria
Figura 7.2: Diagrama de Caso de Uso do Website - Consultar Dados Antigos
Nome do Caso de Uso: Consultar Dados Antigos.
Ator Principal: Usuario, Administrador.
Ator Secundario: Banco de Dados.
85
Descricao: Usuario ou Administrador acessa o site e pode verificar dados ad-
quiridos anteriormente pela estacao remota;
Pre-Condicoes: Que o banco de dados contenha dados adquiridos anterior-
mente;
Pos-Condicoes: Nao ha;
Fluxo Basico:
1. Usuario ou administrador acessa o WebSite;
2. Usuario clica no botao responsavel por fornecer o dados antigos;
3. O Website ira acessar o banco de dados e mostrar em uma lista os dados disponıveis;
4. O usuario podera ordenar essa lista por data, ID da estacao, ou pela informacao
desejada (Luz, Temperatura, CO, etc).
5. O Sistema fornece uma lista como os dados requisitados pelo usuario;
Fluxo Alternativo:
• O usuario pode a qualquer momento fechar o Browser de acesso;
Regras do Negocio: Nao ha;
86
Fonte: Autoria Propria
Figura 7.3: Diagrama de Caso de Uso do Website - Plotar Graficos
Nome do Caso de Uso: Plotar grafico dos dados selecionados;
Ator Principal: Usuario, Administrador;
Ator Secundario: Banco de Dados;
Descricao: Usuario ou Administrador acessa o site e pode plotar dados em
graficos com o criterios por ele escolhidos;
Pre-Condicoes: Que o banco de dados contenha ao menos um dado da estacao
remota disponıvel;
Pos-Condicoes: Nao ha;
Fluxo Basico:
1. Usuario ou administrador acessa o WebSite;
2. Usuario clica no botao responsavel por desenhar os dados.
3. O WebSite ira acessar o banco de dados e mostrar em uma lista os dados disponıveis
para serem plotados.
87
4. E o usuario devera escolher no mınimo tres para sem plotados;
5. Usuario seleciona os dados desejados;
6. O sistema plota o grafico e apresenta-o para o usuario;
Fluxo Alternativo:
• O usuario pode a qualquer momento fechar o Browser de aesso;
Regras do Negocio: Nao ha;
Fonte: Autoria Propria
Figura 7.4: Diagrama de Caso de Uso do Website - Visualizar Dados em um Mapa
Nome do Caso de Uso: Visualizar dados atraves de um mapa;
Ator Principal: Usuario, Administrador;
Ator Secundario: Nao ha;
Descricao: O usuario podera consultar em uma mapa a posicao e a ultima
atualizacao dos valores da estacao;
Pre-Condicoes: Ter alguma estacao cadastrada e com algum dado disponıvel;
88
Pos-Condicoes: Nao ha;
Fluxo Basico:
1. Usuario Acessa ao Website;
2. O Usuario localiza o mapa;
3. O Usuario pode verificar no mapa a posicao das estacoes remotas e sua ultima
atualizacao;
Fluxo Alternativo:
• O usuario pode a qualquer momento fechar o Browser de acesso;
Regras do Negocio: Nao ha;
Fonte: Autoria Propria
Figura 7.5: Diagrama de Caso de Uso do Website - Remover EMR
Nome do Caso de Uso: Remover estacao remota;
Ator Principal: Administrador;
Ator Secundario: Banco de dados;
89
Descricao: O administrador, verificado por login e senha, pode remover uma
EMR e todos os seus dados presentes no bancos, mas nao pode desativar uma EMR
especıfica;
Pre-Condicoes: Ter um administrador cadastrado, e verificado por login e se-
nha;
Pos-Condicoes: Verificar se a estacao foi corretamente removida;
Fluxo Basico:
1. Usuario Acessa ao Website;
2. O usuario clica no botao de realizar login;
3. O usuario faz o login e transformar-se e um administrador;
4. O administrador clica e um botao antes nao presente de remover uma nova estacao;
5. O administrador escolhe a EMR que tera seus dados removidos.
6. O sistema pede uma confirmacao do administrador.
7. O sistema excluı todos os dados desta EMR do banco de dados.
Fluxo Alternativo:
• O administrador pode a qualquer momento cancelar a remocao de uma estacao
remota antes de confirmar ao administrador;
• O administrador pode a qualquer momento fechar o Browser de acesso;
Regras do Negocio: Nao ha;
90
Fonte: Autoria Propria
Figura 7.6: Diagrama de Caso de Uso do Website - Mudar Frequencia
Nome do Caso de Uso: Mudar a frequencia de aquisicao de dados;
Ator Principal: Administrador;
Ator Secundario: Banco de dados;
Descricao: O administrador, verificado por login e senha, pode modificar a
frequencia em que a estacao remota adquire e envia os dados;
Pre-Condicoes: Ter um administrador cadastrado, e verificado por login e senha
e uma estacao remota cadastrada;
Pos-Condicoes: Verificar se a frequencia foi modificada corretamente;
Fluxo Basico:
1. Usuario Acessa ao Website;
2. O usuario clica no botao de realizar login;
3. O usuario faz o login e transformar-se e um administrador;
4. O administrador clica e um botao antes nao presente de modificar a frequencia de
aquisicao de dados da estacao remota;
91
5. Na nova janela que ira aparecer o administrador informa o ID da estacao remota e
a frequencia, em minutos, desejada;
6. O Website modifica a tabela responsavel pela comunicacao entre o Website e Dae-
mon com os valores informados pelo usuario.
Fluxo Alternativo:
• O administrador pode a qualquer momento, antes do item 6, cancelar a mudanca
de frequencia;
Regras do Negocio: Nao ha;
Fonte: Autoria Propria
Figura 7.7: Diagrama de Caso de Uso do Website - Logar-se
Nome do Caso de Uso: Logar-se.
Ator Principal: Cliente, Administrador;
Ator Secundario: Banco de Dados.
Descricao: A verificacao do cadastro do usuario para verificar se o mesmo pode
ter permissoes de administrador;
92
Pre-Condicoes: Nao ha;
Pos-Condicoes: Informa se o usuario conseguiu acessou de administrador ou
nao;
Fluxo Basico:
1. Usuario Acessa ao Website;
2. O usuario clica no botao de realizar login;
3. O usuario faz o login digita sua senha e nome de acesso;
4. O sistema verifica no banco de dados se ha algum administrador como informado;
5. O usuario recebe permissoes de administrador;
Fluxo Alternativo:
• O sistema informa se a senha ou nome de acesso estao incorretos;
Regras do Negocio: os caracteres de digitar a senha deverao ser escondidos;
Fonte: Autoria Propria
Figura 7.8: Diagrama de Caso de Uso do Website - Listar EMRs
93
Nome do Caso de Uso: Listar EMRs.
Ator Principal: Cliente, Administrador;
Ator Secundario: Banco de Dados.
Descricao: Listar todos as EMRs cadastradas e sua frequencia de aquisicao de
dados;
Pre-Condicoes: Ter alguma EMR cadastrada e em funcionamento;
Pos-Condicoes: Nao Ha;
Fluxo Basico:
1. Usuario Acessa ao Website;
2. O usuario vai na opcao de listar EMRs;
3. O sistema faz uma consulta ao banco de dados;
4. O sistema adquire os valores do banco de dados;
5. O sistema preenche uma tabela para informar ao usuario;
Fluxo Alternativo:
• O sistema informa se nao ha nenhuma EMR cadastrada;
Regras do Negocio: Nao ha;
94
Fonte: Autoria Propria
Figura 7.9: Diagrama de Caso de Uso do Website - Listar Administradores
Nome do Caso de Uso: Listar Administradores.
Ator Principal: Administrador;
Ator Secundario: Banco de Dados.
Descricao: A consulta ao banco de dados para verificar administradores estao
cadastrados ao sistema.
Pre-Condicoes: Ter um administrador cadastrado;
Pos-Condicoes: Nao ha;
Fluxo Basico:
1. Usuario Acessa ao Website;
2. O usuario clica no botao de realizar login;
3. O usuario faz o login digita sua senha e nome de acesso;
4. O sistema verifica no banco de dados se ha algum administrador como informado;
5. O usuario recebe permissoes de administrador;
6. O Administrar acessa a opcao de listar administradores;
95
7. O sistema faz uma consulta ao banco de dados;
8. O sistema adquire do banco os administradores cadastrados;
9. O sistema preenche uma tabela com os administradores;
Fluxo Alternativo:
• O sistema informa se a senha ou nome de acesso estao incorretos;
• O sistema informa se nao ha nenhum admnistrador cadastrado;
Regras do Negocio: Nao ha;
Fonte: Autoria Propria
Figura 7.10: Diagrama de Caso de Uso do Website - Remover/Adicionar Administradores
Nome do Caso de Uso: Remover/Adicionar Administradores.
Ator Principal: Administrador;
Ator Secundario: Banco de Dados.
Descricao: A remocao ou adicao de um administrador do sistema.
Pre-Condicoes: Ter um administrador cadastrado, para remocao;
Pos-Condicoes: Confirmar adicao ou remocao;
Fluxo Basico:
96
1. Usuario Acessa ao Website;
2. O usuario clica no botao de realizar login;
3. O usuario faz o login digita sua senha e nome de acesso;
4. O sistema verifica no banco de dados se ha algum administrador como informado;
5. O usuario recebe permissoes de administrador;
6. O administrar acessa a opcao de listar administradores;
7. O sistema faz uma consulta ao banco de dados;
8. O sistema adquire do banco os administradores cadastrados;
9. O sistema preenche uma tabela com os administradores;
10. O administrador escolhe se quer adicionar/remover um administrador. Caso adici-
onar o administrar devera informar um nome e senha. Caso remover apenas devera
selecionar um na lista.
11. O administrador informa o requisitado pelo sistema.
12. O sistema entre em contato com o banco de dados e remover/adiciona um adminis-
trador.
13. o sistema apresenta uma mensagem de confirmacao ao administrador.
Fluxo Alternativo:
• O sistema informa se a senha ou nome de acesso estao incorretos;
• O sistema informa se nao ha nenhum admnistrador cadastrado;
Regras do Negocio: Nao ha;
97
7.1.3 Diagrama de Atividades Website
Nesta secao e mostrado como fuciona o fluxo da atividades para as opcoes pre-
sentes no Website.
Fonte: Autoria Propria
Figura 7.11: Diagrama de Atividades do Website - Opcoes
Devido ao tamanho optou-se pela divisao dos diagramas, na figura 7.11 pode ser
visto as opcoes iniciais que o usuario tem ao abrir a pagina do Website. As Opcoes abaixo
de Logar-se so estao disponıveis apos realizar a atividade de mesmo nome.
Nas figuras abaixo, 7.12, 7.13, 7.14, 7.15, 7.16, 7.17 e 7.18 pode ser visto o fluxo
de processos para cada uma das opcoes disponıveis para o Website.
98
Fonte: Autoria Propria
Figura 7.12: Diagrama de Atividades do Website - Logar-se
99
Fonte: Autoria Propria
Figura 7.13: Diagrama de Atividades do Website - Exibir Informacoes em um Mapa
100
Fonte: Autoria Propria
Figura 7.14: Diagrama de Atividades do Website - Consultar Dados Antigos
101
Fonte: Autoria Propria
Figura 7.15: Diagrama de Atividades do Website - Plotar Graficos
102
Fonte: Autoria Propria
Figura 7.16: Diagrama de Atividades do Website - Mudar Frequencia EMR
103
Fonte: Autoria Propria
Figura 7.17: Diagrama de Atividades do Website - Remover EMR
104
Fonte: Autoria Propria
Figura 7.18: Diagrama de Atividades do Website - Opcoes para Administrador
105
7.2 Banco de Dados
7.2.1 Diagrama entidade-relacionamento do banco de dados
Fonte: Autoria Propria
Figura 7.19: Diagrama ER
7.2.2 Dicionario de informacoes: Tabela Administradores
Nessa tabela fica registrado o login e senha de todos os administradores do website.
106
Nome Descricao Tipo Tamanho Domınio Formato Restricoes
idAdministradores Codigo que
identifica o
Administra-
dor. Codigo
unico e auto
incrementado
a cada nova
insercao.
inteiro - - - -
login Nome do
usuario
texto 45 - Apenas letras
e numeros.
Sem espaco e
simbolos
Deve ser
unico na
tabela
senha Hash MD5
da senha do
usuario
texto 32 - -
Tabela 7.1: Dicionario de dados da Tabela Administradores
7.2.3 Dicionario de informacoes: Tabela EMR
Nessa tabela ficam registradas todas as EMRs que se comunicarem com o daemon.
107
Nome Descricao Tipo Tamanho Domınio Formato Restricoes
idEmr Codigo que
identifica a
EMR. Codigo
unico e auto
incrementado
a cada nova
insercao.
inteiro - - - -
frequencia Valor, em mi-
nutos, do in-
tervalo entre
cada envio de
dados.
inteiro - - - De 5 a
1440(24hrs)
ip Endereco IP
da EMR
texto 15 - 255.255.255.255 Deve ser
um en-
dereco IP
valido
data atualizacao Data da
ultima atua-
lizacao feita
pela EMR
datetime - - YYYY-MM-DD
HH:MM:SS
Deve ser
uma data
valida
Tabela 7.2: Dicionario de dados da Tabela EMR
7.2.4 Dicionario de informacoes: Tabela Dados
Nessa tabela ficam registrados todos os dados adquiridos das EMRs.
108
Nome Descricao Tipo Tamanho Domınio Formato Restricoes
idDados Codigo que
identifica o
dado adqui-
rido. Codigo
unico e auto
incrementado
a cada nova
insercao.
inteiro - - - -
idEMR Codigo que
relaciona a
leitura adqui-
rida a uma
unica EMR.
inteiro - EMR - Deve exis-
tir na ta-
bela EMR
data leitura Data em que
a leitura foi
registrada.
datetime - - YYYY-MM-
DD
HH:MM:SS
Deve ser
uma data
valida
latitude Latitude em
que a leitura
foi realizada.
inteiro - - - Deve estar
entre -180
e +180
longitude Longitude em
que a leitura
foi realizada.
inteiro - - - Deve estar
entre -180
e +180
co Valor da
quantidade
de CO lido.
inteiro - - -
voc Valor da
quantidade
de VOC lido.
inteiro - - -
temp Temperatura
lida
inteiro. - - -
umidade Umidade re-
lativa lida.
inteiro - - -
luz Quantidade
de luminosi-
dade lida.
inteiro - - -
Tabela 7.3: Dicionario de dados da Tabela Dados
109
7.2.5 Dicionario de informacoes: Tabela Queue
Nessa tabela esta armazenada a fila de pacotes que o daemon devera enviar as
EMRs.
Nome Descricao Tipo Tamanho Domınio Formato Restricoes
idQueue Codigo que
identifica
o item a
ser enviado.
Codigo unico
e auto in-
crementado
a cada nova
insercao.
inteiro - - - -
idEMR Codigo que
indica a qual
EMR devera
ser enviado o
item.
inteiro - EMR - Deve exis-
tir na ta-
bela EMR
data inclusao Data em que
a item foi in-
cluido na fila.
datetime - - YYYY-MM-DD
HH:MM:SS
Deve ser
uma data
valida
comando Comando que
devera ser en-
viado a EMR
texto 15 - 255.255.255.255 Deve ser
um en-
dereco IP
valido
dado Dado que
complementa
o comando
inteiro - - - -
Tabela 7.4: Dicionario de dados da Tabela Queue
7.3 Google Chart
Para cumprir um dos requisitos propostos do website, plotar graficos, foi escolhido
o Google Charts. O Google Charts e uma poderosa ferramenta de desenvolvimento em
JavaScript para criacao de diversos tipos de graficos e que sao facilmente implementados
110
em paginas HTML, proporcionando uma excelente apresentacao visual nao requerendo
instalacao de componentes adicionais, uma vez que todas informacoes sao processadas
pelo proprio Google.
7.3.1 Dependencias
Utilizando a API do Google nao se faz necessario o uso de outras bibliotecas, pois
ao incluir o script todas as bibliotecas necessarias ja sao incorporadas, bastando que o
cliente tenha acesso ao Google para que os graficos funcionem.
7.3.2 Implementacao
Ha tres formas de gerar os graficos:
• via URL, onde e passado todos os parametros via GET e e retornado uma imagem
com o grafico;
• atraves de bibliotecas externas opensource;
• usar da propria API do Google e suas respectivas funcoes.
A forma escolhida foi a terceira, por possuir boa documentacao e ser de facil im-
plementacao (usando diretamente os recursos do proprio Google). Para a implementacao
dessa forma deve-se inserir dentro do cabecalho head do codigo-fonte o endereco do script
que carrega as bibliotecas e as inicializa. Um exemplo pode ser visto no Codigo 7.1.
Codigo 7.1: Inicializacao Google Chart
1 <head>
2 <title>Pagina de teste</title>
3 <script type=”text/javascript” src=”http://www.google.com/jsapi”></script>
4 <script type=”text/javascript”>
5 google.load(’ visualization ’, ’1’, packages: [’ corechart ’]);
6 </script>
7 </head>
Os dados que sao apresentados nos graficos podem ser definidos por diversas
formas, como:
• Array: como exemplo apresentado no Codigo 7.2;
111
• Google Drive: como exemplo apresentado no Codigo 7.3;
• JSON: ou como exemplo apresentado no Codigo 7.4
Codigo 7.2: Array contendo valores para o grafico
1 var data = google.visualization .arrayToDataTable([
2 [’ Year’, ’Austria ’, ’Belgium’, ’Czech Republic’, ’Finland’, ’France’, ’Germany’],
3 [’2003’, 1336060, 3817614, 974066, 1104797, 6651824, 15727003],
4 [’2004’, 1538156, 3968305, 928875, 1151983, 5940129, 17356071],
5 [’2005’, 1576579, 4063225, 1063414, 1156441, 5714009, 16716049],
6 [’2006’, 1600652, 4604684, 940478, 1167979, 6190532, 18542843],
7 [’2007’, 1968113, 4013653, 1037079, 1207029, 6420270, 19564053],
8 [’2008’, 1901067, 6792087, 1037327, 1284795, 6240921, 19830493]]);
Codigo 7.3: Valores provenientes de uma planilha do Google Drive
1 var query = new google.visualization.Query(
2 ’http://spreadsheets.google.com/tq?key=pCQbetdCptGXxxQIG7VFIQ&range=B1:D11&pub=1’);
Codigo 7.4: Valores contidos em uma estrutura de dados do JSON
1 var JSONObject =
2 cols : [ id : ’task ’, label : ’Task’, type: ’ string ’,
3 id: ’hours’, label : ’Hours per Day’, type: ’number’],
4 rows: [c :[v: ’Work’, p: ’ style ’: ’border: 7px solid orange ;’, v: 11],
5 c :[v: ’Eat’, v: 2],
6 c :[v: ’Commute’, v: 2, f: ’2.000’]];
7 var data = new google.visualization.DataTable(JSONObject, 0.5);
Utilizando esta API do Google e possıvel gerar diversos tipos de graficos, como
por exemplo: area, barras horizontais e verticais, bolhas, geologia, pizza, entre outros.
7.4 Google Maps
Outro requisito e informar dados em um mapa, para cumprir este requisito foi
escolhia a API Google Maps. A API do Google Maps, tambem desenvolvida em JavaS-
cript, permite incorporar o Google Maps em paginas da web. A Versao 3 desta API foi
desenvolvida para ser mais rapida e mais aplicavel aos dispositivos moveis, bem como aos
aplicativos de navegadores desktop tradicionais.
112
Esta API oferece diversos utilitarios para manipulacao de mapas (as mesmas
oferecidas no site oficial do Google Maps (Google, 2013)) e para a adicao de conteudo ao
mapa por meio de diversos servicos, o que permite criar robustos aplicativos que envolvem
mapas.
7.4.1 Dependencias
O funcionamento desta API e igual ao funcionamento do Google Charts apresen-
tado anteriormente na Secao 7.3, ou seja, utilizando esta nao se faz necessario o uso de
outras bibliotecas, pois ao incluir o script todas as bibliotecas necessarias ja sao incorpo-
radas, bastando que o cliente tenha acesso ao Google para que os mapas funcionem.
7.4.2 Implementacao
O uso do Google Maps no website funciona de forma bem semelhante ao Google
Charts: deve ser feita uma chamada no corpo do cabecalho header para incorporar as
funcoes da API de mapas e a partir disso executar funcoes para carregar e configurar o
mapa com caracterısticas personalizadas, como pode ser visto no Codigo 7.5.
Codigo 7.5: Implementacao exemplo do Google Maps
1 <head>
2 <title>Pagina de teste</title>
3 <script src=”https://maps.googleapis.com/maps/api/js?v=3.exp&sensor=false”></script>
4 <script>
5 var map;
6 function initialize ()
7 var mapOptions =
8 zoom: 8,
9 center : new google.maps.LatLng(−25.43896, −49.2688),
10 mapTypeId: google.maps.MapTypeId.ROADMAP
11 ;
12 map = new google.maps.Map(document.getElementById(’mapcanvas’), mapOptions);
13
14 google.maps.event.addDomListener(window, ’load’, initialize);
15 </script>
16 </head>
113
7.5 Apache
Para a manuntecao do servidor e compilacao do PHP foi escolhido o Servidor
Apache.
7.5.1 Instalacao
A instalacao do servidor web foi feita em um computador rodando o sistema
Linux, conforme havia sido definido na analise tecnologica no plano do projeto e a distri-
buicao escolhida foi a Ubuntu 12.04 LTS.
A instalacao e/ou atualizacao dos pacotes necessarios para estabelecer um ser-
vidor seguro e confiavel foi feita atraves do gerenciador de pacotes padrao do Ubuntu
(tambem utilizado em outras distribuicoes). Na lista de Codigos 7.6 estao presentes os
comandos executados pelo administrador do servidor para instalar os pacotes no terminal
de comandos.
Codigo 7.6: Instalacao dos pacotes para Apache, PHP e MySQL
1 # apt−get install apache2
2 # apt−get install php5 libapache2−mod−php5
3 # apt−get install mysql−server libapache2−mod−auth−mysql php5−mysql
7.5.2 Configuracao
Para o projeto, foi adquirido o domınio online “oficinas3.tk” e depois o Apache
foi configurado para tratar os pedidos desse domınio atraves do mecanismo de Virtual Host
(Foundation, 2013), pois a utilizacao do Apache com Virtual Host possibilita hospedar
mais de um website em um mesmo servidor. Sua configuracao esta presente na lista de
Codigos 7.7
O servidor utilizado neste projeto deve ser aberto a conexoes externas a sua
LAN, porem, como o endereco do mesmo nao e fixo foi necessario instalar e configurar
um servidor DNS, sendo escolhido o programa BIND9 (BIND9, 2013). Sua configuracao
pode ser vista em Codigo 7.8.
Codigo 7.7: Configuracao Apache
1 <VirtualHost ∗:80>
114
2 ServerAdmin webmaster@localhost
3 ServerName oficinas3.tk
4 ServerAlias ∗. oficinas3 .tk
5
6 DocumentRoot /var/sites/oficinas3.tk/www
7
8 <Directory /var/sites/oficinas3 .tk/www>
9 Options Indexes FollowSymLinks MultiViews
10 AllowOverride None
11 Order allow,deny
12 allow from all
13 </Directory>
14
15 ErrorLog APACHE LOG DIR/error.log
16
17 # Possible values include: debug, info , notice , warn, error , crit ,
18 # alert, emerg.
19 LogLevel warn
20
21 CustomLog APACHE LOG DIR/access.log combined
22 </VirtualHost>
Codigo 7.8: Configuracao BIND9
1 ORIGIN .
2 TTL 600 ; 10 minutes
3 oficinas3 .tk IN SOA tiagoaveiro.noip.com. tiaveiro.gmail.com. (
4 2013071614 ; serial
5 600 ; refresh (10 minutes)
6 300 ; retry (5 minutes)
7 604800 ; expire (1 week)
8 600 ; minimum (10 minutes)
9 )
10 NS tiagoaveiro.noip.com.
11 TTL 50 ; 50 seconds
12 A 177.204.58.242
13 ORIGIN oficinas3.tk.
14 svn A 177.204.58.242
15 www A 177.204.58.242
115
Para o PHP foram mudadas poucas configuracoes padroes, as quais podem ser
observadas na lista de Codigos 7.9
Codigo 7.9: Configuracao PHP
1 short open tag = On
2 safe mode = Off
3 error reporting = E ALL & ˜E DEPRECATED
4 register globals = Off
7.6 Interface do usuario (Website)
Nesta secao esta apresentada a versao final do layout do Website, pelas imagens
e possıvel verificar que o mesmo encontra-se disponıvel no site utilizado para a realizacao
deste projeto.
Fonte: Autoria Propria
Figura 7.20: Tela Inicial do Website
Na tela 7.20 e a tela inicial do Website, nela pode ser verificado o mapa contendo
a posicao das EMRs em funcionamento e sua ultima atualizacao de valores. O mesmo
acontece na tabela abaixo do mapa, nela ainda e possıvel verificar longitude e a latitude,
que no mapa e marcado pela posicao da EMR.
A tela 7.21 contem as opcoes de consulta de dados das EMRs e a opcao de
plotar os graficos. Apos selecionar o botao presente na pagina pode ser visto a tela 7.22,
116
Fonte: Autoria Propria
Figura 7.21: Tela Consulta do Website 1
Fonte: Autoria Propria
Figura 7.22: Tela Consulta do Website 2
117
onde podera ser escolhido um perıodo de amostragem e as EMRs a serem pesquisadas,
possiblitando a pesquisa de varias EMRs no mesmo perıdo. A tela 7.21 ainda apresenta
um grafico de uma consulta ja realizada.
Fonte: Autoria Propria
Figura 7.23: Tela Configuracoes do Website
A opcao configuracao, tela 7.23, inicia com a necessidade de login, deste modo
usuarios cadastrados podem acessar este menu. Se o usuario digitar um login incorreto,
aparecera ao mesmo uma mensagem de erro. Se o login for digitado corretamente o
usuario podera acessar as opcoes do menu configuracoes, que sao: adicionar novos ad-
ministradores, excluir os atuais, listar as EMRs com sua frequencia de aquisicao, alterar
essa frequencia das EMRs e excluir todo o conteudo do site e do banco de dados de uma
EMR especıfica.
Fonte: Autoria Propria
Figura 7.24: Tela Configuracoes do Usuario do Website
Apos a tela login, e apresentada ao usuario a tela 7.24, onde usuarios adminis-
118
tradores podem ser removidos e adicionados. E desta tela o usuario podera acessar a tela
7.25, onde podera remover todos os conteudos das EMRs, assim esta EMR sera excluıda
do mapa e das consultas. Ao clicar no botao alteracao, sera apresentada a tela 7.26 onde
a frequencia de aquisicao de dados da EMR especıfica podera ser alterada.
Fonte: Autoria Propria
Figura 7.25: Tela com a Lista de EMR do Website
Fonte: Autoria Propria
Figura 7.26: Tela Alterar da EMR do Website
119
8 — Sistema de Comunicacao
Como sistema de comunicacao pode ser entendido como todo componente que
efetua direta ou indiretamente a comunicacao entre a estacao base e a estacao remota, ou
seja, todas sequencias de instrucao (programas) que envolvem a troca de dados entre as
duas estacao, faz parte do sistema de comunicacao.
Podemos dividir o sistema em dois grandes programas, um estando na estacao
base servidor e outro no sistema embarcado (software embarcado do microcontrolador
e modulo de comunicacao GPRS). Este primeiro iremos nos referir como daemon, pois
ficara o tempo todo em execucao em background no servidor, tendo o papel de captar
e enviar dados para a estacao remota; ja o segundo programa e o responsavel por fazer
todas as configuracoes necessarias, tanto no microcontrolador quanto no modulo, para a
estabelecer uma conexao estavel a rede GPRS e consequentemente a internet.
8.1 Protocolo de Comunicacao
Para obter um sistema de comunicacao que atenda os requisitos pre-estabelecidos
no Plano de Projeto na Secao 6.1.2 e necessario desenvolver um protocolo proprio, sempre
tendo em mente as solucoes para o cumprimento dos requisitos.
Como a comunicacao e bilateral (entre o sistema embarcado EMR e o daemon no
servidor), alguns cuidados devem ser tomados quanto ao controle de envio e/ou reenvio
de pacotes, assim como no tratamento de possıveis erros sobre o conteudo de cada pacote
transmitido.
Nesta secao serao apresentados os diagramas do sistema de comunicacao: de
estados e sequencia, a fim de demonstrar de forma facilitada o funcionamento deste.
8.1.1 Diagrama de Estados
Primeiramente foi desenvolvido o diagrama de estados, pelo qual e possıvel ob-
servar as acoes que serao tomadas pelos dois lados da comunicacao. O funcionamento dos
dois lados pode ser considerado identicos, ja que estes diagramas apenas irao representar o
120
lado da comunicacao do sistema embarcado e do daemon, ignorando-se qualquer interacao
com algum componente externo, como por exemplo, banco de dados e sensores.
Na Figura 8.1 contem o diagrama de estados responsavel pela transmissao de
pacotes, ja na 8.2 esta apresentado o diagrama de estados para a recepcao de pacotes em
ambos lados da comunicacao.
121
Fonte: Autoria propria
Figura 8.1: Diagrama de estados para transmissao de pacotes em ambos lados da comunicacao.
122
Fonte: Autoria propria
Figura 8.2: Diagrama de estados para recepcao de pacotes de ambos lados da comunicacao.
8.1.2 Diagrama de Sequencia
Com os diagramas de estados ja construıdos e possıvel observar a comunicacao
entre eles atraves de situacoes esbocadas pelo diagrama de sequencia, sendo tambem
possıvel demonstrar todas as situacoes possıveis para este sistema de comunicacao.
Para este documento serao apresentadas as quatro situacoes mais gerais e comuns
do sistema, sendo que algumas variacoes podem ocorrer apenas no pacote enviado, porem
a ordem e a sequencia permanecem as mesmas para todos os demais casos.
O primeiro diagrama apresentado sera o da Figura 8.3, onde a troca de pacotes
e totalmente bem sucedida em ambos lados da comunicacao. Mas observando este dia-
grama e possıvel ocorrer uma duvida sobre como funciona o envio de uma resposta de
um determinado comando enviado por um dos lados. A resposta pode ser dada a partir
de um exemplo: caso o daemon solicite uma leitura forcada dos sensores, a EMR ira
primeiramente informar que recebeu o pacote que continha a solicitacao e ira encerrar a
conexao, pois o tempo gasto para a deteccao dos sensores nao e pre-estabelecido, porem,
assim que o pacote estiver pronto o sistema embarcado ira iniciar uma nova conexao com
o daemon, seguindo o mesmo diagrama de sequencia feito anteriormente pelo daemon.
Outra questao observavel neste diagrama e a respeito do controle de sequencia
dos pacotes, em outras palavras, o ACK enviado e referente a qual pacote enviado an-
teriormente, pois caso mais de um pacote seja enviado antes do ACK no primeiro ser
123
recebido pode gerar uma confusao. A solucao utilizada pode ser observada no conteudo
interno dos pacotes no Apendice D deste documento, onde tambem contem os coman-
dos possıveis de serem executados. O campo Seq indica qual e o numero de sequencia
daquele pacote e o campo RefSeq presente nos pacotes de ACK e NACK referenciam
pelo numero de sequencia do pacote ao qual eles pertencem. Sendo assim, e possıvel que
seja enviado varios pacotes antes que qualquer ACK seja recebido.
Fonte: Autoria propria
Figura 8.3: Diagrama de sequencia bem sucedido na transmissao e recepcao de um pacote emambos lados da comunicacao.
O diagrama presente na Figura 8.4 apresenta a situacao onde o daemon passa
pelo problema de “limite de tempo de espera”, consequente da perda de comunicacao
momentanea com a EMR por motivos diversos: problema da rede GPRS, interferencia no
sinal, entre outros, porem, ao fim recebe uma resposta bem sucedida.
Caso o numero de reenvios de pacote ultrapassasse o limite de tentativas pre-
estabelecido a comunicacao seria encerrada, acarretando na perda do pacote permanen-
temente, ou seja, a perda da solicitacao de algum comando. E importante lembrar que
este comportamento vale para ambos lados da comunicacao, independente de qual lado
esteja sendo feita a transmissao.
124
Fonte: Autoria propria
Figura 8.4: Diagrama de sequencia bem sucedido com a ultrapassgem do tempo de limite deespera.
Por ultimo, na Figura 8.5 contem o diagrama que mostra o comportamento dos
componentes da comunicacao quando ha alguma falha na integridade dos dados do pacote.
Assim que esse erro e detectado, um comando NACK e enviado para o remetente do
pacote e entao o diagrama e re-executado, a fim de obter uma resposta bem sucedida.
Fonte: Autoria propria
Figura 8.5: Diagrama de sequencia mal sucedido por erro de CRC Invalido.
125
8.2 Diagrama de casos de uso do daemon
Os casos de uso do daemon, Figura 8.6, estao listados abaixo bem como sua
documentacao.
1. Mudar Frequencia;
2. Adquiscao de Dados;
3. Atualizar IP;
4. Adicionar EMR;
Fonte: Autoria propria
Figura 8.6: Diagrama de casos de uso geral do daemon.
8.2.1 Atores
Para o Daemon serao os seguintes atores:
• Banco de Dados: ator que representara o software banco de dados onde estar ao
as informacoes das posicoes das EMR e os dados adquiridos por cada estacao, alem
disso estara no banco de dados a tabela responsavel pela comunicacao entre o Web-
site e o Daemon;
126
• Sistema Embarcado: ator que representara o sistema embarcado, composto por
sensores, microcontrolador e sistema de comunicacao. Responsavel pela aquisicao
dos dados.
8.2.2 Especificacao dos casos de uso
Mudar frequencia
Fonte: Autoria propria
Figura 8.7: Diagrama de casos de uso “Mudar frequencia”.
Nome do caso de uso: Mudar Frequencia.
Ator Principal: Banco de Dados.
Ator Secundario: Sistema Embarcado.
Descricao: Daemon ira receber atraves de uma tabela no banco de dados uma
requisicao da troca de frequencia de uma determinada estacao remota, e ira mandar uma
mensagem para esta estacao com a mudanca.
Pre-Condicoes: Ter uma estacao remota e banco de dados cadastrados e em
funcionamento.
Pos-Condicoes: Confirmar atraves de uma mensagem a mudanca.
Fluxo Basico:
1. Daemon recebe do website atraves de uma tabela especial um pedido de mudanca de
frequencia, nele estara contido o ID da estacao remota e o novo valor da frequencia;
127
2. O Daemon conecta-se com a estacao remota especificada no id do item anterior;
3. Envia uma mensagem com o comando e valor da frequencia desejada;
4. Espera a resposta com a confirmacao da mudanca.
Fluxo Alternativo:
• Caso nao consiga conexao o sistema devera esperar uma oportunidade para realizar
a mudanca;
• Se o sistema nao receber a confirmacao de mudanca devera realizar uma nova ten-
tava;
Regras do Negocio: As mensagens deverao ser codificadas em um padrao.
Adicionar EMR
Fonte: Autoria propria
Figura 8.8: Diagrama de casos de uso “Adicionar EMR”.
Nome do caso de uso: Adicionar EMR.
Ator Principal: Sistema Embarcado.
Ator Secundario: Banco de dados.
Descricao: Adicao de uma nova estacao remota para a captacao de dados em
outro lugar.
128
Pre-Condicoes: Nao ha.
Pos-Condicoes: Confirmar a adicao da nova estacao remota.
Fluxo Basico:
1. Daemon fica aguardando o recebimento de pacotes;
2. Daemon se algum pacote de uma EMR nao cadastrada for recebido, o Daemon
adicionara o mesmo na tabela como uma nova EMR.
Fluxo Alternativo:
• Se o Daemon ja encontrar dados parecido da EMR desconhecida ele atualizara o IP
da mesma;
Regras do Negocio: As mensagens enviadas e recebidas deverao ter um formato
padrao.
Aquisicao de dados
Fonte: Autoria propria
Figura 8.9: Diagrama de casos de uso “Aquisicao de dados”.
Nome do caso de uso: Aquisicao de Dados.
Ator Principal: Sistema Embarcado.
Ator Secundario: Banco de Dados.
129
Descricao: A captura dos pacotes e sua separacao nos dados enviados pela EMR,
como dados de posicao e sensores.
Pre-Condicoes: Ter cadastrado ao menos uma EMR.
Pos-Condicoes: Confirmar o recebimento do pacote.
Fluxo Basico:
1. Daemon fica a espera pacotes da EMR cadastrada;
2. EMR tenta uma conexao;
3. Daemon responde e confirma a abertura de uma conexao com a EMR;
4. EMR envia pacote;
5. Daemon confirma recebimento do pacote;
6. Daemon verifica integridade do pacote;
7. Daemon aplica algoritmo, pre-definido, para segmentar o pacote nos dados corretos;
8. Daemon confirma o recebimento do pacote para a EMR;
9. Daemon conecta-se com o banco de dados;
10. Daemon salva os dados no banco de dados.
Fluxo Alternativo:
• Se nao for possıvel a abertura da conexao, sera realizada uma nova tentativa;
• Se o Daemon nao receber o pacote enviara uma mensagem a EMR requisitando um
reenvio;
• Se o pacote nao estiver integro, o Daemon requisitara um reenvio.
Regras do Negocio: Os formatos das mensagens devem ser definidos previa-
mente.
130
Fonte: Autoria propria
Figura 8.10: Diagrama de casos de uso “Atualizar IP”.
Atualizar IP
Nome do Caso de Uso: Atualizar IP.
Ator Principal: Sistema Embarcado.
Ator Secundario: Banco de Dados.
Descricao: Como a conexao do GPRS nao suporta IP fixo, a cada conexao
realizada pela EMR seu IP devera ser atualizada para que desta forma possa se comunicar
com Daemon em futuras transmissoes.
Pre-Condicoes: Ter cadastrado ao menos uma EMR.
Pos-Condicoes: Confirmar a atualizacao do IP.
Fluxo Basico:
1. Daemon fica a espera pacotes da EMR cadastrada;
2. EMR tenta uma conexao;
3. Daemon responde e confirma a abertura de uma conexao com a EMR;
4. EMR envia pacote;
5. Daemon confirma recebimento do pacote;
6. Daemon verifica integridade do pacote;
131
7. Neste pacote inicial estao presente o IP da EMR e seu ID, Daemon entao atualiza
o IP com a EMR correta;
8. Daemon conecta-se com o banco de dados;
9. Daemon atualiza os dados da EMR no banco de dados.
Fluxo Alternativo:
• Se nao for possıvel a abertura da conexao, sera realizada uma nova tentativa;
• Se o Daemon nao receber o pacote enviara uma mensagem a EMR requisitando um
reenvio;
• Se o pacote nao estiver integro, o Daemon requisitara um reenvio;
• Se a EMR nao estiver ainda cadastrada ele sera adicionada ao sistema.
Regras do Negocio: Os formatos das mensagens devem ser definidos previa-
mente.
8.3 Diagrama de atividades do daemon
No Diagrama 8.11 pode ser verificado como funcionara o daemon. O programa
sera dividido em duas partes, que estarao presentes no mesmo codigo, sendo uma res-
ponsavel pela transmissao de pacotes as EMRs e outra pelo recebimento dos pacotes e o
seu tratamento.
132
Fonte: Autoria propria
Figura 8.11: Diagrama de Atividade do Daemon - Inicial
No diagrama 8.12, mostra como sera o funcionamento da recepcao, esta sera
responsavel pela comunicacao no sentido EMR - Website, pacotes que chegam a estacao
base. Ela devera suportar um socket de conexao, onde ficara aguardando uma tentativa
de conexao. Apos alguma tentativa o daemon ira utilizar a maquina de estados proposta
pelo protocolo de comunicacao para adquirir e verificar o pacote. E apos o recebimento
gravara os dados em uma tabela especıfica no banco de dados.
133
Fonte: Autoria propria
Figura 8.12: Diagrama de Atividades do Daemon - Recepcao
informações
134
Fonte: Autoria propria
Figura 8.13: Diagrama de Atividades do Daemon - Transmissao
comandos
135
No diagrama 8.13, uma segunda parte sera responsavel pela comunicacao no sen-
tido inverso ao da primeira, ou seja, sera responsavel pelo sentido estacao-base para sis-
tema embarcado. Esta parte tera um timer pre-definido e ficara realizando suas operacoes
e so retornando quando o timer estourar sua contagem. Quando acordar checara uma
tabela especial que contera mudancas requisitadas por um Administrador no website ao
sistema embarcado. Apos isso fara uso da maquina de estados do protocolo de comu-
nicacao responsavel pela transmissao para enviar o pacote a EMR. Entao depois marcara
o comando da tabela como utilizado e verificara se ha mais comandos na tabela, se houver
ela ira repetir o processo de transmissao, e se nao houver mais comando a serem enviados,
o timer zera sua contagem.
Apesar de separadas ambas as partes sao indissociaveis no codigo do daemon.
8.4 Programacao Daemon
Nesta secao estarao descritos os metodos e funcoes necessarios para a criacao do
Daemon.
8.4.1 Sockets
Para as conexoes do daemon sera utilizada a criacao de Sockets, que possibilita
a conexao entrada e saıda e cumpre os requisitos necessarios ao projeto. Em C ha a
possibilidade de criacao de Sockets baseados em TCP ou UDP, para o projeto foi escolhida
a opcao de UDP, pois possibilita a utilizacao de pacotes menores e uma conexao mais
simples. Para o enderecamento faz-se uso de uma struct com a seguinte forma:
Codigo 8.1: Struct Enderecamento Socket.
1 struct sockaddr in
2 short int sin family ;
3 unsigned short int sin port;
4 struct in addr sin addr;
5
• short int sin family: Indica que tipo de famılia do protocolo sera utilizado, valor
padrao AF INET;
136
• unsigned short int sin port: indica a porta que sera utilizada para a comunicacao
entre os processos. Para a definicao da porta e necessario mudar o valor da variavel
ou constante que sera utilizada para uma variavel de rede da seguinte maneira:
htons(SERVER PORT), onde SERVER PORT e a porta definida para realizar a
comunicacao.
• Struct in addr sin addr: define o ip da maquina de destino. Como o servidor
aguardara uma conexao, seu valor devera receber a constante INADDR ANY. Para
o cliente sera utilizado o seguinte metodo: gethostbyname(), onde recebe como
parametro um endereco id, no caso do projeto recebera o id da estacao remota.
Alem da estrutura de enderecamento apresentada acima e necessaria a utilizacao
de alguns metodos para a criacao do socket propriamente dito e o envio de pacotes. Todos
os metodos da biblioteca padrao de criacao de Sockets retornam um valor negativo em
caso de erro, possibilitando a verificacao de erros na sua utilizacao. A funcao basica de
criacao do socket esta descrita abaixo:
Codigo 8.2: Criacao do Socket.
1 int socket(int family, int type, int protocol );
• int Family: indica a famılia de protocolos que sera utilizada, neste caso AF INET;
• int type: define o tipo de socket a ser criado, UDP ou TCP. Para TCP passar o
parametro SOCK STREAM, e para UDP SOCK DGRAM;
• int protocol: identifica o protocolo a ser utilizado. Recebe 0, pois os parametros
anteriormente descritos ja identificam o protocolo;
Outra funcao disponıvel e a funcao de associar uma porta ao socket, deste modo
aquela porta ficara disponıvel apenas para esta aplicacao. O metodo para realizar esta
operacao esta descrito abaixo:
Codigo 8.3: Alocacao Porta ao Socket.
1 int bind(int socket, struct sockaddr ∗address, int addr len);
• int socket: indica o socket que foi criado anteriormente para ficar travado com a
porta especifica;
137
• struct sockaddr *address: estrutura que contem as informacoes de enderecamento
requeridas para a associacao;
• int addr len: e o tamanho da estrutura acima citada, realizar um sizeof() da
estrutura para definir este valor.
As duas funcoes seguintes sao as responsaveis pela comunicacao em si do socket,
o recebimento e envio de pacotes. A funcao responsavel pelo sentido da comunicacao
estacao base-remota esta apresentada a seguir:
Codigo 8.4: Envio de Mensagem.
1 int sendto(int socket, char ∗message, int msg len, int flags ,
2 struct sockaddr ∗address, int addr len);
• int socket: refere-se ao socket anteriormente criado;
• char *message: endereco da mensagem a ser transmitida;
• int msg len: o tamanho da mensagem a ser transmitida;
• int flags: flags de controle, recebem valor 0;
• struct sockaddr *address: estrutura de enderecamento de destino;
• int addr len: e o tamanho da estrutura acima citada, realizar um sizeof() da
estrutura para definir este valor.
A funcao de recepcao possui os mesmos atributos, mas com a diferenca de que um
ponteiro para a mensagem a ser enviada e um ponteiro para o buffer em que a mensagem
sera armazenada.
Codigo 8.5: Recepcao de Mensagem.
1 int recvfrom(int socket, char ∗buffer, int buffer len , int flags ,
2 struct sockaddr ∗address, int ∗addr len);
• int socket: refere-se ao socket anteriormente criado;
• char * buffer : endereco do buffer onde a mensagem sera transmitida;
138
• int int buffer len : o tamanho do buffer que recebera a mensagem;
• int flags: flags de controle, recebem valor 0;
• struct sockaddr *address: estrutura de enderecamento de destino;
• int addr len: e o tamanho da estrutura acima citada, realizar um sizeof() da
estrutura para definir este valor.
A ultima funcao que sera utilizada e a responsavel por fechar um socket anteri-
ormente criado:
Codigo 8.6: Fechar Socket.
1 int close (int socket );
• int socket: refere-se ao socket anteriormente criado;
Esta funcao retorna um valor nulo em caso de sucesso.
Desta forma utilizando os metodos citados acima, com 8.2 e 8.3, e ainda adi-
cionando o metodo 8.5 em um looping infinito criar-se um servidor para o recebimento
de dados na porta especıfica. Neste looping pode-se ainda adicionar um tratamento aos
dados recebidos como salvar em um arquivos ou em um banco de dados.
Com 8.4 faz-se um metodo que envia mensagens as EMRs, para tal e necessaria
o IP de destino que estara guardada em uma tabela no banco de dados.
8.4.2 Conexao com o Banco de Dados
Para a conexao com o banco dados foram utilizados metodos disponibilizados pela
fabricante fornecedora do mesmo, esses metodos fornecem ao programador uma rapida
programa nao ligacao entre a linguagem da estacao base , C, e o banco de dados, MySQL.
Os metodos necessarios para realizar uma conexao ao banco da dados sao os seguintes:
Codigo 8.7: Iniciliazacao do MySQL.
1 MYSQL ∗ mysql init(MYSQL ∗mysql);
Codigo 8.8: Conexao com MySQL.
1 MYSQL ∗ mysql real connect(MYSQL ∗mysql, const char ∗host, const char ∗user,
139
2 const char ∗passwd, const char ∗db, unsigned int port,
3 const char ∗unix socket, unsigned int clientflag);
As funcoes acima possibilitam a conexao com um banco de dados MySQL, a
funcao 8.7 inicia uma variavel do tipo MySQL para ser utilizada. A funcao 8.8 possibilita
uma conexao com um bando de dados especıfico, tem como parametros a variavel MySQL
ja iniciada pela funcao 8.7, o host do banco que sera acessado, o usuario, a senha deste
usuario, o banco que sera acessado e uma possıvel porta, socket e flag de acesso.
Codigo 8.9: Finalizacao do MySQL.
1 void mysql close(MYSQL ∗sock);
A funcao close, 8.9, e responsavel por finalizar a variavel aberta em init.
Codigo 8.10: Realizacao de uma Query.
1 int mysql query(MYSQL ∗mysql, const char ∗q);
Para realizar queries responsaveis por modificar e por pesquisar no banco de
dados pode ser utilizada a funcao 8.10. Esta funcao recebe a variavel antes iniciada e
uma matriz de char onde a query podera ser escrita. Ha a opcao da escrita direta ao nos
parametros do metodo, mas deste modo a utilizacao da query torna-se mais estatica.
8.4.3 Verificacao de Integridade
Para verificar a integridade dos pacotes foi utilizado o metodo CRC (Cyclic Re-
dundancy Check) de 16 bits, este metodo e razoavel para o calculo de erros, pois permite
que pequenos erros sejam identificados com facilidade. O calculo do CRC e realizado da
seguinte maneira:
1. Primeiro escolhe-se uma funcao polinomial de 16 bits que servira para a base do
calculo do CRC, no caso foi escolhida a funcao x16 + x15 + x2 + 1 (0x8005, em
hexadecimal);
2. Passa-se os dados, comecando com o LSB, atraves da rotina que ira calcular o CRC,
a qual ira realizar a operacao ou exclusivo nos dados inseridos com polinomio antes
escolhido, neste caso 0x8005, alem disso a operacao ou exclusivo so sera realizada
se o bit do pacote de entrada for 1, se for 0 a rotina passa ao proximo bit do pacote,
140
ate que os dados do pacote sejam zeros, exceto os 16 bits finais que serao o valor do
CRC;
3. Retira-se os 16 bits finais dos dados, que no caso sao o valor do CRC;
4. Inverte-se os bits do CRC;
Apos encontrar o valor do CRC para os dados, adiciona-se os 16 bits correspon-
dentes ao CRC no final do pacote a ser enviado.
8.4.4 Resposta as requisicoes da EMR e do website
Para a comunicacao entre o daemon e o website foi utilizado a tabela Queue,
entao por intermedio desta tabela realiza-se a comunicacao entre daemon e website. E
para a organizacao das mensagens a serem enviadas a EMR foi criada uma fila a partir
da estrutura 8.11
Codigo 8.11: Estrutura para os Pacotes.
1 struct fila pkt
2
3 struct fila pkt∗ anterior
4 struct fila pkt∗ proximo;
5 int estado;
6 unsigned char destino[15];
7 unsigned char pacote[256];
8 unsigned char tamanho;
9 unsigned char sequencia[5];
10 unsigned long ultimo envio;
11 ;
Assim, quando ha algum pacote de EMR que precisa ser respondido ou alguma
requisicao a partir do website a ordem de envio sera respeitada pela fila. Entao, por
exemplo, se o daemon recebeu um INIT de uma EMR, este ira adicionar a resposta na
fila para ser enviado. Apenas se a fila estiver vazia, sem a necessidade de respostas as
EMRs, e que o daemon ira consultar a tabela Queue. A vantagem da criacao da estrutura
e que esta guarda as informacoes de destinatario e o estado em que a comunicacao se
encontra. Atraves do envio foi adicionado o timeout. No total foram adicionados dois
timeouts : um e responsavel por verificar se ha ainda pacotes sendo enviados e outro para
141
garantir a entrega do pacote enviado. A quantidade de tentativas que sera realizada sao
de 5, entao um pacote sera enviado no maximo 5 vezes, apos passar para o proximo da
fila.
8.5 Diagrama de casos de uso da EMR
Para o Sistema Embarcado (EMR) foram estipulados os seguintes casos de uso:
Fonte: Autoria propria
Figura 8.14: Diagrama de casos de uso gerais do sistema embarcado.
8.5.1 Atores
A EMR tera apenas um atores que sera o Daemon:
• Daemon: Responsavel por comunicar-se com a EMR, recebendo e transmitindo
dados.
142
8.5.2 Especificacao dos casos de uso
Aquisicao dos dados dos sensores
Fonte: Autoria propria
Figura 8.15: Diagrama de caso de uso “Aquisicao dos dados”
Nome do Caso de Uso: Aquisicao Dados Sensores.
Ator Principal: Daemon.
Ator Secundario: Nao ha.
Descricao: A captura dos dados dos sensores por parte dos microcontrolador e
seu envio ao daemon.
Pre-Condicoes: Ter o daemon em funcionamento.
Pos-Condicoes: Nao ha.
Fluxo Basico:
1. EMR acorda de acordo com o perıodo de aquisicao de dados;
2. EMR coleta os dados dos sensores;
143
3. EMR monta o pacote com o dado dos sensores, e suas informacoes basicas, como IP
e ID;
4. EMR envia suas informacoes basicas ao Daemon;
5. Daemon confirma informacoes basicas;
6. EMR envia o pacote ao daemon;
7. Daemon confirma recebimento.
Fluxo Alternativo:
• Daemon pode requisitar um reenvio do pacote, caso o mesmo n ao seja integro.
• EMR tentara enviar o pacote mais de uma vez em caso de erro.
Regras do Negocio: A tentativa da conexao sera realizada de acordo com o
protocolo pre-estabelecido.
Mudar frequencia
Nome do caso de uso: Mudar Frequencia.
Ator Principal: Daemon.
Ator Secundario: Nao ha.
Descricao: O recebimento de uma mensagem atraves do daemon para a mudanca
da frequencia em que EMR “acorda” para realizar adquirir os dados.
Pre-Condicoes: Ter uma EMR cadastradas no banco de dados, para que o
daemon possa comunicar-se atraves do IP da mesma.
Pos-Condicoes: Nao ha.
Fluxo Basico:
1. Daemon recebe atraves da tabela Queue uma requisicao de mudanca de frequencia
de uma EMR especıfica;
2. Daemon busca no banco de dado o IP da EMR em questao;
3. Daemon envia um mensagem a EMR;
4. EMR abre a mensagem e troca a variavel responsavel pelo tempo de seu sleep.
144
Fonte: Autoria propria
Figura 8.16: Diagrama de caso de uso “Mudar frequencia”
Fluxo Alternativo:
• O daemon pode nao conseguir conectar-se com a EMR se o IP da dessa estiver
desatualizado;
• Se o daemon nao obter conexao realizara uma outra tentativa de acordo com o
protocolo;
Regras do Negocio: A tentativa da conexao sera realizada de acordo com o
protocolo pre-estabelecido.
Atualizar IP
Nome do Caso de Uso: Atualizar IP.
Ator Principal: Daemon.
Ator Secundario: Nao ha.
Descricao: Quando a EMR acorda e ativa o GRPS e provavel que seu IP seja
trocado pela operadora do chip utilizado, desta forma e necessario que seu IP seja atua-
lizado para que o daemon possa comunicar-se com a EMR posteriormente.
145
Fonte: Autoria propria
Figura 8.17: Diagrama de caso de uso “Atualizar IP”
Pre-Condicoes: Ter uma EMR ja cadastrada e em funcionamento.
Pos-Condicoes: Nao ha.
Fluxo Basico:
1. EMR acorda, adquire os dados e monta o pacote;
2. EMR antes de enviar o pacote com os dados dos sensores, ela envia um pacote menor
contendo suas informacoes como IP e ID.
3. Daemon recebe o pacote;
4. Daemon confirma o id da EMR e atualiza o IP desta no banco de dados.
Fluxo Alternativo:
• Se a EMR nao conseguir se conectar na primeira tentativa, realizara outra de acordo
com o protocolo.
Regras do Negocio: A tentativa da conexao sera realizada de acordo com o
protocolo pre-estabelecido.
146
8.6 Pacote de dados
Uma vez que todo o hardware foi integrado com sucesso, o software pode, entao,
unir todas as informacoes disponıveis a fim de criar pacotes para a comunicacao entre a
estacao base e a estacao remota.
Os pacotes possıveis podem ser consultados no apendice D. Como exemplo, sera
apresentado o pacote gerado pelo programa embarcado no microcontrolador que contem as
leituras dos sensores juntamente com os demais campos como: numero de identificacao da
estacao remota, numero do comando (0x13 para envio das leituras dos sensores), numero
de sequencia do pacote e, para finalizar, o CRC de 16 bits para verificacao de integridade
dos dados contidos no pacote.
8.6.1 Estacao remota
Na lista de comandos 8.12 esta apresentada a struct que representa o pacote a
ser enviado a estacao base, o qual sera transformado em uma string unica ao ser enviado.
Codigo 8.12: Estrutura que representa o pacote na EMR
1 /∗ Estrutura que representa o pacote a ser enviado
2 ∗ a estacao base. Sendo formada inteiramente por
3 ∗ um conjunto de bytes de 8bits . ∗/
4 typedef struct
5 uint8 t id ;
6 uint8 t command;
7 uint8 t payload[256];
8 uint8 t num seq;
9 uint8 t crc [2];
10
11 /∗ Usado apenas para suporte.
12 ∗ Nao entrara nos dados enviados a EBS. ∗/
13 uint16 t size ;
14 PACKAGE;
Vale lembrar que nao ha apenas o pacote com os valores dos sensores, tambem ha
os pacotes de handshake do protocolo, como o INIT, INIT-ACK, ACK e NACK. Ha
tambem pacotes especıficos que apenas a EMR ira receber, ou seja, pacotes enviados pela
147
EBS, tais como: pacote de configuracao para atualizacao da frequencia de captacao dos
dados dos sensores e tambem o pacote que forca uma leitura dos sensores. Todos pacotes
irao se encaixar com a estrutura apresentada na lista 8.12, porem, cada um preenchera
cada atributo da estrutura de uma forma especıfica para aquele pacote.
Quando o recebimento de um pacote e completado o primeiro passo feito, tanto
na estacao base como na remota, e a verificacao do CRC de 16 bits daquele pacote, caso o
resultado for coerente (o resultado calculado bater com o presente no pacote) as operacoes
a serem tomadas a partir deste pacote sao executadas.
8.6.2 Estacao base
Para que o pacote enviado pela EMR tenha algum efeito na EBS e necessario
que esta tambem conheca o formato de todos os pacotes possıveis de serem recebidos, os
quais seguem o formato da struct apresentada na secao anterior.
Na figura 8.18 esta apresentado uma parte do log de recepcao do servidor, onde
este recebeu um pacote, verificou seu CRC e, sendo o calculo igual ao valor presente no
pacote 0E 13, confirmou-se a recepcao do pacote com o envio de um pacote ACK.
Figura 8.18: Registros do log de recebimento de pacotes do daemon.
148
9 — Resultados e Conclusao
Esta secao sera dedicada a apresentacao dos resultados finais do projeto, obtidos
atraves de testes com valores reais (nao fictıcios). Tambem havera uma breve discussao
sobre as dificuldades encontradas no decorrer do desenvolvimento do projeto, em todas
as partes (EMR, EBS e sistema de comunicacao); a concretizacao de alguns riscos que
haviam sido previstos no inıcio do projeto (no planejamento do projeto para ser mais
especıfico), bem como as medidas adotadas para contornar o ocorrido.
Este projeto foi desenvolvido visando a ideia de escalabilidade, ou seja, a possibi-
lidade de aumentar ou acrescentar novos componentes e/ou funcionalidades, sendo assim,
sera apresentado alguns paragrafos tratando sobre projetos e/ou melhorias futuras que
poderiam ser efetuadas sobre o artefato ja existente.
Para finalizar, alguns consideracoes finais serao discutidas, como por exemplo,
aprendizado adquirido, integracao da equipe, comportamento dos integrantes durante o
projeto e uma avaliacao final sobre a equipe como um todo e a disciplina para a qual o
projeto foi desenvolvido.
9.1 Dificuldades
9.1.1 Sensores
Alguns dos sensores utilizados no projeto apresentaram certas questoes que di-
ficultaram sua utilizacao e calibracao. Os primeiros que acarretaram tais dificuldades
foram os sensores de gas, pois para realizar sua calibracao de forma correta e exata seria
preciso ter acesso a equipamentos profissionais de isolamento do gas e controle de fluxo
de ar, temperatura e umidade, fatores estes que influenciam diretamente no resultado da
captacao dos gases medidos.
Como a equipe nao teve acesso aos equipamentos necessarios e os gastos seriam
muito elevados, foi decidido que ficaria fora do escopo deste projeto, deixando o foco para
as areas do projeto mais relacionadas ao curso de Engenharia de Computacao como o
protocolo de comunicacao, desenvolvimento de hardware e software. O desenvolvimento e
149
estudo de sensores apropriados pode ficar, entao, como sugestao para um projeto conjunto
entre estudantes de quımica e eletronica.
O sensor de umidade tambem apresentou dificuldades para o seu funcionamento,
sendo preciso montar um circuito auxiliar e criar um algoritmo especıfico para conseguir
extrair as suas informacoes, ja que este trabalhava com capacitancia variavel. Outra
dificuldade foi sobre o sensor de temperatura, o qual se utiliza do protocolo 1-Wire e o
microcontrolador nao possui uma interface especıfica para este, com isso a equipe, nao
tendo conhecimento basico suficiente para a implementacao do mesmo, teve que dispor
de algum tempo para o estudo teorico e depois seguir para a implementacao.
Porem, ao fim, todos os sensores, exceto os de gas, funcionaram perfeitamente
com uma saıda coerente com as esperada.
9.1.2 Sistema de comunicacao
Desde o inıcio do projeto foi designado tempo e esforco maior ao sistema de
comunicacao, pois este seria dado atraves de uma tecnologia totalmente nova para os
integrantes da equipe, o GPRS. Justamente por este tempo e esforco a mais sobre o sistema
de comunicacao todos os problemas que foram encontrados puderam ser sanados dentro do
limite de tempo estabelecido pelo cronograma, porem, um problema foi encontrado logo
apos a concretizacao de um dos riscos previstos no planejamento do projeto (vide secao
9.1.3), o que gerou certas complicacoes, pois com o atraso gerado pela ocorrencia do risco
a equipe estava sem tempo e esforco suficiente para focar sobre o problema apresentado
pela comunicacao. Porem, ao final a solucao foi encontrada e sua implementacao foi bem
sucedida, podendo assim, completar o sistema de comunicacao.
O problema encontrado na comunicacao foi relacionado ao recebimento de dados
da EBS pela EMR, pois inicialmente havia a ideia de que a cada pacote recebido pelo
modulo GM862-GPS uma interrupcao seria gerada ou em um pino GPIO ou nos proprios
pinos seriais UART do modulo, os quais estavam conectados diretamente no microcontro-
lador. Conforme os testes foram sendo realizados foi constatado que esse comportamento
nao estava ocorrendo, detalhando: a interrupcao so era gerada no primeiro pacote rece-
bido pelo modulo de comunicacao, os pacotes subsequentes nao apresentavam qualquer
tipo de sinal “avisando” sua chegada, ou seja, como nosso microcontrolador ficaria em
estado de hibernacao enquanto nao atingisse o tempo para enviar os dados para a EBS,
150
somente o primeiro pacote recebido da EBS seria reconhecido, fazendo com que os demais
fossem perdidos (ja que o microcontrolador estaria hibernado e nao teria nenhum evento
para acorda-lo).
A solucao foi encontrada durante uma minuciosa leitura sobre o datasheet e lista
de comandos AT disponıveis para o modulo GM862-GPS, onde foi encontrado uma opcao
que mudava o tipo de sinal gerado quando era detectada a recepcao de um novo pacote.
Assim, a cada pacote recebido pelo modulo uma interrupcao seria gerada no canal serial
UART.
9.1.3 Concretizacao dos riscos previstos
No inıcio do projeto (no planejamento) foram levantados alguns riscos que seriam
possıveis de acontecer e que acarretariam algum tipo de prejuızo a equipe, fosse prejuızo
financeiro ou de tempo.
Felizmente apenas um risco previsto se concretizou, porem, foi um risco que
trouxe algumas complicacoes graves, principalmente no atraso do andamento do desenvol-
vimento do projeto, este risco foi o de numero 2 (vide apendice F para maiores detalhes),
o de “Queima ou estragos ao microcontrolador”.
As medidas tomadas foram justamente as apresentadas no plano de resposta aos
riscos no apendice F no campo de mitigacao: “Ter disponıvel um microcontrolador reserva
ou ter a possibilidade de mudar o microcontrolador para outro parecido e que tenha facil
disponibilidade”. A escolha tomada foi a utilizacao de um microcontrolador reserva sendo
do mesmo modelo, a fim de nao perder todo o desenvolvimento feito ate aquele presente
momento no software embarcado.
Devido a ocorrencia deste risco a equipe teve um atraso total no desenvolvimento
de aproximadamente uma semana, pois, como o projeto ja se encontrava nos ultimos
estados do desenvolvimento, muitos cuidados tiveram que ser tomados, a fim de verificar
o motivo da queima e tambem verificar se nenhum outro componente havia sido danificado
juntamente com o microcontrolador.
Ao final da analise foi constatado que apenas o microcontrolador havia sido da-
nificado e os demais componentes estariam em perfeitas condicoes de uso.
O acoplamento de um novo microcontrolador nao acarretou nenhum problema,
ja que este era de mesmo modelo e fabricante, nao sendo necessario nenhuma mudanca ao
151
software embarcado ou ao esquematico eletronico de acoplamento dos sensores e modulo
de comunicacao.
9.2 Resultados
Apesar das dificuldades, em cada etapa a equipe obteve resultados positivos.
Como foi demonstrado e explicado nos capıtulos anteriores, foram feitos testes individu-
ais para cada sensor primeiramente ligados a um kit Arduino, apos constatado seu bom
funcionamento e resultados coerentes estes foram ligados diretamente ao microcontrolador
utilizado no projeto, alem dos testes com os sensores tambem foram realizados testes in-
dividuais com o modulo GPS/GPRS ligado diretamente ao computador por comunicacao
USB, pois a placa utilizada inicialmente para acoplar o modulo possuıa conector USB e
um modulo FTDI para conversao do protocolo USB para serial UART.
Apos esta etapa de testes individuais, foi feita a integracao de todo o sistema, e
foram feitos alguns testes para demonstrar o funcionamento do sistema integrado ja com
o protocolo de comunicacao pronto entre a EMR e EBS. Estes testes serao apresentados
em apenas um que engloba todos os resultados: integracao dos sensores, comunicacao
entre microcontrolador e modulo de comunicacao, protocolo de comunicacao, estacao base
servidor e estacao base cliente.
Na figura 9.1 sao os resultados do log de entrada e saıda de pacotes do servidor,
no qual e relatado a data e a hora da troca de pacotes (campo este que foi ocultado para
melhorar a visualizacao da imagem neste documento), se o pacote e proveniente da EMR
(ENTRADA) ou se e da estacao base cliente (SAIDA), o numero IP da estacao remota,
a porta utilizada para comunicacao, o comando recebido/enviado, o conteudo total do
pacote que foi enviado/recebido pelo servidor e, por ultimo, a verificacao da integridade
do pacote pelo codigo CRC de 16 bits.
O teste foi realizado com a comunicacao iniciada pelo cliente no website, o qual
forcou uma leitura dos sensores pela EMR. Sendo assim, pode-se descrever as acoes to-
madas pelos dois extremos da comunicacao da seguinte forma:
1. servidor envia um pacote de inicializacao de comunicacao, o pacote INIT;
2. a EMR responde, confirmando que esta na escuta, com o pacote INIT-ACK;
152
3. assim que o servidor recebe o pacote de confirmacao da EMR, finaliza a fase de
handshake e inicia a troca de dados, enviando o pacote de requisicao de leitura (ja
que o cliente forcou a leitura);
4. quando a EMR recebe essa requisicao comecara a executar o processo de leitura dos
sensores, levando alguns segundos para isso se completar, quando completo, envia
como resposta ao servidor um pacote contendo todos os valores dos sensores;
5. caso o recebimento for bem sucedido (conferido CRC) e os dados adicionados no
banco de dados, o servidor retorna um pacote ACK confirmando o recebimento e
sinalizando o termino da comunicacao.
Figura 9.1: Troca de pacotes entre EMR e servidor
Como resultado final, tem-se o website com os valores dos sensores referente a
EMR de ID igual a 7 atualizados como na figura 9.2.
Figura 9.2: Website atualizado com os novos valores dos sensores da EMR de ID igual a 7.
153
Para os testes apresentados foram utilizados os circuitos na EMR apresentados
nos esquematicos do apendice A e do apendice B.
9.3 Trabalhos Futuros
Apos o termino do projeto alguns pontos podem ser apontados como futuras
melhorias, para caso este projeto seja continuado. Estes pontos sao:
• estudos e execucao da calibracao dos sensores de gas (CO e VOC), ja que estes
estao apenas retornando um valor em tensao, nao sendo significante para a medida
de poluentes em si;
• construcao de uma estrutura fısica para o acoplamento da estacao remota, visando a
melhor posicao dos sensores para captacao dos dados e protecao ao ambiente (chuva,
sol em excesso, entre outros);
• acrescentar novas estacoes remotas a fim de se obter um conjunto destas em diversas
partes da cidade ou ate paıs.
Estes sao os principais pontos que a equipe pode destacar como ponto de partida,
os quais levarao a outras questoes mais especıficas no decorrer do desenvolvimento.
9.4 Consideracoes Finais
A disciplina de Oficina de Integracao 3 proporciona aos alunos um amplo contato
com o lado pratico do curso de graduacao, tanto no que se diz tecnico como tambem na
parte de recursos humanos. Tambem uma grande oportunidade que a disciplina apresen-
tou foi relacionado ao amadurecimento das capacidades de cada aluno, a fim de eliminar
o medo que muitas vezes limita as pessoas de conhecerem o que e novo. Este tipo de
amadurecimento abre novas visoes para um futuro trabalho de conclusao de curso (TCC),
disciplina na qual muitas vezes sao feitos trabalhos relativamente simples por medo de
arriscar em uma area na qual o aluno nao possui conhecimento e correndo o risco de nao
concluir o trabalho e, consequentemente, o curso.
No aspecto tecnico, pode-se apontar a oportunidade de aprender sobre um novo
sistema de comunicacao, ate entao nunca utilizado na disciplina, o sistema GPRS. Quando
154
a equipe propos a utilizar o modulo GPRS sem ter nenhum conhecimento sobre a tecno-
logia, foi previsto que esta seria a maior dificuldade do projeto, porem alem desta, como
citado anteriormente, foram percebidas outras dificuldades com os sensores, integracao
com o microcontrolador, interacao da estacao base com a estacao remota, com os pra-
zos para cada entrega e o conciliamento desta disciplina com as demais disciplinas do
semestre.
Porem ao final, o resultado obtido foi satisfatorio, tanto relacionado ao artefato
final, como tambem na satisfacao de todos membros da equipe em realizar um trabalho
como este. Como resumo geral, foram cumpridas todas as etapas previstas no planeja-
mento do projeto, foram utilizados os planos de resposta aos riscos e a equipe teve um bom
entrosamento, concluindo assim, com sucesso, a Estacao de Monitoramento de Poluentes.
155
Referencias Bibliograficas
AR Al-Ali, Imran Zualkernan, and Fadi Aloul. A mobile GPRS-sensors array for air
pollution monitoring. Sensors Journal, IEEE, 10(10):1666–1671, 2010.
BIND9. The Domain Name System. http://www.bind9.org/, acessado em julho de
2013.
Dale DePriest. NMEA data. http://www.gpsinformation.org/dale/nmea.htm, aces-
sado em agosto de 2013.
SparkFun Eletronics. GM862 EVK V3USB/RS-232, 2005.
Apache Software Foundation. VirtualHost Examples. http://httpd.apache.org/docs/
2.2/vhosts/examples.html, acessado em julho de 2013.
Google. Google Maps. https://www.google.com/maps/, acessado em agosto de 2013.
V. Ramya and B. Palaniappan. Embedded system for Hazardous Gas detection and Aler-
ting. Proc. of International Journal of Distribted and parallel system (IJDPS), 3(3),
2012.
Peter Rysavy. Data Capabilities: GPRS to HSPDA, Setembro 2004.
Ricardo Di Lucia Santos. Redes GSM, GPRS, EDGE e UMTS. http://www.gta.ufrj.
br/ensino/eel879/trabalhos_vf_2008_2/ricardo/3.html, acessado em agosto de
2013.
Teleco. Voz sobre IP. http://www.teleco.com.br/tutoriais/tutorialvoipconv/
pagina_3.asp, acessado em setembro de 2013.
156
A — Esquematicos - Parte 1: LPC1769 e modulo GM862
157
B — Esquematicos - Parte 2: Sensores
158
C — Prototipo da placa de circuito impresso
159
D — Comandos e pacotes aceitos para o sistema de comunicacao
160
E — Cronograma Detalhado - Microsoft Project
Id Modo
da
Tarefa
Nome da tarefa Duração Início Término
1 Qualificação 0 dias Qua 10/07/13 Qua 10/07/13
2
3 Estudo teórico do microcontrolador 58 dias Seg 15/07/13 Qua 11/09/13
4 Primeiro Entregável 28 dias Qua 10/07/13Qua 07/08/13
5 Estação Base 25 dias Qua 10/07/13Dom 04/08/13
6 Estudos 12 dias Qua 10/07/13Seg 22/07/13
44 Planejamento 13 dias Seg 22/07/13 Dom 04/08/13
45 HTML + PHP 13 dias Seg 22/07/13 Dom 04/08/13
46 Prototipação de Telas 8 dias Seg 22/07/13 Ter 30/07/13
47 Desevolvimento de exemplos 8 dias Seg 22/07/13 Ter 30/07/13
48 Documentação 10 dias Qui 25/07/13 Dom 04/08/13
49 Estação Remota 25 dias Qua 10/07/13Dom 04/08/13
50 Recebimento dos componentes eletrônicos 5 dias Qua 10/07/13 Seg 15/07/13
51 Estudo teórico dos sensores 15 dias Qui 18/07/13 Sex 02/08/13
52 Teste de funcionamento dos sensores 2 dias Sex 02/08/13 Dom 04/08/13
53 Sistema de Comunicação 17 dias Qui 18/07/13 Dom 04/08/13
54 Estudo teórico do módulo GM862-GPS 15 dias Qui 18/07/13 Sex 02/08/13
55 Teste de funcionamento do módulo
GM862-GPS
2 dias Sex 02/08/13 Dom
04/08/13
56 Apresentação 0 dias Qua 07/08/13 Qua 07/08/13
57 1 dia Qua 10/07/13 Qui 11/07/13
58 Segundo Entregável 14 dias Qua 07/08/13Qua 21/08/13
59 Estação Base 12 dias Qua 07/08/13Seg 19/08/13
60 Desenvolvimento 12 dias Qua 07/08/13Seg 19/08/13
61 C++ 6 dias Qua 07/08/13Ter 13/08/13
62 Diagrama de casos de uso 3 dias Qua 07/08/13Sáb 10/08/13
63 Diagrama de fluxo (atividade) 3 dias Sáb 10/08/13 Ter 13/08/13
64 Banco de Dados 6 dias Ter 13/08/13 Seg 19/08/13
65 Diagrama ER 5,38 dias Ter 13/08/13 Dom 18/08/13
66 HTML + PHP 8 dias Qua 07/08/13Qui 15/08/13
67 Diagrama de casos de uso 4 dias Qua 07/08/13 Dom 11/08/13
68 Diagrama de fluxo (atividade) 4 dias Dom 11/08/13Qui 15/08/13
69 Estação Remota 13,38 dias Qua 07/08/13Ter 20/08/13
70 Obtenção dos dados dos sensores 15,13 dias Qua 07/08/13 Qui 22/08/13
71 Testes do módulo conectado ao computador 5,63 dias Ter 13/08/13 Seg 19/08/13
72 Sistema de Comunicação 13 dias Qua 07/08/13Ter 20/08/13
73 Criação do diagrama de estados da
comunicação
13 dias Qua 07/08/13 Ter 20/08/13
74 Estabelecimento do conteúdo dos pacotes de
comunicação
13 dias Qua 07/08/13 Ter 20/08/13
75 Apresentação 0 dias Qua 21/08/13 Qua 21/08/13
76 1 dia Qua 07/08/13 Qui 08/08/13
77 Terceiro Entregável 14 dias Qua 21/08/13Qua 04/09/13
78 Estação Base 12 dias Qua 21/08/13Seg 02/09/13
79 Desenvolvimento 12 dias Qua 21/08/13Seg 02/09/13
80 C++ 6 dias Qua 21/08/13Ter 27/08/13
81 Desenvolver comunicação entre deamon
e BD
6 dias Qua 21/08/13 Ter 27/08/13
82 HTML + PHP 9 dias Qua 21/08/13Sex 30/08/13
161
Id Modo
da
Tarefa
Nome da tarefa Duração Início Término
83 Desenvolvimento da página visual 1 dia Qua 21/08/13 Qui 22/08/13
84 Desenvolvimento das páginas com os
Plugins
3 dias Qui 22/08/13 Dom
25/08/13
85 Desenvolvimento das páginas que
coletára do BD os dados
5 dias Dom
25/08/13
Sex 30/08/13
86 Documentação 9 dias Qua 21/08/13 Sex 30/08/13
87 Estação Remota 12 dias Qua 21/08/13Seg 02/09/13
88 Diagramas elétricos para conectar
GM862-GPS ao microcontrolador
7 dias Ter 13/08/13 Sex 23/08/13
89 Diagramas elétricos para conectar sensores ao
microcontrolador
7 dias Qui 15/08/13 Dom
25/08/13
90 Testes da localização GPS com o módulo já
conectado ao microcontrolador
8,63 dias Sáb 24/08/13 Seg 02/09/13
91 Sistema de Comunicação 6 dias Ter 27/08/13 Seg 02/09/13
92 Teste com sensores conectados ao
microcontrolador
5 dias Ter 27/08/13 Dom
01/09/13
93 Testes com a comunicação GRPS com o
módulo já ligado ao microcontrolador
5 dias Qui 29/08/13 Ter 03/09/13
94 Desenvolver funções básicas de comuncação
com a EMR
6 dias Ter 27/08/13 Seg 02/09/13
95 Apresentação 0 dias Qua 04/09/13 Qua 04/09/13
96 Quarto Entregável 14 dias Qua 04/09/13Qua 18/09/13
97 Estação Base 12 dias Qua 04/09/13Seg 16/09/13
98 Finalização da integração do deamon, BD e
website
12 dias Qua 04/09/13 Seg 16/09/13
99 Estação Remota 13 dias Qua 04/09/13Ter 17/09/13
100 Finalização da integração dos sensores,
microcontrolador e módulo GM862-GPS
6 dias Qua 04/09/13 Ter 10/09/13
101 Confecção das PCIs para acoplamento do
módulo GM862-GPS e sensores
15,72 dias Ter 10/09/13 Dom
29/09/13
102 Sistema de Comunicação 8 dias Ter 10/09/13 Qua 18/09/13
103 Testes de comunicação entre EMR e EBS 10 dias Ter 10/09/13 Ter 24/09/13
104 Finalização da Monografia 6 dias Qua 18/09/13 Ter 24/09/13
105 Defesa do Projeto 0 dias Qua 02/10/13 Qua 02/10/13
162
F — Plano de resposta aos riscos
1a etapa: Identificacao do Risco
Denominacao do risco: Comunicacao sem fio entre estacao demedicao e base nao estabelecida
No Identificacao1
Descricao do risco: Problemas com o modulo GPRS, sem o qual a estacao base nao seriacapaz de receber os dados da estacao de medicao e, consequentemente, nao apresentarestes dados ao usuario, nao atingindo o objetivo do projeto.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)O desenvolvimento de partes independentes do projeto poderia continuar, porem, o obje-tivo final do projeto nao seria atingido.Probabilidade: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Devido a falta de conhecimento pleno do funcionamento do modulo de GPRS a equipeesta sujeita a complicacoes de implementacao.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Estudar detalhadamente o modulo e a tecnologia GPRS, manter um resumode funcionamento do mesmo para outros membros da equipe poderem ajudar na resolucaode problemas de funcionamento.Transferir: -Mitigar: Adquirir um modulo reserva para ser usado em caso de avaria do titular.Aceitar: -
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
163
1a etapa: Identificacao do Risco
Denominacao do risco: Queima ou estragos ao microcontroladorNo Identificacao
2
Descricao do risco: Possıveis problemas que possam acontecer com o microcontroladorescolhido, tais como queima ou perda por fatores diversos.
2a etapa: Avaliacao do Risco
Impacto: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)O microcontrolador e uma peca fundamental do projeto, desta forma qualquer problemacom o mesmo e de alto impacto.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)A equipe tem experiencia no manuseio de microcontroladores, mas ainda assim algumproblema inesperado podem ocorrer.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Sempre ter cuidado com o manuseio do microcontrolador e qualquer mudancasempre ser conferida por outro membro.Transferir: -Mitigar: Ter disponıvel um microcontrolador reserva ou ter a possibilidade de mudar omicrocontrolador para outro parecido e que tenha facil disponibilidade.Aceitar: -
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
164
1a etapa: Identificacao do Risco
Denominacao do risco: Problemas na precisao ou mal funciona-mento dos sensores.
No Identificacao3
Descricao do risco: Os sensores podem nao atender as necessidades do projeto, naopossuir a precisao desejada, nao atuarem conforme o esperado. Os prejuızos podem serfinanceiros (troca do sensor, possivelmente por um mais caro) e podem tambem afetar ocronograma de diversas maneiras.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Caso os sensores nao sejam compatıveis com as necessidades do projeto, sera necessariosubstituı-los.Probabilidade: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Em experiencias anteriores, nas disciplinas de Oficina de Integracao e outras, os sensores jaforam fonte de problemas nos mais variados tipos de projeto. Esse projeto, em especıfico,demanda uma boa precisao e resposta dos sensores.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Estudar detalhadamente as caracterısticas dos sensores disponıveis, escolheros que melhor se adaptem ao projeto.Transferir: -Mitigar: Possuir uma lista de sensores que possam substituir os escolhidos e ondecompra-los. Buscar sensores que nao demadem grandes alteracoes no hardware casovenham ser substituıdos.Aceitar: -
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
165
1a etapa: Identificacao do Risco
Denominacao do risco: Nao cumprimentos de metas estabeleci-das.
No Identificacao4
Descricao do risco: O nao cumprimento dos prazos de entrega estabelecidos pela equipee pelos professores acarretaria problemas com tempo, notas e, consequentemente, no de-senvolvimento do projeto.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)O nao cumprimento de metas e obejtivos e de alto impacto, pois pode em ultimo casolevar a reprovacao da equipe.Probabilidade: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)A falta de experiencia da equipe em alguns topicos do projeto pode gerar atrasos comcerta frequencia.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Manter a equipe focada no desenvolvimento do projeto, respeitando o crono-grama e metas.Transferir: -Mitigar: Promover uma reuniao para verificar as acoes necessaria para manter o crono-grama em ordem.Aceitar: -
Impacto reavaliado: 3 (medio)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
166
1a etapa: Identificacao do Risco
Denominacao do risco: Atraso na entrega de componenentesencomendados.
No Identificacao5
Descricao do risco: Os componentes comprados podem sofrer atrasos em sua entrega.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Sem os componentes solicitados nao ha possibilidade de realizar o projeto, acarretandoatrasos no cronograma definido pela equipe.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)Por mais que as encomendas sejam feitas com antecedencia ainda ha a possibilidade destaentrega atrasar por fatores como: fiscalizacao alfandegaria, avaria da mercadoria, entreoutros.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Encomendar os componentes com antecedencia suficiente para evitar impactosde atrasos na entrega no cronograma do projeto.Transferir: -Mitigar: Realizar emprestimo de componentes similiares para uso caso os encomendadosatrasem, e realizar a encomenda com bastante tempo de antecedencia.Aceitar: -
Impacto reavaliado: 3 (medio)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
167
1a etapa: Identificacao do Risco
Denominacao do risco: Avaria em equipamentos utilizados comlongo prazo de aquisicao.
No Identificacao6
Descricao do risco: Inviabilizacao de uso de equipamentos/componentes utilizados nodecorrer do desenvolvimento do projeto que tenham longo prazo de aquisecao para umnovo.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Caso nao for previsto este risco o projeto pode ser inviabilizado ou sofrer grande atrasoem relacao ao cronograma planejado.Probabilidade: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Por mais que a equipe mantenha um componente reservas estes podem vir a dar problemas,tornando sua utilizacao impossıvel.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: A utilizacao de cada um dos componentes do projeto deve ser bem planejada ea montagem bem feita. A equipe tambem deve dar preferencia a produtos que possam sercomprados no Brasil, evitando importacoes, porem, caso for necessario importar qualquerequipamento/componente, isto deve ser feito o quanto antes para evitar atrasos iniciaisdo projeto.Transferir: -Mitigar: Ter para cada componente utilizado no projeto um componente identico oumuito similar como reserva; para cada reserva utilizada obter um novo como reserva.Aceitar: -
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
168
1a etapa: Identificacao do Risco
Denominacao do risco: Reducao do tamanho da equipe causadapela desistencia de um ou mais membros da disciplina.
No Identificacao7
Descricao do risco: Seria a saıda de um ou mais integrantes do grupo ate o fim doprojeto. Ocasionando uma diminuicao na capacidade de recursos de desenvolvimento etrazendo como consequencia uma maior sobrecarga nos integrantes que permaneceram nogrupo.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Nao temos flexibilidade no prazo de entrega do projeto, nem na aquisicao de novos recursoshumanos. O grupo e relativamente pequeno, a saıda de um integrante corresponde a 20%de recursos humanos que temos. Caso saia mais de um integrante, o impacto e aindamaior.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)A saıda pode acontecer por diversos motivos, desde viagens, intercambio, desentendimen-tos com a equipe, descontentamento com o projeto, sobrecarga de outras materias. Achance de umas dessas situacoes acontecer e media.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: A prevencao pode ser feita atuando em cima das possıveis causas de evasao.Manter sempre o grupo motivado; Distribuir tarefas aos integrantes de forma equivalentee sensata de acordo com as capacidades individuais; Sempre reconhecer os esforcos dosintegrantes do grupo no desenvolvimento do projeto; Tratar desentendimento com dialogose resolver de forma em que o grupo saia beneficiado e nao prejudique demais algumintegrante.Transferir: -Mitigar: De forma a trazer menos prejuızo a equipe no caso de saıda de um integrante,sera necessario sempre manter documentado o desenvolvimento, pesquisas e estudo sobrepartes do projeto. Sempre deve haver mais de um integrante trabalhando e acompanhandocada parte do desenvolvimento para, assim, nao precisar haver um retrabalho de pesquisa,estudo, demandando mais horas de trabalho.Aceitar: No caso de saıda nao ha outra acao a nao ser distribuir o trabalho do integranteentre os que permaneceram na equipe.
Impacto reavaliado: 3 (medio)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
169
1a etapa: Identificacao do Risco
Denominacao do risco: Reducao temporaria do tamanho daequipe por motivo de provas, trabalhos, doencas e/ou viagens.
No Identificacao8
Descricao do risco: Por inumeras situacoes pode acontecer de algum integrante daequipe ter sua capacidade produtiva reduzida ou ate mesmo ter que se afastar do desen-volvimento do projeto por algum tempo, podendo ser dias e ate semanas.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Por termos o prazo de entrega bem definido e inflexıvel, o planejamento de trabalho paracada integrante sera bem definido para que todos possam desempenhar seu papel de formarapida e sem sobrecarga. A ausencia momentanea tras um impacto medio/alto pelo fatode termos que distribuir as tarefas do integrante ausente.Probabilidade: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)A probabilidade de isso acontecer e grande. Pode acontecer por varios motivos como:viagens nao programadas, provas adiadas, doencas.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Nao ha uma forma de prevenir eventos em que ocorram situacoes extraor-dinarias. Mas podemos prevenir situacoes como provas e entrega de trabalhos de outrasmaterias, viagens programadas, etc. Situacoes ja previstas devem entrar no cronogramaindividual de cada colaborador de forma a transferir esses perıodos com baixa produtivi-dade para outras semanas.Transferir: Buscar deixar mais de uma pessoa encarregada pelas tarefas podendo, casoocorra algum imprevisto, tranferi-las para outros integrantes da equipe.Mitigar: Caso, no meio do desenvolvimento, surja algum evento nao programado deve-se, com a maior brevidade, alterar o cronograma de forma a prejudicar menos possıvel oprazo e os outros colaboradores.Aceitar: Situacoes como as supracitadas podem sempre ocorrer, devem ser encaradascom tranquilidade e em uma discussao com a equipe chegar a uma melhor solucao para oproblema.
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
170
1a etapa: Identificacao do Risco
Denominacao do risco: Possıveis problemas causados por fatoresexternos e internos a estrutura da estacao.
No Identificacao9
Descricao do risco: Problemas mecanicos na estrutura da estacao podem ocorrer, porexemplo, a mesma pode apresentar falhas de montagem, falhas de fabricacao, falhas defuncionamento, entre outros.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1 (baixo)Se forem detectados falhas mecanicas na estrutura da estacao, a mesma pode sofrer con-sequencias como ter os equipamentos molhados por chuva, equipamentos danificados porpossıveis quedas, entre outros.Probabilidade: 5 (alto) 4 (medio/alto) 3 (medio) • 2 (medio/baixo) 1(baixo)Mesmo a equipe tendo extremo cuidado na parte da montagem e pela estacao nao es-tar sujeita apenas a ambientes internos, existe a probabilidade de fatores meteorologicos(chuvas, ventanias, etc.) causarem danos a estrutura.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: A equipe deve verificar minuciosamente os detalhes da montagem, checarparafusos, checar os cabos e conexoes, e por fim realizar testes que previnam situacoescomo chuvas e ventanias.Transferir: -Mitigar: Ter uma estrutura e componentes reservas caso algo seja danificado.Aceitar: -
Impacto reavaliado: 2 (medio/baixo)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
171
1a etapa: Identificacao do Risco
Denominacao do risco: Problemas no cronograma ou em recur-sos devido a acoes tomada pela lideranca da universidade.
No Identificacao10
Descricao do risco: Problemas de estrutura da universidade como greves, reformas dolocal de aula e apresentacao, quedas de luz, entre outros fatores que possam afetar ocronograma.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1 (baixo)Caso ocorra, esse problema pode afetar o cronograma do projeto, mas dificilmente invia-biliza-lo.Probabilidade: 5 (alto) 4 (medio/alto) 3 (medio) • 2 (medio/baixo) 1(baixo)Em um dos semestres anteriores, ocorreu um destes problemas (greve de 4 meses).etc.)causarem danos a estrutura.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Nao ha muito que se possa fazer para prevenir esses acontecimentos, mas aequipe deve estar preparada para mudancas no cronograma.Transferir: -Mitigar: Refazer o cronograma, mudar local de apresentacao.Aceitar: Aceitacao passiva: Caso ocorra uma greve, por exemplo, nao ha outra alterna-tiva a nao ser aceitar o problema e reprogramar as atividades do projeto de acordo como novo calendario academico.
Impacto reavaliado: 3 (medio)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
172
1a etapa: Identificacao do Risco
Denominacao do risco: PProblema de perda de equipamento.No Identificacao
11
Descricao do risco: Problema de perda, roubo ou extravio do hardware ou equipamentosutilizados no projeto.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Caso um ou mais componentes seja perdido, os prejuızos financeiros podem ser gravespara a equipe. O cronograma podera ser afetado, ja que ficaria sem esse equipamento ateque fosse substituıdo.Probabilidade: 5 (alto) 4 (medio/alto) 3 (medio) • 2 (medio/baixo) 1(baixo)Ja ocorreram casos de roubo e perda de equipamentos com equipes na disciplina.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Realizar a compra de componentes de reserva. Guardar componentes reservasem locais diferentes dos outros componentes, para nao correr o risco de perder todoequipamento de uma vez.Transferir: -Mitigar: Procurar por componentes substitutos, o mais rapido possıvel. Emprestarcomponentes enquanto novos equipamentos nao chegam.Aceitar: -
Impacto reavaliado: 3 (medio)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
173
1a etapa: Identificacao do Risco
Denominacao do risco: Falhas de software sobre o projeto.No Identificacao
12
Descricao do risco: Problema de perda, roubo ou extravio do hardware ou equipamentosutilizados no projeto.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1 (baixo)O impacto seria sobre o tempo demandado para reorganizar/reconfigurar um computadore/ou programas para retomar ao ponto de parada do projeto antes do problema ocorrer.Probabilidade: 5 (alto) 4 (medio/alto) 3 (medio) • 2 (medio/baixo) 1(baixo)A equipe utilizara softwares ja conhecidos por todos membros, tornando assim a manu-tencao facil e a chance de ocorrer algum problema nao muito elevada.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Do inıcio ao fim do desenvolvimento do projeto utilizar ambientes de desen-volvimento e sistemas operacionais em suas versoes estaveis, evitando erros de atualizacaoou de versoes nao estaveis (alfa, beta, rc, entre outros).Transferir: -Mitigar: Sempre manter backups de toda documentacao e arquivos de desenvolvimentoem particoes e maquinas distintas.Aceitar: -
Impacto reavaliado: 2 (medio/baixo) Probabilidade reavaliada: 1 (baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
174
1a etapa: Identificacao do Risco
Denominacao do risco: Ultrapassar o orcamento inicial do pro-jeto.
No Identificacao13
Descricao do risco: Ocorrera se o projeto tiver um custo maior do que o previsto eultrapassar o teto pre-estabelecido.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1 (baixo)Caso o custo do projeto ultrapasse em muito o valor antes determinado, podera acarretarem problemas no projeto pois seria preciso um novo orcamento e uma nova aprovacao dosclientes, que caso seja negada, pode tornar o projeto inviavel.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)Os custos do projeto podem ultrapassar o orcamento por falha no planejamento ou poroutros problemas (roubo, perda, danificacao dos componentes).
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Fazer um estudo dos componentes que precisarao ser utilizados no projetoe tentar adquirir o que tenha melhor custo/benefıcio disponıvel, e deixar uma sobra noorcamento para possıveis problemas.Transferir: -Mitigar: Reduzir a funcionalidade da estacao (retirando alguns componentes que tenhamo valor sobressalente ao orcamento) ou procurar alternativas viaveis e que se adentrem aoque foi determinado.Aceitar: -
Impacto reavaliado: 2 (medio/baixo)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
175
1a etapa: Identificacao do Risco
Denominacao do risco: Falta de locais e/ou horarios parareunioes e testes.
No Identificacao14
Descricao do risco: Problemas para conseguir locais e/ou horarios para realizar os testee reunioes necessarios para a realizacao do projeto, dificultando a comunicacao da equipe.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)O impacto da falta de comunicacao e alto, pois pode levar a falencia da equipe.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)
E natural algumas faltas em reunioes e desentendimentos, mas nao com a equipe inteira,desta forma a probabilidade e media.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Verificar previamente os horarios disponıveis dos membros do grupo e suaacessibilidade ao lugar em que a reuniao foi marcada.Transferir: Caso o horario/lugar escolhido nao for acessivel a todos os membros, alteraro horario/lugar.Mitigar: Realizar reunioes na internet para manter sempre todos os membros atualiza-dos. Informar aos nao presentes atraves de outro modo os conteudos discutidos e seusresultados.Aceitar: -
Impacto reavaliado: 2 (medio/baixo) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
176
1a etapa: Identificacao do Risco
Denominacao do risco: Falta de conhecimento em assuntos re-lacionados ao projeto.
No Identificacao15
Descricao do risco: Problema gerado pela subestimacao da complexidade da imple-mentacao dos artefatos de hardware/software do projeto.
2a etapa: Avaliacao do Risco
Impacto: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Caso falte conhecimento para o grupo em qualquer assunto relacionamento ao desen-volvimento do projeto, o mesmo tem grande impacto sobre este pois ira atrasar ou atemesmo comprometer o seu funcionamento. A falta de conhecimento pode levar a escolhasinadequadas de componentes, por exemplo.Probabilidade: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Existe uma probabilidade relativamente alta pois e a primeira experiencia da equipe como sistema de comunicacao e outros sensores que serao utilizados.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Realizar um estudo aprofundado sobre os conhecimentos que serao necessariospara desenvolver o projeto, com tempo habil para descartar os que nao atenderem aproposta do projeto e para procurar novas alternativas.Transferir: -Mitigar: Procurar novas solucoes rapidamente para suprir possıveis falhas ou adotarconhecimentos que a equipe ja tem experiencia, o que pode causar uma diminuicao dacapacidade da estacao, porem, nao comprometendo todo o projeto.Aceitar: -
Impacto reavaliado: 4 (medio/alto)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
177
1a etapa: Identificacao do Risco
Denominacao do risco: Subestimacao do prazo de execucao dastarefas.
No Identificacao16
Descricao do risco: A falta de experiencias na area de planejamento pode gerar estima-tivas ruins quanto ao prazo de desenvolvimento de cada tarefa do projeto, principalmentenas partes onde os integrantes da equipe nao possuem grande conhecimento.
2a etapa: Avaliacao do Risco
Impacto: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)O projeto tem varias etapas de desenvolvimento, algumas ocorrem de forma paralela eoutras em sequencia, sejam por dependencia de desenvolvimento e pesquisa ou por maode obra. O erro de estimar o prazos ruins tem maior impacto nas tarefas que possuemdependentes, que por sua vez pode haver outros dependentes, formando atrasos sucessivos.Probabilidade: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)A falta de experiencia no planejamento tras consigo uma margem muito grande de erro.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Pesquisar e indagar pessoas e equipes anteriores sobre qual a melhor forma deplanejar a distribuicao dos prazos de desenvolvimento. Caso haja alguma duvida sobrea quantidade de tempo necessario e melhor que se de um tempo um pouco maior que osuposto. Transferir: Aumentar temporariamente o numero de membros para trabalharna tarefa que pode gerar atrasos.Transferir: Aumentar temporariamente o numero de membros para trabalhar na tarefaque pode gerar atrasos.Mitigar: No planejamento do cronograma deve-se inserir perıodos de escape. Deve haverum intervalo entre algumas tarefas, caso tudo ocorra bem pode ser usado como descanso oucomo adiantamento das tarefas, mas no caso de atraso, serve como tempo de recuperacaosem interferir nas tarefas subsequentes.Aceitar: Na ocorrencia de uma mensuracao incorreta, deve-se de imediato rever o cro-nograma e reavaliar prazos das outras tarefas pendentes. O erro de medida se da tantopara mais, quanto para menos, no caso de se planejar muito tempo para uma tarefaque demande menos, pode-se reavaliar o cronograma dando mais folga para tarefas maispesadas.Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
178
1a etapa: Identificacao do Risco
Denominacao do risco: Grande numero de iteracoes no cicloprojeto – construcao – testes.
No Identificacao17
Descricao do risco: Um numero muito alto de iteracoes no ciclo projeto – construcao– testes para prototipos e para o artefato propriamente dito.
2a etapa: Avaliacao do Risco
Impacto: 5 (alto) • 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1 (baixo)Nesse caso o maior dano e no prazo do projeto. Como nao e possıvel estender o prazofinal de entrega, o projeto pode ficar comprometido.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)Apesar da fase de planejamento minuciosa, devido a inexperiencia da equipe com projetosdesse porte, erros podem ocorrer provocando um aumento no numero de iteracoes do ciclo.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Seguir o planejamento de maneira criteriosa, estudar as tecnologias e procurarutilizar tecnicas reconhecidas evitando conjecturar sem base cientıfica. Realizar testesseguidos a cada passo do projeto e nao realizar sessoes de testes apenas com o artefatopronto. Antes de cada teste o grupo deve certificar-se do procedimento a ser adotado afim de validar os resultados obtidos.Transferir: -Mitigar: A equipe devera propor solucoes a curto prazo para corrigir o que for necessarioe adaptar o artefato de modo a superar qualquer dificuldade encontrada nas sessoes detestes e minimizando o replanejamento a ser adotado a fim de validar os resultados obtidos.Aceitar: -
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 3 (medio)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
179
1a etapa: Identificacao do Risco
Denominacao do risco: Gerente da equipe deixar de cumprirsuas funcoes ou desistir do cargo.
No Identificacao18
Descricao do risco: As funcoes do gerentes sao de extrema importancia para a orga-nizacao, direcionamento e controle do projeto. O gerente, alem dessas funcoes, tambemtem a tarefa de ajudar na pesquisa e desenvolvimento do produto. A saıda dessa pessoatem um maior peso pelo fato de ter uma maior responsabilidade.
2a etapa: Avaliacao do Risco
Impacto: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Pelo fato de o gerente ter mais funcoes que um outro integrate normal e determinaralgumas funcoes deles faz com que o impacto seja alto. Pode acontecer uma situacaodo gerente nao exercer com propriedade o seu papel e ocorrer de ser percebida apenasquando o problema ja atingiu nıveis crıticos, nao havendo tempo de arrumar e ajustar astarefas entre todos. E quanto maior a pressao, maior a change de desistencia, trazendomais impacto no caso de ocorrer.Probabilidade: 5 (alto) 4 (medio/alto) • 3 (medio) 2 (medio/baixo) 1(baixo)O gerente foi selecionado por ja possuir algumas caracteristicas de gerente/gestor etambem por vontade propria. Nao foi imposto o papel para ele. Mas pressoes e pro-blemas podem ocorrer.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Para prevenir devemos atuar nas causas dos problemas. Nao deixar o gerentemuito sobrecarregado; Ter um sub-gerente para ajudar nos papeis de gerencia; Todosdevem ter pro-atividade, agir em funcao do grupo, sem ter que ficar esperando funcoesdelegadas pelo gerente; Sempre que ocorrer atrasos, confusoes, brigas, verificar se o papeldo gerente esta sendo cumprido.Transferir: -Mitigar: Sempre deve ter alguem acompanhando o gerente, como um sub-gerente, paraque caso ocorra da desistencia do papel de gerente ou nao execucao correta do papel,outra pessoa possa assumir sem muitos problemas para a equipe.Aceitar: No caso de ocorrer desistencia, outra pessoa deve assumir o papel.
Impacto reavaliado: 4 (medio/alto)Probabilidade reavaliada: 2(medio/baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
180
1a etapa: Identificacao do Risco
Denominacao do risco: Mudancas no formato e avaliacao dadisciplina.
No Identificacao19
Descricao do risco: Qualquer mudanca realizada no formato no cronograma da disci-plina que foi previamente disponibilizado pelos professores no comeco do semestre. Essamudanca pode ocorrer devido a mudanca dos professores, greve na universidade ou outrosfatores.
2a etapa: Avaliacao do Risco
Impacto: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Caso ocorra seria um grande impacto, pois provocaria varias mudancas ao projeto.Probabilidade: 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) • 1 (baixo)Nao ha historico de mudancas da disciplina, entao a probabilidade deste risco e baixa.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Sempre manter o cronograma atualizado, para que se alguma mudanca ocorraao projeto possa facilmente adequar-se ao novo.Transferir: -Mitigar: Adequar as tarefas restantes para a nova forma de avaliacao.Aceitar: Caso a mudanca ocorra, o grupo devera fazer as mudancas requisitadas.
Impacto reavaliado: 3 (medio) Probabilidade reavaliada: 1 (baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
181
1a etapa: Identificacao do Risco
Denominacao do risco: Mudancas no escopo do projeto.No Identificacao
20
Descricao do risco: A decisao dos sponsors do projeto pode levar a uma mudancabrusca no escopo do projeto, por exemplo.
2a etapa: Avaliacao do Risco
Impacto: • 5 (alto) 4 (medio/alto) 3 (medio) 2 (medio/baixo) 1(baixo)Uma mudanca no escopo do projeto em qualquer fase a partir da aceitacao seria de grandeimpacto pois levaria a necessidade de reconstrucao e reorganizacao tanto do cronogramaquanto da estrutura de trabalho da equipe, prejudicando gravemente todo o decorrer doprojeto ate entao.Probabilidade: 5 (alto) 4 (medio/alto) 3 (medio) • 2 (medio/baixo) 1(baixo)A mudanca seria feita apenas por parte dos sponsors, mas como o projeto ja esta em fasede formalizacao e pouco provavel ocorrer mudancas bruscas no escopo projeto.
3a etapa: Desenvolvimento da Resposta ao Risco
Acoes, Responsaveis e Datas de ConclusaoEstrategias e acoes:Prevenir: Manter sempre uma boa documentacao de entrega para os sponsors,mantendo-os sempre informados do andamento do projeto.Transferir: -Mitigar: -Aceitar: Aceitacao ativa: Reconstrucao e reorganizacao imediata do cronograma e dasequipes de trabalho, respectivamente, e aumentar a carga de trabalho semanal por inte-grante.
Impacto reavaliado: 5 (alto) Probabilidade reavaliada: 1 (baixo)
Elaborado por: Ale-sandro, Amanda,Bruno, Jonathan,Tiago
Data: 23/06/2013 Respostas
incluıdas naWBS/Cronograma
Registros adicionais:Verso ou anexos
Formulario sugerido por Gasnier, 2000; Editora IMAN e alterado por Wille.
