Hunter GE Drive Test (Application)

quinta-feira, 16 de junho de 2011 18:08:00 Categories: Access Drive Test Hunter
Rate this Content 1 Votes

Após vários tutoriais voltados a familiarização com a estrutura do Hunter, continuamos agora com aplicações mais práticas, prontas para serem usadas no dia a dia.

 

 

Hoje veremos a aplicação responsável pela criação de arquivos KMZ a partir de arquivos Texto ou Planilhas do Microsoft Excel, exportadas a partir de qualquer Software de Drive Test.

Quem conhece o poder das ferramentas customizadas vai se surpreender como, com um pouco de criatividade, conseguimos soluções simples mas que não deixam nada a desejar em relação a várias aplicações comerciais existentes.

A aplicação de hoje, conforme falamos, é sobre análise de Drive Test. Entretanto, envolve uma grande quantidade de dicas, e boas práticas que você pode utilizar em seu trabalho.

 

Objetivo

Apresentar a solução do Módulo Hunter GE Drive Test. Fica mais fácil desta vez apresentar o objetivo mostrando a interface atual do módulo em questão.

Sempre seguindo a metodologia apresentada até hoje, a interface nos permite interagir com os dados brutos exportados do Drive Test (no formato TXT ou XLS), e com um simples clique, gerar os arquivos no formato do Google Earth, de acordo com as configurações desejadas.

As configurações são apresentadas em forma de tabela (onde os dados são editáveis). Também é possível ajustar o BIN, que permite a geração de um arquivo mais leve (menos pontos) ou mais detalhado (todos os pontos). Veremos mais detalhes sobre isso mais adiante.

Também temos a opção através da interface de abrir as pastas de entrada (Data – onde colocamos os arquivos TXT/XLS) e também de saída (Output – onde os arquivos KML/KMZ são gerados) do módulo.

Um pequeno Help também está disponível, onde podemos ver por exemplo que os campos mais importantes são Indicator, Mouse Over?, e Plot?.

O campo 'Indicator' serve como referência para o Indicador desejado (RxLevel, EcIo, etc...). O campo 'Mouse Over' serve para informar se queremos que o valor de cada ponto seja mostrado quando o passamos o mouse sobre o mesmo. E o campo 'Plot' informa se esse Indicador, se presente no arquivo, deve ser plotado.

Os campos 'Technology' e 'AliasN' são campos de referência. Servem apenas para vizualizar a tecnologia, e para saber qual o nome ou nomes de campos esperados para serem plotados para cada Indicador.

Tudo fica um pouco mais claro quando praticamos, utilizando a ferramenta. Então vamos lá, e ver como tudo é feito.

 

Cenário

O nosso cenário, como já falamos, e primeiramente obter os dados de todos os Drive Tests num formato TXT ou XLS. A partir desse arquivo, plotar os dados no Google Earth, fazendo todos os tratamentos pertinentes.

A geração desses arquivos é um ponto importante, porém não é complicada. Infelizmente, não temos como demonstrar aqui como fazer para cada Software Existente, mas com certeza o que você utiliza lhe permite fazer isso.

Nota: se você precisar de ajuda, entre em contato (link na página Sobre), e enviamos o passo a passo para o seu Software específico.

Se você não realiza a coleta, mas simplesmente recebe os relatórios de uma empresa contratada, simplesmente peça que eles lhe enviem TAMBÉM os dados no formato TXT ou XLS.

 

Para ficar mais fácil de vizualizar, veja a lista de campos.

 

Os campos mais importantes, naturalmente, são Latitude e Longitude, por motivos óbvios.

O campo DateTime também é importante e desejável, embora não seja imprescindível. Se esse campo estiver presente, e contiver a informação da Data, a mesma será usada na nome do arquivo KML/KMZ, ou seja, você saberá a data exata quando o Drive Test for realizado.

