Ano novo, tema novo….

Uma rápida revisão dos projetos que vou desenvolver este ano me deixou tão animado que resolví mudar de tema, para sair um pouco da rotina.  Afinal, em 2012 vou sacar o funil da inovação e implementar vários projetos profissionais que estavam na “incubadora” mas que agora ganharam sinal verde para ir adiante (leia-se: tempo, recursos e planejamento) . Entre uma pausa e outra para refletir, espero compartilhar alguns deles por aqui.

Novo Samsung Galaxy Tab 7.7

Galaxy tab 7.7

A Samsung acaba de lançar o Galaxy Tab 7.7,  novo tablet que promete acirrar ainda mais a disputa com a Apple pela preferência do consumidor. O novo dispositivo é o primeiro tablet do mercado a empregar a tecnologia de display Super AMOLED a qual permite maior nitidez e qualidade de imagem, com resolução de 1280 x 800 (WXGA) e 7.7 polegadas.   Segundo a Samsung,  a tecnologia permite atingir uma duração de bateria de até 10 horas, com reprodução de vídeo.

Com apenas 7.89 mm de expessura, o aparelho também evidencia a busca compulsiva de alguns fabricantes por dispositivos cada vez mais finos e de design arrojado.  O tablet utiliza processador dual core de 1.4 Ghz e memória RAM a partir de 16 GB (podendo ir a 64GB) além de poder usar um cartão microSD com até 32GB extras.  

 Outros ítens que merecem destaque são a interface de rede LTE & HSPA de 21 mbs,  reprodução de vídeo em HD,  câmeras para fotografias (3MP) e vídeo-conferência (2MP) com foco automático.   O sistema operacional é o Android Honeycomb 3.2v, otimizado para rodar em telas de 7 polegadas.

Gestão de Incidentes e Problemas em Genexus

Quando iniciamos a consultoria para certificação ISO/IEC 20000 (serviços em TI) ficou claro a urgente necessidade de automatizar vários processos exigidos pela norma a fim de atender seus requisitos – particularmente a gestão de incidentes e problemas.   Uma vez que estávamos avaliando o  Genexus,  surgiu a idéia usar esta ferramenta para suprir nossa necessidade.   Aliás,  várias organizações no Brasil e no mundo usam a ferramenta justamente para desenvolver rapidamente soluções de uso interno, bem no perfil do nosso software.

 

Uma das vantagens do Genexus é a capacidade de abstrair aspectos da tecnologia – você pode gerar aplicações em Java ou C#, por exemplo – e ir direto ao ponto que interessa, ou seja, modelar seus processos de acordo com a realidade do negócio.   Outra característica interessante é o suporte nativo a workflows,   permitindo flexibilidade ao modelar regras como nossos requisitos da norma ISO.  Assim,  iniciamos um projeto-piloto do SIGIP  (Sistema de gestão de incidentes e problemas).

 

Tela de Login do SIGIP

Uma das primeiras providências foi criar uma identidade visual para o sistema (ver a tela de login,  acima),  já que o esquema-padrão fornecido pelo Genexus não é esteticamente refinado.  Fazer isso na ferramenta não é grande coisa, graças ao suporte a Master Pages do Genexus que nos permite padronizar tanto a aparência quanto o comportamento de todas as views do sistema.   É possível criar os artefatos HTML/javascript em outra IDE (em nosso caso, Photoshop + Eclipse) e exportá-lo para o Genexus sem problemas.  Também é possivel importar packages java (ou assembly .NET) para prover funcionalidades não oferecidas nativamente pela ferramenta, ou para aproveitar componentes existentes.

O uso do Genexus tem sido promissor para o desenvolvimento desta ferramenta de uso interno e pretendemos usar a experiência adquirida no projeto para oferecer também a solução a nossos clientes.

Um botão para Desligar a Internet

Lei permitiria ao Presidente "Desligar a Internet"

