META 5-1: Estudo de Mapeamento para Implantação do Sistema AIS (Automatic Identification System) na Hidrovia Tietê-Paraná.
Introdução
O AIS (Automatic Identification System) é um modo de comunicação de curta distância que opera por rádios VHF (Very High Frequency) dedicado aos meios marítimos, capaz de prover eletronicamente, em tempo real, aos navegantes as informações de posição, curso, velocidade, tráfego e parâmetros de alerta de proximidade de outras embarcações. Dependendo da potência do sinal do transmissor, das condições meteorológicas, da topografia e da capacidade do receptor o alcance da comunicação pode ser estabelecido até 50 km ou mais.
O CTHTP (Comitê Técnico da Hidrovia Tietê-Paraná) deliberou que a partir de 2014 haverá uma implantação gradativa do AIS na hidrovia, iniciando a instalação do sistema pelo trecho de maior tráfego do Rio Tietê e na sequência integrando-o até o Rio Paraná.
Este relatório contempla nosso compromisso firmado na 61ª Reunião do CTHTP realizada em 28/11/2013 em Ilha Solteira – SP, a respeito de estudos e mapeamento para implantação de cobertura dos rádios do sistema AIS na Hidrovia Tietê-Paraná. Estão apresentadas as coordenadas dos pontos mais propícios para a instalação dos rádios, considerada a disponibilidade de infraestrutura tais como; eclusas, pontes, faróis, faroletes e eventuais cidades às margens da hidrovia, de modo a se compor o mapa de recobrimento para um rastreamento/monitoramento com o mínimo de sombras.
Metodologia
O estudo para a composição de cobertura da hidrovia pelos transceptores do sistema AIS foi realizado partindo-se da análise de locais onde já se dispõe de alguma infraestrutura prévia, especialmente, a disponibilidade de energia e a logística de facilidades de instalação e manutenção. Diante disso foram consideradas, em ordem de prioridade, as próprias usinas hidrelétricas, as pontes com sistema de monitoramento pelo D.H., os faróis e faroletes da AHRANA e instalações em cidades ou locais nas vizinhanças da hidrovia.
Como premissa inicial, foi admitido nesse estudo um recobrimento econômico, isto é, com o mínimo de superposição dos enlaces, porém garantindo a plena cobertura da hidrovia, ou seja, os links de enlaces devem prover a ausência de pontos cegos ou de sombra.
Ademais, para garantir a premissa anteriormente elencada, e considerando aspectos de consumo de energia x potência dos transmissores, o que pode ser crítico em pontos com
55 alimentação por painéis solares, caso dos faróis e faroletes, priorizamos a definição de rádios de menor potência (2 Watts), portanto, com alcance definido para 30 km. Apenas em três locais (Guaíra, Presidente Epitácio e Jupiá), por questão de suprir o recobrimento do enlace foram necessários rádios de maior potência (12 Watts).
Uma parte da base de dados das coordenadas de posição dos possíveis pontos com infraestrutura para instalação dos transmissores AIS foi fornecido pelas empresas AES Tietê e AHRANA e outros pontos coletados a partir da base do mapa Google Earth Pro.
A localização dos pontos para a instalação do sistema AIS, classe B, foi realizada tomando como referência os dados de rádios marca “em-trak B100” e “em-trak B212”, cujo alcance foi pré-estabelecido como sendo 30 e 50 km, respectivamente. Ambos os transceptores operam com frequência variando de 156.025 a 162.025 MHz. A escolha desses alcances também é justificada em função da elevada estratificação do índice de refração da atmosfera sobre a superfície dos lagos, especialmente nas condições de nevoeiros.
A influência de atenuação de sinal ou sombras devido ao relevo não foi diretamente considerada nesse estudo preliminar pelo fato de não se conhecer, a priori, a altura de todas as torres para a instalação dos transmissores. Entretanto, como na definição dos pontos de posicionamento dos transmissores procurou-se levar em conta a questão da sinuosidade dos rios. Assim, o posicionamento foi estruturado de modo a assegurar visadas diretas sobre o leito do rio entre os sucessivos transmissores.
Os pontos definidos para a composição dos enlaces foram justapostos em suas coordenadas no mapa Google Earth Pro, para permitir a visualização do campo de cobertura sobre toda a hidrovia.
Resultados
As envoltórias de cobertura dos rádios AIS estão apresentadas na Figura 5.1. São destacados na cor verde a fração relativa ao Rio Tietê, cuja composição contempla a cobertura por 8 estações de 2 Watts (em-trak B100) com envoltórias de 30 km. A fração do Rio Paraná, de São Simão à Itaipu, está destacada em vermelho e amarelo. Sendo composta por 13 estações de 2 Watts (em-trak B100) com envoltórias de 30 km (vermelho) e 3 estações de 12 Watts (em-trak B212) com envoltórias de 50 Km (amarelo).
Nas Tabelas 5.1 e 5.2, estão detalhadas as coordenadas de posicionamento das estações AIS para os rios Tietê e Paraná, respectivamente.
56
57
Tabela 5.1 – Estações no Rio Tietê. Número
da Estação Local Latitude Longitude Tipo de rádio
1 Usina Pioneiros – Sud Menucci
Açúcar e Álcool 20°43'45.26"S 50°57'34.59"O em-trak B100
2 Ponte da SP-463 21° 2'36.57"S 50°27'50.62"O em-trak B100
3 UHE Nova Avanhandava 21° 7'25.86"S 50°12'48.09"O em-trak B100
4 UHE Promissão 21°17'52.12"S 49°47'20.87"O em-trak B100
5 Ponte entre Pongai e NH 21°38'47.16"S 49°16'37.61"O em-trak B100
6 UHE Ibitinga 21°45'33.89"S 48°59'26.36"O em-trak B100
7 UHE Bariri 22° 9'11.82"S 48°45'8.69"O em-trak B100
8 UHE Barra Bonita 22°31'10.34"S 48°32'0.37"O em-trak B100
Tabela 5.2 – Estações no Rio Paraná Número
da Estação Local Latitude Longitude Tipo de Rádio
1 Farol Bonanza 19° 8'23.01"S 50°40'33.22"O em-trak B100
2 Reserva 19°23'54.94"S 50°51'22.88"O em-trak B100
3 Farolete Serra L 19°46'0.09"S 51° 2'0.28"O em-trak B100
4 Farolete Pontal de Minas 20° 4'0.04"S 51° 0'0.00"O em-trak B100
5 Farol São Martinho 20°20'0.98"S 51°18'0.08"O em-trak B100
6 UHE Jupiá 20°46'41.00"S 51°37'46.00"O em-trak B212
7 Panorama 21°22'14.52"S 51°51'42.50"O em-trak B100
8 Pres. Epitácio, Base da Marinha 21°44'49.00"S 52°11'53.87"O em-trak B212
9 Anaurilândia 22°11'20.18"S 52°43'9.90"O em-trak B100
10 UHE Porto Primavera 22°28'59.00"S 52°57'27.00"O em-trak B100
11 Pau d'Alho 22°50'5.20"S 53°22'18.27"O em-trak B100
12 Porto Caiuá 23°15'54.99"S 53°43'2.19"O em-trak B100
13 Pto Baunilha 23°34'21.80"S 54° 2'6.51"O em-trak B100
14 Guaíra, Base da Marinha 24° 5'7.61"S 54°15'28.16"O em-trak B212
58
16 Farolete Ocoí 25°15'0.24"S 54°27'0.15"O em-trak B100
META 5-2: Modelo de Otimização de Filas no Processo de Eclusagem Estruturação do problema
É proposta a criação de um sistema para aperfeiçoar o processo de transposição nas eclusas do Rio Tietê, a fim de minimizar os tempos de espera de eclusagem, ou seja, diminuir as filas nas eclusas.
Tendo em vista a grande demanda atual de transporte de cargas, e a projeção para os próximos anos, nota-se um crescimento acentuado no volume de embarcações em seu leito, o que pode acarretar formações de filas nas eclusas e atrasos do fluxo de embarcações.
A fim de minimizar os tempos de espera em eclusagens, é necessário a implementação de um modelo de otimização de filas no processo de eclusagens na Hidrovia do Tietê.
Para dimensionamento do Sistema de otimização, foram considerados como variáveis do sistema, os seguintes parâmetros:
a) Sequência prioritária, normas de trafego da Hidrovia Tietê-Paraná; b) Tipo de embarcação;
c) Posição da eclusa, Montante ou jusante; d) Posição da embarcação;
e) Previsão de chegada à eclusa;
Construção do Modelo/Teoria
As primeiras ideias tinham como premissa a criação de rotinas de cálculos com estruturas condicionais e blocos de pesquisa, para a otimização do sistema. Entretanto, considerando que esta proposta envolve, sobretudo, uma aplicação operacional e naturalmente deve primar pela eficiência combinada com a simplicidade, decidimos substituir a estrutura de algoritmos computacionais do tipo decisão lógica por uma modelagem matemática.
Assim, foi concebido um modelo matemático com três equações, que de acordo com suas variáveis, atribuem um valor de prioridade para uma lista de embarcações, sendo:
a) F(t_chegada; pos_barco; pos_eclusa), função com 3 variáveis, ordena uma lista de embarcações de acordo com a previsão de chegada, a posição do barco e eclusa. b) F(t_final) =| t_chegada|, necessária para comparar os vencedores;
c) F(t_final) =| t_chegada +30|, ajuste da função para discordância da posição do barco com a câmara.
Isso permite diminuir o tamanho e a complexidade das rotinas, e desta forma, solucionar o problema com uma metodologia mais clássica e com abordagem inovadora. O fluxograma da Figura 5.2 apresenta a dinâmica do modelo.
59
60
61
Figura 5.2 (continuação)– Fluxograma do modelo de otimização.
Estudo de viabilidade
A meta do modelo de otimização é reduzir em 30% as etapas dos processos de transposição de barragens, baseando num melhor aproveitamento das operações de enchimento e esvaziamento da eclusa, o que por si só, pode ser fator econômico da viabilidade.
62 Lopes (2011) realizou um estudo dos impactos energéticos produzidos na cascata do rio Tietê em decorrência do aumento do tráfego hidroviário. Este estudo concluiu que, em termos de consumo energético, as eclusagens representam uma retirada energética de 7 MWh para o horizonte de 2015 e 10 MWh médios para 2020.
De acordo com a concessionária AES Tietê, o número de eclusagens realizadas no ano de 2012 nas eclusas administradas por ela, foi de 16457. Considerando o período de tempo de um ano, e o volume médio das câmaras das eclusas do Tietê em 45 mil m3, é possível obter uma vazão equivalente de eclusagem de 23,48 m3/s. Seguindo o mesmo raciocínio de Lopes (2011), esta vazão constante durante o ano de 2012, seria capaz de produzir 5,4 MWh médio de energia.
Segundo a Secretaria de Transportes do Estado de São Paulo a estimativa de crescimento do tráfego hidroviário na Hidrovia Tietê é 26,5% até 2020. Face ao este crescimento esperado e analisando a capacidade operacional das eclusas desta hidrovia, especialmente as eclusas de Barra Bonita e Bariri devem chegar em suas capacidades máximas de operações de eclusagens no ano de 2014, conforme Lopes (2011).
Partindo das informações anteriormente elencadas, o desenvolvimento de um modelo de otimização nos processos de transposição de barragens é relevante, pois, uma redução de 30% nas etapas dos processos de eclusagens, resultaria, como exemplo, numa economia de 1,61 MWh no ano de 2012.
META 5-3: Instalação de Centrais Remotas de Instrumentação para Coletar Dados Introdução
As estações remotas enviam informações para o laboratório permitindo que elas sejam estudadas e analisadas. Mas para isso, esses dados precisam ser devidamente armazenados em um servidor de maneira fácil, porém com supervisão humana para evitar que dados importantes sejam sobrescritos.
A fim de melhorar essa tarefa, propôs-se a criação de um programa com interface gráfica para armazenamento dos dados coletados pelos equipamentos de medição em um servidor SQL disponível.
Com as diversas linguagens de programação e as diversas bibliotecas disponíveis para fazer programas com interface gráfica, torna-se uma tarefa complicada e muitas vezes subjetiva escolher a plataforma que se utilizará para trabalhar. Planejou-se então escrever um programa que pode ser executado em Windows, Linux ou mac OS (após o processo de instalação adequado) que pudesse ser desenvolvido de forma prática e flexível (para que possíveis mudanças no esquema do programa pudessem ser implementadas de forma fácil). Escolheu-se então trabalhar com a linguagem de programação Python na versão 2.7 juntamente com a biblioteca PyQT, uma extensão da biblioteca de interfaces gráficas para C++ adaptada para trabalhar de forma flexível e prática com o Python.
Python é uma linguagem de programação de alto nível, interpretada e orientada a objetos criada em 1991, mas que teve uma recente explosão em número de usuários e em número de projetos que utilizam a linguagem. A Figura 5.3 apresenta o percentual de utilização de
63 linguagens de programação em projetos. As tradicionais linguagens Java e C++ estão apresentadas em roxo e laranja, respectivamente, observa-se que no período de 2005 até 2014 estas linguagens passaram a ser menos utilizadas. Em azul está Python, a linguagem escolhida para utilização que alcançou um patamar de utilização próximo ao das linguagens tradicionais. Em vermelho está Ruby, outra opção que foi analisada, porém foi descartada devido ao baixo número de usuários comparado às outras linguagens.
Figura 5.3 - Comparação de linguagens de programação – Percentual de projetos por ano. Fonte: http://www.ohloh.net/languages
A ascenção do Python nos últimos anos se deve à agilidade que a linguagem traz ao desenvolvimento de projetos, além disso, é uma linguagem com grandes possibilidades de ser estendida, permitindo chamar funções em C++, Fortran e outras linguagens. Assim, uma grande quantidade de bibliotecas de uso específico foi adicionada.
Metodologia
Observando o processo de desenvolvimento de software realizou-se um processo de desenvolvimento cíclico em que varias versões do programa são feitas como passos intermediários até chegar numa versão final. A cada ciclo o programa vai crescendo em complexidade e em funcionalidade.
As versões iniciais permitiam que o usuário pelo terminal do linux fosse feito o upload de um arquivo de texto contendo as informações necessárias, em seguida iniciou-se o desenvolvimento da interface gráfica e de funções para permitir a manipulação do arquivo de texto, selecionando o cabeçalho, pulando linhas, entre outras funções para facilitar a utilização do usuário final.
Escolheu-se a biblioteca SQLAlchemy por oferecer diversas funções já implementadas para trabalhar com a linguagem de requisições de servidor chamada SQL.
64 O programa desenvolvido foi feito de forma modular para permitir que ele seja facilmente compreendido e também seja facilmente estendido caso seja necessário algum desenvolvimento futuro. A versão atual encontra-se disponível na base de dados do projeto.
Resultados
Como resultado do trabalho de desenvolvimento de software para realizar o upload de dados provindos de sensores instalados em centrais de instrumentação remotas obteve-se um software multiplataforma com interface gráfica. O resultado visual encontra-se na Figura 5.4.
Figura 5.4- Interface gráfica final.
A Figura 5.4 mostra um exemplo real de upload para um servidor SQL em que são enviados dados de pressão com uma coluna representando a data e o horário em que a informação foi coletada, uma coluna representando um número de registro daquela informação e por fim uma coluna que representa a informação de pressão em si.
Ao pressionar o botão “Arquivo de Origem” abre-se uma janela que permite a busca de arquivos csv para ser feito upload. As duas caixas adjacentes à esse botão permitem pular linhas de forma que parte do cabeçalho do arquivo csv pode ser pulado, fazendo apenas informações uteis serem inseridas no servidor.
65 O software desenvolvido é capaz de fazer upload de arquivos csv gerados pelas estações de instrumentação remotas, a interface gráfica confere maior controle ao usuário sobre o que está sendo colocado no servidor do que opções automatizadas (que poderiam causar erros que demorariam muito tempo a serem percebidos).
O uso da linguagem Python foi um grande facilitador na implementação do projeto uma vez que ela possui bibliotecas completas para trabalhar com servidores SQL e interfaces gráficas. Alguns bugs são conhecidos e estão sendo trabalhados, como por exemplo, ao se fazer o upload de um mesmo arquivo duas vezes o programa gera um erro e trava, para ser resolvido faremos uma verificação linha a linha se a entrada já existe antes de fazer o upload.
Pelo controle de versões atual o programa está na versão 0.9, sendo que a versão 1.0 será o programa completamente capaz de enviar um arquivo csv ao servidor SQL controlado por um usuário comum e que não retorne erros ao encontrar uma entrada igual no servidor (sem deixar entradas duplicadas no servidor).
Foi deixado espaço para estender as funcionalidades do programa que atualmente faz apenas a escrita no servidor. Em um projeto futuro, pode-se fazer um módulo que faça a leitura dos dados e já seja capaz de plotar gráficos de histórico dos dados em questão. Com essa funcionalidade adicionada à versão do software seria considerada 2.0.
Referências Bibliográficas
SUMMERFIELD, M - Rapid Gui Programming With Python And Qt - PEARSON EDUCATION, 648p, 2007.
MILANI, A. – MySQL guia do programador. – NOVATEC, 400p, 2007.
LUTZ, M. – Programming Python – 4ª edição, O’REILLY MEDIA, 1632p, 2010.
META 5-4: Banco de Dados MySQL
Um dos ramos de pesquisa do projeto Ondisa 8 é a recepção e disseminação, em tempo real, de dados meteorológicos que reproduzem a relação Vento x Onda nos lagos da Hidrovia Tietê-Paraná. Os dados são coletados, armazenados e monitorados pelo Laboratório de Hidrologia e Hidrometria (LH²) da Unesp de Ilha Solteira. Para o gerenciamento do banco de dados do projeto é utilizado o programa MySQL, que é de fácil manuseio e garante a segurança dos dados. A importância de se ter um banco de dados organizado e em operação reflete na necessidade de recuperar informações, tirar conclusões e assim tomar decisões.
Os dados meteorológicos são obtidos de torres localizadas ao longo da Hidrovia Tietê- Paraná e os dados de ondas são obtidos pelos sensores do ADCP-Waves que, após um período mergulhado no fundo do rio, é emerso para manutenção e coleta dos dados em forma bruta.
A existência de um banco de dados é de suma importância para o projeto, pois é a nele que todas as informações obtidas são armazenadas e organizadas, permitindo que sejam feitas análises e interpretações dos eventos e assim que as decisões sejam tomadas baseadas nas conclusões. Também o banco de dados permite a recuperação de informações, caso necessário.
66 As informações de vento podem ser organizadas basicamente quanto a intensidade, direção e duração e as informações de ondas interessam quanto as alturas atingidas pelas ondas e suas durações.
A etapa de armazenagem das informações processadas em um banco de dados ocorre após a fase de aquisição dos dados brutos. Os sensores instalados em campo, tanto para medição de fatores meteorológicos quanto para medição de ondas são captam a informação da grandeza física desejada e transforma em dados que são armazenados na memória interna de um datalogger, estes dados, porém, estão na forma bruta, portanto precisam ser processados e organizados para que se obtenham as informações desejadas – exemplo, velocidade, direção e intensidade de vento, altura de ondas – para isso os dados brutos são importados e processados em computador e armazenados de forma organizada no banco de dados. Assim é possível melhor visualizar a relação Vento x Onda que ocorre em campo. As análises e interpretações destes eventos meteorológicos e hidrodinâmicos é de grande valia no auxilio para construir um modelo capaz de relacionar tais grandezas.
A seguir, um exemplo de organização dos dados de vento já processados e obtidos em certo período pela estação de Ilha Solteira – CESP. Nota-se a facilidade na interpretação e compreensão dos dados demonstrados.
Tabela 5.3 – Exemplo de organização de dados de vento, Estação Ilha Solteira – CESP.
Para o armazenamento dos dados processados é utilizado o servidor de banco de dados MySQL, que é um sistema de banco de dados SQL (Structured Query Language ou Linguagem Estruturada para Pesquisa). Com ele é possível ter acesso aos dados coletados ao longo de todo o projeto, de maneira rápida e precisa. O motivo de sua escolha para servidor do projeto Ondisa 8 é devido sua praticidade, facilidade de manuseio além de ser seguro e livre.
Conclusão.
Nota-se a importância da boa integração entre a fase de aquisição de dados e o processamento destes para chegar aos resultados dos eventos para então poder tomar as decisões baseadas nas análises e interpretações das informações. Dados de vento como intensidade,
67 direção e duração – obtidos por anemômetro – quando relacionados aos dados de ondas obtidos pelo ADCP-Waves geram um perfil de comportamento entre estes dois eventos que estão interligados. Estes dados podem ser representados em tabelas, gráficos e imagens variando com a necessidade do tipo de interpretação. O servidor do banco, MySQL mantém os dados seguros e organizados para consultas e recuperações de informações, sendo possível a consulta dos dados coletados ao longo de todo o projeto, bem como analisar dados específicos como máximos e mínimos dos eventos.
68