Blog do Andre Fonseca

Se você é um leitor assíduo do meu blog, já deve ter percebido o quanto gosto de testes automatizados. Não só gosto como acredito neles e no retorno que eles proporcionam. Sempre que tenho a oportunidade procuro “vender esse peixe”. O interessante é que com isso acabei escutando alguns exageros que chegam a ser engraçados.  Um exemplo foi após uma conversa em que até rolou uma  sessão de codificação em par com a pessoa, no final, ela soltou a seguinte pérola :”Agora então não preciso mais do pessoal de teste“.  Opa! Devagar com o andor que o santo é de barro, meu amigo.

Antes que concorde com isso,  deixa eu mostra meu ponto de vista.  Teste automatizados ajudam muito e realmente tornam a vida do desenvolvedor e do cliente melhores.  Torna a vida do desenvolvedor mais fácil quando permite que ele faça seus testes rapidamente e detecte um erro o mais cedo o possível.  Para o cliente significa que a automação mais testes podem ser executados num tempo menor e com isso mais qualidade com menor custo.  Mas e a história do cara de teste, onde entra? Calma.  Para automatizar os testes devemos fazer algumas considerações e escolhas.  Para facilitar o que quero ilustrar, imagine um portal. Portais são aplicações webs muito interessantes, pois a cada acesso o seu comportamento pode mudar e isso não é necessariamente um erro.  Por isso, testes automatizados, em ambientes como estes são bem complicados de serem feitos e levam a gente a fazer algumas “adaptações”. Com isso,  os teste acabam validando parte das coisas e logo, ainda temos a necessidade de uma pessoa testando.  Entretanto, agora, essa pessoa não precisa estar testando tudo e qualquer coisa. Ele pode focar um pouco mais, realizando apenas verificações pontuais.

Outra frase que sempre escuto é a questão do recurso e gastos.  Geralmente quando converso com os gerentes sobre testes – principalmente os ditos PMI – eles quase que instantaneamente dizem que isto é inviável e trabalhoso. Bom, primeiro devemos definir o contexto:  se imaginarmos os famosos “cowboys“, rapaziada que desenvolve a culhão e não teste se o objeto que eles estão pegando é nulo, realmente testes automatizados são trabalhosos, pois não fazem nenhum.  Para aqueles que pretendem o mínimo de qualidade, dá para dizer que, realmente, NO INÍCIO,  testes automatizados demandam mais tempos, mais se olharmos ao longo da linha tempo esse custo se dilui e tende a zero. Isso porque, após todos os casos criados, o trabalho será de executá-los e mantê-los atualizados.  Fora que, imagine o custo de pessoas, máquinas, tempo,  para que a cada alteração que um desenvolvedor fizesse na aplicação, toda ela fosse retestada.

Enfim,  caso ainda não acredite em mim quando digo que ferramentas de testes são legais e estão aí para nos ajudar,  experimente e tire suas próprias conclusões. Duvido, sendo você empresário, gerente pmi, coordenador, desenvolvedor, cliente, etc no final não ficará pelo menos tentado a usar algum no seu próximo projeto.