A idéia parece coisa de filme:  o Presidente dos Estados Unidos tem acesso a um botão onde pode, a qualquer momento, simplesmente desligar a internet no pais inteiro deixando todo mundo offline.   Soa estranho ?  pois o assunto é sério e está em debate no Congresso Americano.   

Entenda 

O projeto de lei encabeçado por três Senadores tem como objetivo declarado proteger a rede dos Estados Unidos em situações que ponham em risco a segurança nacional.  O assunto, é claro, gerou polêmica e o debate sobre a nova Lei tem divido liberais e conservadores dos principais partidos devido as implicações que este novo poder daria ao Presidente, transformando-o em uma especie de “senhor da internet”,  segundo os críticos.   

Entre as preocupações discutidas está a possibilidade do sistema ser utilizado para podar direitos de indivíduos e até a liberdade de expressão de fontes contrárias ao governo.  Por exemplo, com este poder em mãos  o governo poderia interferir de forma “cirúrgica”,  barrando um site específico,  ou certas regiões geográficas do pais.   

O projeto permite que o Presidente declare uma  ”emergência cibernética”,  mas atualmente não deixa claro os limites para uso do sistema nem quais as prováveis consequências de seu uso.  Os defensores do projeto negam que o tal botão venha a existir, fisicamente falando, e sustentam que a Lei é uma resposta a ameaças atuais e futuras e que suplantará tratados existentes, como o Ato de Comunicações de 1934. 

Com a internet tendo papel cada vez mais importante na vida moderna, além de ser uma espécie de “ícone” da liberdade de expressão,  resta saber se os políticos conseguirão convencer a sociedade Americana sobre a necessidade deste tipo de controle.

Nota Fiscal Eletrônica: O interesse Continua

Dois anos após termos iniciado uma série de road-shows sobre Nota Fiscal Eletrônica (NF-e), o interesse no assunto continua em alta.  Em todas as ocasiões o auditório tem estado lotado com máximo número de inscrições e participação de empresários,  contadores,  profissionais de TI,  dentre outros.  O evento mais recente,  realizado como parte da programação local do PEIEX 2010, não foi exceção com um público bastante interessado e cheio de dúvidas sobre NF-e  (e pelo SPED, de maneira geral).

Seminários sobre NF-e tem despertado interesse das empresas

Teoricamente,  a implantação da NF-e não deveria alterar de forma significativa a rotina operacional das empresas, afinal o documento eletrônico substitui o atual (1/1-A) em todas as hipóteses previstas na legislação.  Existem vantagens como eliminação de algumas  despesas acessórias (AIDF),  redução de custo de impressão por nota,  facilidade para armazenar os documentos eletrônicos durante o período decadencial  e incentivo ao relacionamento comercial eletrônico (B2B) entre as partes. 

Para muitas empresas, entretanto,  a falta de infra-estrutura tecnológica adequada pode atrapalhar o processo de emisão da NF-e e significar uma dor de cabeça adicional.   Um dos problemas mais recorrentes é a má qualidade e custo elevado das conexões internet em muitos lugares no Brasil – algo que pode vir a ser remediado com o plano de expansão da malha anunciada pelo Governo Federal mas que ainda não representa uma solução a curto prazo.  

Outra preocupação digna de nota é a diversidade de sistemas existentes para a emissão de NF-e (e como sabemos, atualmente não é exigido um processo de homologação com acontece com os aplicativos PAF-ECF) muitos deles incapazes de se integrar de forma harmoniosa com os sistemas legados de gestão administrativa,  gerando dificuldades operacionais, falta de confiabilidade e aumento na carga de trabalho dos faturistas.  Em decorrência disso, muitas empresas que emitem quantidade considerável de documentos fiscais acabam optando por terceirizar uma solução de emissão e gestão de NF-e e arcar com taxas de emissão e hospedagem decorrentes – ironicamente,  indo de encontro a uma das maiores promessas da NF-e que é a redução de custo operacional.

