Universidade do Minho - intranet.dei.uminho.ptintranet.dei.uminho.pt/gdmi/galeria/temas/pdf/50102.pdf · Computadores Trabalho efetuado sob a orientação do ... geographically scattered

Outubro de 2012

Universidade do Minho

Escola de Engenharia

Duarte Manuel Azevedo Fernandes

IntelFleet-Sistema de Gestão e Localização de Frotas

via GPS

Dissertação de Mestrado

Mestrado Integrado em Engenharia Eletrónica Industrial e

Computadores

Trabalho efetuado sob a orientação do

Professor Doutor Paulo Francisco S. Cardoso

IntelFleet-Sistema de Gestão e Localização de Frotas via GPS

Duarte Fernandes

DECLARAÇÃO

Nome: Duarte Manuel Azevedo Fernandes

Endereço eletrónico: [email protected] Telefone: 917033731 / 252921160

Número do Bilhete de Identidade:13237625

Título dissertação: IntelFleet-Sistema de Gestão e Localização de Frotas via GPS

Orientador: Doutor Paulo Francisco S. Cardoso

Ano de conclusão: 2012

Designação do Mestrado: Mestrado Integrado em Engenharia Eletrónica Industrial e

Computadores – Ramo Sistemas Embebidos

É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA TESE/TRABALHO

APENAS PARA EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO

ESCRITA DO INTERESSADO, QUE A TAL SE COMPROMETE;

Universidade do Minho, ___/___/______

Assinatura: ________________________________________________


Duarte Fernandes

iii

Agradecimentos

Apesar de uma dissertação ser um trabalho individual, devido ao seu objetivo

académico, há sempre contributos de natureza diversa que não podem deixar de ser

mencionados, pelo que expresso aqui os meus sinceros agradecimentos a todos os que

contribuíram de uma forma decisiva para a concretização deste trabalho.

Gostaria de salientar o meu orientador Professor Doutor Paulo Francisco S. Cardoso,

pelo estímulo e entusiasmo revelado por esta dissertação, pela disponibilidade sempre

revelada, pelas críticas e sugestões relevantes feitas durante a orientação que foram

essenciais para atingir os objetivos propostos.

De realçar o bom espirito e companheirismo encontrado no laboratório, mais

especificamente o bom ambiente criado muito graças aos meus colegas André Ferreira e

Nélson Barbosa.

Por último, manifesto um sentido e profundo reconhecimento à minha família pelo

apoio incondicional ao longo destes anos. Expresso sentimento idêntico em relação a

todos os meus amigos de longa data. A todos que me ajudaram a ser quem sou, que

depositaram confiança em mim e para os quais sou uma esperança, resta-me

afincadamente não vos desiludir. Muito obrigado!


Duarte Fernandes

iv


Duarte Fernandes

v

Resumo

Neste mundo globalizado, onde fabricantes e consumidores se encontram

geograficamente dispersos e onde a necessidade de matéria-prima é quase imediata,

obriga a que as empresas de transporte de mercadorias procurem melhorar a qualidade

dos seus serviços, de forma a satisfazer consumidores cada vez mais exigentes. O

transporte rodoviário é por vários motivos o modo de transporte mais vantajoso para o

transporte interno de mercadorias, isto provocou um rápido crescimento no mercado

rodoviário de mercadorias, acompanhado por um aumento significativo da concorrência

para as empresas privadas da área. Assim sendo, as organizações de transporte

rodoviário de mercadorias apostam em equiparem-se com sistemas tecnológicos de

gestão e localização de forma a melhorar os resultados obtidos no serviço ao cliente e a

minimizar os custos [1]. Esta necessidade, não é a única sentida por estas organizações

face ao número significativo de roubo de veículos e mercadorias [2] que se verifica,

assim torna-se inevitável tomar medidas de segurança preventivas.

O presente trabalho aborda o desenvolvimento de um sistema de gestão da atividade de

frotas apoiado na informação geográfica recolhida por tecnologia GPS, a solução

proposta, é intitulada a partir da junção dos termos em inglês “Intelligence” e “Fleet”

obtendo assim o nome da ferramenta apresentada, IntelFleet. Este instrumento,

destinado essencialmente a empresas de frotas foca-se essencialmente no planeamento e

acompanhamento em tempo real das atividades dos recursos que executam suas tarefas

fora da organização, tais como viaturas e condutores.

Palavras-Chave: Tracking, GPS, GSM, Android, Google Maps, Gestão de Frotas;

https://www.google.pt/search?hl=pt-PT&sa=X&ei=-iXfT-30Eqa_0QW-6P2ACw&ved=0CAgQvwUoAQ&q=intelligence&spell=1


Duarte Fernandes

vi


Duarte Fernandes

vii

Abstract

In this globalized world, where manufacturers and consumers are found

geographically scattered and where the need of raw material is barely immediate,

demand to that the goods transport companies, are going to improve the quality of his

service of form it satisfy consumers more and more demanding. The transport road is

for several motives the worth while way of transport for the internal transport of goods,

this provoke a quick growth in the goods road market, accompanied by a significant

increase of the competition for the private companies of the area. Like this being, the

goods road transport organizations wager in will equip itself with technological systems

of management and location and still his vehicles with systems of navigation and

tracking1 of form it improve the results obtained in the service to the client and it

minimize the costs. This need is not to unique felt by these organizations, face to the

significant number of robbery of merchandise that is verified, like this becomes-itself

inevitable take preventive safety measures.

To present dissertation approaches the development of a system of management of the

activity of fleets rested on the geographical information collected by technology GPS,

the proposed solution, is titled from the juncture of we will have in English

“Intelligence” and “Fleet” obtaining like this the name of the tool presented, IntelFleet.

This instrument, destined essentially the seal fleets bearers companies itself essentially

in the management of all of the resources that develop all her task outside of the

organization, such as vehicles and drivers, permitting the accompaniment in real time of

the her activities, beyond the supervision permitting the planning of these same task.

Keywords: Tracking, GPS, GSM, Android, Google Maps, Fleet Management;

1 Process Control and Monitoring of objects, people, etc.


Duarte Fernandes

viii


Duarte Fernandes

ix

Índice

Agradecimentos ................................................................................................................. iii

Resumo ............................................................................................................................... v

Abstract ............................................................................................................................ vii

Índice ................................................................................................................................. ix

Índice de Figuras ............................................................................................................... xiii

Índice de Tabelas .............................................................................................................. xix

Abreviaturas ..................................................................................................................... xxi

1. Introdução ................................................................................................................... 1

1.1 Objetivos ............................................................................................................ 1

1.2 Motivações ......................................................................................................... 2

1.3 Organização e Estrutura da Tese........................................................................ 3

2. Âmbito dos Sistemas de Localização e Gestão ............................................................... 5

2.1 Tecnologias de Localização ............................................................................... 5

2.2 Tecnologia de Comunicação GSM..................................................................... 8

2.3 Visão Global dos Sistemas Existentes no Mercado ........................................... 9

2.3.1 Xtran Gestão de Frotas .......................................................................................... 9

2.3.2 NVfrotasoft.......................................................................................................... 11

2.3.3 Moviloc ................................................................................................................ 13

2.3.4 Outras Soluções no Mercado ............................................................................... 14

2.3.5 Comparação das Soluções Descritas ................................................................... 15

2.4 Exemplos de Dispositivos GPS Tracking ........................................................ 16

2.4.1 G959 GPS Tracking ............................................................................................ 16

2.4.2 HCT PRO Plus .................................................................................................... 17

2.4.3 QTracker GT-Q3000 ........................................................................................... 18

2.5 Comparação das Soluções Apresentadas ......................................................... 19

3. Caraterização do Problema ......................................................................................... 21

3.1 Exposição do Problema ................................................................................... 21

3.2 Requisitos do Sistema ...................................................................................... 21

3.3 Restrições do Sistema ...................................................................................... 22


Duarte Fernandes

x

3.4 Especificações de Hardware............................................................................ 23

3.4.1 Modem GSM, Telit EZ10-GPRS ........................................................................ 24

3.4.2 Unidade de Localização Móvel ........................................................................... 24

3.5 Especificações de Software .............................................................................. 30

3.5.1 Interface com os Utilizadores .............................................................................. 30

3.5.2 Software Adotado para o Desenvolvimento da Unidade Móvel ......................... 39

4. Arquitetura e Desenvolvimento do Sistema ................................................................ 41

4.1 Visão Global do Sistema .................................................................................. 41

4.2 Modelo Relacional ........................................................................................... 44

4.2.1 Relacionamento entre Entidades ......................................................................... 45

4.3 Centro de Controlo ........................................................................................... 49

4.3.1 Interface entre os Processos ................................................................................ 50

4.3.2 Background Service ............................................................................................. 52

4.3.3 Aplicação Gráfica ................................................................................................ 65

4.4 Posto de Trabalho ............................................................................................ 65

4.4.1 Página Web .......................................................................................................... 67

4.4.2 Inclusão dos Mapas da Google ............................................................................ 71

4.5 Terminal do Condutor ...................................................................................... 81

4.5.1 Visão Global da Aplicação .................................................................................. 81

4.5.2 Atividades............................................................................................................ 82

4.5.3 Broadcast Receiver (Filtragem de Mensagens de Texto) .................................... 83

4.5.4 Serviço Executado em Background .................................................................... 84

4.5.5 QRcode Scanner .................................................................................................. 86

4.6 Unidade Móvel ................................................................................................ 88

4.6.1 Processos de Software ......................................................................................... 89

4.6.2 Comunicação com a Unidade Móvel ................................................................ 103

5. Testes e Resultados Obtidos ..................................................................................... 107

5.1 Unidade Móvel .............................................................................................. 107

5.2 Centro de Controlo ......................................................................................... 111

5.3 Posto de Trabalho .......................................................................................... 115

5.4 Terminal do Condutor .................................................................................... 119


Duarte Fernandes

xi

6. Conclusão e Trabalho Futuro .................................................................................... 125

6.1 Conclusões ..................................................................................................... 125

6.2 Trabalho Futuro ............................................................................................. 126

Bibliografia ...................................................................................................................... 129

Apêndice A ...................................................................................................................... 133

A.1 Protocolo NMEA ............................................................................................ 133

A.2 Caraterísticas do Modem GSM ...................................................................... 135

A.3 Características do recetor GPS FGPMMOPA6B .......................................... 135

A.4 Comandos AT ................................................................................................. 136

A.5 Dicionário de Dados ...................................................................................... 137

A.6 Aplicação Posto de Trabalho ......................................................................... 139

A.7 Funcionalidades do Posto de Trabalho .......................................................... 146

A.7.1 Visualização da Posição Geográfica do Veiculo ............................................... 146

A.7.2 Serviços Terminados ......................................................................................... 147

A.7.3 Verificação de rotas percorridas ........................................................................ 149

A.8 Aplicação Terminal do Condutor .................................................................. 150

A.8.1 Declarar Atividades ........................................................................................... 150

A.9 Circuitos e Esquemáticos da Unidade Móvel ................................................ 151

A.9.1 Placa desenvolvida ............................................................................................ 151

A.9.2 Esquemático em Eagle ...................................................................................... 154

A.9.3 GPIO ................................................................................................................. 155


Duarte Fernandes

xii


Duarte Fernandes

xiii

Índice de Figuras

Figura 1 - Arquitetura da rede GSM, [10]. ....................................................................... 8

Figura 2 - Overview da solução Xtran, [11]. .................................................................... 9

Figura 3 - Geração de relatórios informando distâncias percorridas, velocidades entre

outos na forma de gráficos, [11]. .................................................................................... 10

Figura 4 - Equipamentos de hardware que compõem a ferramenta Xtran: consola

"Dispatch & Navigation", unidade móvel e exemplares do terminal do condutor

respetivamente, [11]. ...................................................................................................... 11

Figura 5 - Módulos que compõem a solução NVfrotasoft e interação dos mesmos, [13].

........................................................................................................................................ 12

Figura 6 - A visualização da posição dos veículos (entre outras informações) na

ferramenta NVfrotasoft é realizada sobre um mapa, [13]. .............................................. 12

Figura 7 - Funcionamento da ferramenta Moviloc desde o processo inicial de recolha de

dados até ao objetivo final que consiste na apresentação da informação relevante ao

utilizador, [14]. ............................................................................................................... 13

Figura 8 - Equipamento MOVILOC® instalado no veículo, [14]. ................................. 14

Figura 9 - Imobilização veículo de forma remota, por ordem do Centro de Controlo,

[14]. ................................................................................................................................ 14

Figura 10 - Componentes constituintes do produto G959 GPS Tracker, [16]. .............. 16

Figura 11 - Dispositivo HCT PRO PLUS utilizado na localização de veículos, [17]. ... 17

Figura 12 - Modem Telit EZ10-GPRS, [21] . .................................................................. 24

Figura 13 - Conversor step-down PTN78060 W, [24]. ................................................... 26

Figura 14 - Aspeto físico do recetor GPS FGPMMOPA6B, [25]. ................................. 27

Figura 15 - Diagrama de blocos do módulo recetor GPS selecionado para o projeto,

[25]. ................................................................................................................................ 27

Figura 16 - Módulo GSM da Siemens, TC-3, [26]. ......................................................... 28

Figura 17 - Instalação do sistema de corte da bomba. .................................................... 30


Duarte Fernandes

xiv

Figura 18 - Funcionalidades do sistema do ponto de vista do Gestor. ........................... 31

Figura 19 - Funcionalidades a suportar pela interface do Gestor. .................................. 32

Figura 20 - Funcionalidades da ferramenta IntelFleet do ponto de vista do Condutor. . 33

Figura 21 - Funcionalidades que a interface do Condutor deve suportar. ...................... 34

Figura 22 - Funcionalidades da ferramenta do ponto de vista do coordenador. ............. 37

Figura 23 - Funcionalidades suportadas pelo posto de trabalho. .................................... 37

Figura 24 - Visão Global do sistema IntelFleet. ............................................................. 42

Figura 25 - Modelo Entidade-Relação da base de dados criada para o sistema IntelFleet.

........................................................................................................................................ 44

Figura 26 - Relacionamento de várias entidades com a entidade central, “Servicos”. ... 46

Figura 27 - Relação de uma para vários entre as entidades Historico_Servico e Servicos.

........................................................................................................................................ 47

Figura 28 - Relação entre as entidades Driver e veiculo. ............................................... 47

Figura 29 - Trigger responsável por remover ligação de um condutor a um veículo

removido. ........................................................................................................................ 48

Figura 30 - Arquitetura do Centro de Controlo. ............................................................. 49

Figura 31 - Interação Serviço-Aplicação gráfica na aplicação Centro de Controlo. ...... 50

Figura 32 - Comunicação entre aplicação gráfica e o background service via sockets. . 51

Figura 33 - Processo de Start-up da aplicação executada em background. ................... 53

Figura 34 - Algoritmo de configuração do modem GSM. .............................................. 54

Figura 35 - Fluxograma do subsistema de aquisição dos dados em modo periódico. .... 56

Figura 36 - Fluxograma do subsistema de aquisição de dados no modo “on-demand”. 57

Figura 37 - Comportamento sobre a forma de fluxograma do subsistema de

Comunicação durante receção de informação. ............................................................... 58

Figura 38 - Comportamento sobre a forma de fluxograma do subsistema de

Comunicação durante o envio de informação. ............................................................... 60

Figura 39 - Algoritmo do subsistema de tratamento de dados. ...................................... 61


Duarte Fernandes

xv

Figura 40 - Hosts com acesso permitido à base de dados. ............................................. 65

Figura 41 - Visão Global da aplicação Posto de Trabalho. ............................................ 66

Figura 42 - Pesquisa de dados armazenados no servidor. .............................................. 69

Figura 43 - Interação entre as diferentes camadas durante a requisição assíncrona. ...... 70

Figura 44 - Exemplo do ficheiro XML enviado como resposta pelo servidor. ............... 71

Figura 45 - Aspeto encontrado pelo utilizador quando pretende conhecer a posição

geográfica dos veículos sobre um mapa. ........................................................................ 73

Figura 46 - Processo de inserção da localização do veículo no mapa. ........................... 74

Figura 47 - Marcadores interativos. ................................................................................ 74

Figura 48 - Página 'querys.php' após a primeira requisição ao servidor. ....................... 75

Figura 49 - Fluxo de informação gerado durante a pesquisa de tarefas já realizadas. ... 76

Figura 50 - Exemplo da resposta do servidor ao pedido de informações dos pontos

geográficas percorridos durante a execução de um dado serviço. .................................. 77

Figura 51 - Algoritmo implementado para a deteção de trajetos indesejados. ............... 78

Figura 52 - Informação relevante para o planeamento de novos serviços...................... 80

Figura 53 - Overview da aplicação Terminal do Condutor. ........................................... 81

Figura 54 - Processo iniciado após receção de mensagem de texto. .............................. 84

Figura 55 - Módulo Serviço executado em background na aplicação Android (detetar

novas tarefas definidas pelos coordenadores no Posto de Trabalho). ............................ 85

Figura 56 - Notificação ao utilizador de prazo de execução da tarefa a expirar,

IntelFleet_warn e IntelFleet_gps_warn respetivamente. ................................................ 86

Figura 57 - Processo de registo de veículos. .................................................................. 87

Figura 58 - Registo de veículos utilizando o Barcode Scanner. .................................... 88

Figura 59 - Visão global da Unidade Móvel sobre a forma de blocos. .......................... 88

Figura 60 - Processo de Start-up. ................................................................................... 90

Figura 61 - Procedimentos executados durante a inicialização do Receiver GPS. ......... 91

Figura 62 - Diagrama temporal do processo de recolha de dados GPS. ........................ 92


Duarte Fernandes

xvi

Figura 63 - Processo de inicialização do módulo GSM. ................................................. 92

Figura 64 - Algoritmo percorrido durante o processo de verificação de falhas no

dispositivo. ...................................................................................................................... 94

Figura 65 - Determinação do evento que gerou interrupção. ......................................... 95

Figura 66 - Interpretação de comandos. ......................................................................... 96

Figura 67 - Identificação do modo de atualização de dados solicitado. ......................... 97

Figura 68 - Algoritmo de extração dos parâmetros GPS solicitados. ............................. 98

Figura 69 - Algoritmo implementado na função Parse_GPS. ....................................... 99

Figura 70 - Processo de envio dos parâmetros solicitados. .......................................... 100

Figura 71 - Fluxo de informação durante o bloquei do veículo. .................................. 101

Figura 72 - Instruções da função Verify_fix.................................................................. 102

Figura 73 - Fluxograma da função ‘Fix_detect’. .......................................................... 103

Figura 74 - Frases NMEA transmitidas pelo receiver. .................................................. 109

Figura 75 - Frase NMEA recebida, proveniente do output do Receiver e variáveis de

interesse extraídas do output. ....................................................................................... 109

Figura 76 - Ponto geográficos obtidos durante o teste da aquisição de dados do

dispositivo móvel numa posição fixa (ponto A). .......................................................... 111

Figura 77 - Resultado ao teste de verificação do serviço. ............................................ 112

Figura 78 - Verificação do estado do background service. .......................................... 112

Figura 79 - Resultado obtido após forçar o início do serviço. ...................................... 112

Figura 80 - Gestor de serviço do Windows. .................................................................. 113

Figura 81 - Dados dos condutores registados na base de dados ................................... 113

Figura 82 - Inserção de um cliente na base de dados. .................................................. 114

Figura 83 -Notificação da atualização de dados. .......................................................... 115

Figura 84 - Detalhes do condutor com o id=1; ............................................................. 115

Figura 85 -Parâmetros que caraterizam uma tarefa. ..................................................... 116


Duarte Fernandes

xvii

Figura 86 - Informações do veículo, antes do condutor ter conhecimento da nova tarefa.

...................................................................................................................................... 116

Figura 87 - Tabela com os serviços que se encontram por realizar. ............................. 117

Figura 88 - Rota definida para a tarefa pelo coordenador. ........................................... 117

Figura 89 - Registos dos pontos na base de dados. ...................................................... 117

Figura 90 - Aspeto da imagem após consulta do trajeto percorrido pelo veículo. ....... 118

Figura 91 - Teste do processo responsável por detetar trajetórias indesejáveis. .......... 118

Figura 92- Conteúdo do ficheiro XML obtido no teste ao processo de autenticação ... 119

Figura 93 - Tela durante processo de login e tela seguinte (Menu da aplicação, notifica

utilizador quando iniciado o background service). ...................................................... 119

Figura 94 - Gestor de aplicações apresenta detalhes da aplicação, espaço ocupado,

tempo de execução e componentes a correrem (serviço). ............................................ 120

Figura 95 - Parâmetros enviados durante requisição de atualização “on-demand”,

número do localizador e texto da mensagem................................................................ 120

Figura 96 - Telas durante o pedido de atualização da localização ............................... 120

Figura 97 - Estado da mensagem, enviada com sucesso. ............................................. 121

Figura 98 - Estado da mensagem, recebida pela unidade móvel. ................................. 121

Figura 99 - QRcode gerado a partir do texto "728-12-DN". ........................................ 121

Figura 100 - Texto após o scanner ter sido realizado................................................... 121

Figura 101 - Resultado positiva após o processo de registo de veículos, alterados com

sucesso os campos necessários que traduzem a mudança de veículo à organização. .. 122

Figura 102 - Tabela “Driver” após alterações dos campos influenciados por esta

mudança levada a cabo durante o teste. ........................................................................ 122

Figura 103 - Identificação do conteúdo da mensagem de texto proveniente da unidade

móvel. ........................................................................................................................... 122

Figura 104 - Localização correspondente as coordenadas transmitidas pela unidade

móvel. ........................................................................................................................... 123

Figura 105 - Resultado da atualização “on-demand”. .................................................. 123


Duarte Fernandes

xviii

Figura 106 - Ficheiro XML, contêm os dados relativos à tarefa criada ao longo do teste.

...................................................................................................................................... 123

Figura 107 - Resultado do processo de "escuta" de novas tarefas durante o teste

realizado........................................................................................................................ 124

Figura 108 - Conetores utilizados para interface com o modem. ................................. 135

Figura 109 - Consulta dos dados requisitados utilizando os comandos SQL. .............. 141

Figura 110 - Aquisição dos dados resultantes de uma consulta à base de dados. ........ 141

Figura 111 - Incorporar informação coletada num ficheiro XML. ............................... 142

Figura 112 - Função "callback" definida como função de retorno. .............................. 142

Figura 113 - Carregar para página HTML a API do Google Maps. ............................. 144

Figura 114 - Criação de uma instancia da classe Map. ................................................ 145

Figura 115 - Configuração do objeto Map. .................................................................. 145

Figura 116 - Geração de rotas com passagem em pontos de referência utilizando API do

Google Maps. ............................................................................................................... 149

Figura 117 - Implementação do método onCreate da classe Activity. ......................... 150

Figura 118 - Exemplo da estrutura do ficheiro Android Manifest.xml. ....................... 150

Figura 119 - Aspeto físico da placa desenvolvida. ....................................................... 151

Figura 120- Montagem do receiver GPS. ..................................................................... 152

Figura 121 - Esquema de ligação da fonte comutada PTN78060W............................. 153

Figura 122 - Circuito elevador de tensão. .................................................................... 153

Figura 123 - Divisor de tensão como meio de baixar o nível de tensão. ...................... 154

Figura 124 - Circuito de bloqueio do veículo. .............................................................. 154

Figura 125 - PCB desenvolvida para a Unidade Móvel. .............................................. 155


Duarte Fernandes

xix

Índice de Tabelas

Tabela 1 - Descrição das principais mensagens padronizadas pela NMEA ..................... 7

Tabela 2 - Comparação entre as soluções apresentadas/estudadas. ................................ 15

Tabela 3 - Características do GPS tracker integrado com o dispositivo G945............... 17

Tabela 4 - Características do dispositivo HCT PRO Plus. ............................................. 18

Tabela 5 - Características do dispositivo QTracker. ...................................................... 18

Tabela 6 - Comparação dos módulos GPS Tracker analisados. ..................................... 19

Tabela 7 - Descrição dos pinos I/O do recetor GPS. ...................................................... 27

Tabela 8 - Descrição dos principais sistemas operativos no mercado de dispositivos

móveis. ............................................................................................................................ 35

Tabela 9 - Comparação entre as API’s da Google e Yahoo Maps. ................................. 38

Tabela 10 - Descrição das entidades/tabelas que compõem a base de dados

intelfleet_mydb. .............................................................................................................. 45

Tabela 11 - Comandos provenientes da interface gráfica reconhecidos pelo serviço. ... 62

Tabela 12 - Associação de ficheiros por funcionalidade, desde seu aspeto (HTML) até ao

ficheiro (JavaScript) responsável por efetuar as requisições ao servidor e por fim o

arquivo que processa estes pedidos. ............................................................................... 68

Tabela 13 - Conjunto de Atividades que compõem a aplicação Terminal do Condutor. 83

Tabela 14 - Descrição dos comandos AT necessários durante a configuração do modem

GSM. ............................................................................................................................... 93

Tabela 15 - Funções de resposta ao evento. ................................................................... 95

Tabela 16 - Comandos AT usados durante o processo de envio dos parâmetros. ........ 101

-Tabela 17 - Formato das mensagens reconhecidas pela Unidade Móvel .................... 104

Tabela 18 – Parâmetros da mensagem da unidade móvel como resposta às solicitações

de atualização de dados. ............................................................................................... 105

Tabela 19 - Casos de teste utilizados para prevenir erros no produto final. ................. 108

Tabela 20 - Resultados do teste as atualizações periódicas. ......................................... 110


Duarte Fernandes

xx

Tabela 21- Dados GPS adquiridos durante a realização da tarefa. ............................... 114

Tabela 22 - Campos da frase GPRMC. ........................................................................ 133

Tabela 23 - Campos da frase GPRMC relevantes para o cálculo da latitude. .............. 134

Tabela 24 - Campos da frase GPRMC relevantes para o calculo da latitude. .............. 134

Tabela 25 - Características do modem GSM (Telit EZ10-GPRS). ............................... 135

Tabela 26 - Características do receiver GPS. ............................................................... 136

Tabela 27 - Principais comandos AT. ........................................................................... 137

Tabela 28 - Parâmetros do objeto XMLHttpRequest. ................................................... 140

Tabela 29 - Parâmetros recebidos pela função mysql_connect(). ................................. 141

Tabela 30 - Parâmetros recebidos pela função mysql_select_db(). .............................. 141

Tabela 31 - Estados da interação HTTP. ...................................................................... 143

Tabela 32 - Funções de auxílio utilizadas pela função ‘ParseMessages()’. ................. 143

Tabela 33 - Construtor google.maps.Map().................................................................. 145

Tabela 34 - Parâmetros a incluir no objeto ‘DirectionsRequest’ e entidade onde estão

armazenados os valores com que estes são iniciados. .................................................. 148

Tabela 35 - Pinos do microcontrolador utilizados. ....................................................... 155


Duarte Fernandes

xxi

Abreviaturas

ADC – Analog-to-Digital Converter

AVL – Automatic Vehicle Location

C/A – Código de Aquisição Inicial

DAC – Digital-toAnalog Converte

DoD – Departamento de Defesa dos

EUA

DOM – Document Object Model

EEPROM – Electrically-Erasable

Programmable Read-Only Memory

GPRS – General Packet Radio Service

GPS – Sistema de Posicionamento

Global

GSM – Global System for Mobile

Communications

HTML – HyperText Markup Language

IPC – Inter Process Communication

LBS – Location Based Services

ME – Estação Móvel

NAVSTAR – Navigation System by

Time and Rancing

NMEA – National Marine Electronics

Association

SQL – Structured Query Language

P Code – Código de Precisão

PCB – Placa de Circuito Impresso

PDU – Protocol Data Unit

PHP – Hypertext Preprocesso

XML – eXtensible Markup Language

SMS – Mensagem de Texto

SPI – Serial Peripheral Interface Bus

SRAM – Static Random Access

Memory

URL – Uniform Resource Locator

USART – Universal Synchronous

Asynchronous Receiver Transmitter


Duarte Fernandes

xxii


Duarte Fernandes

1

1. Introdução

Neste capítulo são explicadas as motivações inerentes ao desenvolvimento da

solução, onde é feita a contextualização deste projeto, dado a conhecer os seus

objetivos, metas a atingir e por fim é realizada uma descrição da organização

documental.

1.1 Objetivos

O presente trabalho apresenta como objetivo sumário, o desenvolvimento de um

sistema de localização/tracking e gestão de frotas. Para cumprimento deste propósito,

são exigidas etapas essenciais como a planificação, a implementação e a interação entre

os elementos que constituirão o sistema.

Os objetivos inerentes à etapa da planificação referem-se ao estudo e aquisição dos

dispositivos necessários à montagem do dispositivo eletrónico de receção e envio de

coordenadas GPS que constituem a unidade móvel, a definição dos parâmetros a serem

transmitidos entre os diferentes elementos que constituirão o sistema e que melhor

gestão proporciona devido à continua atualização, a definição das variáveis a

monitorizar, a escolha das ferramentas para desenvolvimento das diferentes interfaces

gráficas e por último, o estudo de métodos para bloqueio do veículo em caso de roubo

sem o danificar.

Na etapa de implementação, objetiva-se a construção dos diferentes elementos que

constituem o sistema, podendo ser divididos em elementos de hardware (plataforma

física instalada no veículo) e software (aplicações que tratam as informações recolhidas

sobre os veículos e a disponibilizam ao utilizador).

Na etapa de integração, pretende-se criar a ligação entre os diferentes elementos,

baseando-se numa comunicação sem fios. A plataforma física transmite as coordenadas

geográficas via GSM para a unidade central da ferramenta IntelFleet, neste ponto são

atualizadas as informações relativas ao veículo e condutor em questão. Estando desde

então a informação atualizada e disponível aos diferentes utilizadores, por intermédio

das aplicações desenvolvidas para o efeito.

De forma a automatizar o sistema, pretende-se que um conjunto de funcionalidades seja

concedido aos diferentes utilizadores consoante as suas tarefas na organização. Quando


Duarte Fernandes

2

os clientes requerem novos serviços, estes deverão ser planeados com o auxílio de

informação relevante e sempre atualizada. A ferramenta IntelFleet deverá disponibilizar

de forma gráfica esta informação ao utilizador responsável pela sua execução

(motorista), através de uma aplicação de software a correr sobre um smartphone/tablet.

Durante a realização dos serviços os utilizadores devem ser capazes de seguir a sua

execução em tempo real. Outra funcionalidade pretendida é a prevenção de roubos das

viaturas, isto é, o condutor deve ter meios que lhe permita imobilizar o veículo de forma

remota e ainda de conhecer a localização geográfica do veículo sempre que desejar. Isto

permite em situações de furto do veículo/mercadoria conhecer o seu paradeiro,

facilitando a sua recuperação. Estas são das funcionalidades mais relevantes que a

ferramenta deve fornecer aos utilizadores.

1.2 Motivações

É sabido que a partir de uma eficiente gestão de frotas é possível reduzir os

gastos inerentes às viagens, como tempos de utilização indevidos dos veículos por parte

dos funcionários, aperfeiçoar rotas e aumentar a rapidez de resposta aos clientes [3],

permite ainda agendar com antecedência tarefas com base na localização dos veículos

aumentando a produtividade da empresa [4]. Para alcançar estes objetivos é necessário

gerir adequadamente uma frota, aplicando o conceito de inteligência de negócios.

Cada vez mais se requer uma melhor compreensão das variáveis de negócio que

orientam a empresa com objetivo de tomar melhores decisões, baseadas na melhor

informação. É neste contexto que surge a inteligência de negócios, como apoio

fundamental da tomada de decisões, este conceito refere-se ao processo de recolha,

organização, análise, compartilhamento e monitoramento de informações que oferecem

suporte a gestão de negócios [5]. Para as organizações da área do tema dissertado obter

eficientemente estas características, necessitam de bons gestores integrados de frotas na

organização, sendo esta necessidade atualmente reconhecida bem como as vantagens

obtidas na utilização destas ferramentas, conduzindo as empresas a adquirir sistemas