Uma das coisa que me incomondam bastante é toda vez que vou iniciar um projeto, e tenho que montar um ambiente de desenvolvimento, perco horas e mais horas para completar a tarefa. Tudo porque, na maioria das empresas para as quais trabalhei, trabalho e trabalharei,  nunca tem um processo automatizado e padronizado de montagem de ambiente.  Sei que isso pode soar um tanto burocrático e o pessoal que odeia qualquer coisa que possa virar papel vai dizer que isso é uma heresia, mas acredito que é um mal necessário.
Para a grande parte das pessoas que começam numa nova empresa, projeto, etc, a rotina sempre a mesma :  horas baixando instaladores,  horas instalando tudo (pior se for em windows, pois as vezes tem que dar reboot na máquina), mais um monte de outras horas para configurar, criar usuários, baixar código, entender como funciona o build, e por aí se vão dias de trabalho gerando zero de valor agregado para o cliente.  O mais esquisito, que mesmo sendo isso um mega prejuízo para o projeto – uma pessoa consumindo horas do projeto sem fazer “nada” , não existe nenhum movimento para mudar essa realidade.
Não estou falando de processos ultra-automatizados que lê mentes e pelo jeito que você diz bom dia monta a sua máquina,  estou falando de coisas simples, como padronizar, repositórios internos de instalações e bibliotecas, uso de produtos que automatizem build e tarefas repetitivas, etc.  Estou falando também de, no caso de empresa maiores,  uma imagem de ambiente (backup) padronizada para que quando um novo desenvolvedor chegue, basta comprar um novo computador, baixar a imagem e configurar.
Não faltam ferramentas, produtos e soluções no mercado que podem ajudar a qualquer um a resolver isso. Em aplicações java, temos o maven (maven.apache.org) que pode cobrir muito bem quase toda o problema:  ele pode montar o projeto, instalá-lo, baixar as bibliotecas, configurar ambiente, compilar e fazer build, etc; além dele existe a opção de escrever em ant (ant.apache.org)  diversos scripts para automatizar build de aplicação, montagem de ambiente, etc. Em Ruby,  aqui não muito minha praia, acredito que existe o gems e o rake que facilitam bem esse trabalho.  Para os passo não cobertos por essas ferramentas, existem outras.  Em última instancia, pode ser colocado como uma história do sprint ( ou uma tarefa de backlog) e assim criar um programa que faça isso (bash, bat, cmd ,etc).
A questão mais importante é que exista algo padronizado e de preferencia automatizado, fazendo que se perca o mínimo de tempo possível com tarefas que não agregam valor ao cliente que está pagando.  A ideia é exatamente de não perder tempo com coisas que não geram retorno: atividades repetitivas, processos  que podem ser automatizados e outras coisas, maximizando o foco na funcionalidade.

Simplesmente considero que a informática (entenda-se todo desenvolvimento e criação de produtos) ligada a engenharia e industria está andando na contramão do progresso de TI.  É impressionante a quantidade de ambientes, softwares, ferramentas, etc… que se mantém num modelo proprietário de “caixinha” (você tem que pagar a licença pelo aplicativo, licença para usar um recurso, e por ai vai a exploração) . Fora isso, para mim um dos “pecados” mais grave é a questão de muitos não possuírem versões para outros sistemas operacionais que não o Windows. Um exemplo clássico disso é o Autocad, sistemas de supervisório (Factory Link, RSView, etc), sistemas de acesso ao plc (RSLinx), etc.

Dados recentes de censos promovidos, acredito que no Estados Unidos, mostram um crescente número de pessoas que estão usando outros S.O (sistemas operacionais). Dentro estes outros, existe um destaque para o uso de MAC OS (cuja a última versão é o Snow Leopard) .  Isso se deve a fatos como estabilidade maior, menor vulnerabilidade, robustez, menor custo de licença (no caso de distribuições linux elas são de graça), desempenho, entre muitas outras coisas. Hoje entre desenvolvedores (que não usam o .NET  - por motivos meio que óbvios) é quase que um consenso que a melhor plataforma (máquina e SO) para trabalhar são Mac Apple (iMac, Mac Book …)

Porém quem trabalha com automação ou com desenvolvimento de sistemas do tipo MES – supervisórios – tem a dependência de alguns produtos. Se você for desenvolver um ladder precisará de uma ferramenta para conectar ao PLC e fazer o upload e download. Se você for desenvolver um supervisório, precisará de ferramentas para desenvolver, outra para conectar ao PLC e outra para mostrar as telas. Todas estes aplicativos, com raras exceções, são proprietários e só tem versões disponíveis para Windows.

Num mundo onde cada vez mais se discute a questão do software livre, novos modelos de negócio, sistemas multiplataformas, fim de monopólios, esse tipo de comportamento se coloca justamente na contra mão  de toda uma realidade atual. A questão que mais me choca é, estes fabricantes, quando perguntados porque dessa postura nada respondem ou são extremamente evasivos.