Evidentemente as preocupações do contribuinte não param  por aí  pois trata-se de um assunto com implicações abrangentes e complexas, mas uma coisa costumamos deixar bem claro em nossos encontros com empresários:  a integração de informações e controle absoluto do Estado das operações comerciais, tendo em vista a aplicação das leis vigentes, é um movimento inexorável e que tende a expandir-se por todos os setores em curto e médio prazos.   Sendo assim,  resta a todos os envolvidos no processo se manterem atualizados e não deixarem algumas providências importantes para última hora.

O Computador Que Foi à Lua

16 de Julho de 1969.  Um ruído equivalente à explosão de 200 toneladas de TNT sacode a tranqüila manhã no complexo 39 do Centro Espacial Kennedy, na Flórida.  Ainda preso à estrutura de lançamento, o Saturn V – maior foguete já construído com seus 110 metros de comprimento e 4000 toneladas de peso – acelera os 5 motores F1 a máxima potência, fazendo-os consumir 15 toneladas de combustível por segundo.  No topo da espaçonave,  amarrados dentro do módulo de comando Columbia,  os astronautas Neil Armstrong,  Edwin “Buzz” Aldrin e Michael Collins  iniciam a mais complexa e perigosa missão jamais realizada pelo homem:   uma viagem de ida e volta à Lua.

Manobra Perigosa

Apenas 12 minutos após a alucinante subida pelas camadas da atmosfera, o estágio superior do foguete contendo o módulo de comando, módulo de serviço e módulo lunar (que na Apollo 11 chamava-se “Eagle”) estava em órbita da Terra e os astronautas iniciavam o checklist para a manobra que os levaria até nosso satélite natural.  Uma vez que não havia como carregar combustível suficiente para dirigir a espaçonave em trajetória direta para a Lua, os cientistas do projeto Apollo planejaram executar uma manobra denominada TLI (Trans Lunar Injection).   A perigosa manobra consistia em orientar e acelerar a espaçonave para uma posição no espaço onde a Lua estaria em três dias, o que requeria precisão extrema no uso da navegação e sistemas de propulsão.  Um erro de cálculo significaria a perda da espaçonave e sua tripulação.   O conjunto até poderia ser guiado por sinais de rádio enviados pelo centro de controle em Houston, Texas, mas em plena Guerra Fria os planejadores temiam que interferências intencionais nas freqüências de rádio pudessem colocar a missão em perigo.   Além disso,  a manobra para alunissagem incluia passagens pela face oculta da Lua, onde não é possível contato de rádio com a Terra.  A solução encontrada pelos cientistas foi incluir um computador digital a bordo para controlar a espaçonave de forma autônoma,  com a precisão e confiabilidade exigida pela missão.  O problema era que com a tecnologia disponível na década de 60, computadores com esta capacidade ocupavam andares inteiros de prédios e pesavam toneladas.

Desafio Tecnológico

Módulo com chips usados pelo AGC

A árdua tarefa de projetar um computador com os requisitos especiais definidos pela NASA ficou a cargo do Instrumentation Lab (IL) do MIT (Massachusetts Institute of Technology) que tinha experiência em sistemas de orientação dos mísseis Polaris e Poseidon, que  usavam computadores analógicos.  O novo sistema deveria utilizar arquitetura 100% digital e seria a primeira vez que um computador deste tipo controlaria o vôo de um veículo espacial.  Como já era comum no projeto Apollo,  algumas tecnologias-chaves ou não existiam ou estavam ainda em sua infância.  Exemplo disso eram os recém criados circuitos integrados. Fabricados inicialmente pela Fairchild, um chip com apenas três portas lógicas chegou a ser vendido aos militares por até US$ 1000,00.  Após alguns experimentos, os engenheiros do IL logo enxergaram o potencial desta tecnologia,  a qual foi incluída no projeto apesar de não se saber na época o quão confiável seria.  Uma das motivações para usar circuitos integrados ao invés dos componentes discretos tradicionais era a necessidade de reduzir o peso e o consumo de energia do artefato a fim de tornar possível sua operação em uma nave espacial  (curiosamente esta decisão fez com que durante algum tempo o projeto Apollo consumisse quase toda a produção de chips da indústria nos EUA).  Nascia então o AGC – Apollo Guidance Computer – com módulos produzidos e testados pela Raytheon, baseado e um protótipo experimental do MIT.