competitivos de modo a aumentar a produtividade.

Assim, verifica-se que esta é uma área em ascensão, longe de atingir a maturidade [6],

resultando tudo isto num excelente ponto de partida no desenvolvimento de um sistema,

que vai de encontro às necessidades e contexto atual das empresas: arranjar soluções


Duarte Fernandes

3

simples, competitivas, mas de baixo custo em busca do seu principal objetivo no

mercado que é destacar-se dos seus concorrentes e reduzir os seus custos.

Como estudante de engenharia eletrónica industrial e computadores e adotando este

facto como ponto de partida, encontro uma forte motivação e entusiasmo no

desenvolvimento de tal sistema num contexto empresarial, que colocará constantemente

os meus conhecimentos a prova.

1.3 Organização e Estrutura da Tese

A presente dissertação encontra-se organizada em sete capítulos, que conduzem

desde a conceção inicial da ferramenta até à solução final proposta, acrescentando ainda

possíveis futuros desenvolvimentos.

O primeiro capítulo é composto por três secções, onde são abordadas as motivações do

trabalho descrito, os objetivos fundamentais a atingir e ainda informação da estrutura da

tese.

O segundo capítulo abrange toda a pesquisa realizada, o estudo da arte de sistemas

existentes no mercado, e uma descrição das tecnologias utilizadas na criação da

ferramenta proposta.

O terceiro capítulo aborda as especificações do sistema como as escolhas de software e

hardware que suportam a implementação da ferramenta desenvolvida.

O capítulo quatro encontra-se dividido em seis subcapítulos e tem como objetivo

descrever a arquitetura geral do sistema e a implementação dos diferentes módulos

constituintes da ferramenta IntelFleet, apresentado posteriormente no quinto capítulo os

diferentes testes realizados seguidos de uma discussão dos resultados obtidos.

O capítulo que finaliza o presente documento apresenta as conclusões finais do projeto e

ainda algumas sugestões de trabalhos possíveis de realizar no futuro.


Duarte Fernandes

4


Duarte Fernandes

5

2. Âmbito dos Sistemas de Localização e Gestão

O presente capítulo descreve e compara os vários sistemas de gestão e

localização de frotas disponíveis no mercado. Como introdução à descrição é

apresentada as principais tecnologias que constituem estes sistemas.

2.1 Tecnologias de Localização

Atualmente, encontram-se disponíveis as seguintes tecnologias de localização: o

europeu Galileo, o russo GLONASS, o chinês COMPASS, o indiano IRNSS e o

americano GPS [7]. Este último é o sistema mais conhecido e utilizado, sendo que todos

os restantes sistemas têm por base o princípio de funcionamento do sistema americano.

O Sistema de Posicionamento Global (GPS) foi desenvolvido na década de 1970/80

pelo Departamento de Defesa dos EUA (DoD), destinado inicialmente ao exército

americano, estando como segundo plano a sua utilização para fins não militares. Na

década de 90 os utilizadores civis estavam limitados quanto à sua utilização, apenas

alguns sinais imitidos por GPS lhes eram destinados, mas apesar destas limitações a

taxa de aplicações civis cresceu surpreendentemente. Graças às atividades em que este

sistema é aplicado, se adivinha que o seu caminho é se tornar numa parte essencial do

comércio e infraestrutura pública.

Atualmente esta tecnologia é empregada numa enorme variedade de aplicações [3], tais

como:

Localização de veículos, particularmente útil quando estes são roubados;

Gestores de frotas e roteamento de veículos beneficiam desta tecnologia

indiretamente;

Localizar pessoas, estas podem ser equipadas com recetores GPS de modo a

conhecer o seu paradeiro, bastante útil em pacientes com distúrbios mentais e

ainda ao nível da segurança, quando aplicado em prisioneiros em liberdade

condicional;

Estudo do movimento e comportamento da vida selvagem, útil para os cientistas

que desejam conhecer mais sobre animais selvagens, como exemplo segue o

sistema ZebraNet aplicado numa zebra retornando sua posição a cada três

minutos [8].


Duarte Fernandes

6

O sistema GPS consiste numa constelação de 24 satélites que orbitam a Terra, esta

disposição nos planos orbitais garante que pelo menos quatro satélites estejam

simultaneamente visíveis em qualquer ponto do planeta.

O princípio de funcionamento do GPS é bastante simples, a nossa posição pode ser

determinada se medirmos a distância a cada um de três satélites visíveis, cujas posições

são conhecidas. Na verdade, os satélites estão em movimento no espaço a uma

velocidade aproximada de 4 km por segundo, mas a posição pode ser obtida em

qualquer instante, a partir da mensagem de transmissão emitida pelo satélite. Estes

transmitem dois sinais de rádio, designados de L1 e L2 a uma frequência 1575,42 MHz

e 1227,60 respetivamente, mas o sinal de cada satélite é transmitido a uma modulação

diferente, sob forma de código, permitindo facilmente a identificação do satélite ao

recetor GPS [7]. Estas modulações consistem de um Código de Precisão (P Code2) e de

um Código de Aquisição Inicial (C/A – Coarse Acquisition Code). A portadora L1

contém as ambas modulações em código, enquanto a L2 contém apenas o Código P.

Esta modulação é acessível apenas para utilizadores militares norte-americanos e outras

agências dos EUA. Por sua vez, o Código C/A encontra-se acessível para os demais,

assim os recetores são capazes de medir as distâncias obtidas pela duração do trajeto

(intervalo de tempo) do sinal de rádio entre os satélites e o recetor. Além da distância, é

necessário também conhecer as posições dos satélites GPS, esta informação encontra-se

disponível na mensagem de navegação, pois esta contém todos os dados necessários

para o cálculo da posição do satélite no instante da medição da distância entre recetor e

satélite.

Presentemente os recetores GPS suportam o protocolo NMEA, este protocolo foi

instituído pela National Marine Electronicas Association (NMEA) e baseia-se no envio

e receção de tramas de texto em ASCII com conteúdo e sinalização específica [9]. Este

protocolo surgiu com intuito de padronizar todas as mensagens, implicando que elas

respeitem as normas estabelecidas pela NMEA. As mensagens devem possuir a seguinte

sintaxe:

$<dispositivo><Id da mensagem>, <campo de dados>, <campo de

dados>,…*<checksum> <CR> <LF>

2 Modelação acessível apenas a utilizadores militares norte-americanos.


Duarte Fernandes

7

As mensagens começam com o carater “$” seguidas de um prefixo de duas letras que

definem o tipo de dispositivo que está a ser utilizado (GP para recetores GPS), seguido

pelo identificador da mensagem recebida constituído por três letras. Os campos de

dados são sempre separados por vírgulas, sendo seguido pelo checksum, o último campo

é utilizado para verificar a integridade do conteúdo da trama. O carater de controlo “*” é

utilizado para preceder o checksum permitindo aos recetores facilmente o identificar,

este nada é mais que dois dígitos hexadecimais que representam um ou exclusivo (XOR)

de oito bits de todos os carateres entre, “$” e “*”.

Como referido anteriormente, existe um campo identificador do tipo de mensagem, isto

se deve ao facto de existir vários tipos de mensagens NMEA, cada uma com uma

designação própria, que indica os tipos de dados que compõem a mensagem. A Tabela 1

apresenta as principais mensagens NMEA que poderemos encontrar.

Tabela 1 - Descrição das principais mensagens padronizadas pela NMEA

ID da Mensagem Descrição GGA Posição geográfica precisa – latitude, longitude e altitude

GLL Posição geográfica - latitude e longitude

VTG Dados relativos ao deslocamento – velocidade

RMC Dados temporais – data e hora

A seguinte trama é apresentada como exemplo de uma possível mensagem recebida por

um recetor: $GPGLL, 4825.56, N,13412.21,W,203225,A,*1D.

Onde:

GP indica que a mensagem foi enviada por um dispositivo GPS;

GLL indica que a mensagem contém informação relativa à localização (latitude e

longitude);

4825.56, Latitude 48 graus e 25.56 minutos Norte (N);

13412.21, Longitude 134 graus 12.21 minutos Oeste (W);

203225, FIXO às 20:32:25 UTC;

A, Dados Active (ativo) ou Void (sem nada);

*1B, checksum.

Uma descrição mais detalhada das mensagens recebidas no protocolo NMEA encontra-

se disponível para consulta no anexo A.1 (Protocolo NMEA).

As alternativas de sistemas de localização, desenvolvidos posteriormente como é o caso

do europeu Galileo, dispõem de um maior número de satélites, atualmente são 30


Duarte Fernandes

8

satélites que constituem o sistema, o que resulta num maior número de satélites visíveis

em qualquer ponto terrestre, de 6 a 8. Impondo assim, uma maior precisão quando

comparado com o americano GPS [7].

2.2 Tecnologia de Comunicação GSM

O Global System for Mobile Communications (GSM), é o sistema mais popular

para comunicações de longo alcance utilizado em dispositivos móveis. Foi desenvolvido

na Europa e introduzido no mercado no ano 1991, tendo crescido imediatamente a taxa

da sua utilização, contando presentemente com mais de um bilhão de telefones que

utilizem o sistema. O GSM é o primeiro sistema móvel no mundo a especificar

modulação digital e arquiteturas de serviços de nível de rede, concebido com o

propósito de resolver problemas de fragmentação dos primeiros sistemas na Europa.

O padrão GSM utiliza as frequências 900MHz na Europa e 850MHz nos Estados

Unidos na América e é composto por várias entidades com funções e interfaces

específicas [10]. A rede GSM pode então ser dividida em três grandes grupos: a Estação

Móvel (ME), o Subsistema de Estação Base e o Subsistema de Rede como apresentado

na Figura 1.

Figura 1 - Arquitetura da rede GSM, [10].

De forma resumida, a Estação Móvel consiste na integração do dispositivo móvel

transportado pelo subscritor do serviço com o cartão SIM, enquanto o Subsistema da

Estação Base controla a ligação com o primeiro. O Subsistema de Rede tem a função de

controlar as ligações entre Estação Móvel e os outros subscritores de redes móveis ou


Duarte Fernandes

9

fixas, assim como o controlo da mobilidade que permite ao subscritor variar a sua

localização física durante a transferência de dados/voz. Os principais serviços

fornecidos pelo sistema GSM são os seguintes:

Comunicação de voz;

Serviço de SMS;

2.3 Visão Global dos Sistemas Existentes no Mercado

É possível encontrar atualmente no mercado, uma enorme variedade de sistemas

de gestão de frotas, com uma grande diversidade de tecnologias bem como

funcionalidades concebidas ao cliente. De seguida serão apresentadas algumas soluções,

sendo abordadas as funcionalidades fornecidas, as vantagens, o custo do produto no

mercado atual e quais as tecnologias empregadas no sistema de forma a distinguir a

ferramenta IntelFleet dos demais.

2.3.1 Xtran Gestão de Frotas

O XTran Gestão de frotas é uma ferramenta desenvolvida pela empresa Tecmic,

é descrita como uma ferramenta essencial na gestão de todos os recursos que

desenvolvem o seu trabalho fora da empresa (viaturas e condutores), baseados numa

arquitetura Cliente/Servidor [11]. O XTran permite a gestão através de informações

recebidas de forma automática pelo equipamento instalado nos veículos. Este sistema é

constituído por um sistema central que permite à organização gerir toda atividade,

comunicando com todas as unidades instaladas nos veículos como ilustrado na Figura 2,

através de vários meios de comunicação (GSM, GPRS, CDMA entre outros).

Figura 2 - Overview da solução Xtran, [11].


Duarte Fernandes

10

Com uma comunicação bidirecional e atualização em “tempo real” da informação das

viaturas, o XTran permite conhecer em qualquer momento o estado dos veículos, inserir

e localizar locais, traçar rotas percorridas e alertar passagem por zonas previamente

delimitadas. A ferramenta descrita evita a utilização de relatórios escritos, optando por

apresentar toda essa informação de forma gráfica, uma interface mais amigável do

ponto de vista do utilizador, como apresentado na Figura 3.

Figura 3 - Geração de relatórios informando distâncias percorridas, velocidades entre outos na forma de

gráficos, [11].

O equipamento instalado é composto por uma consola para auxílio de navegação (ecrã

tátil de alta resolução e grandes dimensões), um módulo eletrónico (unidade móvel) que

integra um recetor do sistema GPS e um terminal de comunicação móvel que estabelece

comunicação com a central. Este equipamento disponibiliza várias entradas digitais e

analógicas, para ligação de periféricos (impressora, sensores etc.) de acordo com as

necessidades do utilizador. A comunicação entre o condutor e a central/gestor é

estabelecida através de um equipamento extra, designado de Terminal do Condutor. É

um equipamento portátil com autonomia semelhante aos exemplares apresentados na

Figura 4, pelo que pode ser removido do veículo e utilizado pelo condutor para registar

dados referentes ao serviço (entregas, confirmações de clientes, etc.).


Duarte Fernandes

11

Figura 4 - Equipamentos de hardware que compõem a ferramenta Xtran: consola "Dispatch & Navigation",

unidade móvel e exemplares do terminal do condutor respetivamente, [11].

A Tecmic disponibiliza uma interface para empresas que já contam com o XTran

instalado. É baseado na versatilidade dos Browsers da internet, possibilitando a

realização de consultas por parte de utilizadores autorizados a informações das

atividades desenvolvidas pelas frotas. Permitindo assim, acesso aos dados da frota em

qualquer local, desde que possua acesso à internet [12].

2.3.2 NVfrotasoft

A NVfrotasoft é uma solução de gestão de frotas via GPS/Web, com grandes

semelhanças da solução anteriormente apresentada, distinguindo-se do mesmo por

utilizar como meio de comunicação exclusivamente a rede GSM e por ser uma

ferramenta de gestão unicamente online. Esta ferramenta possibilita acompanhar em

tempo real a atividade da frota e visualizar todos os relatórios gerados. Na Figura 5 é

descrito graficamente os funcionamentos do NVfrotasoft, os veículos encontram-se

equipados com um localizador GPS compacto e fiável, enviando constantemente

informações via GSM para o data center onde é processada, organizada e armazenada

em servidores de elevada segurança. Estes servidores estão conectados via internet,

possibilitando ao utilizador o acesso a estes em qualquer parte do mundo. Os clientes

proprietários da ferramenta NVfrotasoft podem gerir níveis de acesso ao software,

protegendo os seus dados e privacidade [13].

A ferramenta proporciona ao utilizador a configuração de toda a informação, de forma a

simplificar a sua utilização, assim define quais as variáveis a ser analisadas e

incorporadas nos relatórios de gestão. Estes relatórios incluem informação de paragens,

passagem por marcos, velocidades, entre outros. Podendo ser enviados automaticamente

para os endereços de e-mail previamente configurados.


Duarte Fernandes

12

Figura 5 - Módulos que compõem a solução NVfrotasoft e interação dos mesmos, [13].

Os veículos são dotados de um equipamento recetor de GPS e de um terminal

identificador de condutor, funcionando como um sistema de registo e sistema de

segurança complementar de forma a impossibilitar que a viatura possa entrar em

funcionamento sem a identificação válida. Para visualização online do estado do

veículo, é realizada a georreferenciação no mapa, utilizando para isso o recurso do

Google Maps3, como comprova a Figura 6.

Figura 6 - A visualização da posição dos veículos (entre outras informações) na ferramenta NVfrotasoft é

realizada sobre um mapa, [13].

3 Serviço disponibilizado pela empresa Google, permite a pesquisa e visualização de mapas e imagens de

satélite do planeta Terra.


Duarte Fernandes

13

2.3.3 Moviloc

Esta solução é fornecida pela Moviloc®, consiste numa ferramenta Web para a

gestão, localização e otimização de frotas que não necessita de qualquer software

instalado. É facultado ao utilizador um leque de funcionalidades baseado nas

tecnologias GPS, GSM/GPRS e suportado pela plataforma de serviços de localização

PALVIEW®. Na Figura 7 é apresentado o funcionamento do sistema, que consiste na

utilização de um equipamento móvel instalado no veículo, encarregue de calcular a

posição geográfica, de obter dados do veículo e posteriormente os transmitir para uma

plataforma central, denominada PALVIEW® [14]. Esta armazena todos os dados,

minuto a minuto e implementa todas as ferramentas necessárias para que os utilizadores

realizem uma gestão da frota através de qualquer computador ligado à internet. Esta

solução Web fornece várias funcionalidades, são elas: localização em tempo real,

geração de relatórios de incidentes, histórico de descargas, exportação de dados para

Excel e alarmes automáticos por email/SMS.

Figura 7 - Funcionamento da ferramenta Moviloc desde o processo inicial de recolha de dados até ao objetivo

final que consiste na apresentação da informação relevante ao utilizador, [14].

Os veículos são equipados com uma vasta gama de periféricos, como ilustrado na

Figura 8. É utilizado e instalado no veículo o equipamento U-10, responsável por

recolher dados dos periféricos e transmitir-lhos ao servidor. De todos os periféricos é de

destacar o botão de pânico e o sistema de corte da injeção do veículo. O botão de

pressão é um periférico instalado discretamente no veículo com o objetivo de ser


Duarte Fernandes

14

pressionado em situações de alarme. Este aviso irá informar os utilizadores da situação

de alarme, transmitindo-lhes informações como a hora e o local da ocorrência.

Figura 8 - Equipamento MOVILOC® instalado no veículo, [14].

O sistema de corte da injeção do veículo permite a imobilização remota do veículo,

impedindo o arranque do veículo. Este sistema foi concebido de modo a ser ativado

remotamente assim que detetado o roubo do veículo como ilustrado na Figura 9.

Figura 9 - Imobilização veículo de forma remota, por ordem do Centro de Controlo, [14].

2.3.4 Outras Soluções no Mercado

Até então foram descritas algumas soluções de sistemas de gestão e localização

de frotas, baseados na tecnologia GPS com uma presença forte no mercado. Contudo

existem muitas outras soluções com funcionalidades semelhantes às descritas até então.

Uma das quais, disponibilizada ao cliente pela PT Negócios, um serviço de gestão de

frotas que pode ser caraterizado da seguinte forma: equipamentos instalados nas

viaturas obtêm informações GPS, do veículo e do condutor, permitindo a interação deste

com um gestor do sistema central [15]. Esse sistema central processa a informação e

torna-a disponível para os gestores do sistema, que lhe podem aceder recorrendo à

internet. A comunicação de dados entre o veículo e o sistema é feita através da rede

TMN, utilizando cartões SIM instalados nos equipamentos das viaturas. Encontram-se

então no mercado outras soluções, tais como:


Duarte Fernandes

15

InoFrota Trace, da Inosat;

Amplifrota, da Vodafone;

The NexTraq Platform da NexTraq;

Frotcom da Frotcom, lda.

2.3.5 Comparação das Soluções Descritas

De um modo geral, verifica-se que o princípio de funcionamento de todas as

soluções descritas é semelhante e comum entre elas, podendo-se descrever do seguinte

modo: equipamentos de tracking são instalados nos veículos para obter dados

representativos do seu estado. Os dados utilizados para traçar os percursos percorridos

são transmitidos utilizando algum meio de comunicação em tempo real. Algumas

funcionalidades extras são facultadas, geração de alarmes, relatórios da atividade,

sistemas antirroubo, consulta de dados via internet ou no centro de controlo e a inclusão

de periféricos que permite a monitorização de várias variáveis de negócio.

Em suma, estas soluções distinguem-se no meio de comunicação utilizada (GSM,

GPRS, entre outras) e nas funcionalidades oferecidas dependendo das necessidades do

utilizador. De modo a verificar todas estas considerações é apresentada uma tabela

comparativa das características das soluções descritas anteriormente (Tabela 2).

Tabela 2 - Comparação entre as soluções apresentadas/estudadas.

Tipo

de

Acesso

U.

Móvel

Especifi

ca/ Tec.

GPS

Sistema

de

seguran

ça

Meio

Comunica

ção

Mapas Relatórios

/Alertas

Preço

Unid.

XTran PC e

Web Sim/GPS Não

GSM/GPRS

entre outros

Google

Maps Sim/Sim ?

NVfrotas

oft Web Sim/GPS Sim GSM

Google

Maps Sim/Sim ?

Moviloc Web Não/GPS Sim GSM/GPRS Google

Earth Sim/Sim ?

PT

Negócios Web

Não/A-

GPS Sim GSM/GPRS

Google

Maps Sim/Não

25€ Mês

Frotcom Web Não/GPS Não GPRS Google Maps/

Bing maps Sim/Sim ?

The

NexTraq Web Sim/GPS Não GSM ? Não/Não ?

InoFrota

Trace Web Sim/GPS Não GSM

Google

Maps Sim/Sim 25€

Mês


Duarte Fernandes

16

Verificou-se que praticamente todas as soluções se baseiam num sistema de gestão de

frotas online, proporcionando a vantagem aos utilizadores de acompanhar as frotas em

qualquer lugar, necessitando apenas de um dispositivo com acesso à internet sem

necessidade de instalação de softwares.

2.4 Exemplos de Dispositivos GPS Tracking

Nenhuma das soluções apresentadas oferece informação detalhada do hardware

utilizado, para colmatar esta falta de informação é apresentado de seguida alguns

equipamentos de tracking disponíveis no mercado. Este subcapítulo termina com as

conclusões retiradas da comparação entre os dispositivos aqui apresentados.

2.4.1 G959 GPS Tracking

O G959 GPS Tracker é uma solução disponibilizada pela empresa Gosafe

Company, ltd, consiste num módulo de hardware para controlo e georreferenciação de

veículos [16]. O seu princípio de funcionamento baseia-se na interação entre o módulo

do sistema integrado no veículo e um telemóvel, componentes apresentados na Figura

10.

Figura 10 - Componentes constituintes do produto G959 GPS Tracker, [16].

O G959 permite além do tradicional controlo e gestão através de SMS e servidor, o

controlo do veículo remotamente via software instalado no dispositivo móvel do

utilizador, o que reforça a segurança do veículo. Este produto possui o conjunto de

especificações exibidas na Tabela 3.


Duarte Fernandes

17

Tabela 3 - Características do GPS tracker integrado com o dispositivo G945.

Especificações

Físicas Dimensão

Peso

91x65x28mm

100g

Alimentação

Bateria

Tensão

Consumo de corrente

500mAh Lion Recarregável

10-35V DC

140mA (Ativo), 80mA (Sleep)

Temperatura Temperatura de funcionamento

Humidade

-20ºC – +70ºC

5%-90%

Módulo GPS

Antena

Receiver

Canais

Exatidão de posição

Sensibilidade

Update de navegação

Externa

Ublox NEO-6M (GPS, Galilieo)

50 Canais paralelos

<2.5m

-162dBm

1 Segundo

Módulo comunicação

Modem

Antena

Ublox LEON G100 Quad Band

850/900/1800/1900 MHz, GPRS classe

10

Externa

Outros módulos

CPU

E/S

RAM estática de 32 Kbytes

Entradas e saídas digitais, entrada e

saída RJ45

2.4.2 HCT PRO Plus

A BrickHouse Security disponibiliza ao mercado o módulo HCT PRO Plus

apresentado na Figura 11, que consiste numa solução de rastreamento de viaturas,

utilizado na gestão de frotas [17]. É um produto destinado aos veículos, com uma

instalação fácil e escondida no interior do veículo, atualiza a sua posição geográfica a

cada 30 segundos e possui uma antena externa para maximizar o desempenho. O HCT

Pro Plus possui uma bateria de backup para continuar a fornecer informações de

localização, com uma autonomia de 12 horas.

Figura 11 - Dispositivo HCT PRO PLUS utilizado na localização de veículos, [17].

A Tabela 4 apresenta as principais especificações deste produto disponível no mercado.


Duarte Fernandes

18

Tabela 4 - Características do dispositivo HCT PRO Plus.

Especificações

Físicas Dimensão

Peso

104x93x26mm

114g

Alimentação

Bateria

Tensão

Consumo de corrente

Bateria do veículo

8-30V DC

680mA (pico max.), 95mA (média)

Temperatura

Temperatura de

funcionamento

Humidade

-30ºC – +85ºC

5%-90%

Módulo GPS

Antena

Canais


Sensibilidade


Externa

50 Canais paralelos

2.5m

-161dBm

27s

Módulo

comunicação

GSM

GPRS

GSM1800/900 classe 1, Quad Band

850/900/1800/1900 MHz

Classe 10, sensibilidade -110dBm

Outros módulos

E/S

5 Entradas digitais, 1 entrada analógica

1 Porta RS232, 2 Leds

2.4.3 QTracker GT-Q3000

A QSTARZ coloca à disposição o módulo QTracker GT-Q3000, que também se

destina à gestão de frotas de veículos, uma vez que partilha dados relativos à posição

geográfica do mesmo. O QTracker oferece total controlo e informação geográfica em

tempo-real via Google Map no telemóvel 3G [18]. Este produto apresenta as

especificações exibidas na Tabela 5.

Tabela 5 - Características do dispositivo QTracker.

Especificações

Físicas Dimensão

Peso

82x44x18mm

70g

Alimentação

Bateria

Tempo de carga

Tensão

Lion Recarregável

3hrs

3.0-5.0V DC

Temperatura Temperatura de funcionamento -10ºC – +60ºC

Módulo GPS

Antena

Receiver

Canais



Interna

Modulo MTK II GPS

66 Canais paralelos

<3m

<1 Segundo

Módulo comunicação Modem

Antena

850/900/1800/1900 MHz,

Interna

Outros módulos

E/S

Entrada Mini USB, Botão SOS


Duarte Fernandes

19

2.5 Comparação das Soluções Apresentadas

Depois de apresentadas e estudadas as diversas soluções de dispositivos GPS

Tracking, a partir da Tabela 6 podemos concluir que existem semelhanças comuns entre

eles. A sua arquitetura é idêntica e baseia-se nos seguintes três módulos: dispositivo

para processamento de dados (microprocessador e memória externa), hardware de

comunicação (GSM e/ GPRS) e módulos de E/S (entradas e saídas digitais e analógicas).

As principais diferenças baseiam-se em torno do suporte protocolar e nos consumos de

corrente, que por recomendação dos fabricantes de automóveis não devem ultrapassar

os 500 mA [19].

Tabela 6 - Comparação dos módulos GPS Tracker analisados.

Dimensões Peso Tipo

bateria

Módulo

GPS

Módulo

comunicação Protocolo

G959 GPS 91x65x28mm 100g Lion

Recarregável

Ublox

NEO-6M,

antena

externa

Ublox LEON

G100,

GSM/GPRS

ProtcoloTCP/IP

HCT PRO

Plus 104x93x26mm 114g

Bateria

veículo

Antena

externa GSM/GPRS

---

QTracker

GT-Q3000 82x44x18mm 70g

Lion

Recarregável

MTK II

GPS,

antena

interna

GSM

Protocolo TCP

e UDP


Duarte Fernandes

20


Duarte Fernandes

21

3. Caraterização do Problema

O presente capítulo apresenta uma análise do sistema a implementar, onde é

apresentado o problema a ser resolvido, bem como a justificação da escolha dos meios

(hardware e software) utilizados para alcançar os objetivos impostos. São ainda

apresentadas as restrições impostas ao sistema, de forma a conhecer além do âmbito do

projeto as suas possíveis limitações.

3.1 Exposição do Problema

As soluções de sistemas e gestão de frotas permitem às organizações explorar os

seus recursos, especialmente os meios que realizam os serviços aos clientes. Numa fase

inicial estes sistemas utilizavam meios de rastreamento de veículos passivos, estes

consistem em dispositivos de hardware instalados no veículo que coletam e armazenam

informação que em algum ponto será transferida para um PC. Este tipo de dispositivos

não permite o controlo, localização em tempo real dos veículos não podendo ser

utilizados como meio de garantir a segurança dos funcionários e produtos da empresa.

Assim um sistema de gestão de frotas além da aquisição de informação em tempo real

requer meios (software) capazes de utilizar estes dados para fins de controlo e

localização em tempo real, conduzindo a uma redução de custos, planeamento mais

eficiente dos serviços e aumento de segurança.

3.2 Requisitos do Sistema

De seguida é apresentado um conjunto de propriedades ou funcionalidades

desejáveis que especifiquem o comportamento do sistema.

Em qualquer ferramenta de gestão de frotas é necessário posse de informação relevante

e sempre atualizada, que permita alcançar o sucesso na gestão das frotas. Assim sendo

encontra-se aqui o primeiro requisito: a “monitorização” da frota deve ser realizada em

tempo real. Deste requisito surge a necessidade de acompanhar graficamente a atividade

da frota sobre um mapa. Para presentear estas funcionalidades aos utilizadores é

necessário implementar duas aplicações distintas, a primeira designada de Posto de

Trabalho, baseada na versatilidade dos browsers da internet, deverá permitir a

realização de consultas por parte de utilizadores autorizados a informações das


Duarte Fernandes

22

atividades desenvolvidas pelas frotas, para fins de planeamento dos serviços a serem

transmitidos aos condutores.

A segunda aplicação destina-se ao condutor, é uma aplicação designada de Terminal do

Condutor que será executada num tablet/smartphone, utilizando as potencialidades do

sistema operativo móvel instalado neste como meio de disponibilizar o conjunto de

funcionalidades necessárias ao condutor na realização das suas tarefas dentro da

organização.

O principal propósito desta aplicação passa por apresentar as informações das tarefas

planeadas pelos coordenadores, além disso deve permitir a consulta do histórico de

serviços realizados pelo condutor, facultar a posição do veículo em caso de roubo e

ainda dentro deste cenário, deverá possibilitar o controlo do veículo remotamente. Esta

ação irá bloquear o veículo impedindo que este seja utilizado indevidamente, assim e

através do conhecimento da posição do veículo após o bloqueio é possível recuperar o

veículo.

No seguimento das funcionalidades anteriormente apresentadas surge a necessidade de

outro requisito, a recolha e transmissão de informação do estado do veículo,

nomeadamente variáveis como a posição geográfica e sua velocidade proveniente do

módulo Unidade Móvel instalado no veículo, a uma taxa de amostragem definida pelo

utilizador de acordo com as necessidades da organização. Este elemento deverá ainda

ser capaz de interpretar comandos, de bloquear o veículo, impedindo utilizações

indevidas sempre que o condutor ou gestor assim “ordenar” de forma remota. Como

último requisito, a ferramenta deverá permitir o acesso e manipulação da base de dados

da organização, alocada num servidor. De forma a cumprir o requisito apresentado é

necessário implementar uma interface gráfica para o efeito, designado de Centro de

Controlo que se destina ao gestor, o indivíduo responsável por gerir toda a informação

da organização (adicionar, editar, eliminar dados), tais como funcionários, veículos,

clientes entre outros.

3.3 Restrições do Sistema

Para conceção do sistema de gestão IntelFleet são identificadas algumas

restrições ao nível do hardware e do software. Na solução proposta, um dos requisitos

apresentados é a atualização dos dados relativos ao veículo, neste requisito são


Duarte Fernandes

23

estabelecidas duas restrições, a primeira imposta pela tecnologia utilizada para obter os

dados do veículo, pois estes dados deverem ser fornecidos com base na tecnologia GPS,

a última restrição imposta encontra-se relacionada com a forma como estes dados serão

comunicados aos restantes elementos de modo a estarem disponíveis para o utilizador,

assim sendo a comunicação realizada deverá ser através da rede móvel GSM. A Unidade

Móvel consistirá num conjunto de módulos configurados para obter e transmitir dados

geográficos, sendo assim necessário um módulo GPS e um módulo GSM para a

transmissão dos dados da frota ao Centro de Controlo. Esta última aplicação necessita

de um modem GSM, capaz de receber os dados provenientes da Unidade Móvel.

Ao nível do software, é conhecido que a ferramenta a desenvolver será constituída por

três elementos baseados em software, são eles: Centro de Controlo, Posto de Trabalho e

o Terminal do Condutor. Estes elementos só serão úteis aos utilizadores caso permitam

o acesso à informação presente na base de dados, surge então a primeira restrição: o

desenvolvimento de uma base de dados que permita acesso remoto utilizando a

linguagem SQL. O Posto de Trabalho deve permitir aos colaboradores visualizar a

