A unidade de comunica¸c˜ao ´e respons´avel pelo estabelecimento de um canal para trans- miss˜ao de dados entre o m´odulo de controlo, neste caso o m´odulo mXS4, e uma aplica¸c˜ao servidor. Esta ´ultima ser´a explicada na sec¸c˜ao seguinte.
Para melhor se compreender a contextualiza¸c˜ao com o conceito Machine-to-Machine deve consultar-se o Apˆendice B onde se apresenta um estudo sobre esta mesma tem´atica.
5.2.1 Cinterion XT65
O m´odulo utilizado para comunica¸c˜ao foi o XT65 da Cinterion. Um estudo das suas potencialidades foi levado a cabo por forma a compreender a sua aplicabilidade no projecto. Este m´odulo m´ovel que combina tecnologia GSM e GPS pode ser configurado para utilizar GPRS (General Packet Radio Service) que ´e uma tecnologia entre 2G e 3G, vulgarmente designada 2.5G. Este servi¸co garante uma certa qualidade de servi¸co (QoS) e apresenta taxas
de transferˆencia na ordem dos 56 a 114kbps. Este servi¸co estende as capacidades do CSD (Circuit Switched Data) e passa a possibilitar:
• Internet sempre on; • MMS;
• WAP (aplica¸c˜oes Internet para smart devices); • Servi¸co P2P;
Na Figura 5.6 [29] apresenta-se um diagrama de blocos que demonstra, de uma forma l´ogica, as funcionalidades do XT65.
Figura 5.6: Vis˜ao geral do XT65.
Um estudo do manual foi realizado de onde se efectuou um levantamento de caracter´ısticas mais importantes como apresentado na Tabela 5.1
Este m´odulo apresenta uma interface el´ectrica de 80 pinos Board-to-Board para possibilitar a integra¸c˜ao em solu¸c˜oes electr´onicas. Um m´odulo de expans˜ao para o XT65 foi utilizado por forma a permitir a utiliza¸c˜ao das unidades de comunica¸c˜ao. Este m´odulo de expans˜ao, UniCard AnyWhere, foi desenvolvido pela Micro I/O - Servi¸cos de Electr´onica, Lda.4, e mais uma vez por quest˜oes de propriedade e confidencialidade, detalhes t´ecnicos n˜ao ser˜ao aqui disponibilizados. Importa apenas saber que esta placa permite utiliza¸c˜ao de comunica¸c˜ao USB, UART, inser¸c˜ao de cart˜ao SIM e a alimenta¸c˜ao por bateria.
Tabela 5.1: Levantamento de caracter´ısticas do m´odulo Cinterion XT65. Caracter´ıstica Implementa¸c˜ao
Geral
Bandas de Frequˆencia Quad Band: GSM 850/900/1800/1900M Hz Alimenta¸c˜ao 3.3V a 4.5V
Temperatura de opera¸c˜ao −30oC a +60oC
F´ısico Dimens˜oes: 34mm× 59mm × 3.5mm
Peso: < 10g
RoHS Todo o hardware completamente
de acordo com as directivas RoHS da EU.
Dados: GSM/GPRS GPS
Exactid˜ao da posi¸c˜ao 2.5m CEP, 5.0m SEP
With DGPS/SBAS: 2.0m CEP, 3.0m SEP Tempos de Start-Up Hot start < 3.5s
Warm start 33s, m´edia Cold start 34s, m´edia Software
Java platform Java Virtual Machine com APIs para AT Parser, JDK Version: 1.4.2 09 Interface S´erie, FlashFileSystem
e Stack TCP/IP. AT commands
TCP/IP stack
IP addresses IP version 4
Na Figura 5.7 apresenta-se uma fotografia do conjunto XT65 com o m´odulo UniCard AnyWhere, que foi o sistema utilizado para desenvolver aplica¸c˜oes para o XT65.
Figura 5.7: Fotografia do sistema de desenvolvimento para o m´odulo XT65.
radora Optimus5.
5.2.2 Aplica¸c˜ao cliente
Na estrutura que se apresentou na Figura 5.1 a aplica¸c˜ao cliente trata-se da aplica¸c˜ao respons´avel de, atrav´es do canal de comunica¸c˜ao com o servidor, enviar dados dos sensores referentes ao sistema de pain´eis solares t´ermicos, e em simultˆaneo, respons´avel por receber comandos provenientes de um terminal capaz de aceder ao canal de comunica¸c˜ao cliente- servidor. As propriedades de comunica¸c˜ao ser˜ao devidamente esclarecidas mais `a frente.
Importa, para j´a, descrever a forma como foi implementada a aplica¸c˜ao cliente, de um ponto de vista funcional, contudo, n˜ao de um ponto de vista de implementa¸c˜ao.
Como foi referido anteriormente, o XT65 incorpora m´aquina virtual de Java, raz˜ao pela qual a aplica¸c˜ao cliente foi desenvolvida nesta linguagem de programa¸c˜ao. Deve ainda notar-se que a aplica¸c˜ao cliente ficou ao encargo do m´odulo XT65, que sendo um m´odulo de comu- nica¸c˜ao, com capacidade de processamento, faria sentido ser o respons´avel por lidar com o processamento relacionado com a transmiss˜ao e recep¸c˜ao de dados.
A solu¸c˜ao implementada passou por cumprir um conjunto de regras estabelecidas, que tentam garantir o funcionamento do controlo, mesmo perante a falha do sistema de comu- nica¸c˜ao:
• O m´odulo de controlo, mXS4, n˜ao pode, em situa¸c˜ao alguma, ficar com a capacidade de processamento comprometida devido `a transmiss˜ao de dados para o XT65;
• O XT65 dever´a ser capaz de identificar o mXS4 e este ´ultimo dever´a identificar-se perante um pedido de identifica¸c˜ao;
• O XT65 deve identificar-se no servidor;
• Em caso de falha, o XT65 dever´a ser capaz de se re-conectar, quer ao mXS4 quer ao servidor;
• Uma falha do XT65 n˜ao dever´a influenciar o funcionamento do mXS4;
• Para o m´odulo mXS4 deve ser apenas enviada informa¸c˜ao que a ele lhe corresponde; Portanto, toda a aplica¸c˜ao cliente foi projectada tendo em considera¸c˜ao este conjunto de regras, e criando um conjunto de comandos e op¸c˜oes para troca de dados entre os m´odulos envolvidos (mXS4, XT65 e servidor) a apresentar mais adiante.
No diagrama da Figura 5.8 apresenta-se o procedimento base da aplica¸c˜ao cliente.
Figura 5.8: Aplica¸c˜ao cliente.
O conte´udo das mensagens vindas do mXS4 n˜ao ser´a modificado pelo XT65 e ser˜ao en- viadas para o servidor, sendo o servidor o respons´avel pelo manuseamento da informa¸c˜ao. A cadˆencia `a qual as mensagens s˜ao enviadas ´e definida pela cadˆencia `a qual as mensagens s˜ao enviadas por parte do mXS4.