Sistema Embarcado 

O AGC pode ser considerado o primeiro sistema embarcado da era moderna. Com cerca de 4000 circuitos integrados, o sistema possuía um clock principal de 2 MHz, 2k de RAM e 36k de ROM,  armazenadas em núcleos magnéticos,  com uma arquitetura de 16 bits (14 de dados, 1 de sinal e 1 de paridade).  Em 1966, esses requisitos eram considerados “supra-sumo” da tecnologia digital.  Cada missão Apollo utilizava dois AGCs: o primeiro ficava no módulo de comando, sendo responsável pela inserção na órbita lunar e retorno à Terra; o segundo AGC ficava no módulo lunar e tinha como função controlar sua descida na superfície da Lua e posteriormente retorná-lo à órbita, quando os astronautas eram transferidos de volta ao módulo de comando para o retorno à Terra.  A tripulação se comunicava com o AGC através de uma interface bastante prática chamada DSKY (pronuncia-se “diskey”), composta por teclado, painel de status e displays numéricos. Os programas e seus parâmetros eram invocados através desta unidade e uma missão típica requeria cerca de 10500 digitações no teclado. Engenheiros no centro de controle também poderiam inserir comandos no computador de forma remota através do “uplink”,  se necessário.  Em uma época em que software era ainda uma ciência em gestação, os engenheiros do MIT praticamente criaram o conceito, dentro do esforço para desenvolver um sistema embarcado programável e flexível já que cada missão poderia necessitar de configurações operacionais diferentes.  O AGC também foi pioneiro no uso de um sistema operacional de tempo real não-preemptivo, onde cada processo executava funções em uma escala de tempo determinística e era orientado a ceder o controle para outros processos de acordo com sua prioridade.  Ao ser ligado, o sistema levava menos de um segundo para carregar todos os programas (“boot”) e iniciar sua operação normal.

Quarto Tripulante

O AGC possuía interfaces com praticamente todos os sistemas da espaçonave e podia controlar aspectos críticos como navegação, atitude (orientação em torno dos três eixos), links de telemetria, combustível e propulsão. Mesmo quando a tripulação assumia o controle manual (como fez Neil Armstrong, em seu pouso histórico) usando uma espécie de Joystick para realizar manobras, o AGC era quem estava analisando a entrada do piloto e traduzindo suas intenções para o sistema de propulsão. A automação do sistema impressionava até os astronautas (todos pilotos de teste profissionais) a exemplo de Pete Conrad, comandante da Apollo 12.  Usando um programa chamado LPD (Landing Point Designator), Conrad foi capaz de informar com precisão o local na superfície da Lua onde desejava pousar o módulo lunar “Intrepid”.  O AGC “pilotou” o módulo com perfeição até o local designado e fez todos os complexos cálculos para acelerar os motores do módulo de forma precisa, levando em conta sua massa atual, altitude, orientação em relação à linha de vôo,  dentre outros fatores.  Outra demonstração da capacidade do sistema era um programa chamado PTC (Passive Thermal Control), que realizava uma manobra complexa usada para distribuir o calor em volta da espaçonave de maneira uniforme.  Neste modo,  o AGC alinhava o eixo longitudinal  da espaçonave de forma perpendicular ao Sol e depois acelerava delicadamente os motores de manobra para fazer o conjunto girar lentamente dando uma volta completa em torno de si a cada 1 hora – tudo isso enquanto mantinha as antenas corretamente apontadas para a Terra e cuidava de outras tarefas simultâneas ! Tamanha era a confiança depositada no sistema que alguns astronautas o apelidaram de o “quarto tripulante”. 

Qualidade do Design