localização da frota sobre um mapa, sendo esta informação gráfica implementada a

partir da API do Google Maps [20]. O desenvolvimento do domínio do servidor

IntelFleet será realizado através da utilização das seguintes linguagens, Java Script,

PHP e ainda HTML. Por sua vez, o Terminal do Condutor deve ser executado num

smartphone/tablet. O Centro de Controlo será desenvolvido utilizando a linguagem de

programação C# e a API do Google Maps para apresentar a posição do veículo em

situações de alerta ao gestor.

3.4 Especificações de Hardware

Para o desenvolvimento da solução proposta são necessárias várias tecnologias,

que possibilitam a implementação das funcionalidades previstas. Este subcapítulo

apresentada as especificações dos dispositivos de hardware utilizados como meio de

usufruir das potencialidades dessas mesmas tecnologias.


Duarte Fernandes

24

3.4.1 Modem GSM, Telit EZ10-GPRS

É um produto colocado no mercado pela Telit Communications S.p.A, este

modem oferece uma completa solução para aplicações M2M4 sem fios [21]. É

controlado através da interface standart RS232 a uma tensão de alimentação que se

encontra entre os 9 e 24 volts. O EZ10 é um Dual-Band GSM/GPRS wireless modem

baseado na tecnologia GM862GSM/GPRS, o que significa que suporta até duas gamas

de frequências GSM (900/1800MHz), sendo capaz de oferecer serviço de voz, fax,

dados, GSM, SMS, GPRS.

O terminal permite o controlo remoto através de comandos AT. Mais detalhes deste

dispositivo com o aspeto da Figura 12 são exibidos no anexo A.2.

Figura 12 - Modem Telit EZ10-GPRS, [21] .

3.4.2 Unidade de Localização Móvel

Com um localizador via GPS e um comunicador GSM é possível localizar e

comunicar com as viaturas através de uma simples SMS [22]. A Unidade Móvel é um

dispositivo eletrónico que integra estas duas tecnologias, desenvolvido para ser

instalado no veículo, possibilitando assim o cálculo da posição geográfica do veículo

via GPS e transmissão das coordenadas e outros dados através das funcionalidades do

módulo GSM.

O dispositivo complementa-se com um sistema de bloqueio, permitindo o controlo

remoto da viatura, pensado para as situações de roubo. Em termos de hardware o

sistema é composto pelos seguintes módulos:

Unidade de processamento(a)

Alimentação da Unidade(b)

4 Refere-se ao conceito utilizado nas comunicações entre tecnologias com ou sem fios com outros

dispositivos que possuem mesma tecnologia.


Duarte Fernandes

25

Módulo de localização(c)

Módulo de Comunicação(d)

Sistema de bloqueio(e)

a) Unidade de Processamento

Este módulo é exclusivamente composto por um microcontrolador, que deve ser

capaz de processar dados de forma a manter o sistema a operar em tempo real. Para tal

foi selecionado um processador de 16 bits com a tecnologia nanoWatt eXtreme Low

Power (XLP). Os microcontroladores com esta tecnologia, permitem implementar

aplicações com as mesmas referências em termos de eficiência energética, capaz de

alcançar consumos baixos de corrente na ordem dos 20nA, são ainda aconselháveis para

aplicações que requerem elevado desempenho onde existe a necessidade de economizar

espaço e custos. Além destes motivos, existem outros que conduzem à escolha deste

microcontrolador (PIC18LF46K22 [23]), como o seu reduzido custo e algumas das suas

características que serão apresentadas de seguida.

Segundo o fabricante este uC possui as seguintes especificações: 64 KBytes de memória

Flash interna, 3896 Bytes de memória SRAM interna, EEPROM com uma capacidade

de 1024 Bytes de memória, velocidade máxima de relógio 64 MHz, tensão de

funcionamento entre os 1.8V e 3.6V, módulo ADC com 30 canais com uma resolução

de 10-bits, um módulo DAC, 35 pinos I/O e suporta os protocolos de comunicação SPI,

I2C e USART.

Um fator que pesou na escolha deste microcontrolador durante o planeamento da

Unidade Móvel, foi a necessidade deste possuir duas portas USART disponíveis para a

comunicação em série com os módulos de localização e comunicação, e ainda

disponibiliza pelo menos um timer indispensável na implementação de um tempo de

amostragem definido pelo utilizador.

b) Alimentação da Unidade Móvel

A Unidade Móvel é um dispositivo projetado para ser instalado no veículo, onde

é possível e se torna vantajoso retirar proveito dos seus recursos, nomeadamente a

bateria. Assim sendo, este módulo foi projetado para satisfazer todas as necessidades do

dispositivo a partir da fonte de alimentação da viatura, onde deverá ir ao encontro de

todos os níveis de tensão aplicados no circuito do dispositivo. Visto que a Unidade

Móvel é um sistema constituído por vários subsistemas (componentes), será necessário


Duarte Fernandes

26

aplicar vários reguladores de tensão para satisfazer as diferentes necessidades de

alimentação dos componentes. Foi escolhido o conversor step-down, PTN78060W

(Figura 13) para baixar o nível de tensão da bateria da viatura, que por norma possuem a

tensão nominal 12V e fornecem corrente contínua. Este conversor é bastante utilizado

na indústria automóvel pela sua versatilidade, o seu baixo custo e corrente máxima

extraída (3A) [24], mais que o suficiente para o sistema a desenvolver. Segundo o

manual do fornecedor, o conversor possui as seguintes características:

Tensão de entrada: 7V a 36V;

Tensão de saída: 2.2V a 12.6V;

Alta eficiência: >96%;

Corrente máxima de saída: 3A;

Temperatura de funcionamento: -40ºC até 85ºC.

Figura 13 - Conversor step-down PTN78060 W, [24].

c) Módulo de Localização

Este módulo é projetado para obter informações do veículo em tempo real. No

contexto da Unidade Móvel pretende-se calcular as coordenadas geográficas e a

velocidade da viatura, assim a sua função traduz-se na receção e transmissão de dados

no formato do protocolo NMEA para o microcontrolador escolhido para o

processamento destes dados. Este módulo é constituído unicamente por um recetor

GPS. O componente de hardware escolhido para o efeito é o FGPMMOPA6B

representado na Figura 14, é um módulo “ultracompacto” de alta precisão de velocidade

e localização em condições urbanas. Suporta até 66 canais, foi desenhado com um baixo

form factor em mente e é aplicável em diferentes aplicações, designadamente na gestão

e posicionamento de frotas, em sistemas LBS e AVL (Automatic Vehicle Location) e

ainda em dispositivos portáteis de posicionamento global ou para navegação [25], como

características principais do FGPMMOPA6B podem-se referir as seguintes:

Chipset MediaTek MT3329;


Duarte Fernandes

27

Sinal L1C/A code – utilização civil -, 66 canais;

Deteção e redução de interferência;

Precisão de localização:

o -Sem ajuda: 3m ;

o -DGPS:2.5m.

Baixo consumo de energia: 48mA durante a aquisição, 37mA após aquisição ;

Baixo consumo quando desabilitado: 15uA;

Frequência de atualização: Até 10Hz;

Interface USB integrado;

Figura 14 - Aspeto físico do recetor GPS FGPMMOPA6B, [25].

A Figura 15 ilustra o módulo GPS sobre a forma de diagrama de blocos, destacando os

diferentes componentes e os pinos I/O descritos na Tabela 7.

Figura 15 - Diagrama de blocos do módulo recetor GPS selecionado para o projeto, [25].

Para mais especificações técnicas acerca do módulo recetor GPS deve-se consultar o

manual do fabricante, que se encontra no anexo A.3.

Tabela 7 - Descrição dos pinos I/O do recetor GPS.


Duarte Fernandes

28

Pino Nome I/O Descrição 1 VCC Alimentação Fonte de alimentação DC, tensão devera se encontrar entre 3.2-5V

2 ENABLE I Em aberto ou em nível lógico para ativar módulo, nível baixo

desativa

3 GND Alimentação Ground

4 VBACKUP Alimentação

I

É a energia que mantem o RTC em execução quando alimentação

falha

5 3D-FIX O Saída para assinalar quando são encontradas os satélites

suficientes para funcionamento

6 DPLUS I/O USB Port DPLUS signal

7 DMINUS I/O USB Port DMINUS Signal

8 GND Alimentação Ground

9 TX O Este é o transmissor UART do módulo, é a saída para transmissão

de dados GPS

10 RX I É o UART Receiver do módulo, é utilizado para receber comandos

e Firmware Update

d) Módulo de Comunicação

O referido módulo é constituído unicamente por um componente que permite a

comunicação GSM entre a Unidade Móvel e os restantes elementos da ferramenta

desenvolvida. O componente escolhido para o efeito é o módulo da Siemens TC-35

apresentado na Figura 16, capaz de satisfazer todos os requisitos de comunicação

pretendidos. A seleção deste módulo em detrimento de outros deve-se em grande parte ao

facto de se tratar de um módulo compacto para transferência de dados, de voz na rede

GSM, com o leitor de SIMcard integrado permitindo a sua rápida e facilitada utilização

como um terminal dual band GSM [26]. A sua largura de banda e o seu desempenho

bem como a sua robustez física torna vantajoso o seu emprego em aplicações destinadas

a veículos, que se encontram sujeitos constantemente a instabilidades impostas pelos

caminhos percorridos pelos veículos.

Figura 16 - Módulo GSM da Siemens, TC-3, [26].


Duarte Fernandes

29

O componente em questão permite que um microcontrolador o controle via AT

commands, em que cada um desempenha uma função e pode ser precedida de

parâmetros que especificam a operação pretendida, mais detalhes sobre comandos AT

são exibidos no anexo A.4. As principais características identificadas do módulo TC-35

são:

Interface RS232;

Dual Band EGSM900/GSM1800;

Dados, Voz, SMS e Fax;

CSD acima de 14.4 Kbps;

Gama de tensão de alimentação: 8V-30V;

Baixo consumo energético;

LED sinalizador de estado;

Fácil integração;

Dimensões: 65x74x33 mm.

Sistema de Bloqueio

O sistema de bloqueio foi planeado de forma a permitir a imobilização segura do

veículo. Existem várias alternativas, são elas:

Corte da corrente na bobine de ignição, utilizado em veículos descapotáveis

como método de prevenir furtos;

Corte na bomba de combustível [27], o que faz com que o veículo pare por

completo ao fim de pouco tempo por consequência de falta de combustível;

Controlo da centralina, isto é, fornecer diretamente ao veículo o comando de

paragem e ainda enviar outros comandos, como por exemplo o bloqueio das

portas do veículo [2];

Imobilizar o veículo a partir do corte da corrente de saída da bateria elétrica;

Os sistemas de bloqueio listados, apresentam diferentes pontos de vista, entre eles

podemos identificar o método de bloqueio por controlo da centralina como o que maior

controle proporciona sobre o veículo. A imobilização do veículo através do corte da

corrente da bateria elétrica não permite instantaneamente imobilizar o veículo, contudo

possibilita que uma vez desligado não seja possível a sua reutilização, pois é necessário

a energia proveniente da bateria para efetuar a ignição do veículo. Este modo de


Duarte Fernandes

30

funcionamento apresenta como vantagem a total integridade dos produtos e utilizadores,

uma desvantagem identificada é a necessidade de um dispositivo robusto e com elevado

de poder de corte, pois a corrente de saída de uma bateria pode atingir valores elevados.

Entre as diferentes soluções plausíveis descritas optou-se pela imobilização do veículo a

partir do corte de corrente na bomba de combustível, nesta solução o veículo não é

parado instantaneamente, enquanto existir combustível no circuito ele continuará a ser

utilizado, após isto o veículo deixará de fazer a combustão/explosão desligando-se.

Conclui-se que se trata de uma solução viável, que entre as várias soluções apresentadas

é que melhor balanço gera entre os parâmetros de segurança, facilidade de

utilização/instalação e tempo de imobilização. Para corte da alimentação da bomba de

combustível do veículo é utilizado por norma um relé [28].

Quando recebidas ordens de imobilização é efetuado corte por completo da alimentação

da bomba fazendo com que o veículo pare. A instalação do sistema de corte de

combustível é simples, basta interromper o fio de alimentação que vai para a bomba e

ligar dois fios em cada lado do fio cortado conforme ilustrado na Figura 17 ao relé,

como deu para entender e como qualquer acessório antirroubo altera a originalidade do

veículo.

Figura 17 - Instalação do sistema de corte da bomba.

3.5 Especificações de Software

Nesta secção é especificado o software necessário para implementação da

ferramenta proposta, dentro deste é possível subdividir a ferramenta IntelFleet em vários

subsistemas de acordo com os diferentes utilizadores.

3.5.1 Interface com os Utilizadores

A solução IntelFleet disponibiliza diferentes interfaces, visto que a ferramenta

não se destina apenas a um utilizador, só assim suporta as atividades dos diferentes

intervenientes das organizações. Cada um destes utilizadores deverá possuir um


Duarte Fernandes

31

conjunto de funcionalidades disponibilizadas pela ferramenta. Consoante a sua tarefa

dentro da empresa é lhe atribuída uma interface com o sistema, de forma a garantir o

cumprimento das suas tarefas. Assim sendo, podemos identificar os seguintes potências

utilizadores dentro da organização:

Gestor (a)

Condutor (b)

Coordenador (c)

a) Gestor

O primeiro utilizador, o Gestor, tem a tarefa de gerir a informação da ferramenta

IntelFleet, tais como os dados dos recursos humanos e físicos da empresa. Este

utilizador realiza funções tais como adicionar, editar e eliminar veículos, clientes e

condutores, entre outras funcionalidades ilustradas na Figura 18.

Figura 18 - Funcionalidades do sistema do ponto de vista do Gestor.

A aplicação que lhe confere interface com o sistema é o Centro de Controlo, esta

aplicação é o sistema central da ferramenta, pois habilitará o tracking dos veículos

através do envio de pedidos de atualização da sua informação e posterior receção e


Duarte Fernandes

32

processamento das variáveis monitorizadas da Unidade Móvel. Além de proporcionar a

gestão dos dados da empresa como já referido, gera relatórios diários das atividades dos

veículos para a consulta por parte do Gestor e ainda um ErrorLog, utilizado para

armazenar detalhes dos erros detetados na comunicação com os veículos, como meio de

alertar o Gestor de anomalias identificados no sistema. Na Figura 19 são ilustradas as

funcionalidades que a interface do Gestor deve suportar de forma a garantir que este

consiga realizar todas as tarefas inerentes à sua função dentro da empresa.

Figura 19 - Funcionalidades a suportar pela interface do Gestor.

Software e Tecnologias de Desenvolvimento

A linguagem de programação a utilizar no desenvolvimento da aplicação é o C#.

A familiarização com a linguagem, os documentos de apoio disponíveis e as

ferramentas de apoio existentes e conhecidas foram critérios que pesaram na escolha

desta linguagem de programação. Além disso, esta é uma linguagem orientada a objetos

projetados para trabalhar com a plataforma NET da Microsoft, a partir desta relação a

linguagem obtém as classes ou funções de execução, o que permite que um programa

compilado num determinado sistema operativo seja executado noutro, pois as aplicações

deixam de ser implementadas para um determinado sistema operativo mas sim para a

Framework obtendo portabilidade de código que antes não existia [29].

Além desta linguagem, sendo ela a principal utilizada não evita a necessidade de

recorrer a outras tecnologias de forma a cumprir os requisitos apresentados em 3.2

(Restrições do Sistema) nomeadamente a utilização da linguagem SQL para consulta da

Centro de Controlo

Gestão de Recursos

Adicionar/Editar/Eliminar

Veículos Condutor Clientes Coordenadores

Geração de Relatorios

Visualização

ErrorLog

Geração de Alertas

Comunicação com Veículos

Manipulação Tempo de

Amostragem

Gestão da seleção de veículos a monitorizar


Duarte Fernandes

33

base de dados; a implementação de um Windows Service utilizando a linguagem de

programação C# [30], justifica-se pela necessidade de o sistema se encontrar

constantemente em comunicação com os veículos.

O ambiente de desenvolvimento adotado, para a produção da interface com o utilizador

Gestor, é o IDE da Microsoft, o Visual Studio 2010. Este programa permite a edição e

organização de todo o código fonte utilizado no desenvolvimento da interface e possui

ainda um modo de debugger que permite certificar o trabalho realizado. Este ambiente

de desenvolvimento foi também escolhido para a implementação do serviço que corre

em background, que juntamente com aplicação gráfica formam o Centro de Controlo.

b) Condutor

Este utilizador executa todas as suas tarefas fora da organização e portanto é um

elemento com especial atenção. Assim sendo, a organização necessita de supervisionar

estes utilizadores, de estar em contacto com eles e ainda de lhes oferece um conjunto de

funcionalidades que os auxilie nas suas tarefas com o objetivo de reduzir custos e

aumentar o desempenho na execução das suas tarefas. Estas funcionalidades encontram-

se representadas no Diagrama Use-Cases da Figura 20.

Figura 20 - Funcionalidades da ferramenta IntelFleet do ponto de vista do Condutor.


Duarte Fernandes

34

Neste conjunto de funcionalidades apresentadas do ponto de vista do utilizador

condutor, é de destacar a funcionalidade “Registo de veículos” pelo facto de não ter sido

referida até então ao contrário das restantes. Os dados dos condutores e dos veículos são

armazenados numa base de dados existindo uma relação entre eles, na linguagem SQL é

possível criar relações entre registos/tabelas, portanto a cada condutor é “atribuído” um

veículo, estando esta informação armazenada e disponível aos diferentes utilizadores.

Contudo, dentro da organização cliente existirá a possibilidade dos condutores alterarem

de veículo, estando a partir de então a utilizar um veículo que não lhe foi atribuído

inicialmente, consequentemente a informação relativa aos recursos da organização passa

a estar desatualizada. De forma a combater este problema foi introduzido um sistema de

registo de veículo, esta funcionalidade permite indicar à organização a alteração

realizada pelo condutor, estando sempre atualizada a informação disponível aos

utilizadores, mais detalhes são apresentados posteriormente.

A aplicação que confere ao condutor a interface com o sistema é designada de Terminal

do Condutor, baseia-se numa aplicação que é executada sobre o sistema operativo

móvel adotado para implementação da referida aplicação. Na Figura 21 é ilustrado

todos os módulos que constituem a aplicação e que conferem as funcionalidades

facultadas ao condutor. Todo software/linguagem de programação utilizado na sua

conceção é apresentado de seguida.

Figura 21 - Funcionalidades que a interface do Condutor deve suportar.


IntelFleet/Terminal do Condutor

Histórico de

Tarefas

Consulta

Controlo do

veículo

Consulta da localização

geográfica do veiculo

Notificação de tarefas

Visualização da informação das tarefas e rota a

executar

Sistema de registo de veiculos

Registo de alteração de

veículo

Alertas

Pazo da tarefa a expirar/expirad

o

Rota desrespeitada


Duarte Fernandes

35

Antes de determinar qual a linguagem de programação a utilizar é necessário

decidir sobre qual o sistema operativo irá decorrer a aplicação. Para tal foi realizado um

estudo dos diferentes sistemas disponíveis no mercado dos dispositivos móveis.

Atualmente, os sistemas operativos dominantes em dispositivos móveis são: iOS da

Apple, Android da Google, BlackBerry’s OS e Microsoft Windows Mobile [31]. Os

critérios adotados na seleção de um sistema operativo são: quota de mercado, suporte de

informação, facilidade de desenvolvimento de aplicações, plataforma desktop suportada

e licença da aplicação. A seguinte tabela (Tabela 8) compara estes sistemas operativos

de acordo com a licença, linguagem de programação e plataforma de desenvolvimento

suportada oficialmente.

Tabela 8 - Descrição dos principais sistemas operativos no mercado de dispositivos móveis.

S.O Licença

Linguagem

de

Programação

Plataforma de desenvolvimento

iOS Proprietário Objective-C Mac OS/Unix-Like

Android Open Source Maioritariamente

Java Multiplataforma

Blackberry Proprietário Java Windows

Symbian Proprietário C++ Multiplataforma

Windows

Mobile Proprietário

Dot NET

languages (C#,

C++, VB.Net)

Windows

Após isto, o sistema operativo selecionado é o Android por se tratar de um sistema

open-source de fácil desenvolvimento, sem barreiras à entrada e difusão. Outra

interessante vantagem é a possibilidade de aplicações escritas para smartphones serem

facilmente implementadas para tablets sem grandes ou nenhumas alterações técnicas.

A linguagem de programação utilizada no desenvolvimento de aplicações Android é o

Java.

De modo a garantir alguns dos requisitos apresentados no subcapítulo 3.2 (Requisitos

do Sistema) é necessário recorrer a recursos do Android. Exemplo disso é a necessidade

da aplicação comunicar com o mundo exterior, a partir do uso de mensagens de texto é

possível cumprir este requisito. O Android vem com uma aplicação de SMS built-in [32]

o que permite o envio e receção de mensagens de texto. No contexto da aplicação

Terminal do Condutor é necessário utilizar recursos de SMS, sendo utilizado na

comunicação com a Unidade Móvel (bloqueio do veículo, pedido de localização) e com

o Centro de Controlo (transmissão bidirecional de alertas/ordens). A aplicação Terminal


Duarte Fernandes

36

do Condutor receberá por parte do Posto de Trabalho os detalhes dos serviços

especificados pelo coordenador, para tal é necessário utilizar recursos Networking do

SO para baixar arquivos XML do servidor e analisar o seu conteúdo.

O ambiente de desenvolvimento adotado para a produção da interface com o utilizador

Condutor é o Android SDK e Eclipse. O Android SDK fornece ferramentas e APIs

necessárias para o desenvolvimento de aplicações destinadas à plataforma Android

utilizando a linguagem de programação Java, encontrando-se disponível para o

Windows, Linux e Mac [33]. O Eclipse é um ambiente de desenvolvimento

multiplataforma que corre em todos os principais sistemas operativos. O Google fornece

um plug-in para o Eclipse que permite uma utilização fácil e controlo das instalações

Android SDK. Este plugin é chamado de ADT Plugin (Android Development Tool),

depois de instaladas a maioria das ferramentas SDK podem ser acedidas através do

Eclipse [34]. Este ambiente de desenvolvimento foi o escolhido em detrimento de

outros IDEs por ser o ambiente suportado oficialmente.

c) Coordenador

Este utilizador tem como tarefa, a supervisão e planeamento das tarefas da frota,

de forma a alcançar estes fins é necessário disponibilizar informação relevante, e

atualizada que melhor descreva a atividade da frota. A gestão da atividade da frota é a

maior responsabilidade para um utilizador dentro da organização, onde apenas com uma

correta gestão se consegue alcançar metas fundamentais para a redução de custos, entre

outros objetivos desejados pela organização. Desta forma, é necessário que a ferramenta

proposta implemente uma interface, capaz de facultar um conjunto de funcionalidades

(Figura 22), que do ponto de vista do coordenador são essenciais na realização das suas

tarefas.

A interface deste utilizador com a ferramenta IntelFleet, denomina-se de Posto de

Trabalho e é acessível através de um browser num dispositivo com acesso à internet.

Baseia-se no acesso ao domínio do servidor, que armazena toda a informação das

atividades e dados da organização, este domínio faculta todas as ferramentas necessárias

ao coordenador para a realização das suas tarefas dentro da organização.


Duarte Fernandes

37

Figura 22 - Funcionalidades da ferramenta do ponto de vista do coordenador.

Na Figura 23 são ilustrados todos os módulos que conferem as funcionalidades do

coordenador através da interface desenvolvida para o efeito. Todo software/linguagem

de programação utilizado na sua conceção é apresentado de seguida.

Figura 23 - Funcionalidades suportadas pelo posto de trabalho.


A inclusão de mapas embebidos diretamente nas páginas do domínio designado

de posto de trabalho é um requisito desta interface/aplicação, só assim se consegue

implementar funcionalidades essenciais para o coordenador. Atualmente, existe vários

serviços que fornecem uma variedade de funcionalidades que vão de encontro às

necessidades da aplicação, as principias e mais utilizadas encontram-se descritas na

Tabela 9, são elas o Google Maps e Yahoo Maps.

IntelFleet/Posto de trabalho

Recursos físcios e humanos

Consulta

Supervisão

Consulta da localização geográfica/rota do veiculo no mapa

Planeamento de tarefas

Criação de tarefas


Duarte Fernandes

38

Tabela 9 - Comparação entre as API’s da Google e Yahoo Maps.

Goole Maps Yahoo Maps Não possui Geocoder “próprio” Proporciona seu próprio Geocoder

Mapas podem ser gerados em qualquer página

com correspondente Key Os mapas serão unicamente gerados em Yahoo

Utiliza Ajax Não utiliza Ajax

Pode ser utilizado para propósitos comerciais

sempre e quando for gratuito para utilizador

final

Pode ser utilizado para propósitos comerciais, mas é

necessária autorização para esse efeito

Pode agregar texto HTML ou XML em uma

pequena janela de informação

Pode agregar texto HTML em uma pequena janela de

informação e permite o uso de IFRAMES

Nenhuma restrição de uso Nenhuma restrição de uso

Optou-se por utilizar os serviços do Google Maps, essencialmente pela sua versatilidade

e compatibilidade. A última versão da API (V3 ) foi desenvolvida especialmente para

ser mais rápida e apresentar maior compatibilidade com as aplicações tradicionais para

browsers e também com dispositivos móveis [35], sendo que este é um aspeto

importante a ter em conta na seleção do serviço a utilizar, visto que este serviço será

necessário também na aplicação para dispositivos móveis (Terminal do Condutor). A

API consiste num conjunto de classes que oferece uma interface ao programador para

que possa desenvolver suas aplicações, como exibir mapas, implementar funções de

zoom, realizar consultas por endereços ou por coordenadas geográficas entre outras

possibilidades. A última versão (v3) fornece diversos utilitários para manipulação de

mapas e adição de conteúdo aos mapas por meio de serviços, permitindo obter

aplicações de mapas robustas [36].

Para desenvolver a aplicação será necessária mais do que uma linguagem de

programação, a linguagem Java script é incorporada nos ficheiros HTML (lado do

cliente) enquanto do lado do servidor é necessária a utilização da linguagem de

programação PHP [37] para processar e gerar uma resposta à solicitação de informação

por parte do cliente. Devido à necessidade de apresentar ao utilizador informações

armazenadas no servidor recorre-se à tecnologia Web service, esta permite a aplicações

com diferentes linguagens enviar e receber dados em formato XML. Ainda neste

contexto, será utilizada a tecnologia AJAX para tornar a página Web mas interativa com

o utilizador, esta tecnologia consiste num conjunto de técnicas de desenvolvimento Web

[38] usadas no lado do cliente com o propósito já referido.

O ambiente de desenvolvimento adotado para a produção da interface com o utilizador

Coordenador é o Dreamweaver. Trata-se de um software de design Web que fornece

uma interface visual intuitiva para criação e edição de sites em HTML. O Dreamweaver


Duarte Fernandes

39

conta com uma enorme comunidade de programadores que tornam disponíveis

extensões, estes são pequenos programas que qualquer programador web pode escrever

e qualquer um pode obter e instalar, o que proporciona funcionalidades adicionais ao

software. Apesar de tudo isto, a principal característica que conduziu à decisão de

utilização deste software foi os diferentes modos de programação que disponibiliza ao

utilizador, sendo eles: modo Design, este esconde os detalhes do código HTML do

utilizador, permitindo aos designados de não especialistas em HTML criarem suas

próprias páginas e aplicações Web. Encontrando assim um grande interesse na utilização

deste modo, pois permite esconder detalhes referentes ao design da página Web,

possibilitando aos utilizadores com pouca experiência em web design desenvolver a

interface da página de forma gráfica e intuitiva com muita maior facilidade do que

através de código; modo Código, suporta todas as sintaxes das linguagens de

programação cobertas pelo software fornecendo dicas ao utilizador. O software

disponibiliza também uma ferramenta que após indicar um browser, permite visualizar

uma previsão da página HTML.

3.5.2 Software Adotado para o Desenvolvimento da Unidade Móvel

O ambiente de desenvolvimento da unidade de localização móvel pode ser

dividido em duas categorias distintas e que melhor traduzem o processo de

desenvolvimento da unidade: o desenvolvimento do software e o desenvolvimento do

hardware.

No âmbito do desenvolvimento do hardware, este permite a criação de um esquemático

com os componentes físicos e respetivas ligações. Após obter o esquemático aprovado

bem como todas as ligações entre os componentes certificados, dará origem a uma PCB

(placa de circuito impresso), à escala que permite a disposição dos componentes de

hardware de forma a minimizar o número de vias possíveis.

O software adotado para o desenvolvimento e validação da PCB é o CadSoft EAGLE

que possui um grande conjunto de bibliotecas e ainda suporte online [39].

Para produção de software foi adotado o ambiente de desenvolvimento MPLABX por

ser um produto gratuito e recomendado pelo fabricante do microcontrolador. Em

conjunto com este IDE, é necessário selecionar também um compilador C, o eleito é o

HI-TECH PICC18.


Duarte Fernandes

40


Duarte Fernandes

41

4. Arquitetura e Desenvolvimento do Sistema

Este capítulo apresenta uma visão geral do sistema, recorrendo frequentemente a

diagrama de blocos para uma melhor descrição do funcionamento dos principais

elementos que constituem o projeto final. É ainda dado a conhecer os detalhes do

desenvolvimento do dispositivo de hardware (Unidade Móvel) e os detalhes das

diferentes aplicações de software que fazem parte das diferentes interfaces

desenvolvidas para os utilizadores, assim como o propósito da sua concessão. Antes

disto é demonstrado o modelo de dados desenvolvidos e adotados que define as

características de funcionamento e comportamento das aplicações de software.

4.1 Visão Global do Sistema

Alcançado este ponto, e após dar a conhecer os limites e restrições impostas ao

sistema bem como o âmbito do projeto procura-se obter uma melhor perspetiva do

sistema. Resumidamente o objetivo do projeto passa por desenvolver um sistema que

permita a gestão das atividades de uma frota através da informação GPS recolhida,

permitindo o seu controlo remotamente. Para alcançar este objetivo foi realizado o

estudo das várias soluções já existentes, descrito no capítulo 2 (Âmbito dos Sistemas de

Localização e Gestão). Através de uma análise detalhada das suas limitações e

vantagens oferecidas chegou-se à conclusão de quais os elementos que deverão

constituir o sistema, quais as suas funções e limitações a ultrapassar que no âmbito do

projeto mais se aproximaria da melhor solução possível. Assim identificaram-se os

seguintes elementos (representados no diagrama da Figura 24) que constituíram o

sistema IntelFleet: Centro de Controlo, o Terminal do Condutor, o Plano de Trabalho e

ainda a Unidade Móvel.


Duarte Fernandes

42

Base

Dados

Servidor Web

Posto de Trabalho

+ Coordenador

Detalhes dos serviços a realizar (Destino, tempo previsto

para realização, Kms, percurso entre outros)

Web Service via 3G

Centro de Controlo

+

Gestor

*

Unidade Móvel

Veículo

+

Pedidos e ordens sob a forma

de comandos

Informações do veículo

(Velocidade, coordenadas geográficas, entre outros)

Via GSM

Terminal do Condutor

+

Condutor

Info

rmaç

ões

do

veí

culo

(Vel

oci

dad

e, c

oo

rden

ada,

etc

.)

Via

GS

M

Ped

ido

s e

ord

ens

sob

a f

orm

a

de

com

and

os *

Via

GS

M

Avis

os

Ale

rtas

e o

rden

s

Figura 24 - Visão Global do sistema IntelFleet.


Duarte Fernandes

43

Este sistema é constituído por um sistema central, a aplicação designada de Centro de

Controlo instalada num computador local responsável pela comunicação com todas as

Unidades Móveis instaladas nos veículos, através do meio de comunicação GSM. A

informação que resulta desta comunicação, não é nada mais que variáveis que

influenciam as tomadas de decisão na gestão da atividade da frota, são processadas,

organizadas e armazenadas na base de dados, presente num servidor, onde se encontra