Exemplos não faltam e justificava para que não façam também. Posso citar um caso de empresa onde trabalho. Lá temos um fornecedor de PLCs. Gastamos bilhões (isso mesmo) anuais em compra deste equipamentos. Porém, para podermos trabalhar com eles (conectar, alterar o programa ladder, ver estado de bits, etc) temos que ainda pagar milhares (cada licença custa em média mil dólares) por sistemas. Ou seja, a empresa ganha dinheiro com tudo. Além disso, caso queira fazer um sistema seu para fazer oque as ferramentas deles fazem, não tem como pois usam de protocolos proprietários e cada  especificação chega a custar muitas centenas de milhares de dinheiro.

Outro exemplo é o nojento do AutoCad. Hoje todos os desenhos de engenharia são feitos nele (em alguns casos muito especificos usamos outros aplicativos). Ele só tem versão para Windows e cada licença custa uma verdadeira fortuna. A diferença do caso anterior é que pelo menos existem outras opções.

Enfim, quando todos caminham para se libertar de SOs e de modelos retrogrados de licença tipo caixinha, o pessoal da engenharia continua nos tempos da caverna achando que são vanguardistas usando telas coloridas para seus sistemas.

Em aplicações industriais existe algo que o pessoal que as desenvolve chama de alarme. O alarme, para o pessoal do corporativo entender, é algo mais que avisos de tela e arquivos de log da aplicação. É assunto sério e a atenção para ele vem aumentando ultimamente.

Um sistema industrial, na maioria dos casos, é feito para supervisionar um processo ou planta. Por isso sempre é muito rico em sinópticos (telas com representações gráficas/ esquemáticas  das plantas ou processos).

Imagem exemplo de sinóptico da feg unesp

Tais sinópticos são ricos em uso de cores para alerta, sinalizações de falhas, aviso de equipamento em uso, etc. Tudo isso visando facilitar a vida do operador. Entretanto, só isso, no mundo atual onde a redução de pessoal é meta de grandes (mas isso é papo para outro post), não basta. Por vezes, o próprio automatismo, pode detectar um situação insegura é alertar ao operador, inclusive, sugerindo uma ação, por exemplo: “Nível pressão do oléo alta, abrir válvula de alívio”. Esses avisos, textuais, são os alarmes.

O uso dos alarmes, até então, era mais como avisos de falhas, alertas de manobras, etc. Porém isso vem mudando e ganhando novas cores e atenções por parte de todos.  Notou-se que os alarmes podem ser mais inteligentes, sugerindo criticidades, ações imediatas, etc .. servindo como um guia para operador.  Além disso, os alarmes,  também representam uma fonte importante do comportamento da planta, máquina, processo, etc.  Esses dados podem ser usados para uma otimização ou redução de tempos de paradas por conta de falhas redundantes.

Alarmes são coisas sérias e tem padrões e regras.

Muitos que nunca participaram de grandes projetos (grandes não em tamanho mais em qualidade e desenvolvimento e complexidade) podem, num descuido, considerar alarmes algo que possa ser feito de qualquer jeito, sem grandes explicações ou padrões (regras) a serem seguidas ou adotadas. Mas o pessoal da ISA, principalmente, através de suas publicações e etc, vem mostrando exatamente o contrário.

Em edição recente da Revista da ISA (InTech Brasil ed 113), não faltam matérias sobre o assunto como estudos de casos,  projetos de implatanção, etc.  Para verem quão importante é isso.  Por exemplo, existe uma norma ISA, em vias de finalização, senão me engano sobre a gestão de alarmes (ISA SP18.02).

Pessoal segue abaixo um link para o blog do Denis Leite…. O conteúdo não é tão de TI e sim mais voltado para a questão de automação, porém é super bem escrito, interessante, vale a visita

Blog do Denis leite