Toda a confiabilidade alcançada pelo AGC foi resultado do extremo esforço de engenharia realizado nos processos de design e  fabricação, além da qualidade dos testes tanto do hardware quanto do software.  Por exemplo, um dos testes envolvia mergulhar os circuitos integrados em Freon líquido e depois pesá-los em uma balança de precisão. Os chips com peso acima de determinado valor, eram descartados já que isso indicava que o líquido havia conseguido entrar no invólucro.  Outro teste impressionante consistia em mergulhar o sistema completo em solução de alta concentração salina durante dias e depois testá-lo. O sistema era capaz de funcionar normalmente em seguida.  Todos os circuitos do AGC eram selados em resina e robustos o suficiente para suportar a radiação e as forças a que o veículo espacial seria submetido durante todas as fases do voo.

Tributo à Criatividade

A "Águia" na Lua

As características de processamento e memória modestas do AGC, comparadas aos sistemas atuais, tem gerado comentários depreciativos ao longo dos anos, sendo que comparações entre a capacidade do AGC e relógios de pulso são muito comuns.  Essas comparações obviamente não consideram a confiabilidade do sistema e sua função crítica da qual dependiam as vidas de três astronautas e bilhões de dólares em equipamento.  Sem o AGC o pouso tripulado na Lua teria sido impossível, pois mesmo os melhores pilotos não conseguiriam controlar um veículo de várias toneladas descendo com propulsão de forma estabilizada e sem velocidade horizontal – pré-requisitos para que o módulo não tombasse e fosse destruído.  Mesmo quando foi sobrecarregado por sinais do radar-altímetro durante o pouso da Apollo 11 (gerando as famosas mensagens de alerta 1201 e 1202) , o sistema continuou a executar suas funções críticas, após colocar automaticamente as tarefas de baixa prioridade em segundo plano.  O resto, é história .

O AGC foi uma fantástica peça de engenharia criada pelos melhores gênios de sua época, a quem presto meu tributo nesses 40 anos da chegada do homem na Lua.

ALife com Java

Quando a humanidade começar a explorar para valer os planetas e luas mais distantes do sistema solar (como Europa,  uma das seis luas de Júpter e onde se acredita que existam oceanos)  vamos precisar de meios cada vez mais inteligentes e autônomos a fim de preparar o caminho para a chegada de uma possível missão tripulada.  Muito longe da Terra,  sondas e robôs de exploração deverão ser capazes de tomar suas próprias decisões à medida em incursionam no ambiente desconhecido e, na maioria das vezes, hostil.   Esta habilidade e capacidade de reagir e adaptar-se ao meio-ambiente é tipica dos seres vivos e existem vários campos de estudo que tem como objetivo justamente incorporar essas características a sistemas não-biológicos.   Uma das mais interessantes áreas de pequisa chama-se Artificial Life (Vida Artificial) ou ALife, para abreviar.

ALife

ALife visa o estudo de sistemas vivos,  suas diferentes formas,  processos e evolução, com o objetivo de recriar fenômenos biológicos através de modelos computacionais em ambientes simulados.  Faz parte desse  estudo determinar as formas de interação dos agentes biógicos artificiais entre sí e com o ecosistema em que estão inseridos – ou em que “vivem”,  por assim dizer.   A parte controversa tem a ver como definimos e aceitamos atualmente o conceito da vida:  algumas vertentes sustentam que o processo da vida pode ser abstraído de qualquer meio em particular (biológico, computacional, por exemplo)  enquanto outros defendem que é impossível recriar um processo vivo fora da esfera biológica tradicional.  

Controvérsias à parte, o resultado prático tem demonstrado a habilidade dos organismos sintéticos em imitar os diversos estados e comportamentos associados às suas contrapartes biológicas, como a necessidade de sobreviver, lidar com ameaças, alimentar-se,  reproduzir-se e até morrer.   A observação cuidadosa desse ecosistema demonstra que alguns estados e comportamentos tornam-se emergentes, ou seja não são resultado de uma programação previamente estabelecida (tipo, SE acontecer isso, FAÇA aquilo…),  mas decorrentes da forma como organismo reage a estímulos internos e externos.  