residente toda a informação da organização.

As unidades móveis são dispositivos instalados nos veículos, dotados de um módulo

GPS para o cálculo das variáveis necessárias (localização espacial e velocidade), de um

módulo GSM que estabelece a comunicação entre o veículo e o sistema central,

transmitindo-lhe os parâmetros descritos anteriormente. O dispositivo de hardware

integra ainda um sistema de bloqueio do veículo que permite a imobilização remota do

veículo, impedindo sua reutilização.

O acompanhamento em tempo real da atividade da frota é realizado online via

georreferenciação num mapa, através do acesso ao domínio do servidor onde reside a

base de dados que é atualizada com informação dos veículos proveniente das unidades

móveis instaladas nos veículos. Denominado de Posto de Trabalho, é onde os

coordenadores encontram toda a informação necessária para supervisionar e planear

todas as tarefas das frotas que são transmitidas aos condutores, de forma a serem

realizadas. Os dados das tarefas são apresentados aos condutores por meio de consolas

proporcionadas a estes pela ferramenta IntelFleet.

O Terminal do Condutor é a consola do condutor, consiste numa aplicação para o

sistema operativo Android executada num smartphone/tablet, com o intuito de

apresentar os dados das tarefas de forma amigável e gráfica, tais como trajeto a

percorrer, entre outros dados. Além desta funcionalidade, permitirá ao condutor o

controlo remoto do veículo, assim nas situações de furto é possível impedir sua

utilização indevida.

Na Figura 24 encontram-se ilustradas além dos elementos aqui descritos, os meios de

comunicação utilizados e por fim os tipos de dados trocados entre si.


Duarte Fernandes

44

4.2 Modelo Relacional

Em qualquer sistema que envolva base de dados é necessário realizar um modelo

de dados, só deste modo é possível obter uma boa organização e documentação de

dados. O processo de modelação de dados consiste na identificação de entidades, as

suas propriedades e os relacionamentos entre as entidades, representado através do

diagrama entidade-relação. No âmbito do sistema podemos identificar as seguintes

entidades, representadas no modelo ER da Figura 25. Este traduz-se nas seguintes

tabelas da base de dados alocada no servidor (denominada intelfleet_mydb):

Clientes_Alvo, Driver, Veiculo, Utilizadores, Servicos, Historico_Servico,

Linha_Servicos, Tipo_Alvo.

Figura 25 - Modelo Entidade-Relação da base de dados criada para o sistema IntelFleet.

A Tabela 10 apresenta uma breve descrição de cada uma das entidades que fazem parte

do modelo relacional.


Duarte Fernandes

45

Tabela 10 - Descrição das entidades/tabelas que compõem a base de dados intelfleet_mydb.

Tabela Descrição

Clientes_Alvo Tabela com informação textual sobre cada cliente da empresa, tendo como

campos mais relevantes as coordenadas geográficas da sede do cliente.

Tipo_Alvo Tabela com dados armazenados por defeito que permite identificar o tipo de

cliente, estes podem ser de dois géneros: cliente de destino da mercadoria ou

cliente fornecedor de mercadoria.

Driver Possui informação textual relativa a cada condutor que faz parte dos quadros

da organização.

veiculo Esta tabela armazena informação textual dos veículos que são propriedade da

organização e que são utilizados pelos condutores (ligação á tabela Driver).

Utilizadores A tabela referida armazena dados que permite identificar os coordenadores e

o seu estado (online/offline) que acedem ao Posto de Trabalho via Internet.

Produtos Possui informação textual relativa à mercadoria classificada por tipo de

produto, por exemplo: ‘produtos alimentares’, ‘produtos de desporto’.

Servicos

Esta é a tabela central de todo o sistema, pois permite armazenar dados dos

serviços prestados pela organização aos clientes. Os serviços possuem como

principal informação o destino (ligação á tabela Cliente), o Condutor e

Coordenador responsável pela tarefa (ligação á tabela Driver e Utilizadores

respetivamente). Os serviços estão classificados quanto ao seu estado: ‘em

execução’, ‘executado’ sendo ainda que qualquer serviço está ligado a uma

rota, que se traduz num conjunto de localizações, esta ligação é feita pela

seguinte tabela.

Historico_Servico Tabela com os pontos geográficos que representam a rota percorrida na

execução do serviço (ligação á tabela Servicos).

4.2.1 Relacionamento entre Entidades

A ferramenta IntelFleet visa essencialmente gerir as atividades que são

executadas fora da organização, mais concretamente as executadas pelo condutor. As

suas atividades baseiam-se maioritariamente na execução de serviços estabelecidos pela

organização/coordenador após sua requisição por parte do cliente, assim entende-se que

a entidade/tabela central seja “Servicos”. Na figura seguinte podemos identificar os

principais campos que constituem a tabela: a chave primária ‘num_servico’ permite

identificar de forma única um serviço na tabela, as chaves estrangeiras

‘Driver_num_driver’, ‘ID’ e ‘clientes_alvo_cod_cliente’ têm o prepósito de representar

um relacionamento entre tabelas. De notar que os relacionamentos impostos entre as

tabelas visíveis na Figura 26 possuem a mesma propriedade: uma relação de um para

vários. Isto significa, por exemplo na interação entre a tabela “Servicos” e

“Utilizadores” que um utilizador poderá se encontrar em um ou mais serviços

realizados, mas por sua vez um serviço só poderá ter um utilizador, o mesmo se aplica

às restantes relações.


Duarte Fernandes

46

Figura 26 - Relacionamento de várias entidades com a entidade central, “Servicos”.

Além destes encontram-se campos que traduzem os serviços, tais como a data em que

foi gerado um novo serviço requisitado por um cliente (‘data_inicio’), a data prevista

para a realização da tarefa (‘data_previsão_final’), os quilómetros a percorrer que utiliza

para fins de cálculo de distâncias de duas posições geográficas, a posição (ponto de

partida) do condutor/veículo selecionado no momento na requisição dos serviços e a

localização do cliente (ponto de chegada do serviço), o campo ‘data_realizacao’ pode

ter o valor nulo, pois este campo só é preenchido quando o condutor der indicação da

realização do serviço, o campo ‘realizado’ é utilizado para facilitar a pesquisa de

serviços pendentes ou realizados, por último os campos ‘latitude’ e ‘longitude’

especificam a posição geográfica de destino.

A relação entre as tabelas “Servicos” e “Histórico_servico” apresentada na Figura 27 é

importante durante o processo realizado pelo coordenador de geração de rotas, esta

última tabela armazena os pontos geográficos percorridos na execução de um serviço.

1..n

1

1..n 1

1..n

1


Duarte Fernandes

47

Figura 27 - Relação de uma para vários entre as entidades Historico_Servico e Servicos.

O relacionamento apresentado na Figura 28 entre as tabelas “Driver” e “veiculo” pode-

se traduzir do seguinte modo: cada condutor da organização tem zero ou mais veículos

associados e um veículo pode ter zero ou mais condutores associados.

Figura 28 - Relação entre as entidades Driver e veiculo.

Numa situação de pesquisa em que se pretenda conhecer qual o veículo que está

associado a uma tarefa por realizar, torna-se necessário percorrer o caminho desde a

tabela “Servicos” até “veículo”, através das chaves secundárias é possível. Obtendo o

identificador do condutor (‘num_driver’) na tabela “Servicos” realiza-se uma pesquisa

na tabela “Driver” adquirindo a sua chave secundária ‘veículo_matrícula’ que faz a

0..

1

0..1

0..1


Duarte Fernandes

48

ligação com a tabela “veículo”, assim através do identificador que nunca se repete

‘matrícula’ temos acesso aos restantes dados do veículo.

Junto com o modelo Entidade-Relação da Figura 25 é adicionado e mantido um

documento com explicação de todos os objetos nele criado. Este documento, pode ser

chamado de Dicionário de Dados e está disponível para consulta no anexo A.5.

Trigger

Consiste num evento gerado por alterações realizadas na base de dados, isto

permite a realização de ações no instante que este ocorre. Os triggers podem ser

divididos em duas categorias, por coluna e por declaração. A primeira categoria é

utilizada para ações nas colunas, por sua vez a restante categoria emprega-se ao

conjunto de declarações que aplicam UPDATE, DELETE e INSERT.

Os trigeers são bastante uteis no âmbito do projeto, sua utilização automatiza a relação

entre entidades, mantendo a integridade das tabelas da base de dados MySQL.

Devido às relações ilustradas na Figura 25, existe uma série de passos que devem ser

realizados sempre que uma tabela referenciada por outra sofre alterações. Por exemplo,

quando um dado veículo é eliminado da base de dados, é necessário remover a

associação dos condutores ao veículo, ou seja, caso exista algum condutor associado ao

veículo (campo ‘veiculo_matricula’) deve ser removida essa relação. O trigger

implementado na Figura 29 permite efetuar o tratamento da informação nas tabelas que

referenciam o veículo, quando é removido uma linha na tabela “veículo” é gerado um

evento que ira percorrer a tabela “Driver” e atualizar todas as linhas que possuem

referência à matrícula do veículo eliminado.

Figura 29 - Trigger responsável por remover ligação de um condutor a um veículo removido.

No dicionário de dados do anexo A.5 podemos identificar todos os triggers

implementados de forma a manter a integridade dos dados armazenados na base de

dados.


Duarte Fernandes

49

4.3 Centro de Controlo

A aplicação Centro de Controlo (Figura 30) tem um papel fundamental no

âmbito do projeto IntelFleet, anteriormente descrita como sistema central da ferramenta,

devido ao papel de intermediário que exerce entre os veículos (informação

representativa do seu estado) e o Posto de Trabalho. A aplicação é responsável pela

recolha dos dados e ainda de os disponibilizar ao coordenador. É ainda a interface entre

o utilizador gestor e a ferramenta IntelFleet, permitindo-lhe realizar todas as

funcionalidades apresentas em Figura 18.

Figura 30 - Arquitetura do Centro de Controlo.

Na arquitetura ilustrada na Figura 30, o Centro de Controlo encontra-se dividido em

dois grandes módulos, são eles:

Serviço, executado em background;

Aplicação gráfica que fornece interface ao utilizador;


Duarte Fernandes

50

Outro diagrama a ter em consideração é o da Figura 31, que representa a interação entre

o serviço e a aplicação gráfica. A decisão de dividir o Centro de Controlo em dois

grandes módulos, justifica-se pela necessidade de garantir uma comunicação constante

com os veículos, um possível exemplo prático que espelha este requisito seria: durante a

realização de uma tarefa mais duradoura com maiores distâncias a percorrer, é

necessário coletar a informação do veículo, o serviço é responsável por esta tarefa

excluindo a necessidade da aplicação gráfica se encontrar em execução durante esta

tarefa.

Figura 31 - Interação Serviço-Aplicação gráfica na aplicação Centro de Controlo.

Assim sendo, a aplicação executada em background é iniciada sempre que o

computador onde se encontra instalado é iniciado. Esta aplicação é executada em

segundo plano sem interação do utilizador, assim não é necessário o Gestor estar

conectado à aplicação gráfica para manter a comunicação com os veículos, para tal

apenas necessita manter o computador ligado.

4.3.1 Interface entre os Processos

A interface entre os processos serviço e aplicação gráfica é realizada recorrendo

aos sockets TCP/IP [40]. Esta interface permite ao utilizador comunicar com o serviço e

mais especificamente usufruir diretamente das funcionalidades do modem GSM. Assim

sendo, verificasse que os conceitos de Inter Process Communication (IPC) e threads

terão um papel importante nesta aplicação.

O fluxograma da Figura 32 ilustra o processo de comunicação entre as aplicações. Na

figura podemos identificar um servidor e um cliente, visto que a aplicação background é

implementada para correr continuamente, foi decretada servidor e por sua vez a

aplicação gráfica iniciada sobre comando do gestor será o cliente que ira requisitar uma

ligação ao servidor, para troca de informação. Quando fechada a aplicação gráfica é

dada por terminada a comunicação TCP/IP e libertados os recursos utilizados no

atendimento ao cliente (thread).

Comandos

Serviço Aplicação

Gráfica

Alertas

Feedbacks


Duarte Fernandes

51

Figura 32 - Comunicação entre aplicação gráfica e o background service via sockets.

Para tornar tudo isto possível é necessário criar e configurar o servidor TCP/IP e ainda

definir e implementar um processo que ficará à escuta de pedidos de ligação,

provenientes do cliente. Na figura anterior, é ilustrada a configuração da comunicação

Servidor-Cliente TCP/IP, do lado servidor é necessário como primeira etapa definir um

socket que requer dois identificadores são eles: o endereço IP (indica local de um nó na

rede) e sua porta (identifica o canal de dados). O lado do servidor comporta-se de forma

passiva, isto é, aguarda pedidos pela parte da aplicação gráfica (cliente), isto é iniciado

através do método Start do objeto TcpListener com os identificadores bem definidos.

Quando um novo pedido é recebido e processado, é enviada uma resposta ao cliente e o

pedido é guardado num objeto do tipo TcpClient, após aceite, é iniciado um objeto da

classe thread que irá manter a comunicação com a aplicação gráfica, enquanto esta se

encontrar aberta pelo utilizador.

Este foi o modo de implementação do servidor TCP/IP, sendo então momento de

detalhar a implementação do Cliente TCP/IP na aplicação interface gráfica

desenvolvida em C#. Assim sendo, no desenvolvimento do cliente é primeiramente

definido o socket, responsável por estabelecer a comunicação com o serviço através do

endereço IP e respetiva Porta passados como parâmetro no seguinte método.

requestSocket = new Socket(ip, port);

Após executada a instrução anterior, a conexão é estabelecida podendo então o cliente

enviar comandos ao servidor (descritos na Tabela 11) que traduzem as ações ou

intenções do utilizador.


Duarte Fernandes

52

4.3.2 Background Service

Na Figura 30 os módulos encontram-se contemplados com os subsistemas que

os constituem, para o caso do módulo serviço desenvolvido, existe além do subsistema

de comunicação que garante a comunicação deste com a aplicação gráfica outros quatro

subsistemas fundamentais, são eles:

Aquisição de dados geográficos (a);

Tratamento de dados (b);

Tratamento de erros (c);

Acesso e armazenamento de dados (d).

Antes de apresentar detalhes dos vários subsistemas que completam o módulo serviço,

invocados durante a execução da aplicação executada em background é descrito e

analisado o seu processo de Start-up ilustrado na Figura 33.

Este processo é iniciado com o estabelecimento de conexão à base de dados de forma

remota, a seguinte linha de código executa isso mesmo.

MySqlConnection(“Server=intelfleet.com;Database=intelfle_mydb;Uid=intelfle

_root;Pwd=xxxxx”);

O parâmetro Server indica o servidor e Database o nome da base de dados a quem será

estabelecida a conexão.

O seguinte passo, configura e inicializa o hardware utilizado pela aplicação Centro de

Controlo, processo descrito com maior detalhe ainda na presente seção. A partir deste

instante o serviço irá estar à espera dos dados provenientes das Unidades Móveis. O

passo seguinte é a obtenção através da realização de consultas à base de dados do tempo

de amostragem, definido pelo utilizador e da lista de veículos que estão assinalados para

monitorização das suas variáveis (localização, velocidade e se está livre de tarefas). Por

fim é criado o socket TCP/IP e iniciada a escuta a pedidos do cliente, isto é, o serviço

iniciará uma thread de atendimento ao cliente.


Duarte Fernandes

53

Figura 33 - Processo de Start-up da aplicação executada em background.

Interface com o Hardware

A presente aplicação, interage com o módulo GSM descrito na secção 3.4.1. Este

dispositivo permite a interação da aplicação Centro de Controlo com a Unidade Móvel e

Terminal do Condutor, para tal são utilizadas as seguintes interfaces:

Porta Série;

Rede GSM.

Através da porta série e envio de comandos AT é criada uma ligação entre o Centro de

Controlo e o modem GSM. De modo a utilizar a porta série recorreu-se a classe

SerilPort da biblioteca System.IO.Ports [29]. Para configurar uma porta é necessário

definir o baudrate, uso do bit de paridade entre outras características que podemos

encontrar na Figura 34.


Duarte Fernandes

54

Figura 34 - Algoritmo de configuração do modem GSM.

O fluxo de informação ilustrado na figura anterior representa a implementação da

configuração da porta série e posteriormente a conexão ao modem GSM. Este processo

inicia-se com a deteção de portas COM já utilizadas, o que pode significar que o modem

GSM já se encontra conectado fisicamente à entrada COM. Em caso afirmativo são

verificadas todas as portas COM conectadas com objetivo de detetar hardware utilizado

pelo Centro de Controlo. Para realizar este passo é necessário instanciar e inicializar um

objeto da classe SerialPort, com os parâmetros recomendados pelo fornecedor do

modem:

serialPort1=new SerialPort(serialports,9600,Parity.None,8,StopBits,One);

A instrução anterior inicializa o objeto chamado serialPort1 com um baudrate de

9600bps, sem bit de paridade, 8 bits de dados e um stopbit. Após aberta a conexão à

porta COM é finalmente testada a comunicação, o envio via série do comando “AT”

permite averiguar se o modem está conetado, pois após o envio é esperada uma resposta


Duarte Fernandes

55

dentro de um tempo (<3000ms), quando ultrapassado este tempo é gerado um timeout,

reportado o erro e terminada a execução do serviço.

Quando obtida uma resposta (“OK”) dentro do tempo espectável, é continuada a

execução do serviço, sendo que o próximo passo é a configuração da rede GSM. Por fim

e após configuração da rede GSM é indicada a função de atendimento

(SerialPort1_DataReceived) aos dados recebidos, esta função é invocada sempre que

novos dados são recebidos através da porta COM, o que corresponde ao subsistema

“Aquisição de Dados” descrito na 4.3.2.

serialPort1.DataReceived += new

SerialDataReceivedEventHandler(serialPort1_DataReceived);

No final destas configurações o equipamento está apto a ser utilizado pelo Centro de

Controlo e a comunicar com os restantes elementos da ferramenta IntelFleet via GSM.

a) Aquisição de Dados

O presente subsistema é responsável pela aquisição dos dados provenientes das

diferentes unidades móveis, é invocado quando são recebidas atualizações das

localizações das Unidades Móveis, o que requer a inicialização do hardware. Existem

dois tipos de aquisições: no modo periódica ou no modo “on-demand”, este último é

utilizado pelo Terminal do Condutor e pela presente aplicação enquanto o primeiro é

utilizado exclusivamente pelo Centro de Controlo.

Aquisição Periódica

Neste tipo de aquisição, como o próprio nome indica, corresponde a um evento

que ocorre em intervalos de tempo frequentes, definido pelo gestor de acordo com as

necessidades da organização. O utilizador gestor define o tempo de amostragem e

quando um veículo é colocado no modo periódico através da interface gráfica, é

comunicada essa intenção via socket TCP/IP ao serviço enviando o seguinte comando

(Tabela 11):

TRACKED_num;

O parâmetro “num” define o número do localizador (Unidade Móvel) instalado no

veículo, o procedimento do background service nesta situação é indicar à unidade

através do envio de comandos reconhecidos pelo mesmo que deseja receber


Duarte Fernandes

56

atualizações de forma periódica. O comando enviado encontra-se listado na -Tabela 17

e possui o seguinte formato:

*txxxx+

Os intervalos de tempo admissíveis e aceites pela ferramenta compreendem entre os 60

segundos e os 10800 segundos. Quando um veículo já se encontra em modo periódico e

com um tempo entre atualizações bem definido poderá ser alterado a qualquer instante

pelo gestor enviando novamente o comando anterior com o tempo desejado como

parâmetro.

Neste tipo de aquisições não é necessário enviar novos comandos a cada evento

ocorrido sendo apenas necessário indicar à Unidade Móvel para sair deste modo quando

não se deseja receber mais atualizações da posição do veículo através do envio do

comando:

*tstop+

Figura 35 - Fluxograma do subsistema de aquisição dos dados em modo periódico.

O fluxograma anterior reflete o comportamento do subsistema de aquisição de dados no

modo periódico. O serviço após enviar o pedido de atualização da informação do

veículo de forma periódica fica à escuta dos dados. Quando recebidos é invocado a

rotina de análise das mensagens de textos recebidas, abordada no presente capítulo na

secção 4.3.2 (Tratamento de Dados).


Duarte Fernandes

57

Aquisição “on-demand”

Este tipo de atualizações da informação do veículo, foi implementado a pensar

nas situações que apenas se deseja conhecer a localização do veículo nesse preciso

instante e não monitorizá-lo continuamente, sendo especialmente útil como meio de

recuperação dos veículos roubados. O fluxograma ilustrado na Figura 36 representa o

comportamento subsistema no modo “on-demand”.

Figura 36 - Fluxograma do subsistema de aquisição de dados no modo “on-demand”.

Através da interface gráfica o utilizador Gestor indica o desejo de atualizar as variáveis

do veículo no modo “on-demand”, quando tal ocorre a interface é responsável por

transmitir esse desejo ao serviço, através do envio do seguinte comando (descrito na

Tabela 11):

Demand_num

O parâmetro “num” identifica o localizador do veículo (número SIM), este é notificado

do pedido de atualização imediata através do envio do seguinte comando descrito na -

Tabela 17:

*t0000+

A partir deste instante, a aplicação executada em segundo plano fica à escuta dos dados

provenientes da unidade. Quando recebidos, são colocados à disposição do subsistema

Tratamento de Dados, tendo por fim a tarefa de alertar o utilizador da receção de novos

dados.


Duarte Fernandes

58

b) Subsistema de Comunicação

A presente secção demonstra como foi implementado o subsistema de

comunicação, responsável pela troca bidirecional de informação com os elementos

Unidade Móvel e Terminal do Condutor via GSM.

Receção de Dados

O Módulo GSM só é habilitado a receber mensagens quando configurado com

sucesso (processo de configuração GSM), a Figura 37 ilustra o comportamento da

aplicação após a receção de uma nova mensagem de texto.

Figura 37 - Comportamento sobre a forma de fluxograma do subsistema de Comunicação durante receção de

informação.

Quando recebida, é gerada pela porta série uma interrupção que invoca a função de

atendimento SerialPort1_DataReceived, nesta são realizadas as etapas apresentadas no

fluxograma, com o objetivo de consumir as mensagens de texto armazenadas no meio

de armazenamento definido durante a configuração da comunicação série (memória do

cartão SIM). Este processo inicia-se com a interpretação do comando recebido

(disponível no buffer da comunicação série), existe dois comandos AT de interesse para

o presente subsistema, são eles o CMTI e CMGR. O primeiro indica que foi recebida

uma nova mensagem e têm o seguinte formato:


Duarte Fernandes

59

+CMTI:”SM”, ID_SMS;

Deste comando é retirado o parâmetro “ID_SMS” que identifica a mensagem de texto

dentro da memória do SIM. Nesta situação é indicada a intenção de consumir o

conteúdo da mensagem de texto, através do envio do seguinte comando AT com o

parâmetro ID_SMS extraído no passo anterior:

AT+GMGR = ID_SMS;

O comando em falta (CMGR), indica que o conteúdo da mensagem de texto esta

disponível, colocando-o à disposição do subsistema Tratamento de Dados.

Os últimos passos visam garantir que nenhuns dados são perdidos, todas as informações

relevantes após tratadas e armazenadas na base de dados são eliminadas dando espaço a

novas informações/mensagens de texto. Contudo, pode ocorrer interrupções durante o

consumo da informação oferecida pela mensagem de texto gerado por uma nova SMS,

isto significa que o processo de consumo da informação anterior não foi terminado e

esquecido, ficando a nova informação com a capacidade de processamento.

De modo a evitar a perda de informações relevantes, são realizados os últimos passos do

fluxograma (Figura 37), estes eliminam as mensagens já consumidas (indicando o

ID_SMS no comando CMGD) e deteta a existência de mensagens “perdidas”, em caso

afirmativo estas são consumidas e esvaziada a memória SIM.

Envio de Dados

Como referido a transmissão é bidirecional, o que significa que este subsistema é

responsável pela transmissão dos dados aos elementos já mencionados na presente

secção. O fluxograma da Figura 38 identifica o fluxo de tarefas executadas por este

subsistema durante o envio de informação.

O primeiro passo verifica se o equipamento de hardware esta conetado, em caso

afirmativo o subsistema indica-lhe a intenção de enviar uma mensagem de texto para

um determinado destinatário através do seguinte comando:

AT+GMGS=N_SIM;

O passo final insere o corpo da mensagem e por fim o caráter CNTRL_Z, se o buffer da

porta série conter o valor “OK”, significa que foi realizada com sucesso as tarefas até


Duarte Fernandes

60

então do subsistema. Se este processo não for executado corretamente é reiniciado a

sequência de passos do fluxograma da figura seguinte.

Figura 38 - Comportamento sobre a forma de fluxograma do subsistema de Comunicação durante o envio de

informação.

c) Tratamento de Dados

Este subsistema de software é invocado após o subsistema de aquisição de

dados, isto deve-se à necessidade de processar a informação recolhida pelo subsistema

que o antecede para posteriormente armazenar e/ou apresentar os dados recolhidos aos

utilizadores. Este subsistema possui particular importância, pois a ele se deve a

responsabilidade de processar os dados recolhidos. Como exemplo, o Centro de

Controlo recebe atualizações da posição geográfica do veículo e após sua aquisição é

necessário reconhecer e validar estes dados utilizados para atualizar a informação

referente ao veículo. O fluxograma ilustrado na Figura 39 descreve o processo de

tratamento dos dados recebidos.


Duarte Fernandes

61

Figura 39 - Algoritmo do subsistema de tratamento de dados.

Após a receção dum comando é verificada qual a intensão do utilizador, isto indica qual

a ação que deverá ser realizada e ainda a informação que é necessária recolher do

comando. Existe uma variedade de comandos reconhecidos pela aplicação (descritos na

Tabela 11), assim é necessário comparar o comando com um lote de comandos

permitindo distinguir o tratamento correspondente ao pedido recebido.

Depois de identificado o tratamento a ser executado, é analisada a necessidade de

responder ao elemento que realizou o pedido, caso tal se verifique é enviada a

resposta/feedback ao respetivo elemento. No passo final é invocado o subsistema de

acesso e armazenamento de dados para atualização de informação.

A Tabela 11 descreve todos os comandos que são aceites e reconhecidos pelo serviço,

estes são provenientes da aplicação gráfica e resultam da interação do gestor com a

interface gráfica durante a execução das suas tarefas na organização.

Contudo existe outros comandos que não se encontram descritos na tabela anterior que

também são reconhecidos pela aplicação executada em background, estes comandos são

provenientes das unidades de localização móveis e resultam dos pedidos de localização

e de bloqueio. A descrição destes comandos é realizada na seção 4.6.2 (Formato da

Resposta às Solicitações de Atualização da Localização Unidade Móvel)


Duarte Fernandes

62

Tabela 11 - Comandos provenientes da interface gráfica reconhecidos pelo serviço.

Comando Parâmetros Descrição Tratamento

TRACKED_localizador

Localizador-número

SIM da unidade de

localização móvel

Pedido de

atualização de

dados geográficos

no modo

periódico

Envio de comando à

unidade móvel

indicando o início de

comunicação de forma

periódica

STOP_localizador

Localizador-

número SIM da

unidade de


Pedido de

paragem de

atualização de

dados no modo

periódico

Envio de comando

indicando a intensão de

não voltar a receber as

atualizações de forma

periódica

UPDATE_time

Time-tempo entre

atualizações definido

em segundos

Alteração do

tempo do tempo

de amostragem

Envio do status do

processo de alteração

ao Gestor

FEEDBACK_ACTIONS ----

Request do status

da comunicação

no modo

periódico com

todos os veículos

Criação de uma string

com a informação da

comunicação, onde

esta indica o número

de atualizações já

recebidas, isto permite

detetar falhas na

comunicação

DEMAND_localizador

Localizador-número

SIM da unidade de


Pedido de

atualização dos

dados geográficos

no modo “on-

demand”

Envio de comando à

unidade móvel pedindo

a atualização da

localização geográfica

no preciso instante

BLOCK_localizador

Localizador-número

SIM da unidade de


Pedido de

bloqueio do

veículo

Envio do comando de

bloqueio reconhecido

pela unidade móvel

UNBLOCK_localizador

Localizador-número

SIM da unidade


Pedido de

desbloqueio do

veículo

Envio do comando de

desbloqueio do veículo

reconhecido pela

unidade móvel

d) Tratamento de Erros e Alertas

Nesta secção do presente capítulo é descrita a estratégia usada na geração de

alertas e tratamento de erros. O primeiro tema abordado é o tratamento de erros, seu

objetivo é verificar se a informação proveniente dos restantes elementos do sistema é

válida de forma a não ser processada e armazenada informação invalida que possa gerar

incoerências durante o planeamento das tarefas dos veículos. Deste modo podemos

identificar as seguintes fontes de erros:

Erros gerados durante a comunicação entre entidades, corresponde a qualquer

erro que impeça a comunicação do Centro de Controlo com outras entidades da

ferramenta;

Erros gerados durante a comunicação entre o background service e a aplicação

gráfica;


Duarte Fernandes

63

Erros gerados durante o processamento dos dados recolhidos, corresponde a

dados inválidos recebidos de outros elementos do sistema (por exemplo,

atualizações geográficas transmitidos pela unidade móvel).

A estratégia adotada no tratamento dos erros das várias fontes baseia-se essencialmente

na notificação dos erros ao utilizador. Como é possível verificar nos vários fluxogramas

utilizados para descrever o comportamento dos subsistemas do background service,

quando ocorre alguma falha é reportado o erro, isto significa que estes são gravados

num ficheiro que armazena a informação do erro: o instante em que ocorreu, a origem e

ainda uma pequena descrição.

Quando o utilizador inicia a aplicação é notificado dos erros ocorridos após o último

acesso à aplicação Centro de Controlo. Todos os erros podem ser consultados por data

no interior da aplicação gráfica, a ocorrência de erros é notificado como já referido

através da utilização da classe MessageBox, os objetos desta classe permitem imitar

sons e apresentar uma caixa de diálogo com detalhes dos erros.

Para erros que limitem a execução do Centro de Controlo (como é o caso de

inicialização do serviço, erros gerados durante a comunicação GSM ou durante o acesso

à base de dados), além da notificação ao utilizador é-lhe exposta a possibilidade de

executar uma nova tentativa, isto é, de repetir o passo que não foi concluído devido ao

erro ocorrido. Por exemplo, nas situações que o background service não se encontra em

execução a aplicação notifica o utilizador e fornece-lhe a interface necessária para

iniciar a execução da aplicação executada em background.

No que diz respeito a alertas estes podem ser dos seguintes tipos:

Alerta de furto do veículo;

Serviço não realizado antes do tempo definido;

Notificação de atualizações da localização por veículo;

Alerta de comunicação interrompida com uma determinada Unidade Móvel;

Os alertas de furtos acontecem por indicação do condutor, quando detetado um furto do

veículo ou produtos é informada toda a organização utilizando a tecnologia web service

para alterar o campo ‘alertas’ da linha que corresponde ao veículo furtado. A aplicação

gráfica notifica o utilizador quando deteta alterações na tabela veículos.


Duarte Fernandes

64

As atualizações são obtidas e processadas pelo subsistema “Aquisição de dados” do

background service, quando tal ocorre o elemento service avisa a aplicação gráfica

através do meio de comunicação adotado, por fim a aplicação notifica o utilizador via

messagebox deste acontecimento.

A comunicação interrompida com os veículos é detetada através da comparação do

número de feedbacks recebidos por estes (atualizações periódicas), sempre que é

alterado o tempo de amostragem é transmitida essa informação a todos os veículos que

estão a ser “monitorizados”, assim é reiniciada a contagem dos feedbacks, o mesmo se

sucede quando um novo veículo é referenciado para ser monitorizado. Deste modo

quando existir uma diferença assinalável entre feedbacks a aplicação gráfica notifica o

utilizador que não estão a ser obtidas respostas da respetiva Unidade Móvel. Além disso

o utilizador poderá a partir deste momento testar a unidade individualmente enviando

