Blog do Andre Fonseca

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).