Page 1
João Diogo Peixoto do Vale
Desenvolvimento de um Protótipo baseadoem PC de um Centro de Monitorização deEstafetas
João
Dio
go P
eixot
o do
Val
e
Outubro de 2012UMin
ho |
201
2De
senv
olvi
men
to d
e um
Pro
tótip
o ba
sead
o em
PC d
e um
Cen
tro
de M
onito
riza
ção
de E
staf
etas
Universidade do MinhoEscola de Engenharia
Page 3
Outubro de 2012
Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre em Engenharia Eletrónica Industrial e Computadores
Trabalho efetuado sob a orientação doProfessor Doutor José A. Mendes
João Diogo Peixoto do Vale
Desenvolvimento de um Protótipo baseadoem PC de um Centro de Monitorização deEstafetas
Universidade do MinhoEscola de Engenharia
Page 5
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
iii
Agradecimentos
Antes de tudo, gostaria de deixar o meu sincero agradecimento ao Professor Doutor
Adriano Tavares, que propôs este projeto para tema da minha dissertação e que sempre
esteve disponível para qualquer tipo de esclarecimento ou conselho do meu interesse.
Também gostaria de agradecer ao Professor Doutor José Mendes, por ter aceitado
orientar-me e pela relação aberta que teve para comigo e com o meu trabalho.
A todos os meus amigos de trabalho, em particular ao amigo Pedro Rodrigues com
quem tive o imenso prazer de trabalhar, gratifico o bom ambiente, apoio e amizade que
sempre demostraram.
Queria agradecer ao meu grupo de amigos do dia-a-dia, obrigado por todo o vosso apoio
e confiança que me concederam quando precisei.
Aos técnicos e funcionários das oficinas do Departamento de Engenharia Eletrónica
Industrial pela disponibilidade, simpatia e boa disposição com que sempre me
atenderam e disponibilizaram os seus serviços e material ao meu dispor.
Uma palavra de agradecimento a todos os professores e colegas da Universidade do
Minho, que proporcionaram os conhecimentos necessários.
Por último, mas não menos importante quero deixar o meu profundo agradecimento aos
meus pais, que sem eles esta caminhada não se tornaria possível, por toda a confiança e
apoio transmitido nos momentos bons e maus aquando da realização deste projeto.
Page 6
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
iv
Page 7
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
v
Resumo
Normalmente a palavra tracking significa monitorização e depois controlo. Um centro
de monitorização de estafetas pode definir-se como um centro de observação de pessoas
em movimento de modo continuado na qual é fornecida uma sequência de dados
ordenados da respetiva localização a uma determinada aplicação capaz de traduzir esse
movimento visualmente. Por exemplo, atualmente sabendo as coordenadas espaciais de
uma pessoa através de um dispositivo de localização, é possível saber onde ela está com
o simples recurso a uma ferramenta de geração de mapas. No mercado existe uma
grande variedade de tecnologias que suporta este tipo de conceito, indicadores em
tempo real, como por exemplo, o Sistemas de Posicionamento Global, popularmente
conhecido por recetor GPS.
O que se pretende implementar nesta dissertação, é um protótipo baseado em PC de um
centro de monitorização de estafetas apoiado na informação da localização geográfica
recolhida por tecnologia GPS com possibilidade de correção de trajeto. É um projeto
baseado no conceito de tracking com grande relevância aplicacional na qual existe a
possibilidade de ser inserido numa empresa de restauração. Imagine-se uma empresa de
entregas ao domicílio de pizzas em que o proprietário pretende monitorizar os seus
estafetas, seus percursos e alertá-los, por exemplo, se um estafeta se está a desviar do
correto trajeto ou se cumpriu o tempo mínimo de entrega.
Através deste protótipo deverá ser possível a comunicação remota do servidor com
qualquer recetor GPS através da comunicação a partir de sockets (protocolo TCP/IP) ou
pela rede GSM. [1] A aplicação do lado servidor irá interagir com recetores GPS, trocar
informação e permitir visualizar as localizações de cada estafeta (Data Viewer). Para
isso, irão ser utilizados recursos do Google Maps. Ainda nesta dissertação será
desenvolvida outra aplicação para ser inserida em dispositivos Android (por exemplo,
telemóvel) com uma série de funcionalidades e informações úteis.
Em suma, o principal foco da dissertação é o desenvolvimento de software que permita
a comunicação entre o hardware e o utilizador de forma a criar um centro de
monitorização de estafetas.
Palavras-chave: Tracking, Sistema de Monitorização, GPS, GSM, TCP/IP, Google
Maps, Android;
Page 8
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
vi
Page 9
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
vii
Abstract
Normally the tracking word means monitoring and then control. A tracking system of
courier can be defined like an observation center for people moving in a continuous
mode where is given a series of ordered data of corresponding location that a given
application can translate such movement visually. For example, knowing the spatial
coordinates given by a location device, it is possible to precisely locate and mark it in a
map reproduced by a map generator. On the market there are a variety of technologies
which support this type of concept, indicators in real time, as the Global Positioning
System, popularly known as GPS.
The goal of this dissertation is implementing a prototype of a PC-based tracking system
of courier supported on the geographical location information collected by GPS
technology with the possibility of correction path. It is a project based on the concept of
tracking with great relevance applicational which later can be incorporated into the
delivery system of a restauration company. Imagine a home delivery company of pizzas
where the owner want to track his couriers, their routes and alert them, for example, if
they are deviating from the trajectory or if they meet the minimum time for delivery.
Using this prototype should be possible to establish remote communication between the
server and the GPSs devices via GSM or sockets (protocol TCP/IP). [1] The server
application will interact with GPSs devices, exchange information and allow you to
view the locations of each courier as a data viewer. For this, it will be used capabilities
of Google Maps. Two version of such application will be implemented to be running on
the desktop and Android devices, respectively.
In conclusion, the main focus of this dissertation is the development of a software that
enables the communication among GPS device, courier, and courier’s manager to create
a monitoring center.
Keywords: Tracking, Monitoring system, GPS, GSM, TCP/IP, Google Maps, Android;
Page 10
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
viii
Page 11
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
ix
Índice
Agradecimentos ............................................................................................................... iii
Resumo ............................................................................................................................. v
Abstract ........................................................................................................................... vii
Índice ............................................................................................................................... ix
Índice de Ilustrações ...................................................................................................... xiii
Índice de Tabelas .......................................................................................................... xvii
Lista de Acrónimos ........................................................................................................ xix
Introdução ......................................................................................................................... 1
1. Motivações ............................................................................................................ 2
2. Estrutura da Dissertação ........................................................................................ 3
Estado da Arte .................................................................................................................. 5
3. Visão geral dos sistemas já existentes no mercado ............................................... 5
4. Exemplos de centros de monitorização ................................................................. 6
4.1. Amplifrota ...................................................................................................... 6
4.2. Frotcom .......................................................................................................... 7
4.3. 3dtracking ....................................................................................................... 8
4.4. LiveGTS ......................................................................................................... 8
4.5. Outras soluções .............................................................................................. 9
4.6. Comparação das soluções apresentadas ....................................................... 10
5. Geofencing........................................................................................................... 12
Estudo/Análise do sistema a implementar ...................................................................... 15
6. Restrições do sistema .......................................................................................... 15
7. Requisitos do sistema .......................................................................................... 16
8. Especificação do hardware .................................................................................. 18
8.1. GPS............................................................................................................... 18
Page 12
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
x
Recetores GPS ..................................................................................................... 19
Protocolo NMEA 0183 ........................................................................................ 22
8.2. GSM ............................................................................................................. 23
Modem GSM ....................................................................................................... 24
Comunicação com o modem via comandos AT .................................................. 25
8.3. RFID ............................................................................................................. 26
Módulo RFID (Leitor + Etiquetas) ...................................................................... 27
8.4. Unidade de Localização Móvel .................................................................... 30
9. Especificação de software a utilizar .................................................................... 31
9.1. Interface com o utilizador ............................................................................ 31
C# ........................................................................................................................ 31
Sistema Operativo Android ................................................................................. 32
9.2. Base de dados ............................................................................................... 36
SQLite .................................................................................................................. 36
9.3. Protocolo TCP/IP ......................................................................................... 37
Modelo cliente/servidor TCP/IP (sockets) .......................................................... 38
9.4. Google Maps ................................................................................................ 40
9.5. Subsistemas de software............................................................................... 42
Aquisição de dados .............................................................................................. 42
Tratamento de dados ............................................................................................ 43
Comunicação ....................................................................................................... 43
Deteção de erros e alertas .................................................................................... 43
10. Diagrama Geral do sistema a implementar ...................................................... 45
Modelação e Desenvolvimento do sistema .................................................................... 49
11. Modelação de dados ......................................................................................... 49
12. Interfaces com o Hardware .............................................................................. 54
12.1. Porta-Série ................................................................................................ 54
Page 13
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xi
12.2. Cliente/Servidor TCP/IP ........................................................................... 57
12.3. Rede GSM ................................................................................................ 60
13. Subsistemas de software .................................................................................. 62
13.1. Subsistema de aquisição de dados ............................................................ 62
Aquisição periódica ............................................................................................. 62
Aquisição on-demand .......................................................................................... 63
13.2. Subsistema de tratamento de dados .......................................................... 65
Comandos reconhecidos pelo centro de monitorização (com a unidade de
localização móvel) ............................................................................................... 67
Comandos reconhecidos pelo centro de monitorização (com dispositivos
Android) ............................................................................................................... 77
13.3. Subsistema de comunicação ..................................................................... 86
13.4. Tratamentos de erros e alertas .................................................................. 91
14. Interfaces gráficas das aplicações .................................................................... 95
14.1. Aplicação Servidor em C# ........................................................................ 95
14.2. Aplicação Cliente para Android ............................................................. 108
15. Funcionalidades ............................................................................................. 114
15.1. Google Maps .......................................................................................... 114
15.2. Sistema de Autenticação ......................................................................... 121
15.3. Sistema de cópias de segurança da base de dados .................................. 122
15.4. Localização do Centro de Monitorização ............................................... 126
15.5. Lista de espera (encomendas) ................................................................. 126
15.6. Escrita de etiqueta RFID dados de um estafeta ...................................... 127
Testes e Resultados ....................................................................................................... 129
16. Ligação e comunicação com dispositivos do tipo cliente .............................. 130
17. Base de dados ................................................................................................. 132
18. Posição geográfica de uma unidade de localização móvel ............................ 134
Page 14
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xii
19. Deteção da saída de rota ................................................................................ 136
20. Sistema de cópias de segurança ..................................................................... 138
21. Pedido para processamento de encomenda .................................................... 139
22. Centro de monitorização e unidade de localização móvel em tempo real ..... 142
Conclusões e Trabalho Futuro ...................................................................................... 143
23. Conclusões ..................................................................................................... 143
24. Trabalho Futuro ............................................................................................. 144
Bibliografia ................................................................................................................... 145
Anexos .......................................................................................................................... 147
25. Como instalar o sistema ................................................................................. 147
Page 15
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xiii
Índice de Ilustrações
Ilustração 1 – Visão dos recetores GPS (marcadores vermelhos) pelo gestor Amplifrota 6
Ilustração 2 – Funcionamento do sistema Frotcom .......................................................... 7
Ilustração 3 – Funcionamento de um sistema LiveGTS .................................................... 9
Ilustração 4 – Exemplo de formas de perímetros ........................................................... 12
Ilustração 5 – Geofencing na monitorização de veículos ............................................... 13
Ilustração 6 – Exemplos de recetores GPS ..................................................................... 18
Ilustração 7 – Holux M-1000C ....................................................................................... 20
Ilustração 8 – CANMORE GT-370F.............................................................................. 21
Ilustração 9 – G-SAT BT-328T ...................................................................................... 22
Ilustração 10 – Exemplos de Modem GSM/GPRS ......................................................... 24
Ilustração 11 – Telit EZ10-GPRS ................................................................................... 24
Ilustração 12 – Exemplo da utilização da tecnologia RFID ........................................... 27
Ilustração 13 – SSRFID v1.0 + Etiqueta MF1 IC S50 ................................................... 29
Ilustração 14 – Organização da memória EEPROM ...................................................... 30
Ilustração 15 – Protótipo da unidade de localização móvel ........................................... 30
Ilustração 16 – Camadas do SO Android ....................................................................... 32
Ilustração 17 – Ciclo de vida de uma atividade .............................................................. 34
Ilustração 18 – Conjunto de camadas do protocolo TCP/IP .......................................... 37
Ilustração 19 – Modelo Cliente/Servidor........................................................................ 39
Ilustração 20 – Modelo cliente/servidor TCP/IP ............................................................ 40
Ilustração 21 – Diagrama Geral (com os nodos Singulares GPS) .................................. 46
Ilustração 22 – Diagrama Geral (unidades de localização móvel) ................................. 46
Ilustração 23 – Diagrama Geral (Dispositivo com aplicação para Android) .................. 47
Ilustração 24 – Diagrama ER da base de dados ............................................................. 50
Ilustração 25 – Base de Dados do sistema com recurso à ferramenta SQLite
Administrator .................................................................................................................. 53
Ilustração 26 – Fluxograma de configuração e conexão do módulo RFID .................... 55
Ilustração 27 – Fluxograma de configuração e conexãodo modem GSM ...................... 56
Ilustração 28 – Fluxograma da configuração e inicialização do servidor ...................... 58
Ilustração 29 – Fluxograma da thread responsável pelo atendimento a novas conexões
........................................................................................................................................ 59
Page 16
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xiv
Ilustração 30 – Fluxograma que representa a configuração do cliente TCP/IP ............. 60
Ilustração 31 – Fluxograma da sub-rotina Configurar rede GSM .................................. 61
Ilustração 32 – Fluxograma do subsistema de aquisição periódica ................................ 63
Ilustração 33 – Fluxograma do subsistema de aquisição on-demand (lado do centro) .. 64
Ilustração 34 – Fluxograma do subsistema de aquisição on-demand (lado da aplicação
Android) .......................................................................................................................... 65
Ilustração 35 – Fluxograma que representa o sub-rotina de tratamento de dados .......... 66
Ilustração 36 – Fluxograma da thread responsável pela receção de dados .................... 86
Ilustração 37 – Fluxograma da thread que processa do envio de dados ........................ 87
Ilustração 38 – Fluxograma para leitura de dados pela rede GSM ................................. 88
Ilustração 39 – Fluxograma da rotina Ler mensagem..................................................... 89
Ilustração 40 – Fluxograma da rotina Tratar mensagem lida ........................................ 89
Ilustração 41 – Fluxograma para a escrita de dados pela rede GSM .............................. 91
Ilustração 42 – Exemplo de uma caixa de diálogo (MessageBox) ................................. 92
Ilustração 43 – Exemplo da utilização das StatusLabels ................................................ 92
Ilustração 44 – Exemplo da utilização dos Toasts .......................................................... 93
Ilustração 45 – Exemplo da utilização da declaração lock ............................................. 94
Ilustração 46 – AboutForm.cs ........................................................................................ 96
Ilustração 47 – BackupForm.cs ...................................................................................... 97
Ilustração 48 – CenterLocationForm.cs.......................................................................... 97
Ilustração 49 – ClientForm.cs ......................................................................................... 98
Ilustração 50 – ClientMapForm.cs ................................................................................. 99
Ilustração 51 – CommunicationForm.cs ......................................................................... 99
Ilustração 52 – LoginForm.cs ....................................................................................... 100
Ilustração 53 – LoginChanger.cs .................................................................................. 100
Ilustração 54 – MainForm.cs ........................................................................................ 101
Ilustração 55 – OrderForm.cs ....................................................................................... 102
Ilustração 56 – OrderMapForm.cs ................................................................................ 103
Ilustração 57 – ProductForm.cs .................................................................................... 104
Ilustração 58 – RemoveForm.cs ................................................................................... 104
Ilustração 59 – SearchForm.cs...................................................................................... 105
Ilustração 60 – SpecificWorkerForm.cs ....................................................................... 106
Ilustração 61 – Splash.cs .............................................................................................. 107
Page 17
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xv
Ilustração 62 – WorkerForm.cs .................................................................................... 107
Ilustração 63 – main.xml .............................................................................................. 108
Ilustração 64 – worker_list.xml .................................................................................... 109
Ilustração 65 – specific_w.xml ..................................................................................... 110
Ilustração 66 – workerinfo.xml .................................................................................... 110
Ilustração 67 – workerlocation.xml .............................................................................. 111
Ilustração 68 – orderlist.xml ......................................................................................... 111
Ilustração 69 – orderinfo.xml ....................................................................................... 112
Ilustração 70 – orderhistory.xml ................................................................................... 112
Ilustração 71 – GOOGLE_MAPS_CENTERLOCATION.html .................................. 116
Ilustração 72 – GOOGLE_MAPS_CLIENTS.html ..................................................... 117
Ilustração 73 – GOOGLE_MAPS_FORM1.html ........................................................ 118
Ilustração 74 – GOOGLE_MAPS_FORM3.html (calcHistory) .................................. 119
Ilustração 75 – GOOGLE_MAPS_FORM3.html (routeOrder) ................................... 120
Ilustração 76 – Instrução enviada ao estafeta ............................................................... 120
Ilustração 77 – GOOGLE_MAPS_ORDERS.html ...................................................... 121
Ilustração 78 – Carregar ficheiros SQLite .................................................................... 125
Ilustração 79 – Salvaguardar ficheiros SQLite ............................................................. 125
Ilustração 80 – Seleção da localização do centro de monitorização ............................. 126
Ilustração 81 – Receção do comando por parte da unidade de localização móvel ....... 130
Ilustração 82 – Unidade de localização móvel registada com sucesso na base de dados
do centro ....................................................................................................................... 130
Ilustração 83 – Resposta ao pedido de registo da unidade de localização móvel ........ 130
Ilustração 84 – Indicação do tipo de comunicação com o centro ................................. 131
Ilustração 85 – Receção do comando por parte da aplicação Android ......................... 131
Ilustração 86 – Resposta ao pedido de registo do dispositivo Android ........................ 131
Ilustração 87 – Estado da tabela client antes do teste ................................................... 132
Ilustração 88 – Estado da tabela client depois de adicionar um novo elemento .......... 132
Ilustração 89 – Estado da tabela client depois de editar um elemento ......................... 133
Ilustração 90 – Remoção de um elemento da base de dados ........................................ 133
Ilustração 91 – Comando da localização geográfica enviado por uma unidade de
localização móvel ......................................................................................................... 134
Ilustração 92 – Posição no mapa do centro .................................................................. 134
Page 18
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xvi
Ilustração 93 – Posição no mapa Google Earth ........................................................... 135
Ilustração 94 – Correta posição no processamento de um pedido ................................ 136
Ilustração 95 – Incorreta posição no processamento de um pedido ............................. 137
Ilustração 96 – Comando enviado à unidade de localização móvel quando o centro
deteta desvio de rota ..................................................................................................... 137
Ilustração 97 – Menu de configuração para o teste ...................................................... 138
Ilustração 98 – Cópia de segurança do ficheiro de base de dados ................................ 138
Ilustração 99 – Login do funcionário com identificador 2 com a unidade de localização
móvel 1 ......................................................................................................................... 139
Ilustração 100 – Pedido de processamento de encomenda ........................................... 139
Ilustração 101 – Encomenda aceite .............................................................................. 140
Ilustração 102 – Processamento de encomenda concluído com sucesso...................... 140
Ilustração 103 – Logout do funcionário com identificador 2 com a unidade de
localização móvel 1 ...................................................................................................... 141
Ilustração 104 – Ficheiros de instalação do centro de monitorização .......................... 147
Ilustração 105 – Menu de boas vindas do instalador .................................................... 147
Ilustração 106 – Escolher localização .......................................................................... 148
Ilustração 107 – Confirmação da instalação ................................................................. 148
Ilustração 108 – A instalar a aplicação ......................................................................... 149
Ilustração 109 – Instalação bem-sucedida .................................................................... 149
Ilustração 110 – Atalho para a aplicação instalada ....................................................... 149
Page 19
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xvii
Índice de Tabelas
Tabela 1 – Comparação entre as soluções apresentadas................................................. 10
Tabela 2 – Descrição do estado dos LEDs (HOLUX M-1000C) ................................... 20
Tabela 3 – Descrição do estado dos LEDs (CANMORE GT-370F) .............................. 21
Tabela 4 – Descrição do estado dos LEDs (G-SAT BT-328T) ...................................... 22
Tabela 5 – Descrição da trama GGA .............................................................................. 23
Tabela 6 – Comandos AT mais utilizados ...................................................................... 26
Tabela 7 – Descrição do funcionamento do estado dos LEDs ....................................... 28
Tabela 8 – Alguns comandos importantes para implementação do centro .................... 29
Tabela 9 – Métodos do ciclo de vida de uma atividade.................................................. 34
Tabela 10 – Descrição das tabelas constituintes da base de dados ................................. 52
Tabela 11 – Comandos que o centro reconhece provenientes das unidades de localização
móveis ............................................................................................................................. 75
Tabela 12 – Comandos que o centro envia para as unidades de localização móveis ..... 76
Tabela 13 – Comandos que o centro reconhece provenientes dos dipositivos Android 84
Tabela 14 – Comandos que o centro envia à aplicação Android .................................... 85
Tabela 15 – Descrição da tabela user ........................................................................... 122
Page 20
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xviii
Page 21
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xix
Lista de Acrónimos
A-GPS – Assisted Global Positioning System
API – Application Programming Interface
EEPROM – Electrically Erasable Programmable Read-Only Memory
FTP – File Transfer Protocol
GPS – Global Positioning System
GSM – Global System for Mobile Communications
HTML – HyperText Markup Language
HTTP – Hypertext Transfer Protocol
IP – Internet Protocol
KML – Keyhole Markup Language
LED – Light-Emitting Diode
NMEA – National Marine Electronics Association
PC – Personal Computer
PDF – Portable Document Format
RFID – Radio-Frequency IDentification
SMS – Short Message Service
SMTP – Simple Mail Transfer Protocol
SPI – Serial Peripheral Interface Bus
SQL – Structured Query Language
TCP – Transmission Control Protocol
UART – Universal Asynchronous Receiver/Transmitter
USB – Universal Serial Bus
Page 22
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
xx
Page 23
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
1
Introdução
O centro de monitorização de estafetas a implementar está inserido num projeto mais
amplo e completo, o desenvolvimento de um sistema de tracking1. Basicamente este
projeto está dividido em duas partes. A primeira parte é constituída pela implementação
do centro de monitorização que inicialmente utilizará nodos singulares de recetores
GPS. A segunda parte diz respeito ao desenvolvimento de uma unidade de localização
móvel com funcionalidades de tracking. Esta última unidade móvel será desenvolvida
por outro colega, também como tema de dissertação. O objetivo é a integração destas
unidades de localização móveis de baixo custo através do centro de monitorização. É
um projeto que se pretende seja inserido numa empresa de restauração como alternativa
às soluções existentes no mercado.
Por fim, os objetivos gerais deste trabalho são:
Desenvolver um centro de monitorização na qual seja possível conectar uma
diversidade de módulos GPS seja por Bluetooth, USB, etc;
O centro deve ser capaz de comunicar remotamente com recetores GPS através
da comunicação a partir de sockets2 (protocolo TCP/IP) e da rede GSM de forma
a possibilitar a troca de informação/alertas;
Permitir visualizar com recurso a APIs do Google Maps3, a localização de um ou
mais recetores GPS;
Desenvolver uma aplicação gráfica para PC e outra aplicação em Java para
dispositivos Android;
Dotar a aplicação de inteligência, por exemplo, um estafeta tem um percurso a
cumprir e a aplicação deve alertá-lo quando se afasta do trajeto;
O centro deve ser capaz de suportar as unidades de localização móveis.
1 Monitorização, controlo e acompanhamento.
2 Utilizado em ligações de redes de computadores de forma a permitir um elo bidirecional de
comunicação entre dois programas. 3 Serviço de pesquisa e visualização de mapas e imagens de satélite da Terra gratuito na internet fornecido
e desenvolvido pela empresa Google.
Page 24
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
2
1. Motivações
Em termos aplicacionais, o facto dos centros de monitorização que suportam unidades
de localização móveis em tempo real serem ferramentas com grande utilidade,
desenvolvimento e expansão futura. Outro facto muito motivador é saber que existe a
possibilidade de ver este projeto a ser aplicado a uma situação real, isto é, um projeto
que tem grande utilidade no dia-a-dia.
A nível pessoal o facto de existir a possibilidade do projeto poder ser comercializado
num futuro próximo é um dos fatores mais importantes a tomar em conta. É um projeto
que envolve o gosto na área de sistemas embebidos, pela programação e
desenvolvimento de aplicações gráficas. Este projeto irá permitir fortalecer as
competências já adquiridas em quatro anos académicos, bem como adquirir novas
competências na área das comunicações com a utilização de tecnologias como GPS,
GSM, entre outras.
Page 25
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
3
2. Estrutura da Dissertação
O documento está dividido em seis capítulos.
No primeiro capítulo faz-se uma pequena introdução ao projeto que se pretende
desenvolver, bem como são conhecidas as motivações do autor da dissertação e a
estrutura da mesma.
No segundo capítulo apresenta-se uma visão dos produtos existentes no mercado,
estudados alguns centros de monitorização, bem como uma comparação entre eles.
Além disso, é dado a conhecer uma tecnologia denominada de Geofecing.
No terceiro capítulo é realizado o estudo/análise às tecnologias usadas para o seu
desenvolvimento e como será desenvolvido o projeto.
O desenvolvimento do centro é apresentado no quarto capítulo, isto é, implementação
da aplicação em C# e da aplicação para dispositivos que suportem Android.
No quinto capítulo são realizados testes às aplicações desenvolvidas e apresentados os
respetivos resultados.
Finalmente, no sexto capítulo são apresentadas as conclusões finais desta dissertação e
discutido o trabalho futuro.
Page 26
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
4
Page 27
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
5
Estado da Arte
3. Visão geral dos sistemas já existentes no mercado
Atualmente existe no mercado uma grande variedade de sistemas ou centros de
monitorização com funcionalidades comuns às que se pretende implementar. Todos eles
utilizam a tecnologia GPS como modo de obtenção da posição geográfica e geração de
alarmes (por correio eletrónico ou SMS). De notar que grande parte das soluções
encontradas desenvolve o centro de monitorização baseado numa página Web tendo
como principal vantagem o facto de não ser necessário a instalação de qualquer
software e como desvantagem o facto de depender da ligação à internet para conseguir
manter a comunicação com a unidade móvel.
Serão apresentadas de seguida algumas soluções, quer de empresas nacionais como
internacionais. Contudo, é necessário deixar claro que grande parte destas soluções
incluem uma parte de software, o centro de monitorização propriamente dito que requer
um hardware específico (geralmente pertence à própria empresa). Nestes casos, só
serão abordadas as características e funcionalidades relativas ao seu centro de
monitorização.
Page 28
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
6
4. Exemplos de centros de monitorização
4.1. Amplifrota
O Amplifrota é um sistema desenvolvido com base em tecnologia Web aplicada a
veículos dotados de um equipamento recetor de GPS e rede móvel, GSM. Este conjunto
transmite em tempo real ao Amplifrota a localização, direção e velocidade do veículo.
Este centro utiliza o Google Maps para a utilização e interação com mapas, como se
pode ver na Ilustração 1. Relativamente aos dados recolhidos, estes são arquivados
numa base de dados centralizada.
Ilustração 1 – Visão dos recetores GPS (marcadores vermelhos) pelo gestor Amplifrota
Com acesso à internet, o gestor do centro poderá consultar as informações recolhidas
pelos dispositivos móveis. Os dados sobre os veículos são recolhidos via tecnologia
GPS a cada minuto, sendo depois transmitidos através da rede GPRS.
Para ter acesso ao Amplifrota, é necessária a instalação de equipamento móvel
constituído por um recetor GPS e respetivo módulo de comunicações nos veículos que
se pretende monitorizar. Após concluída a instalação e para aceder à área de cliente, são
fornecidas ao cliente as credenciais de acesso (Username, Conta e Palavra-Passe) que o
cliente deverá utilizar caso necessite de verificar o estado da sua frota em tempo real,
definir rotas, verificar históricos de percursos. Também existe a possibilidade de
geração de alertas de entrada e saída de zonas predefinidas, aviso de velocidade
excessiva e condução fora de horas. [2]
Page 29
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
7
4.2. Frotcom
A ideia do centro Frotcom é semelhante ao anterior, ou seja, através de uma pequena
unidade de localização móvel que contém um recetor GPS e módulo de comunicações
GPRS que é instalado nos veículos que se pretende monitorizar. Esta unidade móvel
envia informação ao centro que controla todos os movimentos dos veículos, onde estão,
onde estiveram, quando começaram a jornada, quanto tempo estiveram parados entre
outras coisas.
Com o sistema Frotcom é possível controlar os veículos 24 horas por dia, com dados de
posicionamento GPS e outras informações que são recebidas a cada minuto permitindo
uma monitorização em tempo real. Além disso, este centro utiliza os recursos da Google
Maps para visualizar a posição de determinado veículo. Os dados recebidos pelo centro
são processados tendo o gestor a possibilidade de gerar relatórios bastante
pormenorizados, úteis e de fácil leitura. Estes relatórios podem ser enviados
automaticamente para os endereços de correio eletrónico previamente configurados. No
que diz respeito a situações de alarme, estas quando detetadas são imediatamente
reportadas ao gestor via correio eletrónico ou SMS.
Para aceder ao Frotcom é necessária ter uma ligação à internet e web browser4, pois o
centro de monitorização é baseado numa aplicação Web (não é necessário instalar
software). Contudo, é obrigatório que as unidades de localização móvel instaladas nos
veículos serem da empresa Frotcom, pois o seu centro só suporta esse tipo de unidades
de localização móvel. [3]
Ilustração 2 – Funcionamento do sistema Frotcom
4 É um programa de computador que habilita os seus utilizadores a interagirem com páginas da Web.
Page 30
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
8
4.3. 3dtracking
A tecnologia 3dtracking permite aos seus clientes saber sempre a localização dos seus
bens móveis e assim ter controlo 24 horas por dia, 365 dias ao ano, sobre os mesmos.
Para comercialização a 3dtracking dispõe de vários serviços associados:
O 3dTrack - permite saber a posição e estado dos veículos em tempo real, gerar
rotas bem detalhadas, bem como a utilização de diversos recetores GPS;
O 3dReport - permite obter informação sobre a condução e dados de trabalho de
forma rápida e eficiente (por exemplo, tempos de condução, de chegada,
transgressões, etc). Esta informação pode ser configurada para ser escrita em
forma de relatórios enviados via correio eletrónico de forma automática numa
base diária, semanal ou mensal;
O 3dAlert – mantém o gestor do centro a par de toda a atividade importante dos
veículos. Este tipo de informação é enviado via correio eletrónico ou SMS para o
gestor com o objetivo de ajudar a empresa a prestar um melhor serviço ao seu
próprio cliente, bem como manter um controle mais rígido sobre os seus
funcionários.
Além destes serviços, a 3dtracking presta outros serviços tanto para nível comercial
como para privados, mas estes não são relevantes para esta dissertação. Por fim, tem a
vantagem de suportar diversas unidades de localização móveis. [4]
4.4. LiveGTS
O LiveGTS é basicamente uma página Web baseada em GPS Tracking Software, que
permite-nos construir o nosso próprio servidor GPS de localização de baixo custo. É
possível construir um centro com o nosso nome de domínio, nome da empresa,
logotipo, correio eletrónico de contacto, linguagem e outras informações que os nossos
clientes nem saberão que este software é propriedade da empresa Bofan.
Esta ferramenta on-line apresenta ainda as seguintes características:
Real-Time Tracking – possibilidade de visualizar todos dispositivos móveis em
tempo real;
Page 31
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
9
Various Alarm – suporta uma série de alarmes (SOS, velocidade, bateria baixa,
desvio da rota destinada, entre outros). De salientar que quando um destes
alarmes é ativado é gerada uma mensagem via correio eletrónico para o gestor
do centro ou trabalhador;
History Playback – possibilidade de selecionar um determinado recetor GPS e
visualizar o seu histórico de percursos e tempos. Essa informação pode ser
guardada em ficheiros KML, Excel ou arquivo PDF.
Report – geração de relatórios sobre a atividade de determinados dispositivos
móveis;
Existem outras funcionalidades mas não são relevantes para este trabalho.
Ilustração 3 – Funcionamento de um sistema LiveGTS
Por fim, esta solução requer dispositivos móveis específicos, o que limita muito o
sistema no seu conjunto. [5]
4.5. Outras soluções
Até aqui foram apresentadas algumas soluções de centros de monitorização com base na
tecnologia GPS que se destacavam como os mais importantes. Mas existem outras
soluções que fizeram parte da pesquisa do Estado da Arte, mas por serem demasiado
Page 32
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
10
semelhantes e não se destacarem às apresentadas, não foram descritas e discutidas. E
são elas as seguintes:
Frotasoft da Novatrónica; [6]
N-Auto da Navento; [7]
Gestor de frotas Moviloc; [8]
The NexTraq Platform da NexTraq; [9]
Wialon da Gurtam. [10]
4.6. Comparação das soluções apresentadas
Para melhor perceção do que cada centro é capaz e tecnologias utilizadas é apresentada
a Tabela 1, um resumo/comparação entre todos os sistemas incluindo o centro que se
pretende implementar.
Tipo
de
Aplicação
Tecnologia
de
Aquisição
Mapas
Tipo
de
Rede
Alertas Relatórios
Histórico
de
Percursos
Unidade
Localização
Específica
Amplifrota Web GPS Google
Maps GSM/GPRS Sim Não Sim Sim
Frotcom Web GPS Google
Maps GPRS Sim Sim Não Não
3dtracking Web GPS ? GSM Sim Sim Sim Não
LiveGTS Web GPS
Google
Maps/Bing
Maps
GSM/GPRS Sim Sim Sim Sim
Frotasoft Web GPS Google
Maps GSM/GPRS Sim Sim Sim Sim
N-Auto Web A-GPS Google
Maps GSM/GPRS Sim Não Não Sim
Moviloc Web GPS Google
Earth GSM Sim Não Sim Não
The NexTraq Web GPS Google
Maps GSM Não Não Sim Sim
Wialon Web GPS
Google
Maps/Bing
Maps
GSM Sim Não Sim Sim
Centro
de
Monitorização
PC GPS Google
Maps
GSM
cliente/servidor
TCP/IP
Sim Sim Sim Não
Tabela 1 – Comparação entre as soluções apresentadas
Page 33
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
11
Depois de apresentadas e estudadas as diversas soluções já existentes para o problema a
que esta dissertação se propõe resolver, é necessário refletir sobre as lacunas dos
mesmos de modo a resolve-las.
Em grande parte dos sistemas, o centro de monitorização tem como base uma página
Web, isto faz com que para ter acesso ao centro é indispensável o acesso à internet. Por
exemplo, se a ligação à internet falhar, a comunicação com a unidade de localização
móvel é totalmente perdida. Nesta dissertação, como o centro é baseado numa aplicação
para PC, caso a ligação à internet não exista, o centro irá continuar a comunicar com as
unidades móveis, através da rede GSM e somente são perdidas as funcionalidades
referentes ao Google Maps). Contudo há a consciência que existe a desvantagem da
escolha de desenvolver o centro baseado numa aplicação para PC, isto é, a necessidade
de instalação da aplicação do centro no computador.
Em algumas das soluções, o modo de comunicação entre o centro de monitorização e a
unidade localização móvel é somente realizado por rede GPRS, mas isto levanta um
problema, nem todas as zonas por onde as unidades móveis viajam estão cobertas por
rede GPRS ou acesso a internet, ou seja, o centro pode perder comunicação e total
monitorização e controlo sobre a unidade de localização móvel. Este problema é
resolvido nesta dissertação dotando o centro de monitorização de um cliente/servidor
TCP/IP e modem GSM, ou seja, quando não houver comunicação através do
cliente/servidor TCP/IP, ele optará pela rede GSM.
Page 34
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
12
5. Geofencing
Geofencing é uma tecnologia que se define como um perímetro virtual numa área
geográfica com base em informação de um dispositivo de localização (por exemplo,
GPS). Assim, quando um dispositivo entra ou sai do perímetro definido, uma
notificação será gerada. A colocação de uma vedação fictícia, pode tomar qualquer
forma, desde círculos, retângulos ou um conjunto de coordenadas desde que perfaçam
um perímetro fechado.
Ilustração 4 – Exemplo de formas de perímetros
Esta é uma tecnologia bastante utilizada em sistemas de tracking, tal como o que se
pretende implementar. Aplicado então a centros de monitorização permite ao gestor
configurar a geração de notificações para o caso de uma unidade de localização móvel
entrar ou sair dos limites definidos, dando ao gestor um total controlo sobre o percurso
dessa unidade móvel. Por exemplo, um estafeta tem uma determinada rota a cumprir e a
cada momento que sair do limite definido, o centro é notificado e informará o estafeta
de forma a corrigir o seu percurso. Tudo isto é realizado com base na tecnologia GPS
sendo a localização do recetor registada e transmitida pela unidade móvel.
Page 35
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
13
Ilustração 5 – Geofencing na monitorização de veículos
Para além de ser muito útil nos sistemas de tracking, esta tecnologia pode ser usada em
serviços de localização de crianças em que os pais são notificados sempre que o filho
deixar o perímetro delimitado. Da mesma maneira, esta ideia pode ser aplicada na
agricultura no controlo de animais (por exemplo, rebanhos). Uma aplicação mais
extrema desta tecnologia, é aplicá-la em caso de roubos de veículos em que a ação é a
imobilização total do veículo e possível notificação às autoridades.
Page 36
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
14
Page 37
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
15
Estudo/Análise do sistema a implementar
Neste capítulo é realizado um estudo/análise do sistema que se pretende implementar. É
aqui que será justificada a escolha de todo hardware e software, bem como uma breve
descrição do mesmo. Portanto é feita uma análise às especificações das diversas
tecnologias e dispositivos que irão constituir o centro de monitorização de estafetas.
Todo o estudo/análise levará em conta o cumprimento das restrições e requisitos deste
projeto.
6. Restrições do sistema
Em todos os projetos existem algumas imposições para quem os implementa e o centro
de monitorização de estafetas não foge à regra. Para o centro saber a posição dos seus
estafetas é necessário saber as suas coordenadas espaciais, impondo assim a primeira
restrição. A informação geográfica tem de ser fornecida com base em tecnologia GPS.
O sistema a implementar está dividido em duas partes, por um lado, o servidor que é
onde atuará o centro de monitorização e por outro lado, os clientes que correspondem
aos recetores GPS ou unidades de localização móveis. Para que o conjunto funcione é
necessário haver troca de informação entre as duas partes e daí a segunda restrição deste
sistema, ou seja, a comunicação remota entre o centro e as unidades de localização
móveis é realizada via rede móvel GSM ou pela comunicação a partir de sockets
recorrendo a um servidor com base no protoloco TCP/IP.
Como foi referido no capítulo do “Estado da Arte” já existem no mercado várias
soluções com aspetos semelhantes ao que se pretende implementar. Mas existe uma
limitação comum a todas elas que é o seu elevado preço. Portanto a terceira restrição
desde projeto é o desenvolvimento de um conjunto de baixo custo.
Finalmente existe um tempo para a conclusão deste projeto, no final do semestre do
presente ano letivo a implementação do centro de monitorização baseado em PC de
estafetas deve estar concluída o que representa aproximadamente um ano.
Page 38
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
16
7. Requisitos do sistema
Os requisitos de um projeto não são nada mais que um conjunto de informações
fundamentais para a fase de projeto e implementação de um sistema. São propriedades,
características/funções necessárias a serem consideradas no desenvolvimento do sistema
a implementar.
Como se pretende um permanente controlo sobre os estafetas da empresa de
restauração, existe o requisito de que a monitorização seja em tempo real.
Outro aspeto desejável na implementação do centro de monitorização é a possibilidade
de acompanhamento de um determinado estafeta visualmente, isto é, de o gestor do
centro ser capaz de ver onde está o estafeta num mapa. Isto será possível com o recurso
à API do Google Maps, ferramenta muito utilizada atualmente e cheia de
funcionalidades mesmo para fins comerciais.
No seguimento da necessidade anterior surge um novo requisito, a leitura do histórico
dos percursos de um determinado estafeta tal como um Data Viewer. Este requisito
surge da necessidade do proprietário da empresa de restauração de controlar/monitorizar
tudo o que o seu funcionário fez, por onde circulou durante o seu horário de trabalho
para assim conseguir aumentar os níveis de qualidade e serviço prestado.
Como já foi referido, a implementação deste sistema requer o desenvolvimento de duas
interfaces gráficas, uma que é o centro de monitorização de estafetas para PC e outra a
aplicação para dispositivos Android (por exemplo, para smarthphones que suportem
este sistema operativo) com funcionalidades básicas e informações muito úteis para
quem a utilizar. Sendo assim, é fundamental que estas interfaces gráficas sejam
ambientes bastante intuitivos e apelativos para proporcionar ao utilizador a melhor
experiência possível.
Na maior parte dos sistemas existe sempre a possibilidade de ocorrência de erros, e por
isso é fundamental que das aplicações façam parte indicadores de erros para ser mais
fácil identificá-los de modo a serem corrigidos no menor espaço de tempo. Existem dois
tipos de erros, erros do centro de monitorização, como por exemplo, erros de
comunicação com uma unidade de localização móvel, erros de aquisição de dados, entre
outros. O segundo tipo de erros corresponde a alertas que têm de ser entregues a um
determinado estafeta como por exemplo, alertas sobre a saída de trajeto por parte de um
estafeta.
Page 39
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
17
Como último requisito, o centro de monitorização deve ser capaz comunicar com as
unidades de localização móvel. Isto para ser possível apresentar uma boa solução e
barata às empresas de restauração.
Page 40
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
18
8. Especificação do hardware
Para o desenvolvimento desta dissertação irão ser utilizadas diferentes tecnologias que
estão presentes em determinados tipos de dispositivos. Nesta parte será realizada uma
breve descrição das tecnologias necessárias para a implementação do sistema, sua
importância e também especificação dos dispositivos que contemplam essa tecnologia.
Portanto em termos de tecnologias irão fazer parte:
GPS;
GSM;
RFID.
8.1. GPS
O Sistema de Posicionamento Global popularmente conhecido por GPS foi criado em
1973. É um sistema de navegação por satélite que fornece a um aparelho recetor móvel
a posição e informação horária, sob todas e quaisquer condições atmosféricas, a
qualquer momento e em qualquer lugar na Terra. Para tal o recetor tem que se encontrar
no campo de visão de pelo menos quatro satélites GPS.
Em termos aplicacionais pode-se ver esta tecnologia na aviação geral, comercial e
navegação marítima. Através de um simples recetor GPS qualquer pessoa pode saber a
sua posição, encontrar o caminho para determinado lugar, bem como conhecer a
velocidade, deslocamento e direção. Atualmente estão disponíveis nos automóveis mais
recentes como sistema de navegação de mapas que possibilita uma condução mais
eficaz, segura e económica.
Ilustração 6 – Exemplos de recetores GPS
Page 41
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
19
Estes dispositivos com tecnologia GPS são necessários para este projeto porque são
responsáveis pelo cálculo da posição espacial, ou seja, vai determinar qual a localização
em tempo real de um determinado estafeta.
De modo a usufruir da tecnologia GPS serão obrigatoriamente usados recetores com a
tecnologia GPS. Numa fase inicial serão utilizados nodos singulares de dispositivos
GPS para tornar possível o desenvolvimento do centro enquanto a unidade de
localização móvel não estiver pronta a interagir com o centro.
Em termos de recetores GPS a utilizar durante a prototipagem deste projeto, temos os
seguintes recetores:
Holux M-1000C;
CANMORE GT-370F;
G-SAT BT-328T;
U-BLOX LEA 5S (Unidade de localização móvel).
Recetores GPS
Holux M-1000C
Este dispositivo com tecnologia GPS (Ilustração 7) apresenta uma precisão abaixo dos 3
metros, pode atingir as 28 horas de funcionamento e ainda pode comunicar com cerca
de 66 satélites em simultâneo. É composto por três LEDs que ajudam a perceber o seu
funcionamento (ver Tabela 2).
Page 42
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
20
LED Cor Estado Descrição
Bluetooth Azul Intermitente
1 vez de 1em 1s Procurar dispositivos Bluetooth
1 vez de 1em 1s Modo de suspensão
1 vez de 3 em 3s Transferência de dados
Bateria
Vermelho Ligado Carga fraca
Verde Ligado A carregar
N/A Desligado Bateria cheia ou não está a ser carregada
GPS Cor de laranja
Ligado A obter sinal
Intermitente 1 vez de 1em 1s Posição fixa
Tabela 2 – Descrição do estado dos LEDs (HOLUX M-1000C)
A interface deste recetor é Bluetooth no entanto é compatível com o perfil da porta-
série. Ainda é capaz de armazenar mais de cem mil pontos geográficas através da sua
memória flash de 2MBytes e suporta o protocolo de dados NMEA 0183.
Ilustração 7 – Holux M-1000C
Por fim, a aquisição de sinal pode demorar até 33 segundos enquanto o tempo de re-
aquisição é inferior a 1 segundo. [11]
Page 43
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
21
CANMORE GT-370F
O GT-370F representado pela Ilustração 8 tem interface USB, suporte para A-GPS5
(Assisted-GPS) e protocolo NMEA 0183. No que toca à sua precisão, esta é inferior a 5
metros. Apresenta a desvantagem de não possuir fonte de alimentação interna mas
consegue comunicar com 65 satélites. É composto por um LED sendo o seu
comportamento descrito na Tabela 3.
Estado Função
Desligado Recetor não conectado
Intermitente Posição fixa
Ligado A obter sinal
Tabela 3 – Descrição do estado dos LEDs (CANMORE GT-370F)
É capaz de armazenar mais de duzentos e cinquenta mil pontos GPS através de 2MBytes
de memória flash. Por fim, a aquisição de sinal demora menos de 30 segundos e o
tempo de reaquisição é inferior a 1 segundo. [12]
Ilustração 8 – CANMORE GT-370F
G-SAT BT-328T
Este último recetor GPS representado pela Ilustração 9 é composto por uma bateria
recarregável com uma autonomia com cerca de 16 horas e suporta o protocolo NMEA
0183. Quanto à sua precisão da posição adquirida, esta é inferior a 10 metros. É capaz
de comunicar somente com cerca 12 satélites em simultâneo. Ainda, é composto por
três LEDs que ajudam a compreender o seu funcionamento (ver Tabela 4).
5 Sistema que melhora o desempenho de inicialização de um recetor GPS, pois recebe dados de suporte
através de uma conexão de dados, ou seja, ajuda o recetor GPS a calcular as coordenadas da sua posição.
Page 44
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
22
LED Cor Estado Descrição
Bluetooth Azul Intermitente
1 vez de 3em 3s Procurar dispositivos Bluetooth
1 vez de 1em 1s Transferência de dados
Bateria
Vermelho Ligado Carga fraca
Amarelo Ligado A carregar
N/A Desligado Bateria cheia ou não está a ser carregada
GPS Verde
Ligado A obter sinal
Intermitente Posição fixa
Tabela 4 – Descrição do estado dos LEDs (G-SAT BT-328T)
A aquisição de sinal deste dispositivo é inferior a 42 segundos e o tempo de reaquisição
de sinal inferior a 100 milissegundos. Por fim, o interface de comunicação deste recetor
é por Bluetooth e compatível com o perfil da porta-série.
Ilustração 9 – G-SAT BT-328T
Protocolo NMEA 0183
O NMEA 0183 é o protocolo mais usado em dispositivos de navegação com tecnologia
GPS incorporada, tal como os anteriores recetores especificados. Criado pela agência
norte americana Nacional Marine Electronics Association, basicamente este protocolo
está definido para ser usado em transmissões série com um baud-rate de 4800 bps onde
toda a comunicação é efetuada através de tramas representadas por carateres ASCII. As
tramas podem ser constituídas por dados relativos à posição, velocidade, altura e entre
outros. [13] Essas tramas seguem um conjunto de regras:
Page 45
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
23
O início da string começa sempre com o símbolo “$”;
Os próximos cinco carateres indicam a origem da mensagem (dois para a origem
e três para o tipo de mensagem);
Todos os campos de dados estão separados por vírgulas;
Quando não há dados disponíveis o campo recebe um byte nulo (por exemplo,
"123,,456");
O primeiro caractere do último campo deve ser um “*”;
A mensagem é terminada com um “nova linha”, <CR>, <LF> ou "\n".
Por exemplo, uma mensagem de aviso de chegada tem a forma:
$GPGGA,092750.000,5321.6802,N,00630.3372,W,1,8,1.03,61.7,M,,,,*76
Onde:
GP ID do remetente (GP para uma unidade de GPS)
GGA Horas, posição e dados recebidos relativos à posição
092750.000 Horas
5321.6802 Latitude
N Norte ou Sul
00630.3372 Longitude
W Este ou Oeste
1 Qualidade do sinal GPS
8 Número de satélites
1.03 Diluição horizontal da precisão
61.7 Altitude da antena
M Unidade da altitude da antena
Tabela 5 – Descrição da trama GGA
8.2. GSM
O Global System for Mobile communications (GSM) é o padrão mais conhecido para
telemóveis no mundo. Com este sistema é possível o roaming internacional e
diferencia-se das tecnologias anteriores na medida em que os sinais e canais de voz são
digitais.
Dado que o centro de monitorização estará alocado num local fixo e os estafetas estarão
a andar pelas ruas a fazer as suas entregas, é necessário garantir a comunicação entre o
Page 46
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
24
centro de monitorização e eles no caso de não ser possível implementar o
cliente/servidor TCP/IP. Daí a importância da tecnologia GSM para o projeto atuando
como um plano B, de modo a manter a comunicação.
Ilustração 10 – Exemplos de Modem GSM/GPRS
Para implementar este plano B, terá de ser parte constituinte do centro um modem GSM
de modo a manter a comunicação remota entre o centro de monitorização e o lado
cliente (qualquer um dos estafetas). Assim continuará a ser possível a troca informação
sobre a sua posição e outras informações importantes para qualquer um dos dois
agentes. O modem escolhido para desempenhar esta função foi um modem da Telit, o
EZ10-GPRS.
Modem GSM
Telit EZ10-GPRS
O modem representado na Ilustração 11 é produto da Telit Communications S.p.A e
oferece uma completa solução para aplicações M2M (Machine to Machine) sem fios. Na
comunicação rádio o dispositivo suporta até duas gamas de frequências GSM (Dual
band), sendo elas a GSM 900 e 1800. Ainda oferece serviços de voz e dados
importantes sobre a rede GSM, bem como todos os módulos da Telit. É diretamente
controlado por interface RS-232 e a tensão de alimentação está entre os 9 e 24 volts de
corrente contínua.
Ilustração 11 – Telit EZ10-GPRS
Page 47
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
25
Este modem é controlado e configurado através de diversos comandados AT. Por fim, é
composto por portos de entrada e saída programáveis permitindo a conexão de sensores
úteis para uma determinada aplicação. [14]
Comunicação com o modem via comandos AT
A troca de informação entre o centro (lado servidor) e o modem ligado por porta-série é
realizado via comandos AT. São uma linguagem de comandos orientados por linhas, na
medida em que cada comando é constituído por três elementos:
o prefixo – consiste nos caracteres “AT”, com exceção do comando “A/”;
o corpo do comando – é constituído por caracteres singulares;
o caracter terminação – consiste num caracter que indica o fim da linha ou
comando (por defeito corresponde ao caracter “<CR> – Carriage-Return” ou
0x0D).
Comandos AT mais utilizados
Nesta fase são demostrados comandos AT importantes e que farão parte da
implementação da comunicação com o estafeta via GSM, como por exemplo enviar e ler
um SMS.
Comando Função
AT<CR> Verificar a comunicação com o modem.
AT+IPR=<rate><CR>
Definir o baud rate da porta-série.
<rate>, poder ser:
0, 300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200.
AT+CMEE=<valor><CR>
Habilitar ou desabilitar o relatório de erros.
<valor>, pode ser:
0 – desabilitar o relatório de erros;
1 – habilitar o relatório de erros (formato numérico);
2 – habilitar o relatório de erros (formato texto).
AT+CPIN<CR> Verificar a existência e estado do cartão SIM.
AT+CPIN=****<CR> Fornecer o código PIN do cartão SIM.
**** – Código PIN do cartão.
AT+CREG<CR> Verificar o estado da rede.
AT+CSQ<CR> Verificar a força e qualidade do sinal.
AT+CMGF=<mode><CR>
Modo de texto da SMS.
<mode>, pode ser:
0 – modo PDU (Protocol Data Unit);
1 – modo texto.
Page 48
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
26
AT+CNMI=<mode>,<mt>,
<bm>,<ds>,0<CR>
Conjunto de comandos para selecionar o comportamento do modem no caso de receção de novos
SMSs.
<mode>, pode ser:
0, 1 ou 2.
<mt>, pode ser:
0, 1, 2 ou 3.
<bm>, pode ser:
0 ou 2.
<ds>, pode ser:
0, 1 ou 2.
AT+CMGS=<da><CR>
Enviar SMS.
Esperar pelo caracter “>”.
Escrever o corpo da mensagem (160 caracteres).
Acabar com o “CTRL-Z” (0x1A).
AT+CMGD=<index><CR> Eliminar uma determinada SMS.
Índice do SMS que pretende eliminar.
AT+CMGR=<index><CR> Ler uma determinada SMS.
Índice do SMS que pretende ler.
AT+CMGL=<stat><CR>
Ler um conjunto de SMSs.
<stat>, pode ser:
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 escrioas enviados;
ALL – ler todos SMSs.
Tabela 6 – Comandos AT mais utilizados
8.3. RFID
Radio Frequency IDentification é um modo de identificação automática com recurso a
sinais rádio. Nesta tecnologia existem dois intervenientes, o transmissor e o recetor que
geralmente são etiquetas RFID onde dados enviados pelo transmissor são remotamente
armazenados. Uma etiqueta RFID é um pequeno objeto que pode ser colocado em
pessoas, objetos, etc. Esta tecnologia tem atualmente vasta aplicação, como por
exemplo, o uso em veículos para o pagamento de parques ou portagens.
Page 49
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
27
Ilustração 12 – Exemplo da utilização da tecnologia RFID
No sistema a implementar nesta dissertação é desejável ter esta tecnologia para que seja
possível escrever de uma forma eficaz e rápida, nas etiquetas pertencentes aos estafetas
que precisam delas para fazerem login na unidade de localização móvel. Por
consequência, o centro de monitorização deverá possuir um módulo RFID e os estafetas
terão etiquetas RFID de modo a individualizar cada um. As etiquetes serão escritas pelo
gestor do centro. O módulo escolhido para desempenhar estas funções foi o SSRFID
v1.0 e a etiquetas foram as Mirafe MF1 IC S50.
Módulo RFID (Leitor + Etiquetas)
SSRFID v1.0
O módulo representado na Ilustração 13 (lado esquerdo) é baseado em MFRC522
(integrado de leitura/escrita de comunicação com as etiquetas suportadas). Fornece
diversos comandos compactos para o utilizador facilmente ler e escrever nas etiquetas.
Esta comunicação entre o módulo e o utilizador e vice-versa é possível através da
interface UART ou SPI. A interface de comunicação a ser utilizada nesta
implementação, será a UART em que o baud rate pode estar entre os 2400 bps e 115200
bps. Segundo o datasheet6, este módulo tem as seguintes definições por defeito:
baud rate – 9600 bps;
parity bit – Não;
start bit – 1;
data bit – 8;
stop bit – 1.
6 Documento que apresenta todos os dados e características técnicas de um equipamento ou produto.
Page 50
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
28
No que diz respeito a etiquetas, este módulo suporta as etiquetas Mirafe One S50, S70,
Mifare_UltraLight, Mirafe_Pro e Mirafe_DESFire. Estas etiquetas devem estar a
menos de 50 mm de distância do módulo RFID para ser possível estabelecer
comunicação e evitar falhas entre eles. Neste módulo faz parte uma memória EEPROM
de 8 KBytes de fácil acesso e que protege a informação de configuração contra falhas de
energia. Quanto à tensão de alimentação deste módulo pode variar entre os 4,5 e 5,5
volts, sendo que o recomendado são 5 volts.
O SSRFID v1.0 é constituído por três LEDs que ajudam a perceber o estado do módulo
e são eles: o STATE LED, CARD LED e MODE LED e as suas funções estão descritas
na Tabela 7.
LED Função
STATUS
LED
Enquanto o módulo está alimentado, STATUS LED está ligado. Se o módulo executa um comando com sucesso,
STATUS LED pisca uma vez, senão pisca quatro vezes.
CARD LED Enquanto o módulo deteta uma etiqueta, o CARD LED acende. Quando a etiqueta deixa a área de deteção, o CARD
LED apaga.
MODE
LED
O MODE LED está ligado quando se utilizar o modo Compact Command e desligado quando se utilizar o modo
Basic Command.
Tabela 7 – Descrição do funcionamento do estado dos LEDs
Basic Command
Neste módulo para se comunicar com as etiquetas existem dois tipos de comandos, o
Compact Command e o Basic Command que irão ser os utilizados e por isso descritos
nesta fase. Deste modo, importa primeiro mostrar e explicar o formato deste tipo de
comandos:
Cabeçalho – para este tipo de comandos, o cabeçalho é sempre 0xAB;
Tamanho – Ocupa 1 byte e corresponde ao número de bytes desde o campo Tamanho
(incluído) até ao último byte do campo Data;
Instrução – Ocupa 1 byte e corresponde ao identificador para uma determinada função
que se pretende executar;
Cabeçalho + Tamanho + Instrução + Dados
Page 51
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
29
Data – Depende do comando porque em alguns comandos este campo não necessita de
ser preenchido.
Compreendido o formato dos comandos do tipo Basic Command, irão ser especificados
alguns dos comandos importantes e que farão parte da implementação desde centro.
Instrução Função Formato
0x01 Ler o tipo de etiqueta.
Comando: AB 02 01
Resposta:
Sucesso – AB 04 01 [tipo de etiqueta];
Insucesso – AB 02 FE/FC.
0x02 Procurar e ler nº de série da etiqueta.
Comando: AB 02 02
Resposta:
Sucesso – AB 06 02 [nº de série];
Insucesso – AB 02 FD/FF.
0x03 Ler dados duma etiqueta.
Comando: AB 0A 03 [nº do bloco] [tipo de chave] [chave]
Resposta:
Sucesso – AB [tamanho] 03 [dados];
Insucesso – AB 02 FC.
0x04 Escrever dados numa etiqueta.
Comando: AB 1A 04 [nº do bloco] [tipo de chave] [chave] [dados]
Resposta:
Sucesso – AB 02 04/06;
Insucesso – AB 02 FB/F9.
Tabela 8 – Alguns comandos importantes para implementação do centro
MF1 IC S50
A etiqueta presente na Ilustração 13 (lado direita) é da família Mirafe One S50
suportada pelo módulo RFID acima apresentado. Esta etiqueta não tem qualquer tipo de
fonte de energia e funciona a uma frequência de 13,56 MHz.
Ilustração 13 – SSRFID v1.0 + Etiqueta MF1 IC S50
É constituída por uma memória do tipo EEPROM de 1 KByte organizada em 16
sectores com 4 blocos de 16 bytes cada (Ilustração 14) e o seu ciclo de vida ronda os
100 mil ciclos.
Page 52
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
30
Ilustração 14 – Organização da memória EEPROM
8.4. Unidade de Localização Móvel
Anteriormente foram especificados os dispositivos e tecnologias que o centro de
monitorização deverá suportar. Mas como já foi referido anteriormente, do lado do
cliente existirá uma unidade de localização móvel que deverá possuir as mesmas
tecnologias. Esta unidade móvel irá ser desenvolvida por um colega e depois conectada
ao centro de monitorização de estafetas que se pretende desenvolver. Esta unidade
móvel terá todas as tecnologias atrás referidas, GPS, GSM e RFID, bem como interface
USB, Bluetooth e rede móvel GPRS para ser possível a conexão cliente/servidor
TCP/IP. Basicamente cada estafeta terá uma unidade de localização móvel (ver
Ilustração 15) que através do módulo GPS calculará a posição espacial. Essa informação
é enviada de modo periódico para o centro de.
Ilustração 15 – Protótipo da unidade de localização móvel
Page 53
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
31
9. Especificação de software a utilizar
Nesta parte é especificado o software indispensável à produção do centro de
monitorização, interfaces com utilizador, linguagens de programação a utilizar, bem
como a definição dos subsistemas para o funcionamento do centro no seu todo.
Portanto em termos de especificações de software irão fazer parte:
as interfaces com o utilizador;
o recurso a base de dados;
o recurso a um Cliente/Servidor com base no protocolo TCP/IP;
o recurso à API do Google Maps;
os subsistemas de software (aquisição e tratamento de dados, comunicação e
deteção de erros e alertas).
9.1. Interface com o utilizador
Teremos então duas interfaces com o utilizador, uma para PC desenvolvida em C# e
outra para dispositivos Android.
C#
O C# é uma linguagem de programação proposta pela Microsoft, para o
desenvolvimento de aplicações. Lançada em conjunto com a plataforma .Net7 é uma
linguagem orientada a objetos, simples e que permite desenvolver software com grande
robustez. Esta linguagem a par da introdução de inovações ao nível da orientação aos
componentes e da programação declarativa com atributos, tira total partido dos serviços
de segurança, da compilação just-in-time, da gestão automática de memória e de um
conjunto vasto de bibliotecas da plataforma .Net. [15]
Esta linguagem tem as seguintes principais características:
Orientada a objetos;
Robusta;
7 Iniciativa da empresa Microsoft, que visa uma plataforma única para desenvolvimento e execução de
sistemas e aplicações.
Page 54
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
32
Moderna;
Familiar.
Em suma, o desenvolvimento do centro de monitorização de estafetas baseado em PC
será implementado na linguagem C# com recurso ao Microsoft Visual C# como
ferramenta de desenvolvimento. É objetivo criar uma aplicação gráfica robusta,
moderna e apelativa (baseada nas aplicações para PC atuais) de modo a proporcionar
uma ótima experiência ao utilizador e acima de tudo atingir os objetivos propostos.
Sistema Operativo Android
O Android é um sistema operativo que corre sobre o núcleo Linux. Inicialmente
desenvolvido pela Google e posteriormente pela Open Handset Alliance, sendo a
Google responsável pela gestão do produto e engenharia de processos. O Android
permite aos programadores desenvolverem aplicações na linguagem de programação
Java [16], controlando o dispositivo através de inúmeras bibliotecas desenvolvidas pelo
Google. Para ter uma ideia de como o desenvolvimento Android foi bem aceite, no
início de 2012 existiam mais de 400 mil aplicações disponíveis para este sistema
operativo.
No que diz respeito à arquitetura do sistema operativo Android, ela está dividida em
várias camadas, onde cada uma é responsável por gerir os seus processos. [17]
Ilustração 16 – Camadas do SO Android
Page 55
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
33
Assim, o ambiente Android está dividido nas seguintes camadas (ver Ilustração 16):
Linux Kernel - Inclui os serviços essenciais do sistema, como por exemplo,
segurança dos arquivos, gestão de memória, threads, gestão de processos,
protocolos de rede e diversos drivers de hardware;
Libraries - Possui um conjunto de bibliotecas C/C++ usadas por diversos
componentes do sistema, bibliotecas multimédia, visualização de camadas 2D e
3D, funções para navegadores Web e funções de acesso à base de dados SQLite;
Android Runtime - Nesta camada instancia-se a máquina virtual Dalvik, criada
para cada aplicação executada no Android. Essa máquina virtual é considerada a
melhor quanto ao desempenho e à integração com a nova geração de hardware e
é projetada para executar vários processos paralelamente;
Application Framework - foi desenvolvida para simplificar a reutilização dos
componentes. Assim sendo, qualquer projetista pode construir uma aplicação e
disponibilizar as suas potencialidades, permitindo que sejam utilizadas por
outros programas. Esta camada disponibiliza inúmeras APIs usadas em
aplicações centrais que facilitam a criação e desenvolvimento de aplicações;
Application - encontram-se todas as aplicações que são executadas sobre o
sistema operativo, tais como, browser, calculadora, correio eletrónico, SMS e
MMS e entre outros.
Entender o que são as atividades é fundamental para o bom entendimento do
funcionamento das aplicações Android. Deste modo, elas representam uma classe com
elementos a serem executados assim que são chamados. Cada atividade tem um ciclo de
vida associado, desde a sua criação até ao momento do término da aplicação. Esse ciclo
de vida está retratado na Ilustração 17.
Page 56
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
34
Ilustração 17 – Ciclo de vida de uma atividade
Na Ilustração 17 pode-se visualizar como é o ciclo de vida de uma atividade e os vários
métodos que estão descritos na Tabela 9.
Método invocados Descrição
OnCreate A atividade é iniciada.
OnStart A aplicação fica visível para o utilizador.
OnResume A atividade vai iniciar a interação com o utilizador.
OnPause O sistema está prestes a retomar outra atividade.
OnStop A atividade deixar de estar visível para o utilizador.
OnDestroy A aplicação já terminou, ou quando o sistema necessita de finalizar uma atividade.
OnRestart Após a atividade ser parada e antes de ser reiniciada.
Tabela 9 – Métodos do ciclo de vida de uma atividade
Page 57
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
35
A atividade é representada através de um ecrã na aplicação, ou seja, para cada atividade
existe um interface gráfico de utilizador composto por views8, componentes gráficos,
eventos entre outros componentes.
Além das atividades, outro componente muito utilizado nas aplicações Android são os
Intents. Têm muita utilidade para o programador porque permitem-lhe enviar uma
solicitação para o sistema operativo e executar processos, como por exemplo:
fazer uma ligação;
enviar uma SMS;
solicitar a abertura de outra aplicação;
solicitar outras atividades.
Para além destes componentes, mas não tão importantes existem:
Intent Filter – utilizado para mapear a ação de um Intent;
Services – utilizado para criar um serviço que é executado em background;
Content Providers – permite compartilhar informações para que qualquer outra
aplicação possa utilizá-las;
Broadcast Receivers – utilizado para executar as solicitações feitas pelos Intent.
Será desenvolvida uma aplicação gráfica para dispositivos que suportem o sistema
operativo Android. Esta aplicação será vista como uma miniatura cliente do centro de
monitorização para PC, ou seja, será uma aplicação simples e apelativa com a
informação útil necessária a quem a utilizar.
8 Fornece classes que expõem as classes básicas do interface com o utilizador que lidam com layout de
um ecrã.
Page 58
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
36
9.2. Base de dados
SQLite
SQLite é uma biblioteca na linguagem C que implementa uma base de dados
SQL embutido na própria aplicação (local), isto é, esta biblioteca lê e escreve
diretamente para e de um único ficheiro que constitui a base de dados.
Esta biblioteca é recomendada onde a simplicidade da administração, implementação e
manutenção são mais importantes. A SQLite é um software livre, multiplataforma e
seguro que não necessita de instalação, configuração ou administração. Além disso,
implementa a maioria do SQL92, não tem dependências externas e tem capacidade para
suportar bases de dados inferiores a 2 TBytes. [18]
Alguns exemplos do uso de SQLite:
Website com menos de cem mil acessos por dia;
Dispositivos e sistemas embebidos;
Aplicações desktop.
Não se recomenda o uso do SQLite:
Para fins que envolvam grandes volumes de acessos;
Grandes quantidades de dados;
Sistemas com grande concorrência.
Portanto, o centro de monitorização vai recorrer a uma base de dados local SQL, do tipo
SQLite com a função de gerir os dados de tabelas, como por exemplo, tabelas de
estafetas, coordenadas, clientes, entre outras estruturas de dados.
Esta opção deve-se ao facto da grande vantagem deste centro relativamente a outros
produtos existentes no mercado (ver Tabela 1), ser um funcionário contínuo com ou
sem acesso à rede internet. Assim, mesmo que haja ou não acesso à rede internet a base
de dados local (SQLite) estará sempre ativa com o centro a fazer cópias de segurança
Page 59
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
37
automaticamente ou manualmente. Tudo isto para a implementação de um sistema de
monitorização seguro e barato.
9.3. Protocolo TCP/IP
É o principal protocolo para transmissão de dados entre máquinas em rede e pode ser
visto como um tipo de idioma que permite às aplicações conversarem entre si. O
TCP/IP surge da interligação de dois protocolos, o TCP com o IP. Deste modo, a junção
destes dois protocolos pode ser encarada como uma espécie de modelo de camadas em
que cada camada é responsável por um conjunto de tarefas. Este protocolo está dividido
num grupo de quatro camadas, a camada de aplicação, de transporte, de rede e interface
de forma a garantir a integridade da informação transmitida.
Ilustração 18 – Conjunto de camadas do protocolo TCP/IP
Aplicação
A camada de aplicação é usada pela maioria dos programas quando pretendem enviar
ou receber dados de outros programas através de uma rede. Nesta rede fazem parte
protocolos como o SMTP para correio eletrónico, FTP para transferência de ficheiros e
o mais que conhecido HTTP para navegação na internet. Depois de a informação ser
processada por esta camada, ela é enviada para a camada imediatamente abaixo, ou seja,
a camada de Transporte.
Page 60
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
38
Transporte
Esta camada é responsável pela receção da informação enviada pela camada de
aplicação, fazer a verificação da sua confiabilidade (saber se a informação chegou ao
seu destino) e integridade (saber se chegaram na ordem correta). Seguidamente os dados
são separados em vários pacotes e encaminhados para a próxima camada, a camada de
Rede.
Rede
A camada de Rede é responsável por anexar os pacotes recebidos pela camada acima ao
endereço virtual da máquina remetente e destinatária, ou seja, basicamente tem a tarefa
de endereçar os pacotes de dados.
Interface
Por último, a camada de Interface tem a função de receber e enviar os pacotes
endereçados da camada anterior pela rede. Os protocolos utilizados nesta camada vão
depender do tipo de rede (por exemplo, Ethernet) que é utilizado neste procedimento.
Sendo assim, uma das possibilidades para conseguir trocar informações entre o centro
de monitorização e a unidade de localização móvel é através da utilização de um
cliente/servidor TCP/IP a partir do envio de pacotes.
Modelo cliente/servidor TCP/IP (sockets)
Grande parte das aplicações da internet utilizam o modelo cliente/servidor como forma
de interação. Cliente é um programa que basicamente solicita informações/dados a
outro programa que está do lado servidor. Servidor é um programa que aguarda
solicitações por parte de clientes, ou seja, aceita e responde a pedidos realizados do lado
dos clientes.
Page 61
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
39
Ilustração 19 – Modelo Cliente/Servidor
As aplicações do tipo cliente caracterizam-se por estabelecerem ligação com o servidor,
aguardam resposta ao seu pedido, efetuam as ligações quando desejarem (não estão
permanentemente ligados ao servidor) e podem ter endereços IP dinâmicos.
Por outro lado, as aplicações do tipo servidor são do tipo proativo, isto é, aguardam por
pedidos por parte dos clientes. Quando recebem um pedido, o servidor processa-o e
envia a resposta podendo interagir com mais do que um cliente ao mesmo tempo. Além
disso, o servidor deve estar sempre ligado e de preferência com um endereço IP fixo.
Relativamente aos sockets, estes são uma interface fornecida e controlada pelo sistema
operativo e criada a partir de solicitações a partir de aplicações para que os respetivos
processos possam envia/receber dados de/para outros processos. O socket é constituído
por dois identificadores, o endereço IP (indica o local de um nó numa rede) e a porta
(número que identifica um canal de dados entre o cliente e o servidor).
Para ser possível implementar um cliente/servidor TCP/IP com recurso a sockets é
necessário que do lado do cliente seja criado um socket TCP, estabelecer ligação com o
servidor através do seu endereço IP e respetiva porta. Assim, o cliente já pode fazer os
pedidos que bem entender, desde que ao concluir a comunicação feche a ligação com o
servidor. Do lado do servidor, este deve também criar um socket TCP, atribuir uma
porta para esse socket. Seguidamente, deve colocar o socket à escuta e de forma
repetida, aceitar novas ligações feitas por diversos clientes, receber e responder aos
pedidos e no final fechar a ligação.
Page 62
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
40
Ilustração 20 – Modelo cliente/servidor TCP/IP
A Ilustração 20 demostra o modelo de cliente/servidor que se pretende adotar para o
sistema a implementar, ou seja, o centro de monitorização será o servidor que terá um
endereço IP e uma porta associada. Assim, ele ficará à escuta de pedidos por parte dos
clientes, ou seja, das unidades de localização móveis que se conectem através do
endereço IP e porta correspondentes ao servidor implementado no centro. Finalmente,
esta possibilidade pode ser levada a cabo para o caso de tanto o centro como a unidade
de localização móvel tiverem acesso à rede internet. Para o caso de um dos agentes não
satisfazer essa condição, existe um plano B para que o centro continue a comunicar com
as unidades de localização móveis, ou seja, através de comunicação por rede GSM.
9.4. Google Maps
O Google Maps é um serviço de pesquisa e visualização de mapas e imagens de satélite
da Terra. Foi desenvolvido pela empresa Google que fornece este serviço de forma
gratuita. O Google Maps nasceu dia 8 de Fevereiro de 2005 como versão beta e tornou-
se muito depressa a maior referência e novidade que a internet começa a viver.
Com uma interface rica e intuitiva, a aplicação permitia acesso a uma enorme base de
dados contendo uma infinidade de mapas de cidades, bairros, ruas e avenidas em
algumas partes do globo. Em Novembro de 2008, foi quando o Google Maps começou a
permitir consultas de localizações em Portugal. Passado um mês, a versão completa foi
Page 63
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
41
lançada para o público em geral, em português e com a possibilidade de se localizar
restaurantes, hotéis, traçar rotas, entre outras funcionalidades.
Atualmente grande parte de páginas da internet utiliza funcionalidades dos mapas do
Google no seu conteúdo, desde a geração de pontos de interesse, caminhos para
determinado sítio e ainda a simples localização de estabelecimentos comerciais ou
ponto turísticos. Tudo isto é possível através do Google Maps API.
Em Junho de 2005 foi lançada a primeira versão da API e desde aí, as suas
funcionalidades foram melhoradas e algumas novas adicionadas. Atualmente não existe
só uma API (anteriormente só para JavaScript), mas um conjunto de APIs perfazendo a
Família do Google Maps API que permite que se incorpore a funcionalidade robusta e a
grande utilidade do Google Maps a páginas Web e aplicações a diferentes ambientes e
necessidades. Esta família é composta pela:
Google Maps JavaScript API – a mais utilizada atualmente;
Google Maps API for Flash;
Google Earth API;
Google Static Maps API;
Google Maps Data API;
Google Maps API Web Services.
Estas APIs consistem num conjunto de classes dependendo da família da API que
fornecem a interface necessária para que o programador possa desenvolver aplicações
para exibir mapas, realizar consultas por endereços, realizar funções de zoom,
acrescentar pontos de referência, entre outras possibilidades. [19]
Portanto, dentro do que se pretende implementar para o centro, o Google Maps vai
permitir a visualização da posição de uma determinada unidade de localização móvel
que esteja na posse de um estafeta, possibilitar traçar os melhores caminhos para o
percurso do estafeta, bem como ser possível ver o histórico de cada estafeta no mapa.
Page 64
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
42
9.5. Subsistemas de software
São subsistemas importantes a serem implementados com o objetivo de proporcionar a
perfeita interação entre o centro de monitorização e as unidades de localização móveis.
Foi então analisado o que se pretende implementar e chegou-se à conclusão que são
necessários quatro subsistemas de software:
Aquisição de dados;
Tratamento de dados;
Comunicação;
Deteção de erros e alertas.
Aquisição de dados
No centro de monitorização será implementado um subsistema de aquisição de dados
provenientes das unidades de localização móveis. Basicamente existem dois tipos de
aquisição:
Aquisição periódica;
Aquisição on-demand.
O primeiro tipo de aquisição vai assentar na obtenção de dados da unidade de
localização móvel com uma determinada frequência. Esses dados são informações
importantes para a atualização do centro de monitorização de forma a cumprir a
monitorização em tempo real de um determinado estafeta em serviço.
No que diz respeito ao segundo tipo de aquisição, consiste na obtenção de dados da
unidade de localização móvel mas de forma não periódica. Este tipo de aquisição existe
para o caso de o gestor do centro querer obter dados não pertencentes à aquisição
periódica, isto é, determinadas informações sobre o trabalho do estafeta ou querer
antecipar a obtenção de dados periódicos.
Page 65
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
43
Tratamento de dados
O tratamento de dados é um subsistema que segue o subsistema de aquisição, ou seja,
depois de o centro adquirir informações provenientes da unidade de localização móvel
tem de existir um subsistema que interprete e processe essas informações recebidas.
Imagine-se que o centro obteve dados relativas à localização geográfica de um dado
estafeta, latitude e longitude. O centro lê essa informação, processa esses dados e um
possível processamento é a criação ou atualização de um mapa referente à posição do
estafeta em questão.
Comunicação
O subsistema da comunicação é o responsável por garantir a comunicação entre o centro
de monitorização (lado servidor) e as unidades de localização móveis (lado cliente). É
através dele que vai ser possível a troca de informação entre os dois lados através da
rede móvel GSM ou GPRS, dependendo da cobertura de sinal. Basicamente depois de
estabelecida a ligação entre o cliente e o servidor, este subsistema fica responsável por
receber pedidos por parte do cliente ou enviar de pedidos às unidades de localização
móvel.
Deteção de erros e alertas
É muito importante para este sistema a deteção dos erros ou alertas porque é essencial
haver sempre comunicação entre os dois agentes deste sistema e que a informação
resultante dessa comunicação seja válida e processada de forma correta. Assim, haverá
três tipos de erros e outros três alertas:
Em termos de erros:
o Erros de aquisição – basicamente correspondem a informação obtida
pelo centro mas que não sejam válidos (por exemplo, o sistema tem que
verificar se os dados obtidos são válidos);
o Erros de tratamento – correspondem a informação recebida pelo sistema,
mas que depois de recebida, o resultado do processamento não
corresponda ao esperado (por exemplo, o estafeta está muito afastado do
seu trajeto e não recebeu um alerta sobre o sucedido, mas deveria);
Page 66
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
44
o Erros de comunicação – é qualquer erro que ponha em causa a ligação
entre o lado servidor e o lado cliente (por exemplo, quando a ligação é
perdida).
Em termos de alertas:
o Nova encomenda – é enviado um pedido do centro ao estafeta e aguarda
pela aceitação ou negação do mesmo. Em caso de o pedido ser aceite, o
centro enviará os dados do cliente;
o Localização – é exigida à unidade de localização móvel a sua localização
pelo gestor do centro de monitorização;
o Desvio de trajeto – acontece quando o estafeta se desvia de um
determinado raio (um quilómetro) da sua rota, e neste caso é
imediatamente alertado tanto o gestor como o estafeta.
Page 67
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
45
10. Diagrama Geral do sistema a implementar
O projeto que se pretende implementar está dividido em dois grandes blocos, servidor e
cliente. O lado do servidor, ou seja, o centro de monitorização baseado em PC de onde
consta uma aplicação gráfica robusta e moderna na qual é realizada a gestão em tempo
real dos estafetas.
O lado do cliente, ou seja, à parte relacionada com unidades de localização móveis com
tecnologia GPS que cada estafeta irá ser portador. Assim do lado do servidor vai existir
uma aplicação desenvolvida em C#. Esta aplicação vai ser programada de modo a
interagir com:
Cliente TCP/IP ou modem GSM – para possibilitar a comunicação remota com o
lado cliente;
RFID reader/writer – para ser possível escrever as etiquetas de cada estafeta;
Base de dados SQLite – corresponde a um ficheiro onde estará alojada a
estrutura da base de dados em SQL para o centro de monitorização;
Google Maps API – responsável pela visualização da posição dos estafetas,
leitura de histórico, entre outras funcionalidades.
Do lado do cliente da qual fazem parte as unidades de localização móveis responsáveis
pela localização da posição do estafeta, usar-se-á numa fase inicial nodos singulares
GPS (Ilustração 21) só para tornar possível o desenvolvimento do centro ao mesmo
tempo que se desenvolve a unidade de localização móvel suportada. Estes nodos
comunicarão com o centro por interface USB ou Bluetooth dependendo do recetor GPS
em utilização.
Page 68
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
46
Ilustração 21 – Diagrama Geral (com os nodos Singulares GPS)
No momento em que a unidade de localização móvel estiver desenvolvida, já é possível
a comunicação com ela sendo o meio de comunicação entre os dois blocos através de
redes móveis, GSM ou GPRS tal como mostra a Ilustração 22.
Ilustração 22 – Diagrama Geral (unidades de localização móvel)
Outro diagrama a tomar em consideração é o da Ilustração 23. Este diagrama representa
como é que o centro de monitorização vai interagir com a aplicação para dispositivos
Android. Como já foi explicado anteriormente esta aplicação contém informações úteis
e importantes para dispositivos portáteis. Assim quem estiver na posse de um
dispositivo com esta aplicação devidamente autenticada quando o entender poderá pedir
ao centro informações relativamente a um determinado estafeta.
Page 69
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
47
Ilustração 23 – Diagrama Geral (Dispositivo com aplicação para Android)
Page 70
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
48
Page 71
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
49
Modelação e Desenvolvimento do sistema
Neste capítulo é explicado como interligar todas as tecnologias estudadas e apresentadas
no capítulo anterior de modo a iniciar a construção do centro de monitorização.
11. Modelação de dados
Em grande parte dos projetos que recorrem a base de dados relacionais é obrigatório
(depois de conhecidos os requisitos do sistema) desenhar o modelo da base de dados
que se pretende implementar de modo a criar uma base segura e sólida. Para a
elaboração deste modelo fizeram parte os seguintes grupos chave:
os estafetas;
as unidades de localização móveis;
as encomendas;
os clientes;
os produtos.
Deste modo é apresentada na Ilustração 24, o diagrama ER (Entidade e Relações) que
descreve o modelo de dados, bem como ilustra as tabelas, atributos e relacionamentos
constituintes à base de dados implementada para este projeto.
Page 72
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
50
Ilustração 24 – Diagrama ER da base de dados
Apresentado o diagrama ER, é altura de descrever o propósito de cada tabela e o que
representam os seus atributos (ver Tabela 10) e assim entender a lógica do sistema.
Tabela Descrição
client
Tabela com informação relativa aos clientes do proprietário do sistema implementado.
Esta tabela tem os seguintes atributos:
ClientID – Identificador do cliente;
Name – Nome do cliente;
Street – Rua do cliente;
Locality – Localidade do cliente;
ZipCode – Código postal do cliente;
PhoneNumber – Número de telefone ou telemóvel do cliente;
Latitude – Latitude da localização geográfica da morada do cliente;
Page 73
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
51
Longitude – Longitude da localização geográfica da morada do cliente;
Description – Descrição particular da morada do cliente de forma a ajudar quem vai realizar o serviço.
coordinates
Tabela com informação relativa às coordenadas de uma determinada encomenda. Por exemplo, um estafeta está a
realizar uma encomenda e a cada minuto envia as coordenadas da sua localização. A localização enviada pertence
a esta tabela.
A tabela coordinates tem os seguintes atributos:
CoordinatesID – Identificador da coordenada;
Latitude – Latitude da localização enviada pelo portador da unidade de localização móvel;
Longitude – Longitude da localização enviada pelo portador da unidade de localização móvel;
DateTime – Data e tempo aquando é enviada esta coordenada;
OrderID – Identificador da encomenda.
order
Tabela com informação referente às encomendas realizadas pelo sistema completo.
Esta tabela tem os seguintes atributos:
OrderID – Identificador da encomenda adicionada;
DateTime – Data e tempo de aquando a encomenda é adicionada no sistema;
StartTime – Tempo de quando a encomenda é aceite pelo trabalhador que a está a processar;
FinishTime – Tempo de quando o trabalhador chega à morada pretendida, mesmo que a encomenda
seja entregue com ou sem sucesso;
State – Estado da encomenda. Este atributo pode tomar o valor de:
o Waiting for Accepting – encomenda à espera de ser aceite/rejeitada por quem a irá
processar;
o In Progress – encomenda aceite e em processamento;
o Delivery Completed – encomenda processada com sucesso;
o Delivery Not Completed – encamenda não processada (trabalhador não conseguir entregar
ao cliente).
WorkerID – Identificador do trabalhador que processa a encomenda;
ClientID – Identificador do cliente para quem a encomenda deve ser entregue.
product
Tabela com informação relativa aos produtos que constituem o negócio para qual este sistema funciona.
Esta tabela tem os seguintes atributos:
ProductID – Identificador do produto;
Name – Nome do produto;
Description – Descrição do produto (Por exemplo, ingredientes).
orderproduct
Tabela com informação relativa a encomendas e a produtos de modo a ligar as duas tabela (order e product)
conforme o conceito de normalização.
Esta tabela tem os seguintes atributos:
OrderProductID – Identificador do orderproduct;
Quantity – Quantidade de produtos que farão parte da encomenda;
OrderID – Identificador da encomenda adicionada;
Page 74
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
52
ProductID – Identificador do produto.
unit
Tabela com informação relativa à unidade de localização móvel que os trabalhadores levam em sua posse.
Esta tabela tem os seguintes atributos:
UnitID – Identificador da unidade de localização móvel;
PhoneNumber – número da unidade de localização móvel (cada unidade de localização móvel tem um
cartão SIM);
StateCommunication – Diz qual o modo de comunicação com o centro de monitorização. Este atributo
pode tomar os seguintes valores:
o 0 – Não existe comunicação com o centro;
o 1 – Existe comunicação com o centro por rede GSM;
o 2 – Existe comunicação com o centro através do envio de sockets, ou seja, a unidade de
localização móvel está a utilizar a rede GPRS para comunicar com o centro.
worker
Tabela com informação relativa aos trabalhadores registados no centro de monitorização.
Esta tabela tem os seguintes atributos:
WorkerID – Identificador do estafeta;
Name – Nome do estafeta;
Street – Rua do estafeta;
Locality – Localidade do estafeta;
ZipCode – Código postal do estafeta;
PhoneNumber – Número de telefone ou telemóvel do estafeta;
Birthday – Data de nascimento do estafeta;
State – Estado do estafeta para o centro. Este atributo pode tomar os seguintes valores:
o Disconnected! – Estafeta que não fez login no centro de monitorização;
o Connected! – Estafeta com login realizado no centro de monitorização;
o Connected - Not Responding! – Estafeta conectado ao centro de monitorização mas que por
qualquer motivo não responde a pedidos de processamento de encomenda;
o Connected - Busy! – Estafeta conectado ao centro de monitorização e a processar uma
encomenda.
LastLocation – Última localização (Latitude e Longitude) do estafeta.
workeruit
Tabela com informação relativa a trabalhadores e unidades de localização móveis de modo a ligar as duas tabela
(worker e unit) conforme o conceito de normalização aplicado às bases de dados.
Esta tabela tem os seguintes atributos:
WorkerUnitID – Identificador do workerunit;
UnitID – Identificador da unidade de localização móvel;
WorkerID – Identificador do estafeta.
Tabela 10 – Descrição das tabelas constituintes da base de dados
Depois de finalizada a modelação de dados torna-se necessário transformá-la em código
SQLite, uma vez que foi a base de dados escolhida para o sistema que se pretendia
Page 75
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
53
implementar com base na linguagem SQL. Deste modo foi utilizado o SQLite
Administrator9, uma ferramenta livre que permite criar e editar facilmente bases de
dados SQLite.
Foi criada a base de dados do sistema com o nome _crewt. Ao mesmo tempo é criado
um ficheiro com o mesmo nome pois as bases de dados SQLite concentram-se em
apenas um ficheiro que contém toda a estrutura e dados (ver Ilustração 25).
Ilustração 25 – Base de Dados do sistema com recurso à ferramenta SQLite Administrator
Basicamente, depois de criado o ficheiro com extensão .db, foram adicionadas todas as
tabelas e atributos (como se pode ver no lado esquerdo da Ilustração 25) de acordo com
o diagrama ER construído para este projeto (ve Ilustração 24).
De notar ainda na Ilustração 25 que existem três tabelas que não fazem parte da
modelação de dados (center, sqlite_sequence e user). A tabela center contém
informações acerca da localização geográfica (latitude e longitude) do centro de
monitorização de modo a possibilitar a inclusão de uma funcionalidade que mais à
frente será devidamente explicada, mas que basicamente ajuda o gestor na escolha do
estafeta mais adequado para a tarefa. Relativamente à tabela sqlite_sequence, esta é
criada automaticamente pela ferramenta não sendo relevante para este sistema. Por fim,
a tabela user foi criada para que este sistema tenha um sistema de autenticação (será
explicado detalhadamente mais à frente) de modo a aumentar a segurança do sistema.
9 www.sqliteadmin.orbmu2k.de
Page 76
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
54
12. Interfaces com o Hardware
Na maior parte dos projetos que recorrem a hardware é obrigatório a interação como
ele, por exemplo quando se utiliza sensores é necessário ter uma aplicação capaz de
traduzir a leitura deles.
Neste centro de monitorização como já foi descrito no capítulo da “Especificação do
hardware” o centro é composto por um modem GSM e um RFID reader/writer e tem de
comunicar com unidades de localização móveis e dispositivos que suportem o sistema
operativo Android (com a aplicação desenvolvida pela esse efeito). Para tal recorreu-se
às seguintes interfaces:
à porta-série;
ao cliente/servidor TCP/IP;
à rede GSM.
12.1. Porta-Série
A porta-série é a interface com que a aplicação de monitorização comunica com o
modem GSM e com o módulo RFID. Basicamente a comunicação é efetuada através da
leitura e da escrita de comandos com ou sem dados agregados reconhecidos pelo
módulo.
Uma vez que a aplicação do centro de monitorização é implementada na linguagem C#,
ela já fornece ao projetista uma classe (SerialPort) de interface ao device driver do
módulo da porta-série. Assim para ter acesso à classe SerialPort é necessário primeiro
incluir a biblioteca System.IO.Ports no projeto C# e depois ir à Toolbox → Components
e arrastar a classe SerialPort para o Form onde se pretende utilizá-la. Para o sistema que
se implementou, do centro são constituintes um modem GSM e um módulo RFID e por
isso, são necessários diferentes objetos da classe SerialPort para a utilização dos dois ao
mesmo tempo sem prejudicar o funcionamento do centro de monitorização. Depois é
necessário inicializar cada classe do modo que se pretende, isto é, definir baud rates, bit
de paridade, entre outras coisas como se pode observar nas Ilustrações 27 e 28.
Page 77
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
55
Ilustração 26 – Fluxograma de configuração e conexão do módulo RFID
O fluxograma da Ilustração 26 representa o modo como é realizada a configuração e
conexão do módulo RFID à aplicação. Em primeiro lugar é necessário verificar se
existem portas COM para futura conexão. Caso a resposta seja negativa, o gestor do
centro terá posteriormente a que efetuar esta conexão manualmente. Em caso
afirmativo, o próximo passo é verificar se a porta COM selecionada não está ocupada.
Se isto for verdade, é criado e inicializado um novo objeto da classe SerialPort com os
parâmetros recomendados pelo manual do módulo RFID escolhido para o projeto:
Este objeto é inicializado para a porta COM contida em serialports, com um baud rate
de 9600 bps, sem bit de paridade, 8 bits de dados e um stopbit.
serialPort1 = new SerialPort(serialports, 9600, Parity.None, 8, StopBits.One)
Page 78
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
56
De seguida é obrigatório abrir a conexão para a porta COM através do método
SerialPort.Open() já integrado na classe SerialPort e verificar se é o módulo RFID que
está conectado à porta selecionada. Para isso escreve-se para porta-série (método
SerialPort.Write()) selecionada um comando que seja reconhecido pelo módulo (por
exemplo, a instrução 0x01 presente na Tabela 8 que permite ler o tipo de etiqueta) e
verifica-se a resposta (método SerialPort.Read()). Por fim, se a leitura coincidir com
alguma das respostas possíveis, isso significa que foi o módulo RFID que efetuou o
pedido. Se não, é fechada a porta utilizada até aqui.
Para a ligação via modem GSM o procedimento é semelhante como se pode verificar
através da observação do fluxograma da Ilustração 27:
Ilustração 27 – Fluxograma de configuração e conexãodo modem GSM
Page 79
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
57
O fluxograma da Ilustração 27 representa como é implementada a conexão e
configuração do modem GSM com o centro. Tal como o caso anterior, é necessário
verificar se existem portas-séries disponíveis. Caso a reposta seja negativa, o gestor de
centro é alertado e tem a possibilidade de fazer esta conexão manualmente. Em caso
afirmativo, o próximo passo é verificar se a porta COM selecionada não está ocupada
por outro processo. Se a porta não estiver ocupada, é criado e inicializado um novo
objeto da classe SerialPort com os parâmetros recomendados no manual disponível:
O objeto serialPort2 é inicializado para funcionar para a porta-série que a variável
serialports representar. O baud rate aconselhado é de 9600 bps (pelo fabricante), não
possuiu bit de paridade, tem 8 bits para dados e um stopbit. Depois é aberta a conexão
para a porta COM escolhida e verificado se é um modem GSM que está conectado. Para
isso escreve-se pela porta-série selecionada, um comando reconhecido pelo modem (por
exemplo, o comando AT presente na Tabela 6 que permite ver se existe ou não
comunicação com o modem GSM) e verifica-se a resposta da porta-série, ou seja, se
corresponde ao esperado OK. O próximo passo é configurar o modem para funcionar do
modo que se pretende, daí a sub-rotina Configurar rede GSM (Ilustração 31). Caso o
modem seja configurado com sucesso é recebido pela porta-série um OK. Desta forma é
criada uma função de atendimento (serialPort2_DataReceived) aos dados recebidos
pela porta, isto é, sempre que porta-série receber dados esta função é invocada:
12.2. Cliente/Servidor TCP/IP
Nesta fase é explicado como o centro de monitorização comunica com as unidades de
localização móveis e com os dipositivos com a aplicação Android. A implementação
serialPort2 = new SerialPort(serialports, 9600, Parity.None, 8, StopBits.One)
serialPort2.DataReceived += new
SerialDataReceivedEventHandler(serialPort2_DataReceived)
Page 80
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
58
baseia-se na arquitetura TCP/IP cliente/servidor com o envio de pacotes através de
sockets, que basicamente corresponde ao transporte de comandos reconhecidos pelo
centro de monitorização, unidades de localização móveis ou dispositivos Android. Para
tornar isto possível é necessário criar e configurar o servidor TCP/IP (ver Ilustração 28),
implementar uma thread responsável pelo atendimento a novos clientes (Ilustração 29).
Assim, cada novo cliente que se conecta ao centro de monitorização terá uma thread de
comunicação, garantindo que uma unidade de localização móvel apenas receberá
pacotes endereçada a ela.
Ilustração 28 – Fluxograma da configuração e inicialização do servidor
A Ilustração 28 representa o fluxograma para a configuração e inicialização do servidor.
É importante ter a noção que esta configuração depende da existência de rede internet.
Em primeiro lugar é necessário obter o endereço IP e definir a porta para este servidor
TCP/IP. Este endereço vai variar consoante a rede em que o servidor estiver conectado,
e foi escolhida a porta 1234. De seguida inicializa-se o objeto da classe TcpListener
com o endereço IP e porta e posteriormente inicializar-se-á a thread de pedido de
ligação ao servidor passando-lhe como parâmetro o nome da função que terá que
executar. Portanto, à thread é dada a ordem para iniciar que tem a função de tratar das
novas conexões.
Page 81
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
59
Até ao momento foi explicado como configurar o servidor TCP/IP e agora é altura para
explicar como funciona a thread responsável pelo atendimento das novas conexões, tal
como retrata a Ilustração 29.
Ilustração 29 – Fluxograma da thread responsável pelo atendimento a novas conexões
Nesta thread começa-se por iniciar o servidor TCP/IP através do método Start() da
classe TcpListener e espera-se por novos pedidos de conexão. Na ocorrência de um
pedido de ligação por um novo cliente, este será guardado num objeto do tipo
TcpClient, caso o pedido for aceite.
Depois do cliente ser aceite pelo centro, é criado e inicializado uma nova thread
responsável pela comunicação entre o centro e a unidade de localização móvel ou
dispositivo Android. Finalmente é associada a esta thread, o cliente que pediu a conexão
ao centro.
Nesta fase é explicado só como foi implementado o cliente TCP/IP na aplicação em
Java para dispositivos Android. A Ilustração 30 mostra o procedimento de configuração
do cliente TCP/IP. Em primeiro lugar, é criado um socket para se conectar ao servidor
do centro de monitorização na qual é necessário passar por parâmetros o IP e porta do
servidor (enviados pelo centro via rede móvel GSM):
Page 82
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
60
Criando o socket com o IP e porta do servidor, a conexão é estabelecida faltando
somente a obtenção das variáveis de leitura e escrita do servidor.
Ilustração 30 – Fluxograma que representa a configuração do cliente TCP/IP
Em caso de sucesso, o cliente TCP/IP está configurado e pronto para trocar informação
com o centro de monitorização.
12.3. Rede GSM
Tal como foi referido, é possível comunicar com a unidade de localização móvel ou
através do cliente/servidor TCP/IP ou pela rede móvel GSM. Assim, nesta secção é
explicada como é realizada a configuração desta rede, de modo que o modem GSM
possa permitir a comunicação com as unidades de localização móveis como desejado.
requestSocket = new Socket(ip, port)
Page 83
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
61
Ilustração 31 – Fluxograma da sub-rotina Configurar rede GSM
Nesta sub-rotina são habilitados os códigos de erros facilitar a identificação do
problema. É verificada a presença de um cartão SIM no modem. Naturalmente em caso
afirmativo, é introduzido o seu código PIN, senão ocorrerá um erro. No final desta sub-
rotina é habilitado o modo texto para as mensagens.
Page 84
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
62
13. Subsistemas de software
Tal como foi identificado no subcapítulo do “Estudo/Análise do sistema a
implementar”, denominado de “Subsistemas de software” no sistema implementado
existem 4 grandes subsistemas fundamentais para este projeto. Entre eles:
o subsistema de aquisição de dados;
o subsistema de tratamento de dados;
o subsistema de comunicação;
e o tratamento de erros.
13.1. Subsistema de aquisição de dados
Este subsistema é responsável pela aquisição de dados provenientes das unidades de
localização móveis. No centro de monitorização existem duas diferentes aquisições, a
aquisição periódica e a on-demand. Por outro lado, na aplicação desenvolvida em Java
para dispositivos Android só existe aquisição on-demand.
Aquisição periódica
Tal como o próprio nome sugere, a aquisição periódica corresponde a um evento que
acontece em intervalos regulares de tempo. Para este projeto, o intervalo de tempo
escolhido para esta aquisição é de 60 segundos, ou seja, de 60 em 60 segundos as
unidades de localização móveis enviam o comando da localização para o centro de
modo a mantê-lo totalmente atualizado quanto à sua localização. A razão da escolha
deste valor, deve-se ao facto de em 60 segundos o estafeta não percorrer uma distância
suficientemente longa que ponha em risco a funcionalidade que deteta se o estafeta se
afastou demasiado da rota pretendida nem o resto do sistema.
Page 85
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
63
Ilustração 32 – Fluxograma do subsistema de aquisição periódica
O fluxograma da Ilustração 32 representa o modo como se processa esta aquisição.
Assim, quando uma unidade de localização móvel se conecta ao centro de
monitorização, é iniciado um temporizador de 1 minuto que fica responsável de enviar
para o centro de monitorização os dados que representam a localização da unidade de
localização móvel. Deste modo, o centro somente tem de verificar se a unidade de
localização móvel está conectada a ele. Se sim, o centro aguarda pelo envio periódico da
localização. Depois de recebida essa localização, o centro processa essa informação de
acordo com a sub-rotina Tratar dados recebidos abordada no subcapítulo “Subsistema
de tratamento de dados”.
Aquisição on-demand
Este tipo de aquisição representa a vontade do gestor do centro ou utilizador da
aplicação Android, isto é, são pedidos ou informações que qualquer um destes agentes
pode realizar sobre as unidades de localização móveis no caso do gestor ou sobre o
centro no caso do utilizador Android. Assim, o gestor do centro tem a possibilidade de
interagir com a unidade de localização móvel consultando ou ordenando pedidos que
não dizem respeito com a localização ou até mesmo antecipar a aquisição periódica. No
caso do utilizador da aplicação Android, este só pode comunicar com o centro de
monitorização para se informar sobre por exemplo, o estado de uma determinada
encomenda.
Page 86
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
64
A Ilustração 33 representa o modo como foi implementado este subsistema de aquisição
no desenvolvimento do centro de monitorização.
Ilustração 33 – Fluxograma do subsistema de aquisição on-demand (lado do centro)
Assim quando o gestor do centro pretende fazer um pedido a uma determinada unidade
de localização móvel, é verificado se é possível realizar esse pedido, ou seja, se a
unidade móvel está ainda conectada ao centro e só depois em caso positivo é que o
pedido é enviado, senão dá-se um erro. Depois é verificado se existiu algum erro no
envio, se sim é produzido um erro.
Se o gestor do centro não pretender enviar um pedido, isso significa que está à espera de
alguma informação proveniente da unidade de localização móvel. Assim, o sistema
aguarda pelo comando, que quando recebido será reencaminhado para o subsistema
responsável pelo seu processamento.
No caso da aplicação Android, a implementação é parecida à anterior como é possível
ver pelo fluxograma representado pela Ilustração 34.
Primeiramente é validada a intenção do utilizador em comunicar com o centro. Caso
afirmativo, é necessária verificar se a aplicação cliente ainda está conectada ao centro de
monitorização. Estando conectada é enviado determinado pedido, senão ocorre um erro.
Page 87
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
65
Depois é verificado se existiu algum erro no envio, se sim é produzido um erro. Caso
não haja erros, a aplicação fica à espera da resposta proveniente do centro e quando
recebida são processados tal como mostra a Ilustração 35.
Ilustração 34 – Fluxograma do subsistema de aquisição on-demand (lado da aplicação Android)
13.2. Subsistema de tratamento de dados
É o subsistema responsável por processar a informação recebida pelas unidades de
localização móveis ou pelos dipositivos Android, ou seja, informação proveniente do
subsistema de aquisição de dados. Basicamente este subsistema lê e processa toda a
informação recebida pelos três agentes deste sistema. Por exemplo, o centro recebe por
parte da unidade de localização móvel dados referentes à posição geográfica do estafeta,
este subsistema vai reconhecer esse tipo de dados e atualizar a posição do estafeta no
mapa do centro.
Page 88
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
66
Ilustração 35 – Fluxograma que representa o sub-rotina de tratamento de dados
Qualquer que seja o tipo de aquisição ou pedido feito por qualquer um dos agentes deste
sistema, primeiro verifica-se qual a ação a que corresponde o pedido realizado. No que
diz respeito ao tratamento de dados com informação proveniente das unidades de
localização móveis ou dos dispositivos com a aplicação Android, este basicamente
corresponde à verificação do comando num grande lote de comandos de forma a
distinguir o seu tratamento correspondente. Relativamente a pedidos provenientes do
gestor o seu tratamento pode corresponder entre atualizações pontuais somente no
centro (adicionar clientes à base de dados do centro) e pedidos às unidades de
localização móveis (adicionar uma nova encomenda).
Depois de saber qual o processamento correspondente ao pedido, é verificada a
necessidade de responder ao pedido. Em caso afirmativo, o centro comunica com quem
lhe fez o pedido e envia-lhe a resposta. Por fim, é atualizado a informação no centro
caso necessário.
Page 89
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
67
Comandos reconhecidos pelo centro de monitorização (com a unidade de
localização móvel)
Nesta secção dá-se a conhecer todos os comandos reconhecidos pelo centro de
monitorização com origem nas unidades de localização móveis, de uma forma detalhada
para se perceber o funcionamento deste sistema e seu respetivo processamento.
UNIT_REG:ID_UNIT
Quando o centro de monitorização deteta que os dados enviados pela unidade de
localização móvel começam por UNIT_REG: significa que uma unidade móvel quer
estabelecer conexão. Este comando tem a particularidade de só poder ser enviado
através da rede GSM (por SMS), uma vez que não há outra forma de comunicação
possível na medida em que é impossível para a unidade de localização móvel saber o IP
(não-fixo) do centro, sem que seja o próprio a lhe fornecer essa informação.
Este comando recebe um parâmetro, o identificador da unidade móvel. Depois de saber
qual é a unidade de localização que se pretende conectar, procura-se na base de dados se
ela foi anteriormente registada (realizado um SELECT). Em caso negativo, a nova
unidade móvel é registada (realizado um INSERT) na base de dados do centro. De
seguida, é verificado se o servidor TCP/IP está ativo. Se sim, o centro informa a
unidade de localização móvel que pode conectar como cliente TCP/IP, ou seja, é
enviado o comando REG_OK: onde são fornecidos o endereço IP e porta. Se o servidor
não está ativo, o centro envia de seguida a notificação NO_IP e a comunicação entre
eles continua a processar-se por troca de SMSs.
UNIT_USING_GPRS:ID_UNIT
Quando os dados recebidos começam por UNIT_USING_GPRS significa que a unidade
de localização móvel que tinha efetuado o pedido se conseguiu conectar ao centro.
Basicamente o centro atualiza na base de dados o atributo StateCommunication com o
valor 2 através de uma query do tipo UPDATE com base no parâmetro que representa o
identificador da unidade de localização.
Page 90
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
68
UNIT_USING_SMS
A receção deste comando pelo centro de monitorização significa que a unidade de
localização móvel não conseguiu conectar como cliente TCP/IP ou que o servidor
TCP/IP do centro não está ativo. Deste modo, o que o centro tem a fazer é atualizar na
base de dados o estado da conexão com o valor 1, novamente através da query do tipo
UPDATE com base no número de telefone do cartão SIM, uma vez que ele é único a
cada unidade de localização móvel.
LOGIN:ID_UNIT,ID_RFIDCARD,ID_WORKER
Quando o centro deteta que os dados enviados pela unidade de localização móvel
começam por LOGIN: significa que um determinado estafeta que tem uma determinada
unidade de localização móvel deseja realizar login no centro de monitorização. Depois é
necessário identificar o estafeta, isto é, saber qual o seu identificar do cartão RFID e que
unidade de localização móvel ele está a utilizar. No fim de ter esses dados, atualiza-se o
estado do estafeta (atributo State da tabela worker) de Disconnected! Para o valor
Connected! através de uma query do tipo UPDATE. De seguida, é necessário associar a
unidade móvel a esse estafeta, ou seja, uma query do tipo INSERT da tabela workerunit.
Por conseguinte, é preciso atualizar a informação do centro visível ao gestor do centro,
ou seja, na listView que mostra os estafetas ligados ao centro e respetivos estados. Por
fim, é necessário verificar o tipo de comunicação que o centro tem com a unidade de
localização móvel, para lhe enviar o comando que informa que o login foi realizado
com sucesso (LOGIN_OK:ID_WORKER;).
FUNC_GEO:ID_WORKER,ID_ORDER,$GEO
No caso do centro receber dados que comecem por FUNC_GEO: significa que uma
determinada unidade de localização móvel lhe está a enviar a sua localização, e nesse
caso é necessário avaliar várias situações:
1) Se o estafeta não estiver autenticado no centro, o primeiro parâmetro não tem
valor;
2) Se o estafeta estiver autenticado no centro, o primeiro parâmetro tem valor
correspondente ao identificador do estafeta. Dentro desta situação, é preciso
analisar:
Page 91
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
69
a. Se o estafeta não estiver a realizar uma encomenda, o segundo parâmetro
não tem valor;
b. Se o estafeta estiver a realizar uma encomenda, o segundo parâmetro tem
valor e corresponde ao identificador da encomenda.
Nestes casos em primeiro lugar, é necessário separar o identificador do estafeta, da
encomenda e a instrução GGA do protocolo NMEA. Com esses dados referentes a
localização geográfica, é extraída a latitude, longitude e atualizado o atributo
LastLocation da tabela worker (realizado um UPDATE) que representa a posição
geográfica mais recente. Depois se existir acesso à rede internet é adicionada ou
atualizada a posição do marcador no mapa que mostra a localização de todos os
estafetas conectados ao centro. No caso de o estafeta estar a realizar uma entrega, as
coordenadas geográficas anteriormente extraídas são inseridas na base de dados como
parte integrante do percurso dessa encomenda (realizado um INSERT na tabela
coordinates).
WAITING_FOR_REQ_DATA:ID_WORKER,ID_ORDER;$GEO
O comando WAITING_FOR_REQ_DATA informa o centro de que um determinado
pedido para processamento de entrega foi aceite por um estafeta, ficando a unidade de
localização móvel à espera que o centro lhe envie os dados referentes à encomenda,
como por exemplo, o nome de cliente, morada, entre outras informações. Em primeiro
lugar é preciso separar do comando, os dados referente ao identificador do estafeta, da
encomenda e da localização geográfica (trama GGA). Depois é necessário garantir que a
encomenda não foi entregue a outro estafeta, uma vez que pode acontecer a situação de
um estafeta estar demasiado tempo sem responder ao pedido de entrega. Se for esse o
caso, o centro só tem que atualizar na base de dados o valor do atributo State de
Connected – Not Responding! para Connected! e enviar um comando ao estafeta. Este
comando irá informá-lo que a encomenda foi entregue a outro estafeta
(ORDER_ALREADY_ACCEPTED) consoante o tipo de comunicação em que estiverem
a operar.
Por outro lado, se o atributo State da tabela order tem o valor Waiting for Accepting
(ainda ninguém está a processar a encomenda) é parado o temporizador responsável por
verificar se ao fim de um minuto da inserção da encomenda, ela necessita de mudar de
Page 92
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
70
estafeta (caso o estafeta esteja incontactável) ou ir para lista de espera. Em seguida, são
atualizadas as informações referentes ao estado do estafeta (State da tabela worker passa
a ter valor de Connected – Busy!), da encomenda (State da tabela order passa a ter valor
de In Progress) e ao tempo de início da encomenda, ou seja, o atributo StartTime da
tabela order é atualizado com o tempo do instante que o centro recebeu este comando.
Depois, com base no identificador da encomenda é procurado o identificador do cliente
para qual deve ser entregue a encomenda (realizando um SELECT). Consecutivamente
com o identificador do cliente é realizada uma busca às restantes informações do cliente
que o estafeta necessita, ou seja, nome, rua, localidade, código postal, descrição do local
(se possível) e número de telefone. No fim de possuir toda a informação, ela é enviada
para a unidade de localização móvel (consoante o tipo de comunicação) através do
comando REQUEST_DATA. Finalmente são inseridas as coordenadas de onde a
encomenda foi aceite, em que estas são consideradas as primeiras coordenadas do
trajeto da encomenda.
REQ_REJECTED:ID_ORDER
No caso do centro receber dados começados por REQ_REJECTED: significa que um
determinado estafeta rejeitou o pedido para processamento de uma encomenda
representada pelo identificador (ID_ORDER). Como o estafeta rejeitou a encomenda, o
centro somente envia o identificador dela para uma rotina (detalhadamente explicada a
frente) que está responsável por transferir esta encomenda para outro estafeta ou colocá-
la em lista de espera até que alguém a aceite.
REQ_DONE:ID_ORDER,$GEO
O comando REQ_DONE informa o centro de que uma determinada encomenda foi
processada com sucesso, ou seja, o estafeta diz ao centro que concluiu aquele pedido.
Assim o centro começa por separar o identificador da encomenda e a localização
geográfica de onde ela foi entregue.
Depois já com o identificador, o centro atualiza a informação referente à encomenda, ou
seja, realiza um UPDATE na tabela order, alterando o valor do atributo FinishTime
(com o tempo do sistema aquando da receção do comando) e o valor do atributo State
para Delivery Completed. Também, é necessário atualizar o atributo State da tabela
worker para Connected! para o estafeta estar disponível para receber novas encomendas.
Page 93
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
71
Quanto ao cliente, são atualizadas as coordenadas geográficas da sua morada, uma vez
que quando é inserido um cliente no centro só é fornecida a morada e a API do Google
Maps converte-a para coordenadas geográficas podendo existir um pequeno erro. Por
fim, o centro atualiza as informações visíveis ao gestor que foram alteradas.
REQ_FAIL:ID_ORDER
O comando REQ_FAIL informa o centro de que uma determinada encomenda não foi
processada com sucesso, ou seja, o estafeta informa o centro que não concluiu o pedido
(por exemplo, o cliente não estava em casa). Depois, o centro começa por separar o
identificador da encomenda, atualiza a informação referente à encomenda, ou seja,
realiza um UPDATE na tabela order alterando o valor do atributo FinishTime (com o
instante em que recebeu o comando) e o valor do atributo State para Delivery Not
Completed. Também, é necessário atualizar o atributo State da tabela worker para
Connected!. Finalmente, o centro atualiza as informações visíveis ao gestor que foram
alteradas.
LOGOUT:ID_WORKER
Quando o centro de monitorização deteta que os dados enviados pela unidade de
localização móvel começam por LOGOUT: significa que um determinado estafeta que
tem uma determinada unidade de localização móvel, quer realizar logout do centro de
monitorização. Em primeiro lugar, é necessário saber qual é o estafeta para atualizar o
valor State da tabela worker para Disconnected!, ou seja, uma query do tipo UPDATE.
De seguida, é necessário eliminar a ligação que um estafeta tem com uma determinada
unidade de localização móvel, ou seja, uma query do tipo DELETE na tabela workerunit
tendo como referência o identificador do estafeta que se desconectou. No final, é
necessário remover o marcador do mapa com a localização desse estafeta.
Estes são os comandos que o centro recebe das unidades de localização móveis. Mas
agora, é altura de detalhar e explicar os comandos que o centro envia às unidades de
localização.
Page 94
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
72
REG_OK:IP:PORTA;
Corresponde a uma possível resposta ao comando recebido pelo centro, UNIT_REG.
Basicamente informa a unidade de localização móvel do endereção IP e porta para o
qual ela se deve conectar para comunicar com o centro através do cliente/servidor
TCP/IP. Depois o centro aguarda que a conexão seja realizada com êxito e pela resposta
da unidade móvel (UNIT_USING_GPRS).
REG_OK:NO_IP;
Corresponde à outra resposta possível ao comando UNIT_REG que é enviado para o
centro. Basicamente informa a unidade de localização móvel de que o centro não tem o
cliente/servidor TCP/IP ativo e que terão de utilizar a rede móvel GSM como meio de
comunicação. Depois o centro aguarda pela resposta da unidade de localização móvel,
ou seja, pelo comando UNIT_USING_SMS.
LOGIN:ID_WORKER;
Diz respeito à resposta ao pedido de autenticação de um estafeta no centro de
monitorização (LOGIN). Informa o estafeta com um determinado identificador
(ID_WORKER) que realizou o login com sucesso.
REQUEST_DATA:INFO_CLIENT;
Quando um determinado estafeta aceita uma encomenda, o centro recebe
WAITING_FOR_REQ_DATA e tem de enviar a informação referente à encomenda, ou
seja, os dados do cliente. Assim, depois de o centro obter essa informação (nome, rua,
localidade, etc), ele envia este comando com essa informação agregada para a unidade
de localização móvel.
SET_REQ:ID_ORDER;
Corresponde à ação do gestor ao inserir uma encomenda no sistema, na qual é enviado
automaticamente para a unidade de localização móvel este comando. Este comando
pressupõe uma resposta ao centro por parte do estafeta, ou seja, o estafeta ou aceita
(WAITING_FOR_REQ_DATA), rejeita (REQ_REJECTED) a encomenda ou está
incontactável.
Page 95
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
73
SET_MESSAGE:MESSAGE;
Diz respeito à vontade do gestor querer enviar uma mensagem ao estafeta de modo a
auxiliar no seu trabalho, se necessário ou se entender. Este comando é enviado e com
ele é enviado o corpo da mensagem que o gestor bem entender. Esta mensagem pode ser
escrita pelo gestor numa caixa de texto localizada no Form de nome SpecificWorker.cs.
GET_LOCATION
É um comando que só é possível na comunicação por rede móvel GSM e tem a função
de pedir ao estafeta a sua localização geográfica. Isto surgiu da necessidade de redução
de custos com esta rede. Imagine-se que se está a comunicar com uma unidade de
localização móvel por GSM, ao fim de algum tempo devido à aquisição de minuto em
minuto, o número de mensagens enviadas pelas unidades móveis para o centro seria
enorme e dispendioso. Assim, ficou decidido que quando a unidade de localização
móvel estiver a comunicar com o cento por rede GSM, ela não irá enviar periodicamente
a sua localização, mas quando o gestor do centro quiser poderá pedir manualmente essa
localização. E é desta necessidade que surge este comando que exige resposta por parte
da unidade (FUNC_GEO).
FORCE_MODE:GPRS,IP:PORTA;
Quando o centro deteta que o estado da sua rede mudou (por exemplo, a rede internet
voltou), então ele faz uma busca de todos os estafetas conectados e seguidamente dos
seus números de telefone (recorrendo a querys do tipo SELECT). Tudo isto com o
objetivo de tornar possível o envio deste comando para todos os estafetas ativos. E
assim, se possível comunicar com eles via cliente/servidor TCP/IP, em vez de rede
GSM, evitando custos adicionais.
FORCE_MODE:SMS;
Este comando é da família do anterior, isto é, quando o centro deteta que ficou sem
acesso à rede internet, indispensável para o funcionamento da cliente/servidor TCP/IP, é
necessário forçar o modo GSM como comunicação entre o centro e as unidades de
localização móveis. Tal como o anterior, o centro começa por fazer uma pesquisa por
todos os estafetas conectados e seguidamente, dos seus números de telefone (recorrendo
Page 96
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
74
a querys do tipo SELECT). Depois de ter os dados necessários, o centro envia este
comando que força as unidades de localização móveis a comunicarem com centro via
rede GSM.
OUT_ROUTE:INTRUCTION;
Corresponde quando o estafeta está demasiado fora do raio definido para o efeito, ou
seja, o estafeta está desviado da sua rota. Graças à API do Google Maps é possível
implementar esta funcionalidade que mais a frente será explicada em detalhe. Assim,
quando é detetado que o estafeta está demasiado longe do seu objetivo, o centro envia
este comando para o determinado estafeta. Comando este que está agregado de uma
instrução que tem como objetivo ajudar o estafeta a encontrar de forma mais rápida o
caminho correto para o cliente.
Com base nas Tabelas 11 e 12 estão presentes os comandos até aqui explicados de
forma resumida:
Comando Parâmetros Descrição Resposta
UNIT_REG:ID_UNIT ID_INIT – Identificador da
unidade de localização móvel.
Pedido de conexão
com o centro de
monitorização.
Sim
UNIT_USING_GPRS:ID_UNIT ID_UNIT - – Identificador da
unidade de localização móvel.
Informa o centro que
a unidade de
localização móvel
está a comunicar
como cliente
TCP/IP.
Não
UNIT_USING_SMS - - - -
Informa o centro que
a unidade de
localização móvel
está a comunicar
através da rede GSM.
Não
LOGIN:ID_UNIT,ID_RFIDCARD,ID_WORKER
ID_INIT – Identificador da
unidade de localização
móvel;
ID_RFIDCARD –
Identificador do cartão RFID
que o estafeta possuiu;
ID_WORKER – Identificador
do estafeta.
Estafeta faz login no
centro de
monitorização.
Sim
FUNC_GEO:ID_WORKER,ID_ORDER,$GEO ID_WORKER – Identificador
do estafeta;
Informa o centro da
localização da Não
Page 97
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
75
ID_ORDER – Indentificador
da encomenda;
$GEO – Localização
geográfica da unidade no
formato GGA referente ao
protocolo NMEA.
unidade de
localização móvel.
WAITING_FOR_REQ_DATA:
ID_WORKER,ID_ORDER;$GEO
ID_WORKER – Identificador
do estafeta;
ID_ORDER – Indentificador
da encomenda;
$GEO – Localização
geográfica da unidade de
localização móvel no formato
GGA referente ao protocolo
NMEA.
Informa o centro que
a encomenda foi
aceite.
Sim
REQ_REJECTED:ID_ORDER ID_ORDER – Indentificador
da encomenda.
Informa o centro que
o estafeta rejeitou a
encomenda.
Não
REQ_DONE:ID_ORDER,$GEO
ID_ORDER – Indentificador
da encomenda;
$GEO – Localização
geográfica da unidade de
localização móvel no formato
GGA referente ao protocolo
NMEA.
Informa o centro que
a encomenda foi
entregue com
sucesso ao cliente.
Não
REQ_FAIL:ID_ORDER ID_ORDER – Indentificador
da encomenda.
Informa o centro que
a encomenda não foi
entregue com
sucesso ao cliente.
Não
LOGOUT:ID_WORKER ID_WORKER – Identificador
do estafeta.
Estafeta faz logout
no centro de
monitorização.
Não
Tabela 11 – Comandos que o centro reconhece provenientes das unidades de localização móveis
Até aqui foram resumidos os comandos que o centro reconhece e que têm como fonte as
unidades de localização móveis. Agora é altura de fazer o mesmo para os comandos que
são enviados do centro para as unidades móveis:
Comando Parâmetros Descrição Resposta
REG_OK:IP:PORTA; IP – endereço IP;
PORTA – valor da porta.
Resposta ao pedido
de conexão.
Comunicação por
servidor/cliente
TCP/IP.
Não
REG_OK:NO_IP; NO_IP – Modo GSM. Resposta ao pedido
de conexão. Não
Page 98
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
76
Comunicação através
da rede móvel GSM.
LOGIN:ID_WORKER; ID_WORKER – Identificador do estafeta.
Informa a unidade de
localização móvel
que o estafeta fez
login com êxito.
Não
REQUEST_DATA:INFO_CLIENT;
INFO_CLIENT – Dados referentes a um
cliente. É composto por:
o Nome;
o Rua;
o Localidade;
o Código Postal;
o Descrição do sítio (se
possível);
o Nº Telefone.
Enviado para o
estafeta as
informações
necessárias para
processar a
encomenda.
Não
SET_REQ:ID_ORDER; ID_ORDER – Indentificador da
encomenda.
O centro pede a um
determinado estafeta
para processar uma
encomenda. Pode ser
aceite ou rejeitado.
Sim
SET_MESSAGE:MESSAGE; MESSAGE – Corpo da mensagem que se
deseja enviar ao estafeta.
Enviar uma
mensagem
manualmente ao
estafeta.
Não
GET_LOCATION - - - -
Pedido manual da
localização (Só em
modo GSM).
Sim
FORCE_MODE:GPRS,IP:PORTA;
GPRS – Modo de comunicação;
IP – endereço IP;
PORTA – valor da porta.
Força a comunicação
entre o centro e a
unidade de
localização móvel
por cliente/servidor
TCP/IP.
Sim
FORCE_MODE:SMS; SMS – Modo de comunicação.
Força a comunicação
entre o centro e a
unidade de
localização móvel
por rede GSM.
Sim
OUT_ROUTE:INSTRUCTION; INTRUCTION – Próxima instrução para
o estafeta se orientar.
Alerta enviado para a
unidade de
localização móvel
para o estafeta estiver
a se desviar do seu
percurso.
Não
Tabela 12 – Comandos que o centro envia para as unidades de localização móveis
Page 99
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
77
Comandos reconhecidos pelo centro de monitorização (com dispositivos Android)
Nesta secção explicar-se-á de forma detalhada todos os comandos reconhecidos pelos
dispositivos (por exemplo, telemóveis, tabletes) com a aplicação desenvolvida para o
sistema operativo Android.
AND_REG;
Quando o centro de monitorização deteta que os dados enviados começam por
AND_REG; significa que um dispositivo Android quer estabelecer ligação. Este
comando tem a particularidade de só poder ser enviado pelo dispositivo através da rede
GSM, uma vez que não há outra forma de comunicação possível na medida em que é
impossível para a aplicação Android saber o IP (não-fixo) do centro, sem que seja o
próprio a lhe fornecer essa informação.
Em termos de processamento, o centro somente tem de verificar se o servidor TCP/IP
está ativo. Em caso afirmativo, o centro informa o dispositivo que se pode conectar com
ele como cliente TCP/IP, ou seja, é enviado ao dispositivo Android o comando
REG_OK agregado do endereço IP e porta correspondente. Se o servidor não está ativo,
o centro envia adicionalmente o comando NO_IP; e a comunicação não é possível. De
notar que estes comandos são também somente enviados pelo centro por rede GSM.
GET_WORKERS;
Quando é detetado que os dados recebidos começam por GET_WORKERS; significa
que o dispositivo deseja saber quais são os estafetas que estão registados no centro de
monitorização. Deste modo, o centro faz uma pesquisa na sua base de dados (recorrendo
a um SELECT) para obter todos os estafetas. A informação é organizada do seguinte
modo:
Em primeiro lugar vem o nome do estafeta e depois o seu identificador (entre
parênteses). Os diferentes estafetas são separados por vírgulas. Finalmente a informação
Nome A (Identificador A),…,…, Nome D (Identificador D)
Page 100
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
78
é enviada através do servidor TCP/IP o comando WORKER_LIST: que tem como
anexo, toda a informação atrás adquirida.
GET_WORKERINFO:ID_WORKER
Corresponde a um pedido por parte da aplicação Android para o centro lhe enviar
informações sobre um determinado estafeta, dado pelo parâmetro ID_WORKER
(identificador do estafeta). Deste modo, quando é detetado este pedido o centro realiza
mais uma vez uma procura à sua base de dados (recorrendo a um SELECT) de modo a
recolher as informações. Informações compostas pelo nome, rua, localidade, código
postal, número de telefone e estado do estafeta com o centro. Elas estão organizadas da
seguinte maneira:
Portanto, os diferentes dados são separados por vírgulas e são enviados através do
servidor TCP/IP. O comando WORKER_INFO: tem anexado toda a informação atrás
adquirida.
GET_WORKERLOCATION:ID_WORKER
No caso de o centro receber este comando, isso significa que o utilizador da aplicação
Android deseja saber qual a posição mais recente do estafeta especificado no parâmetro
ID_WORKER. Para tal, o centro tem que pesquisar na tabela worker pela LastLocation
do determinado estafeta:
Depois de obter a posição geográfica mais recente, o centro envia através do servidor
TCP/IP o comando WORKER_LOCATION:, seguido da informação adquirida
anteriormente.
Nome,Rua,Localicade,Código Postal,Nº Telefone,Estado
Latitude;Longitude
Page 101
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
79
GET_ORDERS:ID_WORKER
Quando é detetado que os dados recebidos começam por GET_ORDERS: significa que
a aplicação está a pedir ao centro todas as encomendas processadas por um estafeta.
Para o centro responder corretamente a tal pedido, ele tem que realizar uma pesquisa à
base de dados pelos identificadores dos clientes de encomendas que o estafeta entregou
para saber quais os nomes dos clientes. De seguida, faz uma última pesquisa pelos
identificadores das encomendas que o estafeta realizou de forma a agrupar a informação
do seguinte modo:
Portanto, os diferentes dados são separados por vírgulas e enviados através do comando
ORDERS.
GET_ORDERINFO:ID_ORDER
Corresponde a um pedido por parte da aplicação Android para o centro lhe enviar
informações sobre uma encomenda, dada pelo parâmetro ID_ORDER. Deste modo
quando é detetado tal pedido, o centro realiza a procura da informação na sua base de
dados. Em primeiro lugar, é adquirida a informação da tabela order, ou seja, os
atributos DateTime, StartTime e FinishTime. Depois, pesquisa-se nas tabelas worker e
client e adquirir os dados dos atributos, WorkerID e ClientID para completar a
informação que fica organizada do seguinte modo:
Desta maneira, o comando ORDER_INFO: é enviado e tem anexado toda a informação
atrás adquirida (separados por vírgulas).
Identificador A (Nome A),…,…,Identificador D (Nome D)
Data e Tempo,Nome do estafeta (Identificador),Nome do Cliente
(Identificador),Tempo de Início,Tempo de Fim,Estado
Page 102
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
80
GET_ORDERHISTORY:ID_ORDER
Basicamente diz respeito a um pedido ao centro, para este lhe enviar todas as posições
geográficas realizadas numa determinada encomenda, dada pelo parâmetro ID_ORDER.
Deste modo, quando é detetado este pedido o centro realiza várias buscas à sua base de
dados de modo a recolher todas as latitudes e longitudes. Estes dados ficam organizados
do seguinte modo:
Assim, os diferentes dados são separados por vírgulas e enviado através do servidor
TCP/IP o comando ORDER_HISTORY: que tem a ele agregado todas as coordenadas
atrás recolhidas.
Estes são os comandos que o centro recebe provenientes da aplicação Android, pelo que
de seguida descreve-se detalhadamente os comandos que o centro envia à aplicação.
REG_OK:IP:PORTA;
Este comando também aparece nos comandos enviado pelo centro às unidades de
localização móveis de localização móveis e como tal, a sua intenção é a mesma. Assim,
ele corresponde a uma possível resposta ao comando recebido pelo centro, o
AND_REG;. Basicamente informa o dispositivo Android do endereção IP e porta para o
qual deve-se conectar para comunicar com o centro através do único modo de
comunicação possível entre eles, ou seja, através do cliente/servidor TCP/IP.
Do lado da aplicação Android quando ela recebe este comando, a primeira coisa que faz
é separar os parâmetros que vêm agregados ao comando, o endereço IP e porta. De
seguida, tenta dar início à conexão como cliente TCP/IP. Se a conexão é conseguida, a
aplicação avisa o utilizador de tal facto e realiza um pedido ao centro, ou seja, envia-lhe
o comando GET_WORKERS; anteriormente explicado. Por outro lado, se a conexão não
foi conseguida, ela avisa também o utilizador que não foi possível conectar com o
centro (mas o problema está do lado da aplicação Android).
Latitude A,Longitude A,…,…,Latitude D,Longitude D
Page 103
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
81
REG_OK:NO_IP;
Corresponde à outra resposta possível ao comando AND_REG; que é enviado para o
centro. Basicamente informa o aparelho Android de que o centro não tem o
cliente/servidor TCP/IP ativo e sendo assim, não existe modo de comunicar com o
centro.
Do lado da aplicação Android, quando ela recebe o comando REG_OK:NO_IP;, o
utilizador da aplicação é informado que não é possível a conexão com o centro (mas o
problema está do lado do centro).
WORKER_LIST:DATA
Diz respeito à resposta por parte do centro ao comando enviado pela aplicação Android,
ou seja, GET_WORKERS; que indica que a aplicação está conectada ao centro e lhe
pediu todos os estafetas registados nele. Este comando contém informação (nome e
identificador) de todos os estafetas do centro. Informação que está presente no
parâmetro DATA.
Do lado da aplicação Android, quando ela recebe este comando, a primeira coisa que faz
é criar e inicializar um Intent (explicado na secção “Sistema Operativo Android”). Antes
de enviar o Intent para a atividade principal (Android_Center), adiciona-lhe os dados
previamente separados deste comando. Depois quando a atividade principal deteta esse
Intent, é criada e inicializada uma nova atividade (worker_list) que é responsável por ler
os dados, ordená-los por ordem crescente de identificador e apresentá-los consoante foi
desenhado o interface da atividade, ou seja, colocá-los numa lista para poderem ser
selecionados posteriormente.
WORKER_INFO:DATA
Diz respeito à resposta por parte do centro ao comando GET_WORKERINFO: que
indica que o utilizador da aplicação selecionou um determinado estafeta e quer saber os
seus dados pessoais (por exemplo, nome). Este comando contém a informação de um
estafeta registado no centro representada pelo parâmetro DATA. Do lado da aplicação
Android, quando ela recebe este comando, a primeira coisa que faz é separar os dados
do comando. De seguida cria um Intent e adiciona-lhe os dados previamente separados
deste comando. Depois é criada e inicializada uma nova atividade (WorkerInfo) que é
Page 104
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
82
responsável por ler os dados (adquirir os dados do Intent) pessoais e colocá-los
conforme o desenho desta nova atividade.
WORKER_LOCATION:LATITUDE;LONGITUDE
Corresponde à resposta por parte do centro ao comando enviado pela aplicação Android,
GET_WORKERLOCATION:. Indica que o utilizador da aplicação selecionou um
determinado estafeta e deseja saber a sua localização mais recente. Assim, este comando
contém a informação da posição geográfica de um estafeta representada no parâmetro
DATA.
No que diz respeito à aplicação Android, quando ela recebe tal comando começa por
separar os dados do comando. Depois cria e inicializa um Intent que contém os dados
previamente separados. Depois é dada ordem de início de uma nova atividade
(WorkerLocation) que é responsável por adquirir nos dados do Intent referentes à
localização geográfica e com recurso à API do Google Maps para Android a aplicação
cria um mapa com um marcador que traduz a posição mais recente do estafeta.
ORDERS:DATA
Indica que utilizador deseja saber quais as encomendas processadas de um determinado
estafeta. Corresponde à resposta do centro ao comando GET_ORDERS:. Este comando
contém todas as encomendas realizadas pelo estafeta, retratadas pelo parâmetro DATA.
Do lado da aplicação Android, quando ela recebe este comando a primeira coisa que faz
é separar as encomendas do comando. Depois cria, inicializa um Intent onde lhe passa
os dados previamente separados deste comando. Depois é iniciada a nova atividade,
OrderList que basicamente está desenhada como uma lista de encomendas ordenadas
por ordem crescente de identificador de encomenda de forma a serem selecionadas
futuramente.
ORDER_INFO:DATA
Diz respeito à resposta do centro ao comando GET_ORDERINFO: enviado pela
aplicação Android. Indica que o utilizador da aplicação selecionou uma encomenda
processada por um determinado estafeta e quer saber as informações dela (por exemplo,
se foi entregue ou não). Este comando contém a informação de uma encomenda que
está representada no parâmetro DATA.
Page 105
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
83
Do lado da aplicação, quando ela recebe este comando começa por separar os dados que
vêm como parâmetro do comando. De seguida é criado e inicializado um Intent onde
lhe associa os dados anteriormente processados. Depois é criada e inicializada uma nova
atividade (OrderInfo), responsável pela leitura e formatação da encomenda conforme o
desenho da atividade.
ORDER_HISTORY:DATA
Corresponde à resposta que o centro tem preparado para o comando
GET_ORDERHISTORY: que indica que o utilizador da aplicação selecionou uma
determinada encomenda de um determinado estafeta e quer saber os pontos geográficos
por onde este passou aquando do processamento da encomenda. Este comando contém a
informação dos vários checkpoints do trajeto da encomenda e estão retratados pelo
parâmetro DATA. No que diz respeito ao tratamento realizado pela aplicação Android,
ela começa por separar o parâmetro DATA do comando. De seguida cria e inicializa um
Intent passando-lhe os dados anteriormente separados. Depois é dada ordem de início
duma nova atividade (OrderHistory) que basicamente lê todas as posições geográficas
do processamento da encomenda. E depois com recurso à API do Google Maps para
Android cria um mapa com marcadores que traduzem essas posições anteriormente
adquiridas.
Page 106
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
84
Explicados todos os comandos reconhecidos na comunicação entre o centro e a
aplicação Android, apresenta-se um resumo dos mesmos nas Tabelas 13 e 14:
Comando Parâmetros Descrição Resposta
AND_REG; - - - - Pedido de conexão por parte
da aplicação Android. Sim
GET_WORKERS; - - - - Pedido ao centro de todos os
estafetas registados nele. Sim
GET_WORKERINFO:ID_WORKER
ID_WORKER –
Identificador do
estafeta.
Pedido ao centro dos dados
pessoais de um determinado
estafeta (ID_WORKER).
Sim
GET_WORKERLOCATION:ID_WORKER
ID_WORKER –
Identificador do
estafeta.
Pedido ao centro da posição
geográfica mais recente de um
determinado estafeta
(ID_WORKER).
Sim
GET_ORDERS:ID_WORKER
ID_WORKER –
Identificador do
estafeta.
Pedido ao centro de todas as
encomendas que um
determinado estafeta
(ID_WORKER) processou.
Sim
GET_ORDERINFO:ID_ORDER
ID_ORDER –
Indentificador da
encomenda.
Pedido ao centro dos dados
referentes a uma determinada
encomenda (ID_ORDER) que
um estafeta processou.
Sim
GET_ORDERHISTORY:ID_ORDER
ID_ORDER –
Indentificador da
encomenda.
Pedido ao centro de todas as
localizações geográficas do
trajeto de uma determinada
encomenda (ID_ORDER) que
um estafeta processou.
Sim
Tabela 13 – Comandos que o centro reconhece provenientes dos dipositivos Android
Page 107
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
85
Até aqui foram resumidos os comandos que o centro reconhece e que têm como fonte a
aplicação Android. De seguida apresenta-se o resumo dos comandos enviados do centro
para a aplicação:
Comando Parâmetros Descrição Resposta
REG_OK:IP:PORTA; IP – endereço IP;
PORTA – valor da porta.
Resposta ao pedido de
conexão. Comunicação por
servidor/cliente TCP/IP.
Não
REG_OK:NO_IP; - - - -
Resposta ao pedido de
conexão. Não é possível
conectar ao centro.
Não
WORKER_LIST:DATA
DATA – Informação de todos os
estafetas registados no centro (Nome e
Identificador).
Resposta à aplicação Android
ao comando GET_WORKERS;. Não
WORKER_INFO:DATA
DATA – Informação pessoal de um
determinado estafeta. Desta informação
faz parte:
o Nome;
o Rua;
o Localidade;
o Código Postal;
o Nº Telefone;
o Estado.
Resposta à aplicação Android
ao comando
GET_WORKERINFO:. São
enviadas as informações
pessoais de um estafeta.
Não
WORKER_LOCATION:
LATITUDE;LONGITUDE
LATITUDE – Latitude de um estafeta;
LONGITUDE – Longitude de um
estafeta.
Resposta à aplicação Android
ao comando
GET_WORKERLOCATION:.
É enviada a posição mais
recente de um estafeta.
Não
ORDERS:DATA
DATA – Informação de todas as
estafetas processadas por um estafeta
(Identificador e nome do cliente).
Resposta à aplicação Android
ao comando GET_ORDERS:. Não
ORDER_INFO:DATA
DATA – Informação detalhada de uma
determinada encomenda. Desta
informação faz parte:
o Data e Tempo de inserção;
o Nome do estafeta;
o Nome do cliente;
o Tempo de início;
o Tempo de fim;
o Estado.
Resposta à aplicação Android
ao comando
GET_ORDERINFO:. É
enviada as informações de uma
encomenda.
Não
ORDER_HISTORY:DATA
DATA – Informação de todas posições
geográficas do trajeto de uma
encomenda.
Resposta à aplicação Android
ao comando
GET_ORDERHISTORY:. É
enviada as localizações do
trajeto de uma encomenda.
Não
Tabela 14 – Comandos que o centro envia à aplicação Android
Page 108
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
86
13.3. Subsistema de comunicação
É um subsistema muito importante para o sistema, uma vez que é responsável pela troca
de informação/dados entre o centro com as unidades de localização móveis e dipositivos
Android e vice-versa. Quando se fala em troca de informação, isto inclui a receção ou
envio quer no centro ou nos dispositivos Android. Basicamente este subsistema permite
que o centro ou a aplicação Android recebam ou enviem dados. O centro pode receber
ou enviar dados com as unidades móveis ou com a aplicação Android. As unidades de
localização móveis e os dispositivos que suportem Android somente podem trocar
informação com o centro.
Na secção “Cliente/Servidor TCP/IP” do capítulo “Interfaces com o Hardware” já foi
explicado como configurar o servidor e cliente TCP/IP e como implementar a thread
responsável por lidar com os novos pedidos de conexão. Neste momento só falta
apresentar como foi implementado a thread responsável pela receção (Ilustração 36) e
envio (Ilustração 37) de dados entre o servidor e o cliente TCP/IP.
Ilustração 36 – Fluxograma da thread responsável pela receção de dados
No fluxograma da Ilustração 36 pode-se ver que é necessário começar pela obtenção do
stream através do método GetStream() que pertence à classe TcpListner. Este método
retorna informação do tipo NetworkStream que é usado para receber dados de um
determinado cliente. Depois de obter então o stream, é importante verificar se há dados
para ler. Em caso afirmativo, essa informação tem de ser lida (método Read() da classe
Page 109
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
87
NetworkStream) e convertida de bytes para string uma vez que são comandos
específicos que o centro recebe das unidades de localização móveis. Por outro lado,
caso não haja dados para ler, o cliente é desconectado do servidor.
Ilustração 37 – Fluxograma da thread que processa do envio de dados
Tal como no caso anterior, no fluxograma da Ilustração 37 é necessário começar pela
obtenção do stream e verificar se existem dados para enviar para o cliente TCP/IP. Em
caso negativo, o cliente é desconectado. Por outro lado se houverem dados para enviar,
a informação é convertida de string para bytes e enviada pelo stream anteriormente
obtido. No final, é necessário limpar todos os buffers utilizados pelo stream através do
método Flush() pertencente à classe NetworkStream.
Tal como já foi referido muitas vezes é possível comunicar com a unidade de
localização móvel ou através do cliente/servidor TCP/IP ou pela rede móvel GSM (será
necessário equipamento que suporte essa rede). Assim, nesta parte do capítulo é
explicado como é implementado a comunicação com as unidades de localização através
da rede GSM (ver Ilustração 38, Ilustração 39, Ilustração 40 e Ilustração 41).
Page 110
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
88
Ilustração 38 – Fluxograma para leitura de dados pela rede GSM
Na Ilustração 38 está traduzida a implementação da leitura de mensagens enviadas pela
unidade de localização móvel para o centro. Primeiro é necessário saber se o modo
comportamental do modem está configurado de modo a detetar novas mensagens
recebidas. Caso não esteja, é necessário ativar essa opção para assim o centro ser capaz
de detetar a receção de mensagens. Quando uma mensagem é recebida, a função de
atendimento criada na configuração e conexão (serialPort2_DataReceived) do modem
ao centro é chamada pois foi escrita informação na porta. Quando se recebe uma
mensagem, o buffer tem o seguinte aspeto:
A aplicação analisa o buffer da porta-série associada ao modem e verifica se este
começa por +CMTI:, que é o mesmo que dizer que uma mensagem foi recebida.
+CMTI: “SM”, 1
Page 111
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
89
Ilustração 39 – Fluxograma da rotina Ler mensagem
No caso afirmativo, entra-se na sub-rotina Ler mensagem retratada pela Ilustração 39.
Esta rotina é responsável por pegar extrair do buffer da porta-série o índice da
mensagem no cartão SIM para depois pedir ao modem através do comando AT+CMGR
para ler o corpo da mensagem enviada pela unidade de localização móvel, como por
exemplo:
Ou seja, ordena-se ao modem GSM para ler a mensagem que tem a posição 1 no cartão
SIM.
Ilustração 40 – Fluxograma da rotina Tratar mensagem lida
AT+GMGR = 1
Page 112
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
90
Por outro lado, se o buffer não contém +CMTI: pode ser que comece por +CMGR: que
significa que o modem leu o corpo da mensagem. Neste caso, é necessário limpar o
buffer para só ficar com o que realmente a unidade de localização móvel enviou para
posteriormente ser analisado pela rotina responsável para processar essa informação,
nomeadamente ver se corresponde a algum dos comandos que o centro reconhece. Por
fim, ordena-se ao modem para eliminar a mensagem através do comando AT+CMGD,
como por exemplo:
Ou seja, o modem vai eliminar a mensagem com o índice 1 do seu cartão SIM e não
ocupar memória desnecessariamente.
Deste modo foi explicado como se implementou a leitura de mensagens enviadas pela
unidade de localização móvel e como o centro processa essa leitura. De seguida,
descreve-se como o centro faz o oposto, isto é, envia mensagens para as unidades
móveis (ver Ilustração 41).
Assim, antes de enviar a mensagem é necessário saber se o modem continua conectado
ao centro e o modo de texto da mensagem. Depois faz-se um pedido ao modem através
do comando AT+CMGS para enviar uma mensagem para o número da unidade de
localização móvel, como por exemplo:
Depois de o modem processar e validar este comando, é escrito para a porta-série a
mensagem que se deseja enviar agregado no final do carater CRTL-Z. No final, é
necessário saber se a mensagem foi enviada com sucesso, ou seja, verificar no buffer da
porta-série se existe uma notificação OK.
AT+CMGD = 1
AT+CMGS = 912890478
Page 113
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
91
Ilustração 41 – Fluxograma para a escrita de dados pela rede GSM
Portanto, fica demonstrado como o servidor TCP/IP lê e envia os seus comandos dos e
para os clientes TCP/IP. Mas também como ler e enviar dados para o caso particular da
comunicação se processar por rede GSM entre o centro e alguma unidade de localização
móvel.
13.4. Tratamentos de erros e alertas
Neste secção é explicado como o tratamento dos erros e alertas especificados na secção
“Deteção de erros e alertas” do capítulo “Especificação de software a utilizar” é
realizado. No que diz respeito aos erros, tal como se devem recordar foram
especificados três possíveis erros:
aquisição;
tratamento;
e comunicação.
Basicamente, estes representam os erros dos subsistemas de software que compõem o
sistema desenvolvido.
No que diz respeito ao seu tratamento, ele é igual para os três casos. Consiste
principalmente em deixar o gestor do centro ou utilizador da aplicação Android
Page 114
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
92
consciente do que aconteceu, e além disso, esclarecê-lo com uma pequena descrição do
sucedido. E em alguns casos, na descrição pode vir a solução para a resolução do
problema.
No caso da aplicação centro de monitorização para PC, o gestor do centro é avisado da
ocorrência dos vários erros através de caixas de diálogo, possíveis devido à existência
na linguagem C# da classe MessageBox. Basicamente são exibidas caixas de diálogo
que contêm determinado texto, ilustrações e emitem som de forma a captar a atenção do
gestor, tal como está demonstrado na Ilustração 42:
Ilustração 42 – Exemplo de uma caixa de diálogo (MessageBox)
Ainda para o centro foi implementada outra maneira de exibir o texto associado aos
erros que informa e ajuda o gestor a tomar algumas decisões. Com o mesmo objetivo
mas não tão poderosa, pois não faz parar o processo (como as MessageBoxs). Deste
modo, a aplicação C# também utiliza a classe StatusStrip que consiste em apresentar
texto (no caso das StatusLabels) no canto inferior esquerdo das Windows Forms
(contorno verde na Ilustração 43). É muito útil e ideal para aqueles erros que não
colocam a aplicação do centro em risco.
Ilustração 43 – Exemplo da utilização das StatusLabels
Para a aplicação Android estas notificações são implementadas através dos Toasts. Não
são nada mais do que mensagens que aparecem na superfície da janela. Este tipo de
notificação desaparece automaticamente da janela e não aceita interação com ela. A
Ilustração 44 mostra um exemplo de uma notificação do tipo Toast:
Page 115
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
93
Ilustração 44 – Exemplo da utilização dos Toasts
No que diz respeito aos alertas, tal como foi especificado podem haver três alertas
possíveis:
nova encomenda;
localização;
e desvio de trajeto.
Para uma unidade de localização móvel receber um alerta de nova encomenda, o gestor
do centro tem à zona de inserção de encomendas na base de dados e adicionar uma nova
encomenda (MainForm > DataBase > Orders > Add…) com determinadas
especificações (por exemplo, o cliente). Só assim é que este alerta é enviado para o
estafeta através do comando SET_REQ reconhecido pelo centro.
O alerta de localização ocorre quando o gestor do centro está a comunicar com a
unidade de localização móvel por rede GSM e então, como a posição dela deixa de ser
enviada de forma automática, o gestor tem de enviar o alerta de localização para a
unidade de localização (comando GET_LOCATION).
Por fim, o alerta de desvio de trajeto faz parte da funcionalidade da aplicação PC.
Através desta funcionalidade o centro é capaz de saber quando um estafeta está
demasiado longe da sua rota. Assim é enviado automaticamente o alerta de desvio de
trajeto para o estafeta através do comando OUT_ROUTE.
Agora que acabou a descrição dos subsistemas do centro, resta explicar como foi
conseguido o sincronismo entre eles, uma vez que alguns dos subsistemas estão
implementados como threads pelo partilham dados entre si. Foi necessário garantir por
exemplo, que duas threads não acedam a um recurso ao mesmo tempo. Assim, este
sincronismo é conseguido através da declaração lock. O lock é uma declaração que pode
ser utilizada para garantir que um bloco de código é executado por uma única thread até
à sua conclusão.
Page 116
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
94
A uma declaração lock é passado um objeto como argumento, seguido por um bloco de
código que deve ser executado por uma thread de cada vez (ver Ilustração 45).
Ilustração 45 – Exemplo da utilização da declaração lock
Se um bloco de código estiver já a ser executado por uma determinada thread, assim
que outra thread tentar aceder a esse mesmo bloco, ela fica bloqueada. Assim que a
secção de código seja libertada, a thread bloqueada passará para o estado de execução.
Page 117
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
95
14. Interfaces gráficas das aplicações
Neste capítulo serão apresentadas as interfaces gráficas das duas aplicações
desenvolvidos, a aplicação C# e a aplicação Android.
14.1. Aplicação Servidor em C#
Aqui irão ser apresentados os dezassete Windows Forms, algumas tomadas de decisões
e para que servem. Quase todos os Forms foram construídos conforme as aplicações
modernas, ou seja, com barras de menu, atalhos e estado. Assim, desta aplicação do tipo
servidor na linguagem C#, existem os seguintes Windows Forms:
AboutForm;
BackupForm;
CenterLocationForm;
ClientForm;
ClientMapForm;
CommunicationForm;
LoginForm;
LoginChanger;
MainForm;
OrderForm;
OrderMapForm;
ProductForm;
RemoveForm;
SearchForm;
SpecificWorker;
Splash;
WorkerForm.
Page 118
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
96
AboutForm
Este Windows Form10
permite ao gestor saber algumas informações sobre a aplicação,
como por exemplo, a versão, quem desenvolveu a aplicação, entre outras coisas.
Ilustração 46 – AboutForm.cs
BackupForm
Permite ao gestor do centro configurar as opções para uma das funcionalidades
implementadas neste sistema, realizar cópias de segurança da base de dados local
(detalhado no capítulo das “Funcionalidades”). Neste Form é possível configurar a
aplicação para fazer cópias de segurança de forma automática diariamente,
semanalmente ou mensalmente, às horas que o gestor bem entender. Mas se o gestor do
centro quiser ser ele a fazer a cópia de segurança, opta pela opção manual. A Ilustração
47 retrata então, a interface deste Form.
10
Ou Form, é o nome dado à interface gráfica de programação de aplicações incluído como parte da
Microsoft .NET Framework.
Page 119
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
97
Ilustração 47 – BackupForm.cs
CenterLocationForm
O Windows Form representado na Ilustração 48 possibilita ao gestor do centro através
da API do Google Maps transmitir à aplicação as corretas coordenadas da posição
geográfica do centro para qual este sistema pertence. Isto é necessário para o correto
funcionamento da funcionalidade que ajuda o gestor do centro a escolher o estafeta mais
próximo do centro para processar uma determinada encomenda no mínimo tempo
possível.
Ilustração 48 – CenterLocationForm.cs
Page 120
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
98
ClientForm
Este Windows Form traduz o comportamento da base de dados com os clientes. Ou seja,
nele é possível adicionar ou editar as informações de um determinado cliente. A
Ilustração 49 representa o caso de adicionar. Do lado esquerdo estão os campos a ser
obrigatoriamente preenchidos de acordo com algumas diretrizes (como por exemplo, o
campo Name não pode conter números). Quando tudo estiver correto, já não haverão
pontos de exclamação (bolas a vermelho na Ilustração 49) e o cliente pode ser
adicionado com sucesso. Os campos Latitude e Longitude como se pode verificar são
somente de leitura e são preenchidos automaticamente de acordo com a morada do
cliente (possível devido ao às potencialidade do Google Maps) ou então corrigidos
automaticamente quando uma entrega é concluída com sucesso, uma vez que quando
uma encomenda é entregue com sucesso são gravadas as coordenadas do local de
entrega.
Ilustração 49 – ClientForm.cs
O lado direito é composto por um monitor da base de dados concentrado na tabela client
da base de dados. Isto permite ao gestor, uma visão pelos diversos clientes já inseridos e
também para confirmar se os dados do cliente são inseridos corretamente.
ClientMapForm
Este Form foi construído para corrigir a posição gerada pelo Google Maps, uma vez que
pode sempre existir um erro de poucos metros da real morada do cliente devido à
conversão da morada para coordenadas geográficas. Assim, quando o gestor quiser
Page 121
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
99
editar dados de um cliente esta funcionalidade fica ativa. Para corrigir a posição basta
premir no sítio correto no mapa que do marcador será atualizada.
Ilustração 50 – ClientMapForm.cs
CommunicationForm
A Ilustração 51 demostra o menu de configuração das comunicações com o módulo
RFID e modem GSM. É ideal para quando a conexão automática destes dipositivos não
for possível. Permite ao gestor do centro ligar ou desligar qualquer um destes
dispositivos de uma forma manual. Basicamente, o gestor só precisa de escolher a porta
COM onde o dispositivo está conectado no PC e premir no botão Connect.
Ilustração 51 – CommunicationForm.cs
Page 122
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
100
LoginForm
Este Windows Form retrata o menu de autenticação do centro. Só o gestor do centro
deve possuir as credenciais deste sistema, o username e a consequente password. Como
é natural sem realizar autenticação com sucesso não é possível entrar na aplicação
servidor. Por defeito, quando a aplicação é instalada no PC e utilizada pela primeira vez
os valores do username e password é admin e posteriormente poderão ser alterados no
Form LoginChanger (Ilustração 53).
Ilustração 52 – LoginForm.cs
LoginChanger
Este Windows Form permite ao gestor do centro alterar o username e password que
servem para ele se autenticar no centro. No lado direito Windows Form da Ilustração 53
estão representados os campos editáveis. O primeiro campo é automaticamente
preenchido com o valor do username em vigor (se o gestor quiser modificá-lo, deve
fazê-lo).
Ilustração 53 – LoginChanger.cs
Page 123
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
101
O campo Old Password tem de ser preenchido com o valor da palavra-chave ainda em
vigor. Os terceiro e quarto campos são preenchidos com o valor que o gestor queira dar
à nova palavra-chave. Só será possível guardar as novas credenciais se estiver tudo
correto.
MainForm
A Ilustração 54 pertence ao principal Form do centro de monitorização que é onde
quase tudo se processa. Ele é constituído por um sistema de navegação moderno tal
como, para quase todos os outros Windows Forms através das barras de navegação.
Depois possui uma lista onde estão todos os estafetas registados no centro. Esta lista
apresenta os dados mais importantes neste momento para o gestor, ou seja, o
identificador do estafeta, o nome dele, e a descrição do estado dele para com o centro.
No lado direito deste Form está representado um grande mapa. Este mapa tem o
objetivo de mostrar a posição geográfica de todos os estafetas ligados ao centro através
das unidades de localização móveis.
Ilustração 54 – MainForm.cs
No canto superior direito da Ilustração 54, o gestor tem conhecimento do estado da rede
internet (G significa que tem rede) e se o modem GSM está ou não conectado e
configurado com o centro (neste caso, não está).
Page 124
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
102
Por fim, no final da janela existe uma barra do tipo StatusLabel que tem a função de
informar o gestor do centro de alguns acontecimentos ou de alguns erros que não
colocam em risco o funcionamento do centro. De notar que é a partir deste Windows
Form que nascem todos os outros.
OrderForm
Tal como o ClientForm, este Windows Form para encomendas permite adicionar ou
editar as informações das encomendas. A Ilustração 55 representa o caso de adicionar.
Assim, do lado esquerdo é onde estão os campos que têm de ser obrigatoriamente
preenchidos de acordo com algumas imposições (como por exemplo, o valor quantidade
só pode tomar números). Quando tudo estiver correto, já não haverão pontos de
exclamação, e o pedido de encomenda pode ser adicionado e encaminhado para o
estafeta com sucesso.
No campo Client (ID) estão disponíveis os clientes registados na base de dados do
centro. No caso do campo Worker (ID) só aparecem os estafetas que estão disponíveis
para processar encomendas. Do lado direito deste campo na Ilustração 55, existe um
botão que mostra a distância e tempo que o estafeta está do centro, para assim, ser
selecionado o estafeta mais perto de si. Tal como no campo Client (ID), no Product ID
estão disponíveis os produtos registados. Relativamente ao campo Order Date, este é
preenchido automaticamente aquando do clique no botão Save com a data e tempo do
sistema onde está instalada a aplicação.
Ilustração 55 – OrderForm.cs
Page 125
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
103
O lado direito da Ilustração 55 é composto por um monitor da base de dados
concentrado na tabela order. Isto permite ao gestor uma visão por todas as encomendas
já inseridas. No caso de o gestor querer editar uma encomenda, o monitor só é composto
pelas encomendas que não foram aceites pelos seus estafetas primeiramente escolhidos
para o seu processamento.
OrderMapForm
Tal como foi referido no Form anterior, ao premir no botão ao lado do campo Worker
ID aparece um novo Windows Form, representado pela Ilustração 56. Ele representa um
auxílio para o gestor relativamente à escolha do melhor estafeta para realizar uma
encomenda. Deste modo, com recurso novamente às potencialidades da API do Google
Maps, é traçada uma rota de A a B. O ponto A represente a localização do centro e B, a
posição do estafeta. Depois serão calculados a distância entre os dois pontos e uma
estimativa do tempo que o estafeta demorará em condições normais a chegar ao centro.
Ilustração 56 – OrderMapForm.cs
ProductForm
A Ilustração 57 representa o caso de edição dos dados de um produto. Este Windows
Form retrata a inserção ou edição de produtos que o centro tem disponíveis e que fazem
parte das encomendas. Tal como os outros Forms deste género, do lado esquerdo é onde
estão os campos que têm de ser obrigatoriamente preenchidos de acordo com
Page 126
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
104
determinadas normas. Quando tudo estiver corretamente preenchido, já não haverão
pontos de exclamação e o produto pode ser adicionado ou editado com sucesso.
Ilustração 57 – ProductForm.cs
RemoveForm
A Ilustração 58 representa o menu de remoção de dados do centro de monitorização e
no caso específico, a remoção de um estafeta da base de dados. Basicamente este Form
é composto por um monitor que mostra consoante a tabela, os dados já inseridos na base
de dados. Depois basta selecionar o item que se deseja remover e premir no botão
Remove.
Ilustração 58 – RemoveForm.cs
É possível remover estafetas, encomendas, produtos e ainda de clientes.
Page 127
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
105
SearchForm
Este Form traduz o menu de pesquisa do centro. É possível pesquisar por estafetas,
clientes (no caso da Ilustração 59), encomendas e produtos. Basicamente, ele é
composto por um comboBox responsável pela escolha do campo que se pretende
pesquisar (pelo identificador da tabela client no caso da Ilustração 59). Ao lado
comboBox, existe uma caixa de texto para ser preenchida com parte ou totalidade do
que se pretende procurar. Depois de preenchidos os campo, só resta premir no botão
Search.
Ilustração 59 – SearchForm.cs
No caso da pesquisa recair nas informações de clientes, existe a possibilidade de ver a
sua localização geográfica (depois de selecionar um cliente no monitor) num Form do
tipo ClientMapForm (ver Ilustração 50). Para tal efeito, basta na barra de menus, ir a
View e depois premir em Map….
SpecificWorkerForm
Este Form é composto por três secções, a History, Last Location e Send Message
presentes na Ilustração 60. Para entrar neste Form, somente é necessário premir duas
vezes sobre um estafeta ou num botão na barra de Menu do MainForm representado
pela Ilustração 54.
A primeira secção é constituída por uma lista que representa a tabela coordinates, isto é,
uma lista com as coordenadas do estafeta. É possível ordená-las por data ou por
Page 128
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
106
identificador de encomenda. Neste último caso, no mapa ao lado é gerado a rota
realizada pelo estafeta com cada coordenada representada por um marcador.
A segunda secção é composta por um mapa com o objetivo de mostrar a ultima posição
do estafeta desde que conectado ao centro. Também é aqui que é detetado se o estafeta
está no caminho correto. Caso não esteja é automaticamente enviado o alerta.
Ilustração 60 – SpecificWorkerForm.cs
A última secção representa a vontade do gestor do centro comunicar com estafeta,
enviando-lhe uma mensagem com o texto que pretender. Depois carregue-se no botão
Send Message e espera-se que a mensagem seja enviada com sucesso. Por fim, reparar
no canto superior direito a label que informa o gestor do tipo de comunicação que este
está a ter com o especifico estafeta. No caso da Ilustração 60, o gestor não estava
comunicando (No Communication) com o estafeta, uma vez que este nem autenticado
estava ao centro.
Page 129
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
107
Splash
Este Windows Form representa o intro da aplicação. Possui um logótipo da aplicação
para PC do centro de monitorização, a versão dela e uma barra progressiva visualmente
atrativa.
Ilustração 61 – Splash.cs
WorkerForm
Este Windows Form possibilita ao gestor do centro adicionar ou editar informações no
que diz respeito aos estafetas. A Ilustração 62 representa o caso de adicionar. Assim, do
lado esquerdo aparecem aos campos que obrigatoriamente têm de ser preenchidos de
acordo com determinadas normas. Quando tudo estiver correto, o estafeta pode ser
adicionado com sucesso.
Ilustração 62 – WorkerForm.cs
O lado direito da Ilustração 62 é composto por um monitor concentrado na tabela
worker. Isto permite ao gestor uma visão por todos os estafetas inseridos e todos os seus
dados.
Page 130
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
108
Caso seja adicionado com sucesso ou o gestor estiver em modo de edição, depois de
premir num dos estafetas do monitor tem a possibilidade de guardar para uma etiqueta
RFID, os dados referentes a esse item selecionado.
14.2. Aplicação Cliente para Android
Nesta secção irão ser apresentados os oito layouts que constituem a aplicação cliente
para dispositivos Android. Quase todos os layouts foram construídos de uma forma
simples como é característica fundamental deste tipo de aplicações. Assim para esta
aplicação do tipo cliente existem os seguintes layouts:
main;
worker_list;
specific_w;
workerinfo;
workerlocation;
orderlist;
orderinfo;
orderhistory.
main
Este layout (Ilustração 63) é o que aparece ao utilizador quando abre a aplicação
Android. Aqui tem o nome do projeto, CrewTrack. Depois apresenta uma barra
progressiva circular que indica que aplicação está a espera de conexão com o centro.
Ilustração 63 – main.xml
Page 131
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
109
Logo que inicie o layout da Ilustração 63, surge uma caixa de diálogo a pedir ao
utilizador que introduza o número do centro de monitorização. Como já foi explicado
em capítulos anteriores, a aplicação Android necessita de pedir o endereço IP e porta
para se conectar como cliente TCP/IP.
worker_list
A Ilustração 64 representa o layout da atividade worker_list que basicamente ordena os
trabalhadores registados no centro por ordem de identificação. Depois fica à espera que
o utilizador selecione um deles para entrar no seu menu específico.
Ilustração 64 – worker_list.xml
specific_w
Este layout representado pela Ilustração 65 está associado à atividade Specific_Worker
que diz respeito ao menu do estafeta e o que é possível saber sobre ele. Em primeiro
lugar, o utilizador vê uma label com nome e identificador do estafeta selecionado.
Depois tem à sua disposição quatro botões que permitem saber de forma precisa dados
relativos aos estafetas e às encomendas processadas. Por fim, cada botão conduz a uma
nova atividade e consequente layout.
Page 132
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
110
Ilustração 65 – specific_w.xml
workerinfo
A Ilustração 66 representa o layout da atividade WorkerInfo e diz respeito à informação
detalhada do estafeta selecionado anteriormente. Neste layout como é possível ver pela
ilustração abaixo existem várias etiquetas de texto com a informação que está presente
na base de dados do centro. No fim, existe um botão com a função de voltar ao menu
anterior, case o utilizador assim o deseje.
Ilustração 66 – workerinfo.xml
workerlocation
Este layout representado pela Ilustração 67 está associado à atividade WorkerLocation
que diz respeito ao mapa com a posição mais recente do estafeta anteriormente
selecionado.
Basicamente existe um objeto do tipo MapView que recebe as coordenadas do centro de
monitorização e as traduz num marcador no mapa. Isto só foi possível devido à API do
Page 133
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
111
Google Maps para aplicações Android (não tão poderosa como a JavaScript API
implementada no centro).
Ilustração 67 – workerlocation.xml
orderlist
O layout representado pela Ilustração 68 pertence à atividade OrdersList que diz
respeito ao menu das encomendas que o estafeta anteriormente processou. Basicamente
este layout está desenhado para ter todas as encomendas ordenadas por identificador de
encomenda para quando o utilizador o desejar selecionar. Basicamente este layout pode
ser visto como um menu de seleção.
Ilustração 68 – orderlist.xml
orderinfo
Tal como o layout da Ilustração 66, o layout representado pela Ilustração 69 diz respeito
à informação detalhada de uma encomenda realizada por um estafeta.
Page 134
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
112
Neste layout como é possível ver pela ilustração abaixo existem várias etiquetas de
texto com a informação que está na base de dados do centro (como por exemplo, tempo
de início ou fim da encomenda).
Ilustração 69 – orderinfo.xml
No fim existe um botão que tem a função de voltar ao menu anterior, case o utilizador
assim o deseje.
orderhistory
Este layout representado pela Ilustração 70 está associado à atividade OrderHistory e
representa os pontos geográficos por onde passou uma encomenda processada por um
estafeta, selecionado anteriormente. Basicamente existe um objeto do tipo MapView que
recebe as várias coordenadas do centro de monitorização e elas ficam representadas em
vários marcadores no mapa.
Ilustração 70 – orderhistory.xml
Page 135
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
113
Como é possível pela Ilustração 70, a API aqui utilizada só permite colocar os
marcadores, ou seja, não foi possível gerar a rota entre eles como acontece na aplicação
desenvolvida para PC.
Page 136
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
114
15. Funcionalidades
Nesta secção vão ser apresentadas funcionalidades que a aplicação centro de
monitorização para PC tem a seu dispor. São funcionalidades que foram vistas como
uma maior valia para o sistema e sobretudo para quem o utiliza, nomeadamente o gestor
de centro.
15.1. Google Maps
É considerada das funcionalidades mais importantes do centro de monitorização, uma
vez que com recurso à sua API é possível implementar uma infinidade de serviços,
desde mostrar a localização geográfica dos estafetas, gerar de rotas, entre outras coisas.
O sistema desenvolvido utiliza a JavaScript API V3 do Google Maps11
de modo a
implementar e incorporar os mapas em páginas Web. Deste modo, na aplicação na
linguagem C# sempre que um Windows Form utiliza recurso das do Google Maps, no
desenho da interface tem de ser composta por um objeto da classe WebBrowser. Este
objeto permite a navegação em páginas Web dentro de um Windows Form. Para tornar
isto possível foram criados ficheiros com extensão HTML (cada Form que é composto
por um objeto WebBrowser tem um ficheiro HTML associado) com o código JavaScript
da API. Depois através do método Navigate, as páginas são carregadas, como por
exemplo:
Onde sitePath corresponde à localização do ficheiro que se pretende carregar. Portanto
foram implementados os seguintes ficheiros:
GOOGLE_MAPS_CENTERLOCATION – referente à Form da Ilustração 48;
GOOGLE_MAPS_CLIENTS – referente à Form da Ilustração 50;
GOOGLE_MAPS_FORM1 – referente à Form da Ilustração 54;
GOOGLE_MAPS_FORM3 – referente à Form da Ilustração 60;
11
www.developers.google.com/maps/documentation/javascript/
webBrowser1.Navigate(sitePath);
Page 137
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
115
GOOGLE_MAPS_ORDERS – referente à Form da Ilustração 56.
Em todos documentos atrás especificados foi necessário:
a) Declarar o ficheiro como HTML5 usando a declaração <!DOCTYPE html>;
b) Carregar a API do Google Maps;
c) Criar um elemento div chamado map_canvas para suportar o mapa;
d) Criar um objeto JavaScript para conter diversas propriedades do mapa;
e) Escrever uma função JavaScript para criar um objeto map;
f) Inicializar o objeto do mapa a partir do evento onload.
Depois de explicar como é implementado de um modo geral para todos os ficheiros, é
altura de entrar em cada um e explicar o que trazem de novo para o sistema.
GOOGLE_MAPS_CENTERLOCATION
Neste ficheiro HTML existem três funções: MAP_INIT(), calcLocationCenter(),
changeLocationCenter(lat, long). A primeira função é chamada sempre que a página é
carregada. É composta pela configuração do mapa que é inicializado:
centro do mapa em 41.452281, -8.290896 (não obrigatoriamente estas);
zoom com valor 6;
tipo de mapa, ROADMAP;
adicionado controlos:
o panorâmica;
o zoom;
o escala;
o tipo de mapa;
o visão geral.
De seguida é inicializado o mapa com as opções anteriormente adicionadas.
Relativamente à segunda função, ela é responsável por indicar à aplicação as
coordenadas geográficas que o mapa retorna quando o gestor carregue no mapa de
modo a indicar a correta posição do centro. Assim, é criado um evento do tipo click que
fica à espera que o gestor clique em algum local. Quando isso acontece, é adicionado
Page 138
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
116
um marcador no local do clique e o mapa é centrado nessa nova localização. De
seguida, é criado um evento para quando se carrega no marcador. Basicamente ao
premir no balão surge um balão informativo com o texto StoreHouse (ver Ilustração
71). Esta função invoca uma função da aplicação C# onde lhe passa como argumentos a
latitude e longitude da posição premida.
Ilustração 71 – GOOGLE_MAPS_CENTERLOCATION.html
Por último, a função changeLocationCenter é chamada quando já existe uma
localização na informação do centro, por isso é que vêm como parâmetros na função a a
latitude e longitude. Em primeiro lugar, o mapa é centrado nessa localização. Depois é
atualizado o valor do zoom para 14 e o tipo de mapa para ROADMAP. De seguida é
adicionado um marcador nessa localização. Finalmente é invocada a função
calcLocationCenter, uma vez que o objetivo é fazer o mesmo, ou seja, esperar pela nova
localização escolhida pelo gestor.
GOOGLE_MAPS_CLIENTS
Neste documento HTML existem três funções: MAP_INIT(), viewClient(address),
viewClientLatLong(lat, long, address).
A primeira função é chamada logo que a página é carregada sendo composta pela
configuração igual ao mapa do documento anterior.
No que diz respeito à segunda função, esta tem o objetivo converter a morada de um
cliente (parâmetro address presente na base de dados do centro) para coordenadas
Page 139
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
117
geográficas e enviá-las para o centro. Mas essa conversão pode conter um erro de
poucos metros da real morada. Então esta função também permite a correção com o
clique do gestor no local correto. Esta função é somente invocada na primeira conversão
da morada. Deste modo, a função começa por fazer a conversão do parâmetro address
através da função geocode disponibilizada pela API. Se a conversão foi realizada com
sucesso, o mapa é centrado nas novas coordenadas, é atualizado o valor do zoom para
15 e o tipo de mapa para ROADMAP. Ainda é adicionado um marcador na posição, e
quando premido, surge um balão informativo com a morada do cliente (ver Ilustração
72). No caso de ser necessário corrigir a posição anteriormente convertida, esta função
possui um evento que fica à espera de um clique no mapa de forma a corrigir o geocode
anterior.
Em caso de clique, é modificada a posição do marcador e do centro do mapa. Por fim,
são enviadas as novas coordenadas para a aplicação C# a fim de serem atualizados os
dados do cliente na base de dados.
Ilustração 72 – GOOGLE_MAPS_CLIENTS.html
A função viewClientLatLong é chamada quando o cliente tem já coordenadas
geográficas definidas, e como é natural já não é necessário fazer a conversão da morada.
Deste modo, esta função tem que carregar a localização presente em lat e long no mapa
através de um marcador. Depois tem que estar habilitada e detetar o evento de clique no
mapa por parte do gestor com a nova posição da morada do cliente e por fim, enviar os
novos valores da posição para a aplicação.
Page 140
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
118
GOOGLE_MAPS_FORM1
O GOOGLE_MAPS_FORM1 é constituído por três funções, MAP_INIT(),
worker_marker(name, id, lat, lon), workerdelete(id), sendo a primeira igual às duas
anteriores.
A função worker_marker é responsável por adicionar no mapa, um marcador que traduz
a posição mais recente de um estafeta quando este se autentica com o centro. Recebe
como parâmetros o nome, identificador, latitude e longitude. Esta função começa por
alterar o valor do zoom para 14 e cria no mapa um marcador na posição indicada pelo
parâmetro lat e lon. De seguida, é associado a este marcador um evento de clique.
Quando isso acontece, aparece um balão informativo com o nome e identificador do
estafeta (Ilustração 73).
Ilustração 73 – GOOGLE_MAPS_FORM1.html
Por fim, caso já exista um marcador para o mesmo estafeta com uma posição anterior,
este é eliminado (invocando implicitamente a função workersdelete) e o mapa é
ajustado em volta de todos os marcadores que compõem o mapa através da função
fitBounds.
A última função, workersdelete basicamente existe para eliminar marcadores, ou
marcadores de posições antigas, ou marcador que pertença a um estafeta que acabe de
fazer logout do centro de monitorização.
Page 141
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
119
GOOGLE_MAPS_FORM3
Este documento é o que utiliza mais recursos da API e é composto por cinco funções:
MAP_INIT();
GEO_P(lat, long);
calcHistory(coordinates);
routeOrder(coordinates);
geoficing(coorCheckPoint, coorWorker, finishPoint).
A segunda função, GEO_P é responsável por mostrar a posição mais recente do estafeta
no mapa (instanciado na primeira função). Esta função começa por limpar todos
marcadores ou figuras geométricas presentes no mapa. Depois centra o mapa na posição
enviada pelo centro através dos parâmetros lat e long. É atualizado o valor do zoom para
18, criado o marcador que traduz visualmente a posição do estafeta e ainda criada uma
circunferência de um quilómetro de raio à volta do marcador (para funcionalidade que
deteta se aconteceu desvio de trajeto).
A função calcHistory tem o objetivo de mostrar no mapa o trajeto percorrido pelo
estafeta no processamento de uma encomenda. O parâmetro coordinates representa
todas as coordenadas associadas à encomenda para o qual se requereu esta
funcionalidade. A primeira coisa que esta função faz é limpar o lixo do mapa e fornecer
à API os dados referentes a posição de início, fim e checkpoints entre eles. Se tudo
correr como de acordo, é gerada a rota que é traduzida no mapa por marcadores
(Ilustração 74).
Ilustração 74 – GOOGLE_MAPS_FORM3.html (calcHistory)
Page 142
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
120
Quanto à função routeOrder, esta tem o propósito de gerar a melhor rota, da posição em
que o estafeta aceitou a encomenda até à localização do cliente. Ao mesmo tempo,
também deve verificar se o estafeta está dentro ou fora da rota gerada. A função começa
por atualizar o valor do tipo de mapa ROADMAP, depois limpa o mapa de todos os
marcadores existentes. De seguida é configurado o modo de geração da rota, ou seja, é
passado à API a posição de início, de fim, o modo de viagem, evitar autoestradas e
apresentar rotas alternativas. No final é dada a ordem para geração da rota e chamada a
função geoficing que vai verificar se existe ou não desvio de trajeto (ver Ilustração 75).
Ilustração 75 – GOOGLE_MAPS_FORM3.html (routeOrder)
A última função corresponde à função geoficing. Esta função tem como parâmetros as
coordenadas do estafeta, do cliente e de todos os checkpoints. Assim, esta função o que
faz é saber qual o checkpoint (bandeiras azuis da Ilustração 75) mais próximo do
estafeta (marcador verde da Ilustração 75). Ao achar o checkpoint mais próximo é
verificado se este está dentro ou fora do limite da circunferência, ou seja, um
quilómetro.
Ilustração 76 – Instrução enviada ao estafeta
Se estiver fora (caso da Ilustração 75), significa que o estafeta já está algo desviado do
seu original trajeto. Deste modo é invocada uma função da aplicação C# que recebe
como argumento uma instrução para ajudar o estafeta a voltar a rota (ver Ilustração 76).
Page 143
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
121
GOOGLE_MAPS_ORDERS
O documento GOOGLE_MAPS_ORDERS é constituído por duas funções:
MAP_INIT();
viewDistance(coordinates).
A função viewDistance foi implementada para auxiliar o gestor a optar pelo estafeta
mais próximo do centro para processar determinada encomenda.
Ilustração 77 – GOOGLE_MAPS_ORDERS.html
A esta função são fornecidas as informações da posição do estafeta e do centro
(parâmetro coordinates), modo de condução, evitar as autoestradas e gerar rotas
alternativas. Depois é gerada a rota entre A e B como é visível na Ilustração 77. Depois
com recurso a função getDistanceMatrix é calculada a distância e tempo de um ponto ao
outro. A esta função é necessário também fornecer a posição inicial e final. No fim,
estes valores são enviados para a aplicação centro de monitorização e preenchidos no
Form associado.
15.2. Sistema de Autenticação
Por questões de segurança decidiu-se implementar um sistema de autenticação para o
centro de monitorização, nomeadamente para a aplicação C#. E nesta secção irá ser
explicado como foi implementado.
Page 144
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
122
Primeiramente foi criada na base de dados local uma tabela denominada de user, da
qual fazem parte os seguintes atributos:
Tabela Descrição
user
Tabela que contém a informação relativa ao username e password para o sistema de autenticação.
Esta tabela tem os seguintes atributos:
UserID – Identificador do cliente;
Username – Nome do usuário;
Password – Palavra Chave.
Tabela 15 – Descrição da tabela user
Deste modo quando aparecer o Windows Form denominado de LoginForm (Ilustração
52), o gestor preenche os campos do Username e Password e carrega no botão Login. A
aplicação verifica se os valores que estão nas caixas de textos correspondem aos
presentes na base de dados. Se os dois coincidirem, a aplicação avança para o
MainForm. Caso contrário, indica qual o campo que está incorreto.
Deste sistema ainda faz parte o Form responsável pela mudança do nome de utilizador
ou da palavra-chave, o LoginChanger (Ilustração 53). Neste Form basta preencher os
quatro campos. O campo nome de usuário pode ser o que o gestor quiser, o primeiro
campo para a palavra-chave tem que corresponder à palavra-chave em vigor. Depois os
próximos dois campos para a nova palavra-chave têm de ser iguais. Finalmente, se tudo
estiver correto, o botão Save fica ativo e as alterações na base de dados são atualizados
através de querys do tipo UPDATE.
De notar, que na primeira utilização do centro de monitorização os valores do nome do
usuário e palavra-chave são admin.
15.3. Sistema de cópias de segurança da base de dados
Como foi explicado na secção “Base de dados” do capítulo “Especificação de software
a utilizar” este sistema é composto por uma base de dados SQLite local. Deste modo foi
necessário implementar um sistema com a função de fazer cópias de segurança da
maneira que o gestor desejar (automaticamente ou manualmente). É uma funcionalidade
muito útil, uma vez que deste modo existe sempre uma ou mais bases de reserva para o
caso da principal se danificar. Assim não se perde os dados de forma definitiva e além
Page 145
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
123
disso, se instalar a aplicação noutro computador, o centro pode continuar a interagir
com a base de dados mais recente desde que carregada pelo gestor com sucesso.
Este sistema é composto por três subsistemas que irão ser em termos das suas
funcionalidades e implementação das mesmas:
Configurar cópias de segurança;
Carregar base de dados SQLite;
Salvaguardar base de dados SQLite.
Configurar cópias de segurança
Este subsistema está associado ao Windows Form da Ilustração 47. Quando carregado
este Form, a aplicação do centro verifica se existe nos seus recursos o ficheiro
backupData com extensão .config. Este ficheiro contém as opções da última
configuração, como por exemplo:
Caso exista ficheiro, a aplicação lê linha a linha e vai preenchendo o Form conforme a
informação correspondente. Se a aplicação na primeira linha ler A significa que a cópia
de segurança deve ser feita de modo automático (tal como na Ilustração 47). Se ler um
M isso representa cópia de segurança manual, ou seja, é o gestor a fazer a salvaguarda
do ficheiro SQLite.
A segunda linha representa com que regularidade é que a cópia de segurança é feita
(caso modo automático). Se o valor lido for 0, significa que é todos os dias, caso seja 1,
backupData.config:
A
0
17
2012
7
5
Page 146
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
124
a cópia é realizada todas as semanas. Finalmente, se a aplicação detetar um 2, significa
que a cópia é feita de mês a mês.
Na terceira linha vem as horas a que a cópia de segurança da base de dados deve ser
realizada. Basicamente o segundo comboBox (ver Ilustração 47) está preenchido de 0 a
23 e assim, o valor que o gestor selecionar também corresponde ao índice que aparecerá
no ficheiro de configuração.
As restantes linhas correspondem à data da modificação deste ficheiro (Ano, Mês e
Dia), ou seja, neste caso de cima foi em 2012-07-05.
Mas se por acaso for a primeira utilização ou não existir ficheiro, a aplicação cria um
ficheiro e escreve nele as opções por defeito:
Depois de o ficheiro ser carregado com sucesso, o gestor já pode navegar na Form e
configurar as cópias de segurança como desejar. Depois deve premir no botão OK ou
Apply de modo à aplicação tomar em consideração a configuração realizada, ou seja, se
modo automático configurar as interrupções para realizar a cópia a determinado dia e
hora. Se carregar no botão Cancel é mantido a configuração anterior.
Carregar base de dados SQLite
Para tornar possível o carregamento de ficheiros na aplicação C# é necessário ter um
objeto da classe OpenFileDialog que está presente no Form denominado por MainForm
retratado na Ilustração 54. Esta classe permite ao gestor a abertura de arquivos. Para ter
acesso a esta funcionalidade, o gestor deve no MainForm ir à barra de menu e premir
em Tools > Load DataBase (ver Ilustração 78):
backupData.config:
A
0
0
2012
8
15
Page 147
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
125
Ilustração 78 – Carregar ficheiros SQLite
Quando esta janela é aberta, o gestor somente tem de abrir o ficheiro com extensão .db
que deseja e que represente uma base de dados com a estrutura apresentada no capítulo
“Modelação de dados”. De seguida, a aplicação verifica se já existe um ficheiro igual ao
que se pretende carregar. Se existir, é eliminado esse ficheiro. Depois a aplicação copia
o ficheiro carregado pelo gestor para a localização onde o ficheiro SQLite deve estar.
Salvaguardar base de dados SQLite
Para tornar possível a salvaguarda de arquivos na aplicação C# é necessário ter um
objeto da classe SaveFileDialog que está presente no MainForm retratado na Ilustração
54. Esta classe permite ao gestor escolher uma localização para guardar os arquivos,
nomeadamente ficheiros SQLite. Para ter acesso a esta funcionalidade, o gestor deve no
MainForm ir à barra de menu e carregar em Tools > Save DataBase (ver Ilustração 78):
Ilustração 79 – Salvaguardar ficheiros SQLite
Page 148
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
126
Quando esta janela é aberta, o gestor somente tem de escolher o caminho para onde
deseja que seja copiado o ficheiro SQLite com extensão .db. De seguida, a aplicação
verifica se já existe algum ficheiro igual na localização escolhida. Caso exista, ele é
eliminado e copiado o arquivo que é utilizado pela aplicação como base de dados local
para o caminho escolhido pelo gestor.
15.4. Localização do Centro de Monitorização
Esta funcionalidade é implementada no Form denominado de CenterLocationMap (ver
Ilustração 48). Para ter acesso a ela, o gestor necessita de ir à barra de menu do
MainForm > Tools > Change StoreHouse Location. Depois é aberto o
CenterLocationMap onde o gestor só tem de carregar no local correto da loja (ver
Ilustração 80). Quando o novo local é escolhido é invocada uma função na aplicação
denominada de coordinatesCenter que recebe as coordenadas da API do Google Maps e
as atualiza na base de dados através de uma query do tipo UPDATE na tabela center.
Ilustração 80 – Seleção da localização do centro de monitorização
15.5. Lista de espera (encomendas)
Esta funcionalidade é implementada através de uma função da aplicação C#
denominada por waiting_list que recebe como argumento, o identificador de
Page 149
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
127
determinada encomenda. Esta função é invocada quando um estafeta demora mais do
que um minuto a responder ao pedido do gestor para processar a encomenda. Quando
isso acontecer, a aplicação começa por procurar por estafetas disponíveis (valor do
atributo State da tabela worker igual a Connected!) para passar a um deles a encomenda.
De seguida é atualizada na base de dados a alteração do estafeta, enviando o novo
pedido a ele conforme o tipo de comunicação e iniciando novamente o temporizador de
um minuto. Caso não existam estafetas disponíveis para processar a encomenda, esta
fica em lista de espera e volta a ser verificada passada um minuto.
15.6. Escrita de etiqueta RFID dados de um estafeta
Esta funcionalidade é implementada no Form denominado de WorkerForm (ver
Ilustração 62). Para ter acesso a ela, o gestor deve de ir à barra de menu do WorkerForm
> File > Wirte Personal Card. Caso o módulo RFID esteja conectado ao centro de
monitorização e detete a presença de uma etiqueta RFID, este tem permissão para
escrever os dados pessoais do estafeta selecionado. Neste conjunto de dados está
presente o nome do estafeta, morada, contacto telefónico, data de nascimento,
identificador, bem como, o nome de exibição e um código de validação da etiqueta
RFID na unidade de localização móvel. Por outro lado, se as condições não estiverem
reunidas o gestor do centro é avisado.
Page 150
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
128
Page 151
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
129
Testes e Resultados
Neste capítulo são realizados testes do que poderá acontecer numa situação real, ou seja,
irão ser efetuados pedidos de encomendas ao centro de forma a testar e analisar os
consequentes resultados. Ao mesmo tempo irão ser postos à prova todos os subsistemas
pertencentes ao centro de monitorização. Irão ser utilizadas ferramentas, como o
debugger da Microsoft Visual Studio12
e SQLite Administrator para visualização do
conteúdo da base de dados. Deste modo, vão ser realizadas as seguintes experiências:
à ligação e comunicação com as unidades de localização móveis e dipositivos
com a aplicação Android;
à base de dados (manipulação);
à posição de uma unidade de localização móvel no centro;
à funcionalidade que deteta a saída de rota;
ao sistema responsável pelas cópias de segurança da base de dados;
e processamento do uma encomenda.
No final, são realizados testes entre o centro de monitorização e uma unidade de
localização móvel em tempo real que incluirão a instalação do centro de monitorização
num computador, configuração de cópias de segurança, manipulação da base de dados,
registo de unidades, processamento de encomendas e demonstração de algumas das
funcionalidades.
12
www.microsoft.com/visualstudio/
Page 152
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
130
16. Ligação e comunicação com dispositivos do tipo cliente
Tal como já foi expresso no capítulo anterior, são os dispositivos do tipo cliente que têm
de pedir permissão ao centro para se conectarem a ele.
No caso de unidades de localização móveis, estas enviam o comando UNIT_REG que é
recebido pelo centro como se pode ver na Ilustração 81.
Ilustração 81 – Receção do comando por parte da unidade de localização móvel
Depois o centro processa o comando recebido (ver Ilustração 82) e reponde à unidade
de localização móvel com o identificador 00001, ou seja, é enviado o comando
REG_OK por rede GSM, ver Ilustração 83.
Ilustração 82 – Unidade de localização móvel registada com sucesso na base de dados do centro
Neste caso como o servidor TCP/IP está ativo, junto ao comando segue a informação
que a unidade de localização móvel necessita para se conectar ao centro.
Ilustração 83 – Resposta ao pedido de registo da unidade de localização móvel
Depois a unidade de localização móvel envia ao centro um comando que indica qual o
tipo de comunicação que ela pode estabelecer. No caso da Ilustração 84, a unidade de
localização móvel 00001 indica ao centro que está ligado como cliente TCP/IP, pois o
centro recebeu o comando UNIT_USING_GPRS.
Page 153
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
131
Ilustração 84 – Indicação do tipo de comunicação com o centro
Para os dispositivos com a aplicação Android, o processo é muito semelhante. O centro
recebe um pedido para conexão através do comando AND_REG (ver Ilustração 85).
Ilustração 85 – Receção do comando por parte da aplicação Android
Depois o centro só precisa de responder ao pedido, como se pode ver na Ilustração 86.
Ilustração 86 – Resposta ao pedido de registo do dispositivo Android
Page 154
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
132
17. Base de dados
Para testar a base de dados presente no centro, irá ser escolhida uma tabela de modo
aleatório onde será testada a adição, alteração e remoção de dados, por exemplo de
clientes.
Ilustração 87 – Estado da tabela client antes do teste
Na Ilustração 87 está traduzido o conteúdo da tabela cliente, ou seja, existem dois
clientes, a Maria Peixoto e o Pedro Rodrigues. Agora o gestor do centro irá adicionar
um terceiro elemento à tabela como é demonstrado pela Ilustração 88 (o cliente Orlando
Francisco). Do lado esquerdo da ilustração estão os dados associados ao novo elemento,
enquanto do lado direito mostra-se que os dados foram adicionados com sucesso à base
de dados.
Ilustração 88 – Estado da tabela client depois de adicionar um novo elemento
Agora é tempo de alterar alguns dados de um dos elementos. Assim, seleciona-se o
terceiro elemento e irão ser editados os campos Name e ZipCode. O campo Name irá
tomar o valor Carlos Fernandes e o campo ZipCode vai passar a ser 4800 Guimaraes.
Page 155
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
133
Ilustração 89 – Estado da tabela client depois de editar um elemento
Como é visível pela Ilustração 89, o elemento com o identificador de cliente 3 já não
tem o nome Orlando Francisco, nem o mesmo ZipCode.
Neste momento só falta testar a remoção de elementos da base de dados do centro de
monitorização. Para tal, é necessário selecionar um elemento e depois premir no botão
Remove para o eliminar, tal como mostra a Ilustração 90.
Ilustração 90 – Remoção de um elemento da base de dados
Na parte superior da Ilustração 90 apresenta-se a seleção do elemento que atrás foi
adicionado e editado, ou seja, o cliente com identificador 3. Na parte inferior mostra-se
que esse elemento já não faz parte da base de dados, uma vez que foi removido com
sucesso.
Page 156
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
134
18. Posição geográfica de uma unidade de localização móvel
Com este teste quer-se demonstrar que o centro recebe a localização geográfica da
unidade de localização móvel e a traduz corretamente para o mapa do Google presente
no centro de monitorização.
O que se pretende fazer é usar a mesma instrução GGA recebida pelo centro proveniente
de uma unidade móvel e colocá-la no Google Earth13
e verificar se o local marcado é
igual ao que o mapa do centro marca. Em primeiro lugar, uma unidade de localização
móvel caso esteja ligada ao centro e como cliente TCP/IP envia a sua localização de
minuto em minuto como está traduzido na Ilustração 91.
Ilustração 91 – Comando da localização geográfica enviado por uma unidade de localização móvel
Depois de obter a instrução GGA que contém informações como a latitude, longitude e
até a informação horária, o centro processa esse comando e traduz essa informação para
um local no mapa (ver Ilustração 92).
Ilustração 92 – Posição no mapa do centro
13
www.google.com/earth/
Page 157
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
135
Depois cria-se um ficheiro com extensão .nmea e lá dentro coloca-se a mesma instrução
GGA que o centro recebeu, neste caso:
Em seguida, abre-se o Google Earth e importa-se o ficheiro anteriormente criado.
Depois como mostra a Ilustração 93, a posição presente na instrução é carregada para o
mapa do Google Earth.
Ilustração 93 – Posição no mapa Google Earth
Comparando a posição geográfica da Ilustração 92 e da Ilustração 93, conclui-se que se
o mapa do centro acompanha o mapa do Google Earth. Portanto o teste realizado tem
resultado positivo.
$GPGGA,173400.804,4127.1074,N,00817.4859,E,1,06,1.5,123.9,M,55.1,M,,0000*4D
Page 158
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
136
19. Deteção da saída de rota
Neste teste pretende-se testar a eficiência da funcionalidade implementada no centro de
monitorização que indica ao gestor e ao estafeta portador de uma unidade de localização
móvel, a saída ou não da rota recomendada pelo centro de monitorização.
Irão ser realizadas duas experiencias, uma manter o estafeta na rota desejada e ver o que
acontece no centro. Depois testar o caso do estafeta estar a caminhar para locais fora do
considerado admissível.
Em primeiro lugar foi adicionada uma encomenda, enviando o pedido para o estafeta
escolhido para o serviço. Este pedido foi aceito pelo estafeta portador da unidade de
localização móvel.
Ilustração 94 – Correta posição no processamento de um pedido
Tal como se pode ver pela análise da Ilustração 94, no ponto A apresenta-se o local
onde o estafeta aceitou o pedido e a sua localização mais recente. Em B está
representado o seu destino, ou seja, a morada do cliente. O traçado a azul representa a
rota gerada pela função da API do Google Maps. Como se pode observar, neste
momento o estafeta está dentro do correto percurso, visto que o círculo vermelho cobre
o traçado da rota. Deste modo, não é enviado qualquer alerta ou informação para o
estafeta.
A Ilustração 95 já representa uma considerável saída do correto destino. Como se pode
constatar, a posição atual da unidade de localização móvel (marcador cinzento) está fora
Page 159
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
137
da rota recomendada, ou seja, nenhum ponto do círculo vermelho coincide com nenhum
ponto ou checkpoint (bandeiras azuis) do percurso gerado.
Ilustração 95 – Incorreta posição no processamento de um pedido
Deste modo, o centro deteta essa infração e envia um alerta para o estafeta (ver
Ilustração 96). Com este comando é enviada para o estafeta a primeira instrução do
caminho que este deve seguir para voltar à correta posição.
Ilustração 96 – Comando enviado à unidade de localização móvel quando o centro deteta desvio de
rota
Tal como ficou demostrado, este teste também revelou resultados corretos e positivos
do bom funcionamento desta funcionalidade do sistema.
Page 160
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
138
20. Sistema de cópias de segurança
Nesta fase pretende-se colocar à prova o sistema automático de cópias de segurança.
Para tal seleciona-se no menu de configuração das cópias de segurança a opção Make
backups automatically. Depois opta-se pelo Every day e seleciona-se uma determinada
hora. Para este teste escolheu-se as quinze horas, tal como mostra a configuração da
Ilustração 97. Depois espera-se que às quinze horas do dia seja criado no computador
uma cópia do ficheiro da base de dados SQLite dentro da pasta backup.
Ilustração 97 – Menu de configuração para o teste
Tal como se esperava às quinze horas foi criado um ficheiro igual ao que está como
principal para o centro de monitorização na pasta de backups, ver Ilustração 98.
Ilustração 98 – Cópia de segurança do ficheiro de base de dados
Deste modo foi criado o ficheiro _crewt na pasta db/backup junto do ficheiro de
configuração da base de dados.
Page 161
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
139
21. Pedido para processamento de encomenda
Neste último teste pretende-se que o gestor do centro envie um pedido para uma
unidade de localização móvel conectada. Depois o estafeta deve aceitar esse pedido,
receber as informações do cliente e então processar essa encomenda com sucesso. No
final pretende-se ver no centro de monitorização o histórico desse processamento.
Em primeiro lugar é necessária que uma unidade de localização móvel peça para se
conectar ao centro de monitorização tal como o primeiro teste deste capítulo. Depois o
estafeta portador da unidade de localização móvel que estabeleceu a conexão deve
efetuar o login no centro como mostra a Ilustração 99.
Ilustração 99 – Login do funcionário com identificador 2 com a unidade de localização móvel 1
Agora é vez do gestor do centro enviar a requisição de encomenda para este estafeta
(ver Ilustração 100).
Ilustração 100 – Pedido de processamento de encomenda
Ou seja, o estafeta recebe o pedido por parte do centro e aceita. Depois de aceite, a
unidade de localização móvel pede ao centro os dados do cliente selecionado, Pedro
Rodrigues.
Page 162
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
140
Ilustração 101 – Encomenda aceite
Como mostra a Ilustração 101, o estafeta aceitou a encomenda uma vez que o seu estado
passou de Connected para Connected – Busy!. Além disso, no seu menu particular já é
possível visualizar o processamento da encomenda.
Ilustração 102 – Processamento de encomenda concluído com sucesso
No que diz respeito à Ilustração 102, esta traduz que a encomenda foi processada com
sucesso (REQ_DONE) e o histórico do percurso dessa encomenda (identificador 28),
isto é, o trajeto levado a cabo pelo estafeta para concluir o pedido com sucesso. Os
marcadores verdes por ordem crescente do alfabeto representam os locais onde a
unidade de localização móvel enviou a sua localização através do comando
FUNC_GEO. O ponto A representa o local onde a encomenda foi aceite e o ponto F
representa a morada do cliente.
Page 163
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
141
Para terminar esta simulação, só falta ao estafeta se desconectar do centro de
monitorização, para tal o estafeta tem premir num botão da unidade de localização
móvel. Ao mesmo tempo, a unidade de localização envia o comando LOGOUT para o
centro que processa essa informação, como se pode observar pela Ilustração 103.
Ilustração 103 – Logout do funcionário com identificador 2 com a unidade de localização móvel 1
Como se pode verificar o estado do estafeta passou de Connected! para Disconnected!.
Page 164
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
142
22. Centro de monitorização e unidade de localização móvel em
tempo real
Os testes apresentados anteriormente são realizados durante a depuração do centro de
monitorização e como tal, a capacidade de execução em tempo real é perdida. De modo
a contornar este problema, conjuntamente com o outro colega responsável pelo
desenvolvimento das unidades de localização móveis realizaram-se diversos testes ao
conjunto centro de monitorização e unidade de localização móvel. Estas experiências
foram gravadas num vídeo com pouco mais de 11 minutos e com acesso através da
seguinte hiperligação:
Este vídeo mostra o papel do gestor no centro e do estafeta na unidade de localização
móvel, ou seja, de que modo é que o gestor realiza pedidos de encomendas, monitoriza
encomendas e estafetas. Mas também, como o estafeta aceita os pedidos e visualiza os
dados do cliente.
http://www.youtube.com/watch?v=sppu3S3rCjQ
Page 165
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
143
Conclusões e Trabalho Futuro
23. Conclusões
Ao fim de um ano de trabalho é possível dizer que os objetivos iniciais desta
implementação foram alcançados com sucesso.
As duas aplicações desenvolvidas para quem as gere ou consulta são de fácil navegação,
leitura, intuitivas, úteis e de agradável apresentação. Permitem monitorizar em tempo
real um enorme número de estafetas e georeferenciar muita informação e revê-la de
forma eficaz e acessível.
O projeto implementado no âmbito desta dissertação demonstra algumas vantagens em
relação a produtos comercializados. No estudo realizado não foi encontrado qualquer
produto no mercado que junte todas as características presentes nesta implementação.
Por outro lado, o facto do gestor do centro de monitorização ter que carregar o ficheiro
de base de dados para o caso de pretender instalar a aplicação noutro computador de
modo a manter a informação já monitorizada pode trazer algum desconforto e é
considerada uma desvantagem. De modo a combater este incómodo foi implementado
um sistema de cópias de segurança e um simples sistema de carregamento desses
ficheiros.
Por último, esta dissertação concentra a maior parte do trabalho na aplicação para PC.
Onde se destacam diversas funcionalidades, como o sistema de autenticação ou a
deteção de saída de rota com alerta em tempo real para o estafeta que cometeu a
infração.
Page 166
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
144
24. Trabalho Futuro
Apesar do bom funcionamento deste sistema desenvolvido, este ainda pode ser
melhorado.
No que diz respeito à aplicação para PC, uma vez que existe a tendência do aumento de
territórios cobertos por redes móveis, como trabalho futuro propunha o
desenvolvimento deste mesmo centro de monitoração, mas que ele somente
comunicasse com as unidades de localização móveis através do cliente/servidor TCP/IP.
Esta opção traria algumas vantagens. Deste modo, já não haveria necessidade de um
modem GSM para o centro. Isto reduziria o custo do conjunto centro/unidade de
localização móvel. Já fará sentido optar por uma base de dados remota que possibilitaria
ao gestor do centro instalar a aplicação em qualquer computador, sem necessidade de
andar com o ficheiro da base de dados atrás de si.
Relativamente à aplicação para dispositivos Android, esta deixaria de estar dependente
do centro de monitorização para visualização de resultados passando a realizar
consultas à base de dados remota. Além disso, já não fará sentido manter o sistema
criado para fazer cópias de segurança da base de dados local pois a base de dados do
sistema já não é local.
Page 167
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
145
Bibliografia
[1] P. M. Muruganandham, “Real Time Web based Vehicle Tracking using GPS,” em
World Academy of Science, Engineering and Technology, January 2010.
[2] “Amplifrota,” [Online]. Available: www.amplifrota.com.
[3] “Frotcom Lusitana,” [Online]. Available: www.frotcom.com.
[4] “3dtracking,” [Online]. Available: www.3dtracking.com.pt.
[5] “LiveGTS,” BOFAN, [Online]. Available: www.bofan.cc/livegts.php.
[6] “Novatronica,” frotasoft, [Online]. Available: www.frotasoft.com.
[7] “N-Auto Pro,” NAVENTO, [Online]. Available: www.navento.biz.
[8] “MOVILOC,” [Online]. Available: www.moviloc.com.
[9] “The NexTraq Platform,” NexTraq, [Online]. Available: www.nextraq.com/what-
we-do/the-nextraq-platform.
[10] “Wialon,” GURTA, [Online]. Available: www.gurtam.com/en/gps_tracking.html.
[11] “Holux,” [Online]. Available: www.holux.com/JCore/en/home/index.jsp.
[12] “Canmore,” [Online]. Available: http://www.canmore.com.tw/index.php.
[13] “NMEA 0183,” [Online]. Available: www.gpsinformation.org/dale/nmea.htm.
[14] “telit,” [Online]. Available: www.telit.com/.
[15] “Microsoft,” [Online]. Available: www.microsoft.com/.
[16] “Java,” [Online]. Available: www.java.com.
[17] “Android,” Google, [Online]. Available: www.android.com.
[18] “SQLite,” [Online]. Available: www.sqlite.org.
[19] “Google Maps API,” Google, [Online]. Available:
www.developers.google.com/maps.
[20] P. Álvarez, R. Béjar, S. Blasco, M. A. Latre e P. Fernández, “LBS for Fleet
Tracking and Management Services through the Internet,” 2001. [Online].
Available: www.ec-gis.org/.
[21] A. Goel e V. Gruhn, “A Fleet Monitoring System for Advanced Tracking of
Commercial Vehicles,” em Proceedings of the 2006 IEEE International
Page 168
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
146
Conference on Systems, Man, and Cybernetics, 2006.
Page 169
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
147
Anexos
Neste capítulo é explicado passo a passo como deve ser instalado o centro de
monitorização de estafetas num computador.
25. Como instalar o sistema
Em primeiro lugar é necessário adquirir o ficheiro CrewTrackSetup e executar um dos
ficheiros representados pela Ilustração 104.
Ilustração 104 – Ficheiros de instalação do centro de monitorização
Premir em Next (Ilustração 105).
Ilustração 105 – Menu de boas vindas do instalador
Page 170
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
148
Escolher a localização onde pretende instalar o centro de monitorização. Depois premir
em Next (ver Ilustração 106).
Ilustração 106 – Escolher localização
Confirmar a instalação e premir Next para dar início à instalação, ver Ilustração 107.
Ilustração 107 – Confirmação da instalação
Aguardar enquanto termina a instalação…
Page 171
Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização de Estafetas
João Vale
149
Ilustração 108 – A instalar a aplicação
Instalação completa, premir em Close (Ilustração 109).
Ilustração 109 – Instalação bem-sucedida
Criado no ambiente de trabalho, um atalho para a aplicação tal como o da Ilustração
110.
Ilustração 110 – Atalho para a aplicação instalada