Recebi este mês a revista da ISA (InTech), americana, de maio, e ela traz uma reportagem interessante sobre o uso de Wireless em redes industriais e de dispositivos. Falo nela pois, algumas pessoas tem me perguntado, seja por e-mail (a maioria) ou por comentários (acho que um só até agora) sobre a questão do uso desta tecnologia. A maioria das questões que recebo são sobre a questão da confiabilidade e na questão de segurança. Bem, vejamos se consigo responder alguma coisa.
Muitos poderiam dizer que redes wifi são inseguras pois permitem que alguém que esteja dentro da área cobertura entre na rede, mas acredito que isso é relativo. Posso dizer que um rede com fios também é insegura pois basta alguém ter acesso a um ponto de rede, e este também poderá entrar na rede. Claro que os mais conservadores diriam – “para acessarem um ponto de rede tem que entrar na minha empresa antes”… Concordo, mas o que vejo na realidade é que numa industria, por exemplo, temos um “mundo” de empresas e pessoas trabalhando que poderiam facilmente entrar em nossa rede. Além disso, dado a convergência atual, já existem redes que possuem roteamento para redes externas, abrindo uma porta para um invasão. Posso adiantar que os equipamentos modernos, que suportam padrões IEEE (802,11…)possuem suporte a criptografia de dados (chaves do tipo WEP,etc) que permite que apenas pessoas “autorizadas” possam trafegar dados em sua rede. Além disso, os roteadores novos, também possuem filtros de ip, filtros de mac address,etc. Entretanto, como um especialista me disse uma vez, isso é apenas um parte todo, existem outras medidas que devem ser consideradas e que não tenho tanto conhecimento para discorrer aqui.
A outra dúvida é questão da confiabilidade , sendo mais aplicável a redes sem fio de maior alcance (3G, GPRS, etc). Muitos fabricantes apresentaram equipamentos cujo a conexão é wifi no mercado, como por exemplo, botoeiras (isso mesmo). Ai vem logo a pergunta: “Se a conexão falhar e precisar acionar o botão como faço ? Se tenho um equipamento critico?”. Bem, na minha opinião, esse problema existe mesmo se não usarmos redes sem fio: o fio do botão pode falhar, o cabo de rede quebrar, etc. Para isso, existem os estudos de risco e redundância. Se a operação é critica, logo maior deve ser a tolerância a falha e a redundância utilizada. Você adotar uma regra : para acionamentos de segurança não usar rede sem fio, por exemplo.
É sempre bom ressaltar que para o uso de rede wireless existe um conjunto de normas publicadas pela ISA que vão no sentido de ajudar, esclarecer e guiar as soluções.
Bem oque para mim fica claro que não podemos ignorar simplesmente esta tecnologia pois ele vem com promessas de melhorar muito nossa vida. Poderia citar aqui a questão de redução de custo ( menos infrastrutura de fios, etc), facilidade para aumento de parque, facilidade em conexão de plantas distantes, etc. Além disso, como o artigo que citei acima diz, existem diversos aspectos que estão sendo considerados que vão mudar de forma significativa a forma que fazemos redes em automação.
Fiquem ligados que vou tentar escrever outros posts, com um jeitão mais tutorial para ver se ajuda !!

