João Diogo Peixoto do Vale - intranet.dei.uminho.ptintranet.dei.uminho.pt/gdmi/galeria/temas/pdf/52677.pdf · Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização

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

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

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.


João Vale

iv


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;


João Vale

vi


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;


João Vale

viii


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


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


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


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


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


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


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


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


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


João Vale

xviii


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

http://www.nmea.org/


João Vale

xx


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.

http://pt.wikipedia.org/wiki/Redes_de_computadores

http://pt.wikipedia.org/wiki/Mapa

http://pt.wikipedia.org/wiki/Imagem_de_sat%C3%A9lite

http://pt.wikipedia.org/wiki/Terra

http://pt.wikipedia.org/wiki/Google


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.


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.


João Vale

4


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.


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]


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.

http://pt.wikipedia.org/wiki/Programa_de_computador

http://pt.wikipedia.org/wiki/Web


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;


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


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


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.


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.


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.


João Vale

14


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.


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.


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.


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


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).


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]


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


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.


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


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:


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

http://pt.wikipedia.org/wiki/Newline


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


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.


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.


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.


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


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.


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


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.

http://pt.wikipedia.org/wiki/Microsoft


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

http://pt.wikipedia.org/wiki/Sistema_operacional

http://pt.wikipedia.org/wiki/N%C3%BAcleo_(inform%C3%A1tica)

http://pt.wikipedia.org/wiki/Linux

http://pt.wikipedia.org/wiki/Google

http://pt.wikipedia.org/wiki/Open_Handset_Alliance

http://pt.wikipedia.org/wiki/Java_(linguagem_de_programa%C3%A7%C3%A3o)

http://pt.wikipedia.org/wiki/Android#cite_note-8


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.


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


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ã.


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


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.


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.


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.

http://pt.wikipedia.org/wiki/Rede_local


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


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.

http://maps.google.com/


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.


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);


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.


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.


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.


João Vale

47

Ilustração 23 – Diagrama Geral (Dispositivo com aplicação para Android)


João Vale

48


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.


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;


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.


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.


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.


OrderProductID – Identificador do orderproduct;

Quantity – Quantidade de produtos que farão parte da encomenda;

OrderID – Identificador da encomenda adicionada;


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.


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.


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.


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


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


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.


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)


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


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)


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.


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):


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)


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.


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.


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.


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.


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.


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.


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.


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:


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


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.


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.


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.


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


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


a unidade de


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


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;


da encomenda;


geográfica da unidade de

localização móvel no formato

GGA referente ao protocolo

NMEA.


a encomenda foi

aceite.

Sim

REQ_REJECTED:ID_ORDER ID_ORDER – Indentificador

da encomenda.


o estafeta rejeitou a

encomenda.

Não

REQ_DONE:ID_ORDER,$GEO


da encomenda;


geográfica da unidade de

localização móvel no formato

GGA referente ao protocolo

NMEA.


a encomenda foi

entregue com

sucesso ao cliente.

Não

REQ_FAIL:ID_ORDER ID_ORDER – Indentificador

da encomenda.


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:


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


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


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;


Força a comunicação

entre o centro e a

unidade de


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


por rede GSM.

Sim

OUT_ROUTE:INSTRUCTION; INTRUCTION – Próxima instrução para

o estafeta se orientar.

Alerta enviado para a

unidade de


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


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)


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


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


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


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 é


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.


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.


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:


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


(ID_WORKER).

Sim

GET_ORDERS:ID_WORKER

ID_WORKER –

Identificador do

estafeta.

Pedido ao centro de todas as

encomendas que um


(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


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:


REG_OK:IP:PORTA; IP – endereço IP;


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.


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.


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).


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.


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.


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


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


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).


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


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


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


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


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:


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.


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.


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.


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.


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


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


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


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


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á).


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


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


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.


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


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.


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.


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


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.


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


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.


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


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.


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);


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


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


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.


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.


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)


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).


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.


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.


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


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


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


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


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


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.


João Vale

128


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/


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.


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


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.


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.


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/


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


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


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.


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.


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.


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.


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!.


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


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.


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.


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


João Vale

146

Conference on Systems, Man, and Cybernetics, 2006.


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


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…


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

Documents

João Diogo Peixoto do Vale - intranet.dei.uminho.ptintranet.dei.uminho.pt/gdmi/galeria/temas/pdf/52677.pdf · Desenvolvimento de um Protótipo baseado em PC de um Centro de Monitorização