Por fim temos os demais campos. Por exemplo, se o arquivo tiver o campo 'RxLev (Full)', a aplicação vai plotar os dados do nível de sinal GSM. Se o indicador estiver no arquivo – com esse nome padrão – e também for marcado para ser tratado – campo 'Plot' – o mesmo será gerado. Simples assim.

Para cada Indicador presente, os dados podem ser gerados. Pode ter um ou todos, depende dos campos que você exportou ou não. E uma coisa importante: você não precisa processar cada arquivo um a um. Por exemplo, se você colocar 3 arquivos TXT ou XLS, serão gerados 3 arquivos KML/KMZ, contendo os indicadores correspondentes – presentes – em cada arquivo.

Observação: Você deve notar que além de um nome padrão, mundialmente utilizado para cada Indicador, temos um ou dois outros. São variações, mas que trazem o mesmo resultado.

Fica mais fácil de entender essa liberdade através de um exemplo. Se o nome de um dos campos exportados for 'RxLev (Full)' ou 'RxLev (Full) (dBm)', tanto faz, o Indicador plotado será o RX_LEVEL_FULL. Isso serve apenas para casos em que, por algum motivo, você receba arquivos com essas variações. Mas não se precocupe com isso, e certifique-se apenas de exportar os dados com os nomes do Alias1.

 

Estrutura de Arquivos

A estrutura básica do Hunter você já conhece dos demais tutoriais, e se vem acompanhando a evolução, já deve ter os diretórios desse módulo já criado.

De qualquer forma, segue a estrutura básica.

 

O diretório 'Script' contém o Script, que nesse caso é a nossa aplicação. O diretório 'Data', como falamos, é o local onde você pode armazenar todos os arquivos exportados TXT/XLS. O diretório 'Output' conterá todos os arquivos KML/KMZ gerados. O diretório 'Help' contém arquivos de apoio, como por exemplo planilhas auxiliares – template dos dados exportados, configuração de ranges para cada indicador e legendas do mesmo, etc. E o diretório 'icon', comum a todos os módulos Hunter GE (Como o de Performance – KPI – e Parameters); esse diretório contém as imagens auxiliares que a aplicação acessa para uma apresentação profissional dos dados.

Sem mais demoras, vamos falar da aplicação com mais detalhes.

IMPORTANTE: apresentaremos as formas criadas por nós para obtenção da solução. Isso inclui uma série de macetes e considerações, que com criatividade nos permitem um resultado prático e funcional. É claro que sempre podem haver melhorias, algumas inclusive já previstas e em desenvolvimento. Você mesmo poderá estender a aplicação para um nível ainda maior e adequada para suas possíveis necessidades. De qualquer forma, certamente vale como aprendizado para se entender como tudo pode ser feito.

 

A Aplicação

Vamos explicar primeiro cada um dos objetos (tabelas, consultas, etc.) do banco de dados, e depois mostrar o que é feito através de código VBA (que não passa de 300 linhas).

 

Tabelas

Vamos começar com a tabela Base: 'DriveTest'. Os dados do arquivo TXT ou XLS são primeiramente importados para a mesma.

E aqui já temos a primeira dica: para importar os arquivos de um arquivo Texto (TXT), precisamos informar ao Access quais são os seus campos. Mas o que fazer, se o arquivo contiver alguns campos a mais, como 'Sequence No'?

De outra maneira, se fossemos importar os dados através da Transferência de Texto, teríamos necessariamente que forçar o arquivo a ter sempre e exatamente os mesmos campos e formato.

Mas quando importamos um arquivo XLS para o Microsoft Access, não precisamos de uma Especificaçao Fixa. E se tivermos uma tabela (como a 'DriveTest') que já tenha praticamente todos os campos possíveis de estarem presentes, basta importar para a mesma. Os campos a mais ficam em branco, mas os nossos desejados são importados corretamente.