Em meu trabalho atual, devido a natureza dos sistemas serem industriais e com isso poderem se ocorrer algum defeito parar a linha de produção, sou obrigado a ficar de plantão ou prontidão (como queiram chamar). Esse plantão me proporciona situações no mínimo interessante e algo que gostaria de comentar.
Uma das primeiras coisas que aprendi ao longo desse trabalhando, é que se existe algo que funcionava e “de repente” parou de funcionar, devemos procurar o que mudou, qual é o fato novo em relação a antes. Pode parecer óbvio, mas nem sempre que “atuando” no problema tem essa percepção e por isso faz diagnósitcos errados, precipitados e podem nos levar a um caminho ruim caso sejam eles nossos interlocutores. Uma outra coisa legal que venho fazendo e posso dizer que funciona é a técnica do 5 por ques: nada resiste a isso. Certamente, caso quem esteja falando com você for minimamente inteligente e honesto, em menos de 5 por ques você chegará a causa raiz do problema. Uma outra coisa interessante é aprender a transformar um problema grande em diversos pequenos problemas. Ao fazer isso, fica, aparentemente, mais fácil de atacar, pois você atua em ordem e prioridade e vai restabelecendo o funcionamento aos poucos.
Tudo isso, como já disse antes, pode parecer óbvio mas em quase totalidade dos casos que sou “acionado” por alguém devido a um problema em um sistema, quase sempre o pessoal que está lá não fez nenhum tipo de analise preliminar, muito menos seguiu os passos acima. Até mesmo colegas de equipe teimam em não seguir este passo a passo. Não quer dizer que caso você o siga, todos os seus problemas irão se resolver, não é isso! A questão que o procedimento acima ajuda a organizar a forma de “atacar” evitando assim aquela enxurrada de esforço inutil.
Voltando a técnica que uso, geralmente, caso esteja disponivel, gosto de analisar os problemas com o quadro branco: primeiro faço uma lista de quais foram as modificações feitas nos últimos dias que possam afetar o funcionamento do sistema; faço um desenho “espinha de peixe” para saber quais são os pontos envolvidos naquele processo e assim determinar quais são os potenciais pontos de falha. De posse destas duas coisas, eu passo a analisar. Uma outra coisa é tentar reduzir ao máximo o universo de atuação. Isso se obtem pela simples exclusão das variaveis envolvidas. Desligue parte do sistema, emule o banco de dados, faça testes na rede, etc.
Por fim, se tudo não funcionar peça ajuda a Deus… brincadeira, creio nele mas pode pedir ajuda para um colega com a cabeça mais tranquila e fresca que a sua