uma mensagem de texto e analisando o estado da mensagem de texto, isto é, se foi

enviada e recebida pela unidade, ficando à espera de uma resposta. Caso tal não se

suceda é indicada a situação a toda a organização através da introdução de uma linha em

branco na tabela “Servicos”, isto indicará que a tarefa do condutor não foi seguida na

totalidade.

e) Subsistema de Acesso e Armazenamento de Dados

Este subsistema tem a tarefa de aceder de forma remota à base de dados, quer

seja para executar operações de escrita ou de leitura na base de dados. Esta encontra-se

alocada num servidor contratado, contudo não permite o acesso remoto. De forma a

alterar esta situação, é efetuado os seguintes passos:

Aceder ao cPanel;

Entrar em MySQLRemoto;

Adicionar host de acesso, colocando o símbolo “%” no campo Host.

O símbolo adicionado (%) indica que o root chamado ‘intelfle_root’ pode aceder de

qualquer host à base de dados. Após estes passos teremos ativado o acesso remoto ao

MySQL do servidor como demonstra a Figura 40.


Duarte Fernandes

65

Figura 40 - Hosts com acesso permitido à base de dados.

As operações de escrita e leitura são realizadas utilizando a linguagem SQL, esta é uma

linguagem de consulta de base de dados que implementa os conceitos definidos no

modelo relacional.

4.3.3 Aplicação Gráfica

Esta aplicação fornece ao utilizador uma interface gráfica para o cumprimento

das suas tarefas, tais como:

Gestão dos recursos físicos da organização (veículos, condutores, utilizadores e

clientes);

Manipulação do tempo de amostragem;

Controlo os instantes que os veículos devem ser colocados em modo periódico;

Assegurar a comunicação com as unidades móveis;

Bloqueio do veículo;

De modo a garantir tudo isto, é necessário a leitura e escrita na base de dados remota,

isto permite a visualização, introdução ou edição dos elementos veículos, condutores

entre outros que correspondem a entidades na base de dados. A comunicação com o

background service é garantida com o objetivo do utilizador transmitir ordens à unidade

móvel, tais como:

Alteração do tempo entre atualizações;

Habilitar ou desabilitar atualizações periódicas;


4.4 Posto de Trabalho

Esta aplicação consiste numa ferramenta Web designada de Posto de Trabalho,

fornece uma solução para a gestão, localização e otimização de frotas via Web.

Na Figura 41 é apresentada uma visão geral desta aplicação, que se encontra

constantemente em contato com a base de dados responsável por armazenar os dados


Duarte Fernandes

66

provenientes do veículo num servidor. Esta aplicação tem a tarefa de presentear ao

coordenador os recursos necessários para a gestão da frota através de qualquer

computador ligado à internet.

Figura 41 - Visão Global da aplicação Posto de Trabalho.

Assim sendo, para o desenvolvimento da ferramenta IntelFleet e mais concretamente a

interface Posto de Trabalho é necessária a utilização de um servidor externo, que

permita armazenar informação numa base de dados e ainda que permita hospedar os

ficheiros que constituem o site.

O servidor utilizado para o efeito é nos fornecidos pela Webtuga, Lda, que fornece

serviços online de máxima qualidade a custos reduzidos. Dispõem de uma variedade de

serviços de alojamentos de sites, registo de domínios, revenda de alojamento, servidores

privados e servidores dedicados, marketing online entre outros.

Após tomadas as decisões na fase de planeamento de quais as tecnologias e recursos a

utilizar apresentadas anteriormente, foi colocado em prática o conhecimento resultante

do estudo dessas tecnologias dando origem à etapa de implementação.


Duarte Fernandes

67

4.4.1 Página Web

A presente aplicação comunica frequentemente com o servidor IntelFleet,

existindo inúmeras trocas de informação entre ambos pois é seguida uma arquitetura

Cliente-Servidor. Dois métodos foram adotados como meio de comunicação com o

servidor, são eles:

Através de métodos HTTP;

Por meio de requisições assíncronas ao servidor.

Os ficheiros que compõem o domínio são alocados no servidor web, dentro destes

podemos identificar os ficheiros de acordo com as seguintes programações:

programação da página web (HTML e PHP), do lado do cliente (JavaScript, realiza

pedidos ao servidor e manipula a página diretamente após receção) e por fim o lado do

servidor (PHP utilizado como linguagem de script do lado do servidor, permite receber

os pedidos realizados pelos clientes e efetuar o processamento do mesmo). A tabela

seguinte apresenta os diferentes ficheiros implementados que compõem toda a lógica e

funcionalidades implementadas na aplicação Posto de Trabalho.


Duarte Fernandes

68

Tabela 12 - Associação de ficheiros por funcionalidade, desde seu aspeto (HTML) até ao ficheiro (JavaScript)

responsável por efetuar as requisições ao servidor e por fim o arquivo que processa estes pedidos.

Ficheiro

HTML

JavaScript

invocada

pela página

Ficheiro PHP para o

processamento das

requisições

Descrição da

funcionalidade da

página Index.html --- Login.php Login da aplicação

Index2.html --- --- “Menu” da aplicação

Inf_extra.php Veiculos_extra.js

Veiculo.php Veiculocomplete.php

Cliente.php Clientescomplete.php

Visualização de um conjunto de

informações relevantes no planeamento das

tarefas

Mapas.php veiculoscript.js Veiculo.php

Veiculocomplete.php

Visualização da localização dos veículos

sobre um mapa

Querys.php javascript.js



Conductor.php Condutorescomplete.php

Pesquisas de todos os recursos físicos e

humanos registados na base de dados, as

pesquisa spodem ser realiadas segunda

chaves de pesquisa, por exemplo consultar apenas tarefas que ainda não foram

terminadas

Rotas.php rotascript.js



Visualização do trajeto percorrido por um veículo durante a execuºão de uma

tarefa, e detetar erros na mesma.

Servicos.php serv_script.js

New_service.php Veiculo.php

Veiculocomplete.php Cliente.php

Clientescomplete.php Conductor.php

Condutorescomplete.php

Criação de novas tarefas

ClientesView.php --- --- Detalhes do conductor

selecionado

VeiculoView.php --- --- Detalhes do veículo

selecionado

Requisições Assíncronas ao Servidor

A utilização de uma programação tradicional através dos métodos HTTP torna-

se menos amigável, mais lenta e menos aconselhável para as interações com o utilizador

coordenador, pois é retornada uma página a cada solicitação realizada ao servidor. Com

o Ajax obtemos uma interface dinâmica, isto se deve às interações serem realizadas em

segundo plano, assim o utilizador poderá continuar na página. As requisições são

iniciadas no código JavaScript e quando finalizadas, atualiza a página a partir do

código-fonte HTML.


Duarte Fernandes

69

As funcionalidades presentes na Figura 22 recorrem à tecnologia AJAX como modo de

obter dados relevantes à realização das tarefas do coordenador. A funcionalidade

“Consulta restrita da B.D” facultada pelo Posto de Trabalho permite ao utilizador

pesquisar várias informações relativas aos recursos da organização e ainda informações

das frotas (posição atual e rota percorrida ou a percorrer). A partir da interface

apresentada na Figura 42, o utilizador pode realizar diferentes tipos de pesquisa,

necessitando apenas de indicar quais os dados que pretende consultar, podendo ser do

seguinte tipo: informação dos veículos da organização, dados relativos aos clientes

registados ou dos funcionários da empresa e por fim serviços ou que se encontram em

fase de execução ou concluídos.

Figura 42 - Pesquisa de dados armazenados no servidor.

A consulta de informação dos veículos será aqui utilizada como exemplo de

demonstração da interação dinâmica com o servidor. Para tal, é analisada a

implementação do cenário de pesquisa dos veículos.

Toda a informação que resulta da pesquisa é proveniente da base de dados, para obtê-la

é necessário percorrer várias camadas de software até a fonte de informação.

A Figura 43 ilustra as interações implementadas entre as camadas durante as requisições

assíncronas ao utilizador.


Duarte Fernandes

70

Figura 43 - Interação entre as diferentes camadas durante a requisição assíncrona.

O fluxo resultante das interações entre as camadas pode ser descrito pelas etapas

seguintes:

1. O utilizador gera um evento ao clicar no botão ‘OK’, indicando a sua intenção

de realizar uma pesquisa, isto resulta numa chamada do JavaScript a uma função

que inicializa um objeto XMLHttpRequest;

2. O objeto é configurado com dois parâmetros: ACTION (utilizado para indicar ao

servidor qual a tarefa que deve realizar) e ID (indica qual o componente que

acionou o evento);

3. O objeto XMLHttpRequest faz uma solicitação assíncrona ao servidor;

4. Do lado do servidor, um objeto listener tem a tarefa de manipular as requisições

dos clientes. Os dados requisitados são obtidos da base de dados e utilizados na

criação de um documento XML utilizado como resposta à requisição;

5. Por fim o objeto XMLHttpRequest recebe o documento XML utilizando uma

função callback, processa o documento e atualiza o HTML DOM para apresentar

os dados da pesquisa.

A Figura 43 apresenta um exemplo de um possível documento XML retornado como

resposta à requisição realizada pelo lado do cliente.

<veiculos>

<veiculo>

</veiculo>

…

</veiculos>

<?php

?>

XMLHttpRequest

Página Web

querys.php

<script type=”texto/javascript”>

</script> Ficheiro javascript.js

function callback(){

//Atualizar HTML DOM }

Atualiza área

especifica da página

Evento

onclick

2

5

Ficheiro

veiculocomplete.js

Listener

Base de dados

1

Cliente Servidor

3

4


Duarte Fernandes

71

Figura 44 - Exemplo do ficheiro XML enviado como resposta pelo servidor.

Estes dados são processados, extraídos e tornados disponíveis ao utilizador após a

atualização do DOM HTML da página web.

A implementação dos diferentes passos enumerados que compõem todo o processo de

requisição assíncrona bem como a utilização da tecnologia Ajax encontra-se detalhada

no anexo A.6.1 (Requisições Assíncronas).

4.4.2 Inclusão dos Mapas da Google

Numa aplicação que recorre a API do Google Maps o elemento fundamental é o

objeto Map (mapa), pois é a partir deste que todas as restantes operações sobre o mapa

descritas no presente subcapítulo se realizam.

Para que a API funcione no domínio da ferramenta torna-se necessário realizar os

passos seguintes [41] (sua implementação e estudo dos objetos utilizados estão

disponíveis para consulta no anexo A.6.2):

1. Carregar API do Google Maps;

2. Mapear elementos DOM;

3. Instanciar objeto Map;

4. Configurar o mapa;

5. Carregar o mapa.


Duarte Fernandes

72

Mapas Interativos

A interface disponibilizada pela página web da ferramenta recorre com

frequência a mapas, com o objetivo de apresentar informações relevantes ao utilizador

coordenador. Das funcionalidades presentes na Figura 22, ainda não estudadas podemos

identificar o seguinte conjunto como funcionalidades que recorrem a mapas para

cumprimento dos seus objetivos:

Visualização da posição geográfica do veículo (a);

Verificar trajetórias percorridas durante a execução de um serviço/tarefa (b);

Validar rota percorrida durante a execução das tarefas (c);

Planeamento de novas tarefas (d).

A informação da frota necessária para gerar o mapa é proveniente da base de dados,

para obtê-la é necessário percorrer várias camadas de software até consultar a base de

dados como descrito na Figura 43 e já demonstrada sua implementação no exemplo da

pesquisa de veículos (requisição assíncrona).

a) Visualização da Posição Geográfica do Veiculo

A página ‘www.intelfleet.com/mapas. php’ disponibiliza esta funcionalidade ao

utilizador e possui o aspeto apresentado na Figura 45, onde podemos facilmente

identificar o mapa e o formulário utilizado para pesquisa, possibilitando a pesquisa com

uma das três diferentes palavras-chave:

“Estado Ocupado”, pesquisa de veículos que se encontram a realizar uma tarefa;

“Estado Livre ”, veículos que se encontram livre;

“Todos os veículos ”, apresenta todos os veículos independentemente do seu

estado.

As informações dos veículos (matrículas) são apresentadas quando o utilizador acede à

página web desenvolvida para o efeito. Durante o carregamento da página são

realizados os seguintes passos:

Configuração do mapa definido na página HTML;

Tornar os elementos DOM da página acessíveis;

Inicialização e configuração do objeto XMLHttpRequest;

Realização da solicitação assíncrona ao servidor.

http://www.intelfleet.com/mapas.%20php


Duarte Fernandes

73

Figura 45 - Aspeto encontrado pelo utilizador quando pretende conhecer a posição geográfica dos veículos

sobre um mapa.

A interação assíncrona realizada durante o carregamento da página é em tudo idêntica

ao caso analisado anteriormente (exemplo de requisição assíncrona descrito em 4.4.1),

inclusive a URL e parâmetros que configuram a solicitação. Isto significa que do lado

do servidor, o listener que irá processar o pedido é o mesmo que o já analisado pois as

informações pretendidas coincidem. Consequentemente o ficheiro XML transmitido

como resposta, possui o mesmo formato que o apresentado como exemplo na Figura 44.

Após carregada a página, esta encontra-se atualizada com as informações dos veículos

presentes na tabela HTML da referida página.

Para cada uma das matrículas carregadas na página é criado um link, quando clicado

desencadeia o seguinte fluxo de informação (Figura 46), os passos nele realizados visam

apresentar sobre um mapa a posição atual do veiculo (exemplo descrito na Figura 47).


Duarte Fernandes

74

Figura 46 - Processo de inserção da localização do veículo no mapa.

O marcador visível na Figura 47 é interativo e permite escutar eventos. Definindo o

evento ‘click’ para este tipo de marcador permite à página exibir janelas de informação

utilizadas para apresentar informação do veículo.

Figura 47 - Marcadores interativos.


Duarte Fernandes

75

Os atributos armazenados que indicam a localização do veículo são: latitude e

longitude. Contudo na Figura 47 é apresentado além das informações recebidas como

argumentos (do método indicado no link) o endereço correspondente. Para obter a

localização geográfica através das coordenadas geográficas obtidas da base de dados é

efetuada a geocodificação inversa. A API do Google Maps fornece recursos para a

realização deste passo, mais em concreto o objeto Geocoder.

A utilização deste objeto, a análise dos parâmetros utilizados e processamento dos

resultados obtidos durante o processo de geocodificação encontrasse disponível para

consulta no anexo A.7.1.

b) Visualizar Trajetórias de um Dado Serviço/Tarefa

Existem duas situações em que é necessário traçar rotas no mapa a partir das

funcionalidades fornecidas pela API do Google Maps, são elas:

Pesquisa de serviços por realizar;

Pesquisa de serviços já finalizados;

Para ambos os casos o princípio de funcionamento e implementação é idêntico, assim

sendo foi adotado o ultimo caso (serviços finalizados) como exemplo a analisar.

Pesquisa de Serviços Finalizados

A pesquisa de tarefas dadas como terminadas, desencadeia duas requisições ao

servidor, ambas se baseiam na metodologia adotada em secção 4.4.1 (Requisições

Assíncronas ao Servidor). Do lado do servidor é apenas coletada e transmitida ao

cliente-sider as tarefas presentes na tabela “Servicos” que já foram terminados (campo

‘realizado’ com o valor ‘1’), por fim é processada a resposta e atualizado o DOM HTML

(exemplo Figura 48).

Figura 48 - Página 'querys.php' após a primeira requisição ao servidor.

A segunda requisição ocorre quando o utilizador clica num dos serviços presentes na

tabela HTML, realizando nesse instante uma chamada à função ‘XML_matricula()’


Duarte Fernandes

76

(através do link criado para cada uma das linhas), iniciando desta forma a requisição

assíncrona ao servidor.

A Figura 49 apresenta o fluxo de informação antes, durante e após a requisição

(apresentação da rota do serviço num mapa ao utilizador).

Figura 49 - Fluxo de informação gerado durante a pesquisa de tarefas já realizadas.

A resposta do servidor à solicitação tem o formato do exemplo ilustrado na Figura 50,

este possui a informação geral do serviço e o conjunto de pontos geográficos recolhidos

durante a execução da tarefa. Após o processamento da resposta os dados extraídos são

utilizados para traçar uma rota que espelhe o trajeto realizado durante a execução do

serviço/tarefa pelo veículo (processo descrito no anexo A.7.2).

A utilização do objeto da DirectionsRequest da API do Google Maps na geração da rota

e a criação dos Wayppoints é descrita no anexo A.7.3.

<composers>

<composer>

</composer>

…

</composers>

<?php

?>

Página Web querys.php

<script type=”texto/javascript”>

</script>

Ficheiro javascript.js

function callback()

{}

Evento onclick

2

5

Ficheiro

rotacomplete.js

Listener

Base de dados

1

Cliente Servidor

3

4

function XML_matricula

{

}

XMLHttpRequest

function

MAP_ROUT()

Aualiza

Mapa e

DOM HTML

rotascript.js querys.php

6


Duarte Fernandes

77

Figura 50 - Exemplo da resposta do servidor ao pedido de informações dos pontos geográficas percorridos

durante a execução de um dado serviço.

c) Validar rotas percorridas durante a execução das tarefas

O utilizador ao selecionar um veículo em execução (página web,

http://www.intelfleet.com/Rotas.php) irá gerar um evento que atualiza o mapa, com a

rota que o veículo deverá percorrer, é ainda colocado um marcador na última posição

conhecida do veículo sobre o mapa. O marcador criado serve de centro para um círculo

criado e apresentado no mapa com um raio de um km. Ao mapa são adicionados dois

controlos, são eles:

Localização, centra o mapa na posição atual do veículo;

Rota, centra o mapa na trajetória delineada e desencadeia o processo de

validação da trajetória.

A estratégia de validação de uma trajetória é ilustrada sobre a forma de fluxograma na

Figura 51. No primeiro passo é traçada a rota que correspondente à definida pelo

utilizador coordenador, durante este processo é retirado os vários steps que resultam da

utilização no objeto DiretionsRequest.

Dados gerais

do

serviço

realizado

Ponto

geográfico

com ID=1

Ponto

geográfico

com ID=2

Restantes

pontos

geográficos

http://www.intelfleet.com/Rotas.php


Duarte Fernandes

78

Um step corresponde a um ponto de decisão num trajeto, isto é, locais onde existe uma

possibilidade de alterar o seu caminho (rotundas, entroncamentos, pontos de viragem),

este possui além das coordenadas geográficas do ponto a distância deste até o step

seguinte. Estes dados são vitais para o sucesso da estratégia implementada.

Figura 51 - Algoritmo implementado para a deteção de trajetos indesejados.

Estas informações são utilizadas para calcular a distancia desde o step até a posição

atual do veículo. Caso exista algum step a uma distância inferior a um quilómetro do

veículo significa que este passou recentemente por esta posição e que está

potencialmente a seguir a trajetória delineada. Em caso negativo, o passo seguinte visa

obter informação (pontos geográficos obtidos durante a realização até então da respetiva

tarefa) que permita averiguar se o veículo seguiu outras direções ou se encontra entre

steps distantes um do outro.

Após isto são calculadas as distâncias entre os pontos e os vários steps, poderá existir

mais que uma distância inferior a um quilómetro, caso tal se verifique é selecionado o

step que se encontra a uma distância pequena (<1 km) do ponto geográfico, que

corresponde à atualização da localização mais recente.


Duarte Fernandes

79

Com este step podemos calcular a distância relativa à posição atual do veículo e

comparará-la com a distância relativa do step selecionado com o seguinte da rota

delineada. Caso se verifique que a distância entre os steps é superior à primeira

calculada, garantimos que o veículo se encontra na rota mas entre steps distantes, caso

contrário seguiu um novo trajeto que não o sugerido pelo coordenador.

A utilização dos recursos da API do Google Maps para a implementação desta estratégia

é analisada e encontra-se disponível para consulta no anexo A.6.2.

c) Planeamento de Novos Serviços

A página “http://www.intelfleet.com/servicos.php”, oferece a interface e a

informação necessária ao utilizador para planeamento das tarefas. As seguintes

informações compõem a tarefa e parte destas são preenchidas manualmente pelo

coordenador durante a criação do mesmo:

Data limite, indica o prazo limite para a realização da tarefa;

Cliente, especifica o utilizador que requisitou a tarefa;

Condutor, indica qual o funcionário que ficara responsável pela execução da

tarefa;

Kms, dá a conhecer uma estimativa da distância a percorrer;

Evitar autoestradas;

Evitar estradas principais,

O número de quilómetros não é definido pelo utilizador, é preenchido automaticamente

após determinado o ponto de destino da tarefa. O valor da distância em quilómetros é

obtido através dos recursos da API do Google Maps que permitem o cálculo de

distâncias entre dois pontos.

De modo a que não seja introduzido valores inválidos no campo ‘Data prevista para

realização da tarefa’, todos dados inseridos são sujeitos a um processo de validação.

Quando este campo sofre alterações, é gerado um evento que valida apenas dados

inseridos que correspondem a datas e nunca inferiores à data atual. Os campos ‘Evitar

auto-estradas’ e ‘Evitar estradas principais’ permitem ao planear a rota consoante as

variáveis que influenciam a execução da tarefa (como evitar zonas com maior trânsito,

reduzir distâncias, gastos em combustíveis ou gastos em portagens entre outros).

http://www.intelfleet.com/servicos.php


Duarte Fernandes

80

O utilizador necessita de se basear em informação relevante e atualizada durante a

geração das tarefas, pensado nessa situação é-lhe disponibilizado um conjunto de dados

relevantes que poderão influenciar o planeamento da tarefa. A página HTML ilustrada

na Figura 52 apresenta por veículo, o tempo estimado para realização da tarefa levando

em conta a distância desde a sua posição atual até ao destino indicado e ainda informa

sobre a disponibilidade atual dos condutores. Ao selecionar um dos veículos é

apresentado num mapa o trajeto consoante as variáveis introduzidas que definem um

serviço, diferentes rotas podem ser geradas, isto permite escolher qual a rota ideal (por

menor distância percorrida ou menos custos gerados devidos a portagens por exemplo).

Figura 52 - Informação relevante para o planeamento de novos serviços.


Duarte Fernandes

81

4.5 Terminal do Condutor

A aplicação é destinada a qualquer dispositivo móvel com pelo menos a versão

2.2 (Froyo) do sistema operativo Android instalado. A utilização da aplicação deve ser

intuitiva e com uma interface amigável, deverá oferecer ao utilizador o feedback em

ações importantes, além destes requisitos a aplicação deverá na ocorrência de erro

notificar o utilizador a partir de uma mensagem de erro simples de compreender.

4.5.1 Visão Global da Aplicação

A presente aplicação descrita através do diagrama de blocos da Figura 53 é uma

solução móvel baseada nos recursos (módulos) do sistema operativo móvel escolhido no

desenrolar do projeto.

Trata-se de uma aplicação que permite uma comunicação bidirecional via GSM do

condutor com o gestor e ainda uma interação com o coordenador via Web service. Ao

nível da gestão de tarefas, permite visualizar detalhes das tarefas, tais como: distância a

percorrer, o melhor percurso, visualizar em qualquer instante a posição do

veículo/condutor, receber e enviar alertas/mensagens de texto.

Figura 53 - Overview da aplicação Terminal do Condutor.

A descrição gráfica anterior, identifica os vários elementos Android utilizados na

implementação do Terminal do Condutor, são eles:

Activity, fornecem a interface gráfica ao utilizador para este executar suas

tarefas;

Broadcast Receiver, classe utilizada para filtrar o conteúdo de mensagens de

texto recebidas;

Broadcast Receiver

Cliente

Aplicação Android Servidor IntelFleet

Atividades

Background Service

Scanner

SGBD

Base de

dados

Suporte

às requisições

do cliente

Servidor


Duarte Fernandes

82

Service, executado em backrground têm objetivo de detetar novas tarefas

planeadas pelos coordenadores.

Scanner, permite a leitura de QRcodes.

4.5.2 Atividades

Cada atividade é representada por uma tela na aplicação, possui interface ao

utilizador composta por Views, componentes gráficos entre outros. Assim na presente

seção é descrita as várias atividades que correspondem do ponto de vista do condutor à

interface que faculta as funcionalidades necessárias à execução das suas tarefas. Todas

as atividades descritas na Tabela 13 estendem obrigatoriamente a classe

android.app.Activit [42].

Na implementação de qualquer atividade no sistema operativo Android, existe um passo

obrigatório que se repete para cada umas das atividades listadas na tabela anterior, este

passo visa declarar uma atividade como sendo parte da aplicação.

Assim sendo, a aplicação Terminal do Condutor é descrita no arquivo

AndroidManifest.xml, neste é declarado todas as Activitys, Services,

BroadcastReceivers e ContentProvider5 da aplicação [42]. Deve ainda conter todas as

permissões para a aplicação, por exemplo, se a aplicação requer acesso à rede, então

deve ser especificado no arquivo. A implementação deste passo encontra-se detalhada

no anexo A.8.1.

Os principais recursos utilizados nas atividades que implementam as funcionalidades

necessárias pelos condutores para cumprimento das suas tarefas são:

API Google Maps, permite ao condutor visualizar informações num mapa como

localização do veículo entre outros;

SMS messaging, recurso utilizado para o envio e receção de mensagens de texto;

Web services, tecnologia utilizada como meio de obter informações armazenadas

na base de dados do servidor.

No anexo A.8, encontra-se descrita a implementação das principais funcionalidades da

aplicação ilustradas no diagrama use-case da Figura 21.

5 Componente Android, permite armazenar e recuperar dados, disponibilizando-os a outras aplicações.


Duarte Fernandes

83

Tabela 13 - Conjunto de Atividades que compõem a aplicação Terminal do Condutor.

Atividade Funcionalidade

do use-case

Recursos

Android Descrição

IntelFleetActivity Login Web service,

grupo de View

Classe que fornece interface gráfica

no processo de login

IntelFleet_Menu

Seleção da

funcionalidade a

executar

Grupo View

Tela para seleção (direcionando o

utilizador) das diferentes

atividades/tarefas

IntelFleet_gps

Visualização da

posição do veículo

num mapa

Grupo View e API

do Google Maps

Apresentação da posição do veículo

num mapa

IntelFleet_location Comunicação com

a unidade móvel

API Google Maps,

Grupo View e

SMS messaging

Envio de comandos à unidade móvel

requisitando atualização da

localização, processamento da

resposta

IntelFleet_tasks Notificação de

tarefas

Web services,

Grupo View e

background

service

Tela apresentada como notificação ao

utilizador de uma nova tarefa

IntelFleet_Scores

Consulta do

histórico de

serviços

Grupo View e Web

Services

Tela composta por 2 tabs, uma

apresenta informações relevantes do

user e a outra o histórico de serviços

por ele realizado

IntelFleet_stop Bloqueio do

veículo

SMS messaging e

Grupo View

Interface para realização do pedido

de bloqueio do veículo

IntelFleet_vehicles Registo de veículos Intent Integrator,

Web services

Permite registar/associar veículo ao

utilizador/condutor através de um

Barcode scanner

IntelFleet_warn Alertas Grupo View e

Web Services

Notifica o utilizador que o prazo para

terminar a tarefa está prestes a

expirar/expirou

IntelFleet_gps_warn Alertas

Grupo View ,

Google Maps e

Web Services

Apresenta dados complementares aos

dados apresentados na atividade

anterior num mapa

4.5.3 Broadcast Receiver (Filtragem de Mensagens de Texto)

Um Broadcast Receiver é um componente Android que permite registar eventos

para todo um sistema ou aplicação [42]. Assim todas as aplicações registadas como

receivers de um dado evento, são notificados quando este ocorrer. A partir da sua

definição é possível identificar a sua utilização no âmbito do projeto. Este componente

permite filtrar as mensagens de texto recebidas pelo smartphone, de modo a identificar

as que se destinam à aplicação Terminal Condutor, sendo bastante útil quando se

pretende uma certa performance da aplicação para um determinado conteúdo da

mensagem recebida. Por exemplo, quando recebida uma atualização “on-demand”

proveniente da Unidade Móvel pretende-se que estes dados sejam apresentados ao

utilizador após a geocodificação, este é o exemplo adotado para explicação do


Duarte Fernandes

84

funcionamento do sistema durante o processo de aquisição das mensagens de texto

(Figura 54).

Figura 54 - Processo iniciado após receção de mensagem de texto.

Para filtrar as mensagens recebidas, foi então criada uma instância da classe Broadcast

Receiver. Este objeto habilita a aplicação Terminal do Condutor a receber Intents

provenientes de outras aplicações, ou seja, habilita a aplicação de manusear eventos

gerados por outras aplicações. Como ilustrado na Figura 54, quando uma nova

mensagem é recebida no smartphone um Intent é criado e gerado um evento na

aplicação desenvolvida listada como Receiver, o que invocará o método onReceive(). A

mensagem de texto encontrar-se-á contida no objeto Intent (segundo parâmetro do

método onReceive) criado após receção da SMS. A mensagem é extraída e analisado o

seu conteúdo, no caso da receção das atualizações “on-demand” consiste numa

mensagem com o formato apresentado em 4.6.2 (Formato da resposta às solicitações), à

qual é extraída as variáveis (coordenadas geográfica) de interesse, e realizada a

geocodificação e apresentado a localização do veículo. A atualização “on-demand” é

utilizada como exemplo na utilização do módulo BroadcastReceiver para o processo de

aquisição e leitura de mensagens de texto.

4.5.4 Serviço Executado em Background

Um serviço é executado em background numa aplicação Android sem qualquer

interação do utilizador [42]. No contexto do projeto deseja-se que a aplicação Terminal

do Condutor esteja “atenta” a novas tarefas criadas pelos coordenadores durante a

interação com o Posto de Trabalho para o efeito analisada em 4.4.1 (Planeamento de

Novos Serviços). Quando uma nova tarefa é atribuída ao condutor, é esperado que a

aplicação Android notifique o utilizador condutor, para tal foi desenvolvido um

Start

Nova

SMS Envia

Intent

IntelFleet_location Processar

dados

Ativa

notificação

SMS

Broadcast

Receiver

Processar

dados

OnReceive()


Duarte Fernandes

85

background service (componente Android service) que executará a tarefa de detetar

novas tarefas do condutor em questão. O algoritmo que traduz a implementação e

comportamento do serviço encontra-se ilustrado na seguinte figura.

Figura 55 - Módulo Serviço executado em background na aplicação Android (detetar novas tarefas definidas

pelos coordenadores no Posto de Trabalho).

O serviço executa repetidamente o fluxo de informação apresentado no fluxograma, este

repete-se a uma frequência definida aquando a configuração do serviço. Este estabelece

uma comunicação com o servidor e verifica a existência de novas tarefas associadas ao

utilizador, em caso afirmativo, notifica o utilizador apresentando um conjunto de

informações relativas à tarefa (em forma de texto ou num mapa como a rota a percorrer

entre outros) na tela da atividade IntelFleet_tasks, independentemente da atividade que

esta a ser executada (passará para modo de espera) ou da aplicação a ser executada. Por

exemplo, se o utilizador tiver a utilizar a câmara fotográfica do smartphone esta


Duarte Fernandes

86

aplicação será suspensa e na tela aparece o layout da atividade IntelFleet_tasks

garantindo que este é sempre informado de novas tarefas.

Alertas

O Terminal do Condutor alerta/notifica o utilizador (condutor) além das novas

tarefas, do prazo para realização da tarefa delineado pelo coordenador quando prestes a

terminar ou já expirado. Notifica ainda quando é desrespeitada a rota traçada (definida

pelo coordenador) durante a execução da tarefa, de forma a que este continue a seguir o

melhor caminho é-lhe apresentada uma nova rota que leve em conta os parâmetros

definidos aquando a criação da tarefa pelo coordenador.

A Figura 56 apresenta o ecrã de notificação quando o prazo para realização da tarefa se

aproxima do fim. Esta notificação é realizada a 24 horas do prazo limite e no respetivo

dia ocorre de duas em duas horas, a menos que o utilizador indique que não deseja

voltar a ser alertado até ao final do prazo.

Figura 56 - Notificação ao utilizador de prazo de execução da tarefa a expirar, IntelFleet_warn e

