universidade do minho -...
TRANSCRIPT
Outubro de 2012
Universidade do Minho
Escola de Engenharia
Duarte Manuel Azevedo Fernandes
IntelFleet-Sistema de Gestão e Localização de Frotas
via GPS
Dissertação de Mestrado
Mestrado Integrado em Engenharia Eletrónica Industrial e
Computadores
Trabalho efetuado sob a orientação do
Professor Doutor Paulo Francisco S. Cardoso
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
DECLARAÇÃO
Nome: Duarte Manuel Azevedo Fernandes
Endereço eletrónico: [email protected] Telefone: 917033731 / 252921160
Número do Bilhete de Identidade:13237625
Título dissertação: IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Orientador: Doutor Paulo Francisco S. Cardoso
Ano de conclusão: 2012
Designação do Mestrado: Mestrado Integrado em Engenharia Eletrónica Industrial e
Computadores – Ramo Sistemas Embebidos
É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA TESE/TRABALHO
APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO
ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE;
Universidade do Minho, ___/___/______
Assinatura: ________________________________________________
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
iii
Agradecimentos
Apesar de uma dissertação ser um trabalho individual, devido ao seu objetivo
académico, há sempre contributos de natureza diversa que não podem deixar de ser
mencionados, pelo que expresso aqui os meus sinceros agradecimentos a todos os que
contribuíram de uma forma decisiva para a concretização deste trabalho.
Gostaria de salientar o meu orientador Professor Doutor Paulo Francisco S. Cardoso,
pelo estímulo e entusiasmo revelado por esta dissertação, pela disponibilidade sempre
revelada, pelas críticas e sugestões relevantes feitas durante a orientação que foram
essenciais para atingir os objetivos propostos.
De realçar o bom espirito e companheirismo encontrado no laboratório, mais
especificamente o bom ambiente criado muito graças aos meus colegas André Ferreira e
Nélson Barbosa.
Por último, manifesto um sentido e profundo reconhecimento à minha família pelo
apoio incondicional ao longo destes anos. Expresso sentimento idêntico em relação a
todos os meus amigos de longa data. A todos que me ajudaram a ser quem sou, que
depositaram confiança em mim e para os quais sou uma esperança, resta-me
afincadamente não vos desiludir. Muito obrigado!
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
iv
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
v
Resumo
Neste mundo globalizado, onde fabricantes e consumidores se encontram
geograficamente dispersos e onde a necessidade de matéria-prima é quase imediata,
obriga a que as empresas de transporte de mercadorias procurem melhorar a qualidade
dos seus serviços, de forma a satisfazer consumidores cada vez mais exigentes. O
transporte rodoviário é por vários motivos o modo de transporte mais vantajoso para o
transporte interno de mercadorias, isto provocou um rápido crescimento no mercado
rodoviário de mercadorias, acompanhado por um aumento significativo da concorrência
para as empresas privadas da área. Assim sendo, as organizações de transporte
rodoviário de mercadorias apostam em equiparem-se com sistemas tecnológicos de
gestão e localização de forma a melhorar os resultados obtidos no serviço ao cliente e a
minimizar os custos [1]. Esta necessidade, não é a única sentida por estas organizações
face ao número significativo de roubo de veículos e mercadorias [2] que se verifica,
assim torna-se inevitável tomar medidas de segurança preventivas.
O presente trabalho aborda o desenvolvimento de um sistema de gestão da atividade de
frotas apoiado na informação geográfica recolhida por tecnologia GPS, a solução
proposta, é intitulada a partir da junção dos termos em inglês “Intelligence” e “Fleet”
obtendo assim o nome da ferramenta apresentada, IntelFleet. Este instrumento,
destinado essencialmente a empresas de frotas foca-se essencialmente no planeamento e
acompanhamento em tempo real das atividades dos recursos que executam suas tarefas
fora da organização, tais como viaturas e condutores.
Palavras-Chave: Tracking, GPS, GSM, Android, Google Maps, Gestão de Frotas;
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
vi
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
vii
Abstract
In this globalized world, where manufacturers and consumers are found
geographically scattered and where the need of raw material is barely immediate,
demand to that the goods transport companies, are going to improve the quality of his
service of form it satisfy consumers more and more demanding. The transport road is
for several motives the worth while way of transport for the internal transport of goods,
this provoke a quick growth in the goods road market, accompanied by a significant
increase of the competition for the private companies of the area. Like this being, the
goods road transport organizations wager in will equip itself with technological systems
of management and location and still his vehicles with systems of navigation and
tracking1 of form it improve the results obtained in the service to the client and it
minimize the costs. This need is not to unique felt by these organizations, face to the
significant number of robbery of merchandise that is verified, like this becomes-itself
inevitable take preventive safety measures.
To present dissertation approaches the development of a system of management of the
activity of fleets rested on the geographical information collected by technology GPS,
the proposed solution, is titled from the juncture of we will have in English
“Intelligence” and “Fleet” obtaining like this the name of the tool presented, IntelFleet.
This instrument, destined essentially the seal fleets bearers companies itself essentially
in the management of all of the resources that develop all her task outside of the
organization, such as vehicles and drivers, permitting the accompaniment in real time of
the her activities, beyond the supervision permitting the planning of these same task.
Keywords: Tracking, GPS, GSM, Android, Google Maps, Fleet Management;
1 Process Control and Monitoring of objects, people, etc.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
viii
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
ix
Índice
Agradecimentos ................................................................................................................. iii
Resumo ............................................................................................................................... v
Abstract ............................................................................................................................ vii
Índice ................................................................................................................................. ix
Índice de Figuras ............................................................................................................... xiii
Índice de Tabelas .............................................................................................................. xix
Abreviaturas ..................................................................................................................... xxi
1. Introdução ................................................................................................................... 1
1.1 Objetivos ............................................................................................................ 1
1.2 Motivações ......................................................................................................... 2
1.3 Organização e Estrutura da Tese........................................................................ 3
2. Âmbito dos Sistemas de Localização e Gestão ............................................................... 5
2.1 Tecnologias de Localização ............................................................................... 5
2.2 Tecnologia de Comunicação GSM..................................................................... 8
2.3 Visão Global dos Sistemas Existentes no Mercado ........................................... 9
2.3.1 Xtran Gestão de Frotas .......................................................................................... 9
2.3.2 NVfrotasoft.......................................................................................................... 11
2.3.3 Moviloc ................................................................................................................ 13
2.3.4 Outras Soluções no Mercado ............................................................................... 14
2.3.5 Comparação das Soluções Descritas ................................................................... 15
2.4 Exemplos de Dispositivos GPS Tracking ........................................................ 16
2.4.1 G959 GPS Tracking ............................................................................................ 16
2.4.2 HCT PRO Plus .................................................................................................... 17
2.4.3 QTracker GT-Q3000 ........................................................................................... 18
2.5 Comparação das Soluções Apresentadas ......................................................... 19
3. Caraterização do Problema ......................................................................................... 21
3.1 Exposição do Problema ................................................................................... 21
3.2 Requisitos do Sistema ...................................................................................... 21
3.3 Restrições do Sistema ...................................................................................... 22
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
x
3.4 Especificações de Hardware............................................................................ 23
3.4.1 Modem GSM, Telit EZ10-GPRS ........................................................................ 24
3.4.2 Unidade de Localização Móvel ........................................................................... 24
3.5 Especificações de Software .............................................................................. 30
3.5.1 Interface com os Utilizadores .............................................................................. 30
3.5.2 Software Adotado para o Desenvolvimento da Unidade Móvel ......................... 39
4. Arquitetura e Desenvolvimento do Sistema ................................................................ 41
4.1 Visão Global do Sistema .................................................................................. 41
4.2 Modelo Relacional ........................................................................................... 44
4.2.1 Relacionamento entre Entidades ......................................................................... 45
4.3 Centro de Controlo ........................................................................................... 49
4.3.1 Interface entre os Processos ................................................................................ 50
4.3.2 Background Service ............................................................................................. 52
4.3.3 Aplicação Gráfica ................................................................................................ 65
4.4 Posto de Trabalho ............................................................................................ 65
4.4.1 Página Web .......................................................................................................... 67
4.4.2 Inclusão dos Mapas da Google ............................................................................ 71
4.5 Terminal do Condutor ...................................................................................... 81
4.5.1 Visão Global da Aplicação .................................................................................. 81
4.5.2 Atividades............................................................................................................ 82
4.5.3 Broadcast Receiver (Filtragem de Mensagens de Texto) .................................... 83
4.5.4 Serviço Executado em Background .................................................................... 84
4.5.5 QRcode Scanner .................................................................................................. 86
4.6 Unidade Móvel ................................................................................................ 88
4.6.1 Processos de Software ......................................................................................... 89
4.6.2 Comunicação com a Unidade Móvel ................................................................ 103
5. Testes e Resultados Obtidos ..................................................................................... 107
5.1 Unidade Móvel .............................................................................................. 107
5.2 Centro de Controlo ......................................................................................... 111
5.3 Posto de Trabalho .......................................................................................... 115
5.4 Terminal do Condutor .................................................................................... 119
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xi
6. Conclusão e Trabalho Futuro .................................................................................... 125
6.1 Conclusões ..................................................................................................... 125
6.2 Trabalho Futuro ............................................................................................. 126
Bibliografia ...................................................................................................................... 129
Apêndice A ...................................................................................................................... 133
A.1 Protocolo NMEA ............................................................................................ 133
A.2 Caraterísticas do Modem GSM ...................................................................... 135
A.3 Características do recetor GPS FGPMMOPA6B .......................................... 135
A.4 Comandos AT ................................................................................................. 136
A.5 Dicionário de Dados ...................................................................................... 137
A.6 Aplicação Posto de Trabalho ......................................................................... 139
A.7 Funcionalidades do Posto de Trabalho .......................................................... 146
A.7.1 Visualização da Posição Geográfica do Veiculo ............................................... 146
A.7.2 Serviços Terminados ......................................................................................... 147
A.7.3 Verificação de rotas percorridas ........................................................................ 149
A.8 Aplicação Terminal do Condutor .................................................................. 150
A.8.1 Declarar Atividades ........................................................................................... 150
A.9 Circuitos e Esquemáticos da Unidade Móvel ................................................ 151
A.9.1 Placa desenvolvida ............................................................................................ 151
A.9.2 Esquemático em Eagle ...................................................................................... 154
A.9.3 GPIO ................................................................................................................. 155
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xii
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xiii
Índice de Figuras
Figura 1 - Arquitetura da rede GSM, [10]. ....................................................................... 8
Figura 2 - Overview da solução Xtran, [11]. .................................................................... 9
Figura 3 - Geração de relatórios informando distâncias percorridas, velocidades entre
outos na forma de gráficos, [11]. .................................................................................... 10
Figura 4 - Equipamentos de hardware que compõem a ferramenta Xtran: consola
"Dispatch & Navigation", unidade móvel e exemplares do terminal do condutor
respetivamente, [11]. ...................................................................................................... 11
Figura 5 - Módulos que compõem a solução NVfrotasoft e interação dos mesmos, [13].
........................................................................................................................................ 12
Figura 6 - A visualização da posição dos veículos (entre outras informações) na
ferramenta NVfrotasoft é realizada sobre um mapa, [13]. .............................................. 12
Figura 7 - Funcionamento da ferramenta Moviloc desde o processo inicial de recolha de
dados até ao objetivo final que consiste na apresentação da informação relevante ao
utilizador, [14]. ............................................................................................................... 13
Figura 8 - Equipamento MOVILOC® instalado no veículo, [14]. ................................. 14
Figura 9 - Imobilização veículo de forma remota, por ordem do Centro de Controlo,
[14]. ................................................................................................................................ 14
Figura 10 - Componentes constituintes do produto G959 GPS Tracker, [16]. .............. 16
Figura 11 - Dispositivo HCT PRO PLUS utilizado na localização de veículos, [17]. ... 17
Figura 12 - Modem Telit EZ10-GPRS, [21] . .................................................................. 24
Figura 13 - Conversor step-down PTN78060 W, [24]. ................................................... 26
Figura 14 - Aspeto físico do recetor GPS FGPMMOPA6B, [25]. ................................. 27
Figura 15 - Diagrama de blocos do módulo recetor GPS selecionado para o projeto,
[25]. ................................................................................................................................ 27
Figura 16 - Módulo GSM da Siemens, TC-3, [26]. ......................................................... 28
Figura 17 - Instalação do sistema de corte da bomba. .................................................... 30
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xiv
Figura 18 - Funcionalidades do sistema do ponto de vista do Gestor. ........................... 31
Figura 19 - Funcionalidades a suportar pela interface do Gestor. .................................. 32
Figura 20 - Funcionalidades da ferramenta IntelFleet do ponto de vista do Condutor. . 33
Figura 21 - Funcionalidades que a interface do Condutor deve suportar. ...................... 34
Figura 22 - Funcionalidades da ferramenta do ponto de vista do coordenador. ............. 37
Figura 23 - Funcionalidades suportadas pelo posto de trabalho. .................................... 37
Figura 24 - Visão Global do sistema IntelFleet. ............................................................. 42
Figura 25 - Modelo Entidade-Relação da base de dados criada para o sistema IntelFleet.
........................................................................................................................................ 44
Figura 26 - Relacionamento de várias entidades com a entidade central, “Servicos”. ... 46
Figura 27 - Relação de uma para vários entre as entidades Historico_Servico e Servicos.
........................................................................................................................................ 47
Figura 28 - Relação entre as entidades Driver e veiculo. ............................................... 47
Figura 29 - Trigger responsável por remover ligação de um condutor a um veículo
removido. ........................................................................................................................ 48
Figura 30 - Arquitetura do Centro de Controlo. ............................................................. 49
Figura 31 - Interação Serviço-Aplicação gráfica na aplicação Centro de Controlo. ...... 50
Figura 32 - Comunicação entre aplicação gráfica e o background service via sockets. . 51
Figura 33 - Processo de Start-up da aplicação executada em background. ................... 53
Figura 34 - Algoritmo de configuração do modem GSM. .............................................. 54
Figura 35 - Fluxograma do subsistema de aquisição dos dados em modo periódico. .... 56
Figura 36 - Fluxograma do subsistema de aquisição de dados no modo “on-demand”. 57
Figura 37 - Comportamento sobre a forma de fluxograma do subsistema de
Comunicação durante receção de informação. ............................................................... 58
Figura 38 - Comportamento sobre a forma de fluxograma do subsistema de
Comunicação durante o envio de informação. ............................................................... 60
Figura 39 - Algoritmo do subsistema de tratamento de dados. ...................................... 61
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xv
Figura 40 - Hosts com acesso permitido à base de dados. ............................................. 65
Figura 41 - Visão Global da aplicação Posto de Trabalho. ............................................ 66
Figura 42 - Pesquisa de dados armazenados no servidor. .............................................. 69
Figura 43 - Interação entre as diferentes camadas durante a requisição assíncrona. ...... 70
Figura 44 - Exemplo do ficheiro XML enviado como resposta pelo servidor. ............... 71
Figura 45 - Aspeto encontrado pelo utilizador quando pretende conhecer a posição
geográfica dos veículos sobre um mapa. ........................................................................ 73
Figura 46 - Processo de inserção da localização do veículo no mapa. ........................... 74
Figura 47 - Marcadores interativos. ................................................................................ 74
Figura 48 - Página 'querys.php' após a primeira requisição ao servidor. ....................... 75
Figura 49 - Fluxo de informação gerado durante a pesquisa de tarefas já realizadas. ... 76
Figura 50 - Exemplo da resposta do servidor ao pedido de informações dos pontos
geográficas percorridos durante a execução de um dado serviço. .................................. 77
Figura 51 - Algoritmo implementado para a deteção de trajetos indesejados. ............... 78
Figura 52 - Informação relevante para o planeamento de novos serviços...................... 80
Figura 53 - Overview da aplicação Terminal do Condutor. ........................................... 81
Figura 54 - Processo iniciado após receção de mensagem de texto. .............................. 84
Figura 55 - Módulo Serviço executado em background na aplicação Android (detetar
novas tarefas definidas pelos coordenadores no Posto de Trabalho). ............................ 85
Figura 56 - Notificação ao utilizador de prazo de execução da tarefa a expirar,
IntelFleet_warn e IntelFleet_gps_warn respetivamente. ................................................ 86
Figura 57 - Processo de registo de veículos. .................................................................. 87
Figura 58 - Registo de veículos utilizando o Barcode Scanner. .................................... 88
Figura 59 - Visão global da Unidade Móvel sobre a forma de blocos. .......................... 88
Figura 60 - Processo de Start-up. ................................................................................... 90
Figura 61 - Procedimentos executados durante a inicialização do Receiver GPS. ......... 91
Figura 62 - Diagrama temporal do processo de recolha de dados GPS. ........................ 92
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xvi
Figura 63 - Processo de inicialização do módulo GSM. ................................................. 92
Figura 64 - Algoritmo percorrido durante o processo de verificação de falhas no
dispositivo. ...................................................................................................................... 94
Figura 65 - Determinação do evento que gerou interrupção. ......................................... 95
Figura 66 - Interpretação de comandos. ......................................................................... 96
Figura 67 - Identificação do modo de atualização de dados solicitado. ......................... 97
Figura 68 - Algoritmo de extração dos parâmetros GPS solicitados. ............................. 98
Figura 69 - Algoritmo implementado na função Parse_GPS. ....................................... 99
Figura 70 - Processo de envio dos parâmetros solicitados. .......................................... 100
Figura 71 - Fluxo de informação durante o bloquei do veículo. .................................. 101
Figura 72 - Instruções da função Verify_fix.................................................................. 102
Figura 73 - Fluxograma da função ‘Fix_detect’. .......................................................... 103
Figura 74 - Frases NMEA transmitidas pelo receiver. .................................................. 109
Figura 75 - Frase NMEA recebida, proveniente do output do Receiver e variáveis de
interesse extraídas do output. ....................................................................................... 109
Figura 76 - Ponto geográficos obtidos durante o teste da aquisição de dados do
dispositivo móvel numa posição fixa (ponto A). .......................................................... 111
Figura 77 - Resultado ao teste de verificação do serviço. ............................................ 112
Figura 78 - Verificação do estado do background service. .......................................... 112
Figura 79 - Resultado obtido após forçar o início do serviço. ...................................... 112
Figura 80 - Gestor de serviço do Windows. .................................................................. 113
Figura 81 - Dados dos condutores registados na base de dados ................................... 113
Figura 82 - Inserção de um cliente na base de dados. .................................................. 114
Figura 83 -Notificação da atualização de dados. .......................................................... 115
Figura 84 - Detalhes do condutor com o id=1; ............................................................. 115
Figura 85 -Parâmetros que caraterizam uma tarefa. ..................................................... 116
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xvii
Figura 86 - Informações do veículo, antes do condutor ter conhecimento da nova tarefa.
...................................................................................................................................... 116
Figura 87 - Tabela com os serviços que se encontram por realizar. ............................. 117
Figura 88 - Rota definida para a tarefa pelo coordenador. ........................................... 117
Figura 89 - Registos dos pontos na base de dados. ...................................................... 117
Figura 90 - Aspeto da imagem após consulta do trajeto percorrido pelo veículo. ....... 118
Figura 91 - Teste do processo responsável por detetar trajetórias indesejáveis. .......... 118
Figura 92- Conteúdo do ficheiro XML obtido no teste ao processo de autenticação ... 119
Figura 93 - Tela durante processo de login e tela seguinte (Menu da aplicação, notifica
utilizador quando iniciado o background service). ...................................................... 119
Figura 94 - Gestor de aplicações apresenta detalhes da aplicação, espaço ocupado,
tempo de execução e componentes a correrem (serviço). ............................................ 120
Figura 95 - Parâmetros enviados durante requisição de atualização “on-demand”,
número do localizador e texto da mensagem................................................................ 120
Figura 96 - Telas durante o pedido de atualização da localização ............................... 120
Figura 97 - Estado da mensagem, enviada com sucesso. ............................................. 121
Figura 98 - Estado da mensagem, recebida pela unidade móvel. ................................. 121
Figura 99 - QRcode gerado a partir do texto "728-12-DN". ........................................ 121
Figura 100 - Texto após o scanner ter sido realizado................................................... 121
Figura 101 - Resultado positiva após o processo de registo de veículos, alterados com
sucesso os campos necessários que traduzem a mudança de veículo à organização. .. 122
Figura 102 - Tabela “Driver” após alterações dos campos influenciados por esta
mudança levada a cabo durante o teste. ........................................................................ 122
Figura 103 - Identificação do conteúdo da mensagem de texto proveniente da unidade
móvel. ........................................................................................................................... 122
Figura 104 - Localização correspondente as coordenadas transmitidas pela unidade
móvel. ........................................................................................................................... 123
Figura 105 - Resultado da atualização “on-demand”. .................................................. 123
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xviii
Figura 106 - Ficheiro XML, contêm os dados relativos à tarefa criada ao longo do teste.
...................................................................................................................................... 123
Figura 107 - Resultado do processo de "escuta" de novas tarefas durante o teste
realizado........................................................................................................................ 124
Figura 108 - Conetores utilizados para interface com o modem. ................................. 135
Figura 109 - Consulta dos dados requisitados utilizando os comandos SQL. .............. 141
Figura 110 - Aquisição dos dados resultantes de uma consulta à base de dados. ........ 141
Figura 111 - Incorporar informação coletada num ficheiro XML. ............................... 142
Figura 112 - Função "callback" definida como função de retorno. .............................. 142
Figura 113 - Carregar para página HTML a API do Google Maps. ............................. 144
Figura 114 - Criação de uma instancia da classe Map. ................................................ 145
Figura 115 - Configuração do objeto Map. .................................................................. 145
Figura 116 - Geração de rotas com passagem em pontos de referência utilizando API do
Google Maps. ............................................................................................................... 149
Figura 117 - Implementação do método onCreate da classe Activity. ......................... 150
Figura 118 - Exemplo da estrutura do ficheiro Android Manifest.xml. ....................... 150
Figura 119 - Aspeto físico da placa desenvolvida. ....................................................... 151
Figura 120- Montagem do receiver GPS. ..................................................................... 152
Figura 121 - Esquema de ligação da fonte comutada PTN78060W............................. 153
Figura 122 - Circuito elevador de tensão. .................................................................... 153
Figura 123 - Divisor de tensão como meio de baixar o nível de tensão. ...................... 154
Figura 124 - Circuito de bloqueio do veículo. .............................................................. 154
Figura 125 - PCB desenvolvida para a Unidade Móvel. .............................................. 155
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xix
Índice de Tabelas
Tabela 1 - Descrição das principais mensagens padronizadas pela NMEA ..................... 7
Tabela 2 - Comparação entre as soluções apresentadas/estudadas. ................................ 15
Tabela 3 - Características do GPS tracker integrado com o dispositivo G945............... 17
Tabela 4 - Características do dispositivo HCT PRO Plus. ............................................. 18
Tabela 5 - Características do dispositivo QTracker. ...................................................... 18
Tabela 6 - Comparação dos módulos GPS Tracker analisados. ..................................... 19
Tabela 7 - Descrição dos pinos I/O do recetor GPS. ...................................................... 27
Tabela 8 - Descrição dos principais sistemas operativos no mercado de dispositivos
móveis. ............................................................................................................................ 35
Tabela 9 - Comparação entre as API’s da Google e Yahoo Maps. ................................. 38
Tabela 10 - Descrição das entidades/tabelas que compõem a base de dados
intelfleet_mydb. .............................................................................................................. 45
Tabela 11 - Comandos provenientes da interface gráfica reconhecidos pelo serviço. ... 62
Tabela 12 - Associação de ficheiros por funcionalidade, desde seu aspeto (HTML) até ao
ficheiro (JavaScript) responsável por efetuar as requisições ao servidor e por fim o
arquivo que processa estes pedidos. ............................................................................... 68
Tabela 13 - Conjunto de Atividades que compõem a aplicação Terminal do Condutor. 83
Tabela 14 - Descrição dos comandos AT necessários durante a configuração do modem
GSM. ............................................................................................................................... 93
Tabela 15 - Funções de resposta ao evento. ................................................................... 95
Tabela 16 - Comandos AT usados durante o processo de envio dos parâmetros. ........ 101
-Tabela 17 - Formato das mensagens reconhecidas pela Unidade Móvel .................... 104
Tabela 18 – Parâmetros da mensagem da unidade móvel como resposta às solicitações
de atualização de dados. ............................................................................................... 105
Tabela 19 - Casos de teste utilizados para prevenir erros no produto final. ................. 108
Tabela 20 - Resultados do teste as atualizações periódicas. ......................................... 110
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xx
Tabela 21- Dados GPS adquiridos durante a realização da tarefa. ............................... 114
Tabela 22 - Campos da frase GPRMC. ........................................................................ 133
Tabela 23 - Campos da frase GPRMC relevantes para o cálculo da latitude. .............. 134
Tabela 24 - Campos da frase GPRMC relevantes para o calculo da latitude. .............. 134
Tabela 25 - Características do modem GSM (Telit EZ10-GPRS). ............................... 135
Tabela 26 - Características do receiver GPS. ............................................................... 136
Tabela 27 - Principais comandos AT. ........................................................................... 137
Tabela 28 - Parâmetros do objeto XMLHttpRequest. ................................................... 140
Tabela 29 - Parâmetros recebidos pela função mysql_connect(). ................................. 141
Tabela 30 - Parâmetros recebidos pela função mysql_select_db(). .............................. 141
Tabela 31 - Estados da interação HTTP. ...................................................................... 143
Tabela 32 - Funções de auxílio utilizadas pela função ‘ParseMessages()’. ................. 143
Tabela 33 - Construtor google.maps.Map().................................................................. 145
Tabela 34 - Parâmetros a incluir no objeto ‘DirectionsRequest’ e entidade onde estão
armazenados os valores com que estes são iniciados. .................................................. 148
Tabela 35 - Pinos do microcontrolador utilizados. ....................................................... 155
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xxi
Abreviaturas
ADC – Analog-to-Digital Converter
AVL – Automatic Vehicle Location
C/A – Código de Aquisição Inicial
DAC – Digital-toAnalog Converte
DoD – Departamento de Defesa dos
EUA
DOM – Document Object Model
EEPROM – Electrically-Erasable
Programmable Read-Only Memory
GPRS – General Packet Radio Service
GPS – Sistema de Posicionamento
Global
GSM – Global System for Mobile
Communications
HTML – HyperText Markup Language
IPC – Inter Process Communication
LBS – Location Based Services
ME – Estação Móvel
NAVSTAR – Navigation System by
Time and Rancing
NMEA – National Marine Electronics
Association
SQL – Structured Query Language
P Code – Código de Precisão
PCB – Placa de Circuito Impresso
PDU – Protocol Data Unit
PHP – Hypertext Preprocesso
XML – eXtensible Markup Language
SMS – Mensagem de Texto
SPI – Serial Peripheral Interface Bus
SRAM – Static Random Access
Memory
URL – Uniform Resource Locator
USART – Universal Synchronous
Asynchronous Receiver Transmitter
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
xxii
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
1
1. Introdução
Neste capítulo são explicadas as motivações inerentes ao desenvolvimento da
solução, onde é feita a contextualização deste projeto, dado a conhecer os seus
objetivos, metas a atingir e por fim é realizada uma descrição da organização
documental.
1.1 Objetivos
O presente trabalho apresenta como objetivo sumário, o desenvolvimento de um
sistema de localização/tracking e gestão de frotas. Para cumprimento deste propósito,
são exigidas etapas essenciais como a planificação, a implementação e a interação entre
os elementos que constituirão o sistema.
Os objetivos inerentes à etapa da planificação referem-se ao estudo e aquisição dos
dispositivos necessários à montagem do dispositivo eletrónico de receção e envio de
coordenadas GPS que constituem a unidade móvel, a definição dos parâmetros a serem
transmitidos entre os diferentes elementos que constituirão o sistema e que melhor
gestão proporciona devido à continua atualização, a definição das variáveis a
monitorizar, a escolha das ferramentas para desenvolvimento das diferentes interfaces
gráficas e por último, o estudo de métodos para bloqueio do veículo em caso de roubo
sem o danificar.
Na etapa de implementação, objetiva-se a construção dos diferentes elementos que
constituem o sistema, podendo ser divididos em elementos de hardware (plataforma
física instalada no veículo) e software (aplicações que tratam as informações recolhidas
sobre os veículos e a disponibilizam ao utilizador).
Na etapa de integração, pretende-se criar a ligação entre os diferentes elementos,
baseando-se numa comunicação sem fios. A plataforma física transmite as coordenadas
geográficas via GSM para a unidade central da ferramenta IntelFleet, neste ponto são
atualizadas as informações relativas ao veículo e condutor em questão. Estando desde
então a informação atualizada e disponível aos diferentes utilizadores, por intermédio
das aplicações desenvolvidas para o efeito.
De forma a automatizar o sistema, pretende-se que um conjunto de funcionalidades seja
concedido aos diferentes utilizadores consoante as suas tarefas na organização. Quando
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
2
os clientes requerem novos serviços, estes deverão ser planeados com o auxílio de
informação relevante e sempre atualizada. A ferramenta IntelFleet deverá disponibilizar
de forma gráfica esta informação ao utilizador responsável pela sua execução
(motorista), através de uma aplicação de software a correr sobre um smartphone/tablet.
Durante a realização dos serviços os utilizadores devem ser capazes de seguir a sua
execução em tempo real. Outra funcionalidade pretendida é a prevenção de roubos das
viaturas, isto é, o condutor deve ter meios que lhe permita imobilizar o veículo de forma
remota e ainda de conhecer a localização geográfica do veículo sempre que desejar. Isto
permite em situações de furto do veículo/mercadoria conhecer o seu paradeiro,
facilitando a sua recuperação. Estas são das funcionalidades mais relevantes que a
ferramenta deve fornecer aos utilizadores.
1.2 Motivações
É sabido que a partir de uma eficiente gestão de frotas é possível reduzir os
gastos inerentes às viagens, como tempos de utilização indevidos dos veículos por parte
dos funcionários, aperfeiçoar rotas e aumentar a rapidez de resposta aos clientes [3],
permite ainda agendar com antecedência tarefas com base na localização dos veículos
aumentando a produtividade da empresa [4]. Para alcançar estes objetivos é necessário
gerir adequadamente uma frota, aplicando o conceito de inteligência de negócios.
Cada vez mais se requer uma melhor compreensão das variáveis de negócio que
orientam a empresa com objetivo de tomar melhores decisões, baseadas na melhor
informação. É neste contexto que surge a inteligência de negócios, como apoio
fundamental da tomada de decisões, este conceito refere-se ao processo de recolha,
organização, análise, compartilhamento e monitoramento de informações que oferecem
suporte a gestão de negócios [5]. Para as organizações da área do tema dissertado obter
eficientemente estas características, necessitam de bons gestores integrados de frotas na
organização, sendo esta necessidade atualmente reconhecida bem como as vantagens
obtidas na utilização destas ferramentas, conduzindo as empresas a adquirir sistemas
competitivos de modo a aumentar a produtividade.
Assim, verifica-se que esta é uma área em ascensão, longe de atingir a maturidade [6],
resultando tudo isto num excelente ponto de partida no desenvolvimento de um sistema,
que vai de encontro às necessidades e contexto atual das empresas: arranjar soluções
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
3
simples, competitivas, mas de baixo custo em busca do seu principal objetivo no
mercado que é destacar-se dos seus concorrentes e reduzir os seus custos.
Como estudante de engenharia eletrónica industrial e computadores e adotando este
facto como ponto de partida, encontro uma forte motivação e entusiasmo no
desenvolvimento de tal sistema num contexto empresarial, que colocará constantemente
os meus conhecimentos a prova.
1.3 Organização e Estrutura da Tese
A presente dissertação encontra-se organizada em sete capítulos, que conduzem
desde a conceção inicial da ferramenta até à solução final proposta, acrescentando ainda
possíveis futuros desenvolvimentos.
O primeiro capítulo é composto por três secções, onde são abordadas as motivações do
trabalho descrito, os objetivos fundamentais a atingir e ainda informação da estrutura da
tese.
O segundo capítulo abrange toda a pesquisa realizada, o estudo da arte de sistemas
existentes no mercado, e uma descrição das tecnologias utilizadas na criação da
ferramenta proposta.
O terceiro capítulo aborda as especificações do sistema como as escolhas de software e
hardware que suportam a implementação da ferramenta desenvolvida.
O capítulo quatro encontra-se dividido em seis subcapítulos e tem como objetivo
descrever a arquitetura geral do sistema e a implementação dos diferentes módulos
constituintes da ferramenta IntelFleet, apresentado posteriormente no quinto capítulo os
diferentes testes realizados seguidos de uma discussão dos resultados obtidos.
O capítulo que finaliza o presente documento apresenta as conclusões finais do projeto e
ainda algumas sugestões de trabalhos possíveis de realizar no futuro.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
4
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
5
2. Âmbito dos Sistemas de Localização e Gestão
O presente capítulo descreve e compara os vários sistemas de gestão e
localização de frotas disponíveis no mercado. Como introdução à descrição é
apresentada as principais tecnologias que constituem estes sistemas.
2.1 Tecnologias de Localização
Atualmente, encontram-se disponíveis as seguintes tecnologias de localização: o
europeu Galileo, o russo GLONASS, o chinês COMPASS, o indiano IRNSS e o
americano GPS [7]. Este último é o sistema mais conhecido e utilizado, sendo que todos
os restantes sistemas têm por base o princípio de funcionamento do sistema americano.
O Sistema de Posicionamento Global (GPS) foi desenvolvido na década de 1970/80
pelo Departamento de Defesa dos EUA (DoD), destinado inicialmente ao exército
americano, estando como segundo plano a sua utilização para fins não militares. Na
década de 90 os utilizadores civis estavam limitados quanto à sua utilização, apenas
alguns sinais imitidos por GPS lhes eram destinados, mas apesar destas limitações a
taxa de aplicações civis cresceu surpreendentemente. Graças às atividades em que este
sistema é aplicado, se adivinha que o seu caminho é se tornar numa parte essencial do
comércio e infraestrutura pública.
Atualmente esta tecnologia é empregada numa enorme variedade de aplicações [3], tais
como:
Localização de veículos, particularmente útil quando estes são roubados;
Gestores de frotas e roteamento de veículos beneficiam desta tecnologia
indiretamente;
Localizar pessoas, estas podem ser equipadas com recetores GPS de modo a
conhecer o seu paradeiro, bastante útil em pacientes com distúrbios mentais e
ainda ao nível da segurança, quando aplicado em prisioneiros em liberdade
condicional;
Estudo do movimento e comportamento da vida selvagem, útil para os cientistas
que desejam conhecer mais sobre animais selvagens, como exemplo segue o
sistema ZebraNet aplicado numa zebra retornando sua posição a cada três
minutos [8].
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
6
O sistema GPS consiste numa constelação de 24 satélites que orbitam a Terra, esta
disposição nos planos orbitais garante que pelo menos quatro satélites estejam
simultaneamente visíveis em qualquer ponto do planeta.
O princípio de funcionamento do GPS é bastante simples, a nossa posição pode ser
determinada se medirmos a distância a cada um de três satélites visíveis, cujas posições
são conhecidas. Na verdade, os satélites estão em movimento no espaço a uma
velocidade aproximada de 4 km por segundo, mas a posição pode ser obtida em
qualquer instante, a partir da mensagem de transmissão emitida pelo satélite. Estes
transmitem dois sinais de rádio, designados de L1 e L2 a uma frequência 1575,42 MHz
e 1227,60 respetivamente, mas o sinal de cada satélite é transmitido a uma modulação
diferente, sob forma de código, permitindo facilmente a identificação do satélite ao
recetor GPS [7]. Estas modulações consistem de um Código de Precisão (P Code2) e de
um Código de Aquisição Inicial (C/A – Coarse Acquisition Code). A portadora L1
contém as ambas modulações em código, enquanto a L2 contém apenas o Código P.
Esta modulação é acessível apenas para utilizadores militares norte-americanos e outras
agências dos EUA. Por sua vez, o Código C/A encontra-se acessível para os demais,
assim os recetores são capazes de medir as distâncias obtidas pela duração do trajeto
(intervalo de tempo) do sinal de rádio entre os satélites e o recetor. Além da distância, é
necessário também conhecer as posições dos satélites GPS, esta informação encontra-se
disponível na mensagem de navegação, pois esta contém todos os dados necessários
para o cálculo da posição do satélite no instante da medição da distância entre recetor e
satélite.
Presentemente os recetores GPS suportam o protocolo NMEA, este protocolo foi
instituído pela National Marine Electronicas Association (NMEA) e baseia-se no envio
e receção de tramas de texto em ASCII com conteúdo e sinalização específica [9]. Este
protocolo surgiu com intuito de padronizar todas as mensagens, implicando que elas
respeitem as normas estabelecidas pela NMEA. As mensagens devem possuir a seguinte
sintaxe:
$<dispositivo><Id da mensagem>, <campo de dados>, <campo de
dados>,…*<checksum> <CR> <LF>
2 Modelação acessível apenas a utilizadores militares norte-americanos.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
7
As mensagens começam com o carater “$” seguidas de um prefixo de duas letras que
definem o tipo de dispositivo que está a ser utilizado (GP para recetores GPS), seguido
pelo identificador da mensagem recebida constituído por três letras. Os campos de
dados são sempre separados por vírgulas, sendo seguido pelo checksum, o último campo
é utilizado para verificar a integridade do conteúdo da trama. O carater de controlo “*” é
utilizado para preceder o checksum permitindo aos recetores facilmente o identificar,
este nada é mais que dois dígitos hexadecimais que representam um ou exclusivo (XOR)
de oito bits de todos os carateres entre, “$” e “*”.
Como referido anteriormente, existe um campo identificador do tipo de mensagem, isto
se deve ao facto de existir vários tipos de mensagens NMEA, cada uma com uma
designação própria, que indica os tipos de dados que compõem a mensagem. A Tabela 1
apresenta as principais mensagens NMEA que poderemos encontrar.
Tabela 1 - Descrição das principais mensagens padronizadas pela NMEA
ID da Mensagem Descrição GGA Posição geográfica precisa – latitude, longitude e altitude
GLL Posição geográfica - latitude e longitude
VTG Dados relativos ao deslocamento – velocidade
RMC Dados temporais – data e hora
A seguinte trama é apresentada como exemplo de uma possível mensagem recebida por
um recetor: $GPGLL, 4825.56, N,13412.21,W,203225,A,*1D.
Onde:
GP indica que a mensagem foi enviada por um dispositivo GPS;
GLL indica que a mensagem contém informação relativa à localização (latitude e
longitude);
4825.56, Latitude 48 graus e 25.56 minutos Norte (N);
13412.21, Longitude 134 graus 12.21 minutos Oeste (W);
203225, FIXO às 20:32:25 UTC;
A, Dados Active (ativo) ou Void (sem nada);
*1B, checksum.
Uma descrição mais detalhada das mensagens recebidas no protocolo NMEA encontra-
se disponível para consulta no anexo A.1 (Protocolo NMEA).
As alternativas de sistemas de localização, desenvolvidos posteriormente como é o caso
do europeu Galileo, dispõem de um maior número de satélites, atualmente são 30
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
8
satélites que constituem o sistema, o que resulta num maior número de satélites visíveis
em qualquer ponto terrestre, de 6 a 8. Impondo assim, uma maior precisão quando
comparado com o americano GPS [7].
2.2 Tecnologia de Comunicação GSM
O Global System for Mobile Communications (GSM), é o sistema mais popular
para comunicações de longo alcance utilizado em dispositivos móveis. Foi desenvolvido
na Europa e introduzido no mercado no ano 1991, tendo crescido imediatamente a taxa
da sua utilização, contando presentemente com mais de um bilhão de telefones que
utilizem o sistema. O GSM é o primeiro sistema móvel no mundo a especificar
modulação digital e arquiteturas de serviços de nível de rede, concebido com o
propósito de resolver problemas de fragmentação dos primeiros sistemas na Europa.
O padrão GSM utiliza as frequências 900MHz na Europa e 850MHz nos Estados
Unidos na América e é composto por várias entidades com funções e interfaces
específicas [10]. A rede GSM pode então ser dividida em três grandes grupos: a Estação
Móvel (ME), o Subsistema de Estação Base e o Subsistema de Rede como apresentado
na Figura 1.
Figura 1 - Arquitetura da rede GSM, [10].
De forma resumida, a Estação Móvel consiste na integração do dispositivo móvel
transportado pelo subscritor do serviço com o cartão SIM, enquanto o Subsistema da
Estação Base controla a ligação com o primeiro. O Subsistema de Rede tem a função de
controlar as ligações entre Estação Móvel e os outros subscritores de redes móveis ou
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
9
fixas, assim como o controlo da mobilidade que permite ao subscritor variar a sua
localização física durante a transferência de dados/voz. Os principais serviços
fornecidos pelo sistema GSM são os seguintes:
Comunicação de voz;
Serviço de SMS;
2.3 Visão Global dos Sistemas Existentes no Mercado
É possível encontrar atualmente no mercado, uma enorme variedade de sistemas
de gestão de frotas, com uma grande diversidade de tecnologias bem como
funcionalidades concebidas ao cliente. De seguida serão apresentadas algumas soluções,
sendo abordadas as funcionalidades fornecidas, as vantagens, o custo do produto no
mercado atual e quais as tecnologias empregadas no sistema de forma a distinguir a
ferramenta IntelFleet dos demais.
2.3.1 Xtran Gestão de Frotas
O XTran Gestão de frotas é uma ferramenta desenvolvida pela empresa Tecmic,
é descrita como uma ferramenta essencial na gestão de todos os recursos que
desenvolvem o seu trabalho fora da empresa (viaturas e condutores), baseados numa
arquitetura Cliente/Servidor [11]. O XTran permite a gestão através de informações
recebidas de forma automática pelo equipamento instalado nos veículos. Este sistema é
constituído por um sistema central que permite à organização gerir toda atividade,
comunicando com todas as unidades instaladas nos veículos como ilustrado na Figura 2,
através de vários meios de comunicação (GSM, GPRS, CDMA entre outros).
Figura 2 - Overview da solução Xtran, [11].
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
10
Com uma comunicação bidirecional e atualização em “tempo real” da informação das
viaturas, o XTran permite conhecer em qualquer momento o estado dos veículos, inserir
e localizar locais, traçar rotas percorridas e alertar passagem por zonas previamente
delimitadas. A ferramenta descrita evita a utilização de relatórios escritos, optando por
apresentar toda essa informação de forma gráfica, uma interface mais amigável do
ponto de vista do utilizador, como apresentado na Figura 3.
Figura 3 - Geração de relatórios informando distâncias percorridas, velocidades entre outos na forma de
gráficos, [11].
O equipamento instalado é composto por uma consola para auxílio de navegação (ecrã
tátil de alta resolução e grandes dimensões), um módulo eletrónico (unidade móvel) que
integra um recetor do sistema GPS e um terminal de comunicação móvel que estabelece
comunicação com a central. Este equipamento disponibiliza várias entradas digitais e
analógicas, para ligação de periféricos (impressora, sensores etc.) de acordo com as
necessidades do utilizador. A comunicação entre o condutor e a central/gestor é
estabelecida através de um equipamento extra, designado de Terminal do Condutor. É
um equipamento portátil com autonomia semelhante aos exemplares apresentados na
Figura 4, pelo que pode ser removido do veículo e utilizado pelo condutor para registar
dados referentes ao serviço (entregas, confirmações de clientes, etc.).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
11
Figura 4 - Equipamentos de hardware que compõem a ferramenta Xtran: consola "Dispatch & Navigation",
unidade móvel e exemplares do terminal do condutor respetivamente, [11].
A Tecmic disponibiliza uma interface para empresas que já contam com o XTran
instalado. É baseado na versatilidade dos Browsers da internet, possibilitando a
realização de consultas por parte de utilizadores autorizados a informações das
atividades desenvolvidas pelas frotas. Permitindo assim, acesso aos dados da frota em
qualquer local, desde que possua acesso à internet [12].
2.3.2 NVfrotasoft
A NVfrotasoft é uma solução de gestão de frotas via GPS/Web, com grandes
semelhanças da solução anteriormente apresentada, distinguindo-se do mesmo por
utilizar como meio de comunicação exclusivamente a rede GSM e por ser uma
ferramenta de gestão unicamente online. Esta ferramenta possibilita acompanhar em
tempo real a atividade da frota e visualizar todos os relatórios gerados. Na Figura 5 é
descrito graficamente os funcionamentos do NVfrotasoft, os veículos encontram-se
equipados com um localizador GPS compacto e fiável, enviando constantemente
informações via GSM para o data center onde é processada, organizada e armazenada
em servidores de elevada segurança. Estes servidores estão conectados via internet,
possibilitando ao utilizador o acesso a estes em qualquer parte do mundo. Os clientes
proprietários da ferramenta NVfrotasoft podem gerir níveis de acesso ao software,
protegendo os seus dados e privacidade [13].
A ferramenta proporciona ao utilizador a configuração de toda a informação, de forma a
simplificar a sua utilização, assim define quais as variáveis a ser analisadas e
incorporadas nos relatórios de gestão. Estes relatórios incluem informação de paragens,
passagem por marcos, velocidades, entre outros. Podendo ser enviados automaticamente
para os endereços de e-mail previamente configurados.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
12
Figura 5 - Módulos que compõem a solução NVfrotasoft e interação dos mesmos, [13].
Os veículos são dotados de um equipamento recetor de GPS e de um terminal
identificador de condutor, funcionando como um sistema de registo e sistema de
segurança complementar de forma a impossibilitar que a viatura possa entrar em
funcionamento sem a identificação válida. Para visualização online do estado do
veículo, é realizada a georreferenciação no mapa, utilizando para isso o recurso do
Google Maps3, como comprova a Figura 6.
Figura 6 - A visualização da posição dos veículos (entre outras informações) na ferramenta NVfrotasoft é
realizada sobre um mapa, [13].
3 Serviço disponibilizado pela empresa Google, permite a pesquisa e visualização de mapas e imagens de
satélite do planeta Terra.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
13
2.3.3 Moviloc
Esta solução é fornecida pela Moviloc®, consiste numa ferramenta Web para a
gestão, localização e otimização de frotas que não necessita de qualquer software
instalado. É facultado ao utilizador um leque de funcionalidades baseado nas
tecnologias GPS, GSM/GPRS e suportado pela plataforma de serviços de localização
PALVIEW®. Na Figura 7 é apresentado o funcionamento do sistema, que consiste na
utilização de um equipamento móvel instalado no veículo, encarregue de calcular a
posição geográfica, de obter dados do veículo e posteriormente os transmitir para uma
plataforma central, denominada PALVIEW® [14]. Esta armazena todos os dados,
minuto a minuto e implementa todas as ferramentas necessárias para que os utilizadores
realizem uma gestão da frota através de qualquer computador ligado à internet. Esta
solução Web fornece várias funcionalidades, são elas: localização em tempo real,
geração de relatórios de incidentes, histórico de descargas, exportação de dados para
Excel e alarmes automáticos por email/SMS.
Figura 7 - Funcionamento da ferramenta Moviloc desde o processo inicial de recolha de dados até ao objetivo
final que consiste na apresentação da informação relevante ao utilizador, [14].
Os veículos são equipados com uma vasta gama de periféricos, como ilustrado na
Figura 8. É utilizado e instalado no veículo o equipamento U-10, responsável por
recolher dados dos periféricos e transmitir-lhos ao servidor. De todos os periféricos é de
destacar o botão de pânico e o sistema de corte da injeção do veículo. O botão de
pressão é um periférico instalado discretamente no veículo com o objetivo de ser
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
14
pressionado em situações de alarme. Este aviso irá informar os utilizadores da situação
de alarme, transmitindo-lhes informações como a hora e o local da ocorrência.
Figura 8 - Equipamento MOVILOC® instalado no veículo, [14].
O sistema de corte da injeção do veículo permite a imobilização remota do veículo,
impedindo o arranque do veículo. Este sistema foi concebido de modo a ser ativado
remotamente assim que detetado o roubo do veículo como ilustrado na Figura 9.
Figura 9 - Imobilização veículo de forma remota, por ordem do Centro de Controlo, [14].
2.3.4 Outras Soluções no Mercado
Até então foram descritas algumas soluções de sistemas de gestão e localização
de frotas, baseados na tecnologia GPS com uma presença forte no mercado. Contudo
existem muitas outras soluções com funcionalidades semelhantes às descritas até então.
Uma das quais, disponibilizada ao cliente pela PT Negócios, um serviço de gestão de
frotas que pode ser caraterizado da seguinte forma: equipamentos instalados nas
viaturas obtêm informações GPS, do veículo e do condutor, permitindo a interação deste
com um gestor do sistema central [15]. Esse sistema central processa a informação e
torna-a disponível para os gestores do sistema, que lhe podem aceder recorrendo à
internet. A comunicação de dados entre o veículo e o sistema é feita através da rede
TMN, utilizando cartões SIM instalados nos equipamentos das viaturas. Encontram-se
então no mercado outras soluções, tais como:
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
15
InoFrota Trace, da Inosat;
Amplifrota, da Vodafone;
The NexTraq Platform da NexTraq;
Frotcom da Frotcom, lda.
2.3.5 Comparação das Soluções Descritas
De um modo geral, verifica-se que o princípio de funcionamento de todas as
soluções descritas é semelhante e comum entre elas, podendo-se descrever do seguinte
modo: equipamentos de tracking são instalados nos veículos para obter dados
representativos do seu estado. Os dados utilizados para traçar os percursos percorridos
são transmitidos utilizando algum meio de comunicação em tempo real. Algumas
funcionalidades extras são facultadas, geração de alarmes, relatórios da atividade,
sistemas antirroubo, consulta de dados via internet ou no centro de controlo e a inclusão
de periféricos que permite a monitorização de várias variáveis de negócio.
Em suma, estas soluções distinguem-se no meio de comunicação utilizada (GSM,
GPRS, entre outras) e nas funcionalidades oferecidas dependendo das necessidades do
utilizador. De modo a verificar todas estas considerações é apresentada uma tabela
comparativa das características das soluções descritas anteriormente (Tabela 2).
Tabela 2 - Comparação entre as soluções apresentadas/estudadas.
Tipo
de
Acesso
U.
Móvel
Especifi
ca/ Tec.
GPS
Sistema
de
seguran
ça
Meio
Comunica
ção
Mapas Relatórios
/Alertas
Preço
Unid.
XTran PC e
Web Sim/GPS Não
GSM/GPRS
entre outros
Maps Sim/Sim ?
NVfrotas
oft Web Sim/GPS Sim GSM
Maps Sim/Sim ?
Moviloc Web Não/GPS Sim GSM/GPRS Google
Earth Sim/Sim ?
PT
Negócios Web
Não/A-
GPS Sim GSM/GPRS
Maps Sim/Não
25€ Mês
Frotcom Web Não/GPS Não GPRS Google Maps/
Bing maps Sim/Sim ?
The
NexTraq Web Sim/GPS Não GSM ? Não/Não ?
InoFrota
Trace Web Sim/GPS Não GSM
Maps Sim/Sim 25€
Mês
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
16
Verificou-se que praticamente todas as soluções se baseiam num sistema de gestão de
frotas online, proporcionando a vantagem aos utilizadores de acompanhar as frotas em
qualquer lugar, necessitando apenas de um dispositivo com acesso à internet sem
necessidade de instalação de softwares.
2.4 Exemplos de Dispositivos GPS Tracking
Nenhuma das soluções apresentadas oferece informação detalhada do hardware
utilizado, para colmatar esta falta de informação é apresentado de seguida alguns
equipamentos de tracking disponíveis no mercado. Este subcapítulo termina com as
conclusões retiradas da comparação entre os dispositivos aqui apresentados.
2.4.1 G959 GPS Tracking
O G959 GPS Tracker é uma solução disponibilizada pela empresa Gosafe
Company, ltd, consiste num módulo de hardware para controlo e georreferenciação de
veículos [16]. O seu princípio de funcionamento baseia-se na interação entre o módulo
do sistema integrado no veículo e um telemóvel, componentes apresentados na Figura
10.
Figura 10 - Componentes constituintes do produto G959 GPS Tracker, [16].
O G959 permite além do tradicional controlo e gestão através de SMS e servidor, o
controlo do veículo remotamente via software instalado no dispositivo móvel do
utilizador, o que reforça a segurança do veículo. Este produto possui o conjunto de
especificações exibidas na Tabela 3.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
17
Tabela 3 - Características do GPS tracker integrado com o dispositivo G945.
Especificações
Físicas Dimensão
Peso
91x65x28mm
100g
Alimentação
Bateria
Tensão
Consumo de corrente
500mAh Lion Recarregável
10-35V DC
140mA (Ativo), 80mA (Sleep)
Temperatura Temperatura de funcionamento
Humidade
-20ºC – +70ºC
5%-90%
Módulo GPS
Antena
Receiver
Canais
Exatidão de posição
Sensibilidade
Update de navegação
Externa
Ublox NEO-6M (GPS, Galilieo)
50 Canais paralelos
<2.5m
-162dBm
1 Segundo
Módulo comunicação
Modem
Antena
Ublox LEON G100 Quad Band
850/900/1800/1900 MHz, GPRS classe
10
Externa
Outros módulos
CPU
E/S
RAM estática de 32 Kbytes
Entradas e saídas digitais, entrada e
saída RJ45
2.4.2 HCT PRO Plus
A BrickHouse Security disponibiliza ao mercado o módulo HCT PRO Plus
apresentado na Figura 11, que consiste numa solução de rastreamento de viaturas,
utilizado na gestão de frotas [17]. É um produto destinado aos veículos, com uma
instalação fácil e escondida no interior do veículo, atualiza a sua posição geográfica a
cada 30 segundos e possui uma antena externa para maximizar o desempenho. O HCT
Pro Plus possui uma bateria de backup para continuar a fornecer informações de
localização, com uma autonomia de 12 horas.
Figura 11 - Dispositivo HCT PRO PLUS utilizado na localização de veículos, [17].
A Tabela 4 apresenta as principais especificações deste produto disponível no mercado.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
18
Tabela 4 - Características do dispositivo HCT PRO Plus.
Especificações
Físicas Dimensão
Peso
104x93x26mm
114g
Alimentação
Bateria
Tensão
Consumo de corrente
Bateria do veículo
8-30V DC
680mA (pico max.), 95mA (média)
Temperatura
Temperatura de
funcionamento
Humidade
-30ºC – +85ºC
5%-90%
Módulo GPS
Antena
Canais
Exatidão de posição
Sensibilidade
Update de navegação
Externa
50 Canais paralelos
2.5m
-161dBm
27s
Módulo
comunicação
GSM
GPRS
GSM1800/900 classe 1, Quad Band
850/900/1800/1900 MHz
Classe 10, sensibilidade -110dBm
Outros módulos
E/S
5 Entradas digitais, 1 entrada analógica
1 Porta RS232, 2 Leds
2.4.3 QTracker GT-Q3000
A QSTARZ coloca à disposição o módulo QTracker GT-Q3000, que também se
destina à gestão de frotas de veículos, uma vez que partilha dados relativos à posição
geográfica do mesmo. O QTracker oferece total controlo e informação geográfica em
tempo-real via Google Map no telemóvel 3G [18]. Este produto apresenta as
especificações exibidas na Tabela 5.
Tabela 5 - Características do dispositivo QTracker.
Especificações
Físicas Dimensão
Peso
82x44x18mm
70g
Alimentação
Bateria
Tempo de carga
Tensão
Lion Recarregável
3hrs
3.0-5.0V DC
Temperatura Temperatura de funcionamento -10ºC – +60ºC
Módulo GPS
Antena
Receiver
Canais
Exatidão de posição
Update de navegação
Interna
Modulo MTK II GPS
66 Canais paralelos
<3m
<1 Segundo
Módulo comunicação Modem
Antena
850/900/1800/1900 MHz,
Interna
Outros módulos
E/S
Entrada Mini USB, Botão SOS
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
19
2.5 Comparação das Soluções Apresentadas
Depois de apresentadas e estudadas as diversas soluções de dispositivos GPS
Tracking, a partir da Tabela 6 podemos concluir que existem semelhanças comuns entre
eles. A sua arquitetura é idêntica e baseia-se nos seguintes três módulos: dispositivo
para processamento de dados (microprocessador e memória externa), hardware de
comunicação (GSM e/ GPRS) e módulos de E/S (entradas e saídas digitais e analógicas).
As principais diferenças baseiam-se em torno do suporte protocolar e nos consumos de
corrente, que por recomendação dos fabricantes de automóveis não devem ultrapassar
os 500 mA [19].
Tabela 6 - Comparação dos módulos GPS Tracker analisados.
Dimensões Peso Tipo
bateria
Módulo
GPS
Módulo
comunicação Protocolo
G959 GPS 91x65x28mm 100g Lion
Recarregável
Ublox
NEO-6M,
antena
externa
Ublox LEON
G100,
GSM/GPRS
ProtcoloTCP/IP
HCT PRO
Plus 104x93x26mm 114g
Bateria
veículo
Antena
externa GSM/GPRS
---
QTracker
GT-Q3000 82x44x18mm 70g
Lion
Recarregável
MTK II
GPS,
antena
interna
GSM
Protocolo TCP
e UDP
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
20
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
21
3. Caraterização do Problema
O presente capítulo apresenta uma análise do sistema a implementar, onde é
apresentado o problema a ser resolvido, bem como a justificação da escolha dos meios
(hardware e software) utilizados para alcançar os objetivos impostos. São ainda
apresentadas as restrições impostas ao sistema, de forma a conhecer além do âmbito do
projeto as suas possíveis limitações.
3.1 Exposição do Problema
As soluções de sistemas e gestão de frotas permitem às organizações explorar os
seus recursos, especialmente os meios que realizam os serviços aos clientes. Numa fase
inicial estes sistemas utilizavam meios de rastreamento de veículos passivos, estes
consistem em dispositivos de hardware instalados no veículo que coletam e armazenam
informação que em algum ponto será transferida para um PC. Este tipo de dispositivos
não permite o controlo, localização em tempo real dos veículos não podendo ser
utilizados como meio de garantir a segurança dos funcionários e produtos da empresa.
Assim um sistema de gestão de frotas além da aquisição de informação em tempo real
requer meios (software) capazes de utilizar estes dados para fins de controlo e
localização em tempo real, conduzindo a uma redução de custos, planeamento mais
eficiente dos serviços e aumento de segurança.
3.2 Requisitos do Sistema
De seguida é apresentado um conjunto de propriedades ou funcionalidades
desejáveis que especifiquem o comportamento do sistema.
Em qualquer ferramenta de gestão de frotas é necessário posse de informação relevante
e sempre atualizada, que permita alcançar o sucesso na gestão das frotas. Assim sendo
encontra-se aqui o primeiro requisito: a “monitorização” da frota deve ser realizada em
tempo real. Deste requisito surge a necessidade de acompanhar graficamente a atividade
da frota sobre um mapa. Para presentear estas funcionalidades aos utilizadores é
necessário implementar duas aplicações distintas, a primeira designada de Posto de
Trabalho, baseada na versatilidade dos browsers da internet, deverá permitir a
realização de consultas por parte de utilizadores autorizados a informações das
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
22
atividades desenvolvidas pelas frotas, para fins de planeamento dos serviços a serem
transmitidos aos condutores.
A segunda aplicação destina-se ao condutor, é uma aplicação designada de Terminal do
Condutor que será executada num tablet/smartphone, utilizando as potencialidades do
sistema operativo móvel instalado neste como meio de disponibilizar o conjunto de
funcionalidades necessárias ao condutor na realização das suas tarefas dentro da
organização.
O principal propósito desta aplicação passa por apresentar as informações das tarefas
planeadas pelos coordenadores, além disso deve permitir a consulta do histórico de
serviços realizados pelo condutor, facultar a posição do veículo em caso de roubo e
ainda dentro deste cenário, deverá possibilitar o controlo do veículo remotamente. Esta
ação irá bloquear o veículo impedindo que este seja utilizado indevidamente, assim e
através do conhecimento da posição do veículo após o bloqueio é possível recuperar o
veículo.
No seguimento das funcionalidades anteriormente apresentadas surge a necessidade de
outro requisito, a recolha e transmissão de informação do estado do veículo,
nomeadamente variáveis como a posição geográfica e sua velocidade proveniente do
módulo Unidade Móvel instalado no veículo, a uma taxa de amostragem definida pelo
utilizador de acordo com as necessidades da organização. Este elemento deverá ainda
ser capaz de interpretar comandos, de bloquear o veículo, impedindo utilizações
indevidas sempre que o condutor ou gestor assim “ordenar” de forma remota. Como
último requisito, a ferramenta deverá permitir o acesso e manipulação da base de dados
da organização, alocada num servidor. De forma a cumprir o requisito apresentado é
necessário implementar uma interface gráfica para o efeito, designado de Centro de
Controlo que se destina ao gestor, o indivíduo responsável por gerir toda a informação
da organização (adicionar, editar, eliminar dados), tais como funcionários, veículos,
clientes entre outros.
3.3 Restrições do Sistema
Para conceção do sistema de gestão IntelFleet são identificadas algumas
restrições ao nível do hardware e do software. Na solução proposta, um dos requisitos
apresentados é a atualização dos dados relativos ao veículo, neste requisito são
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
23
estabelecidas duas restrições, a primeira imposta pela tecnologia utilizada para obter os
dados do veículo, pois estes dados deverem ser fornecidos com base na tecnologia GPS,
a última restrição imposta encontra-se relacionada com a forma como estes dados serão
comunicados aos restantes elementos de modo a estarem disponíveis para o utilizador,
assim sendo a comunicação realizada deverá ser através da rede móvel GSM. A Unidade
Móvel consistirá num conjunto de módulos configurados para obter e transmitir dados
geográficos, sendo assim necessário um módulo GPS e um módulo GSM para a
transmissão dos dados da frota ao Centro de Controlo. Esta última aplicação necessita
de um modem GSM, capaz de receber os dados provenientes da Unidade Móvel.
Ao nível do software, é conhecido que a ferramenta a desenvolver será constituída por
três elementos baseados em software, são eles: Centro de Controlo, Posto de Trabalho e
o Terminal do Condutor. Estes elementos só serão úteis aos utilizadores caso permitam
o acesso à informação presente na base de dados, surge então a primeira restrição: o
desenvolvimento de uma base de dados que permita acesso remoto utilizando a
linguagem SQL. O Posto de Trabalho deve permitir aos colaboradores visualizar a
localização da frota sobre um mapa, sendo esta informação gráfica implementada a
partir da API do Google Maps [20]. O desenvolvimento do domínio do servidor
IntelFleet será realizado através da utilização das seguintes linguagens, Java Script,
PHP e ainda HTML. Por sua vez, o Terminal do Condutor deve ser executado num
smartphone/tablet. O Centro de Controlo será desenvolvido utilizando a linguagem de
programação C# e a API do Google Maps para apresentar a posição do veículo em
situações de alerta ao gestor.
3.4 Especificações de Hardware
Para o desenvolvimento da solução proposta são necessárias várias tecnologias,
que possibilitam a implementação das funcionalidades previstas. Este subcapítulo
apresentada as especificações dos dispositivos de hardware utilizados como meio de
usufruir das potencialidades dessas mesmas tecnologias.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
24
3.4.1 Modem GSM, Telit EZ10-GPRS
É um produto colocado no mercado pela Telit Communications S.p.A, este
modem oferece uma completa solução para aplicações M2M4 sem fios [21]. É
controlado através da interface standart RS232 a uma tensão de alimentação que se
encontra entre os 9 e 24 volts. O EZ10 é um Dual-Band GSM/GPRS wireless modem
baseado na tecnologia GM862GSM/GPRS, o que significa que suporta até duas gamas
de frequências GSM (900/1800MHz), sendo capaz de oferecer serviço de voz, fax,
dados, GSM, SMS, GPRS.
O terminal permite o controlo remoto através de comandos AT. Mais detalhes deste
dispositivo com o aspeto da Figura 12 são exibidos no anexo A.2.
Figura 12 - Modem Telit EZ10-GPRS, [21] .
3.4.2 Unidade de Localização Móvel
Com um localizador via GPS e um comunicador GSM é possível localizar e
comunicar com as viaturas através de uma simples SMS [22]. A Unidade Móvel é um
dispositivo eletrónico que integra estas duas tecnologias, desenvolvido para ser
instalado no veículo, possibilitando assim o cálculo da posição geográfica do veículo
via GPS e transmissão das coordenadas e outros dados através das funcionalidades do
módulo GSM.
O dispositivo complementa-se com um sistema de bloqueio, permitindo o controlo
remoto da viatura, pensado para as situações de roubo. Em termos de hardware o
sistema é composto pelos seguintes módulos:
Unidade de processamento(a)
Alimentação da Unidade(b)
4 Refere-se ao conceito utilizado nas comunicações entre tecnologias com ou sem fios com outros
dispositivos que possuem mesma tecnologia.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
25
Módulo de localização(c)
Módulo de Comunicação(d)
Sistema de bloqueio(e)
a) Unidade de Processamento
Este módulo é exclusivamente composto por um microcontrolador, que deve ser
capaz de processar dados de forma a manter o sistema a operar em tempo real. Para tal
foi selecionado um processador de 16 bits com a tecnologia nanoWatt eXtreme Low
Power (XLP). Os microcontroladores com esta tecnologia, permitem implementar
aplicações com as mesmas referências em termos de eficiência energética, capaz de
alcançar consumos baixos de corrente na ordem dos 20nA, são ainda aconselháveis para
aplicações que requerem elevado desempenho onde existe a necessidade de economizar
espaço e custos. Além destes motivos, existem outros que conduzem à escolha deste
microcontrolador (PIC18LF46K22 [23]), como o seu reduzido custo e algumas das suas
características que serão apresentadas de seguida.
Segundo o fabricante este uC possui as seguintes especificações: 64 KBytes de memória
Flash interna, 3896 Bytes de memória SRAM interna, EEPROM com uma capacidade
de 1024 Bytes de memória, velocidade máxima de relógio 64 MHz, tensão de
funcionamento entre os 1.8V e 3.6V, módulo ADC com 30 canais com uma resolução
de 10-bits, um módulo DAC, 35 pinos I/O e suporta os protocolos de comunicação SPI,
I2C e USART.
Um fator que pesou na escolha deste microcontrolador durante o planeamento da
Unidade Móvel, foi a necessidade deste possuir duas portas USART disponíveis para a
comunicação em série com os módulos de localização e comunicação, e ainda
disponibiliza pelo menos um timer indispensável na implementação de um tempo de
amostragem definido pelo utilizador.
b) Alimentação da Unidade Móvel
A Unidade Móvel é um dispositivo projetado para ser instalado no veículo, onde
é possível e se torna vantajoso retirar proveito dos seus recursos, nomeadamente a
bateria. Assim sendo, este módulo foi projetado para satisfazer todas as necessidades do
dispositivo a partir da fonte de alimentação da viatura, onde deverá ir ao encontro de
todos os níveis de tensão aplicados no circuito do dispositivo. Visto que a Unidade
Móvel é um sistema constituído por vários subsistemas (componentes), será necessário
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
26
aplicar vários reguladores de tensão para satisfazer as diferentes necessidades de
alimentação dos componentes. Foi escolhido o conversor step-down, PTN78060W
(Figura 13) para baixar o nível de tensão da bateria da viatura, que por norma possuem a
tensão nominal 12V e fornecem corrente contínua. Este conversor é bastante utilizado
na indústria automóvel pela sua versatilidade, o seu baixo custo e corrente máxima
extraída (3A) [24], mais que o suficiente para o sistema a desenvolver. Segundo o
manual do fornecedor, o conversor possui as seguintes características:
Tensão de entrada: 7V a 36V;
Tensão de saída: 2.2V a 12.6V;
Alta eficiência: >96%;
Corrente máxima de saída: 3A;
Temperatura de funcionamento: -40ºC até 85ºC.
Figura 13 - Conversor step-down PTN78060 W, [24].
c) Módulo de Localização
Este módulo é projetado para obter informações do veículo em tempo real. No
contexto da Unidade Móvel pretende-se calcular as coordenadas geográficas e a
velocidade da viatura, assim a sua função traduz-se na receção e transmissão de dados
no formato do protocolo NMEA para o microcontrolador escolhido para o
processamento destes dados. Este módulo é constituído unicamente por um recetor
GPS. O componente de hardware escolhido para o efeito é o FGPMMOPA6B
representado na Figura 14, é um módulo “ultracompacto” de alta precisão de velocidade
e localização em condições urbanas. Suporta até 66 canais, foi desenhado com um baixo
form factor em mente e é aplicável em diferentes aplicações, designadamente na gestão
e posicionamento de frotas, em sistemas LBS e AVL (Automatic Vehicle Location) e
ainda em dispositivos portáteis de posicionamento global ou para navegação [25], como
características principais do FGPMMOPA6B podem-se referir as seguintes:
Chipset MediaTek MT3329;
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
27
Sinal L1C/A code – utilização civil -, 66 canais;
Deteção e redução de interferência;
Precisão de localização:
o -Sem ajuda: 3m ;
o -DGPS:2.5m.
Baixo consumo de energia: 48mA durante a aquisição, 37mA após aquisição ;
Baixo consumo quando desabilitado: 15uA;
Frequência de atualização: Até 10Hz;
Interface USB integrado;
Figura 14 - Aspeto físico do recetor GPS FGPMMOPA6B, [25].
A Figura 15 ilustra o módulo GPS sobre a forma de diagrama de blocos, destacando os
diferentes componentes e os pinos I/O descritos na Tabela 7.
Figura 15 - Diagrama de blocos do módulo recetor GPS selecionado para o projeto, [25].
Para mais especificações técnicas acerca do módulo recetor GPS deve-se consultar o
manual do fabricante, que se encontra no anexo A.3.
Tabela 7 - Descrição dos pinos I/O do recetor GPS.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
28
Pino Nome I/O Descrição 1 VCC Alimentação Fonte de alimentação DC, tensão devera se encontrar entre 3.2-5V
2 ENABLE I Em aberto ou em nível lógico para ativar módulo, nível baixo
desativa
3 GND Alimentação Ground
4 VBACKUP Alimentação
I
É a energia que mantem o RTC em execução quando alimentação
falha
5 3D-FIX O Saída para assinalar quando são encontradas os satélites
suficientes para funcionamento
6 DPLUS I/O USB Port DPLUS signal
7 DMINUS I/O USB Port DMINUS Signal
8 GND Alimentação Ground
9 TX O Este é o transmissor UART do módulo, é a saída para transmissão
de dados GPS
10 RX I É o UART Receiver do módulo, é utilizado para receber comandos
e Firmware Update
d) Módulo de Comunicação
O referido módulo é constituído unicamente por um componente que permite a
comunicação GSM entre a Unidade Móvel e os restantes elementos da ferramenta
desenvolvida. O componente escolhido para o efeito é o módulo da Siemens TC-35
apresentado na Figura 16, capaz de satisfazer todos os requisitos de comunicação
pretendidos. A seleção deste módulo em detrimento de outros deve-se em grande parte ao
facto de se tratar de um módulo compacto para transferência de dados, de voz na rede
GSM, com o leitor de SIMcard integrado permitindo a sua rápida e facilitada utilização
como um terminal dual band GSM [26]. A sua largura de banda e o seu desempenho
bem como a sua robustez física torna vantajoso o seu emprego em aplicações destinadas
a veículos, que se encontram sujeitos constantemente a instabilidades impostas pelos
caminhos percorridos pelos veículos.
Figura 16 - Módulo GSM da Siemens, TC-3, [26].
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
29
O componente em questão permite que um microcontrolador o controle via AT
commands, em que cada um desempenha uma função e pode ser precedida de
parâmetros que especificam a operação pretendida, mais detalhes sobre comandos AT
são exibidos no anexo A.4. As principais características identificadas do módulo TC-35
são:
Interface RS232;
Dual Band EGSM900/GSM1800;
Dados, Voz, SMS e Fax;
CSD acima de 14.4 Kbps;
Gama de tensão de alimentação: 8V-30V;
Baixo consumo energético;
LED sinalizador de estado;
Fácil integração;
Dimensões: 65x74x33 mm.
Sistema de Bloqueio
O sistema de bloqueio foi planeado de forma a permitir a imobilização segura do
veículo. Existem várias alternativas, são elas:
Corte da corrente na bobine de ignição, utilizado em veículos descapotáveis
como método de prevenir furtos;
Corte na bomba de combustível [27], o que faz com que o veículo pare por
completo ao fim de pouco tempo por consequência de falta de combustível;
Controlo da centralina, isto é, fornecer diretamente ao veículo o comando de
paragem e ainda enviar outros comandos, como por exemplo o bloqueio das
portas do veículo [2];
Imobilizar o veículo a partir do corte da corrente de saída da bateria elétrica;
Os sistemas de bloqueio listados, apresentam diferentes pontos de vista, entre eles
podemos identificar o método de bloqueio por controlo da centralina como o que maior
controle proporciona sobre o veículo. A imobilização do veículo através do corte da
corrente da bateria elétrica não permite instantaneamente imobilizar o veículo, contudo
possibilita que uma vez desligado não seja possível a sua reutilização, pois é necessário
a energia proveniente da bateria para efetuar a ignição do veículo. Este modo de
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
30
funcionamento apresenta como vantagem a total integridade dos produtos e utilizadores,
uma desvantagem identificada é a necessidade de um dispositivo robusto e com elevado
de poder de corte, pois a corrente de saída de uma bateria pode atingir valores elevados.
Entre as diferentes soluções plausíveis descritas optou-se pela imobilização do veículo a
partir do corte de corrente na bomba de combustível, nesta solução o veículo não é
parado instantaneamente, enquanto existir combustível no circuito ele continuará a ser
utilizado, após isto o veículo deixará de fazer a combustão/explosão desligando-se.
Conclui-se que se trata de uma solução viável, que entre as várias soluções apresentadas
é que melhor balanço gera entre os parâmetros de segurança, facilidade de
utilização/instalação e tempo de imobilização. Para corte da alimentação da bomba de
combustível do veículo é utilizado por norma um relé [28].
Quando recebidas ordens de imobilização é efetuado corte por completo da alimentação
da bomba fazendo com que o veículo pare. A instalação do sistema de corte de
combustível é simples, basta interromper o fio de alimentação que vai para a bomba e
ligar dois fios em cada lado do fio cortado conforme ilustrado na Figura 17 ao relé,
como deu para entender e como qualquer acessório antirroubo altera a originalidade do
veículo.
Figura 17 - Instalação do sistema de corte da bomba.
3.5 Especificações de Software
Nesta secção é especificado o software necessário para implementação da
ferramenta proposta, dentro deste é possível subdividir a ferramenta IntelFleet em vários
subsistemas de acordo com os diferentes utilizadores.
3.5.1 Interface com os Utilizadores
A solução IntelFleet disponibiliza diferentes interfaces, visto que a ferramenta
não se destina apenas a um utilizador, só assim suporta as atividades dos diferentes
intervenientes das organizações. Cada um destes utilizadores deverá possuir um
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
31
conjunto de funcionalidades disponibilizadas pela ferramenta. Consoante a sua tarefa
dentro da empresa é lhe atribuída uma interface com o sistema, de forma a garantir o
cumprimento das suas tarefas. Assim sendo, podemos identificar os seguintes potências
utilizadores dentro da organização:
Gestor (a)
Condutor (b)
Coordenador (c)
a) Gestor
O primeiro utilizador, o Gestor, tem a tarefa de gerir a informação da ferramenta
IntelFleet, tais como os dados dos recursos humanos e físicos da empresa. Este
utilizador realiza funções tais como adicionar, editar e eliminar veículos, clientes e
condutores, entre outras funcionalidades ilustradas na Figura 18.
Figura 18 - Funcionalidades do sistema do ponto de vista do Gestor.
A aplicação que lhe confere interface com o sistema é o Centro de Controlo, esta
aplicação é o sistema central da ferramenta, pois habilitará o tracking dos veículos
através do envio de pedidos de atualização da sua informação e posterior receção e
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
32
processamento das variáveis monitorizadas da Unidade Móvel. Além de proporcionar a
gestão dos dados da empresa como já referido, gera relatórios diários das atividades dos
veículos para a consulta por parte do Gestor e ainda um ErrorLog, utilizado para
armazenar detalhes dos erros detetados na comunicação com os veículos, como meio de
alertar o Gestor de anomalias identificados no sistema. Na Figura 19 são ilustradas as
funcionalidades que a interface do Gestor deve suportar de forma a garantir que este
consiga realizar todas as tarefas inerentes à sua função dentro da empresa.
Figura 19 - Funcionalidades a suportar pela interface do Gestor.
Software e Tecnologias de Desenvolvimento
A linguagem de programação a utilizar no desenvolvimento da aplicação é o C#.
A familiarização com a linguagem, os documentos de apoio disponíveis e as
ferramentas de apoio existentes e conhecidas foram critérios que pesaram na escolha
desta linguagem de programação. Além disso, esta é uma linguagem orientada a objetos
projetados para trabalhar com a plataforma NET da Microsoft, a partir desta relação a
linguagem obtém as classes ou funções de execução, o que permite que um programa
compilado num determinado sistema operativo seja executado noutro, pois as aplicações
deixam de ser implementadas para um determinado sistema operativo mas sim para a
Framework obtendo portabilidade de código que antes não existia [29].
Além desta linguagem, sendo ela a principal utilizada não evita a necessidade de
recorrer a outras tecnologias de forma a cumprir os requisitos apresentados em 3.2
(Restrições do Sistema) nomeadamente a utilização da linguagem SQL para consulta da
Centro de Controlo
Gestão de Recursos
Adicionar/Editar/Eliminar
Veículos Condutor Clientes Coordenadores
Geração de Relatorios
Visualização
ErrorLog
Geração de Alertas
Comunicação com Veículos
Manipulação Tempo de
Amostragem
Gestão da seleção de veículos a monitorizar
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
33
base de dados; a implementação de um Windows Service utilizando a linguagem de
programação C# [30], justifica-se pela necessidade de o sistema se encontrar
constantemente em comunicação com os veículos.
O ambiente de desenvolvimento adotado, para a produção da interface com o utilizador
Gestor, é o IDE da Microsoft, o Visual Studio 2010. Este programa permite a edição e
organização de todo o código fonte utilizado no desenvolvimento da interface e possui
ainda um modo de debugger que permite certificar o trabalho realizado. Este ambiente
de desenvolvimento foi também escolhido para a implementação do serviço que corre
em background, que juntamente com aplicação gráfica formam o Centro de Controlo.
b) Condutor
Este utilizador executa todas as suas tarefas fora da organização e portanto é um
elemento com especial atenção. Assim sendo, a organização necessita de supervisionar
estes utilizadores, de estar em contacto com eles e ainda de lhes oferece um conjunto de
funcionalidades que os auxilie nas suas tarefas com o objetivo de reduzir custos e
aumentar o desempenho na execução das suas tarefas. Estas funcionalidades encontram-
se representadas no Diagrama Use-Cases da Figura 20.
Figura 20 - Funcionalidades da ferramenta IntelFleet do ponto de vista do Condutor.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
34
Neste conjunto de funcionalidades apresentadas do ponto de vista do utilizador
condutor, é de destacar a funcionalidade “Registo de veículos” pelo facto de não ter sido
referida até então ao contrário das restantes. Os dados dos condutores e dos veículos são
armazenados numa base de dados existindo uma relação entre eles, na linguagem SQL é
possível criar relações entre registos/tabelas, portanto a cada condutor é “atribuído” um
veículo, estando esta informação armazenada e disponível aos diferentes utilizadores.
Contudo, dentro da organização cliente existirá a possibilidade dos condutores alterarem
de veículo, estando a partir de então a utilizar um veículo que não lhe foi atribuído
inicialmente, consequentemente a informação relativa aos recursos da organização passa
a estar desatualizada. De forma a combater este problema foi introduzido um sistema de
registo de veículo, esta funcionalidade permite indicar à organização a alteração
realizada pelo condutor, estando sempre atualizada a informação disponível aos
utilizadores, mais detalhes são apresentados posteriormente.
A aplicação que confere ao condutor a interface com o sistema é designada de Terminal
do Condutor, baseia-se numa aplicação que é executada sobre o sistema operativo
móvel adotado para implementação da referida aplicação. Na Figura 21 é ilustrado
todos os módulos que constituem a aplicação e que conferem as funcionalidades
facultadas ao condutor. Todo software/linguagem de programação utilizado na sua
conceção é apresentado de seguida.
Figura 21 - Funcionalidades que a interface do Condutor deve suportar.
Software e Tecnologias de Desenvolvimento
IntelFleet/Terminal do Condutor
Histórico de
Tarefas
Consulta
Controlo do
veículo
Consulta da localização
geográfica do veiculo
Notificação de tarefas
Visualização da informação das tarefas e rota a
executar
Sistema de registo de veiculos
Registo de alteração de
veículo
Alertas
Pazo da tarefa a expirar/expirad
o
Rota desrespeitada
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
35
Antes de determinar qual a linguagem de programação a utilizar é necessário
decidir sobre qual o sistema operativo irá decorrer a aplicação. Para tal foi realizado um
estudo dos diferentes sistemas disponíveis no mercado dos dispositivos móveis.
Atualmente, os sistemas operativos dominantes em dispositivos móveis são: iOS da
Apple, Android da Google, BlackBerry’s OS e Microsoft Windows Mobile [31]. Os
critérios adotados na seleção de um sistema operativo são: quota de mercado, suporte de
informação, facilidade de desenvolvimento de aplicações, plataforma desktop suportada
e licença da aplicação. A seguinte tabela (Tabela 8) compara estes sistemas operativos
de acordo com a licença, linguagem de programação e plataforma de desenvolvimento
suportada oficialmente.
Tabela 8 - Descrição dos principais sistemas operativos no mercado de dispositivos móveis.
S.O Licença
Linguagem
de
Programação
Plataforma de desenvolvimento
iOS Proprietário Objective-C Mac OS/Unix-Like
Android Open Source Maioritariamente
Java Multiplataforma
Blackberry Proprietário Java Windows
Symbian Proprietário C++ Multiplataforma
Windows
Mobile Proprietário
Dot NET
languages (C#,
C++, VB.Net)
Windows
Após isto, o sistema operativo selecionado é o Android por se tratar de um sistema
open-source de fácil desenvolvimento, sem barreiras à entrada e difusão. Outra
interessante vantagem é a possibilidade de aplicações escritas para smartphones serem
facilmente implementadas para tablets sem grandes ou nenhumas alterações técnicas.
A linguagem de programação utilizada no desenvolvimento de aplicações Android é o
Java.
De modo a garantir alguns dos requisitos apresentados no subcapítulo 3.2 (Requisitos
do Sistema) é necessário recorrer a recursos do Android. Exemplo disso é a necessidade
da aplicação comunicar com o mundo exterior, a partir do uso de mensagens de texto é
possível cumprir este requisito. O Android vem com uma aplicação de SMS built-in [32]
o que permite o envio e receção de mensagens de texto. No contexto da aplicação
Terminal do Condutor é necessário utilizar recursos de SMS, sendo utilizado na
comunicação com a Unidade Móvel (bloqueio do veículo, pedido de localização) e com
o Centro de Controlo (transmissão bidirecional de alertas/ordens). A aplicação Terminal
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
36
do Condutor receberá por parte do Posto de Trabalho os detalhes dos serviços
especificados pelo coordenador, para tal é necessário utilizar recursos Networking do
SO para baixar arquivos XML do servidor e analisar o seu conteúdo.
O ambiente de desenvolvimento adotado para a produção da interface com o utilizador
Condutor é o Android SDK e Eclipse. O Android SDK fornece ferramentas e APIs
necessárias para o desenvolvimento de aplicações destinadas à plataforma Android
utilizando a linguagem de programação Java, encontrando-se disponível para o
Windows, Linux e Mac [33]. O Eclipse é um ambiente de desenvolvimento
multiplataforma que corre em todos os principais sistemas operativos. O Google fornece
um plug-in para o Eclipse que permite uma utilização fácil e controlo das instalações
Android SDK. Este plugin é chamado de ADT Plugin (Android Development Tool),
depois de instaladas a maioria das ferramentas SDK podem ser acedidas através do
Eclipse [34]. Este ambiente de desenvolvimento foi o escolhido em detrimento de
outros IDEs por ser o ambiente suportado oficialmente.
c) Coordenador
Este utilizador tem como tarefa, a supervisão e planeamento das tarefas da frota,
de forma a alcançar estes fins é necessário disponibilizar informação relevante, e
atualizada que melhor descreva a atividade da frota. A gestão da atividade da frota é a
maior responsabilidade para um utilizador dentro da organização, onde apenas com uma
correta gestão se consegue alcançar metas fundamentais para a redução de custos, entre
outros objetivos desejados pela organização. Desta forma, é necessário que a ferramenta
proposta implemente uma interface, capaz de facultar um conjunto de funcionalidades
(Figura 22), que do ponto de vista do coordenador são essenciais na realização das suas
tarefas.
A interface deste utilizador com a ferramenta IntelFleet, denomina-se de Posto de
Trabalho e é acessível através de um browser num dispositivo com acesso à internet.
Baseia-se no acesso ao domínio do servidor, que armazena toda a informação das
atividades e dados da organização, este domínio faculta todas as ferramentas necessárias
ao coordenador para a realização das suas tarefas dentro da organização.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
37
Figura 22 - Funcionalidades da ferramenta do ponto de vista do coordenador.
Na Figura 23 são ilustrados todos os módulos que conferem as funcionalidades do
coordenador através da interface desenvolvida para o efeito. Todo software/linguagem
de programação utilizado na sua conceção é apresentado de seguida.
Figura 23 - Funcionalidades suportadas pelo posto de trabalho.
Software e Tecnologias de Desenvolvimento
A inclusão de mapas embebidos diretamente nas páginas do domínio designado
de posto de trabalho é um requisito desta interface/aplicação, só assim se consegue
implementar funcionalidades essenciais para o coordenador. Atualmente, existe vários
serviços que fornecem uma variedade de funcionalidades que vão de encontro às
necessidades da aplicação, as principias e mais utilizadas encontram-se descritas na
Tabela 9, são elas o Google Maps e Yahoo Maps.
IntelFleet/Posto de trabalho
Recursos físcios e humanos
Consulta
Supervisão
Consulta da localização geográfica/rota do veiculo no mapa
Planeamento de tarefas
Criação de tarefas
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
38
Tabela 9 - Comparação entre as API’s da Google e Yahoo Maps.
Goole Maps Yahoo Maps Não possui Geocoder “próprio” Proporciona seu próprio Geocoder
Mapas podem ser gerados em qualquer página
com correspondente Key Os mapas serão unicamente gerados em Yahoo
Utiliza Ajax Não utiliza Ajax
Pode ser utilizado para propósitos comerciais
sempre e quando for gratuito para utilizador
final
Pode ser utilizado para propósitos comerciais, mas é
necessária autorização para esse efeito
Pode agregar texto HTML ou XML em uma
pequena janela de informação
Pode agregar texto HTML em uma pequena janela de
informação e permite o uso de IFRAMES
Nenhuma restrição de uso Nenhuma restrição de uso
Optou-se por utilizar os serviços do Google Maps, essencialmente pela sua versatilidade
e compatibilidade. A última versão da API (V3 ) foi desenvolvida especialmente para
ser mais rápida e apresentar maior compatibilidade com as aplicações tradicionais para
browsers e também com dispositivos móveis [35], sendo que este é um aspeto
importante a ter em conta na seleção do serviço a utilizar, visto que este serviço será
necessário também na aplicação para dispositivos móveis (Terminal do Condutor). A
API consiste num conjunto de classes que oferece uma interface ao programador para
que possa desenvolver suas aplicações, como exibir mapas, implementar funções de
zoom, realizar consultas por endereços ou por coordenadas geográficas entre outras
possibilidades. A última versão (v3) fornece diversos utilitários para manipulação de
mapas e adição de conteúdo aos mapas por meio de serviços, permitindo obter
aplicações de mapas robustas [36].
Para desenvolver a aplicação será necessária mais do que uma linguagem de
programação, a linguagem Java script é incorporada nos ficheiros HTML (lado do
cliente) enquanto do lado do servidor é necessária a utilização da linguagem de
programação PHP [37] para processar e gerar uma resposta à solicitação de informação
por parte do cliente. Devido à necessidade de apresentar ao utilizador informações
armazenadas no servidor recorre-se à tecnologia Web service, esta permite a aplicações
com diferentes linguagens enviar e receber dados em formato XML. Ainda neste
contexto, será utilizada a tecnologia AJAX para tornar a página Web mas interativa com
o utilizador, esta tecnologia consiste num conjunto de técnicas de desenvolvimento Web
[38] usadas no lado do cliente com o propósito já referido.
O ambiente de desenvolvimento adotado para a produção da interface com o utilizador
Coordenador é o Dreamweaver. Trata-se de um software de design Web que fornece
uma interface visual intuitiva para criação e edição de sites em HTML. O Dreamweaver
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
39
conta com uma enorme comunidade de programadores que tornam disponíveis
extensões, estes são pequenos programas que qualquer programador web pode escrever
e qualquer um pode obter e instalar, o que proporciona funcionalidades adicionais ao
software. Apesar de tudo isto, a principal característica que conduziu à decisão de
utilização deste software foi os diferentes modos de programação que disponibiliza ao
utilizador, sendo eles: modo Design, este esconde os detalhes do código HTML do
utilizador, permitindo aos designados de não especialistas em HTML criarem suas
próprias páginas e aplicações Web. Encontrando assim um grande interesse na utilização
deste modo, pois permite esconder detalhes referentes ao design da página Web,
possibilitando aos utilizadores com pouca experiência em web design desenvolver a
interface da página de forma gráfica e intuitiva com muita maior facilidade do que
através de código; modo Código, suporta todas as sintaxes das linguagens de
programação cobertas pelo software fornecendo dicas ao utilizador. O software
disponibiliza também uma ferramenta que após indicar um browser, permite visualizar
uma previsão da página HTML.
3.5.2 Software Adotado para o Desenvolvimento da Unidade Móvel
O ambiente de desenvolvimento da unidade de localização móvel pode ser
dividido em duas categorias distintas e que melhor traduzem o processo de
desenvolvimento da unidade: o desenvolvimento do software e o desenvolvimento do
hardware.
No âmbito do desenvolvimento do hardware, este permite a criação de um esquemático
com os componentes físicos e respetivas ligações. Após obter o esquemático aprovado
bem como todas as ligações entre os componentes certificados, dará origem a uma PCB
(placa de circuito impresso), à escala que permite a disposição dos componentes de
hardware de forma a minimizar o número de vias possíveis.
O software adotado para o desenvolvimento e validação da PCB é o CadSoft EAGLE
que possui um grande conjunto de bibliotecas e ainda suporte online [39].
Para produção de software foi adotado o ambiente de desenvolvimento MPLABX por
ser um produto gratuito e recomendado pelo fabricante do microcontrolador. Em
conjunto com este IDE, é necessário selecionar também um compilador C, o eleito é o
HI-TECH PICC18.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
40
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
41
4. Arquitetura e Desenvolvimento do Sistema
Este capítulo apresenta uma visão geral do sistema, recorrendo frequentemente a
diagrama de blocos para uma melhor descrição do funcionamento dos principais
elementos que constituem o projeto final. É ainda dado a conhecer os detalhes do
desenvolvimento do dispositivo de hardware (Unidade Móvel) e os detalhes das
diferentes aplicações de software que fazem parte das diferentes interfaces
desenvolvidas para os utilizadores, assim como o propósito da sua concessão. Antes
disto é demonstrado o modelo de dados desenvolvidos e adotados que define as
características de funcionamento e comportamento das aplicações de software.
4.1 Visão Global do Sistema
Alcançado este ponto, e após dar a conhecer os limites e restrições impostas ao
sistema bem como o âmbito do projeto procura-se obter uma melhor perspetiva do
sistema. Resumidamente o objetivo do projeto passa por desenvolver um sistema que
permita a gestão das atividades de uma frota através da informação GPS recolhida,
permitindo o seu controlo remotamente. Para alcançar este objetivo foi realizado o
estudo das várias soluções já existentes, descrito no capítulo 2 (Âmbito dos Sistemas de
Localização e Gestão). Através de uma análise detalhada das suas limitações e
vantagens oferecidas chegou-se à conclusão de quais os elementos que deverão
constituir o sistema, quais as suas funções e limitações a ultrapassar que no âmbito do
projeto mais se aproximaria da melhor solução possível. Assim identificaram-se os
seguintes elementos (representados no diagrama da Figura 24) que constituíram o
sistema IntelFleet: Centro de Controlo, o Terminal do Condutor, o Plano de Trabalho e
ainda a Unidade Móvel.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
42
Base
Dados
Servidor Web
Posto de Trabalho
+ Coordenador
Detalhes dos serviços a realizar (Destino, tempo previsto
para realização, Kms, percurso entre outros)
Web Service via 3G
Centro de Controlo
+
Gestor
*
Unidade Móvel
Veículo
+
Pedidos e ordens sob a forma
de comandos
Informações do veículo
(Velocidade, coordenadas geográficas, entre outros)
Via GSM
Terminal do Condutor
+
Condutor
Info
rmaç
ões
do
veí
culo
(Vel
oci
dad
e, c
oo
rden
ada,
etc
.)
Via
GS
M
Ped
ido
s e
ord
ens
sob
a f
orm
a
de
com
and
os *
Via
GS
M
Avis
os
Ale
rtas
e o
rden
s
Figura 24 - Visão Global do sistema IntelFleet.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
43
Este sistema é constituído por um sistema central, a aplicação designada de Centro de
Controlo instalada num computador local responsável pela comunicação com todas as
Unidades Móveis instaladas nos veículos, através do meio de comunicação GSM. A
informação que resulta desta comunicação, não é nada mais que variáveis que
influenciam as tomadas de decisão na gestão da atividade da frota, são processadas,
organizadas e armazenadas na base de dados, presente num servidor, onde se encontra
residente toda a informação da organização.
As unidades móveis são dispositivos instalados nos veículos, dotados de um módulo
GPS para o cálculo das variáveis necessárias (localização espacial e velocidade), de um
módulo GSM que estabelece a comunicação entre o veículo e o sistema central,
transmitindo-lhe os parâmetros descritos anteriormente. O dispositivo de hardware
integra ainda um sistema de bloqueio do veículo que permite a imobilização remota do
veículo, impedindo sua reutilização.
O acompanhamento em tempo real da atividade da frota é realizado online via
georreferenciação num mapa, através do acesso ao domínio do servidor onde reside a
base de dados que é atualizada com informação dos veículos proveniente das unidades
móveis instaladas nos veículos. Denominado de Posto de Trabalho, é onde os
coordenadores encontram toda a informação necessária para supervisionar e planear
todas as tarefas das frotas que são transmitidas aos condutores, de forma a serem
realizadas. Os dados das tarefas são apresentados aos condutores por meio de consolas
proporcionadas a estes pela ferramenta IntelFleet.
O Terminal do Condutor é a consola do condutor, consiste numa aplicação para o
sistema operativo Android executada num smartphone/tablet, com o intuito de
apresentar os dados das tarefas de forma amigável e gráfica, tais como trajeto a
percorrer, entre outros dados. Além desta funcionalidade, permitirá ao condutor o
controlo remoto do veículo, assim nas situações de furto é possível impedir sua
utilização indevida.
Na Figura 24 encontram-se ilustradas além dos elementos aqui descritos, os meios de
comunicação utilizados e por fim os tipos de dados trocados entre si.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
44
4.2 Modelo Relacional
Em qualquer sistema que envolva base de dados é necessário realizar um modelo
de dados, só deste modo é possível obter uma boa organização e documentação de
dados. O processo de modelação de dados consiste na identificação de entidades, as
suas propriedades e os relacionamentos entre as entidades, representado através do
diagrama entidade-relação. No âmbito do sistema podemos identificar as seguintes
entidades, representadas no modelo ER da Figura 25. Este traduz-se nas seguintes
tabelas da base de dados alocada no servidor (denominada intelfleet_mydb):
Clientes_Alvo, Driver, Veiculo, Utilizadores, Servicos, Historico_Servico,
Linha_Servicos, Tipo_Alvo.
Figura 25 - Modelo Entidade-Relação da base de dados criada para o sistema IntelFleet.
A Tabela 10 apresenta uma breve descrição de cada uma das entidades que fazem parte
do modelo relacional.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
45
Tabela 10 - Descrição das entidades/tabelas que compõem a base de dados intelfleet_mydb.
Tabela Descrição
Clientes_Alvo Tabela com informação textual sobre cada cliente da empresa, tendo como
campos mais relevantes as coordenadas geográficas da sede do cliente.
Tipo_Alvo Tabela com dados armazenados por defeito que permite identificar o tipo de
cliente, estes podem ser de dois géneros: cliente de destino da mercadoria ou
cliente fornecedor de mercadoria.
Driver Possui informação textual relativa a cada condutor que faz parte dos quadros
da organização.
veiculo Esta tabela armazena informação textual dos veículos que são propriedade da
organização e que são utilizados pelos condutores (ligação á tabela Driver).
Utilizadores A tabela referida armazena dados que permite identificar os coordenadores e
o seu estado (online/offline) que acedem ao Posto de Trabalho via Internet.
Produtos Possui informação textual relativa à mercadoria classificada por tipo de
produto, por exemplo: ‘produtos alimentares’, ‘produtos de desporto’.
Servicos
Esta é a tabela central de todo o sistema, pois permite armazenar dados dos
serviços prestados pela organização aos clientes. Os serviços possuem como
principal informação o destino (ligação á tabela Cliente), o Condutor e
Coordenador responsável pela tarefa (ligação á tabela Driver e Utilizadores
respetivamente). Os serviços estão classificados quanto ao seu estado: ‘em
execução’, ‘executado’ sendo ainda que qualquer serviço está ligado a uma
rota, que se traduz num conjunto de localizações, esta ligação é feita pela
seguinte tabela.
Historico_Servico Tabela com os pontos geográficos que representam a rota percorrida na
execução do serviço (ligação á tabela Servicos).
4.2.1 Relacionamento entre Entidades
A ferramenta IntelFleet visa essencialmente gerir as atividades que são
executadas fora da organização, mais concretamente as executadas pelo condutor. As
suas atividades baseiam-se maioritariamente na execução de serviços estabelecidos pela
organização/coordenador após sua requisição por parte do cliente, assim entende-se que
a entidade/tabela central seja “Servicos”. Na figura seguinte podemos identificar os
principais campos que constituem a tabela: a chave primária ‘num_servico’ permite
identificar de forma única um serviço na tabela, as chaves estrangeiras
‘Driver_num_driver’, ‘ID’ e ‘clientes_alvo_cod_cliente’ têm o prepósito de representar
um relacionamento entre tabelas. De notar que os relacionamentos impostos entre as
tabelas visíveis na Figura 26 possuem a mesma propriedade: uma relação de um para
vários. Isto significa, por exemplo na interação entre a tabela “Servicos” e
“Utilizadores” que um utilizador poderá se encontrar em um ou mais serviços
realizados, mas por sua vez um serviço só poderá ter um utilizador, o mesmo se aplica
às restantes relações.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
46
Figura 26 - Relacionamento de várias entidades com a entidade central, “Servicos”.
Além destes encontram-se campos que traduzem os serviços, tais como a data em que
foi gerado um novo serviço requisitado por um cliente (‘data_inicio’), a data prevista
para a realização da tarefa (‘data_previsão_final’), os quilómetros a percorrer que utiliza
para fins de cálculo de distâncias de duas posições geográficas, a posição (ponto de
partida) do condutor/veículo selecionado no momento na requisição dos serviços e a
localização do cliente (ponto de chegada do serviço), o campo ‘data_realizacao’ pode
ter o valor nulo, pois este campo só é preenchido quando o condutor der indicação da
realização do serviço, o campo ‘realizado’ é utilizado para facilitar a pesquisa de
serviços pendentes ou realizados, por último os campos ‘latitude’ e ‘longitude’
especificam a posição geográfica de destino.
A relação entre as tabelas “Servicos” e “Histórico_servico” apresentada na Figura 27 é
importante durante o processo realizado pelo coordenador de geração de rotas, esta
última tabela armazena os pontos geográficos percorridos na execução de um serviço.
1..n
1
1..n 1
1..n
1
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
47
Figura 27 - Relação de uma para vários entre as entidades Historico_Servico e Servicos.
O relacionamento apresentado na Figura 28 entre as tabelas “Driver” e “veiculo” pode-
se traduzir do seguinte modo: cada condutor da organização tem zero ou mais veículos
associados e um veículo pode ter zero ou mais condutores associados.
Figura 28 - Relação entre as entidades Driver e veiculo.
Numa situação de pesquisa em que se pretenda conhecer qual o veículo que está
associado a uma tarefa por realizar, torna-se necessário percorrer o caminho desde a
tabela “Servicos” até “veículo”, através das chaves secundárias é possível. Obtendo o
identificador do condutor (‘num_driver’) na tabela “Servicos” realiza-se uma pesquisa
na tabela “Driver” adquirindo a sua chave secundária ‘veículo_matrícula’ que faz a
0..
1
0..1
0..1
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
48
ligação com a tabela “veículo”, assim através do identificador que nunca se repete
‘matrícula’ temos acesso aos restantes dados do veículo.
Junto com o modelo Entidade-Relação da Figura 25 é adicionado e mantido um
documento com explicação de todos os objetos nele criado. Este documento, pode ser
chamado de Dicionário de Dados e está disponível para consulta no anexo A.5.
Trigger
Consiste num evento gerado por alterações realizadas na base de dados, isto
permite a realização de ações no instante que este ocorre. Os triggers podem ser
divididos em duas categorias, por coluna e por declaração. A primeira categoria é
utilizada para ações nas colunas, por sua vez a restante categoria emprega-se ao
conjunto de declarações que aplicam UPDATE, DELETE e INSERT.
Os trigeers são bastante uteis no âmbito do projeto, sua utilização automatiza a relação
entre entidades, mantendo a integridade das tabelas da base de dados MySQL.
Devido às relações ilustradas na Figura 25, existe uma série de passos que devem ser
realizados sempre que uma tabela referenciada por outra sofre alterações. Por exemplo,
quando um dado veículo é eliminado da base de dados, é necessário remover a
associação dos condutores ao veículo, ou seja, caso exista algum condutor associado ao
veículo (campo ‘veiculo_matricula’) deve ser removida essa relação. O trigger
implementado na Figura 29 permite efetuar o tratamento da informação nas tabelas que
referenciam o veículo, quando é removido uma linha na tabela “veículo” é gerado um
evento que ira percorrer a tabela “Driver” e atualizar todas as linhas que possuem
referência à matrícula do veículo eliminado.
Figura 29 - Trigger responsável por remover ligação de um condutor a um veículo removido.
No dicionário de dados do anexo A.5 podemos identificar todos os triggers
implementados de forma a manter a integridade dos dados armazenados na base de
dados.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
49
4.3 Centro de Controlo
A aplicação Centro de Controlo (Figura 30) tem um papel fundamental no
âmbito do projeto IntelFleet, anteriormente descrita como sistema central da ferramenta,
devido ao papel de intermediário que exerce entre os veículos (informação
representativa do seu estado) e o Posto de Trabalho. A aplicação é responsável pela
recolha dos dados e ainda de os disponibilizar ao coordenador. É ainda a interface entre
o utilizador gestor e a ferramenta IntelFleet, permitindo-lhe realizar todas as
funcionalidades apresentas em Figura 18.
Figura 30 - Arquitetura do Centro de Controlo.
Na arquitetura ilustrada na Figura 30, o Centro de Controlo encontra-se dividido em
dois grandes módulos, são eles:
Serviço, executado em background;
Aplicação gráfica que fornece interface ao utilizador;
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
50
Outro diagrama a ter em consideração é o da Figura 31, que representa a interação entre
o serviço e a aplicação gráfica. A decisão de dividir o Centro de Controlo em dois
grandes módulos, justifica-se pela necessidade de garantir uma comunicação constante
com os veículos, um possível exemplo prático que espelha este requisito seria: durante a
realização de uma tarefa mais duradoura com maiores distâncias a percorrer, é
necessário coletar a informação do veículo, o serviço é responsável por esta tarefa
excluindo a necessidade da aplicação gráfica se encontrar em execução durante esta
tarefa.
Figura 31 - Interação Serviço-Aplicação gráfica na aplicação Centro de Controlo.
Assim sendo, a aplicação executada em background é iniciada sempre que o
computador onde se encontra instalado é iniciado. Esta aplicação é executada em
segundo plano sem interação do utilizador, assim não é necessário o Gestor estar
conectado à aplicação gráfica para manter a comunicação com os veículos, para tal
apenas necessita manter o computador ligado.
4.3.1 Interface entre os Processos
A interface entre os processos serviço e aplicação gráfica é realizada recorrendo
aos sockets TCP/IP [40]. Esta interface permite ao utilizador comunicar com o serviço e
mais especificamente usufruir diretamente das funcionalidades do modem GSM. Assim
sendo, verificasse que os conceitos de Inter Process Communication (IPC) e threads
terão um papel importante nesta aplicação.
O fluxograma da Figura 32 ilustra o processo de comunicação entre as aplicações. Na
figura podemos identificar um servidor e um cliente, visto que a aplicação background é
implementada para correr continuamente, foi decretada servidor e por sua vez a
aplicação gráfica iniciada sobre comando do gestor será o cliente que ira requisitar uma
ligação ao servidor, para troca de informação. Quando fechada a aplicação gráfica é
dada por terminada a comunicação TCP/IP e libertados os recursos utilizados no
atendimento ao cliente (thread).
Comandos
Serviço Aplicação
Gráfica
Alertas
Feedbacks
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
51
Figura 32 - Comunicação entre aplicação gráfica e o background service via sockets.
Para tornar tudo isto possível é necessário criar e configurar o servidor TCP/IP e ainda
definir e implementar um processo que ficará à escuta de pedidos de ligação,
provenientes do cliente. Na figura anterior, é ilustrada a configuração da comunicação
Servidor-Cliente TCP/IP, do lado servidor é necessário como primeira etapa definir um
socket que requer dois identificadores são eles: o endereço IP (indica local de um nó na
rede) e sua porta (identifica o canal de dados). O lado do servidor comporta-se de forma
passiva, isto é, aguarda pedidos pela parte da aplicação gráfica (cliente), isto é iniciado
através do método Start do objeto TcpListener com os identificadores bem definidos.
Quando um novo pedido é recebido e processado, é enviada uma resposta ao cliente e o
pedido é guardado num objeto do tipo TcpClient, após aceite, é iniciado um objeto da
classe thread que irá manter a comunicação com a aplicação gráfica, enquanto esta se
encontrar aberta pelo utilizador.
Este foi o modo de implementação do servidor TCP/IP, sendo então momento de
detalhar a implementação do Cliente TCP/IP na aplicação interface gráfica
desenvolvida em C#. Assim sendo, no desenvolvimento do cliente é primeiramente
definido o socket, responsável por estabelecer a comunicação com o serviço através do
endereço IP e respetiva Porta passados como parâmetro no seguinte método.
requestSocket = new Socket(ip, port);
Após executada a instrução anterior, a conexão é estabelecida podendo então o cliente
enviar comandos ao servidor (descritos na Tabela 11) que traduzem as ações ou
intenções do utilizador.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
52
4.3.2 Background Service
Na Figura 30 os módulos encontram-se contemplados com os subsistemas que
os constituem, para o caso do módulo serviço desenvolvido, existe além do subsistema
de comunicação que garante a comunicação deste com a aplicação gráfica outros quatro
subsistemas fundamentais, são eles:
Aquisição de dados geográficos (a);
Tratamento de dados (b);
Tratamento de erros (c);
Acesso e armazenamento de dados (d).
Antes de apresentar detalhes dos vários subsistemas que completam o módulo serviço,
invocados durante a execução da aplicação executada em background é descrito e
analisado o seu processo de Start-up ilustrado na Figura 33.
Este processo é iniciado com o estabelecimento de conexão à base de dados de forma
remota, a seguinte linha de código executa isso mesmo.
MySqlConnection(“Server=intelfleet.com;Database=intelfle_mydb;Uid=intelfle
_root;Pwd=xxxxx”);
O parâmetro Server indica o servidor e Database o nome da base de dados a quem será
estabelecida a conexão.
O seguinte passo, configura e inicializa o hardware utilizado pela aplicação Centro de
Controlo, processo descrito com maior detalhe ainda na presente seção. A partir deste
instante o serviço irá estar à espera dos dados provenientes das Unidades Móveis. O
passo seguinte é a obtenção através da realização de consultas à base de dados do tempo
de amostragem, definido pelo utilizador e da lista de veículos que estão assinalados para
monitorização das suas variáveis (localização, velocidade e se está livre de tarefas). Por
fim é criado o socket TCP/IP e iniciada a escuta a pedidos do cliente, isto é, o serviço
iniciará uma thread de atendimento ao cliente.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
53
Figura 33 - Processo de Start-up da aplicação executada em background.
Interface com o Hardware
A presente aplicação, interage com o módulo GSM descrito na secção 3.4.1. Este
dispositivo permite a interação da aplicação Centro de Controlo com a Unidade Móvel e
Terminal do Condutor, para tal são utilizadas as seguintes interfaces:
Porta Série;
Rede GSM.
Através da porta série e envio de comandos AT é criada uma ligação entre o Centro de
Controlo e o modem GSM. De modo a utilizar a porta série recorreu-se a classe
SerilPort da biblioteca System.IO.Ports [29]. Para configurar uma porta é necessário
definir o baudrate, uso do bit de paridade entre outras características que podemos
encontrar na Figura 34.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
54
Figura 34 - Algoritmo de configuração do modem GSM.
O fluxo de informação ilustrado na figura anterior representa a implementação da
configuração da porta série e posteriormente a conexão ao modem GSM. Este processo
inicia-se com a deteção de portas COM já utilizadas, o que pode significar que o modem
GSM já se encontra conectado fisicamente à entrada COM. Em caso afirmativo são
verificadas todas as portas COM conectadas com objetivo de detetar hardware utilizado
pelo Centro de Controlo. Para realizar este passo é necessário instanciar e inicializar um
objeto da classe SerialPort, com os parâmetros recomendados pelo fornecedor do
modem:
serialPort1=new SerialPort(serialports,9600,Parity.None,8,StopBits,One);
A instrução anterior inicializa o objeto chamado serialPort1 com um baudrate de
9600bps, sem bit de paridade, 8 bits de dados e um stopbit. Após aberta a conexão à
porta COM é finalmente testada a comunicação, o envio via série do comando “AT”
permite averiguar se o modem está conetado, pois após o envio é esperada uma resposta
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
55
dentro de um tempo (<3000ms), quando ultrapassado este tempo é gerado um timeout,
reportado o erro e terminada a execução do serviço.
Quando obtida uma resposta (“OK”) dentro do tempo espectável, é continuada a
execução do serviço, sendo que o próximo passo é a configuração da rede GSM. Por fim
e após configuração da rede GSM é indicada a função de atendimento
(SerialPort1_DataReceived) aos dados recebidos, esta função é invocada sempre que
novos dados são recebidos através da porta COM, o que corresponde ao subsistema
“Aquisição de Dados” descrito na 4.3.2.
serialPort1.DataReceived += new
SerialDataReceivedEventHandler(serialPort1_DataReceived);
No final destas configurações o equipamento está apto a ser utilizado pelo Centro de
Controlo e a comunicar com os restantes elementos da ferramenta IntelFleet via GSM.
a) Aquisição de Dados
O presente subsistema é responsável pela aquisição dos dados provenientes das
diferentes unidades móveis, é invocado quando são recebidas atualizações das
localizações das Unidades Móveis, o que requer a inicialização do hardware. Existem
dois tipos de aquisições: no modo periódica ou no modo “on-demand”, este último é
utilizado pelo Terminal do Condutor e pela presente aplicação enquanto o primeiro é
utilizado exclusivamente pelo Centro de Controlo.
Aquisição Periódica
Neste tipo de aquisição, como o próprio nome indica, corresponde a um evento
que ocorre em intervalos de tempo frequentes, definido pelo gestor de acordo com as
necessidades da organização. O utilizador gestor define o tempo de amostragem e
quando um veículo é colocado no modo periódico através da interface gráfica, é
comunicada essa intenção via socket TCP/IP ao serviço enviando o seguinte comando
(Tabela 11):
TRACKED_num;
O parâmetro “num” define o número do localizador (Unidade Móvel) instalado no
veículo, o procedimento do background service nesta situação é indicar à unidade
através do envio de comandos reconhecidos pelo mesmo que deseja receber
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
56
atualizações de forma periódica. O comando enviado encontra-se listado na -Tabela 17
e possui o seguinte formato:
*txxxx+
Os intervalos de tempo admissíveis e aceites pela ferramenta compreendem entre os 60
segundos e os 10800 segundos. Quando um veículo já se encontra em modo periódico e
com um tempo entre atualizações bem definido poderá ser alterado a qualquer instante
pelo gestor enviando novamente o comando anterior com o tempo desejado como
parâmetro.
Neste tipo de aquisições não é necessário enviar novos comandos a cada evento
ocorrido sendo apenas necessário indicar à Unidade Móvel para sair deste modo quando
não se deseja receber mais atualizações da posição do veículo através do envio do
comando:
*tstop+
Figura 35 - Fluxograma do subsistema de aquisição dos dados em modo periódico.
O fluxograma anterior reflete o comportamento do subsistema de aquisição de dados no
modo periódico. O serviço após enviar o pedido de atualização da informação do
veículo de forma periódica fica à escuta dos dados. Quando recebidos é invocado a
rotina de análise das mensagens de textos recebidas, abordada no presente capítulo na
secção 4.3.2 (Tratamento de Dados).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
57
Aquisição “on-demand”
Este tipo de atualizações da informação do veículo, foi implementado a pensar
nas situações que apenas se deseja conhecer a localização do veículo nesse preciso
instante e não monitorizá-lo continuamente, sendo especialmente útil como meio de
recuperação dos veículos roubados. O fluxograma ilustrado na Figura 36 representa o
comportamento subsistema no modo “on-demand”.
Figura 36 - Fluxograma do subsistema de aquisição de dados no modo “on-demand”.
Através da interface gráfica o utilizador Gestor indica o desejo de atualizar as variáveis
do veículo no modo “on-demand”, quando tal ocorre a interface é responsável por
transmitir esse desejo ao serviço, através do envio do seguinte comando (descrito na
Tabela 11):
Demand_num
O parâmetro “num” identifica o localizador do veículo (número SIM), este é notificado
do pedido de atualização imediata através do envio do seguinte comando descrito na -
Tabela 17:
*t0000+
A partir deste instante, a aplicação executada em segundo plano fica à escuta dos dados
provenientes da unidade. Quando recebidos, são colocados à disposição do subsistema
Tratamento de Dados, tendo por fim a tarefa de alertar o utilizador da receção de novos
dados.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
58
b) Subsistema de Comunicação
A presente secção demonstra como foi implementado o subsistema de
comunicação, responsável pela troca bidirecional de informação com os elementos
Unidade Móvel e Terminal do Condutor via GSM.
Receção de Dados
O Módulo GSM só é habilitado a receber mensagens quando configurado com
sucesso (processo de configuração GSM), a Figura 37 ilustra o comportamento da
aplicação após a receção de uma nova mensagem de texto.
Figura 37 - Comportamento sobre a forma de fluxograma do subsistema de Comunicação durante receção de
informação.
Quando recebida, é gerada pela porta série uma interrupção que invoca a função de
atendimento SerialPort1_DataReceived, nesta são realizadas as etapas apresentadas no
fluxograma, com o objetivo de consumir as mensagens de texto armazenadas no meio
de armazenamento definido durante a configuração da comunicação série (memória do
cartão SIM). Este processo inicia-se com a interpretação do comando recebido
(disponível no buffer da comunicação série), existe dois comandos AT de interesse para
o presente subsistema, são eles o CMTI e CMGR. O primeiro indica que foi recebida
uma nova mensagem e têm o seguinte formato:
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
59
+CMTI:”SM”, ID_SMS;
Deste comando é retirado o parâmetro “ID_SMS” que identifica a mensagem de texto
dentro da memória do SIM. Nesta situação é indicada a intenção de consumir o
conteúdo da mensagem de texto, através do envio do seguinte comando AT com o
parâmetro ID_SMS extraído no passo anterior:
AT+GMGR = ID_SMS;
O comando em falta (CMGR), indica que o conteúdo da mensagem de texto esta
disponível, colocando-o à disposição do subsistema Tratamento de Dados.
Os últimos passos visam garantir que nenhuns dados são perdidos, todas as informações
relevantes após tratadas e armazenadas na base de dados são eliminadas dando espaço a
novas informações/mensagens de texto. Contudo, pode ocorrer interrupções durante o
consumo da informação oferecida pela mensagem de texto gerado por uma nova SMS,
isto significa que o processo de consumo da informação anterior não foi terminado e
esquecido, ficando a nova informação com a capacidade de processamento.
De modo a evitar a perda de informações relevantes, são realizados os últimos passos do
fluxograma (Figura 37), estes eliminam as mensagens já consumidas (indicando o
ID_SMS no comando CMGD) e deteta a existência de mensagens “perdidas”, em caso
afirmativo estas são consumidas e esvaziada a memória SIM.
Envio de Dados
Como referido a transmissão é bidirecional, o que significa que este subsistema é
responsável pela transmissão dos dados aos elementos já mencionados na presente
secção. O fluxograma da Figura 38 identifica o fluxo de tarefas executadas por este
subsistema durante o envio de informação.
O primeiro passo verifica se o equipamento de hardware esta conetado, em caso
afirmativo o subsistema indica-lhe a intenção de enviar uma mensagem de texto para
um determinado destinatário através do seguinte comando:
AT+GMGS=N_SIM;
O passo final insere o corpo da mensagem e por fim o caráter CNTRL_Z, se o buffer da
porta série conter o valor “OK”, significa que foi realizada com sucesso as tarefas até
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
60
então do subsistema. Se este processo não for executado corretamente é reiniciado a
sequência de passos do fluxograma da figura seguinte.
Figura 38 - Comportamento sobre a forma de fluxograma do subsistema de Comunicação durante o envio de
informação.
c) Tratamento de Dados
Este subsistema de software é invocado após o subsistema de aquisição de
dados, isto deve-se à necessidade de processar a informação recolhida pelo subsistema
que o antecede para posteriormente armazenar e/ou apresentar os dados recolhidos aos
utilizadores. Este subsistema possui particular importância, pois a ele se deve a
responsabilidade de processar os dados recolhidos. Como exemplo, o Centro de
Controlo recebe atualizações da posição geográfica do veículo e após sua aquisição é
necessário reconhecer e validar estes dados utilizados para atualizar a informação
referente ao veículo. O fluxograma ilustrado na Figura 39 descreve o processo de
tratamento dos dados recebidos.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
61
Figura 39 - Algoritmo do subsistema de tratamento de dados.
Após a receção dum comando é verificada qual a intensão do utilizador, isto indica qual
a ação que deverá ser realizada e ainda a informação que é necessária recolher do
comando. Existe uma variedade de comandos reconhecidos pela aplicação (descritos na
Tabela 11), assim é necessário comparar o comando com um lote de comandos
permitindo distinguir o tratamento correspondente ao pedido recebido.
Depois de identificado o tratamento a ser executado, é analisada a necessidade de
responder ao elemento que realizou o pedido, caso tal se verifique é enviada a
resposta/feedback ao respetivo elemento. No passo final é invocado o subsistema de
acesso e armazenamento de dados para atualização de informação.
A Tabela 11 descreve todos os comandos que são aceites e reconhecidos pelo serviço,
estes são provenientes da aplicação gráfica e resultam da interação do gestor com a
interface gráfica durante a execução das suas tarefas na organização.
Contudo existe outros comandos que não se encontram descritos na tabela anterior que
também são reconhecidos pela aplicação executada em background, estes comandos são
provenientes das unidades de localização móveis e resultam dos pedidos de localização
e de bloqueio. A descrição destes comandos é realizada na seção 4.6.2 (Formato da
Resposta às Solicitações de Atualização da Localização Unidade Móvel)
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
62
Tabela 11 - Comandos provenientes da interface gráfica reconhecidos pelo serviço.
Comando Parâmetros Descrição Tratamento
TRACKED_localizador
Localizador-número
SIM da unidade de
localização móvel
Pedido de
atualização de
dados geográficos
no modo
periódico
Envio de comando à
unidade móvel
indicando o início de
comunicação de forma
periódica
STOP_localizador
Localizador-
número SIM da
unidade de
localização móvel
Pedido de
paragem de
atualização de
dados no modo
periódico
Envio de comando
indicando a intensão de
não voltar a receber as
atualizações de forma
periódica
UPDATE_time
Time-tempo entre
atualizações definido
em segundos
Alteração do
tempo do tempo
de amostragem
Envio do status do
processo de alteração
ao Gestor
FEEDBACK_ACTIONS ----
Request do status
da comunicação
no modo
periódico com
todos os veículos
Criação de uma string
com a informação da
comunicação, onde
esta indica o número
de atualizações já
recebidas, isto permite
detetar falhas na
comunicação
DEMAND_localizador
Localizador-número
SIM da unidade de
localização móvel
Pedido de
atualização dos
dados geográficos
no modo “on-
demand”
Envio de comando à
unidade móvel pedindo
a atualização da
localização geográfica
no preciso instante
BLOCK_localizador
Localizador-número
SIM da unidade de
localização móvel
Pedido de
bloqueio do
veículo
Envio do comando de
bloqueio reconhecido
pela unidade móvel
UNBLOCK_localizador
Localizador-número
SIM da unidade
localização móvel
Pedido de
desbloqueio do
veículo
Envio do comando de
desbloqueio do veículo
reconhecido pela
unidade móvel
d) Tratamento de Erros e Alertas
Nesta secção do presente capítulo é descrita a estratégia usada na geração de
alertas e tratamento de erros. O primeiro tema abordado é o tratamento de erros, seu
objetivo é verificar se a informação proveniente dos restantes elementos do sistema é
válida de forma a não ser processada e armazenada informação invalida que possa gerar
incoerências durante o planeamento das tarefas dos veículos. Deste modo podemos
identificar as seguintes fontes de erros:
Erros gerados durante a comunicação entre entidades, corresponde a qualquer
erro que impeça a comunicação do Centro de Controlo com outras entidades da
ferramenta;
Erros gerados durante a comunicação entre o background service e a aplicação
gráfica;
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
63
Erros gerados durante o processamento dos dados recolhidos, corresponde a
dados inválidos recebidos de outros elementos do sistema (por exemplo,
atualizações geográficas transmitidos pela unidade móvel).
A estratégia adotada no tratamento dos erros das várias fontes baseia-se essencialmente
na notificação dos erros ao utilizador. Como é possível verificar nos vários fluxogramas
utilizados para descrever o comportamento dos subsistemas do background service,
quando ocorre alguma falha é reportado o erro, isto significa que estes são gravados
num ficheiro que armazena a informação do erro: o instante em que ocorreu, a origem e
ainda uma pequena descrição.
Quando o utilizador inicia a aplicação é notificado dos erros ocorridos após o último
acesso à aplicação Centro de Controlo. Todos os erros podem ser consultados por data
no interior da aplicação gráfica, a ocorrência de erros é notificado como já referido
através da utilização da classe MessageBox, os objetos desta classe permitem imitar
sons e apresentar uma caixa de diálogo com detalhes dos erros.
Para erros que limitem a execução do Centro de Controlo (como é o caso de
inicialização do serviço, erros gerados durante a comunicação GSM ou durante o acesso
à base de dados), além da notificação ao utilizador é-lhe exposta a possibilidade de
executar uma nova tentativa, isto é, de repetir o passo que não foi concluído devido ao
erro ocorrido. Por exemplo, nas situações que o background service não se encontra em
execução a aplicação notifica o utilizador e fornece-lhe a interface necessária para
iniciar a execução da aplicação executada em background.
No que diz respeito a alertas estes podem ser dos seguintes tipos:
Alerta de furto do veículo;
Serviço não realizado antes do tempo definido;
Notificação de atualizações da localização por veículo;
Alerta de comunicação interrompida com uma determinada Unidade Móvel;
Os alertas de furtos acontecem por indicação do condutor, quando detetado um furto do
veículo ou produtos é informada toda a organização utilizando a tecnologia web service
para alterar o campo ‘alertas’ da linha que corresponde ao veículo furtado. A aplicação
gráfica notifica o utilizador quando deteta alterações na tabela veículos.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
64
As atualizações são obtidas e processadas pelo subsistema “Aquisição de dados” do
background service, quando tal ocorre o elemento service avisa a aplicação gráfica
através do meio de comunicação adotado, por fim a aplicação notifica o utilizador via
messagebox deste acontecimento.
A comunicação interrompida com os veículos é detetada através da comparação do
número de feedbacks recebidos por estes (atualizações periódicas), sempre que é
alterado o tempo de amostragem é transmitida essa informação a todos os veículos que
estão a ser “monitorizados”, assim é reiniciada a contagem dos feedbacks, o mesmo se
sucede quando um novo veículo é referenciado para ser monitorizado. Deste modo
quando existir uma diferença assinalável entre feedbacks a aplicação gráfica notifica o
utilizador que não estão a ser obtidas respostas da respetiva Unidade Móvel. Além disso
o utilizador poderá a partir deste momento testar a unidade individualmente enviando
uma mensagem de texto e analisando o estado da mensagem de texto, isto é, se foi
enviada e recebida pela unidade, ficando à espera de uma resposta. Caso tal não se
suceda é indicada a situação a toda a organização através da introdução de uma linha em
branco na tabela “Servicos”, isto indicará que a tarefa do condutor não foi seguida na
totalidade.
e) Subsistema de Acesso e Armazenamento de Dados
Este subsistema tem a tarefa de aceder de forma remota à base de dados, quer
seja para executar operações de escrita ou de leitura na base de dados. Esta encontra-se
alocada num servidor contratado, contudo não permite o acesso remoto. De forma a
alterar esta situação, é efetuado os seguintes passos:
Aceder ao cPanel;
Entrar em MySQLRemoto;
Adicionar host de acesso, colocando o símbolo “%” no campo Host.
O símbolo adicionado (%) indica que o root chamado ‘intelfle_root’ pode aceder de
qualquer host à base de dados. Após estes passos teremos ativado o acesso remoto ao
MySQL do servidor como demonstra a Figura 40.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
65
Figura 40 - Hosts com acesso permitido à base de dados.
As operações de escrita e leitura são realizadas utilizando a linguagem SQL, esta é uma
linguagem de consulta de base de dados que implementa os conceitos definidos no
modelo relacional.
4.3.3 Aplicação Gráfica
Esta aplicação fornece ao utilizador uma interface gráfica para o cumprimento
das suas tarefas, tais como:
Gestão dos recursos físicos da organização (veículos, condutores, utilizadores e
clientes);
Manipulação do tempo de amostragem;
Controlo os instantes que os veículos devem ser colocados em modo periódico;
Assegurar a comunicação com as unidades móveis;
Bloqueio do veículo;
De modo a garantir tudo isto, é necessário a leitura e escrita na base de dados remota,
isto permite a visualização, introdução ou edição dos elementos veículos, condutores
entre outros que correspondem a entidades na base de dados. A comunicação com o
background service é garantida com o objetivo do utilizador transmitir ordens à unidade
móvel, tais como:
Alteração do tempo entre atualizações;
Habilitar ou desabilitar atualizações periódicas;
Bloqueio do veículo;
4.4 Posto de Trabalho
Esta aplicação consiste numa ferramenta Web designada de Posto de Trabalho,
fornece uma solução para a gestão, localização e otimização de frotas via Web.
Na Figura 41 é apresentada uma visão geral desta aplicação, que se encontra
constantemente em contato com a base de dados responsável por armazenar os dados
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
66
provenientes do veículo num servidor. Esta aplicação tem a tarefa de presentear ao
coordenador os recursos necessários para a gestão da frota através de qualquer
computador ligado à internet.
Figura 41 - Visão Global da aplicação Posto de Trabalho.
Assim sendo, para o desenvolvimento da ferramenta IntelFleet e mais concretamente a
interface Posto de Trabalho é necessária a utilização de um servidor externo, que
permita armazenar informação numa base de dados e ainda que permita hospedar os
ficheiros que constituem o site.
O servidor utilizado para o efeito é nos fornecidos pela Webtuga, Lda, que fornece
serviços online de máxima qualidade a custos reduzidos. Dispõem de uma variedade de
serviços de alojamentos de sites, registo de domínios, revenda de alojamento, servidores
privados e servidores dedicados, marketing online entre outros.
Após tomadas as decisões na fase de planeamento de quais as tecnologias e recursos a
utilizar apresentadas anteriormente, foi colocado em prática o conhecimento resultante
do estudo dessas tecnologias dando origem à etapa de implementação.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
67
4.4.1 Página Web
A presente aplicação comunica frequentemente com o servidor IntelFleet,
existindo inúmeras trocas de informação entre ambos pois é seguida uma arquitetura
Cliente-Servidor. Dois métodos foram adotados como meio de comunicação com o
servidor, são eles:
Através de métodos HTTP;
Por meio de requisições assíncronas ao servidor.
Os ficheiros que compõem o domínio são alocados no servidor web, dentro destes
podemos identificar os ficheiros de acordo com as seguintes programações:
programação da página web (HTML e PHP), do lado do cliente (JavaScript, realiza
pedidos ao servidor e manipula a página diretamente após receção) e por fim o lado do
servidor (PHP utilizado como linguagem de script do lado do servidor, permite receber
os pedidos realizados pelos clientes e efetuar o processamento do mesmo). A tabela
seguinte apresenta os diferentes ficheiros implementados que compõem toda a lógica e
funcionalidades implementadas na aplicação Posto de Trabalho.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
68
Tabela 12 - Associação de ficheiros por funcionalidade, desde seu aspeto (HTML) até ao ficheiro (JavaScript)
responsável por efetuar as requisições ao servidor e por fim o arquivo que processa estes pedidos.
Ficheiro
HTML
JavaScript
invocada
pela página
Ficheiro PHP para o
processamento das
requisições
Descrição da
funcionalidade da
página Index.html --- Login.php Login da aplicação
Index2.html --- --- “Menu” da aplicação
Inf_extra.php Veiculos_extra.js
Veiculo.php Veiculocomplete.php
Cliente.php Clientescomplete.php
Visualização de um conjunto de
informações relevantes no planeamento das
tarefas
Mapas.php veiculoscript.js Veiculo.php
Veiculocomplete.php
Visualização da localização dos veículos
sobre um mapa
Querys.php javascript.js
Veiculo.php Veiculocomplete.php
Cliente.php Clientescomplete.php
Conductor.php Condutorescomplete.php
Pesquisas de todos os recursos físicos e
humanos registados na base de dados, as
pesquisa spodem ser realiadas segunda
chaves de pesquisa, por exemplo consultar apenas tarefas que ainda não foram
terminadas
Rotas.php rotascript.js
Veiculo.php Veiculocomplete.php
Cliente.php Clientescomplete.php
Visualização do trajeto percorrido por um veículo durante a execuºão de uma
tarefa, e detetar erros na mesma.
Servicos.php serv_script.js
New_service.php Veiculo.php
Veiculocomplete.php Cliente.php
Clientescomplete.php Conductor.php
Condutorescomplete.php
Criação de novas tarefas
ClientesView.php --- --- Detalhes do conductor
selecionado
VeiculoView.php --- --- Detalhes do veículo
selecionado
Requisições Assíncronas ao Servidor
A utilização de uma programação tradicional através dos métodos HTTP torna-
se menos amigável, mais lenta e menos aconselhável para as interações com o utilizador
coordenador, pois é retornada uma página a cada solicitação realizada ao servidor. Com
o Ajax obtemos uma interface dinâmica, isto se deve às interações serem realizadas em
segundo plano, assim o utilizador poderá continuar na página. As requisições são
iniciadas no código JavaScript e quando finalizadas, atualiza a página a partir do
código-fonte HTML.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
69
As funcionalidades presentes na Figura 22 recorrem à tecnologia AJAX como modo de
obter dados relevantes à realização das tarefas do coordenador. A funcionalidade
“Consulta restrita da B.D” facultada pelo Posto de Trabalho permite ao utilizador
pesquisar várias informações relativas aos recursos da organização e ainda informações
das frotas (posição atual e rota percorrida ou a percorrer). A partir da interface
apresentada na Figura 42, o utilizador pode realizar diferentes tipos de pesquisa,
necessitando apenas de indicar quais os dados que pretende consultar, podendo ser do
seguinte tipo: informação dos veículos da organização, dados relativos aos clientes
registados ou dos funcionários da empresa e por fim serviços ou que se encontram em
fase de execução ou concluídos.
Figura 42 - Pesquisa de dados armazenados no servidor.
A consulta de informação dos veículos será aqui utilizada como exemplo de
demonstração da interação dinâmica com o servidor. Para tal, é analisada a
implementação do cenário de pesquisa dos veículos.
Toda a informação que resulta da pesquisa é proveniente da base de dados, para obtê-la
é necessário percorrer várias camadas de software até a fonte de informação.
A Figura 43 ilustra as interações implementadas entre as camadas durante as requisições
assíncronas ao utilizador.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
70
Figura 43 - Interação entre as diferentes camadas durante a requisição assíncrona.
O fluxo resultante das interações entre as camadas pode ser descrito pelas etapas
seguintes:
1. O utilizador gera um evento ao clicar no botão ‘OK’, indicando a sua intenção
de realizar uma pesquisa, isto resulta numa chamada do JavaScript a uma função
que inicializa um objeto XMLHttpRequest;
2. O objeto é configurado com dois parâmetros: ACTION (utilizado para indicar ao
servidor qual a tarefa que deve realizar) e ID (indica qual o componente que
acionou o evento);
3. O objeto XMLHttpRequest faz uma solicitação assíncrona ao servidor;
4. Do lado do servidor, um objeto listener tem a tarefa de manipular as requisições
dos clientes. Os dados requisitados são obtidos da base de dados e utilizados na
criação de um documento XML utilizado como resposta à requisição;
5. Por fim o objeto XMLHttpRequest recebe o documento XML utilizando uma
função callback, processa o documento e atualiza o HTML DOM para apresentar
os dados da pesquisa.
A Figura 43 apresenta um exemplo de um possível documento XML retornado como
resposta à requisição realizada pelo lado do cliente.
<veiculos>
<veiculo>
</veiculo>
…
</veiculos>
<?php
?>
XMLHttpRequest
Página Web
querys.php
<script type=”texto/javascript”>
</script> Ficheiro javascript.js
function callback(){
//Atualizar HTML DOM }
Atualiza área
especifica da página
Evento
onclick
2
5
Ficheiro
veiculocomplete.js
Listener
Base de dados
1
Cliente Servidor
3
4
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
71
Figura 44 - Exemplo do ficheiro XML enviado como resposta pelo servidor.
Estes dados são processados, extraídos e tornados disponíveis ao utilizador após a
atualização do DOM HTML da página web.
A implementação dos diferentes passos enumerados que compõem todo o processo de
requisição assíncrona bem como a utilização da tecnologia Ajax encontra-se detalhada
no anexo A.6.1 (Requisições Assíncronas).
4.4.2 Inclusão dos Mapas da Google
Numa aplicação que recorre a API do Google Maps o elemento fundamental é o
objeto Map (mapa), pois é a partir deste que todas as restantes operações sobre o mapa
descritas no presente subcapítulo se realizam.
Para que a API funcione no domínio da ferramenta torna-se necessário realizar os
passos seguintes [41] (sua implementação e estudo dos objetos utilizados estão
disponíveis para consulta no anexo A.6.2):
1. Carregar API do Google Maps;
2. Mapear elementos DOM;
3. Instanciar objeto Map;
4. Configurar o mapa;
5. Carregar o mapa.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
72
Mapas Interativos
A interface disponibilizada pela página web da ferramenta recorre com
frequência a mapas, com o objetivo de apresentar informações relevantes ao utilizador
coordenador. Das funcionalidades presentes na Figura 22, ainda não estudadas podemos
identificar o seguinte conjunto como funcionalidades que recorrem a mapas para
cumprimento dos seus objetivos:
Visualização da posição geográfica do veículo (a);
Verificar trajetórias percorridas durante a execução de um serviço/tarefa (b);
Validar rota percorrida durante a execução das tarefas (c);
Planeamento de novas tarefas (d).
A informação da frota necessária para gerar o mapa é proveniente da base de dados,
para obtê-la é necessário percorrer várias camadas de software até consultar a base de
dados como descrito na Figura 43 e já demonstrada sua implementação no exemplo da
pesquisa de veículos (requisição assíncrona).
a) Visualização da Posição Geográfica do Veiculo
A página ‘www.intelfleet.com/mapas. php’ disponibiliza esta funcionalidade ao
utilizador e possui o aspeto apresentado na Figura 45, onde podemos facilmente
identificar o mapa e o formulário utilizado para pesquisa, possibilitando a pesquisa com
uma das três diferentes palavras-chave:
“Estado Ocupado”, pesquisa de veículos que se encontram a realizar uma tarefa;
“Estado Livre ”, veículos que se encontram livre;
“Todos os veículos ”, apresenta todos os veículos independentemente do seu
estado.
As informações dos veículos (matrículas) são apresentadas quando o utilizador acede à
página web desenvolvida para o efeito. Durante o carregamento da página são
realizados os seguintes passos:
Configuração do mapa definido na página HTML;
Tornar os elementos DOM da página acessíveis;
Inicialização e configuração do objeto XMLHttpRequest;
Realização da solicitação assíncrona ao servidor.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
73
Figura 45 - Aspeto encontrado pelo utilizador quando pretende conhecer a posição geográfica dos veículos
sobre um mapa.
A interação assíncrona realizada durante o carregamento da página é em tudo idêntica
ao caso analisado anteriormente (exemplo de requisição assíncrona descrito em 4.4.1),
inclusive a URL e parâmetros que configuram a solicitação. Isto significa que do lado
do servidor, o listener que irá processar o pedido é o mesmo que o já analisado pois as
informações pretendidas coincidem. Consequentemente o ficheiro XML transmitido
como resposta, possui o mesmo formato que o apresentado como exemplo na Figura 44.
Após carregada a página, esta encontra-se atualizada com as informações dos veículos
presentes na tabela HTML da referida página.
Para cada uma das matrículas carregadas na página é criado um link, quando clicado
desencadeia o seguinte fluxo de informação (Figura 46), os passos nele realizados visam
apresentar sobre um mapa a posição atual do veiculo (exemplo descrito na Figura 47).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
74
Figura 46 - Processo de inserção da localização do veículo no mapa.
O marcador visível na Figura 47 é interativo e permite escutar eventos. Definindo o
evento ‘click’ para este tipo de marcador permite à página exibir janelas de informação
utilizadas para apresentar informação do veículo.
Figura 47 - Marcadores interativos.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
75
Os atributos armazenados que indicam a localização do veículo são: latitude e
longitude. Contudo na Figura 47 é apresentado além das informações recebidas como
argumentos (do método indicado no link) o endereço correspondente. Para obter a
localização geográfica através das coordenadas geográficas obtidas da base de dados é
efetuada a geocodificação inversa. A API do Google Maps fornece recursos para a
realização deste passo, mais em concreto o objeto Geocoder.
A utilização deste objeto, a análise dos parâmetros utilizados e processamento dos
resultados obtidos durante o processo de geocodificação encontrasse disponível para
consulta no anexo A.7.1.
b) Visualizar Trajetórias de um Dado Serviço/Tarefa
Existem duas situações em que é necessário traçar rotas no mapa a partir das
funcionalidades fornecidas pela API do Google Maps, são elas:
Pesquisa de serviços por realizar;
Pesquisa de serviços já finalizados;
Para ambos os casos o princípio de funcionamento e implementação é idêntico, assim
sendo foi adotado o ultimo caso (serviços finalizados) como exemplo a analisar.
Pesquisa de Serviços Finalizados
A pesquisa de tarefas dadas como terminadas, desencadeia duas requisições ao
servidor, ambas se baseiam na metodologia adotada em secção 4.4.1 (Requisições
Assíncronas ao Servidor). Do lado do servidor é apenas coletada e transmitida ao
cliente-sider as tarefas presentes na tabela “Servicos” que já foram terminados (campo
‘realizado’ com o valor ‘1’), por fim é processada a resposta e atualizado o DOM HTML
(exemplo Figura 48).
Figura 48 - Página 'querys.php' após a primeira requisição ao servidor.
A segunda requisição ocorre quando o utilizador clica num dos serviços presentes na
tabela HTML, realizando nesse instante uma chamada à função ‘XML_matricula()’
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
76
(através do link criado para cada uma das linhas), iniciando desta forma a requisição
assíncrona ao servidor.
A Figura 49 apresenta o fluxo de informação antes, durante e após a requisição
(apresentação da rota do serviço num mapa ao utilizador).
Figura 49 - Fluxo de informação gerado durante a pesquisa de tarefas já realizadas.
A resposta do servidor à solicitação tem o formato do exemplo ilustrado na Figura 50,
este possui a informação geral do serviço e o conjunto de pontos geográficos recolhidos
durante a execução da tarefa. Após o processamento da resposta os dados extraídos são
utilizados para traçar uma rota que espelhe o trajeto realizado durante a execução do
serviço/tarefa pelo veículo (processo descrito no anexo A.7.2).
A utilização do objeto da DirectionsRequest da API do Google Maps na geração da rota
e a criação dos Wayppoints é descrita no anexo A.7.3.
<composers>
<composer>
</composer>
…
</composers>
<?php
?>
Página Web querys.php
<script type=”texto/javascript”>
</script>
Ficheiro javascript.js
function callback()
{}
Evento onclick
2
5
Ficheiro
rotacomplete.js
Listener
Base de dados
1
Cliente Servidor
3
4
function XML_matricula
{
}
XMLHttpRequest
function
MAP_ROUT()
Aualiza
Mapa e
DOM HTML
rotascript.js querys.php
6
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
77
Figura 50 - Exemplo da resposta do servidor ao pedido de informações dos pontos geográficas percorridos
durante a execução de um dado serviço.
c) Validar rotas percorridas durante a execução das tarefas
O utilizador ao selecionar um veículo em execução (página web,
http://www.intelfleet.com/Rotas.php) irá gerar um evento que atualiza o mapa, com a
rota que o veículo deverá percorrer, é ainda colocado um marcador na última posição
conhecida do veículo sobre o mapa. O marcador criado serve de centro para um círculo
criado e apresentado no mapa com um raio de um km. Ao mapa são adicionados dois
controlos, são eles:
Localização, centra o mapa na posição atual do veículo;
Rota, centra o mapa na trajetória delineada e desencadeia o processo de
validação da trajetória.
A estratégia de validação de uma trajetória é ilustrada sobre a forma de fluxograma na
Figura 51. No primeiro passo é traçada a rota que correspondente à definida pelo
utilizador coordenador, durante este processo é retirado os vários steps que resultam da
utilização no objeto DiretionsRequest.
Dados gerais
do
serviço
realizado
Ponto
geográfico
com ID=1
Ponto
geográfico
com ID=2
Restantes
pontos
geográficos
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
78
Um step corresponde a um ponto de decisão num trajeto, isto é, locais onde existe uma
possibilidade de alterar o seu caminho (rotundas, entroncamentos, pontos de viragem),
este possui além das coordenadas geográficas do ponto a distância deste até o step
seguinte. Estes dados são vitais para o sucesso da estratégia implementada.
Figura 51 - Algoritmo implementado para a deteção de trajetos indesejados.
Estas informações são utilizadas para calcular a distancia desde o step até a posição
atual do veículo. Caso exista algum step a uma distância inferior a um quilómetro do
veículo significa que este passou recentemente por esta posição e que está
potencialmente a seguir a trajetória delineada. Em caso negativo, o passo seguinte visa
obter informação (pontos geográficos obtidos durante a realização até então da respetiva
tarefa) que permita averiguar se o veículo seguiu outras direções ou se encontra entre
steps distantes um do outro.
Após isto são calculadas as distâncias entre os pontos e os vários steps, poderá existir
mais que uma distância inferior a um quilómetro, caso tal se verifique é selecionado o
step que se encontra a uma distância pequena (<1 km) do ponto geográfico, que
corresponde à atualização da localização mais recente.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
79
Com este step podemos calcular a distância relativa à posição atual do veículo e
comparará-la com a distância relativa do step selecionado com o seguinte da rota
delineada. Caso se verifique que a distância entre os steps é superior à primeira
calculada, garantimos que o veículo se encontra na rota mas entre steps distantes, caso
contrário seguiu um novo trajeto que não o sugerido pelo coordenador.
A utilização dos recursos da API do Google Maps para a implementação desta estratégia
é analisada e encontra-se disponível para consulta no anexo A.6.2.
c) Planeamento de Novos Serviços
A página “http://www.intelfleet.com/servicos.php”, oferece a interface e a
informação necessária ao utilizador para planeamento das tarefas. As seguintes
informações compõem a tarefa e parte destas são preenchidas manualmente pelo
coordenador durante a criação do mesmo:
Data limite, indica o prazo limite para a realização da tarefa;
Cliente, especifica o utilizador que requisitou a tarefa;
Condutor, indica qual o funcionário que ficara responsável pela execução da
tarefa;
Kms, dá a conhecer uma estimativa da distância a percorrer;
Evitar autoestradas;
Evitar estradas principais,
O número de quilómetros não é definido pelo utilizador, é preenchido automaticamente
após determinado o ponto de destino da tarefa. O valor da distância em quilómetros é
obtido através dos recursos da API do Google Maps que permitem o cálculo de
distâncias entre dois pontos.
De modo a que não seja introduzido valores inválidos no campo ‘Data prevista para
realização da tarefa’, todos dados inseridos são sujeitos a um processo de validação.
Quando este campo sofre alterações, é gerado um evento que valida apenas dados
inseridos que correspondem a datas e nunca inferiores à data atual. Os campos ‘Evitar
auto-estradas’ e ‘Evitar estradas principais’ permitem ao planear a rota consoante as
variáveis que influenciam a execução da tarefa (como evitar zonas com maior trânsito,
reduzir distâncias, gastos em combustíveis ou gastos em portagens entre outros).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
80
O utilizador necessita de se basear em informação relevante e atualizada durante a
geração das tarefas, pensado nessa situação é-lhe disponibilizado um conjunto de dados
relevantes que poderão influenciar o planeamento da tarefa. A página HTML ilustrada
na Figura 52 apresenta por veículo, o tempo estimado para realização da tarefa levando
em conta a distância desde a sua posição atual até ao destino indicado e ainda informa
sobre a disponibilidade atual dos condutores. Ao selecionar um dos veículos é
apresentado num mapa o trajeto consoante as variáveis introduzidas que definem um
serviço, diferentes rotas podem ser geradas, isto permite escolher qual a rota ideal (por
menor distância percorrida ou menos custos gerados devidos a portagens por exemplo).
Figura 52 - Informação relevante para o planeamento de novos serviços.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
81
4.5 Terminal do Condutor
A aplicação é destinada a qualquer dispositivo móvel com pelo menos a versão
2.2 (Froyo) do sistema operativo Android instalado. A utilização da aplicação deve ser
intuitiva e com uma interface amigável, deverá oferecer ao utilizador o feedback em
ações importantes, além destes requisitos a aplicação deverá na ocorrência de erro
notificar o utilizador a partir de uma mensagem de erro simples de compreender.
4.5.1 Visão Global da Aplicação
A presente aplicação descrita através do diagrama de blocos da Figura 53 é uma
solução móvel baseada nos recursos (módulos) do sistema operativo móvel escolhido no
desenrolar do projeto.
Trata-se de uma aplicação que permite uma comunicação bidirecional via GSM do
condutor com o gestor e ainda uma interação com o coordenador via Web service. Ao
nível da gestão de tarefas, permite visualizar detalhes das tarefas, tais como: distância a
percorrer, o melhor percurso, visualizar em qualquer instante a posição do
veículo/condutor, receber e enviar alertas/mensagens de texto.
Figura 53 - Overview da aplicação Terminal do Condutor.
A descrição gráfica anterior, identifica os vários elementos Android utilizados na
implementação do Terminal do Condutor, são eles:
Activity, fornecem a interface gráfica ao utilizador para este executar suas
tarefas;
Broadcast Receiver, classe utilizada para filtrar o conteúdo de mensagens de
texto recebidas;
Broadcast Receiver
Cliente
Aplicação Android Servidor IntelFleet
Atividades
Background Service
Scanner
SGBD
Base de
dados
Suporte
às requisições
do cliente
Servidor
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
82
Service, executado em backrground têm objetivo de detetar novas tarefas
planeadas pelos coordenadores.
Scanner, permite a leitura de QRcodes.
4.5.2 Atividades
Cada atividade é representada por uma tela na aplicação, possui interface ao
utilizador composta por Views, componentes gráficos entre outros. Assim na presente
seção é descrita as várias atividades que correspondem do ponto de vista do condutor à
interface que faculta as funcionalidades necessárias à execução das suas tarefas. Todas
as atividades descritas na Tabela 13 estendem obrigatoriamente a classe
android.app.Activit [42].
Na implementação de qualquer atividade no sistema operativo Android, existe um passo
obrigatório que se repete para cada umas das atividades listadas na tabela anterior, este
passo visa declarar uma atividade como sendo parte da aplicação.
Assim sendo, a aplicação Terminal do Condutor é descrita no arquivo
AndroidManifest.xml, neste é declarado todas as Activitys, Services,
BroadcastReceivers e ContentProvider5 da aplicação [42]. Deve ainda conter todas as
permissões para a aplicação, por exemplo, se a aplicação requer acesso à rede, então
deve ser especificado no arquivo. A implementação deste passo encontra-se detalhada
no anexo A.8.1.
Os principais recursos utilizados nas atividades que implementam as funcionalidades
necessárias pelos condutores para cumprimento das suas tarefas são:
API Google Maps, permite ao condutor visualizar informações num mapa como
localização do veículo entre outros;
SMS messaging, recurso utilizado para o envio e receção de mensagens de texto;
Web services, tecnologia utilizada como meio de obter informações armazenadas
na base de dados do servidor.
No anexo A.8, encontra-se descrita a implementação das principais funcionalidades da
aplicação ilustradas no diagrama use-case da Figura 21.
5 Componente Android, permite armazenar e recuperar dados, disponibilizando-os a outras aplicações.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
83
Tabela 13 - Conjunto de Atividades que compõem a aplicação Terminal do Condutor.
Atividade Funcionalidade
do use-case
Recursos
Android Descrição
IntelFleetActivity Login Web service,
grupo de View
Classe que fornece interface gráfica
no processo de login
IntelFleet_Menu
Seleção da
funcionalidade a
executar
Grupo View
Tela para seleção (direcionando o
utilizador) das diferentes
atividades/tarefas
IntelFleet_gps
Visualização da
posição do veículo
num mapa
Grupo View e API
do Google Maps
Apresentação da posição do veículo
num mapa
IntelFleet_location Comunicação com
a unidade móvel
API Google Maps,
Grupo View e
SMS messaging
Envio de comandos à unidade móvel
requisitando atualização da
localização, processamento da
resposta
IntelFleet_tasks Notificação de
tarefas
Web services,
Grupo View e
background
service
Tela apresentada como notificação ao
utilizador de uma nova tarefa
IntelFleet_Scores
Consulta do
histórico de
serviços
Grupo View e Web
Services
Tela composta por 2 tabs, uma
apresenta informações relevantes do
user e a outra o histórico de serviços
por ele realizado
IntelFleet_stop Bloqueio do
veículo
SMS messaging e
Grupo View
Interface para realização do pedido
de bloqueio do veículo
IntelFleet_vehicles Registo de veículos Intent Integrator,
Web services
Permite registar/associar veículo ao
utilizador/condutor através de um
Barcode scanner
IntelFleet_warn Alertas Grupo View e
Web Services
Notifica o utilizador que o prazo para
terminar a tarefa está prestes a
expirar/expirou
IntelFleet_gps_warn Alertas
Grupo View ,
Google Maps e
Web Services
Apresenta dados complementares aos
dados apresentados na atividade
anterior num mapa
4.5.3 Broadcast Receiver (Filtragem de Mensagens de Texto)
Um Broadcast Receiver é um componente Android que permite registar eventos
para todo um sistema ou aplicação [42]. Assim todas as aplicações registadas como
receivers de um dado evento, são notificados quando este ocorrer. A partir da sua
definição é possível identificar a sua utilização no âmbito do projeto. Este componente
permite filtrar as mensagens de texto recebidas pelo smartphone, de modo a identificar
as que se destinam à aplicação Terminal Condutor, sendo bastante útil quando se
pretende uma certa performance da aplicação para um determinado conteúdo da
mensagem recebida. Por exemplo, quando recebida uma atualização “on-demand”
proveniente da Unidade Móvel pretende-se que estes dados sejam apresentados ao
utilizador após a geocodificação, este é o exemplo adotado para explicação do
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
84
funcionamento do sistema durante o processo de aquisição das mensagens de texto
(Figura 54).
Figura 54 - Processo iniciado após receção de mensagem de texto.
Para filtrar as mensagens recebidas, foi então criada uma instância da classe Broadcast
Receiver. Este objeto habilita a aplicação Terminal do Condutor a receber Intents
provenientes de outras aplicações, ou seja, habilita a aplicação de manusear eventos
gerados por outras aplicações. Como ilustrado na Figura 54, quando uma nova
mensagem é recebida no smartphone um Intent é criado e gerado um evento na
aplicação desenvolvida listada como Receiver, o que invocará o método onReceive(). A
mensagem de texto encontrar-se-á contida no objeto Intent (segundo parâmetro do
método onReceive) criado após receção da SMS. A mensagem é extraída e analisado o
seu conteúdo, no caso da receção das atualizações “on-demand” consiste numa
mensagem com o formato apresentado em 4.6.2 (Formato da resposta às solicitações), à
qual é extraída as variáveis (coordenadas geográfica) de interesse, e realizada a
geocodificação e apresentado a localização do veículo. A atualização “on-demand” é
utilizada como exemplo na utilização do módulo BroadcastReceiver para o processo de
aquisição e leitura de mensagens de texto.
4.5.4 Serviço Executado em Background
Um serviço é executado em background numa aplicação Android sem qualquer
interação do utilizador [42]. No contexto do projeto deseja-se que a aplicação Terminal
do Condutor esteja “atenta” a novas tarefas criadas pelos coordenadores durante a
interação com o Posto de Trabalho para o efeito analisada em 4.4.1 (Planeamento de
Novos Serviços). Quando uma nova tarefa é atribuída ao condutor, é esperado que a
aplicação Android notifique o utilizador condutor, para tal foi desenvolvido um
Start
Nova
SMS Envia
Intent
IntelFleet_location Processar
dados
Ativa
notificação
SMS
Broadcast
Receiver
Processar
dados
OnReceive()
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
85
background service (componente Android service) que executará a tarefa de detetar
novas tarefas do condutor em questão. O algoritmo que traduz a implementação e
comportamento do serviço encontra-se ilustrado na seguinte figura.
Figura 55 - Módulo Serviço executado em background na aplicação Android (detetar novas tarefas definidas
pelos coordenadores no Posto de Trabalho).
O serviço executa repetidamente o fluxo de informação apresentado no fluxograma, este
repete-se a uma frequência definida aquando a configuração do serviço. Este estabelece
uma comunicação com o servidor e verifica a existência de novas tarefas associadas ao
utilizador, em caso afirmativo, notifica o utilizador apresentando um conjunto de
informações relativas à tarefa (em forma de texto ou num mapa como a rota a percorrer
entre outros) na tela da atividade IntelFleet_tasks, independentemente da atividade que
esta a ser executada (passará para modo de espera) ou da aplicação a ser executada. Por
exemplo, se o utilizador tiver a utilizar a câmara fotográfica do smartphone esta
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
86
aplicação será suspensa e na tela aparece o layout da atividade IntelFleet_tasks
garantindo que este é sempre informado de novas tarefas.
Alertas
O Terminal do Condutor alerta/notifica o utilizador (condutor) além das novas
tarefas, do prazo para realização da tarefa delineado pelo coordenador quando prestes a
terminar ou já expirado. Notifica ainda quando é desrespeitada a rota traçada (definida
pelo coordenador) durante a execução da tarefa, de forma a que este continue a seguir o
melhor caminho é-lhe apresentada uma nova rota que leve em conta os parâmetros
definidos aquando a criação da tarefa pelo coordenador.
A Figura 56 apresenta o ecrã de notificação quando o prazo para realização da tarefa se
aproxima do fim. Esta notificação é realizada a 24 horas do prazo limite e no respetivo
dia ocorre de duas em duas horas, a menos que o utilizador indique que não deseja
voltar a ser alertado até ao final do prazo.
Figura 56 - Notificação ao utilizador de prazo de execução da tarefa a expirar, IntelFleet_warn e
IntelFleet_gps_warn respetivamente.
4.5.5 QRcode Scanner
Como se pode verificar no diagrama entidade-relação (Figura 25), cada condutor
deverá ter zero ou um veículo associado. Numa empresa possuidora de frotas um
condutor pode ter acesso a mais que um veículo, podendo alternar entre veículos a
execução de tarefas. De forma a garantir que a organização tem sempre conhecimento
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
87
de quais os veículos que estão a ser utilizador por cada condutor em tempo real, foi
implementado um sistema de registo de veículos.
Seu princípio é bastante simples, “instalando” QRcode no interior dos veículos que
podem ser convertidos em texto quando lidos pelo scâner da aplicação Terminal do
Condutor. Desta forma é identificado qual o veículo e registada a mudança na base de
dados da organização (através do campo ‘veiculo_matricula’ da tabela “Driver”),
tornando esta informação disponível às restantes aplicações e utilizadores. Este processo
encontra-se descrito no fluxograma da Figura 57.
Figura 57 - Processo de registo de veículos.
Através de um objeto Intent é possível integrar a aplicação Barcode Scanner na
aplicação Terminal do Condutor. Esta é uma forma simples de invocar o barcode e
efetuar o “scanner”, recebendo apenas o resultado final no Terminal do Condutor como
demonstra o exemplo apresentado na Figura 58.
Esta integração consiste essencialmente em invocar o método initiateScan(Activity) e
esperar pelo resultado. Isto requer a instalação da aplicação Barcode Scanner no
smartphone.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
88
Figura 58 - Registo de veículos utilizando o Barcode Scanner.
4.6 Unidade Móvel
O presente subcapítulo procura dar a conhecer o dispositivo de hardware
denominado de Unidade Móvel, mais especificamente os componentes que o
constituem e seu comportamento no âmbito do projeto.
A Figura 59 apresenta um diagrama de blocos que permite identificar os vários
elementos que compõem o dispositivo eletrónico e ainda os protocolos de comunicação
utilizados na interação entre os módulos.
Figura 59 - Visão global da Unidade Móvel sobre a forma de blocos.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
89
4.6.1 Processos de Software
Nesta secção é dada a conhecer os diferentes processos de software executados
no decorrer da execução do dispositivo Unidade Móvel. Desde o processo de
inicialização e configuração de hardware até ao procedimento do dispositivo durante a
execução das suas tarefas.
Processo de Start-Up
O processo de Start-up descreve como um sistema se inicia, isto é, quais os
procedimentos que devem ser realizados de forma a obter um arranque correto.
O fluxograma da Figura 60, descreve este processo que se inicia com a configuração da
comunicação série, posteriormente inicializa os componentes de hardware utilizados
(Receiver GPS e módulo GSM). Caso ocorra algum erro durante estas etapas iniciais o
sistema notifica o utilizador ao ativar o RGB com uma luz azul, indicando o erro no
processo de Start-up. Quando realizado com sucesso este primeiro passo significa que a
unidade central (microcontrolador) se encontra habilitada a comunicar com os módulos
de hardware, com as configurações apresentadas no anexo A.9.2. A partir deste instante
qualquer anomalia identificada durante o funcionamento do sistema será transmitida ao
utilizador Gestor e Condutor por meio de uma mensagem de erro para o Terminal do
Condutor sobre a forma de mensagem de texto (SMS).
Ainda no processo Start-up, o seguinte passo consiste em configurar os timers
necessários para implementação do tempo de amostragem/tempo de atualização, de
forma a permitir uma resposta às solicitações de forma periódica. As restantes etapas
consistem na configuração dos restantes pinos I/O necessários, apresentados no anexo
A.9.3 (por exemplo: bloqueio do veículo) e por fim o sistema procura conhecer se a sua
inicialização ocorre devido a falta de energia, este processo é analisado com maior
detalhe em 4.6.1 (Recuperação de Falhas).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
90
Figura 60 - Processo de Start-up.
Inicialização do Receiver GPS
O módulo GPS escolhido para o projeto da unidade móvel possui entre as
características apresentadas em 3.4.2 (Módulo de Localização) o uso do protocolo
USART como meio de comunicação. Para utilizar este protocolo como meio de troca de
dados com o Receiver foram configurados os pinos e baudrate das portas USART,
seguindo os passos apresentados na Figura 61. Foram realizados alguns cálculos que
justificam o baudrate imposto na comunicação com o Receiver, descritos no anexo
A.9.1.
O firmware presente no receiver GPS inicia o envio contínuo à frequência de 1Hz (uma
vez por segundo) dos dados da localização. Estes dados seguem o padrão NMEA,
enviando as cinco frases (anexo A.1) em cada envio da localização. No âmbito do
sistema IntelFleet, apenas é relevante a informação enviada pela frase GPRMC descrita
com detalhe no A.1, assim na inicialização deste componente torna-se vantajoso
configurá-lo para apenas enviar a frase necessária, utilizando o comando PMTK 314
para o efeito:
PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29<CR><LF>
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
91
Figura 61 - Procedimentos executados durante a inicialização do Receiver GPS.
Os campos iniciais constituintes do comando PMTK 314, correspondem às cinco frases
NMEA, ao atribuir-lhes o valor de zero estarão a ser desabilitadas. Desta forma o
receiver é configurado com todos os campos a zero exepto o campo correspondente à
frase pretendida, passando desde então a enviar apenas a frase selecionada a cada
posição fixa.
Uma vez que a informação output do receiver só é necessária quando os utilizadores
(Condutor e Gestor) a solicitarem e não de forma contínua, por uma questão de
eficiência e poupança de recursos, a comunicação entre a unidade de processamento e o
receiver GPS é ativado apenas quando necessário, ativando e desativando o periférico
USART1. Idealmente, para poupar energia o mais conveniente seria simplesmente
desligar o módulo GPS, contudo iria implicar um maior atraso na resposta aos
utilizadores, pois cada vez que é ligada a alimentação do componente receiver, este
requer algum tempo até se “enquadrar” com os satélites de GPS o que se traduz em
segundos ou mesmo minutos até obter a primeira frase GPRMC. Assim sendo, o recetor
continuará a enviar dados à frequência de 1 Hz, mas a unidade de processamento apenas
irá processar esses dados quando tal se justificar.
Este procedimento gera um inconveniente ilustrado na Figura 62, este ocorre devido à
impossibilidade de controlar em que “posição“ da frase obtida como output nos
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
92
encontraremos no instante em que é habilitada a comunicação. Dependendo do
momento em que esta é ativada, irá existir um atraso no máximo de um segundo até ser
recebida uma nova frase, válida quando recebida por completa.
Figura 62 - Diagrama temporal do processo de recolha de dados GPS.
Inicialização do Módulo GSM
O módulo selecionado para o projeto da unidade móvel suporta comandos AT,
cada um destes comandos desempenha uma função e pode ser precedida de parâmetros
que especificam a configuração pretendida. O fluxograma da Figura 63 demonstra o
processo de inicialização do componente em questão.
Figura 63 - Processo de inicialização do módulo GSM.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
93
Os comandos utilizados no processo de inicialização neste componente encontram-se
descritos na seguinte tabela (Tabela 14), bem como os valores dos parâmetros utilizados
durante a configuração apresentado no fluxograma anterior.
Tabela 14 - Descrição dos comandos AT necessários durante a configuração do modem GSM.
Comando Parâmetros Descrição
AT --- Comando enviado para testar a
comunicação série,
AT+CMEE AT+CMEE=2 Ativa notificação de erros no formato
de texto
AT+CPBS AT+CPBS=”SM” Ativar armazenamento de SMS na
memória do catão
AT+CNMI AT+CNMI=2,1,0,2,1 Ativa receção de SMS
AT+CMGF AT+CMGF=1
0-Modo PDU
1-Modo de texto
AT+CMGD AT+CMGD=”número da SMS”
Permite eliminar as mensagens que
são identificadas por um número de 1
até 10, que é a capacidade de
armazenamento do cartão, 10 SMS
Processo “Verificação de Recuperação a Falhas”
Este processo (Figura 64) é executado durante o processo de Start-up da unidade
móvel, o seu objetivo no âmbito do projeto consiste em identificar se ocorreu alguma
falha na unidade móvel, que tenha obrigado a plataforma física a reiciar o seu
funciomento, como por exemplo uma falha de energia. O seu propósito consiste em
manter as comunicações com o Centro de Controlo, isto é, a comunicação em modo
periódico. Na Figura 67 podemos verificar que quando uma solicitação deste tipo é
recebida, os dados relevantes da mesma são armazenados na memória ROM. Assim
quando ocorrida uma falha e o sistema é iniciado e estas informações mantêm-se
intactas, o que significa que podem ser utilizadas para restabelecer a conexão. É dado
um tempo (2 minutos) para receção de mensagens que foram enviadas enquanto o
sistema se apagou, caso se verifique que foi recebida uma mensagem cancelar a
comunicação periódica, o sistema não voltará a restabelecer a comunicação e elimina os
dados da tarefa da memória.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
94
Figura 64 - Algoritmo percorrido durante o processo de verificação de falhas no dispositivo.
Análise de Eventos
Os eventos no dispositivo são anunciados sobre a forma de interrupções, isto é,
quando ocorre uma interrupção num novo evento é gerada na unidade de
processamento. Os eventos que podemos encontrar são:
Nova mensagem de texto recebida;
Nova frase disponível;
Tempo de amostragem alcançado;
Sinais GPS processados.
No microcontrolador selecionado para o projeto, todas as suas interrupções efetuam call
da mesma função, a partir desta é identificada qual o evento que gerou uma interrupção
e executada a respetiva ISR (rotina de serviço a interrupção). Para detetar qual o evento
ocorrido foi implementado o algoritmo ilustrado na seguinte figura (Figura 65).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
95
Figura 65 - Determinação do evento que gerou interrupção.
Após detetada a proveniência da interrupção através de flags que indicam o estado de
cada dispositivo, é invocada a função que irá processar a informação do evento. Na
Tabela 15 é apresentado por evento a função a ser executada, o componente de
hardware que gerou a interrupção e por fim a tarefa a executar após identificação do
evento ocorrido.
Tabela 15 - Funções de resposta ao evento.
Evento Função Tarefa Componente
Nova mensagem de texto
recebida Parse_GSM
Aquisição de dados
GSM Módem GSM
Nova frase disponível Parse_GPS Tratamento de dados
GPS Reciver GPS
Tempo de amostragem
alcançado Send_count
Atualização periódica
de dados Microcontrolador
Sinais GPS obtidos Fix_detect,
Verify_fix
Habilitação da
aquisição de dados
GPS
Receiver GPS
Aquisição de Dados GSM
Como referido anteriormente, novas mensagens de texto são anunciadas à
unidade de processamento pelo módulo GSM sobre a forma de interrupção gerada pelo
módulo GSM. A função Parse_GSM é a rotina de serviço à interrupção e a sua tarefa é
descodificar a mensagem de texto e de acordo com o comando presente no corpo do
SMS executará uma série de passos ilustrados na Figura 66. Os comandos utlizados na
comunicação com o veículo (listados na -Tabela 17) indicam as seguintes intensões do
utilizador:
Atualização dos dados de localização;
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
96
Bloqueio do veículo;
Desbloqueio do veículo.
Figura 66 - Interpretação de comandos.
A unidade de processamento compara o conteúdo da mensagem de texto com os
diferentes comandos reconhecidos pela Unidade Móvel, quando o conteúdo da
mensagem coincide com um dos formatos dos comandos a unidade irá proceder
consoante intenção do utilizador, identificado através do algoritmo anterior.
Atualização de Dados
A unidade móvel permite o envio das atualizações dos dados de localização em
dois modos:
Atualização periódica;
Atualização “on-demand”.
O primeiro modo é ativado pelo Gestor com objetivo de atualizar a informação do
veículo periodicamente, permitindo acompanhar a execução dos serviços. O modo “on-
demand” desenvolvido a pensar no Condutor, possibilitando requisitar informação da
localização no instante à unidade móvel e visualizar a posição do veículo em qualquer
instante num mapa. Na -Tabela 17 verifica-se que o formato do comando para os
diferentes modos de atualização de dados é o mesmo, desta forma é necessário antes de
responder à solicitação de informação verificar qual o modo de atualização solicitado,
como demonstra o algoritmo da Figura 67 implementado na função Timer_config.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
97
Figura 67 - Identificação do modo de atualização de dados solicitado.
Quando uma nova mensagem de texto é recebida uma interrupção é gerada, a flag da
comunicação série (USART 1) permite à unidade de processamento identificar qual o
evento/interrupção ocorrido invocando a respetiva ISR (Parse_GSM). Esta função tem
como propósito verificar qual o comando transmitido pelo utilizador à unidade móvel. É
percorrido o algoritmo da Figura 65 até ser identificada a intenção do utilizador. No
presente caso de estudo o comando recebido irá possuir o seguinte formato: *txxxx+,
anunciando que o utilizador solicitou atualização da localização. Próximo passo é
preparar a resposta à solicitação invocando a função Timer_config responsável por essa
tarefa.
O algoritmo implementado nesta função inicia-se com a averiguação do tipo de
atualização, identificando-o através do parâmetro incluído no comando, quando este
possui um valor superior a zero significa que se trata do modo periódico. Nesta situação
a unidade de processamento procede com a inicialização das variáveis que armazenarão
valores como o número do dispositivo que requisitou o pedido de atualização e ainda o
tempo de amostragem necessário para o correto envio da resposta à solicitação.
O passo seguinte configura o timer (Timer 0) como temporizador, após transcorrer os
ciclos correspondentes ao tempo de amostragem, ocorre o overflow na contagem do
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
98
timer sendo colocado a ’1’ por hardware a timer overflow flag, gerando a interrupção
que invocará a função ‘send_count’ responsável por verificar se todos os parâmetros
solicitados encontram-se atualizados, para o seu envio ao utilizador sobre a forma de
mensagem de texto. Enquanto este cenário não ocorrer, o sistema deverá aguardar que
os parâmetros sejam atualizados, visto que o sistema utiliza uma programação que
recorre a interrupções e não por polling, a aquisição de dados GPS solicitados é
executada em “paralelo”. O que indica que a qualquer instante estes parâmetros
encontram-se atualizados e prontos a serem enviados ao utilizador que os requisitou,
após o envio é reiniciada a temporização e habilitada a interrupção do timer.
Aquisição dos Parâmetros GPS Solicitados
Como descrito na secção 4.6.1 (Inicialização do Receiver GPS) a comunicação
entre a unidade de processamento e o receiver é ativada quando necessário, isto é,
quando o utilizador solicita a informação output do receiver. Devido ao inconveniente
que esta abordagem gera, é necessário controlar os caracteres recebidos percorrendo o
algoritmo ilustrado na Figura 68 desenvolvido para o efeito, a sua tarefa consiste em
garantir que uma frase foi obtida na totalidade.
Figura 68 - Algoritmo de extração dos parâmetros GPS solicitados.
O processo de aquisição dos parâmetros GPS é representado pelo algoritmo da figura
anterior, a cada posição fixa o receiver inicia a transmissão dos carateres que
completam a frase. A sequência de entrada de carateres será analisada por um analisador
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
99
léxico, que determinará se a estrutura gramatical até então respeita a gramática formal
da frase GPRMC, contando também o número de carateres até então recebidos. Se a
frase não respeitar a gramática formal da frase pretendida significa que esta não foi
recebida na totalidade, assim será necessário esperar por uma nova posição fixa
realizando o mesmo processo aplicado à frase incompleta recebida. Esta estratégia
garante que uma frase inteira é recebida ininterruptamente possibilitando a extração dos
desejados parâmetros (velocidade, coordenadas geográficas e tempo) e desabilitará
comunicação quando realizado com sucesso.
Análise Sintática
Ao impor que a sequência de carateres percorra o algoritmo da Figura 69,
garante-se que a unidade de processamento é capaz de identificar quando uma
mensagem foi recebida na totalidade.
Figura 69 - Algoritmo implementado na função Parse_GPS.
A variável State inicializada com o valor zero, é utilizada como meio de identificar se o
carater lido pertence a uma frase incompleta (que será descartada), ou a uma frase
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
100
completa que será analisada. Quando o carater “$” é recebido, é alterado o valor da
variável State indicando que foi detetado o primeiro carater de uma frase GPRMC. A
partir deste momento, todos os carateres recebidos até ao instante em que é recebido
como output do receiver o carater terminador “/r” são armazenados numa string.
Quando recebido, é confirmada a validade da frase recebida através do checksum, este é
extraído da frase e calculado um novo checksum da frase recebida, quando os valores
coincidem é realizada a “extração” dos valores dos campos relevantes que
correspondem aos parâmetros solicitados. Caso o checksum calculado seja diferente do
obtido, o número de carateres é colocado a zero de forma a garantir que o processo de
aquisição dos parâmetros solicitados é reiniciado até garantir uma frase válida.
Envio dos Parâmetros (Atualizações Geográficas)
Após verificar que todos os parâmetros foram obtidos é tempo de os enviar via
GSM, este procedimento é realizado percorrendo o algoritmo da Figura 70
implementado na função Send_position.
Figura 70 - Processo de envio dos parâmetros solicitados.
Durante a realização dos passos que constituem o algoritmo, foram utilizados os vários
comandos AT descritos na Tabela 16.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
101
Tabela 16 - Comandos AT usados durante o processo de envio dos parâmetros.
Comando Valor Descrição
Verificar qual o modo de
SMS AT+CMGF?
Indica se encontra em modo de texto
(1) ou modo PDU(0)
Criar mensagem de texto AT+CMGS=”numero de telefone” Criar mensagem de texto
Inserir parâmetros ao corpo
do texto <Time of fix:…. Criação do corpo da mensagem
Enviar mensagem <Time of fix:….<CRTL-Z> Enviar mensagem de texto
Processo “Bloqueio do veículo”
Este evento ocorre quando recebida uma mensagem de texto identifica a
intenção do utilizador bloquear o veículo através dos processos ‘Análise de eventos’ e
‘Aquisição de dados GSM’. Quando tal se confirma é invocada a função Act_security
que executará o algoritmo da Figura 71.
Figura 71 - Fluxo de informação durante o bloquei do veículo.
A implementação de uma técnica de bloqueio do veículo requer algumas medidas de
segurança, que garantam a integridade do veículo e do condutor.
Desta forma foi implementada a seguinte estratégia, após ordem de bloqueio é
executado o processo ‘Aquisição de parâmetros GPS solicitados’ analisado na secção
4.6.1, este avalia se a velocidade nesse mesmo instante é inferior a 20kms/h, caso tal
cenário seja verificado irá se prosseguir até à etapa de corte da corrente na bomba de
combustível, processo descrito em 3.4.2. Esta estratégia não coloca em perigo a
integridade do condutor e do veículo aquando o seu bloqueio
Obtenção de Sinais GPS
O receiver GPS após inicializado não se encontra automaticamente preparado
para o envio da frase com os parâmetros de interesse. Este necessita de captar os sinais
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
102
de quatro satélites para assim determinar as suas próprias coordenadas, o tempo e outras
variáveis. Quando o receiver se “enquadra” com os satélites, ele altera o valor do pino
fix para “1”, o que indicar à unidade de processamento que o receiver se encontra
preparado para transmitir informações GPS, possibilitando desde então da realização da
tarefa ‘Aquisição dos parâmetros GPS solicitados’. Para efetuar esta operação recorre-se
a dois tipos de interrupções, sendo elas: temporizador timer 1 e ainda uma interrupção
externa, ativada quando ocorre uma transição de um para zero ou o oposto. Quando uma
transição ocorre a interrupção é gerada e invocada a função Verifiy_fix(), esta inicia a
temporização do Timer 1, após executada a ISR é iniciada novamente a temporização
como demonstrado no fluxograma da Figura 72.
Figura 72 - Instruções da função Verify_fix.
É esperado que a flag do timer 1 seja colocada por hardware a “1”, o que neste contexto
significa que o fix continua com o valor de “1” sem sofrer qualquer alteração durante 30
overflows do timer, significa que o receiver está pronto a transmitir os dados GPS
recolhidos, este processo é realizado pela função ‘Fix_detect’ ilustrado na Figura 73.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
103
Figura 73 - Fluxograma da função ‘Fix_detect’.
4.6.2 Comunicação com a Unidade Móvel
A unidade móvel composta pelo módulo SMS e o receiver GPS envia mensagens
de texto das atualizações de localização num intervalo de tempo pré-configurado ou
quando certos eventos ocorrem para o número SIM que realizou o pedido de update. Os
componentes que realizam trocas de informação direta com a unidade móvel no sistema
IntelFleet são os elementos Centro de Controlo e Terminal do Condutor da arquitetura
ilustrada na Figura 24, esta troca de informação é realizada via mensagens de texto
GSM.
Comandos Recebidos
As mensagens de texto são enviadas à unidade móvel principalmente com o
objetivo de alterar a frequência das atualizações ou em circunstâncias que se deseja o
envio imediato das atualizações, poem ser ainda utilizadas como meio de indicar o
bloqueio do veículo. As mensagens de texto são enviadas com o consentimento
explícito do utilizador e o consequente estado da resposta dada a conhecer ao utilizador.
A unidade móvel envia os dados da localização quando recebe comandos solicitando-os,
contudo pode também ser configurado para funcionar no modo periódico, onde é
enviada informação a cada intervalo de tempo, sendo que o mínimo intervalo entre
atualizações é sessenta segundos e o máximo são três horas.
A unidade pode também funcionar no modo ‘on-demand’, efetuando o update de
informação após a solicitação do mesmo, ação realizada apenas uma vez até novas
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
104
ordens. A unidade móvel pode funcionar em simultâneo nos dois modos, como exemplo
é apresentada a seguinte situação: utilizador/Gestor ativa o tracking ao veículo em
questão, seguindo o seu trajeto a partir das atualizações periódicas da sua localização e
ao mesmo tempo o utilizador condutor pode solicitar a posição à unidade recebendo
apenas a localização do veículo nesse mesmo instante, enquanto os dados de localização
continuarão a ser enviados ao Centro de Controlo até que o gestor indique o contrário.
A -Tabela 17 lista os comandos e respetivos formatos adotados na transmissão das
solicitações/intenções dos utilizadores à Unidade Móvel.
-Tabela 17 - Formato das mensagens reconhecidas pela Unidade Móvel
Mensagem Formato Origem Exemplo
Bloqueio do veículo *block+ A.Android/Centro de
Controlo ---
Desbloqueio do
veículo *ubloc+ Centro de Controlo ---
Modo periódico *txxxx+ Centro de Controlo *t0060+
Desabilitar modo
periódico *tstop+ Centro de Controlo ---
A mensagem com o texto: “*t0060+”, indica à unidade móvel que a transmissão de
dados ao Centro de Controlo de forma periódica com um tempo de amostragem de 60
segundos deve ser iniciada. Quando enviado comando “*block+” é executa a operação
de bloqueio do veículo na unidade móvel, após isto é enviada a atualização da
localização com o mesmo formato e informação das restantes solicitações de
atualização de dados.
Formato da Resposta às Solicitações de Atualização da Localização
As mensagens provenientes da unidade móvel contêm informação de localização
GPS, velocidade e tempo, codificadas em uma modificação do formato NMEA RMC.
Esta sentença NMEA é iniciada com um sinal de dólar ($) e contém uma série de
campos separados por vírgulas. Cada campo é importante para determinar a localização,
a velocidade e a direção do veículo num determinado ponto no tempo. Através destes
campos é construída a sentença a enviar aos elementos que solicitam a atualização da
localização, um exemplo da mensagem poderia ser:
Time of fix:232943Lat:4126.8775NLong:00818.4419WSpeed:34.02;
A Tabela 18 descreve os diferentes campos que compões a mensagem “Time of fix”.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
105
Tabela 18 – Parâmetros da mensagem da unidade móvel como resposta às solicitações de atualização de dados.
Campo Descrição Exemplo Interpretação
Time of fix Seis dígitos que indicam o tempo da atualização 232943 23:29:43 UTC
Lat Valor da latitude em graus 4126.8775 41º26’ 8775’’
Direção da
latitude
Direção da latitude pode ser N ou S (Norte ou
Sul) N Norte
Long Valor da Longitude em graus 00818.4419 8º18’4419’’
Direção da
Longitude
Direção da longitude pode ser E ou W (Este ou
Oeste) W Oeste
Speed Velocidade em nós 34.02 34.02 nós, 63
kms/h
Após recebida a sentença anterior pelo Centro de Controlo é necessário realizar cálculos
(abordados no anexo A.1) que permitam alterar dos dados da sentença NMEA para
valores (coordenadas geográficas) reconhecidas pelos métodos da API do Google Maps.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
106
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
107
5. Testes e Resultados Obtidos
No presente capítulo é analisado os resultados obtidos na utilização desta
ferramenta num cenário que permita avaliar a viabilidade da mesma. Existe a
preocupação de tornar o mais real possível o teste à ferramenta em questão, assim sendo
é instalado o dispositivo no veículo e testadas as funcionalidades das várias aplicações
que a compõem.
Antes disso, são apresentados alguns testes realizados ao dispositivo de hardware
Unidade Móvel. Estes provam as capacidades do dispositivo, anunciadas durante a sua
descrição e implementação, comprovando a veracidade dos dados recebidos nas
diversas aplicações da ferramenta durante o teste de todo o sistema.
5.1 Unidade Móvel
O dispositivo é constituído por vários módulos, assim a melhor forma de testar o
hardware é partir de testes individuais (Tabela 19). Quando estes respondem ao
solicitado, faz sentido testar a integração dos diferentes componentes. Este processo
permite detetar e isolar os erros rapidamente.
Após os testes serem realizados com sucesso, é tempo de iniciar a integração dos
diferentes módulos. De seguida são apresentados os resultados de alguns dos testes
descritos na Tabela 19.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
108
Tabela 19 - Casos de teste utilizados para prevenir erros no produto final.
Módulo Input Resposta Esperada Descrição do teste
PTN78060W 12V 5V
Colocar 12V na entrada do
conversor CC-CC e verificar saída
de 5V.
Receiver GPS --- Frases NMEA
Alimentar Receiver, ligar pinos
RX e TX, configurar comunicação
série e aguardar pelas 5 frases
NMEA como resposta.
Receiver GPS
+PTN78060W ---
Strings descritas pelo
protocolo NMEA
Alimentar Receiver a partir da
saída do conversor CC-CC
alimentado com um valor entre
12-30V, iniciar Receiver e esperar
pela frase NMEA.
Regulador de
tensão
5V 3.3V Impor 5V na entrada do regulador
e verificar valor da saída.
Regulador de
tensão
+PTN7860W
12V
3.3V
Colocar 12V à entrada do
conversor CC-CC e ligar
retificador de tensão À sua saída,
verificar tensão de 3.3V à saída do
regulador.
Módulo GSM “AT” “OK”
Ligar pinos de alimentação, ligar
RX e TX, configurar a ligação da
porta série, enviar string “AT” e
aguardar como resposta “OK”.
Módulo GSM +
PTN78060W
"AT"
"OK"
Ligar os pinos de alimentação à
saída do conversor CC-CC,
configurar a ligação da porta série,
enviar string de input e verificar
resposta.
Microcontrolador
---
Ligar LED
Programar o µc, com um
programa de acender um LED,
alimentar o µc através do
regulador de tensão e verificar se
o LED acende.
TIMER --- Piscar LED
Programar µc para fazer toggle ao
estado de um pino aquando o
timer finaliza a contagem,
alimentar o µc e verificar se o
LED pisca no tempo certo.
USART “Teste” “Teste”
Após programar o µc com um
programa que envia strings pela
porta série, alimentar o µc, ligar o
RX e TX e verificar, através de
um terminal, se é enviado pela
porta série a string de input.
Módulo GPS
Como referido anteriormente, o receiver GPS após alimentado começa o
processo de aquisição de sinais, este consiste no envio contínuo das diversas frases
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
109
NMEA. De forma a testar a comunicação série com o receiver, é configurada a porta
série com os parâmetros referidos em 4.6.1 e iniciada a comunicação. Através de várias
experienciais, verifica-se que o receiver demora em média 90 segundos até colocar o fix
a “1”, a partir deste instante são transmitidas as diferentes frases como demonstra o
resultado a um teste realizado (Figura 74).
Figura 74 - Frases NMEA transmitidas pelo receiver.
Microcontrolador na Aquisição dos Dados GPS.
O teste de aquisição de dados GPS, baseia-se nos seguintes passos: ligar o
módulo GPS à USART2 do µc e o Arduíno à USART1 como interface com o PC.
O µc foi previamente programado, com uma versão do programa que inclui o envio dos
resultados para a USART1, permitindo a visualização dos acontecimentos num PC. Com
este teste, procura-se validar as funções de envio e receção de dados via porta série, o
detetor de sinal do fix e a função de parsing do GPS. Os resultados obtidos encontram-
se ilustrados na Figura 75.
Figura 75 - Frase NMEA recebida, proveniente do output do Receiver e variáveis de interesse extraídas do
output.
A partir do resultado obtido, verifica-se que do output do receiver é obtida apenas a
mensagem GPRMC, o que significa que o este foi configurado apenas para transmitir
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
110
uma única frase NMEA como desejado. O parsing desenvolvido reconhece e aprova as
frases recebidas através do cálculo do checksum, por fim são extraídas as informações
desejadas.
Integração dos Diversos Módulos
A montagem final da Unidade Móvel (Figura 119) é testada do seguinte modo:
microcontrolador programado para enviar a uma frequência de 30 segundos a frase
GPRMC, sobre a forma de uma mensagem de texto para um dado número SIM; a
energia de alimentação deste é obtida da fonte de energia do veículo (bateria). O
dispositivo é colocado sem se deslocar na seguinte posição: 41.415899, -8.4387700
(confirmado pelos mapas da Google), desta forma espera-se que os resultados traduzam
isso mesmo, ou seja, velocidade igual a zero e coordenadas geográficas fixas ao longo
do tempo. Os resultados do teste são apresentados na Tabela 20.
Tabela 20 - Resultados do teste as atualizações periódicas.
Frase recebida Velocidade Latitude Longitude Tempo
Time of fix:134710
Lat: 4124.9555N
Long:00826.3287W
Speed:0.34
0.34 nós/
0.63Kms/h
41º 24.9555’/
41.415925
-008º 26.3287’/
-8.438811666 13:47:10
Time of fix:134741
Lat: 4124.9567N
Long:00826.3287W
Speed:0.42
0.42 nós/
0.77Kms/h
41º 24.9567’/
41.415945
-008º 26.3287’/
-8.438811666 13:47:41
Time of
fix:134815Lat:
4124.9572N
Long:00826.3277W
Speed:0.41
0.41 nós/
0.76Kms/h
41º 24.9572’/
41.415933
-008º 26.3277’/
-8.4387195 13:48:15
Time of fix:134849
Lat: 4124.9579N
Long:00826.3290W
Speed:0.03
0.03 nós/
0.06Kms/h
41º 24.9579’/
41.415965
-008º 26.3290’/
-8.4388166 13:48:49
Os resultados são bastantes satisfatórios, pois demonstram que a aquisição de dados é
bastante viável, obtendo valores bastantes próximos dos esperados. As coordenadas
obtidas, apesar de não corresponderem à verdadeira posição do veículo, apresentam um
erro nunca superior a três, quatros metros como nos demonstra a Figura 76.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
111
Figura 76 - Ponto geográficos obtidos durante o teste da aquisição de dados do dispositivo móvel numa posição
fixa (ponto A).
A variável velocidade adquirida encontra-se muito próxima do valor esperado em todas
as aquisições obtidas, tendo a aproximar-se do valor esperado ao longo do tempo. Isto
significa que no processo de bloqueio do veículo são respeitadas as normas de
segurança, ou seja, a imobilização do veículo irá ocorrer apenas quando sua velocidade
é inferior a 20 km/h.
Os seguintes links, são vídeos que resultam de testes realizados à unidade em
movimento e ainda ao sistema de bloqueio do veículo.
http://www.youtube.com/watch?v=u7OXtzgbZiI;
http://www.youtube.com/watch?v=mwGRSW_XPos;
http://www.youtube.com/watch?v=mSxSS4_Dx_U;
5.2 Centro de Controlo
Para a realização do teste que põe à prova a integração dos diversos
componentes que compõem a ferramenta, a plataforma física foi colocada em
movimento e uma tarefa (Figura 85) foi delineada ao condutor.
Foi parada a execução do background service iniciado aquando ligado o PC. A seguinte
figura demonstra que a aplicação foi capaz de identificar que este não se encontra ainda
em execução.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
112
Figura 77 - Resultado ao teste de verificação do serviço.
O resultado dessa verificação encontra-se ilustrado na Figura 78.
Figura 78 - Verificação do estado do background service.
Como era de esperar o serviço possui como “Status” o valor false, assim foi forçado o
início do serviço, o resultado desta operação encontra-se ilustrado na Figura 79.
Figura 79 - Resultado obtido após forçar o início do serviço.
Como nos comprova o gestor de serviços do Windows (Figura 80), já se encontra a
correr o serviço (Service1).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
113
Figura 80 - Gestor de serviço do Windows.
O próximo passo do teste visa a introdução dos recursos humanos e físicos necessários,
tais como cliente, condutor e veículo. Estes são os elementos ativos durante a realização
da tarefa.
Figura 81 - Dados dos condutores registados na base de dados
A partir desse instante espera-se obter as atualizações periódicas na aplicação
Centro de Controlo que traduzem o trajeto percorrido durante a realização da tarefa.
A Figura 82 reflete o processo de inserção de um cliente, mais especificamente a
indicação da sua localização.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
114
Figura 82 - Inserção de um cliente na base de dados.
As atualizações da localização da unidade obtidas durante a realização da tarefa/teste já
mencionado encontram-se na Tabela 21.
Tabela 21- Dados GPS adquiridos durante a realização da tarefa.
ID do ponto Velocidade
(km/h) Latitude Longitude Tempo
1 0.9 41.416076 -8.439263 19:16:15
2 35 41.417540 -8.441370 19:17:17
3 02 41.419750 -8.444101 19:18:19
4 38 41.417292 -8.450271 19:19:23
5 52 41.414508 -8.459022 19:20:26
6 32 41.413840 -8.466103 19:21:27
7 70 41415247 -8.471639 19:22:29
8 75 41.420879 -8.487171 19:23:31
9 40 41.415390 -8.502962 19:24:33
10 52 41.412930 -8.508671 19:25:35
11 55 41.078969 -8.513846 19:26:33
12 60 41.413701 -8.518674 19:27:34
13 0.6 41.415215 -8.520262 19:28:36
A Figura 83 apresenta a messagebox utilizada como meio de notificar o utilizador de
uma nova atualização.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
115
Figura 83 -Notificação da atualização de dados.
5.3 Posto de Trabalho
Como demonstra a Figura 84, os dados introduzidos que dizem respeito ao
condutor utilizado no presente caso de teste, já se encontra registado na base de dados
remota.
Figura 84 - Detalhes do condutor com o id=1;
Como já referido, foi criada uma tarefa com os parâmetros ilustrados Figura 85.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
116
Figura 85 -Parâmetros que caraterizam uma tarefa.
Antes da realização da tarefa, quando consultada a localização atual do veículo é
apresentado o seguinte conteúdo ao utilizador coordenador (Figura 86)
Figura 86 - Informações do veículo, antes do condutor ter conhecimento da nova tarefa.
Após criado, espera-se que este seja apresentado como um serviço pendente. Realizando
uma consulta aos serviços pendentes, obteve-se o seguinte resultado (Figura 87 e Figura
88).
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
117
Figura 87 - Tabela com os serviços que se encontram por realizar.
Como esperado, o serviço anteriormente criado já se encontra “visível” a toda a
organização, assim o condutor será notificado da nova tarefa e a aquisição das
atualizações de forma periódica estabelecida e iniciada.
Figura 88 - Rota definida para a tarefa pelo coordenador.
À medida que o Centro de Controlo recebe as coordenadas geográficas referentes à
posição do veículo é atualizada a base de dados como nos comprova a Figura 89.
Figura 89 - Registos dos pontos na base de dados.
Quando consultado o trajeto percorrido pelo veículo até então, é obtido o resultado
apresentado na Figura 90.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
118
Figura 90 - Aspeto da imagem após consulta do trajeto percorrido pelo veículo.
Neste instante foi testado o processo de validação de rotas, ao clicar no controlo “Rota”
é obtido o resultado presente na Figura 91. No presente caso, o veículo não possui
nenhum step dentro de um raio de um km, contudo encontra-se no trajeto entre steps o
que significa que o trajeto coincide com o delineado pelo coordenador.
Figura 91 - Teste do processo responsável por detetar trajetórias indesejáveis.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
119
5.4 Terminal do Condutor
Na presente secção, são apresentados os resultados obtidos na realização dos
testes às diferentes funcionalidades da aplicação Terminal do Condutor durante a
simulação.
Login
A resposta esperada do servidor (ficheiro XML) após requisição assíncrona deve
conter os dados dos vários condutores registados na base de dados (dois utilizadores
para o presente teste). O resultado obtido encontra-se ilustrado na Figura 92.
Figura 92- Conteúdo do ficheiro XML obtido no teste ao processo de autenticação
As credenciais introduzidas são comparadas com os dados do resultado anterior, quando
o processo é realizado com sucesso é iniciado o background service. A Figura 92 ilustra
a sequência de telas desde a autenticação até ao menu da aplicação, neste último passo é
colocado a correr o serviço como já referido.
Figura 93 - Tela durante processo de login e tela seguinte (Menu da aplicação, notifica utilizador
quando iniciado o background service).
O gestor de aplicações do smartphone utilizado no teste do software desenvolvido,
apresenta dados sobre as diversas aplicações que se encontram a ser executadas, entre
eles podemos identificar o Terminal do Condutor. Assim sendo, a Figura 94 confirma
que o serviço já se encontra a executar como esperado.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
120
Figura 94 - Gestor de aplicações apresenta detalhes da aplicação, espaço ocupado, tempo de execução e
componentes a correrem (serviço).
Envio de mensagens de texto
Consiste no envio de uma mensagem de texto à Unidade Móvel instalada no
veículo associado ao condutor. A Figura 95 apresenta os valores utilizados para o envio
da mensagem. O número do localizador como podemos verificar coincide com o
registado anteriormente na base de dados, o mesmo acontece com o corpo da
mensagem, pois corresponde ao comando “on-demand”.
Figura 95 - Parâmetros enviados durante requisição de atualização “on-demand”, número do localizador e
texto da mensagem.
A Figura 96 apresenta o conjunto de telas visíveis ao condutor durante este processo.
Figura 96 - Telas durante o pedido de atualização da localização
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
121
O utilizador deve ser notificado do estado de envio da mensagem de texto, a Figura 97 e
a Figura 98 ilustram o estado do envio da mensagem de texto no teste efetuado. Em
modo debug e partir de breakpoints verificou-se que foi enviada e recebida pelo
destinatário.
Figura 97 - Estado da mensagem, enviada com sucesso.
Figura 98 - Estado da mensagem, recebida pela unidade móvel.
Registo de veículos
De forma a testar esta funcionalidade, foi criado um QRcode com o texto do
veículo com a matrícula “78-12-DN”, ilustrado na Figura 99.
Figura 99 - QRcode gerado a partir do texto "728-12-DN".
O texto retornado como resultado da aplicação Barcode Scanner coincide com o texto
do QRcode, como comprova a Figura 100.
Figura 100 - Texto após o scanner ter sido realizado.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
122
A função postData_vehicle (Figura 101) realiza os passos necessários à alteração do
campo ‘veiculo_matricula’ da tabela “Driver”. Como o veículo apenas se pode
encontrar associado a um só condutor, significa que apenas pode estar numa linha da
tabela. Assim espera-se que o condutor anteriormente referenciado deixe de o estar, e o
condutor com o “ID”=1 tenha o novo veículo associado.
Figura 101 - Resultado positiva após o processo de registo de veículos, alterados com sucesso os campos
necessários que traduzem a mudança de veículo à organização.
O resultado apresentado na Figura 102 demonstra que foram realizadas com sucesso as
alterações esperadas na tabela “Driver”.
Figura 102 - Tabela “Driver” após alterações dos campos influenciados por esta mudança levada a cabo
durante o teste.
Receção de Atualizações
Após o envio do comando “on-demand” para a unidade móvel, espera-se por uma
resposta sobre a forma de mensagem de texto com as informações desejadas. A receção,
processamento e apresentação dos dados da localização é responsabilidade do módulo
Broadcast Receiver. A Figura 103 apresenta o conteúdo da mensagem recebida, apenas
as coordenadas geográficas interessam ao condutor, assim são extraídas e utilizadas para
realizar o reverse geocoding.
Figura 103 - Identificação do conteúdo da mensagem de texto proveniente da unidade móvel.
Através das coordenadas obtidas e após realizado o reverse geocoding foi obtido o
resultado ilustrado Figura 104.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
123
Figura 104 - Localização correspondente as coordenadas transmitidas pela unidade móvel.
As telas que informam o utilizador durante o teste são visíveis na Figura 105.
Figura 105 - Resultado da atualização “on-demand”.
Serviço Executado em Background
Quando criada uma nova tarefa para o condutor com o “ID”=1, é esperado que
este seja notificado. A Figura 106 apresenta os dados da tarefa introduzidos no ficheiro
XML como resposta à requisição levada a cabo pelo background service.
Figura 106 - Ficheiro XML, contêm os dados relativos à tarefa criada ao longo do teste.
A Figura 107 apresenta a sequência de telas que resulta do processo de identificação de
novas tarefas, levada a cabo pela aplicação Android durante o teste.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
124
Figura 107 - Resultado do processo de "escuta" de novas tarefas durante o teste realizado.
O vídeo do link apresentado em baixo, demonstra o comportamento da aplicação
Terminal do Condutor e descreve as funcionalidades oferecidas pelo mesmo.
http://www.youtube.com/watch?v=3jruigxd2HE&feature=youtu.be;
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
125
6. Conclusão e Trabalho Futuro
Neste capítulo são descritas as conclusões retiradas da solução implementada,
incluindo ainda as indicações de trabalho futuro que proporcionará melhorias
significativas na ferramenta IntelFleet.
6.1 Conclusões
A presente dissertação teve como objetivo a realização de um sistema de
localização e gestão de frota com uma componente de controlo do veículo, utilizando
tecnologias de GPS e GSM.
Durante o projeto foi realizado o levantamento das tecnologias com utilização relevante
para o sistema e uma comparação de vários produtos já existentes no mercado.
Foi levado em conta as necessidades das empresas possuidoras de frotas, procurando
satisfazer as necessidades dos mesmos a partir da ferramenta, desta forma foi estudado o
melhor meio de conciliar as tecnologias e requisitos das empresas. Além disso, foi
sempre tido em conta a inclusão de uma componente inovadora face aos produtos
analisados existentes.
Do desenvolvimento deste projeto resulta uma solução que vai de encontro aos
objetivos inicialmente propostos. Foi criada uma plataforma física, convenientemente
testada, que suporta comunicação GSM, obtenção de coordenadas GPS, e
armazenamento da informação dos pedidos recebidos (requisições de atualizações
periódicas) do Centro de Controlo durante a sua utilização, isto permite estabelecer
comunicações após falhas no dispositivo que obrigam a plataforma a reiniciar. Os dados
GPS são transmitidos à aplicação Centro de Controlo, este tem a tarefa de tratar os
dados e atualizar o servidor com esta informação, passando a estar disponível para
consulta via Web, bastando aceder ao site desenvolvido para o efeito. Esta aplicação,
designada de Posto de Trabalho apresenta ao utilizador informações sempre atualizadas
para o planeamento de novas tarefas. Verificou-se a partir de vários testes realizados,
que o algoritmo responsável por detetar possíveis trajetos que não estejam a respeitar,
em tempo real a rota definida ante mão é funcional e bastante viável quando aplicado
em ambientes urbanos, onde se espera que exista um maior número de steps.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
126
Dos testes realizados à integração dos vários componentes da ferramenta, obteve-se
resultados satisfatórios, com os dados GPS a estarem próximos do valor real. A partir
destes verifica-se que ao nível da segurança, o sistema respeita as normas impostas, isto
é, o veículo só é imobilizado pela plataforma física quando possui velocidades
inferiores a 20 km/h. As coordenadas enviadas ao condutor após a imobilização do
veículo são viáveis e permitem a sua localização e posterior aquisição corretamente. Ao
nível do Terminal do Condutor, verificou-se pela análise dos testes efetuados que as
funcionalidades concebidas ao condutor são realizadas com sucesso, desde a
comunicação com a unidade móvel ao registo de veículos onde são realizadas ações que
visam manter a integração da base de dados remota através de triggers.
Do ponto de vista do projeto, os objetivos foram cumpridos com sucesso, o sistema é
funcional. Enquanto produto, não se encontra preparado para ser comercializado, pois a
plataforma física requer alguns melhoramentos pois trata-se de um protótipo. Às
aplicações que suportam as tarefas dos vários utilizadores podem novas funcionalidades
serem acrescentadas que automatizem mais a ferramenta IntelFleet.
6.2 Trabalho Futuro
Os trabalhos futuros a curto prazo, prendem-se essencialmente na monitorização
de um maior número de variáveis, isto poderá ser útil dependendo dos tipos de produtos
transportados, por exemplo, no transporte de produtos que requerem determinadas
temperaturas é importante ter conhecimento das mesmas em tempo real. Uma possível
solução que pode ser estudada e implementada seria a incorporação da Unidade Móvel
numa rede sem fios composta por vários sensores (sensor de humidade, de temperatura
entre outros) que permita aquisição destas variáveis para posterior transmissão ao
Centro de Controlo.
A aplicação Terminal do Condutor pode sofrer um acréscimo de funcionalidades a fim
de automatizar o sistema IntelFleet. A realização de encomendas não abordada durante
a implementação da solução poderá ser uma das novas funcionalidades desta aplicação,
automatizando ainda mais a ferramenta IntelFleet.
Uma alteração mais profunda identificada como trabalho futuro, consiste na substituição
do meio de comunicação GSM pelo GPRS, tal implicaria mudanças ao nível do
hardware (Unidade Móvel) e caso se deseje ao nível do software. A utilização deste
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
127
meio de comunicação excluía a necessidade de utilização do modem GSM no Centro de
Controlo (menor custos). A partir deste instante as atualizações de localizações dos
veículos passariam a ser realizadas exclusivamente via Socket TCP/IP.
Ao nível da segurança são reconhecidas algumas melhorias, nomeadamente a
incorporação de um botão de alarme que permita alertar a organização do furto ocorrido
e a utilização de uma pequena bateria para alimentação de todo dispositivo (Unidade
Móvel). Este último passo permite continuar o tracking do veículo mesmo depois de
este ser desmantelado (retirada bateria do veículo) e evita a sua instalação (pode ser
colocado mais próximo dos produtos) e consequente alteração da originalidade do
veículo. Outra possível implementação ao nível da segurança, consiste na incorporação
do serviço Voip, podendo ser utilizado como meio de comunicação com o condutor ou
como meio de escutar o veículo e mais concretamente os indivíduos que conduzem o
veículo após furtados, sendo o serviço Voip ativado remotamente.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
128
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
129
Bibliografia
[1] M. A. A.-K. S. M. I. Montaser N. Ramadan, “Intelligent Anti-Theft and Tracking
System for,” International Journal of Machine Learning and Computing, vol. 2, 2012.
[2] P. P. W. a. P. S. D. G. T.-A. A.-t. System, “Real Time Vehicle Locking and Tracking
System using GSM and GPS Technology-An Anti-theft System,” International Journal
of Technology And Engineering System(IJTES), vol. Vol.2, 2011.
[3] S. Manoharan, “On GPS Tracking of Mobile Devices,” em Fifth International
Conference on Networking and Services, New Zealand, 2009.
[4] M. A. Al-Khedher, “Hybrid GPS-GSM Localization of Automobile Tracking System,”
International Journal of Computer Science & Information Technology (IJCSIT), vol.
Vol 3, Dec 2011.
[5] “Inteligência empresarial,” [Online]. Available:
http://pt.wikipedia.org/wiki/Intelig%C3%AAncia_empresarial. [Acedido em 12
Dezembro 2001].
[6] S. Thong, C. Tien e T. Rahman, “Intelligent Fleet Management System with Concurrent
GPS & GSM Real-Time Positioning Technology,,” Telecommunications, vol. ., n.º .,
pp. 1-6, 6-8, Junho 2007.
[7] H. L. E. W. Bernhard Hofmann-Wellenhof, GNSS - Global Navigation Satellite
Systems: GPS, GLONASS, Galileo, and more, SpringerWienNewYork, 2008.
[8] H. O. Y. W. M. M. L.-S. P. a. D. R. Philo Juang, “Energy-Efficient Computing for
Wildlife Tracking: Design Tradeoffs and Early Experiences with ZebraNet,” em
Conference on Architectural Suport for Programming Languages and Operating
Systems, San Jose, CA, October 2002.
[9] “NMEA data,” [Online]. Available: http://www.gpsinformation.org/dale/nmea.htm.
[Acedido em 21 Dezembro 2011].
[10] “The GSM Standart,” [Online]. Available:
http://www.gsmserver.com/articles/gsm_overview.php. [Acedido em 28 Dezembro
2011].
[11] “Tecmic,” [Online]. Available: http://www.tecmic.pt/docs/Tecmic-XTraN_pt.pdf.
[Acedido em 5 Janeiro 2012].
[12] “Tecmic Web,” [Online]. Available: http://www.tecmic.pt/eng/xtran/xtran_web.html.
[Acedido em 5 Janeiro 2012].
[13] “Frotasoft,” [Online]. Available: www.frotasoft.com/. [Acedido em 6 Janeiro 2012].
[14] “Moviloc,” [Online]. Available:
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
130
http://www.gmv.com/pt/Transportes/FrotasEspeciais/Moviloc.html. [Acedido em 6
Janeiro 2012].
[15] “Pt Negocios, Gestão de Frotas,” [Online]. Available:
http://www.ptnegocios.pt/portal/site/negocios/menuitem.269f923fc057d24c29de769b85
105%206a0/?vgnextoid=43f70ec778bd0310VgnVCM1000005401650aRCRD&view_n
ame=null%2F%3F&gcl%20id=CLS1_4PRu68CFYgifAodE2LbhA. [Acedido em 9
Janeiro 2012].
[16] “QTracker – GPS/GSM,” [Online]. Available: http://205.134.232.209/semsons/Spec-
GT-Q3000.pdf. [Acedido em 30 Janeiro 2012].
[17] “Brick House Security,” [Online]. Available:
http://www.brickhousesecurity.com/product/brickhouse+hct+pro+plus.do?sortby=bestS
ellers. [Acedido em 25 Janeiro 2012].
[18] “GT-Q3000,” [Online]. Available: http://205.134.232.209/semsons/Spec-GT-
Q3000.pdf. [Acedido em 23 Janeiro 2012].
[19] R. A. V. Gomes, Sistema embebido de georreferanciação e controlo, FEUP, 2012.
[20] “API do Google Maps,” [Online]. Available:
https://developers.google.com/maps/documentation/javascript/tutorial. [Acedido em 14
Março 2012].
[21] “Modem GSM/GPRS,” [Online]. Available: http://www.mc-
elettronica.com/telit_ez10_family.pdf. [Acedido em 14 Julho 2012].
[22] P.M.Muruganandham, “Real Time Web based Vehicle Tracking using GPS,” em World
Academy of Science, Engineering and Technology, Janeiro 2010.
[23] “Microcontrolador Microchip,” [Online]. Available:
http://ww1.microchip.com/downloads/en/DeviceDoc/41412F.pdf. [Acedido em 10
Julho 2012].
[24] “Conversor Step-Down,” [Online]. Available:
http://www.ti.com/lit/ds/symlink/ptn78060w.pdf. [Acedido em 24 Julho 2012].
[25] “Módulo GPS,” [Online]. Available: http://www.adafruit.com/datasheets/PA6B-
Datasheet-A07.pdf. [Acedido em 3 Junho 2012].
[26] “Siemens TC-35,” [Online]. Available:
http://harvestelectronics.com/harvest/pdf/tc35_t_ug.pdf. [Acedido em 12 Julho 2012].
[27] “Bloqueador Anti-assalto,” [Online]. Available:
http://www.dni.com.br/media/Manual_DNI_1200-Auto.pdf. [Acedido em 4 Agosto
2012].
[28] J. F. R. d. Oliveira, “Sistema Anti-Roubo de Veículos com GSM/GPS,” FEUP 2011,
2011.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
131
[29] M. Chand, C# Programming for Beginners, C# Corner, 2011.
[30] “Introduction to Windows Service Applications,” [Online]. Available:
http://msdn.microsoft.com/en-us/library/d56de412.aspx. [Acedido em 15 Fevereiro
2012].
[31] “Sistemas Operativos em dispositivos móveis,” [Online]. Available:
http://pt.kioskea.net/faq/11106-sistemas-operacionais-para-celulares-e-dispositivos-
moveis. [Acedido em 24 Janeiro 2012].
[32] “Android architecture,” GOOGLE INC: ANDROID DEVELOPERS, [Online].
Available: http://developer.android.com/guide/basics/what-is-android.html. [Acedido
em 28 Janeiro 2012].
[33] “Android developers: Sdk,” GOOGLE INC: ANDROID DEVELOPERS., [Online].
Available: http://developer.android.com/sdk/1.5_r3/index.html. [Acedido em 28
Fevereiro Fevereiro].
[34] “ADT Plugin,” [Online]. Available: http://developer.android.com/tools/sdk/eclipse-
adt.html. [Acedido em 1 Abril 2012].
[35] “Google Maps API,” GOOGLE INC: ANDROID DEVELOPERS, [Online]. Available:
www.developers.google.com/maps.. [Acedido em 26 Fevereiro 2012].
[36] “Google Maps JavaScript API V3,” [Online]. Available:
https://developers.google.com/maps/documentation/javascript/?hl=pt-br. [Acedido em
10 Julho 2012].
[37] J. Bacon, Practical PHP and MySQL: building eight dynamic web applications,
Prentice Hall PTR, 2006.
[38] L. Babin, Beginning Ajax with PHP: From Novice to Professional, Apress, 2006.
[39] “EAGLE PCB Software,” [Online]. Available: http://www.cadsoftusa.com/ . [Acedido
em 14 Setembro 2012].
[40] D. B. Makofske, TCP/IP Sockets in C# Practical Guide for Programmers Book, Morgan
Kaufmann; 1 edition, 2004.
[41] J. M. G. Alves, “Desenvolvimento de um sistema dinâmico,” Universidade do Minho,
2010.
[42] “API Guides Android,” [Online]. Available:
http://developer.android.com/guide/components/index.html. [Acedido em 14 Julho
2012].
[43] “Requesitos Funcionais e não Funcionais,” Wikipédia, [Online]. Available:
http://pt.wikipedia.org/wiki/Requisito. [Acedido em 14 Dezembro 2011].
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
132
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
133
Apêndice A
A.1 Protocolo NMEA
As principais mensagens NMEA utilizadas pelos recetores GPS são:
GPRMC;
GPGGA;
GPVTG;
GPGSV;
GPGLL.
No âmbito do projeto, a frase NMEA de interesse é a GPRMC pois é esta que é
selecionada para ser gerada pelo recetor GPS.
RMC – Recommended Minimum Specific GNSS Data
Dados: Tempo, data, posição, curso e velocidade
Estrutura: $GPRMC, hhmmss.sss(1), A(2),ddmm.mmmm(3), a(4), dddmm.mmmm(5), a(6), x.x(7), x.x(8),
ddmmyy(9), x.x(10), a(11), a(12), *hh(13) <CR><LF>
Exemplo:$GPRMC,092204.999,A,4250.5589,S,14718.5084,E,0.00,89.68,211200,,A*25<CR><LF>
Para transformar os dados da sentença NMEA em dados validos, para posterior
visualização no Google Maps deve-se seguir os passos apresentados de seguida.
Tabela 22 - Campos da frase GPRMC.
Posição Significado Valor (Exemplo) Descrição
1 Tempo UTC 060932.448 Horário UTC no
formato hhmmss.sss
2 Estado A ‘V’=GPS aquecendo
‘A’=Dados válidos
3 Latitude 2447.0959 Latitude no formato
ddmm.mmmm
4 Indicador N/S N Hemísferio
(‘N’=Norte)(‘S’=Sul)
5 Longitude 12100.5204 Longitudeno formato
ddmm.mmmm
6 Indicador E/W E Hemísferio
(‘N’=Norte)(‘S’=Sul)
7 Velocidade 000.0 Velocidade em nós
8 Curso 000.0 Curso em graus
9 Data UTC 211200
Data UTC de uma
posição, no formato
ddmmyy
10 Variação magnética Em graus (000.0 –
180.0)
11 Variação magnética
Em direção
‘E’=Leste;
‘W’=Oeste
12 Indicador de Modo A ‘N’=Dados não
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
134
válidos
‘A’=Modo autónomo
‘D’=Modo
Diferencial
‘E’=Modo Estimado
‘M’=Modo entrada
manual
‘S’=Modo simulação
13 Checksum 0E
Começa com * e
consiste em 2
carateres r
representam um
número
hexadeciamal
Latitude
A seguinte tabela apresenta os campos de interesse na frase NMEA recebida para o
cálculo da latitude.
Tabela 23 - Campos da frase GPRMC relevantes para o cálculo da latitude.
Posição Significado Valor (Exemplo) Descrição
3 Latitude 425.5589 Latitude no formato
ddmm.mmmm
4 Indicador de direções S Hemísferio
(‘N’=Norte)(‘S’=Sul)
15444.6164 S=-15º 44.9892’
Para transformar em graus divide-se por 60
(44.6164/60)=0,743606=-15.743606
Longitude
A seguinte tabela apresenta os campos de interesse na frase NMEA recebida para o
cálculo da longitude.
Tabela 24 - Campos da frase GPRMC relevantes para o calculo da latitude.
Posição Significado Valor (Exemplo) Descrição
5 Longitude 14718.5084 Longitude no formato
ddmm.mmmm
6 Indicador de
direções
E Hemísferio
(‘E’=Este)(‘W’=Oeste)
04755.6189 W=-047º 55.6189’
Para transformar em graus divide-se por 60
(55.6189/60)=0,926981=-047.926981
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
135
A.2 Caraterísticas do Modem GSM
A seguinte tabela apresenta as características do modem GSM selecionado no
decorrer do projeto.
Tabela 25 - Características do modem GSM (Telit EZ10-GPRS).
Dimensões 107x64x33mm
Peso 200g
Temperaturas
de funcionamento
Em condições normais de funcionamento: -10ºC - +55ºC
Em condições extremas de funcionamento: -20ºC - +85ºC
Em condições de armazenamento: -30ºC – 85ºC
Sensibilidade -102dBm
Alimentação
Tensão de entrada: 9-24VDC
Corrente em modo inativo: 8mA @ 12V
Corrente em modo de comunicação: 110mA @ 120 V
Antena
Externa
Ganho: >0dB
Potência de entrada >2W
A interface com o modem é realizada através de 4 conetores apresentados na figura
seguinte.
Figura 108 - Conetores utilizados para interface com o modem.
Características de interface:
4 I/O de prepósito geral
Áudio analógico
9 pinos D-Type para o conetor RS-232
Fêmea SMS, 50 ohm conetor RF
RJ11 / 6 pinos analógicos
-Entrada/Saída de áudio
-GPIOs
Conetor de energia, 4 pinos
Conetor SIM, 3v com tempo real de
deteção
A.3 Características do recetor GPS FGPMMOPA6B
As características do Receiver GPS FGPMMOPA6B são apresentadas na
seguinte tabela.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
136
Tabela 26 - Características do receiver GPS.
Características Gerais Chipset MTK MT3329
Frequência L1, 1575.42MHz
C/A Code 1.023MHz
Canais 66 Canais
SBAS WAAS, EGNOS, MSAS, GAGAN suportado
DATUM WGS84 (por defeito), Tokyo-M, Tokyo-A
CPU ARM7EJ-S
Dimensões
Físicas 16*16*6mm
Peso 6g
Características de desempenho
Exatidão da posição Sem ajuda: 3m
DGPS (RTCM, SBAS): 2.5m
Exatidão da velocidade Sem ajuda: 0.1m/s
DGPS (RTCM, SBAS): 0.05m/s
Exatidão da aceleração Sem ajuda: 0.1m/s2
DGPS (RTCM, SBAS): 0.05m/s2
Exatidão do tempo 100ns RMS
Sensibilidade Aquisição: -148dBm
Reaquisição: -160dBm
Tracking: -165dBM
Update 1HZ (por defeito)
Aquisição (em céu aberto)
Tempo de reaquisição <1s
Arranque a quente 1.0s
Arranque a frio 35s
Dinâmica
Altitude Máximo 18m
Velocidade Máximo 515m/s
Aceleração Máximo 4G
I/O
Sinal de saída 8 bits de dados, sem paridade e 1 stop bit
Baud Rate Por defeito é 9600bps
Protocolos NMEA 0183 V3.01 (GGA, GSA,GSV,RMC,VTG)
Comandos MTK NMEA
Interface de saída
Interface USB Compatível com USB 2.0
Interface UART TTL level serial port
Condições do meio ambiente
Temperatura de
funcionamento -40ºC até 85ºC
Temperatura de
armazenamento 50ºC até 90ºC
Humidade 5% até 95%
Suporte Tipo SMD. 10 pin
A.4 Comandos AT
O presente anexo apresenta uma análise dos principais comandos AT (listados na
Tabela 27) utilizados ao longo da implementação da comunicação com a unidade móvel
via GSM.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
137
Tabela 27 - Principais comandos AT.
Comando Função
AT<CR> Testa comunicação
AT+IPR=<rate><CR> Define baud rate da porta série, rate pode tomar os
valores de 0, 300, 1200, 2400, 4800, 9600
AT+CPIN<CR> Verifica a existência e estado do cartão SIM.
AT+CPIN=****<CR> Fornece o código PIN do cartão SIM.
AT+CMEE=<valor><CR>
Habilita e desabilita o relatório de erros, onde o
parâmetro <valor> pode ser:
0-desabilita
1-habilita em formato numérico
2-habilita em formato de texto
AT+CSQ<CR> Verifica intensidade a qualidade do sinal.
AT+CREG<CR> Verifica estado da rede
AT+CMGF=<mode><CR> Definir o modo de escrita do SMS
AT+CNMI=<mode>,<mt>,
<bm>,<ds>,0<CR> Define comportamento quando recebidas SMS´s
AT+CMGS=<da><CR>
Envio de SMS
Esperar pelo carater “>”
Escrever corpo da mensagem
Terminar com CTRL-Z(0x1A)
AT+CMGD=<index><CR> Eliminar SMS, identificada pelo índice (parâmetro
<index>)
AT+CMGR=<index><CR> Ler SMS identificada pelo seu índice
AT+CMGL=<stat><CR>
Ler conjunto de SMS, onde <stat> pode ter os
seguintes valores:
REC UNREAD – mostrar SMSs recebidos não
lidos;
REC READ - mostrar SMSs recebidos lidos;
STO UNSENT – mostrar SMSs escritos não
enviados;
STO SENT – mostrar SMSs escritas enviados;
ALL – ler todos SMSs.
A.5 Dicionário de Dados
CREATE TABLE IF NOT EXISTS `intelfleet_mydb`.`clientes_alvo` (
`cod_cliente` INT NOT NULL
AUTO_INCREMENT ,
`nome` VARCHAR(45) NOT NULL ,
`morada` VARCHAR(45) NOT NULL ,
`cidade` VARCHAR(45) NOT NULL ,
`codigo_postal` VARCHAR(45) NOT NULL
,
`NIF` VARCHAR(45) NOT NULL ,
`telefone` VARCHAR(45) NOT NULL ,
`fax` VARCHAR(45) NOT NULL ,
`latitude` VARCHAR(45) NOT NULL ,
`longitude` VARCHAR(45) NOT NULL ,
`e_mail` VARCHAR(45) NOT NULL ,
`Tipo_Alvo_cod_tipo_alvo` INT NOT NULL
,
PRIMARY KEY (`cod_cliente`,
`Tipo_Alvo_cod_tipo_alvo`) ,
INDEX `fk_clientes_alvo_Tipo_Alvo`
(`Tipo_Alvo_cod_tipo_alvo` ASC) ,
CONSTRAINT `fk_clientes_alvo_Tipo_Alvo`
FOREIGN KEY (`Tipo_Alvo_cod_tipo_alvo` )
REFERENCES `intelfleet_mydb`.`Tipo_Alvo` (`cod_tipo_alvo`
)
ON DELETE NO ACTION
ON UPDATE CASCADE
)ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `intelfleet_mydb`.`Driver` (
`num_driver` INT NOT NULL ,
`nome` VARCHAR(45) NOT NULL ,
`Morada` VARCHAR(45) NOT NULL ,
`data` DATE NOT NULL ,
`bi` VARCHAR(45) NOT NULL ,
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
138
`NIF` VARCHAR(45) NOT NULL ,
`veiculo_matricula` VARCHAR(9) NOT
NULL ,
`telefone` VARCHAR(45) NOT NULL ,
`caminho` VARCHAR(255) NULL ,
`nome_foto` VARCHAR(45) NULL ,
`foto` LONGBLOB NULL ,
PRIMARY KEY (`veiculo_matricula`,
`num_driver`) ,
INDEX `fk_Driver_veiculo1`
(`veiculo_matricula` ASC) ,
CONSTRAINT `fk_Driver_veiculo1`
FOREIGN KEY (`veiculo_matricula` )
REFERENCES `intelfllet_mydb`.`veiculo`
(`matricula` )
ON DELETE NO ACTION
ON UPDATE CASCADE
)ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS `intelfleet_mydb`.`utilizadores` (
`ID` VARCHAR(45) NOT NULL ,
`PASSWORD` VARCHAR(45) NULL ,
`EMAIL` VARCHAR(45) NULL ,
`Nome` VARCHAR(45) NULL ,
`L_Nome` VARCHAR(45) NULL ,
`Estado’ INT NOT NULL
PRIMARY KEY (`ID`)
)ENGINE = InnoDB;
CREATE TABLE IF NOT EXISTS intelfleet_`mydb`.`Servicos` (
`num_servico` INT NOT NULL
AUTO_INCREMENT ,
`data_inicio` VARCHAR(45) NOT NULL ,
`data_previsao_final` VARCHAR(45) NOT
NULL ,
`kms` VARCHAR(45) NOT NULL ,
`data_realizacao` VARCHAR(45) NULL ,
`realizado` VARCHAR(45) NULL ,
`latitude_dest` VARCHAR(45) NULL ,
`longitude_dest` VARCHAR(45) NULL ,
`Highways` VARCHAR(45) NULL
`Tolls` VARCHAR(45) NULL
`utilizadores_ID` VARCHAR(45) NOT
NULL ,
`Driver_veiculo_matricula` VARCHAR(9)
NOT NULL ,
`Driver_num_driver` INT NOT NULL ,
`clientes_alvo_cod_cliente` INT NOT NULL
,
`clientes_alvo_Tipo_Alvo_cod_tipo_alvo`
INT NOT NULL ,
PRIMARY KEY (`num_servico`,
`utilizadores_ID`, `Driver_veiculo_matricula`,
`Driver_num_driver`,
`clientes_alvo_cod_cliente`,
`clientes_alvo_Tipo_Alvo_cod_tipo_alvo`) ,
INDEX `fk_Servicos_utilizadores1`
(`utilizadores_ID` ASC) ,
INDEX `fk_Servicos_Driver1`
(`Driver_veiculo_matricula` ASC,
`Driver_num_driver` ASC) ,
INDEX `fk_Servicos_clientes_alvo1`
(`clientes_alvo_cod_cliente` ASC,
`clientes_alvo_Tipo_Alvo_cod_tipo_alvo`
ASC) ,
CONSTRAINT `fk_Servicos_utilizadores1`
FOREIGN KEY (`utilizadores_ID` )
REFERENCES `intelfleet_mydb`.`utilizadores` (`ID` )
ON DELETE NO ACTION
ON UPDATE CASCADE,
CONSTRAINT `fk_Servicos_Driver1`
FOREIGN KEY (`Driver_veiculo_matricula` ,
`Driver_num_driver` )
REFERENCES `intelfleet_mydb`.`Driver`
(`veiculo_matricula` , `num_driver` )
ON DELETE NO ACTION
ON UPDATE NO ACTION,
CONSTRAINT `fk_Servicos_clientes_alvo1`
FOREIGN KEY (`clientes_alvo_cod_cliente` ,
`clientes_alvo_Tipo_Alvo_cod_tipo_alvo` )
REFERENCES `intelfleet_mydb`.`clientes_alvo` (`cod_cliente`
, `Tipo_Alvo_cod_tipo_alvo` )
ON DELETE NO ACTION
ON UPDATE NO ACTION )ENGINE = InnoDB;
Triggers
DELIMITER $
CREATE TRIGGER alter_matricula
AFTER DELETE ON veiculo
FOR EACH ROW
UPDATE Driver SET veiculo_matricula=’’
WHERE veiculo_matricula=OLD.matricula;
$
DELIMITER $
CREATE TRIGGER delete_historico_servicos
AFTER DELETE ON Servicos
FOR EACH ROW
DELETE FROM Historico_servico WHERE
Servicos_num_servico=OLD.num_servico;
$
DELIMITER $
CREATE TRIGGER insert_in_historico_servicos
FOR INSERT ON Servicos
FOR EACH ROW
BEGIN
DECLARE latitude_atual, longitude_atual
VARCHAR(45);
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
139
SELECT latitude, longitude
INTO latitude_atual, longitude_atual
FROM veículos
WHERE matriucula=NEW.
Driver_veiculo_matricula
INSERT INTO Historico_servico (latitude,
longitude, data, Servicos_num_servico)
VALUES (latitude=latitude_atual,
longitude=longitude_atual,
data=NEW.data_incio,
Servicos_num_servico=NEW.num_servico);
END $
DELIMITER $
CREATE TRIGGER alter_clientes
AFTER DELETE ON clients_alvo
FOR EACH ROW
UPDATE Servico SET
clients_alvo_cod_cliente=’’ WHERE
clients_alvo_cod_cliente=OLD.cod_cliente;
$
DELIMITER $
CREATE TRIGGER alter_utilizadores
AFTER DELETE ON utilizadores
FOR EACH ROW
UPDATE Servico SET utilizadores_ID=’’
WHERE utilizadores_ID=OLD.ID;
$
DELIMITER $
CREATE TRIGGER alter_driver
AFTER DELETE ON Driver
FOR EACH ROW
UPDATE Servico SET Driver_num_driver=’’
WHERE Driver_num_driver=OLD.num_driver;
$
A.6 Aplicação Posto de Trabalho
Requisições Assíncronas A.6.1
O processo de requisição assíncrona ao servidor inicia-se com a criação dos
ficheiros que pertencem ao lado do cliente (“’querys.php’ e ‘javascript.js’) necessários
para a realização das etapas 1, 2 e 3 da Figura 43. Após isto, é implementado no lado do
servidor um listener e todas as restantes tarefas apresentadas na etapa quatro, utilizando
a tecnologia PHP. Por fim, retorna-se ao lado do cliente e implementa-se o callback e a
funcionalidade que atualiza o DOM HTML pertencente à etapa cinco.
XMLHttpRequest
Antes de ser realizado o passo 1, é necessário verificar a compatibilidade do
objeto com o browser, pois nem todos os navegadores são compatíveis com o objeto
XMLHttpRequest, assim torna-se necessário verificar qual o navegador que o utilizador
utiliza para assim criar o objeto que permita efetuar requisições ao servidor. Nos
navegadores Firefox, Opera e Safari este objeto possui o nome de XMLHttpRequest
enquanto que no Internet Explorer chama-se de Microsoft.XMLHTTP.
A função ‘initiRequest()’ verifica qual o navegador e cria o objeto de acordo com o
browser. A Tabela 28 apresenta os parâmetros necessários durante a criação do objeto
XMLHttpRequest.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
140
Tabela 28 - Parâmetros do objeto XMLHttpRequest.
Parâmetro Descrição URL Endereço de um recurso presente no servidor
Método HTTP GET ou POST
Tipo de interação Solicitações assíncronas
Na função ‘doCompelete()’ é identificado antes da construção do objeto qual a opção do
formulário que gerou a solicitação, pois os parâmetros variam consoante a opção. No
caso utilizado como exemplo (pesquisa de veículos), os parâmetros são:
URL;
o var url=“php/veiculocomplete.php?action=complete&id=2”+…;
Método GET;
Interação assíncrona;
o Req.open(“GET”,url,true);
Como a interação foi definida como assíncrona é necessário especificar uma chamada
de retorno. A função callback apresentada mais tarde é definida através da linha de
código ‘req.onreadystatechange = callback;’. A interação HTTP começa com
‘req.send(null);’, enviando a solicitação HTTP ao servidor.
Listener para manipulação da requisição
No âmbito da aplicação Posto de Trabalho o servidor deverá processar os
pedidos dos clientes como descrito na etapa quatro, procedendo do seguinte modo:
1. Aceder à base de dados e recolher os dados solicitados;
2. Criar um documento XML com os dados recolhidos;
3. Enviar ficheiro XML como resposta.
Tudo isto é implementado através da tecnologia PHP num ficheiro designado de
‘veiculocomplete.php’. Para realizar o primeiro passo é necessário criar uma conexão e
posteriormente uma consulta MySQL á base de dados.
De modo aceder à base de dados torna-se necessário criar uma conexão com o servidor
MySQL, para tal recorre-se às funções: mysql_connect (server, username, password) e
mysql_select_db(database).
A Tabela 29 descreve as diferentes variáveis passadas como parâmetros na função
mysql_connect()
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
141
Tabela 29 - Parâmetros recebidos pela função mysql_connect().
A função mysql_connect abre uma conexão com o servidor MySQL
Parâmetro Descrição
server Servidor MySQL, pode também incluir o numero da porta
username Nome do utilizador. Por norma é o nome do proprietário do processo
do servidor
password Password de acesso a base de dados
A Tabela 30 descreve as variáveis utilizadas como parâmetros quando invocada a
função mysql_select_db.
Tabela 30 - Parâmetros recebidos pela função mysql_select_db().
A função mysql_select_db seleciona uma base de dados MySQL
Parâmetro Descrição
database Especifica a base de dados presente no servidor MySQL
O código que implementa tudo isto é apresentado na Figura 109.
Figura 109 - Consulta dos dados requisitados utilizando os comandos SQL.
A última linha de código envia a consulta e retorna como resultado um resource, este
mantém uma referência a um recurso externo. Após obter o resultado da pesquisa é
necessário processá-lo. Para tal é utilizada a função mysql_fetch_array, esta retorna uma
matriz que corresponde à linha obtida e move o apontador interno para a linha seguinte.
A informação presente em cada linha é utilizada para instanciar um novo objeto
Veículo, estes são armazenados num array chamado ‘results’. A Figura 110 apresenta
as instruções utilizadas para realização dos passos aqui descritos.
Figura 110 - Aquisição dos dados resultantes de uma consulta à base de dados.
Com o código aqui apresentado temos o primeiro passo finalizado, tendo todas os
recursos necessários para o segundo e seguinte passo: criação de um ficheiro XML
(Figura 111). O tipo de conteúdo da resposta precisa ser definido como text/xml.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
142
Figura 111 - Incorporar informação coletada num ficheiro XML.
O ficheiro ‘veiculocomplete.php’ gera um documento XML que contém informações
dos veículos da organização registados na base de dados.
Função callback
Na última etapa (5) é necessário definir uma função callback (ficheiro
‘javascript.js’) para manipular a resposta do servidor. Esta função é chamada
assincronamente durante a interação HTTP, isto acontece sempre que o objeto
readyState do XMLHttpRequest muda de estado. Nesta aplicação a função de retorno é
chamada de callback, definida como tal (na função ‘doCompletion’ apresentada
anteriormente ainda no presente capítulo) através da propriedade
XMLHttpRequest.onreadystatechange. A Figura 112 apresenta as instruções que
implementam a função callback.
Figura 112 - Função "callback" definida como função de retorno.
A variável readyState indica o estado de interação HTTP, quando tem o valor “4”
significa que a interação foi concluída. Os estados possíveis da interação são
apresentados na Tabela 31.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
143
Tabela 31 - Estados da interação HTTP.
readyState (valor) Descrição do estado do objeto 0 Não inicializado
1 Carregando
2 Carregado
3 Interativo
4 Concluído
A função ‘parseMessages()’ manipula os dados XML recebidos. No código
desenvolvido a função só é chamada quando ‘readyState’ possui o valor “4” e o status é
“200” o que significa o sucesso da interação. Contudo antes de chegarmos a esta função
é necessário introduzir novos elementos (tabela) na página
‘www.intelfllet.com/querys.php’, bem como os seus ID’s para que possam ser
referenciados no ficheiro ‘javascript.js’. Esta função utiliza as várias funções auxiliares
descritas na Tabela 32.
Tabela 32 - Funções de auxílio utilizadas pela função ‘ParseMessages()’.
Função Descrição
clearTable() Torna invisível ao utilizador a tabela HTML e remove todas as entradas de
veículos existentes que tenham sido anteriormente criadas.
getElementY()
Desenvolvida para permitir localizar a posição vertical do elemento pai,
isto é necessário pois verificou-se que a posição deste pode variar
dependendo do tipo de browser
appendVeiculo() Implementada para inserir novas linhas na tabela com os dados do
veículo, insere um link no campo matricula do veículo
O link introduzido no campo matricula de cada linha (veículo) através da linha de
código:
linkElement.setAttribute("href", "php/veiculocomplete.php?action=lookup&id="
+ email);
Esta linha permite a realização de uma nova pesquisa quando clicada sobre o link (com
URL passada como parâmetro), que resulta na apresentação de todos os detalhes
armazenados sobre o veículo selecionado.
Por fim a função ‘parseMessages()’ que recebe como parâmetro um objeto
representativo do ficheiro XML (responseXML) proveniente do ficheiro
‘veiculocomplete.php’. A função verifica que tipo de pesquisa foi realizado através do
elemento select_form, com essa informação temos conhecimento de qual é a informação
que deve ser extraída do documento XML e poderá então realizar a extração dos
mesmos. No exemplo da pesquisa de veículos a função percorre o ficheiro e extrai todos
os dados de cada entrada (matricula, ano, marca, modelo, e localização), as tags
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
144
<veiculo></veiculo> denunciam uma entrada. Os dados após extraídos são passados a
função ‘appendeVeiculo()’, resultando numa atualização dinâmica da tabela (elemento
complteTable).
Mapas do Google Maps A.6.2
Os passos a realizar com objetivo de incorporar mapas do Google na aplicação
Posto de Trabalho são os seguintes (pela ordem que são listados):
1. Carregar API do Google Maps
A URL contida na tag script é localização de um ficheiro JavaScript que carrega
todos os símbolos e definições necessárias para utilizar a API do Google Maps. Na mais
recente versão da API foi removida a necessidade de incorporar uma key única por
cliente, chave que era introduzida nesta mesma URL. Além deste é passado o parâmetro
sensor que indica se é utiliza um sensor para determinar a localização do utilizador
(falso para o presente caso). A Figura 113 apresenta o bloco de código que permite
carregar a API do Google Maps para a página HTML..
Figura 113 - Carregar para página HTML a API do Google Maps.
2. Mapear Elementos DOM
Para apresentar o mapa na página web, é necessário reservar espaço para ele
através da criação de um elemento div e da sua referência DOM (Document Object
Model).
<div id="map_canvas" class="button_all">
A linha de código apresentada como exemplo define um <div> chamado ‘map_canvas.
3. Instanciar Objeto Map
A classe JavaScript que representa um mapa é a classe Map, este objeto define
um único mapa na página. No código anterior foi criada uma nova instância da classe
utilizando o operador JavaScript new. Ao criar uma nova instância do mapa,
especificamos um nó DOM (<div>) como sendo um recipiente para o mapa. Os nós
HTML são filhos do objeto JavaScript document, e obtém-se assim a referência a este
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
145
elemento (map_canvas) pelo método document.getElementById() apresentado na Figura
114.
Figura 114 - Criação de uma instancia da classe Map.
Este código define uma variável chamada ‘map’ e atribui-a a um novo objeto Map. A
função ‘google.maps.Map()’ é um construtor, sua nomenclatura, parâmetros e descrição
é apresentada na Tabela 33.
Tabela 33 - Construtor google.maps.Map().
Construtor Descrição
Map(Div:Nó, opts?:MapOptions)
Cria um novo mapa dentro do container HTML
fornecido (div). Outros parâmetros podem ser
passados (opcional) do tipo MapOptions no
parâmetro opts.
4. Configurar o Mapa
Antes de instanciar o objeto Map é necessário criar o objeto MapOptions que
contém as variáveis de inicialização do mapa. As variáveis inicializadas são: zoom
especifica o nível de zoom apresentado no mapa; Center, para centrar o mapa num
ponto específico, para tal foi criado um objeto LatLng para manter esta localização
passando as coordenadas do local na ordem {latitude, longitude}; mapTypeId, define
especificamente o tipo de mapa inicial, foi definido o tipo ROADMAP que consiste no
padrão por defeito do Google Maps. A Figura 115 implementa este último passo
durante o processo de inclusão de mapas na presente aplicação.
Figura 115 - Configuração do objeto Map.
5. Carregar o Mapa
Durante a apresentação da página, o DOM é criado e todas as imagens e scripts
externos são recebidos e incorporados no objeto document. Para garantir que o mapa é
colocado na página só depois de esta ter sido totalmente carregada, só executamos a
função ‘MAP_INIT()’ presente no ficheiro ‘javascript.js’ que cria o objeto Map depois
de o elemento <body> da página ter recebido um evento onload. Isto evita
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
146
comportamentos imprevisíveis e oferece-nos maior controlo sobre como e quando o
mapa é desenhado.
<body onLoad="init()">
A.7 Funcionalidades do Posto de Trabalho
A.7.1 Visualização da Posição Geográfica do Veiculo
Para adicionar um link num dado campo (matrícula) na tabela HTML foi
implementado o seguinte código:
linkElement.setAttribute("href","javascript:MAP_POINT("+lat+","+long+","+se
rv+","+fg+")");
A linha de código anterior presente na função ‘appendVeiculo’ cria o link que é uma
referência à função ‘MAP_POINT()’ que recebe como parâmetro variáveis com os
valores da latitude, longitude, estado de serviço e data que corresponde a posição
geográfica. O utilizador ao clicar na matrícula ira gerar um evento que executará a
função ‘MAP_POINT’, no fluxograma da Figura 46 é apresentado o fluxo de
informação executado quando selecionado um veículo no mapa pelo utilizador.
Para realizar a geocodificação inversa é utilizado o objeto Geocoder que suporta
geocodificação reversa diretamente, ou seja, em vez de fornecer um endereço sobre a
forma de texto é fornecido separados por vírgula a latitude e longitude no parâmetro
‘LatLng’.
geocoder.geocode({'latLng': myLatlng}, function(results, status);
Na utilização do objeto Geocoder na linha anterior foi ainda adicionado uma função
com parâmetros, isto se deve ao facto do acesso ao serviço de geocodificação ser
assíncrono, pois a API necessita de efetuar uma chamada a um servidor externo por essa
razão é necessário fornecer um método callback para processar o resultado após a
conclusão do pedido. Um dos parâmetros passados pela função, o status contém o status
da solicitação e armazena valores que indicam o que poderá ter falhado numa
geocodificação. A variável satus poderá conter os seguintes valores:
"google.maps.GeocoderStatus.OK" indica que nenhum erro ocorreu; o endereço
foi analisado e pelo menos um geocódigo foi retornado.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
147
"google.maps.GeocoderStatus.ZERO_RESULTS" indica que o geocódigo teve
êxito, mas não retornou resultados. Isso pode ocorrer se o geocódigo passou
um address ou latlng não existente em um local remoto.
"google.maps.GeocoderStatus.OVER_QUERY_LIMIT" indica que você
ultrapassou a sua cota.
"google.maps.GeocoderStatus.REQUEST_DENIED" indica que a sua
solicitação foi negada, normalmente por falta de um parâmetro sensor.
"google.maps.GeocoderStatus.INVALID_REQUEST" normalmente indica que a
aplicação ultrapassou o número de solicitações dentro do prazo permitido.
Quando o processo retorna resultados ele necessita de inseri-los numa matriz, a variável
‘results’ passada como parâmetro na função de retorno é uma matriz que irá armazenar
os resultados. Um dos campos dessa matriz designa-se de formatted_address
(results[1].formatted_address), consiste numa string com o endereço legível do local.
Apesar de ser possível a resposta conter vários resultados é sempre selecionado para
fins de apresentação na janela de informação o primeiro, pois se verificou em testes
realizados que os endereços são retornados do mais especifico para o menos.
Para finalizar a implementação da função ‘MAP_POINT’ resta apenas inserir um
marcador. Os marcadores identificam pontos no mapa, o seu construtor
google.maps.Marker usa um google.maps.LatLng e objetos myOptions opcionais como
argumento, no contexto da aplicação este só é inserido no mapa caso a geocodificação
seja realizada com sucesso e que pelo menos um resultado tenha sido obtido, esta
verificação necessita de ser realizada dentro do scope da função de retorno.
A.7.2 Serviços Terminados
O objeto ‘DirectionsRequest’ inclui parâmetros necessários para a geração da
rota, estes encontram-se descritos na Tabela 34.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
148
Tabela 34 - Parâmetros a incluir no objeto ‘DirectionsRequest’ e entidade onde estão armazenados os valores
com que estes são iniciados.
Parâmetro Descrição Valor atribuído Tabela na B.D origin Especifica o local de início
para calcular a rota
Posição atual do veículo Tabela ‘veiculos’,
campos ‘longitude’ e
‘latitude’
destination Especifica localização final Localização do Cliente ‘cliente_alvo’, campos
‘latitude’ e ‘longitude’
travelMode Especifica modo de transporte google.maps.TravelMod
e.Driving
---
Waypoints[] Alteraram uma rota através do
seu encaminhamento através
do local especificado (s)
null ---
provideRouteAlternatives Especifica se o serviço poder
fornecer mais do que uma
alternativa de rota na resposta
false ---
avoidHighways Indica se a rota calculada deve
evitar estradas principais
Valor indicado aquando
a criação do serviço
‘Servicos’, campo
‘Highways’
avoidTolls Indica se a rota calculada deve
evitar estradas com portagem
Valor indicado aquando
a criação do serviço
‘Servicos’, campo
‘Tolls’
Os pontos extraídos do ficheiro XML são utilizados para especificar os waypoints dentro
do objeto ‘DirectionsRequest’. Estes pontos de passagem permitem calcular a rota
através de locais adicionais. Um waypoint é composto pelos seguintes campos:
Location: especifica o seu endereço;
Stopover: (true) indica se é uma passagem obrigatória da rota ou uma
preferência de passagem de rota a gerar (false).
O código implementado presente na Figura 116 demonstra como é utilizado array
waypoints para o cálculo da rota percorrida pelo condutor. Os diferentes pontos
geográficos são extraídos do ficheiro recebido e armazenados no array, a função
indicada como callback () no instante que é configurada a requisição assíncrona realiza
esta tarefa. Para a criação dos waypoints são percorridas todas estes pontos armazenados
no array e criado o objeto google.maps.LatLng que é armazenado no array waypoints.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
149
Figura 116 - Geração de rotas com passagem em pontos de referência utilizando API do Google Maps.
A solicitação ao servidor retorna um objeto ‘DirectionsResult’ e um código
‘DirectionsStatus’. Este último indica se a solicitação foi realizada com sucesso e
permite apresentar ao utilizador quando ocorre um erro e o seu motivo. Para exibir o
primeiro objeto ao utilizador, através de um ‘DirectionsRenderer’ foram realizados os
seguintes passos:
1. Criar um objeto ‘DirectionsRenderer’;
2. Invocar ‘setMap()’ para vincular lo ao mapa passado;
3. Chamar ‘setDirections()’, passando o ‘DirectionsResult’ assim será
automaticamente atualizado o mapa vinculado.
A.7.3 Verificação de rotas percorridas
A estratégia implementada é possível a partir da exploração do objeto recebido
como resposta da solicitação da rota, DirectionsResult. Este objeto é composto apenas
pelo campo, Routes[] que contêm um conjunto de objetos DirectionsRoute,
correspondendo a diferentes rotas. O objeto alocado na primeira posição do array é
escolhido e utilizada sua informação para validar a execução de um serviço, é utilizado
só e apenas esse objeto, pois assim garante-se que é a mesma rota que é apresentada ao
condutor aquando a realização da tarefa. No objeto interessa-nos o campo legs que
contém um array de objetos DirectionsLeg, cada um contém informação de partes do
trajeto (leg), quanto existe pontos de passagem a rota poderá se dividir em legs. Cada
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
150
leg consiste numa série de DirectionsSteps, este objeto possui informação acerca de
cada etapa (step) da leg. Com a informação dos steps torna-se possível calcular a
distância entre este e a posição do veículo, pois entre outras informações temos a
necessária para o cálculo, start_location (contém as coordenadas geográficas sobre a
forma de objeto LatLng do ponto inicial do step).
A.8 Aplicação Terminal do Condutor
A.8.1 Declarar Atividades
Quando definimos uma atividade temos de a estender como já referido à classe
Activity e implementar obrigatoriamente o método OnCreate (invocado sempre que é
iniciada a atividade) como realizado no bloco de código apresentado na seguinte figura.
Figura 117 - Implementação do método onCreate da classe Activity.
O método setContentView permite associar a atividade à tela/layout, a classe
R.layout.login esta definida no ficheiro R.java, este é gerado automaticamente
vinculando constantes com os recursos desejados na aplicação.
A base de uma aplicação Android define-se no ficheiro AndroidManifest.xml (Figura
118), este ficheiro é obrigatório e fica presente na pasta da raiz do projeto.
Figura 118 - Exemplo da estrutura do ficheiro Android Manifest.xml.
Cada atividade implementada para a presente aplicação deve possuir uma entrada neste
ficheiro entre as tags <activity> e </activity>
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
151
A.9 Circuitos e Esquemáticos da Unidade Móvel
A.9.1 Placa desenvolvida
Todos componentes físicos abordados durante a implementação da ferramenta
são interligados numa placa desenvolvida em PCB visível na Figura 119, obtendo-se de
forma compacta o sistema de comunicação entre os diferentes componentes.
Figura 119 - Aspeto físico da placa desenvolvida.
Unidade de Processamento
O microcontrolador adotado necessita de um cristal com valores entre 16 MHz o
que implica alguns cálculos aquando a escolha do baudrate das portas EUSART.
[ ]
Utilizando a fórmula apresentada acima e para um baud rate de 9600 bps, pode-se
calcular o valor a utilizar na função de configuração da porta.
bps
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
152
Para um cristal de 16MHz e para um baudrate de 9600bps o valor a utilizar na equação
é 25, o que impõe uma percentagem de erros de transação igual 0,16%. Assim pode-se
afirmar que o cristal escolhido em termos de utilização da EUSART, possui um
excelente aproveitamento pois o erro é muito reduzido.
Receiver GPS
Na Figura 120 é apresentada a montagem implementada aquando a utilização do
Receiver GPS.
Figura 120- Montagem do receiver GPS.
Conversor Step-Down
A utilização desta fonte comutada surge da necessidade de extrair da fonte de
energia/bateria do veículo (12V-24V) tensões necessárias para alimentar os
componentes de hardware (Receiver e módulo GPS), que requer 5V e a unidade de
processamento 3.3V. A tensão pretendida é obtida variando a resistência Rset existente
no circuito envolvente. A Figura 121 demonstra a fonte comutada assim como a
montagem típica implementada na placa desenvolvida.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
153
Figura 121 - Esquema de ligação da fonte comutada PTN78060W.
Circuitos Auxiliares
Estes circuitos são utilizados devido às tensões nominais do microcontrolador
ser de 3.3V, enquanto os componentes de hardware que comunicam via série com a
unidade móvel utilizam uma tensão nominal de 5V.
Para compensar o desnível de tensão foram implementados dois circuitos, devido à
comunicação ser bidirecional No envio de dados do microcontrolador para os
componentes é necessário elevar a tensão de 3.3V para 5V, tarefa realizada pelo circuito
da Figura 122.
Figura 122 - Circuito elevador de tensão.
Por sua vez, na transmissão de dados no sentido dos componentes para o
microcontrolador é apenas necessário descer o nível de tensão para 3.3 V, o que pode
ser realizado por um simples divisor de tensão de duas resistências como apresentado na
Figura 123.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
154
Figura 123 - Divisor de tensão como meio de baixar o nível de tensão.
Sistema de Bloqueio
O circuito implementado para o corte da corrente da bomba de gasolina é
apresentado na Figura 124.
Figura 124 - Circuito de bloqueio do veículo.
A.9.2 Esquemático em Eagle
A seguinte figura apresenta o esquemático em Eagle da placa desenvolvida no
presente projeto.
IntelFleet-Sistema de Gestão e Localização de Frotas via GPS
Duarte Fernandes
155
Figura 125 - PCB desenvolvida para a Unidade Móvel.
A.9.3 GPIO
Levantamento do I/O disponível na unidade de processamento e a respetiva
atribuição ao hardware descrito na Tabela 35.
Tabela 35 - Pinos do microcontrolador utilizados.
Port Map Número do
pino
Descrição do
Pino Descrição Hardware
RE3 1 Vpp/MCLR Pinos para programar a PIC com o
PICKit
Programador
RB6 39 PGC
RB7 40 PGD
CR6 25 TX1/CK1 TX USART 1 Módulo GSM RC7 26 RX1/DT1 RX USART 1
RD6 29 TX2/CK2 TX USART 2 Receiver GPS RD7 30 RX2/DT2 RX USART 2
RB7 33
Pin I/O
RED
RGB RB6 34 GREEN
RC0 35 BLUE
RB4 37 Fix GPS Receiver GPS
RD5 28 Relé S.Bloqueio