Esse post é para eu lembrar como se faz para resolver um problema. Quando tenta-se conectar a um RDB que está num alpha via ODBC (tem que ter o driver para isso) e aparece o erro [ORACLE][ODBC][RDB]RDB-F-BAD_DB_HANDLE ….
As configurações do obdc, em meu caso pelo menos, são: Service : Generic e String : attache ‘filename file$db’;
Googleando a internet achei que a solução seria (funcionou no meu caso)
1 – Log no seu aplha
2 – Vá para o diretório sys$manager
3 – Veja o log do banco ( faça um dir por dir *SQLSRV_DIS*.LOG
4- Entre no arquivo… nas últimas linhas deve aparecer algo parecido com :

A origem deste problema vem da questão da versão do SQL que está sendo executado (Versão 7) sendo assim é necessário mudar a versão do serviço generic para a 7.1 , para isso tem que ser feito os passos

1- Va para o sys$system
2- execute run sqlsrv_manager71
3 – Vai aparecer o prompt SQLSRV
4 – Digite o comando : show service generic full;

5 – Execute a sequencia

Alguns conhecidos que lêem este blog me pediram para escrever mais post sobre a questão de como um programa Java poderia conversar com um PLC. Posso adiantar que a tarefa não é da mais simples e, como dizem em diversos foruns do assunto, coisa para que tem “coração forte”. Primeiro, muitos dos que vão se aventurar a fazer algo do genero vão perceber que a quantidade de informações nesse sentido são pouquíssimas e as tem, em sua grande maioria, são pagas. Passei bons meses vasculhando a internet (Deus abençoe o Google ) e o resultado por vezes foi desencorajador.
A maioria dos fabricantes de PLC tem adotado o OPC (OLE for process control) disponibilizando aplicativos para so Windows que expões as tabelas de dados dos plcs através de servidores OPC. Com evolução crescente dos equipamentos, alguns já nem precisam mais do aplicativo e permitem o acesso eles mesmos através de cartas especiais, mas isso é assunto de posso escrever em outro post. O Opc foi algo especificado na tecnologia da Microsoft. Como é algo M$ é facil concluir que toda a gama de produtos da M$ tem este suporte, assim como o seu .NET (suporte nativo através do ActiveX e DCOM) . JUntando outros motivos e o citada anteriormente, tem-se hoje um predileção a escolher a plataforma Windows para o desenvolvimento de drivers, e aplicativos SCADA o que explica a raridade de opções em outras tecnologias e SO. E não é diferente com java.
Alguém poderia dizer ao ler os paragrafos acima que seria simples: “Basta escrevermos uma bilbioteca OPC em Java que está tudo pronto”. Sim, concordo em parte e digo que quem se candidatar faça-o e depois permita que utilizemos sua API pois esta não é uma tarefa nada facil. Um outro caminho seria partir para implementar algum protocolo particular do plc em Java. Bem isso pode ser um caminho, pois alguns deles estão escritos em C seria algo como um engenharia reversa. A questão que temos que pagar por suas especificações ou bibliotecas e fazÊ-lo seria um violação das leis.
Nos sobram poucas possibilidades (bem poucas).
A maioria das opções válidas são pagas e as open source existentes cobrem apenas uma pequenas parte e tem aplicações muito específicas. Uma outra opção seria escrever algo em JAva que acessaria a um driver de um fabricante e por meio deste faria o acesso (é deste jeito que meus programas em .NET fazem). MAS COMO ACESSAR O DRIVER ESCRITO PARA Windows? Bem, a maioria deles expõe seus serviços por meio de DCOMs, bastaria que seu java falasse este “protocolo”. Para tanto, antes que o leitor comece a escrever suas classes através do JNI sugiro uma olhada na api j-Interop. Vale a pena e funciona.
A minha intenção é juntar um pessoal para escrevermos uma biblioteca de acesso em java sobre a licença LGPL. Assim que conseguir aviso a galera.

Ultimamente meu trabalho tem me demandado bastante fazendo com que não tenho muito tempo para escrever aqui. Gostaria de escrever hoje sobre uma questão que acredito seja de interessante e que muitos que trabalham com sistemas industriais já tenham passado. Como já disse em outros posts neste mesmo blog, embora a informática seja a mesma, tudo que é feito voltado para a plataforma industrial tem certas particularidades: o pessoal é muito conservador quanto as soluções, evita-se ao máximo tecnologias que não estejam muito maduras, e as soluções são de certa forma bastante redundantes e antigas do ponto de vista do pessoal que trabalha em TI. Um exemplo é que em muitas empresas opta-se por comprar dois servidores por sistema mesmo que este não vá demandar um processamento que justifique um servidor dedicado e por ai vai.
Outro dia estava fazendo o levantamento de compra para um projeto que estarei fazendo ao longo do ano. Nesta lista deve ser previsto todo material, licenças, software, etc necessários para que seja implantada a solução. Nisso, acabei optando por não comprar um servidor pois já tinha um que estava com outro sistema instalado que não utiliza nem 10% da capacidade disponível. Qual não foi minha surpresa, quando meu chefe pediu que eu modificasse a solução proposta e que em minha lista de comprar colocasse não somente e sim dois servidores para o sistema novo. Vendo minha expressão de supresa, ele me explicou que preferia não arriscar, ou seja, preferiu-se gastar mais algumas centenas de reais para que caso aconteça um problema com o servidor eles não percam muita produção pois dois sistemas estariam na mesma máquina.
A explicação até que faz sentido, embora, que um servidor bem acondicionado (sala climatizada, com pisos corretos, sistema de proteção, etc) tem uma probalidade de quebrar muito reduzida. Fora isso, o custo da manutenção de um servidor por sistema é grande pois a dificuldade de backup é maior, maior é o consumo de energia, o custo de armários, etc.
Acredito que o pessoal da industrial precisa “baixar a guarda” e permitir inovações ou usar oque vem dando certo para a informatica corporativa. Hoje sites de banco, de bolsa de valores, que são aplicações críticas, já estão em data center ultra enxutos. Logo porque não trazermos esta realidade para a industria ?
A reatividade é grande e, olha, que nem falei em virtualização.