IntelFleet_gps_warn respetivamente.

4.5.5 QRcode Scanner

Como se pode verificar no diagrama entidade-relação (Figura 25), cada condutor

deverá ter zero ou um veículo associado. Numa empresa possuidora de frotas um

condutor pode ter acesso a mais que um veículo, podendo alternar entre veículos a

execução de tarefas. De forma a garantir que a organização tem sempre conhecimento


Duarte Fernandes

87

de quais os veículos que estão a ser utilizador por cada condutor em tempo real, foi

implementado um sistema de registo de veículos.

Seu princípio é bastante simples, “instalando” QRcode no interior dos veículos que

podem ser convertidos em texto quando lidos pelo scâner da aplicação Terminal do

Condutor. Desta forma é identificado qual o veículo e registada a mudança na base de

dados da organização (através do campo ‘veiculo_matricula’ da tabela “Driver”),

tornando esta informação disponível às restantes aplicações e utilizadores. Este processo

encontra-se descrito no fluxograma da Figura 57.

Figura 57 - Processo de registo de veículos.

Através de um objeto Intent é possível integrar a aplicação Barcode Scanner na

aplicação Terminal do Condutor. Esta é uma forma simples de invocar o barcode e

efetuar o “scanner”, recebendo apenas o resultado final no Terminal do Condutor como

demonstra o exemplo apresentado na Figura 58.

Esta integração consiste essencialmente em invocar o método initiateScan(Activity) e

esperar pelo resultado. Isto requer a instalação da aplicação Barcode Scanner no

smartphone.


Duarte Fernandes

88

Figura 58 - Registo de veículos utilizando o Barcode Scanner.

4.6 Unidade Móvel

O presente subcapítulo procura dar a conhecer o dispositivo de hardware

denominado de Unidade Móvel, mais especificamente os componentes que o

constituem e seu comportamento no âmbito do projeto.

A Figura 59 apresenta um diagrama de blocos que permite identificar os vários

elementos que compõem o dispositivo eletrónico e ainda os protocolos de comunicação

utilizados na interação entre os módulos.

Figura 59 - Visão global da Unidade Móvel sobre a forma de blocos.


Duarte Fernandes

89

4.6.1 Processos de Software

Nesta secção é dada a conhecer os diferentes processos de software executados

no decorrer da execução do dispositivo Unidade Móvel. Desde o processo de

inicialização e configuração de hardware até ao procedimento do dispositivo durante a

execução das suas tarefas.

Processo de Start-Up

O processo de Start-up descreve como um sistema se inicia, isto é, quais os

procedimentos que devem ser realizados de forma a obter um arranque correto.

O fluxograma da Figura 60, descreve este processo que se inicia com a configuração da

comunicação série, posteriormente inicializa os componentes de hardware utilizados

(Receiver GPS e módulo GSM). Caso ocorra algum erro durante estas etapas iniciais o

sistema notifica o utilizador ao ativar o RGB com uma luz azul, indicando o erro no

processo de Start-up. Quando realizado com sucesso este primeiro passo significa que a

unidade central (microcontrolador) se encontra habilitada a comunicar com os módulos

de hardware, com as configurações apresentadas no anexo A.9.2. A partir deste instante

qualquer anomalia identificada durante o funcionamento do sistema será transmitida ao

utilizador Gestor e Condutor por meio de uma mensagem de erro para o Terminal do

Condutor sobre a forma de mensagem de texto (SMS).

Ainda no processo Start-up, o seguinte passo consiste em configurar os timers

necessários para implementação do tempo de amostragem/tempo de atualização, de

forma a permitir uma resposta às solicitações de forma periódica. As restantes etapas

consistem na configuração dos restantes pinos I/O necessários, apresentados no anexo

A.9.3 (por exemplo: bloqueio do veículo) e por fim o sistema procura conhecer se a sua

inicialização ocorre devido a falta de energia, este processo é analisado com maior

detalhe em 4.6.1 (Recuperação de Falhas).


Duarte Fernandes

90

Figura 60 - Processo de Start-up.

Inicialização do Receiver GPS

O módulo GPS escolhido para o projeto da unidade móvel possui entre as

características apresentadas em 3.4.2 (Módulo de Localização) o uso do protocolo

USART como meio de comunicação. Para utilizar este protocolo como meio de troca de

dados com o Receiver foram configurados os pinos e baudrate das portas USART,

seguindo os passos apresentados na Figura 61. Foram realizados alguns cálculos que

justificam o baudrate imposto na comunicação com o Receiver, descritos no anexo

A.9.1.

O firmware presente no receiver GPS inicia o envio contínuo à frequência de 1Hz (uma

vez por segundo) dos dados da localização. Estes dados seguem o padrão NMEA,

enviando as cinco frases (anexo A.1) em cada envio da localização. No âmbito do

sistema IntelFleet, apenas é relevante a informação enviada pela frase GPRMC descrita

com detalhe no A.1, assim na inicialização deste componente torna-se vantajoso

configurá-lo para apenas enviar a frase necessária, utilizando o comando PMTK 314

para o efeito:

PMTK314,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0*29<CR><LF>


Duarte Fernandes

91

Figura 61 - Procedimentos executados durante a inicialização do Receiver GPS.

Os campos iniciais constituintes do comando PMTK 314, correspondem às cinco frases

NMEA, ao atribuir-lhes o valor de zero estarão a ser desabilitadas. Desta forma o

receiver é configurado com todos os campos a zero exepto o campo correspondente à

frase pretendida, passando desde então a enviar apenas a frase selecionada a cada

posição fixa.

Uma vez que a informação output do receiver só é necessária quando os utilizadores

(Condutor e Gestor) a solicitarem e não de forma contínua, por uma questão de

eficiência e poupança de recursos, a comunicação entre a unidade de processamento e o

receiver GPS é ativado apenas quando necessário, ativando e desativando o periférico

USART1. Idealmente, para poupar energia o mais conveniente seria simplesmente

desligar o módulo GPS, contudo iria implicar um maior atraso na resposta aos

utilizadores, pois cada vez que é ligada a alimentação do componente receiver, este

requer algum tempo até se “enquadrar” com os satélites de GPS o que se traduz em

segundos ou mesmo minutos até obter a primeira frase GPRMC. Assim sendo, o recetor

continuará a enviar dados à frequência de 1 Hz, mas a unidade de processamento apenas

irá processar esses dados quando tal se justificar.

Este procedimento gera um inconveniente ilustrado na Figura 62, este ocorre devido à

impossibilidade de controlar em que “posição“ da frase obtida como output nos


Duarte Fernandes

92

encontraremos no instante em que é habilitada a comunicação. Dependendo do

momento em que esta é ativada, irá existir um atraso no máximo de um segundo até ser

recebida uma nova frase, válida quando recebida por completa.

Figura 62 - Diagrama temporal do processo de recolha de dados GPS.

Inicialização do Módulo GSM

O módulo selecionado para o projeto da unidade móvel suporta comandos AT,

cada um destes comandos desempenha uma função e pode ser precedida de parâmetros

que especificam a configuração pretendida. O fluxograma da Figura 63 demonstra o

processo de inicialização do componente em questão.

Figura 63 - Processo de inicialização do módulo GSM.


Duarte Fernandes

93

Os comandos utilizados no processo de inicialização neste componente encontram-se

descritos na seguinte tabela (Tabela 14), bem como os valores dos parâmetros utilizados

durante a configuração apresentado no fluxograma anterior.

Tabela 14 - Descrição dos comandos AT necessários durante a configuração do modem GSM.

Comando Parâmetros Descrição

AT --- Comando enviado para testar a

comunicação série,

AT+CMEE AT+CMEE=2 Ativa notificação de erros no formato

de texto

AT+CPBS AT+CPBS=”SM” Ativar armazenamento de SMS na

memória do catão

AT+CNMI AT+CNMI=2,1,0,2,1 Ativa receção de SMS

AT+CMGF AT+CMGF=1

0-Modo PDU

1-Modo de texto

AT+CMGD AT+CMGD=”número da SMS”

Permite eliminar as mensagens que

são identificadas por um número de 1

até 10, que é a capacidade de

armazenamento do cartão, 10 SMS

Processo “Verificação de Recuperação a Falhas”

Este processo (Figura 64) é executado durante o processo de Start-up da unidade

móvel, o seu objetivo no âmbito do projeto consiste em identificar se ocorreu alguma

falha na unidade móvel, que tenha obrigado a plataforma física a reiciar o seu

funciomento, como por exemplo uma falha de energia. O seu propósito consiste em

manter as comunicações com o Centro de Controlo, isto é, a comunicação em modo

periódico. Na Figura 67 podemos verificar que quando uma solicitação deste tipo é

recebida, os dados relevantes da mesma são armazenados na memória ROM. Assim

quando ocorrida uma falha e o sistema é iniciado e estas informações mantêm-se

intactas, o que significa que podem ser utilizadas para restabelecer a conexão. É dado

um tempo (2 minutos) para receção de mensagens que foram enviadas enquanto o

sistema se apagou, caso se verifique que foi recebida uma mensagem cancelar a

comunicação periódica, o sistema não voltará a restabelecer a comunicação e elimina os

dados da tarefa da memória.


Duarte Fernandes

94

Figura 64 - Algoritmo percorrido durante o processo de verificação de falhas no dispositivo.

Análise de Eventos

Os eventos no dispositivo são anunciados sobre a forma de interrupções, isto é,

quando ocorre uma interrupção num novo evento é gerada na unidade de

processamento. Os eventos que podemos encontrar são:

Nova mensagem de texto recebida;

Nova frase disponível;

Tempo de amostragem alcançado;

Sinais GPS processados.

No microcontrolador selecionado para o projeto, todas as suas interrupções efetuam call

da mesma função, a partir desta é identificada qual o evento que gerou uma interrupção

e executada a respetiva ISR (rotina de serviço a interrupção). Para detetar qual o evento

ocorrido foi implementado o algoritmo ilustrado na seguinte figura (Figura 65).


Duarte Fernandes

95

Figura 65 - Determinação do evento que gerou interrupção.

Após detetada a proveniência da interrupção através de flags que indicam o estado de

cada dispositivo, é invocada a função que irá processar a informação do evento. Na

Tabela 15 é apresentado por evento a função a ser executada, o componente de

hardware que gerou a interrupção e por fim a tarefa a executar após identificação do

evento ocorrido.

Tabela 15 - Funções de resposta ao evento.

Evento Função Tarefa Componente

Nova mensagem de texto

recebida Parse_GSM

Aquisição de dados

GSM Módem GSM

Nova frase disponível Parse_GPS Tratamento de dados

GPS Reciver GPS

Tempo de amostragem

alcançado Send_count

Atualização periódica

de dados Microcontrolador

Sinais GPS obtidos Fix_detect,

Verify_fix

Habilitação da

aquisição de dados

GPS

Receiver GPS

Aquisição de Dados GSM

Como referido anteriormente, novas mensagens de texto são anunciadas à

unidade de processamento pelo módulo GSM sobre a forma de interrupção gerada pelo

módulo GSM. A função Parse_GSM é a rotina de serviço à interrupção e a sua tarefa é

descodificar a mensagem de texto e de acordo com o comando presente no corpo do

SMS executará uma série de passos ilustrados na Figura 66. Os comandos utlizados na

comunicação com o veículo (listados na -Tabela 17) indicam as seguintes intensões do

utilizador:

Atualização dos dados de localização;


Duarte Fernandes

96


Desbloqueio do veículo.

Figura 66 - Interpretação de comandos.

A unidade de processamento compara o conteúdo da mensagem de texto com os

diferentes comandos reconhecidos pela Unidade Móvel, quando o conteúdo da

mensagem coincide com um dos formatos dos comandos a unidade irá proceder

consoante intenção do utilizador, identificado através do algoritmo anterior.

Atualização de Dados

A unidade móvel permite o envio das atualizações dos dados de localização em

dois modos:

Atualização periódica;

Atualização “on-demand”.

O primeiro modo é ativado pelo Gestor com objetivo de atualizar a informação do

veículo periodicamente, permitindo acompanhar a execução dos serviços. O modo “on-

demand” desenvolvido a pensar no Condutor, possibilitando requisitar informação da

localização no instante à unidade móvel e visualizar a posição do veículo em qualquer

instante num mapa. Na -Tabela 17 verifica-se que o formato do comando para os

diferentes modos de atualização de dados é o mesmo, desta forma é necessário antes de

responder à solicitação de informação verificar qual o modo de atualização solicitado,

como demonstra o algoritmo da Figura 67 implementado na função Timer_config.


Duarte Fernandes

97

Figura 67 - Identificação do modo de atualização de dados solicitado.

Quando uma nova mensagem de texto é recebida uma interrupção é gerada, a flag da

comunicação série (USART 1) permite à unidade de processamento identificar qual o

evento/interrupção ocorrido invocando a respetiva ISR (Parse_GSM). Esta função tem

como propósito verificar qual o comando transmitido pelo utilizador à unidade móvel. É

percorrido o algoritmo da Figura 65 até ser identificada a intenção do utilizador. No

presente caso de estudo o comando recebido irá possuir o seguinte formato: *txxxx+,

anunciando que o utilizador solicitou atualização da localização. Próximo passo é

preparar a resposta à solicitação invocando a função Timer_config responsável por essa

tarefa.

O algoritmo implementado nesta função inicia-se com a averiguação do tipo de

atualização, identificando-o através do parâmetro incluído no comando, quando este

possui um valor superior a zero significa que se trata do modo periódico. Nesta situação

a unidade de processamento procede com a inicialização das variáveis que armazenarão

valores como o número do dispositivo que requisitou o pedido de atualização e ainda o

tempo de amostragem necessário para o correto envio da resposta à solicitação.

O passo seguinte configura o timer (Timer 0) como temporizador, após transcorrer os

ciclos correspondentes ao tempo de amostragem, ocorre o overflow na contagem do


Duarte Fernandes

98

timer sendo colocado a ’1’ por hardware a timer overflow flag, gerando a interrupção

que invocará a função ‘send_count’ responsável por verificar se todos os parâmetros

solicitados encontram-se atualizados, para o seu envio ao utilizador sobre a forma de

mensagem de texto. Enquanto este cenário não ocorrer, o sistema deverá aguardar que

os parâmetros sejam atualizados, visto que o sistema utiliza uma programação que

recorre a interrupções e não por polling, a aquisição de dados GPS solicitados é

executada em “paralelo”. O que indica que a qualquer instante estes parâmetros

encontram-se atualizados e prontos a serem enviados ao utilizador que os requisitou,

após o envio é reiniciada a temporização e habilitada a interrupção do timer.

Aquisição dos Parâmetros GPS Solicitados

Como descrito na secção 4.6.1 (Inicialização do Receiver GPS) a comunicação

entre a unidade de processamento e o receiver é ativada quando necessário, isto é,

quando o utilizador solicita a informação output do receiver. Devido ao inconveniente

que esta abordagem gera, é necessário controlar os caracteres recebidos percorrendo o

algoritmo ilustrado na Figura 68 desenvolvido para o efeito, a sua tarefa consiste em

garantir que uma frase foi obtida na totalidade.

Figura 68 - Algoritmo de extração dos parâmetros GPS solicitados.

O processo de aquisição dos parâmetros GPS é representado pelo algoritmo da figura

anterior, a cada posição fixa o receiver inicia a transmissão dos carateres que

completam a frase. A sequência de entrada de carateres será analisada por um analisador


Duarte Fernandes

99

léxico, que determinará se a estrutura gramatical até então respeita a gramática formal

da frase GPRMC, contando também o número de carateres até então recebidos. Se a

frase não respeitar a gramática formal da frase pretendida significa que esta não foi

recebida na totalidade, assim será necessário esperar por uma nova posição fixa

realizando o mesmo processo aplicado à frase incompleta recebida. Esta estratégia

garante que uma frase inteira é recebida ininterruptamente possibilitando a extração dos

desejados parâmetros (velocidade, coordenadas geográficas e tempo) e desabilitará

comunicação quando realizado com sucesso.

Análise Sintática

Ao impor que a sequência de carateres percorra o algoritmo da Figura 69,

garante-se que a unidade de processamento é capaz de identificar quando uma

mensagem foi recebida na totalidade.

Figura 69 - Algoritmo implementado na função Parse_GPS.

A variável State inicializada com o valor zero, é utilizada como meio de identificar se o

carater lido pertence a uma frase incompleta (que será descartada), ou a uma frase


Duarte Fernandes

100

completa que será analisada. Quando o carater “$” é recebido, é alterado o valor da

variável State indicando que foi detetado o primeiro carater de uma frase GPRMC. A

partir deste momento, todos os carateres recebidos até ao instante em que é recebido

como output do receiver o carater terminador “/r” são armazenados numa string.

Quando recebido, é confirmada a validade da frase recebida através do checksum, este é

extraído da frase e calculado um novo checksum da frase recebida, quando os valores

coincidem é realizada a “extração” dos valores dos campos relevantes que

correspondem aos parâmetros solicitados. Caso o checksum calculado seja diferente do

obtido, o número de carateres é colocado a zero de forma a garantir que o processo de

aquisição dos parâmetros solicitados é reiniciado até garantir uma frase válida.

Envio dos Parâmetros (Atualizações Geográficas)

Após verificar que todos os parâmetros foram obtidos é tempo de os enviar via

GSM, este procedimento é realizado percorrendo o algoritmo da Figura 70

implementado na função Send_position.

Figura 70 - Processo de envio dos parâmetros solicitados.

Durante a realização dos passos que constituem o algoritmo, foram utilizados os vários

comandos AT descritos na Tabela 16.


Duarte Fernandes

101

Tabela 16 - Comandos AT usados durante o processo de envio dos parâmetros.

Comando Valor Descrição

Verificar qual o modo de

SMS AT+CMGF?

Indica se encontra em modo de texto

(1) ou modo PDU(0)

Criar mensagem de texto AT+CMGS=”numero de telefone” Criar mensagem de texto

Inserir parâmetros ao corpo

do texto <Time of fix:…. Criação do corpo da mensagem

Enviar mensagem <Time of fix:….<CRTL-Z> Enviar mensagem de texto

Processo “Bloqueio do veículo”

Este evento ocorre quando recebida uma mensagem de texto identifica a

intenção do utilizador bloquear o veículo através dos processos ‘Análise de eventos’ e

‘Aquisição de dados GSM’. Quando tal se confirma é invocada a função Act_security

que executará o algoritmo da Figura 71.

Figura 71 - Fluxo de informação durante o bloquei do veículo.

A implementação de uma técnica de bloqueio do veículo requer algumas medidas de

segurança, que garantam a integridade do veículo e do condutor.

Desta forma foi implementada a seguinte estratégia, após ordem de bloqueio é

executado o processo ‘Aquisição de parâmetros GPS solicitados’ analisado na secção

4.6.1, este avalia se a velocidade nesse mesmo instante é inferior a 20kms/h, caso tal

cenário seja verificado irá se prosseguir até à etapa de corte da corrente na bomba de

combustível, processo descrito em 3.4.2. Esta estratégia não coloca em perigo a

integridade do condutor e do veículo aquando o seu bloqueio

Obtenção de Sinais GPS

O receiver GPS após inicializado não se encontra automaticamente preparado

para o envio da frase com os parâmetros de interesse. Este necessita de captar os sinais


Duarte Fernandes

102

de quatro satélites para assim determinar as suas próprias coordenadas, o tempo e outras

variáveis. Quando o receiver se “enquadra” com os satélites, ele altera o valor do pino

fix para “1”, o que indicar à unidade de processamento que o receiver se encontra

preparado para transmitir informações GPS, possibilitando desde então da realização da

tarefa ‘Aquisição dos parâmetros GPS solicitados’. Para efetuar esta operação recorre-se

a dois tipos de interrupções, sendo elas: temporizador timer 1 e ainda uma interrupção

externa, ativada quando ocorre uma transição de um para zero ou o oposto. Quando uma

transição ocorre a interrupção é gerada e invocada a função Verifiy_fix(), esta inicia a

temporização do Timer 1, após executada a ISR é iniciada novamente a temporização

como demonstrado no fluxograma da Figura 72.

Figura 72 - Instruções da função Verify_fix.

É esperado que a flag do timer 1 seja colocada por hardware a “1”, o que neste contexto

significa que o fix continua com o valor de “1” sem sofrer qualquer alteração durante 30

overflows do timer, significa que o receiver está pronto a transmitir os dados GPS

recolhidos, este processo é realizado pela função ‘Fix_detect’ ilustrado na Figura 73.


Duarte Fernandes

103

Figura 73 - Fluxograma da função ‘Fix_detect’.

4.6.2 Comunicação com a Unidade Móvel

A unidade móvel composta pelo módulo SMS e o receiver GPS envia mensagens

de texto das atualizações de localização num intervalo de tempo pré-configurado ou

quando certos eventos ocorrem para o número SIM que realizou o pedido de update. Os

componentes que realizam trocas de informação direta com a unidade móvel no sistema

IntelFleet são os elementos Centro de Controlo e Terminal do Condutor da arquitetura

ilustrada na Figura 24, esta troca de informação é realizada via mensagens de texto

GSM.

Comandos Recebidos

As mensagens de texto são enviadas à unidade móvel principalmente com o

objetivo de alterar a frequência das atualizações ou em circunstâncias que se deseja o

envio imediato das atualizações, poem ser ainda utilizadas como meio de indicar o

bloqueio do veículo. As mensagens de texto são enviadas com o consentimento

explícito do utilizador e o consequente estado da resposta dada a conhecer ao utilizador.

A unidade móvel envia os dados da localização quando recebe comandos solicitando-os,

contudo pode também ser configurado para funcionar no modo periódico, onde é

enviada informação a cada intervalo de tempo, sendo que o mínimo intervalo entre

atualizações é sessenta segundos e o máximo são três horas.

A unidade pode também funcionar no modo ‘on-demand’, efetuando o update de

informação após a solicitação do mesmo, ação realizada apenas uma vez até novas


Duarte Fernandes

104

ordens. A unidade móvel pode funcionar em simultâneo nos dois modos, como exemplo

é apresentada a seguinte situação: utilizador/Gestor ativa o tracking ao veículo em

questão, seguindo o seu trajeto a partir das atualizações periódicas da sua localização e

ao mesmo tempo o utilizador condutor pode solicitar a posição à unidade recebendo

apenas a localização do veículo nesse mesmo instante, enquanto os dados de localização

continuarão a ser enviados ao Centro de Controlo até que o gestor indique o contrário.

A -Tabela 17 lista os comandos e respetivos formatos adotados na transmissão das

solicitações/intenções dos utilizadores à Unidade Móvel.

-Tabela 17 - Formato das mensagens reconhecidas pela Unidade Móvel

Mensagem Formato Origem Exemplo

Bloqueio do veículo *block+ A.Android/Centro de

Controlo ---

Desbloqueio do

veículo *ubloc+ Centro de Controlo ---

Modo periódico *txxxx+ Centro de Controlo *t0060+

Desabilitar modo

periódico *tstop+ Centro de Controlo ---

A mensagem com o texto: “*t0060+”, indica à unidade móvel que a transmissão de

dados ao Centro de Controlo de forma periódica com um tempo de amostragem de 60

segundos deve ser iniciada. Quando enviado comando “*block+” é executa a operação

de bloqueio do veículo na unidade móvel, após isto é enviada a atualização da

localização com o mesmo formato e informação das restantes solicitações de

atualização de dados.

Formato da Resposta às Solicitações de Atualização da Localização

As mensagens provenientes da unidade móvel contêm informação de localização

GPS, velocidade e tempo, codificadas em uma modificação do formato NMEA RMC.

Esta sentença NMEA é iniciada com um sinal de dólar ($) e contém uma série de

campos separados por vírgulas. Cada campo é importante para determinar a localização,

a velocidade e a direção do veículo num determinado ponto no tempo. Através destes

campos é construída a sentença a enviar aos elementos que solicitam a atualização da

localização, um exemplo da mensagem poderia ser:

Time of fix:232943Lat:4126.8775NLong:00818.4419WSpeed:34.02;

A Tabela 18 descreve os diferentes campos que compões a mensagem “Time of fix”.


Duarte Fernandes

105

Tabela 18 – Parâmetros da mensagem da unidade móvel como resposta às solicitações de atualização de dados.

Campo Descrição Exemplo Interpretação

Time of fix Seis dígitos que indicam o tempo da atualização 232943 23:29:43 UTC

Lat Valor da latitude em graus 4126.8775 41º26’ 8775’’

Direção da

latitude

Direção da latitude pode ser N ou S (Norte ou

Sul) N Norte

Long Valor da Longitude em graus 00818.4419 8º18’4419’’

Direção da

Longitude

Direção da longitude pode ser E ou W (Este ou

Oeste) W Oeste

Speed Velocidade em nós 34.02 34.02 nós, 63

kms/h

Após recebida a sentença anterior pelo Centro de Controlo é necessário realizar cálculos

(abordados no anexo A.1) que permitam alterar dos dados da sentença NMEA para

valores (coordenadas geográficas) reconhecidas pelos métodos da API do Google Maps.


Duarte Fernandes

106


Duarte Fernandes

107

5. Testes e Resultados Obtidos

No presente capítulo é analisado os resultados obtidos na utilização desta

ferramenta num cenário que permita avaliar a viabilidade da mesma. Existe a

preocupação de tornar o mais real possível o teste à ferramenta em questão, assim sendo

é instalado o dispositivo no veículo e testadas as funcionalidades das várias aplicações

que a compõem.

Antes disso, são apresentados alguns testes realizados ao dispositivo de hardware

Unidade Móvel. Estes provam as capacidades do dispositivo, anunciadas durante a sua

descrição e implementação, comprovando a veracidade dos dados recebidos nas

diversas aplicações da ferramenta durante o teste de todo o sistema.

5.1 Unidade Móvel

O dispositivo é constituído por vários módulos, assim a melhor forma de testar o

hardware é partir de testes individuais (Tabela 19). Quando estes respondem ao

solicitado, faz sentido testar a integração dos diferentes componentes. Este processo

permite detetar e isolar os erros rapidamente.

Após os testes serem realizados com sucesso, é tempo de iniciar a integração dos

diferentes módulos. De seguida são apresentados os resultados de alguns dos testes

descritos na Tabela 19.


Duarte Fernandes

108

Tabela 19 - Casos de teste utilizados para prevenir erros no produto final.

Módulo Input Resposta Esperada Descrição do teste

PTN78060W 12V 5V

Colocar 12V na entrada do

conversor CC-CC e verificar saída

de 5V.

Receiver GPS --- Frases NMEA

Alimentar Receiver, ligar pinos

RX e TX, configurar comunicação

série e aguardar pelas 5 frases

NMEA como resposta.

Receiver GPS

+PTN78060W ---

Strings descritas pelo

protocolo NMEA

Alimentar Receiver a partir da

saída do conversor CC-CC

alimentado com um valor entre

12-30V, iniciar Receiver e esperar

pela frase NMEA.

Regulador de

tensão

5V 3.3V Impor 5V na entrada do regulador

e verificar valor da saída.

Regulador de

tensão

+PTN7860W

12V

3.3V

Colocar 12V à entrada do

conversor CC-CC e ligar

retificador de tensão À sua saída,

verificar tensão de 3.3V à saída do

regulador.

Módulo GSM “AT” “OK”

Ligar pinos de alimentação, ligar

RX e TX, configurar a ligação da

porta série, enviar string “AT” e

aguardar como resposta “OK”.

Módulo GSM +

PTN78060W

"AT"

"OK"

Ligar os pinos de alimentação à

saída do conversor CC-CC,

configurar a ligação da porta série,

enviar string de input e verificar

resposta.

Microcontrolador

---

Ligar LED

Programar o µc, com um

programa de acender um LED,

alimentar o µc através do

regulador de tensão e verificar se

o LED acende.

TIMER --- Piscar LED

Programar µc para fazer toggle ao

estado de um pino aquando o

timer finaliza a contagem,

alimentar o µc e verificar se o

LED pisca no tempo certo.

USART “Teste” “Teste”

Após programar o µc com um

programa que envia strings pela

porta série, alimentar o µc, ligar o

RX e TX e verificar, através de

um terminal, se é enviado pela

porta série a string de input.

Módulo GPS

Como referido anteriormente, o receiver GPS após alimentado começa o

processo de aquisição de sinais, este consiste no envio contínuo das diversas frases


Duarte Fernandes

109

NMEA. De forma a testar a comunicação série com o receiver, é configurada a porta

série com os parâmetros referidos em 4.6.1 e iniciada a comunicação. Através de várias

experienciais, verifica-se que o receiver demora em média 90 segundos até colocar o fix

a “1”, a partir deste instante são transmitidas as diferentes frases como demonstra o

resultado a um teste realizado (Figura 74).

Figura 74 - Frases NMEA transmitidas pelo receiver.

Microcontrolador na Aquisição dos Dados GPS.

O teste de aquisição de dados GPS, baseia-se nos seguintes passos: ligar o

módulo GPS à USART2 do µc e o Arduíno à USART1 como interface com o PC.

O µc foi previamente programado, com uma versão do programa que inclui o envio dos

resultados para a USART1, permitindo a visualização dos acontecimentos num PC. Com

este teste, procura-se validar as funções de envio e receção de dados via porta série, o

detetor de sinal do fix e a função de parsing do GPS. Os resultados obtidos encontram-

se ilustrados na Figura 75.

Figura 75 - Frase NMEA recebida, proveniente do output do Receiver e variáveis de interesse extraídas do

output.

A partir do resultado obtido, verifica-se que do output do receiver é obtida apenas a

mensagem GPRMC, o que significa que o este foi configurado apenas para transmitir


Duarte Fernandes

110

uma única frase NMEA como desejado. O parsing desenvolvido reconhece e aprova as

frases recebidas através do cálculo do checksum, por fim são extraídas as informações

desejadas.

Integração dos Diversos Módulos

A montagem final da Unidade Móvel (Figura 119) é testada do seguinte modo:

microcontrolador programado para enviar a uma frequência de 30 segundos a frase

GPRMC, sobre a forma de uma mensagem de texto para um dado número SIM; a

energia de alimentação deste é obtida da fonte de energia do veículo (bateria). O

dispositivo é colocado sem se deslocar na seguinte posição: 41.415899, -8.4387700

(confirmado pelos mapas da Google), desta forma espera-se que os resultados traduzam

isso mesmo, ou seja, velocidade igual a zero e coordenadas geográficas fixas ao longo

do tempo. Os resultados do teste são apresentados na Tabela 20.

Tabela 20 - Resultados do teste as atualizações periódicas.

Frase recebida Velocidade Latitude Longitude Tempo

Time of fix:134710

Lat: 4124.9555N

Long:00826.3287W

Speed:0.34

0.34 nós/

0.63Kms/h

41º 24.9555’/

41.415925

-008º 26.3287’/

-8.438811666 13:47:10

Time of fix:134741

Lat: 4124.9567N

Long:00826.3287W

Speed:0.42

0.42 nós/

0.77Kms/h

41º 24.9567’/

41.415945

-008º 26.3287’/

-8.438811666 13:47:41

Time of

fix:134815Lat:

4124.9572N

Long:00826.3277W

Speed:0.41

0.41 nós/

0.76Kms/h

41º 24.9572’/

41.415933

-008º 26.3277’/

-8.4387195 13:48:15

Time of fix:134849

Lat: 4124.9579N

Long:00826.3290W

Speed:0.03

0.03 nós/

0.06Kms/h

41º 24.9579’/

41.415965

-008º 26.3290’/

-8.4388166 13:48:49

Os resultados são bastantes satisfatórios, pois demonstram que a aquisição de dados é

bastante viável, obtendo valores bastantes próximos dos esperados. As coordenadas

obtidas, apesar de não corresponderem à verdadeira posição do veículo, apresentam um

erro nunca superior a três, quatros metros como nos demonstra a Figura 76.


Duarte Fernandes

111

Figura 76 - Ponto geográficos obtidos durante o teste da aquisição de dados do dispositivo móvel numa posição

fixa (ponto A).

A variável velocidade adquirida encontra-se muito próxima do valor esperado em todas