Quem já tentou perseguir (sem sucesso) uma barata em sua cozinha  já testemunhou esse fenômeno na esfera biológica – o bichinho “descobre” maneiras de se livrar de seu perseguidor (corre em zigue-zague, muda de direção e velocidade aleatoriamente) enquanto reage aos diversos estímulos que lhe são aplicados.  Esse comportamento reativo, não previsível porém não-caótico é exatamente o que um artefato explorador espacial do futuro vai precisar para realizar tarefas como sair de uma cratera em que acabou de cair ou contornar um obstáculo sem uma “pilotagem” humana – que não poderia acontecer em tempo real devido à distância entre a Terra e os planetas mais distantes.

Um pouco de prática:  Formigas e Plantas

Um final de semana ou feriado chuvoso é uma das ocasiões mais inspiradoras para colocar em prática alguns projetos engavetados devido a falta de tempo.   E foi em um desses que comecei a programar o Biosphere,  um ecosistema artificial que emprega alguns dos conceitos-chave de ALife.   Biosphere é um pequeno mundo onde três espécies (ou classes)  de seres encaram a luta pela sobrevivência:

• Cortadeiras
• Predadoras
• Plantas

Cortadeiras são bichinhos com aparência de formigas e com o torso central na cor verde-claro (ver imagem abaixo).   Quando estão com fome, as Cortadeiras assumem um comportamento nômade e passam a perambular pelo ambiente em busca de alimento, representado pela classe Planta.  Ao encontrarem uma Planta, elas se alimentam  até estarem saciadas,  permanecendo nas proximidades da Planta para evitar futuras caminhadas – a menos que esta tenha sido destruída na colheita ou exista alguma Predadora (seu inimigo natural) por perto, o que as faz fugir mesmo que estejam famintas.   Uma Cortadeira será destruída e removida do ambiente se seu nível de energia cair a zero, o que pode acontecer devido à falta de alimento ou por contato prolongado com uma Predadora.

Predadoras também são formiguinhas que diferem das Cortadeiras pela cor vermelha no torso e pelo comportamento hostil que lhes dá o nome:  São caçadoras e seu alimento são as formigas Cortadeiras.   As Predadoras passam a maior parte do seu tempo em busca de comida, andando a baixa velocidade a fim de poupar energia.  Quando alguma presa aparece dentro de seu raio de detecção (representado visualmente pelo círculo ao seu redor) elas atacam o mais rápido que puderem a fim de drenar energia da vítima.   Quanto mais tempo conseguirem manter contato físico, mais energia irão absorver.   Isso não será tarefa fácil, pois as Cortadeiras são um pouco mais rápidas e farão de tudo para evitar o contato.  Dessa forma, mesmo não tendo inimigos naturais as Predadoras estão sujeitas a sucumbir de fome se não forem eficientes na caçada. 

Criaturas artificiais em ação

 Plantas são espécies pacíficas de cor verde que embelezam o ambiente e servem de alimento para as Cortadeiras.  Possuem uma capacidade de regeneração e conseguem se manter vivas indefinidamente, desde que não sejam atacadas por várias Cortadeiras famintas e percam mais energia do que são capazes de regenerar, o que as fará morrer e serem removidas do ambiente.  

Atualmente, é interessante observar como todo esse ciclo pode se desenrolar por  horas seguidas ou pode ser encerrado em pouco tempo quando as condições do ambiente levam à exaustão de recursos e à falta de alimento, fazendo com que as espécies no topo da cadeia pereçam de fome. 

Embora possua gráficos animados e bichinhos que atacam e fogem,  Biosphere não não foi intencionado para ser e não pode ser classificado como um “game”, no sentido prático da palavra,  já que não permite que o “jogador” interfira nas ações que acontecem no ecosistema.  O observador possui uma “visão de satélite” (cima para baixo) de onde pode mover-se de um lado para o outro e ver o que está acontecendo, porém não consegue interferir (pelo menos na versão atual) nos acontecimentos “lá embaixo”. 

