Monitoramento da frota de caminhões da Liquigás. Laboratório: LAC – Laboratory for Advanced Collaboration Coordenador: Markus Endler Nome: Rodrigo Azevedo Nunes Matrícula: 0512157

O projeto. Projeto envolvendo TecGraf e Liquigás. Atualmente a Petrobrás também está envolvida. Alguns caminhões da liquigás possui um dispositivo que constantemente envia informações sobre o caminhão, como localização, velocidade e alguns eventos ao servidor da liquigás que recebe as informações e faz uma análise. O monitoramento em tempo real pode ser visto na web pelos controladores. No início do projeto eram aproximadamente 20 caminhões com este dispositivo. Com essa quantidade, poucos problemas estavam sendo percebidos no servidor, porém esse número é esperado que chegue a aproximadamente 3000. A partir dessa preocupação, o TecGraf contratou o LAC para auxiliar no projeto.

O papel do LAC O objetivo era fazer uma análise de carga no servidor da Liquigás. Para isso, desenvolvemos um simulador do dispositivo que atualmente roda no caminhão. Este programa simula exatamente o funcionamento do dispositivo, inclusive utiliza rotas reais já utilizadas por alguns caminhões anteriormente. Com este programa, podemos simular diversos dispositivos rodando ao mesmo tempo e bombardeando o servidor com as informações de localização GPS, velocidade, etc. Através de uma análise dos Logs gerados pelo simulador, conseguimos gerar relatórios e informamos aos coordenadores do projeto como a atual arquitetura se comportaria com uma grande quantidade de caminhões rodando.

Fase de estudo Um dos requisitos do projeto era que o simulador deveria ser implementado na linguagem Lua, pois os dispositivos atuais estão sendo substituídos por dispositivos que vem com Lua embarcado (eLua) e o código do simulador sendo nesta linguagem, facilitaria posteriormente portá-lo para dentro do dispositivo em si. Como nós do LAC não tínhamos tido nenhum contato anterior com a linguagem, passamos por uma fase inicial de adaptação ao Lua. Outra etapa de estudo foi entender como funcionava toda a comunicação entre o dispositivo e o servidor. Informações como o formato da string enviada, como eram feitas as análises dessas informações, como funciona a obtenção de eventos por parte dos dispositivos, como agir em casos de falha no servidor ou na rede do próprio dispositivo, etc. Os eventos são informações extras que o motorista do caminhão envia ao servidor através dos dispositivos, tais como parada em cliente, horário de almoço, início da descarga do material, etc. Estas informações também devem ser analisadas pelo servidor.

O simulador Como foi descrito anteriormente, o simulador precisa montar uma string com informações de localização GPS, velocidade do caminhão, eventos ativados pelo motorista, além de simular zonas de problemas na comunicação com o servidor(seja problema no dispositivo, seja no servidor). Toda a simulação de uma viagem ficou guardada em um arquivo XML, onde temos todas essas informações. No início do programa, a primeira coisa a fazer é guardar todos estes dados em uma estrutura de tabela Lua para depois facilitar a obtenção. O XML é mais ou menos dessa forma:

<Cenario> <dispositivo id="8839"></dispositivo> <desconexao id='1'> <latitudeIni direcao='s'>2330.88380</latitudeIni> <longitudeIni direcao='w'>04645.73680</longitudeIni> <latitudeFin direcao='s'>2331.96500</latitudeFin> <longitudeFin direcao='w'>04646.73580</longitudeFin> </desconexao> <gps> <horario>07:05:32</horario> <latitude direcao="S">2332.5017</latitude> <longitude direcao="W">04645.8365</longitude> <velocidade>000</velocidade> <data>17/02/2009</data> </gps> <ev> <horario>07:59:15</horario> <evento codigo="03"> <subevento codigo="00" /> </evento> <odometro>0086769.9</odometro> </ev> <horario>07:06:02</horario> <latitude direcao="S">2332.5089</latitude> <longitude direcao="W">04645.8506</longitude> <velocidade>005</velocidade> </Cenario>

O Simulador O simulador então funciona da seguinte maneira: De 30 em 30 segundos uma thread controla a obtenção da localização GPS, buscando na tabela de GPSs o próximo a ser enviado e concatenando com a string que já preparada anteriormente. De 1 em 1 minuto uma segunda thread controla o envio da string para o servidor. Porém, antes de realizar o envio, ela verifica se está dentro de alguma área de desconexão. Se estiver, acumula a string para ser enviada em uma próxima conexão. Caso contrário, envia a string. Também há uma terceira thread que guarda o horário do próximo evento que deve ocorrer. Como um evento pode ocorrer há qualquer momento, o tratamento do tempo não pode ser feito por intervalos e sim para um horário pré-determinado. Qualquer problema na comunicação é percebida pelo simulador e além de acumular a string, o mesmo guarda esta informação no Log. O cálculo da ocorrência de um evento é de acordo com a sua posição dentro do XML. Assim, o simulador também calcula os horários que devem ocorrer eventos ao início da simulação. Qualquer problema em uma das threads (Timers), o programa aborta e escreve na tela o erro ocorrido.

Os testes Durante os testes, utilizamos uma arquitetura com 3 máquinas de igual desempenho, cada uma rodando um número variável de processos Lua e cada processo com 100 simuladores cada. Realizamos o teste de carga ao servidor simulando 20, 50, 100, 300, 600, 900, 1200 e 3000 dispositivos. Geramos um relatório detalhado para os coordenadores do projeto com os dados obtidos para definirmos os próximos passos. Agora o objetivo do LAC é otimizar a comunicação entre o dispositivo e o servidor de forma a diminuir a quantidade de mensagens enviadas.