Assim, mesmo que tenhamos os arquivos estejam todos no formato TXT, a aplicação vai salvar cada um temporariamente como XLS.

Então, continuando, os dados do novo arquivo XLS são transferidos (via código) do diretório 'Data' para a tabela, um por vez, dependendo da quantidade de arquivos sendo processados no momento.

 

Temos algumas tabelas Auxiliares. Uma delas é a 'RF_PARAMETER_CONTROL'. Essa tabela contém dados auxiliares da nossa rede, que são acessadas pela aplicação. No exemplo, caso o campo 'CellId' esteja presente no arquivo, podemos buscar o nome do setor dessa tabela.

Nota: RF_PARAMETERS_CONTROL é uma tabela padrão do Hunter Parameters, que reúne todos os principais parâmetros de configuração da rede para cada setor, como por exemplo BCCH, CI, BSC, entre vários outros. Essa tabela portanto deve ser vinculada a esse módulo, e sempre que for atualizada, os dados que acessamos por aqui também estão atualizados. Entretanto, replicamos a mesma parcialmente aqui apenas para facilitar.

Outras tabelas auxiliares – cuja finalidade entenderemos logo mais – contém correspondências de valores de BCCH GSM e PN CDMA com cores.

* Poderíamos utilizar o mesmo raciocínio para PSC UMTS. Entretanto, mais tarde vamos mostrar porque fizemos de forma um pouco diferente para ele. Nesse caso vamos ter a tabela 'DriveTest_PSC'.

Para terminar de apresentar as tabelas, vamos falar agora de mais uma dica.

Sabemos que o Google Earth trabalha com Estilos, ou seja, definindo um determinado estilo com um nome específico, você pode atribuir todas as suas características, como cor e imagem correspondente desse estilo. Depois, para cada ponto (Placemark) plotado, basta informar que ele tem aquele determinado estilo!

E podemos escrever todos os estilos nos arquivos gerados linha a linha no código. Mas quando temos uma grande quantidade de estilos, vale a pena escrever os mesmos 'on-the-fly', lendo os dados dessa tabela auxiliar.

Veja como exemplo, o estilo 'color001'. Se esse estilo for atribuído a um ponto no Google Earth, ele vai ter todas as propriedades do mesmo – uma vez que escrevemos no arquivo com o formato adequado!

Agora que conhecemos as nossas tabelas, vamos conhecer as consultas da nossa aplicação.

Veja que tudo é bem simples (Talvez você ainda não esteja familiarizado, mas com o tempo vai concordar que é).

 

Consultas

Começamos com a consulta 'qry_Aux_GE_Styles'. Basicamente os dados da tabela 'tbl_Aux_GE_Styles', filtrados apenas para os estilos desse módulo 'DriveTest'.

Nota: Você pode estar se perguntado, porque usar uma consulta, se a tabela atualmente contém apenas estilos, com propriedades apenas desse módulo. Bom, na verdade, a tabela 'tbl_Aux_GE_Styles' futuramente também residirá em um outro banco de dados. Foi replicada aqui somente para simplificar. Ou seja, no futuro, acessaremos essa tabela de outro banco, e a mesma conterá estilos para outros módulos. Assim, essa consulta filtra os dados desse módulo apenas.

Agora, quase finalizando, vamos falar de 3 consultas mais importantes.

'qry_DriveTest', 'qry_DriveTest_Coords' e 'qry_DriveTest_Coords_Thematic'.

A primeira consulta 'qry_DriveTest' é baseada na tabela 'DriveTest'.

 

Essa consulta faz o tratamento dos dados, mas nada muito complicado. O mais importante é saber que aqui são feitas as considerações (campos calculados) dos alias. Voltando a utilizar o exemplo das variações 'RxLev (Full)' ou 'RxLev (Full) (dBm)', o campo final desse indicador leva em conta se os dados estão em um ou outro – como se fosse uma soma dos mesmos. Novamente, isso não é crítico, e somente um workaround para um caso que provavelmente não vai aocntecer com você – não terá variações de nome de mesmo campo.