O que Java tem a ver com isso ?

Quando estava definindo este projeto educacional,  não foi difícil escolher Java como plataforma para o desenvolvimento, devido a três recursos fundamentais  já presentes no “core”:

• Threads
• Coleções
• Java2D

Cada espécie opera com uma Thread que se comunica com as demais através de mensagens.   As coleções são usadas extensivamente em várias situações como por exemplo,  armazenar uma lista de Predadores dentro de determinada área.   Todas as espécies são definidas através de uma interface denominada Entity.  Uma implementação-padrão desta interface,  LifeForm,  incorpora as características que são comuns às três espécies como sua posição no mundo virtual, sua condição de sáude, capacidade de regeneração,  etc.   Classes mais especializadas estendem LifeForm para implementar comportamentos específicos de cada espécie, como perseguição, evasão, agrupamento, etc. 

A estrutura do simulador envolve ainda uma classe para representar o mundo virtual (World) no qual toda a ação se desenvolve.  As formigas e plantas vivem e interagem dentro do mundo representado por esta classe, a qual está convenientemente desacoplada da engine gráfica que exibe a representação visual da simulação. Isso permite, entre outras coisas, implementar uma futura versão de Biosphere em 3D.  Por enquanto,  o uso de Java2D  tem atendido muito bem as necessidades do projeto, podendo rodar a animação a 60 fps mesmo com uma centena de criaturas ativas.

Com esta introdução, encerro por enquanto este fascinante assunto e prometo tratar mais sobre o tema em futuros posts.  Em especial,  pretendo  introduzir novos organismos no mundo virtual e modelar uma capacidade de reprodução e evolução, atualmente inexistentes em Biosphere.

Sistema põe siderúrgica na palma da mão

Parece que cada vez mais empresas estão investindo em recursos de monitoração e controle de processos à distância.  Exemplo recente disso é uma siderúrgica brasileira que está implantando um videowall (tela de projeção de dados de alta resolução) com 12 metros de largura para monitorar e controlar suas operações via Web, inclusive com o uso de um iPhone.

Controlando uma siderúrgica via Web

O sistema instalado na siderúrgica (cujo nome não foi divulgado) é baseado na solução SAP MII (integração e inteligência de manufatura) e foi adaptado para o videowall pela empresa de consultoria de TI americana Neoris.   O SAP MII permite criar aplicações que integram informações de sistemas heterogêneos e processos via Web.   Com o sistema,  paineis de informação, indicadores gráficos,  displays e janelas de controle são adaptados para operar via internet de forma interativa, em um conceito semelhante aos paineis de bordo ou cockpits.   O uso da tecnologia 3G e um software especialmente desenvolvido para o iPhone permitem que um engenheiro acesse o sistema e comande a operação de processos da siderúrgica remotamente,  via Web.

Além das aplicações industriais, este tipo de tecnologia vem crescendo muito em outras áreas como  telecomunicações, operadoras de sistema elétrico,  transportes e operadores logísticos.

DataTable em Java ?

Quem usa ADO.NET rotineiramente sabe o quão importante é o conjunto de objetos disponíveis pelo framework para trabalho com Datasets.  Entre os objetos existentes  meu favorito é o DataTable,  um versátil componente que mantem uma representação tabular de um conjunto de dados (uma tabela em um banco de dados, por exemplo) o qual podemos carregar e usar em modo “offline”.  

DataTable permite, dentre outras coisas, carregar seus dados a partir de um DataProvider qualquer (Oracle, MySQL, Postgree, etc)  ou diretamente a através de um arquivo XML (sem conexão com um banco de dados) o que é especialmente útil em muitas situações de programação.

E para quem programa em Java?  Como sabemos,  a API JDBC não possui algo semelhante e o “primo” mais parecido com o DataTable, funcionalmente falando,  seria o objeto ResultSet – o qual requer uma conexão ativa durante todo o tempo em que você estiver lendo ou alterando uma linha retornada.