as aquisições obtidas, tendo a aproximar-se do valor esperado ao longo do tempo. Isto

significa que no processo de bloqueio do veículo são respeitadas as normas de

segurança, ou seja, a imobilização do veículo irá ocorrer apenas quando sua velocidade

é inferior a 20 km/h.

Os seguintes links, são vídeos que resultam de testes realizados à unidade em

movimento e ainda ao sistema de bloqueio do veículo.

http://www.youtube.com/watch?v=u7OXtzgbZiI;

http://www.youtube.com/watch?v=mwGRSW_XPos;

http://www.youtube.com/watch?v=mSxSS4_Dx_U;

5.2 Centro de Controlo

Para a realização do teste que põe à prova a integração dos diversos

componentes que compõem a ferramenta, a plataforma física foi colocada em

movimento e uma tarefa (Figura 85) foi delineada ao condutor.

Foi parada a execução do background service iniciado aquando ligado o PC. A seguinte

figura demonstra que a aplicação foi capaz de identificar que este não se encontra ainda

em execução.

http://www.youtube.com/watch?v=u7OXtzgbZiI

http://www.youtube.com/watch?v=mwGRSW_XPos

http://www.youtube.com/watch?v=mSxSS4_Dx_U


Duarte Fernandes

112

Figura 77 - Resultado ao teste de verificação do serviço.

O resultado dessa verificação encontra-se ilustrado na Figura 78.

Figura 78 - Verificação do estado do background service.

Como era de esperar o serviço possui como “Status” o valor false, assim foi forçado o

início do serviço, o resultado desta operação encontra-se ilustrado na Figura 79.

Figura 79 - Resultado obtido após forçar o início do serviço.

Como nos comprova o gestor de serviços do Windows (Figura 80), já se encontra a

correr o serviço (Service1).


Duarte Fernandes

113

Figura 80 - Gestor de serviço do Windows.

O próximo passo do teste visa a introdução dos recursos humanos e físicos necessários,

tais como cliente, condutor e veículo. Estes são os elementos ativos durante a realização

da tarefa.

Figura 81 - Dados dos condutores registados na base de dados

A partir desse instante espera-se obter as atualizações periódicas na aplicação

Centro de Controlo que traduzem o trajeto percorrido durante a realização da tarefa.

A Figura 82 reflete o processo de inserção de um cliente, mais especificamente a

indicação da sua localização.


Duarte Fernandes

114

Figura 82 - Inserção de um cliente na base de dados.

As atualizações da localização da unidade obtidas durante a realização da tarefa/teste já

mencionado encontram-se na Tabela 21.

Tabela 21- Dados GPS adquiridos durante a realização da tarefa.

ID do ponto Velocidade

(km/h) Latitude Longitude Tempo

1 0.9 41.416076 -8.439263 19:16:15

2 35 41.417540 -8.441370 19:17:17

3 02 41.419750 -8.444101 19:18:19

4 38 41.417292 -8.450271 19:19:23

5 52 41.414508 -8.459022 19:20:26

6 32 41.413840 -8.466103 19:21:27

7 70 41415247 -8.471639 19:22:29

8 75 41.420879 -8.487171 19:23:31

9 40 41.415390 -8.502962 19:24:33

10 52 41.412930 -8.508671 19:25:35

11 55 41.078969 -8.513846 19:26:33

12 60 41.413701 -8.518674 19:27:34

13 0.6 41.415215 -8.520262 19:28:36

A Figura 83 apresenta a messagebox utilizada como meio de notificar o utilizador de

uma nova atualização.


Duarte Fernandes

115

Figura 83 -Notificação da atualização de dados.

5.3 Posto de Trabalho

Como demonstra a Figura 84, os dados introduzidos que dizem respeito ao

condutor utilizado no presente caso de teste, já se encontra registado na base de dados

remota.

Figura 84 - Detalhes do condutor com o id=1;

Como já referido, foi criada uma tarefa com os parâmetros ilustrados Figura 85.


Duarte Fernandes

116

Figura 85 -Parâmetros que caraterizam uma tarefa.

Antes da realização da tarefa, quando consultada a localização atual do veículo é

apresentado o seguinte conteúdo ao utilizador coordenador (Figura 86)

Figura 86 - Informações do veículo, antes do condutor ter conhecimento da nova tarefa.

Após criado, espera-se que este seja apresentado como um serviço pendente. Realizando

uma consulta aos serviços pendentes, obteve-se o seguinte resultado (Figura 87 e Figura

88).


Duarte Fernandes

117

Figura 87 - Tabela com os serviços que se encontram por realizar.

Como esperado, o serviço anteriormente criado já se encontra “visível” a toda a

organização, assim o condutor será notificado da nova tarefa e a aquisição das

atualizações de forma periódica estabelecida e iniciada.

Figura 88 - Rota definida para a tarefa pelo coordenador.

À medida que o Centro de Controlo recebe as coordenadas geográficas referentes à

posição do veículo é atualizada a base de dados como nos comprova a Figura 89.

Figura 89 - Registos dos pontos na base de dados.

Quando consultado o trajeto percorrido pelo veículo até então, é obtido o resultado

apresentado na Figura 90.


Duarte Fernandes

118

Figura 90 - Aspeto da imagem após consulta do trajeto percorrido pelo veículo.

Neste instante foi testado o processo de validação de rotas, ao clicar no controlo “Rota”

é obtido o resultado presente na Figura 91. No presente caso, o veículo não possui

nenhum step dentro de um raio de um km, contudo encontra-se no trajeto entre steps o

que significa que o trajeto coincide com o delineado pelo coordenador.

Figura 91 - Teste do processo responsável por detetar trajetórias indesejáveis.


Duarte Fernandes

119

5.4 Terminal do Condutor

Na presente secção, são apresentados os resultados obtidos na realização dos

testes às diferentes funcionalidades da aplicação Terminal do Condutor durante a

simulação.

Login

A resposta esperada do servidor (ficheiro XML) após requisição assíncrona deve

conter os dados dos vários condutores registados na base de dados (dois utilizadores

para o presente teste). O resultado obtido encontra-se ilustrado na Figura 92.

Figura 92- Conteúdo do ficheiro XML obtido no teste ao processo de autenticação

As credenciais introduzidas são comparadas com os dados do resultado anterior, quando

o processo é realizado com sucesso é iniciado o background service. A Figura 92 ilustra

a sequência de telas desde a autenticação até ao menu da aplicação, neste último passo é

colocado a correr o serviço como já referido.

Figura 93 - Tela durante processo de login e tela seguinte (Menu da aplicação, notifica utilizador

quando iniciado o background service).

O gestor de aplicações do smartphone utilizado no teste do software desenvolvido,

apresenta dados sobre as diversas aplicações que se encontram a ser executadas, entre

eles podemos identificar o Terminal do Condutor. Assim sendo, a Figura 94 confirma

que o serviço já se encontra a executar como esperado.


Duarte Fernandes

120

Figura 94 - Gestor de aplicações apresenta detalhes da aplicação, espaço ocupado, tempo de execução e

componentes a correrem (serviço).

Envio de mensagens de texto

Consiste no envio de uma mensagem de texto à Unidade Móvel instalada no

veículo associado ao condutor. A Figura 95 apresenta os valores utilizados para o envio

da mensagem. O número do localizador como podemos verificar coincide com o

registado anteriormente na base de dados, o mesmo acontece com o corpo da

mensagem, pois corresponde ao comando “on-demand”.

Figura 95 - Parâmetros enviados durante requisição de atualização “on-demand”, número do localizador e

texto da mensagem.

A Figura 96 apresenta o conjunto de telas visíveis ao condutor durante este processo.

Figura 96 - Telas durante o pedido de atualização da localização


Duarte Fernandes

121

O utilizador deve ser notificado do estado de envio da mensagem de texto, a Figura 97 e

a Figura 98 ilustram o estado do envio da mensagem de texto no teste efetuado. Em

modo debug e partir de breakpoints verificou-se que foi enviada e recebida pelo

destinatário.

Figura 97 - Estado da mensagem, enviada com sucesso.

Figura 98 - Estado da mensagem, recebida pela unidade móvel.

Registo de veículos

De forma a testar esta funcionalidade, foi criado um QRcode com o texto do

veículo com a matrícula “78-12-DN”, ilustrado na Figura 99.

Figura 99 - QRcode gerado a partir do texto "728-12-DN".

O texto retornado como resultado da aplicação Barcode Scanner coincide com o texto

do QRcode, como comprova a Figura 100.

Figura 100 - Texto após o scanner ter sido realizado.


Duarte Fernandes

122

A função postData_vehicle (Figura 101) realiza os passos necessários à alteração do

campo ‘veiculo_matricula’ da tabela “Driver”. Como o veículo apenas se pode

encontrar associado a um só condutor, significa que apenas pode estar numa linha da

tabela. Assim espera-se que o condutor anteriormente referenciado deixe de o estar, e o

condutor com o “ID”=1 tenha o novo veículo associado.

Figura 101 - Resultado positiva após o processo de registo de veículos, alterados com sucesso os campos

necessários que traduzem a mudança de veículo à organização.

O resultado apresentado na Figura 102 demonstra que foram realizadas com sucesso as

alterações esperadas na tabela “Driver”.

Figura 102 - Tabela “Driver” após alterações dos campos influenciados por esta mudança levada a cabo

durante o teste.

Receção de Atualizações

Após o envio do comando “on-demand” para a unidade móvel, espera-se por uma

resposta sobre a forma de mensagem de texto com as informações desejadas. A receção,

processamento e apresentação dos dados da localização é responsabilidade do módulo

Broadcast Receiver. A Figura 103 apresenta o conteúdo da mensagem recebida, apenas

as coordenadas geográficas interessam ao condutor, assim são extraídas e utilizadas para

realizar o reverse geocoding.

Figura 103 - Identificação do conteúdo da mensagem de texto proveniente da unidade móvel.

Através das coordenadas obtidas e após realizado o reverse geocoding foi obtido o

resultado ilustrado Figura 104.


Duarte Fernandes

123

Figura 104 - Localização correspondente as coordenadas transmitidas pela unidade móvel.

As telas que informam o utilizador durante o teste são visíveis na Figura 105.

Figura 105 - Resultado da atualização “on-demand”.

Serviço Executado em Background

Quando criada uma nova tarefa para o condutor com o “ID”=1, é esperado que

este seja notificado. A Figura 106 apresenta os dados da tarefa introduzidos no ficheiro

XML como resposta à requisição levada a cabo pelo background service.

Figura 106 - Ficheiro XML, contêm os dados relativos à tarefa criada ao longo do teste.

A Figura 107 apresenta a sequência de telas que resulta do processo de identificação de

novas tarefas, levada a cabo pela aplicação Android durante o teste.


Duarte Fernandes

124

Figura 107 - Resultado do processo de "escuta" de novas tarefas durante o teste realizado.

O vídeo do link apresentado em baixo, demonstra o comportamento da aplicação

Terminal do Condutor e descreve as funcionalidades oferecidas pelo mesmo.

http://www.youtube.com/watch?v=3jruigxd2HE&feature=youtu.be;

http://www.youtube.com/watch?v=3jruigxd2HE&feature=youtu.be


Duarte Fernandes

125

6. Conclusão e Trabalho Futuro

Neste capítulo são descritas as conclusões retiradas da solução implementada,

incluindo ainda as indicações de trabalho futuro que proporcionará melhorias

significativas na ferramenta IntelFleet.

6.1 Conclusões

A presente dissertação teve como objetivo a realização de um sistema de

localização e gestão de frota com uma componente de controlo do veículo, utilizando

tecnologias de GPS e GSM.

Durante o projeto foi realizado o levantamento das tecnologias com utilização relevante

para o sistema e uma comparação de vários produtos já existentes no mercado.

Foi levado em conta as necessidades das empresas possuidoras de frotas, procurando

satisfazer as necessidades dos mesmos a partir da ferramenta, desta forma foi estudado o

melhor meio de conciliar as tecnologias e requisitos das empresas. Além disso, foi

sempre tido em conta a inclusão de uma componente inovadora face aos produtos

analisados existentes.

Do desenvolvimento deste projeto resulta uma solução que vai de encontro aos

objetivos inicialmente propostos. Foi criada uma plataforma física, convenientemente

testada, que suporta comunicação GSM, obtenção de coordenadas GPS, e

armazenamento da informação dos pedidos recebidos (requisições de atualizações

periódicas) do Centro de Controlo durante a sua utilização, isto permite estabelecer

comunicações após falhas no dispositivo que obrigam a plataforma a reiniciar. Os dados

GPS são transmitidos à aplicação Centro de Controlo, este tem a tarefa de tratar os

dados e atualizar o servidor com esta informação, passando a estar disponível para

consulta via Web, bastando aceder ao site desenvolvido para o efeito. Esta aplicação,

designada de Posto de Trabalho apresenta ao utilizador informações sempre atualizadas

para o planeamento de novas tarefas. Verificou-se a partir de vários testes realizados,

que o algoritmo responsável por detetar possíveis trajetos que não estejam a respeitar,

em tempo real a rota definida ante mão é funcional e bastante viável quando aplicado

em ambientes urbanos, onde se espera que exista um maior número de steps.


Duarte Fernandes

126

Dos testes realizados à integração dos vários componentes da ferramenta, obteve-se

resultados satisfatórios, com os dados GPS a estarem próximos do valor real. A partir

destes verifica-se que ao nível da segurança, o sistema respeita as normas impostas, isto

é, o veículo só é imobilizado pela plataforma física quando possui velocidades

inferiores a 20 km/h. As coordenadas enviadas ao condutor após a imobilização do

veículo são viáveis e permitem a sua localização e posterior aquisição corretamente. Ao

nível do Terminal do Condutor, verificou-se pela análise dos testes efetuados que as

funcionalidades concebidas ao condutor são realizadas com sucesso, desde a

comunicação com a unidade móvel ao registo de veículos onde são realizadas ações que

visam manter a integração da base de dados remota através de triggers.

Do ponto de vista do projeto, os objetivos foram cumpridos com sucesso, o sistema é

funcional. Enquanto produto, não se encontra preparado para ser comercializado, pois a

plataforma física requer alguns melhoramentos pois trata-se de um protótipo. Às

aplicações que suportam as tarefas dos vários utilizadores podem novas funcionalidades

serem acrescentadas que automatizem mais a ferramenta IntelFleet.

6.2 Trabalho Futuro

Os trabalhos futuros a curto prazo, prendem-se essencialmente na monitorização

de um maior número de variáveis, isto poderá ser útil dependendo dos tipos de produtos

transportados, por exemplo, no transporte de produtos que requerem determinadas

temperaturas é importante ter conhecimento das mesmas em tempo real. Uma possível

solução que pode ser estudada e implementada seria a incorporação da Unidade Móvel

numa rede sem fios composta por vários sensores (sensor de humidade, de temperatura

entre outros) que permita aquisição destas variáveis para posterior transmissão ao

Centro de Controlo.

A aplicação Terminal do Condutor pode sofrer um acréscimo de funcionalidades a fim

de automatizar o sistema IntelFleet. A realização de encomendas não abordada durante

a implementação da solução poderá ser uma das novas funcionalidades desta aplicação,

automatizando ainda mais a ferramenta IntelFleet.

Uma alteração mais profunda identificada como trabalho futuro, consiste na substituição

do meio de comunicação GSM pelo GPRS, tal implicaria mudanças ao nível do

hardware (Unidade Móvel) e caso se deseje ao nível do software. A utilização deste


Duarte Fernandes

127

meio de comunicação excluía a necessidade de utilização do modem GSM no Centro de

Controlo (menor custos). A partir deste instante as atualizações de localizações dos

veículos passariam a ser realizadas exclusivamente via Socket TCP/IP.

Ao nível da segurança são reconhecidas algumas melhorias, nomeadamente a

incorporação de um botão de alarme que permita alertar a organização do furto ocorrido

e a utilização de uma pequena bateria para alimentação de todo dispositivo (Unidade

Móvel). Este último passo permite continuar o tracking do veículo mesmo depois de

este ser desmantelado (retirada bateria do veículo) e evita a sua instalação (pode ser

colocado mais próximo dos produtos) e consequente alteração da originalidade do

veículo. Outra possível implementação ao nível da segurança, consiste na incorporação

do serviço Voip, podendo ser utilizado como meio de comunicação com o condutor ou

como meio de escutar o veículo e mais concretamente os indivíduos que conduzem o

veículo após furtados, sendo o serviço Voip ativado remotamente.


Duarte Fernandes

128


Duarte Fernandes

129

Bibliografia

[1] M. A. A.-K. S. M. I. Montaser N. Ramadan, “Intelligent Anti-Theft and Tracking

System for,” International Journal of Machine Learning and Computing, vol. 2, 2012.

[2] P. P. W. a. P. S. D. G. T.-A. A.-t. System, “Real Time Vehicle Locking and Tracking

System using GSM and GPS Technology-An Anti-theft System,” International Journal

of Technology And Engineering System(IJTES), vol. Vol.2, 2011.

[3] S. Manoharan, “On GPS Tracking of Mobile Devices,” em Fifth International

Conference on Networking and Services, New Zealand, 2009.

[4] M. A. Al-Khedher, “Hybrid GPS-GSM Localization of Automobile Tracking System,”

International Journal of Computer Science & Information Technology (IJCSIT), vol.

Vol 3, Dec 2011.

[5] “Inteligência empresarial,” [Online]. Available:

http://pt.wikipedia.org/wiki/Intelig%C3%AAncia_empresarial. [Acedido em 12

Dezembro 2001].

[6] S. Thong, C. Tien e T. Rahman, “Intelligent Fleet Management System with Concurrent

GPS & GSM Real-Time Positioning Technology,,” Telecommunications, vol. ., n.º .,

pp. 1-6, 6-8, Junho 2007.

[7] H. L. E. W. Bernhard Hofmann-Wellenhof, GNSS - Global Navigation Satellite

Systems: GPS, GLONASS, Galileo, and more, SpringerWienNewYork, 2008.

[8] H. O. Y. W. M. M. L.-S. P. a. D. R. Philo Juang, “Energy-Efficient Computing for

Wildlife Tracking: Design Tradeoffs and Early Experiences with ZebraNet,” em

Conference on Architectural Suport for Programming Languages and Operating

Systems, San Jose, CA, October 2002.

[9] “NMEA data,” [Online]. Available: http://www.gpsinformation.org/dale/nmea.htm.

[Acedido em 21 Dezembro 2011].

[10] “The GSM Standart,” [Online]. Available:

http://www.gsmserver.com/articles/gsm_overview.php. [Acedido em 28 Dezembro

2011].

[11] “Tecmic,” [Online]. Available: http://www.tecmic.pt/docs/Tecmic-XTraN_pt.pdf.

[Acedido em 5 Janeiro 2012].

[12] “Tecmic Web,” [Online]. Available: http://www.tecmic.pt/eng/xtran/xtran_web.html.

[Acedido em 5 Janeiro 2012].

[13] “Frotasoft,” [Online]. Available: www.frotasoft.com/. [Acedido em 6 Janeiro 2012].

[14] “Moviloc,” [Online]. Available:


Duarte Fernandes

130

http://www.gmv.com/pt/Transportes/FrotasEspeciais/Moviloc.html. [Acedido em 6

Janeiro 2012].

[15] “Pt Negocios, Gestão de Frotas,” [Online]. Available:

http://www.ptnegocios.pt/portal/site/negocios/menuitem.269f923fc057d24c29de769b85

105%206a0/?vgnextoid=43f70ec778bd0310VgnVCM1000005401650aRCRD&view_n

ame=null%2F%3F&gcl%20id=CLS1_4PRu68CFYgifAodE2LbhA. [Acedido em 9

Janeiro 2012].

[16] “QTracker – GPS/GSM,” [Online]. Available: http://205.134.232.209/semsons/Spec-

GT-Q3000.pdf. [Acedido em 30 Janeiro 2012].

[17] “Brick House Security,” [Online]. Available:

http://www.brickhousesecurity.com/product/brickhouse+hct+pro+plus.do?sortby=bestS

ellers. [Acedido em 25 Janeiro 2012].

[18] “GT-Q3000,” [Online]. Available: http://205.134.232.209/semsons/Spec-GT-

Q3000.pdf. [Acedido em 23 Janeiro 2012].

[19] R. A. V. Gomes, Sistema embebido de georreferanciação e controlo, FEUP, 2012.

[20] “API do Google Maps,” [Online]. Available:

https://developers.google.com/maps/documentation/javascript/tutorial. [Acedido em 14

Março 2012].

[21] “Modem GSM/GPRS,” [Online]. Available: http://www.mc-

elettronica.com/telit_ez10_family.pdf. [Acedido em 14 Julho 2012].

[22] P.M.Muruganandham, “Real Time Web based Vehicle Tracking using GPS,” em World

Academy of Science, Engineering and Technology, Janeiro 2010.

[23] “Microcontrolador Microchip,” [Online]. Available:

http://ww1.microchip.com/downloads/en/DeviceDoc/41412F.pdf. [Acedido em 10

Julho 2012].

[24] “Conversor Step-Down,” [Online]. Available:

http://www.ti.com/lit/ds/symlink/ptn78060w.pdf. [Acedido em 24 Julho 2012].

[25] “Módulo GPS,” [Online]. Available: http://www.adafruit.com/datasheets/PA6B-

Datasheet-A07.pdf. [Acedido em 3 Junho 2012].

[26] “Siemens TC-35,” [Online]. Available:

http://harvestelectronics.com/harvest/pdf/tc35_t_ug.pdf. [Acedido em 12 Julho 2012].

[27] “Bloqueador Anti-assalto,” [Online]. Available:

http://www.dni.com.br/media/Manual_DNI_1200-Auto.pdf. [Acedido em 4 Agosto

2012].

[28] J. F. R. d. Oliveira, “Sistema Anti-Roubo de Veículos com GSM/GPS,” FEUP 2011,

2011.


Duarte Fernandes

131

[29] M. Chand, C# Programming for Beginners, C# Corner, 2011.

[30] “Introduction to Windows Service Applications,” [Online]. Available:

http://msdn.microsoft.com/en-us/library/d56de412.aspx. [Acedido em 15 Fevereiro

2012].

[31] “Sistemas Operativos em dispositivos móveis,” [Online]. Available:

http://pt.kioskea.net/faq/11106-sistemas-operacionais-para-celulares-e-dispositivos-

moveis. [Acedido em 24 Janeiro 2012].

[32] “Android architecture,” GOOGLE INC: ANDROID DEVELOPERS, [Online].

Available: http://developer.android.com/guide/basics/what-is-android.html. [Acedido

em 28 Janeiro 2012].

[33] “Android developers: Sdk,” GOOGLE INC: ANDROID DEVELOPERS., [Online].

Available: http://developer.android.com/sdk/1.5_r3/index.html. [Acedido em 28

Fevereiro Fevereiro].

[34] “ADT Plugin,” [Online]. Available: http://developer.android.com/tools/sdk/eclipse-

adt.html. [Acedido em 1 Abril 2012].

[35] “Google Maps API,” GOOGLE INC: ANDROID DEVELOPERS, [Online]. Available:

www.developers.google.com/maps.. [Acedido em 26 Fevereiro 2012].

[36] “Google Maps JavaScript API V3,” [Online]. Available:

https://developers.google.com/maps/documentation/javascript/?hl=pt-br. [Acedido em

10 Julho 2012].

[37] J. Bacon, Practical PHP and MySQL: building eight dynamic web applications,

Prentice Hall PTR, 2006.

[38] L. Babin, Beginning Ajax with PHP: From Novice to Professional, Apress, 2006.

[39] “EAGLE PCB Software,” [Online]. Available: http://www.cadsoftusa.com/ . [Acedido

em 14 Setembro 2012].

[40] D. B. Makofske, TCP/IP Sockets in C# Practical Guide for Programmers Book, Morgan

Kaufmann; 1 edition, 2004.

[41] J. M. G. Alves, “Desenvolvimento de um sistema dinâmico,” Universidade do Minho,

2010.

[42] “API Guides Android,” [Online]. Available:

http://developer.android.com/guide/components/index.html. [Acedido em 14 Julho

2012].

[43] “Requesitos Funcionais e não Funcionais,” Wikipédia, [Online]. Available:

http://pt.wikipedia.org/wiki/Requisito. [Acedido em 14 Dezembro 2011].


Duarte Fernandes

132


Duarte Fernandes

133

Apêndice A

A.1 Protocolo NMEA

As principais mensagens NMEA utilizadas pelos recetores GPS são:

GPRMC;

GPGGA;

GPVTG;

GPGSV;

GPGLL.

No âmbito do projeto, a frase NMEA de interesse é a GPRMC pois é esta que é

selecionada para ser gerada pelo recetor GPS.

RMC – Recommended Minimum Specific GNSS Data

Dados: Tempo, data, posição, curso e velocidade

Estrutura: $GPRMC, hhmmss.sss(1), A(2),ddmm.mmmm(3), a(4), dddmm.mmmm(5), a(6), x.x(7), x.x(8),

ddmmyy(9), x.x(10), a(11), a(12), *hh(13) <CR><LF>

Exemplo:$GPRMC,092204.999,A,4250.5589,S,14718.5084,E,0.00,89.68,211200,,A*25<CR><LF>

Para transformar os dados da sentença NMEA em dados validos, para posterior

visualização no Google Maps deve-se seguir os passos apresentados de seguida.

Tabela 22 - Campos da frase GPRMC.

Posição Significado Valor (Exemplo) Descrição

1 Tempo UTC 060932.448 Horário UTC no

formato hhmmss.sss

2 Estado A ‘V’=GPS aquecendo

‘A’=Dados válidos

3 Latitude 2447.0959 Latitude no formato

ddmm.mmmm

4 Indicador N/S N Hemísferio

(‘N’=Norte)(‘S’=Sul)

5 Longitude 12100.5204 Longitudeno formato

ddmm.mmmm

6 Indicador E/W E Hemísferio


7 Velocidade 000.0 Velocidade em nós

8 Curso 000.0 Curso em graus

9 Data UTC 211200

Data UTC de uma

posição, no formato

ddmmyy

10 Variação magnética Em graus (000.0 –

180.0)

11 Variação magnética

Em direção

‘E’=Leste;

‘W’=Oeste

12 Indicador de Modo A ‘N’=Dados não


Duarte Fernandes

134

válidos

‘A’=Modo autónomo

‘D’=Modo

Diferencial

‘E’=Modo Estimado

‘M’=Modo entrada

manual

‘S’=Modo simulação

13 Checksum 0E

Começa com * e

consiste em 2

carateres r

representam um

número

hexadeciamal

Latitude

A seguinte tabela apresenta os campos de interesse na frase NMEA recebida para o

cálculo da latitude.

Tabela 23 - Campos da frase GPRMC relevantes para o cálculo da latitude.


3 Latitude 425.5589 Latitude no formato

ddmm.mmmm

4 Indicador de direções S Hemísferio


15444.6164 S=-15º 44.9892’

Para transformar em graus divide-se por 60

(44.6164/60)=0,743606=-15.743606

Longitude

A seguinte tabela apresenta os campos de interesse na frase NMEA recebida para o

cálculo da longitude.

Tabela 24 - Campos da frase GPRMC relevantes para o calculo da latitude.


5 Longitude 14718.5084 Longitude no formato

ddmm.mmmm

6 Indicador de

direções

E Hemísferio

(‘E’=Este)(‘W’=Oeste)

04755.6189 W=-047º 55.6189’

Para transformar em graus divide-se por 60

(55.6189/60)=0,926981=-047.926981


Duarte Fernandes

135

A.2 Caraterísticas do Modem GSM

A seguinte tabela apresenta as características do modem GSM selecionado no

decorrer do projeto.

Tabela 25 - Características do modem GSM (Telit EZ10-GPRS).

Dimensões 107x64x33mm

Peso 200g

Temperaturas

de funcionamento

Em condições normais de funcionamento: -10ºC - +55ºC

Em condições extremas de funcionamento: -20ºC - +85ºC

Em condições de armazenamento: -30ºC – 85ºC

Sensibilidade -102dBm

Alimentação

Tensão de entrada: 9-24VDC

Corrente em modo inativo: 8mA @ 12V

Corrente em modo de comunicação: 110mA @ 120 V

Antena

Externa

Ganho: >0dB

Potência de entrada >2W

A interface com o modem é realizada através de 4 conetores apresentados na figura

seguinte.

Figura 108 - Conetores utilizados para interface com o modem.

Características de interface:

4 I/O de prepósito geral

Áudio analógico

9 pinos D-Type para o conetor RS-232

Fêmea SMS, 50 ohm conetor RF

RJ11 / 6 pinos analógicos

-Entrada/Saída de áudio

-GPIOs

Conetor de energia, 4 pinos

Conetor SIM, 3v com tempo real de

deteção

A.3 Características do recetor GPS FGPMMOPA6B

As características do Receiver GPS FGPMMOPA6B são apresentadas na

seguinte tabela.


Duarte Fernandes

136

Tabela 26 - Características do receiver GPS.

Características Gerais Chipset MTK MT3329

Frequência L1, 1575.42MHz

C/A Code 1.023MHz

Canais 66 Canais

SBAS WAAS, EGNOS, MSAS, GAGAN suportado

DATUM WGS84 (por defeito), Tokyo-M, Tokyo-A

CPU ARM7EJ-S

Dimensões

Físicas 16*16*6mm

Peso 6g

Características de desempenho

Exatidão da posição Sem ajuda: 3m

DGPS (RTCM, SBAS): 2.5m

Exatidão da velocidade Sem ajuda: 0.1m/s

DGPS (RTCM, SBAS): 0.05m/s

Exatidão da aceleração Sem ajuda: 0.1m/s2

DGPS (RTCM, SBAS): 0.05m/s2

Exatidão do tempo 100ns RMS

Sensibilidade Aquisição: -148dBm

Reaquisição: -160dBm

Tracking: -165dBM

Update 1HZ (por defeito)

Aquisição (em céu aberto)

Tempo de reaquisição <1s

Arranque a quente 1.0s

Arranque a frio 35s

Dinâmica

Altitude Máximo 18m

Velocidade Máximo 515m/s

Aceleração Máximo 4G

I/O

Sinal de saída 8 bits de dados, sem paridade e 1 stop bit

Baud Rate Por defeito é 9600bps

Protocolos NMEA 0183 V3.01 (GGA, GSA,GSV,RMC,VTG)

Comandos MTK NMEA

Interface de saída

Interface USB Compatível com USB 2.0

Interface UART TTL level serial port

Condições do meio ambiente

Temperatura de

funcionamento -40ºC até 85ºC

Temperatura de

armazenamento 50ºC até 90ºC

Humidade 5% até 95%

Suporte Tipo SMD. 10 pin

A.4 Comandos AT

O presente anexo apresenta uma análise dos principais comandos AT (listados na

Tabela 27) utilizados ao longo da implementação da comunicação com a unidade móvel

via GSM.


Duarte Fernandes

137

Tabela 27 - Principais comandos AT.

Comando Função

AT<CR> Testa comunicação

AT+IPR=<rate><CR> Define baud rate da porta série, rate pode tomar os

valores de 0, 300, 1200, 2400, 4800, 9600

AT+CPIN<CR> Verifica a existência e estado do cartão SIM.

AT+CPIN=****<CR> Fornece o código PIN do cartão SIM.

AT+CMEE=<valor><CR>

Habilita e desabilita o relatório de erros, onde o

parâmetro <valor> pode ser:

0-desabilita

1-habilita em formato numérico

2-habilita em formato de texto

AT+CSQ<CR> Verifica intensidade a qualidade do sinal.

AT+CREG<CR> Verifica estado da rede

AT+CMGF=<mode><CR> Definir o modo de escrita do SMS

AT+CNMI=<mode>,<mt>,

<bm>,<ds>,0<CR> Define comportamento quando recebidas SMS´s

AT+CMGS=<da><CR>

Envio de SMS

Esperar pelo carater “>”

Escrever corpo da mensagem

Terminar com CTRL-Z(0x1A)

AT+CMGD=<index><CR> Eliminar SMS, identificada pelo índice (parâmetro

<index>)