A consulta seguinte - 'qry_DriveTest_Coords' - já faz um pequeno ajuste, como falamos no começo, sobre o BIN. Utilizamos esse nome, mas na verdade fazemos uma aproximação bem simplificada – porém funcional. O nosso 'BIN' na verdade representa o número de casas decimais com a qual 'agrupamos' os dados de latitude e longitude.

O truque aqui é utilizarmos nessa consulta a consulta anterior 'qry_DriveTest' junto com a tabela 'Aux_BIN', que contém o BIN configurado. Assim, podemos agrupar os dados (Group By) Latitude e Longitude, arredondado para BIN casas decimais.

E todos os demais campos devem ser calculados como média (Average). Esse procedimento simples nos fornece diferentes plots – com mais ou menos pontos. Entretanto, você vai perceber que para uma vizualização macro, um plot com um BIN menor pode ser suficiente. O ganho aqui? Performance: menos pontos = muito mais leve e rápido de se analisar os dados.

Você pode por exemplo gerar plots com BIN menor para DriveTests muito extensos (muitos pontos), e somente usar o detalhado em situações mais específicas.

 

E por fim, a cosulta 'qry_DriveTest_Coords_Thematic'. Nessa consulta, criamos uma novo campo calculado para cada Indicador, com o nome do estilo que será atribuído a esse ponto, para cada indicador.

Por exemplo no ponto de Latitude/Longitude 37.3573/-122.0862, o RSCP foi de -94.6 dBm, e atribuímos o estilo temático 'color002'. Mas como fazemos isso?

Não é muito complicado – embora possa parecer, vendo a estrutura da consulta.

Temos basicamente dois casos.

O primeiro, para valores individuais. Nesse caso, simplesmente amarramos a consulta anterior 'qry_DriveTest_Coords' - que já tem os nossos dados quase prontos, e com o BIN calculado – a todas as consultas auxiliares com seus correspondentes estilos.

Fica mais fácil com exemplo do Aux_BCCH, para o GSM. Para cada BCCH da nossa consulta 'qry_DriveTest_Coords', quando houver um valor correspondente no campo 'BCCH' da tabela 'Aux_BCCH', colocamos o estilo que já pré-definimos nessa tabela!

 

E a segunda tematização, para ranges de valores. Para isso, utilizamos um campo calculado para cada indicador. Utilizamos a função IIF – a mesma do Excel.

Veja um exemplo por exemplo para Thematic_FER:

Thematic_FER:

IIf([FER]<=1),"color003"