Pois bem, recentemente ao portar um sistema desenvolvido em  .NET para Java, me deparei com a necessidade de ter algo semelhante ao DataTable – especialmente após constatar que a adaptação do modelo para o equivalente em JDBC aumentaria significativamente o número de linhas de código do sistema.   Um dos requerimentos era justamente poder carregar um Dataset e encerrar a conexão com o banco de dados imediatamente, liberando-a para outros processos concorrentes.

Com esta motivação,  criei um novo componente com algumas características-chave do DataTable  e o adicionei à biblioteca TinySQL (um “wrapper” para o JDBC que desenvolvi há alguns anos).    Para se ter uma ideia da sintaxe da coisa,   eis um pequeno trecho de código de uma das rotinas de teste do novo DataTable –  e que usa também o objeto Query de TinySQL:

public void DataTableTest(ConnectionFactory factory) throws SQLException {
// Cria uma query para obter retornar dados do banco
Query query = new Query(factory.getConnection());
// Define uma consulta em uma tabela de usuarios
query.setSQL("SELECT * FROM TSYS_USUARIO");
// Executa a query
query.open();
// Cria nosso DataTable
DataTable table = new DataTable();
// Carrega o objeto DataTable com todas as linhas retornadas pela Query
table.load(query.getResultSet());
// A query pode ser fechada logo em seguida !
query.close();
// Itera sobre cada linha e exibe o conteudo de uma coluna
for (DataRow row : table.getRows()) {
System.out.println(row.getColumn("TSYS_NOME").getValue().toString());
}
}

Como se pode perceber, o DataTable “for Java” possui aplicação semelhante ao de seu similar em .NET, incluindo os objetos DataColumn e DataRow. Esta prova de conceito inicial possui algumas limitações,  como não permitir alterar o dataset associado (algo que até faz sentido se a  intenção for usá-lo apenas no modo offline) e também não permite carregar ou salvar o conjunto de dados a partir de um arquivo XML – feature que fica para a próxima versão.

Projeto V/EFIS

 Finalmente depois de muito refactoring, cheguei a uma versão utilizável do meu projeto V/EFIS (virtual eletronic flight instrumentation system).  O objetivo do projeto (ver imagem abaixo) é criar os principais indicadores gráficos utilizados para monitorar a navegação e o desempenho de uma aeronave em ambiente de simulador  – que no meu caso é o Flightgear, um software open-source muito utilizado em pesquisa acadêmica.

Display do Projeto V/EFIS (Glass Cockpit) em ação.

 Tradicionalmente os simuladores de voo trazem um cockpit 3D renderizando tanto o cenário externo quanto os instrumentos na cabine da aeronave.   Embora esta abordagem seja adequada para fins de diversão, deixa a desejar quando queremos uma experiência mais realista. O uso de um cockpit digital fora do sistema do simulador permite criar uma experiência muito mais rica, além de racionalizar o uso dos sistemas computacionais disponíveis,  já que o simulador agora precisa apenas controlar o modelo de voo e renderizar o cenário.  O resultado final é muito mais interessante.   Iniciei o V/EFIS em 2007 e embora possa dedicar apenas algumas poucas horas por semana ao projeto,  o andamento tem sido satisfatório.  Até o presente,  foram criados os seguintes artefatos:

• Interface com o Flightgear
• PFD-Primary Flight Display
• NG-Navigation Display
• Framework e sistema de suporte a OPEN-GL

Atualmente estou desenvolvendo os gauges para o ECAM (Electronic Centralised Aircraft Monitor) que ainda está em fase inicial de projeto.  Todo o sistema é escrito em C++ (com Visual Studio) e um framework para dar suporte à renderização com OpenGL também está sendo criado. Em futuros posts, darei mais informações sobre o V/EFIS e sobre o resultado dos voos que fiz utilizando o sistema.