AT+CMGR=<index><CR> Ler SMS identificada pelo seu índice

AT+CMGL=<stat><CR>

Ler conjunto de SMS, onde <stat> pode ter os

seguintes valores:

REC UNREAD – mostrar SMSs recebidos não

lidos;

REC READ - mostrar SMSs recebidos lidos;

STO UNSENT – mostrar SMSs escritos não

enviados;

STO SENT – mostrar SMSs escritas enviados;

ALL – ler todos SMSs.

A.5 Dicionário de Dados

CREATE TABLE IF NOT EXISTS ìntelfleet_mydb`.`clientes_alvo` (

`cod_cliente` INT NOT NULL

AUTO_INCREMENT ,

`nome` VARCHAR(45) NOT NULL ,

`morada` VARCHAR(45) NOT NULL ,

`cidade` VARCHAR(45) NOT NULL ,

`codigo_postal` VARCHAR(45) NOT NULL

,

`NIF` VARCHAR(45) NOT NULL ,

`telefone` VARCHAR(45) NOT NULL ,

`fax` VARCHAR(45) NOT NULL ,

`latitude` VARCHAR(45) NOT NULL ,

`longitude` VARCHAR(45) NOT NULL ,

è_mail` VARCHAR(45) NOT NULL ,

`Tipo_Alvo_cod_tipo_alvo` INT NOT NULL

,

PRIMARY KEY (`cod_cliente`,

`Tipo_Alvo_cod_tipo_alvo`) ,

INDEX `fk_clientes_alvo_Tipo_Alvo`

(`Tipo_Alvo_cod_tipo_alvo` ASC) ,

CONSTRAINT `fk_clientes_alvo_Tipo_Alvo`

FOREIGN KEY (`Tipo_Alvo_cod_tipo_alvo` )

REFERENCES ìntelfleet_mydb`.`Tipo_Alvo` (`cod_tipo_alvo`

)

ON DELETE NO ACTION

ON UPDATE CASCADE

)ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS ìntelfleet_mydb`.`Driver` (

`num_driver` INT NOT NULL ,

`nome` VARCHAR(45) NOT NULL ,

`Morada` VARCHAR(45) NOT NULL ,

`data` DATE NOT NULL ,

`bi` VARCHAR(45) NOT NULL ,


Duarte Fernandes

138

`NIF` VARCHAR(45) NOT NULL ,

`veiculo_matricula` VARCHAR(9) NOT

NULL ,

`telefone` VARCHAR(45) NOT NULL ,

`caminho` VARCHAR(255) NULL ,

`nome_foto` VARCHAR(45) NULL ,

`foto` LONGBLOB NULL ,

PRIMARY KEY (`veiculo_matricula`,

`num_driver`) ,

INDEX `fk_Driver_veiculo1`

(`veiculo_matricula` ASC) ,

CONSTRAINT `fk_Driver_veiculo1`

FOREIGN KEY (`veiculo_matricula` )

REFERENCES ìntelfllet_mydb`.`veiculo`

(`matricula` )

ON DELETE NO ACTION

ON UPDATE CASCADE

)ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS ìntelfleet_mydb`.ùtilizadores` (

ÌD` VARCHAR(45) NOT NULL ,

`PASSWORD` VARCHAR(45) NULL ,

ÈMAIL` VARCHAR(45) NULL ,

`Nome` VARCHAR(45) NULL ,

`L_Nome` VARCHAR(45) NULL ,

Èstado’ INT NOT NULL

PRIMARY KEY (ÌD`)

)ENGINE = InnoDB;

CREATE TABLE IF NOT EXISTS intelfleet_`mydb`.`Servicos` (

`num_servico` INT NOT NULL

AUTO_INCREMENT ,

`data_inicio` VARCHAR(45) NOT NULL ,

`data_previsao_final` VARCHAR(45) NOT

NULL ,

`kms` VARCHAR(45) NOT NULL ,

`data_realizacao` VARCHAR(45) NULL ,

`realizado` VARCHAR(45) NULL ,

`latitude_dest` VARCHAR(45) NULL ,

`longitude_dest` VARCHAR(45) NULL ,

`Highways` VARCHAR(45) NULL

`Tolls` VARCHAR(45) NULL

ùtilizadores_ID` VARCHAR(45) NOT

NULL ,

`Driver_veiculo_matricula` VARCHAR(9)

NOT NULL ,

`Driver_num_driver` INT NOT NULL ,

`clientes_alvo_cod_cliente` INT NOT NULL

,

`clientes_alvo_Tipo_Alvo_cod_tipo_alvo`

INT NOT NULL ,

PRIMARY KEY (`num_servico`,

ùtilizadores_ID`, `Driver_veiculo_matricula`,

`Driver_num_driver`,

`clientes_alvo_cod_cliente`,

`clientes_alvo_Tipo_Alvo_cod_tipo_alvo`) ,

INDEX `fk_Servicos_utilizadores1`

(ùtilizadores_ID` ASC) ,

INDEX `fk_Servicos_Driver1`

(`Driver_veiculo_matricula` ASC,

`Driver_num_driver` ASC) ,

INDEX `fk_Servicos_clientes_alvo1`

(`clientes_alvo_cod_cliente` ASC,

`clientes_alvo_Tipo_Alvo_cod_tipo_alvo`

ASC) ,

CONSTRAINT `fk_Servicos_utilizadores1`

FOREIGN KEY (ùtilizadores_ID` )

REFERENCES ìntelfleet_mydb`.ùtilizadores` (ÌD` )

ON DELETE NO ACTION

ON UPDATE CASCADE,

CONSTRAINT `fk_Servicos_Driver1`

FOREIGN KEY (`Driver_veiculo_matricula` ,

`Driver_num_driver` )

REFERENCES ìntelfleet_mydb`.`Driver`

(`veiculo_matricula` , `num_driver` )

ON DELETE NO ACTION

ON UPDATE NO ACTION,

CONSTRAINT `fk_Servicos_clientes_alvo1`

FOREIGN KEY (`clientes_alvo_cod_cliente` ,

`clientes_alvo_Tipo_Alvo_cod_tipo_alvo` )

REFERENCES ìntelfleet_mydb`.`clientes_alvo` (`cod_cliente`

, `Tipo_Alvo_cod_tipo_alvo` )

ON DELETE NO ACTION

ON UPDATE NO ACTION )ENGINE = InnoDB;

Triggers

DELIMITER $

CREATE TRIGGER alter_matricula

AFTER DELETE ON veiculo

FOR EACH ROW

UPDATE Driver SET veiculo_matricula=’’

WHERE veiculo_matricula=OLD.matricula;

$

DELIMITER $

CREATE TRIGGER delete_historico_servicos

AFTER DELETE ON Servicos

FOR EACH ROW

DELETE FROM Historico_servico WHERE

Servicos_num_servico=OLD.num_servico;

$

DELIMITER $

CREATE TRIGGER insert_in_historico_servicos

FOR INSERT ON Servicos

FOR EACH ROW

BEGIN

DECLARE latitude_atual, longitude_atual

VARCHAR(45);


Duarte Fernandes

139

SELECT latitude, longitude

INTO latitude_atual, longitude_atual

FROM veículos

WHERE matriucula=NEW.

Driver_veiculo_matricula

INSERT INTO Historico_servico (latitude,

longitude, data, Servicos_num_servico)

VALUES (latitude=latitude_atual,

longitude=longitude_atual,

data=NEW.data_incio,

Servicos_num_servico=NEW.num_servico);

END $

DELIMITER $

CREATE TRIGGER alter_clientes

AFTER DELETE ON clients_alvo

FOR EACH ROW

UPDATE Servico SET

clients_alvo_cod_cliente=’’ WHERE

clients_alvo_cod_cliente=OLD.cod_cliente;

$

DELIMITER $

CREATE TRIGGER alter_utilizadores

AFTER DELETE ON utilizadores

FOR EACH ROW

UPDATE Servico SET utilizadores_ID=’’

WHERE utilizadores_ID=OLD.ID;

$

DELIMITER $

CREATE TRIGGER alter_driver

AFTER DELETE ON Driver

FOR EACH ROW

UPDATE Servico SET Driver_num_driver=’’

WHERE Driver_num_driver=OLD.num_driver;

$

A.6 Aplicação Posto de Trabalho

Requisições Assíncronas A.6.1

O processo de requisição assíncrona ao servidor inicia-se com a criação dos

ficheiros que pertencem ao lado do cliente (“’querys.php’ e ‘javascript.js’) necessários

para a realização das etapas 1, 2 e 3 da Figura 43. Após isto, é implementado no lado do

servidor um listener e todas as restantes tarefas apresentadas na etapa quatro, utilizando

a tecnologia PHP. Por fim, retorna-se ao lado do cliente e implementa-se o callback e a

funcionalidade que atualiza o DOM HTML pertencente à etapa cinco.

XMLHttpRequest

Antes de ser realizado o passo 1, é necessário verificar a compatibilidade do

objeto com o browser, pois nem todos os navegadores são compatíveis com o objeto

XMLHttpRequest, assim torna-se necessário verificar qual o navegador que o utilizador

utiliza para assim criar o objeto que permita efetuar requisições ao servidor. Nos

navegadores Firefox, Opera e Safari este objeto possui o nome de XMLHttpRequest

enquanto que no Internet Explorer chama-se de Microsoft.XMLHTTP.

A função ‘initiRequest()’ verifica qual o navegador e cria o objeto de acordo com o

browser. A Tabela 28 apresenta os parâmetros necessários durante a criação do objeto

XMLHttpRequest.


Duarte Fernandes

140

Tabela 28 - Parâmetros do objeto XMLHttpRequest.

Parâmetro Descrição URL Endereço de um recurso presente no servidor

Método HTTP GET ou POST

Tipo de interação Solicitações assíncronas

Na função ‘doCompelete()’ é identificado antes da construção do objeto qual a opção do

formulário que gerou a solicitação, pois os parâmetros variam consoante a opção. No

caso utilizado como exemplo (pesquisa de veículos), os parâmetros são:

URL;

o var url=“php/veiculocomplete.php?action=complete&id=2”+…;

Método GET;

Interação assíncrona;

o Req.open(“GET”,url,true);

Como a interação foi definida como assíncrona é necessário especificar uma chamada

de retorno. A função callback apresentada mais tarde é definida através da linha de

código ‘req.onreadystatechange = callback;’. A interação HTTP começa com

‘req.send(null);’, enviando a solicitação HTTP ao servidor.

Listener para manipulação da requisição

No âmbito da aplicação Posto de Trabalho o servidor deverá processar os

pedidos dos clientes como descrito na etapa quatro, procedendo do seguinte modo:

1. Aceder à base de dados e recolher os dados solicitados;

2. Criar um documento XML com os dados recolhidos;

3. Enviar ficheiro XML como resposta.

Tudo isto é implementado através da tecnologia PHP num ficheiro designado de

‘veiculocomplete.php’. Para realizar o primeiro passo é necessário criar uma conexão e

posteriormente uma consulta MySQL á base de dados.

De modo aceder à base de dados torna-se necessário criar uma conexão com o servidor

MySQL, para tal recorre-se às funções: mysql_connect (server, username, password) e

mysql_select_db(database).

A Tabela 29 descreve as diferentes variáveis passadas como parâmetros na função

mysql_connect()


Duarte Fernandes

141

Tabela 29 - Parâmetros recebidos pela função mysql_connect().

A função mysql_connect abre uma conexão com o servidor MySQL

Parâmetro Descrição

server Servidor MySQL, pode também incluir o numero da porta

username Nome do utilizador. Por norma é o nome do proprietário do processo

do servidor

password Password de acesso a base de dados

A Tabela 30 descreve as variáveis utilizadas como parâmetros quando invocada a

função mysql_select_db.

Tabela 30 - Parâmetros recebidos pela função mysql_select_db().

A função mysql_select_db seleciona uma base de dados MySQL

Parâmetro Descrição

database Especifica a base de dados presente no servidor MySQL

O código que implementa tudo isto é apresentado na Figura 109.

Figura 109 - Consulta dos dados requisitados utilizando os comandos SQL.

A última linha de código envia a consulta e retorna como resultado um resource, este

mantém uma referência a um recurso externo. Após obter o resultado da pesquisa é

necessário processá-lo. Para tal é utilizada a função mysql_fetch_array, esta retorna uma

matriz que corresponde à linha obtida e move o apontador interno para a linha seguinte.

A informação presente em cada linha é utilizada para instanciar um novo objeto

Veículo, estes são armazenados num array chamado ‘results’. A Figura 110 apresenta

as instruções utilizadas para realização dos passos aqui descritos.

Figura 110 - Aquisição dos dados resultantes de uma consulta à base de dados.

Com o código aqui apresentado temos o primeiro passo finalizado, tendo todas os

recursos necessários para o segundo e seguinte passo: criação de um ficheiro XML

(Figura 111). O tipo de conteúdo da resposta precisa ser definido como text/xml.


Duarte Fernandes

142

Figura 111 - Incorporar informação coletada num ficheiro XML.

O ficheiro ‘veiculocomplete.php’ gera um documento XML que contém informações

dos veículos da organização registados na base de dados.

Função callback

Na última etapa (5) é necessário definir uma função callback (ficheiro

‘javascript.js’) para manipular a resposta do servidor. Esta função é chamada

assincronamente durante a interação HTTP, isto acontece sempre que o objeto

readyState do XMLHttpRequest muda de estado. Nesta aplicação a função de retorno é

chamada de callback, definida como tal (na função ‘doCompletion’ apresentada

anteriormente ainda no presente capítulo) através da propriedade

XMLHttpRequest.onreadystatechange. A Figura 112 apresenta as instruções que

implementam a função callback.

Figura 112 - Função "callback" definida como função de retorno.

A variável readyState indica o estado de interação HTTP, quando tem o valor “4”

significa que a interação foi concluída. Os estados possíveis da interação são

apresentados na Tabela 31.


Duarte Fernandes

143

Tabela 31 - Estados da interação HTTP.

readyState (valor) Descrição do estado do objeto 0 Não inicializado

1 Carregando

2 Carregado

3 Interativo

4 Concluído

A função ‘parseMessages()’ manipula os dados XML recebidos. No código

desenvolvido a função só é chamada quando ‘readyState’ possui o valor “4” e o status é

“200” o que significa o sucesso da interação. Contudo antes de chegarmos a esta função

é necessário introduzir novos elementos (tabela) na página

‘www.intelfllet.com/querys.php’, bem como os seus ID’s para que possam ser

referenciados no ficheiro ‘javascript.js’. Esta função utiliza as várias funções auxiliares

descritas na Tabela 32.

Tabela 32 - Funções de auxílio utilizadas pela função ‘ParseMessages()’.

Função Descrição

clearTable() Torna invisível ao utilizador a tabela HTML e remove todas as entradas de

veículos existentes que tenham sido anteriormente criadas.

getElementY()

Desenvolvida para permitir localizar a posição vertical do elemento pai,

isto é necessário pois verificou-se que a posição deste pode variar

dependendo do tipo de browser

appendVeiculo() Implementada para inserir novas linhas na tabela com os dados do

veículo, insere um link no campo matricula do veículo

O link introduzido no campo matricula de cada linha (veículo) através da linha de

código:

linkElement.setAttribute("href", "php/veiculocomplete.php?action=lookup&id="

+ email);

Esta linha permite a realização de uma nova pesquisa quando clicada sobre o link (com

URL passada como parâmetro), que resulta na apresentação de todos os detalhes

armazenados sobre o veículo selecionado.

Por fim a função ‘parseMessages()’ que recebe como parâmetro um objeto

representativo do ficheiro XML (responseXML) proveniente do ficheiro

‘veiculocomplete.php’. A função verifica que tipo de pesquisa foi realizado através do

elemento select_form, com essa informação temos conhecimento de qual é a informação

que deve ser extraída do documento XML e poderá então realizar a extração dos

mesmos. No exemplo da pesquisa de veículos a função percorre o ficheiro e extrai todos

os dados de cada entrada (matricula, ano, marca, modelo, e localização), as tags

http://www.intelfllet.com/querys.php


Duarte Fernandes

144

<veiculo></veiculo> denunciam uma entrada. Os dados após extraídos são passados a

função ‘appendeVeiculo()’, resultando numa atualização dinâmica da tabela (elemento

complteTable).

Mapas do Google Maps A.6.2

Os passos a realizar com objetivo de incorporar mapas do Google na aplicação

Posto de Trabalho são os seguintes (pela ordem que são listados):

1. Carregar API do Google Maps

A URL contida na tag script é localização de um ficheiro JavaScript que carrega

todos os símbolos e definições necessárias para utilizar a API do Google Maps. Na mais

recente versão da API foi removida a necessidade de incorporar uma key única por

cliente, chave que era introduzida nesta mesma URL. Além deste é passado o parâmetro

sensor que indica se é utiliza um sensor para determinar a localização do utilizador

(falso para o presente caso). A Figura 113 apresenta o bloco de código que permite

carregar a API do Google Maps para a página HTML..

Figura 113 - Carregar para página HTML a API do Google Maps.

2. Mapear Elementos DOM

Para apresentar o mapa na página web, é necessário reservar espaço para ele

através da criação de um elemento div e da sua referência DOM (Document Object

Model).

<div id="map_canvas" class="button_all">

A linha de código apresentada como exemplo define um <div> chamado ‘map_canvas.

3. Instanciar Objeto Map

A classe JavaScript que representa um mapa é a classe Map, este objeto define

um único mapa na página. No código anterior foi criada uma nova instância da classe

utilizando o operador JavaScript new. Ao criar uma nova instância do mapa,

especificamos um nó DOM (<div>) como sendo um recipiente para o mapa. Os nós

HTML são filhos do objeto JavaScript document, e obtém-se assim a referência a este


Duarte Fernandes

145

elemento (map_canvas) pelo método document.getElementById() apresentado na Figura

114.

Figura 114 - Criação de uma instancia da classe Map.

Este código define uma variável chamada ‘map’ e atribui-a a um novo objeto Map. A

função ‘google.maps.Map()’ é um construtor, sua nomenclatura, parâmetros e descrição

é apresentada na Tabela 33.

Tabela 33 - Construtor google.maps.Map().

Construtor Descrição

Map(Div:Nó, opts?:MapOptions)

Cria um novo mapa dentro do container HTML

fornecido (div). Outros parâmetros podem ser

passados (opcional) do tipo MapOptions no

parâmetro opts.

4. Configurar o Mapa

Antes de instanciar o objeto Map é necessário criar o objeto MapOptions que

contém as variáveis de inicialização do mapa. As variáveis inicializadas são: zoom

especifica o nível de zoom apresentado no mapa; Center, para centrar o mapa num

ponto específico, para tal foi criado um objeto LatLng para manter esta localização

passando as coordenadas do local na ordem {latitude, longitude}; mapTypeId, define

especificamente o tipo de mapa inicial, foi definido o tipo ROADMAP que consiste no

padrão por defeito do Google Maps. A Figura 115 implementa este último passo

durante o processo de inclusão de mapas na presente aplicação.

Figura 115 - Configuração do objeto Map.

5. Carregar o Mapa

Durante a apresentação da página, o DOM é criado e todas as imagens e scripts

externos são recebidos e incorporados no objeto document. Para garantir que o mapa é

colocado na página só depois de esta ter sido totalmente carregada, só executamos a

função ‘MAP_INIT()’ presente no ficheiro ‘javascript.js’ que cria o objeto Map depois

de o elemento <body> da página ter recebido um evento onload. Isto evita


Duarte Fernandes

146

comportamentos imprevisíveis e oferece-nos maior controlo sobre como e quando o

mapa é desenhado.

<body onLoad="init()">

A.7 Funcionalidades do Posto de Trabalho

A.7.1 Visualização da Posição Geográfica do Veiculo

Para adicionar um link num dado campo (matrícula) na tabela HTML foi

implementado o seguinte código:

linkElement.setAttribute("href","javascript:MAP_POINT("+lat+","+long+","+se

rv+","+fg+")");

A linha de código anterior presente na função ‘appendVeiculo’ cria o link que é uma

referência à função ‘MAP_POINT()’ que recebe como parâmetro variáveis com os

valores da latitude, longitude, estado de serviço e data que corresponde a posição

geográfica. O utilizador ao clicar na matrícula ira gerar um evento que executará a

função ‘MAP_POINT’, no fluxograma da Figura 46 é apresentado o fluxo de

informação executado quando selecionado um veículo no mapa pelo utilizador.

Para realizar a geocodificação inversa é utilizado o objeto Geocoder que suporta

geocodificação reversa diretamente, ou seja, em vez de fornecer um endereço sobre a

forma de texto é fornecido separados por vírgula a latitude e longitude no parâmetro

‘LatLng’.

geocoder.geocode({'latLng': myLatlng}, function(results, status);

Na utilização do objeto Geocoder na linha anterior foi ainda adicionado uma função

com parâmetros, isto se deve ao facto do acesso ao serviço de geocodificação ser

assíncrono, pois a API necessita de efetuar uma chamada a um servidor externo por essa

razão é necessário fornecer um método callback para processar o resultado após a

conclusão do pedido. Um dos parâmetros passados pela função, o status contém o status

da solicitação e armazena valores que indicam o que poderá ter falhado numa

geocodificação. A variável satus poderá conter os seguintes valores:

"google.maps.GeocoderStatus.OK" indica que nenhum erro ocorreu; o endereço

foi analisado e pelo menos um geocódigo foi retornado.


Duarte Fernandes

147

"google.maps.GeocoderStatus.ZERO_RESULTS" indica que o geocódigo teve

êxito, mas não retornou resultados. Isso pode ocorrer se o geocódigo passou

um address ou latlng não existente em um local remoto.

"google.maps.GeocoderStatus.OVER_QUERY_LIMIT" indica que você

ultrapassou a sua cota.

"google.maps.GeocoderStatus.REQUEST_DENIED" indica que a sua

solicitação foi negada, normalmente por falta de um parâmetro sensor.

"google.maps.GeocoderStatus.INVALID_REQUEST" normalmente indica que a

aplicação ultrapassou o número de solicitações dentro do prazo permitido.

Quando o processo retorna resultados ele necessita de inseri-los numa matriz, a variável

‘results’ passada como parâmetro na função de retorno é uma matriz que irá armazenar

os resultados. Um dos campos dessa matriz designa-se de formatted_address

(results[1].formatted_address), consiste numa string com o endereço legível do local.

Apesar de ser possível a resposta conter vários resultados é sempre selecionado para

fins de apresentação na janela de informação o primeiro, pois se verificou em testes

realizados que os endereços são retornados do mais especifico para o menos.

Para finalizar a implementação da função ‘MAP_POINT’ resta apenas inserir um

marcador. Os marcadores identificam pontos no mapa, o seu construtor

google.maps.Marker usa um google.maps.LatLng e objetos myOptions opcionais como

argumento, no contexto da aplicação este só é inserido no mapa caso a geocodificação

seja realizada com sucesso e que pelo menos um resultado tenha sido obtido, esta

verificação necessita de ser realizada dentro do scope da função de retorno.

A.7.2 Serviços Terminados

O objeto ‘DirectionsRequest’ inclui parâmetros necessários para a geração da

rota, estes encontram-se descritos na Tabela 34.


Duarte Fernandes

148

Tabela 34 - Parâmetros a incluir no objeto ‘DirectionsRequest’ e entidade onde estão armazenados os valores

com que estes são iniciados.

Parâmetro Descrição Valor atribuído Tabela na B.D origin Especifica o local de início

para calcular a rota

Posição atual do veículo Tabela ‘veiculos’,

campos ‘longitude’ e

‘latitude’

destination Especifica localização final Localização do Cliente ‘cliente_alvo’, campos

‘latitude’ e ‘longitude’

travelMode Especifica modo de transporte google.maps.TravelMod

e.Driving

---

Waypoints[] Alteraram uma rota através do

seu encaminhamento através

do local especificado (s)

null ---

provideRouteAlternatives Especifica se o serviço poder

fornecer mais do que uma

alternativa de rota na resposta

false ---

avoidHighways Indica se a rota calculada deve

evitar estradas principais

Valor indicado aquando

a criação do serviço

‘Servicos’, campo

‘Highways’

avoidTolls Indica se a rota calculada deve

evitar estradas com portagem

Valor indicado aquando

a criação do serviço

‘Servicos’, campo

‘Tolls’

Os pontos extraídos do ficheiro XML são utilizados para especificar os waypoints dentro

do objeto ‘DirectionsRequest’. Estes pontos de passagem permitem calcular a rota

através de locais adicionais. Um waypoint é composto pelos seguintes campos:

Location: especifica o seu endereço;

Stopover: (true) indica se é uma passagem obrigatória da rota ou uma

preferência de passagem de rota a gerar (false).

O código implementado presente na Figura 116 demonstra como é utilizado array

waypoints para o cálculo da rota percorrida pelo condutor. Os diferentes pontos

geográficos são extraídos do ficheiro recebido e armazenados no array, a função

indicada como callback () no instante que é configurada a requisição assíncrona realiza

esta tarefa. Para a criação dos waypoints são percorridas todas estes pontos armazenados

no array e criado o objeto google.maps.LatLng que é armazenado no array waypoints.


Duarte Fernandes

149

Figura 116 - Geração de rotas com passagem em pontos de referência utilizando API do Google Maps.

A solicitação ao servidor retorna um objeto ‘DirectionsResult’ e um código

‘DirectionsStatus’. Este último indica se a solicitação foi realizada com sucesso e

permite apresentar ao utilizador quando ocorre um erro e o seu motivo. Para exibir o

primeiro objeto ao utilizador, através de um ‘DirectionsRenderer’ foram realizados os

seguintes passos:

1. Criar um objeto ‘DirectionsRenderer’;

2. Invocar ‘setMap()’ para vincular lo ao mapa passado;

3. Chamar ‘setDirections()’, passando o ‘DirectionsResult’ assim será

automaticamente atualizado o mapa vinculado.

A.7.3 Verificação de rotas percorridas

A estratégia implementada é possível a partir da exploração do objeto recebido

como resposta da solicitação da rota, DirectionsResult. Este objeto é composto apenas

pelo campo, Routes[] que contêm um conjunto de objetos DirectionsRoute,

correspondendo a diferentes rotas. O objeto alocado na primeira posição do array é

escolhido e utilizada sua informação para validar a execução de um serviço, é utilizado

só e apenas esse objeto, pois assim garante-se que é a mesma rota que é apresentada ao

condutor aquando a realização da tarefa. No objeto interessa-nos o campo legs que

contém um array de objetos DirectionsLeg, cada um contém informação de partes do

trajeto (leg), quanto existe pontos de passagem a rota poderá se dividir em legs. Cada


Duarte Fernandes

150

leg consiste numa série de DirectionsSteps, este objeto possui informação acerca de

cada etapa (step) da leg. Com a informação dos steps torna-se possível calcular a

distância entre este e a posição do veículo, pois entre outras informações temos a

necessária para o cálculo, start_location (contém as coordenadas geográficas sobre a

forma de objeto LatLng do ponto inicial do step).

A.8 Aplicação Terminal do Condutor

A.8.1 Declarar Atividades

Quando definimos uma atividade temos de a estender como já referido à classe

Activity e implementar obrigatoriamente o método OnCreate (invocado sempre que é

iniciada a atividade) como realizado no bloco de código apresentado na seguinte figura.

Figura 117 - Implementação do método onCreate da classe Activity.

O método setContentView permite associar a atividade à tela/layout, a classe

R.layout.login esta definida no ficheiro R.java, este é gerado automaticamente

vinculando constantes com os recursos desejados na aplicação.

A base de uma aplicação Android define-se no ficheiro AndroidManifest.xml (Figura

118), este ficheiro é obrigatório e fica presente na pasta da raiz do projeto.

Figura 118 - Exemplo da estrutura do ficheiro Android Manifest.xml.

Cada atividade implementada para a presente aplicação deve possuir uma entrada neste

ficheiro entre as tags <activity> e </activity>


Duarte Fernandes

151

A.9 Circuitos e Esquemáticos da Unidade Móvel

A.9.1 Placa desenvolvida

Todos componentes físicos abordados durante a implementação da ferramenta

são interligados numa placa desenvolvida em PCB visível na Figura 119, obtendo-se de

forma compacta o sistema de comunicação entre os diferentes componentes.

Figura 119 - Aspeto físico da placa desenvolvida.

Unidade de Processamento

O microcontrolador adotado necessita de um cristal com valores entre 16 MHz o

que implica alguns cálculos aquando a escolha do baudrate das portas EUSART.

[ ]

Utilizando a fórmula apresentada acima e para um baud rate de 9600 bps, pode-se

calcular o valor a utilizar na função de configuração da porta.

bps


Duarte Fernandes

152

Para um cristal de 16MHz e para um baudrate de 9600bps o valor a utilizar na equação

é 25, o que impõe uma percentagem de erros de transação igual 0,16%. Assim pode-se

afirmar que o cristal escolhido em termos de utilização da EUSART, possui um

excelente aproveitamento pois o erro é muito reduzido.

Receiver GPS

Na Figura 120 é apresentada a montagem implementada aquando a utilização do

Receiver GPS.

Figura 120- Montagem do receiver GPS.

Conversor Step-Down

A utilização desta fonte comutada surge da necessidade de extrair da fonte de

energia/bateria do veículo (12V-24V) tensões necessárias para alimentar os

componentes de hardware (Receiver e módulo GPS), que requer 5V e a unidade de

processamento 3.3V. A tensão pretendida é obtida variando a resistência Rset existente

no circuito envolvente. A Figura 121 demonstra a fonte comutada assim como a

montagem típica implementada na placa desenvolvida.


Duarte Fernandes

153

Figura 121 - Esquema de ligação da fonte comutada PTN78060W.

Circuitos Auxiliares

Estes circuitos são utilizados devido às tensões nominais do microcontrolador

ser de 3.3V, enquanto os componentes de hardware que comunicam via série com a

unidade móvel utilizam uma tensão nominal de 5V.

Para compensar o desnível de tensão foram implementados dois circuitos, devido à

comunicação ser bidirecional No envio de dados do microcontrolador para os

componentes é necessário elevar a tensão de 3.3V para 5V, tarefa realizada pelo circuito

da Figura 122.

Figura 122 - Circuito elevador de tensão.

Por sua vez, na transmissão de dados no sentido dos componentes para o

microcontrolador é apenas necessário descer o nível de tensão para 3.3 V, o que pode

ser realizado por um simples divisor de tensão de duas resistências como apresentado na

Figura 123.


Duarte Fernandes

154

Figura 123 - Divisor de tensão como meio de baixar o nível de tensão.

Sistema de Bloqueio

O circuito implementado para o corte da corrente da bomba de gasolina é

apresentado na Figura 124.

Figura 124 - Circuito de bloqueio do veículo.

A.9.2 Esquemático em Eagle

A seguinte figura apresenta o esquemático em Eagle da placa desenvolvida no

presente projeto.


Duarte Fernandes

155

Figura 125 - PCB desenvolvida para a Unidade Móvel.

A.9.3 GPIO

Levantamento do I/O disponível na unidade de processamento e a respetiva

atribuição ao hardware descrito na Tabela 35.

Tabela 35 - Pinos do microcontrolador utilizados.

Port Map Número do

pino

Descrição do

Pino Descrição Hardware

RE3 1 Vpp/MCLR Pinos para programar a PIC com o

PICKit

Programador

RB6 39 PGC

RB7 40 PGD

CR6 25 TX1/CK1 TX USART 1 Módulo GSM RC7 26 RX1/DT1 RX USART 1

RD6 29 TX2/CK2 TX USART 2 Receiver GPS RD7 30 RX2/DT2 RX USART 2

RB7 33

Pin I/O

RED

RGB RB6 34 GREEN

RC0 35 BLUE

RB4 37 Fix GPS Receiver GPS

RD5 28 Relé S.Bloqueio

Documents

Universidade do Minho - intranet.dei.uminho.ptintranet.dei.uminho.pt/gdmi/galeria/temas/pdf/50102.pdf · Computadores Trabalho efetuado sob a orientação do ... geographically scattered