IIf(([FER]>1 And [FER]<=2),"color012"

E assim por diante.

Bom, isso explica o funcionamento da aplicação, do ponto de vista de tratamento de dados.

Vamos só falar agora sobre a questão do PSC UMTS: Porque fizemos diferente de BCCH GSM e PN CDMA?

Na verdade, poderíamos utilizar a mesma solução que vamos mostrar agora para BCCH e PN.

Bom, imagine uma rede com inúmeros PSC. E suponha que você crie uma tabela auxiliar para cada um valor de PSC. E também, que definiu uma cor para cada um deles. O problema é que o range de cores distintas é pequena (no Hunter por exemplo, definimos 56, e mesmo assim com muita dificuldade).

Só que num Drive Test, você não tem todos os PSC da sua rede!

Por exemplo, se você tiver digamos 20 PSC, pode usar uma cor distinta para cada um deles: e aí, consegue ver de forma bem distinta a área de cobertura de cada setor.

Mas como fazer isso?

Aqui, mais um truque. Primeiro, a partir dos PSC presentes na tabela DriveTest, geramos uma tabela axuliar 'DriveTest_PSC'. Para isso, temos uma consulta 'Criar Tabela', que chamamos de 'qry_CREATE_tbl_DriveTest_PSC', e quando a mesma é executada, a nossa tabela é criada.

Isso é metade do caminho. Agora precisamos de alguma forma atribuir os estilos (cores) sequencialmente, para garatirmos distinção dos setores. E para isso, e concluindo sobre consultas por hoje, criamos uma consulta 'rank' no Access.

 

Essa consulta não é muito simples, e vamos explicá-la com detalhes em um breve tutorial na seção de dicas. Esse tipo de consulta é bem poderosa, e utilizamos em diversos outros módulos do Hunter, principalmente Performance/KPI.

Por enquanto, entenda apenas que a consulta gera um número sequencial para cada linha da consulta base. E simplesmente utilizamos esse número (valor) para preencher o nosso estilo – color001, color002, e assim por diante.

Assim, garantimos de forma simples que o PSC vai ser o mais distinto possível. (Como temos 56 cores no Hunter, só começamos a ter repetições a partir do rank 56 – e aí, a coincidência – setores próximos com o mesmo valor - também fica bem mais difícil de ocorrer!

 

Imagens Auxiliares

Nos tutoriais anteriores, você já aprendeu a utilizar imagens para conseguir o artifício de plotar cada ponto com as características desejadas (cor, ícone, etc). E também como mostrar a Legenda de cada arquivo.

É importante manter uma planilha padrão, com a definição de cada cor, e o seu respectivo valor e estilo.

Para cada uma dessas 56 cores foram criadas imagens, aramzenadas no diretório 'icon', e acessadas quando necessário.

Da mesma forma, para cada módulo, as legendas podem ser criadas e/ou modificadas.

 

Código VBA

Escrevemos os tutoriais do telecomHall no Microsoft Word. E no momento já percebemos que estamos na página 14!

Se fossemos passar por todo o código desse módulo, embora o mesmo não seja tão extenso, o tutorial ficaria extremamente extenso e cansativo.

De qualquer forma, não temos praticamente nada muito novo ou diferente dos códigos mostrados em outros tutoriais.

Se você desejar, entre em contato (página Sobre) e solicite ajuda para rotinas que você deseja que seja explicada em um próximo tutorial.

Para mostrar que nada é novo, veja por exemplo como escrevemos os estilos 'on-the-fly'.

Criamos a função 'PrintGEStyles'. Essa função recebe como argumentos o arquivo aberto (h) e o diretório onde estão as imagens (strIconDir). Em seguida, definimos o SQL da nossa tabela (strStylesQuery) para logo depois trabalhar com o Recordset dessa string SQL (rs_StylesQuery). Lemos os valores para variáveis, e depois escrevemos (Print) no arquivo.

E como sempre: o código deve ser totalmente comentado. Sempre.

 

Resultado

O resultado desse módulo, é o esperado. Plots para os mais diversos indicadores no formato KML/KMZ do Google Earth!

A seguir, alguns exemplos.

Bom, por hoje é isso.

 

Download

Para baixar os arquivos* deste tutorial, clique aqui.

* Observação: O Hunter SDK é o conjunto de ferramentas criadas e demonstradas no telecomHall – inlcuindo as Macros e Códigos. O Hunter SDK somente é enviado para Colaboradores Doadores, como forma de agradecimento pela contribuição realizada e reconhecimento do esforço dedicado. Clique aqui se desejar saber mais.

 

Conclusão

Vimos hoje como criar uma aplicação customizada utilizando o Microsoft Access para plotar Indicadores de Drive Test no formato KML/KMZ do Google Earth.

A aplicação completa e funcional, permite que o profissional aplique os seus próprios

Agradecemos a sua visita, e esperamos que as informações apresentadas possam servir de ponto de partida para suas soluções e macros.

Em especial, agradecemos aos colaboradores do telecomHall. Os arquivos desse tutorial já foram enviados, por favor verifiquem. Caso tenham tido algum problema no recebimento, por favor informem.