WinCC 7.0 – Não sabe brincar, não brinca.

Pessoal,

Sinceramente, cada vez que eu começo a falar de WinCC com as pessoas eu acho que elas pensam que estou exagerando ou ficando cego pelo produto.

Não! – Eu respondo. Não estou ficando cego, simplesmente estou sendo ouvido. Eu e milhares de desenvolvedores que sempre querem mais do WinCC. Sendo que a Siemens nos ouve ou se antecipa em relação as nossas necessidades.

Eu podia discursar durante páginas e páginas, porém acho que o product announcement do WinCC 7.0 diz por mil palavras. Vejam
http://www.automation.siemens.com/hmi/html_76/microsites/wincc-v7-overview.htm

Eu não posso deixar de frisar duas coisas:
Object-oriented Engineering:
Se for tão integrado ao Structure Tag quanto eu imagino, e principalmente, se foi melhorado a forma de criar e modificar os structure tags eu acho que outros produtos da Siemens vão ficar com inveja (te cuida PCS 7).
Esse conceito no WinCC Flexible é muito bom, então eu acredito que foi melhorado assim como foi feito no Flexible.

New WinCC Controls:
Eu quero ver se o WinCC 7.0 será um full .NET containner. Se for, meu amigo, tem mais um produto que vai ficar para trás dentro da Siemens. Será o bye bye do IndustrialX que nunca ganhou a importância que merecia!

Em tempo, só tenho a agradecer a Ana Cristina, gerente de HMI da Siemens pelo brilhante trabalho que vem fazendo dentro da Siemens. Divulgando e remexendo esse mercado de HMI.
Ana, agora você tem um porsche na mão, só vai precisar saber pilotar. E você sabe, né? Precisou é só gritar. Ainda está valendo a aposta do Plant Intelligence?

Esperem, pois depois de agosto vou ter mais bala na agulha para falar do novo WinCC 7.0, DataMonitor, Connectivity Pack, Downtime Monitor, IndustrialDataBridge, etc, etc, etc, etc (cansei).

Eu só queria saber quem avalanca quem (PCS 7, WinCC e Flexible)!

Tutoriais de WinCC, Step7 e Outros

Pessoal,

Aqui vai um link para quem sempre me pediu apostilas e tutoriais de WinCC, Step7, Profibus e outros.
O material é baixado diretamente do site do Sitrain, que é a divisão de treinamentos da Siemens e é fornecido em Inglês. Aqui vai o link: https://www.automation.siemens.com/fea/html_76/down_module.htm?HTTPS=REDIR

Abraços,

Márcio Roberto

Publicado em CLP, PLC, SCADA, WinCC. 2 Comentários »

Parceiros para Desenvolvimento de Software Livre

Pessoal,

Há muito tempo eu desenvolvi uma ferramenta para poder exportar tudo quanto é dado do WinCC para o Excel, na época o que eu desenvolvi, usando VB6 (veja o link), não ficou legal apesar de funcionar normalmente.

Agora eu estou querendo reescrever o programa só que dessa vez usando melhores técnicas e práticas. A começar, usando .NET com orientação a objetos, design patterns, refactoring e tudo mais.

Sinceramente vai servir de base para implementar alguns conceitos que venho estudando, pois o acesso aos dados do WinCC usando Connectivity eu já domino. E vai por mim é uma grande ferramenta.

Dependendo de como a ferramenta for implementada, pode vir a se tornar uma ferramenta para diversos tipos de SCADAs.

Então, com isso eu estou procurando alguém que queria entrar nessa empreitada comigo, para desenvolvermos um sistema juntos, com código fonte aberto ou GNU.

Então o perfil das pessoas que estou procurando é:
- Desenvolvedor VB.NET, não precisa ser especialista. Mas tem que ter conhecimentos em orientação a objetos e alguma coisa de refactoring. Se conhecer o básico de design patterns, melhor.
- Opcional: Que conheça o WinCC ou outro supervisório.
- Que queira desenvolver algo em regime de software aberto.

A idéia é abrir um projeto no sourceforge.net e manter o projeto lá.

Quem quiser participar, me manda um e-mail.

Abraços,

Márcio Roberto

Publicado em SCADA, VB, WinCC. 4 Comentários »

Reencontro

Pessoal,

O ano começa prometendo novos desafios. E para mim, dentre inúmeros desafios, coloquei como desafio manter o blog atualizado durante esse ano. E para tanto vou colocar aqui os inúmeros posts que estão no forno ou que estão previamente formatados ou que ainda não passam de masturbações mentais.

Mas vamos lá, são eles:
- Tutorial de IEC61131-3. Incluindo exemplos, principais diferenças, vantagens e desvantagens e se possível colocar alguma coisa de CFC.
- Tutorial sobre o uso de componentes e bibliotecas (OCX e DLL). Incluindo exemplos de como criar, declarar e reaproveitar componentes. Recentemente fiz uns testes criando componentes COM utilizando o VB2005 e chamando os mesmos dentro do WinCC. Pretendo tomar essa prática padrão daqui pra frente.
- Tutorial sobre o acesso a dados no WinCC. Explicando os conceitos de ADO, o uso de RecordSets e principalmente o Connectivity Pack do WinCC, que pra quem me conhece sabe que é uma das ferramentas que eu mais gosto no WinCC.
- Um How To sobre como abrir blocos travados do Step7 e se possível do WinCC, e ver se ajudo a abolir de uma vez por todas essa praga de travar blocos.
- Finalizar um programa para exportar dados do WinCC para N formatos. Nesse desafio eu estou procurando parceiros.

E se tudo ocorrer bem, começar a discutir algo que eu acho que vai dominar o mercado de automação daqui pra frente. Business Intelligence. Acabei de participar de um workshop que mostra o BI usando o SQL Server 2005 que acompanha o WinCC. Fiquei de queixo com as possibilidades de utilizar algo que no mercado de TI já é o diferencial.

E muito, mas muito mais. O que me falta é tempo.

Publicado em CLP, PLC, SCADA, VB, WinCC. 1 Comentário »

Quem procura acha, Siemens na faixa!

Pessoal,

Procurando um manual achei duas páginas que sempre me perguntaram se existiam, e eu nunca soube responder.

1. Vários vídeos explicativos do STEP7.
http://support.automation.siemens.com/WW/view/en/21064133

2. Download do STEP7 demo (versão Lite)
http://support.automation.siemens.com/WW/view/en/22764522

Ambos as páginas estão na área de documentação da Siemens. Espero que possa ajudar as pessoas as desmitificar alguns mitos. Gostei muito do vídeo sobre a integração do STEP7 com as IHM/WinCC.

Não me perguntem as limitações do STEP7 Lite, pois não instalei, mas talvez seja mais seguro “brincar” com essa versão do que as versões do Astalavista ou do Emule.

Abraços,

Márcio Roberto

Como você detecta os erros no seu sistema?!

Recentemente o Gabriel me questionou sobre como detectar falhas de comunicação entre um Mestre DP e seus Slaves no S7-300/400, e disponibilizar as falhas da CPU/Sistema no SCADA.

Citei algumas formas de como fazer isso,  que você pode ler logo abaixo nesse post. O legal do questionamento do Gabriel é observar que o mercado, cada vez mais procura fazer softwares de qualidade e que forneçam informações consistentes ao usuário, seja ele da manutenção, operação ou engenharia.  Parabéns ao Gabriel, e que mais pessoas passem a utilizar essas práticas.

Dentro do S7-300/400 costumamos classificar os erros em dois tipos básicos: Erros de Sistema e Erros de Funcionamento. 
- Erros de sistemas são geralmente erros detectados pela própria CPU/sistema e tendem a levar a CPU para o estado STOP, como exemplo erro de acesso a periferia.
- Erros de funcionamento são erros não detectados pela CPU, e geralmente ocasionam instabilidade no processo, como exemplo erros de lógica.

Em ambos os casos o STEP7 provê ferramentas de diagnósticos para identificar tais erros. Estas ferramentas podem ser as tabelas de monitoramento de variáveis (VAT), monitoramento online do programa ou o poderosissímo diagnósticos de hardware .
E quais são as ferramentas que o STEP7 provê para que o próprio programa do usuário detecte estes erros, sejam eles de funcionamento ou de sistema?
A resposta é muito simples, a excessão dos forces (não força vai, tem soluções melhores) o STEP7 permite que o programa detecte tudo o que está acontecendo no sistema, e dessa forma o programa pode tomar uma decisão, como desabilitar uma determinada rotina ou simplesmente mandar uma mensagem para o SCADA/IHM.

Vamos citar alguns exemplos, sendo que não entrarei em muitos detalhes de como implementar, pois o espaço aqui é resumido e tornaria o post um pouco indigesto. Mas como sempre, se perguntar eu respondo. Só não respondo mais nada por e-mail. Suporte Técnico da Siemens é no 11-3833-4040. Brincadeira, respondo sim, mas tem que ser no blog, para ficar disponível para todo mundo.

  • Detectando Erros por OBs.

Eu, particularmente não gosto de usar os OBs.
Bom, OB (organization block) é a maneira como a CPU interage com o seu programa, vale lembra que você nunca chama um OB, é sempre a CPU que decide o momento em que um determinado OB deve ser executado. O principal OB num programa é OB1, onde origina-se a grande maioria do seu programa, pois este é o OB cíclico que é executado após o término do ciclo da CPU.
Dessa forma, assim como existe o OB1 para uma determinada condição, existem outros OBs específicos, como por exemplo para situações de erros detectados pela CPU. Estes OBs geralmente estão entre a faixa do 80 ao 87 para erros assíncronos (ex, falha de um canal analógico) e na faixa do 121 ao 122 para os erros síncronos (ex, leitura de endereço inexistente).
Como todo bloco, o OB usa dados em sua local stack ou área L através de variáveis locais, sendo que no caso dos OBs a CPU vai disponibilizar diversas informações sobre o motivo do OB estar sendo executado, como por exemplo, timestamp do horário de execução do bloco, endereço do módulo que ocasionou a falha, tipo do módulo, tipo da falha e por aí vai. O que o seu programa pode fazer é analisar estes dados e em função dos valores, que são devidamente documentados nos manuais, diagnosticar o tipo da falha num determinado módulo. Aqui você pode estar se perguntando “Vou ter que analisar um monte de variáveis para detectar um erro” e a resposta é sim, vai! Felizmente, você que não é bobo nem nada vai criar um bloquinho que faça isso e você só vai chamar esse bloquinho dentro dos OBs. Nada mais simples.
O motivo de eu não gostar de usar OBs, é que preciso saber o OB que vai ser chamado para uma determinada falha. E também pelo fato do OB ser chamado duas vezes, uma para quando a falha for detectada e outra para quando a falha for sanada.

  • Detectando Erros por SFC/SFB.

Um dos maiores prazeres que tenho em programar é ver o SFC51 no STEP7, é o verdadeiro faz tudo. De uma olhada na documentação do STEP7 pra ver o que é possível fazer com ele. Basicamente você pode consultar o status de qualquer módulo com o SFC51. Você pode por exemplo, consultar se um módulo possue alguma falha, pode diagnosticar se o conector de uma placa foi retirado, se um canal analógico de 4..20mA está com quebra de fio, se a CPU está com alguma falha interna/externa ou mesmo se a CPU possue algum sinal forçado (O pessoal de manutenção odeia esse, pois geralmente eu coloco essa condição no SCADA, ai fica logado quando um sinal foi forçado…he he he).
A grande sacada do SFC51, é que ele na realidade consulta o status list da CPU/Módulo e pode informar simplesmente todas as informações disponíveis no módulo. Evidentemente alguns módulos possuem mais informações que outros, portanto consulte a documentação dos seus módulos para maiores informações. O uso do SFC51 também é bem simples, basicamente para cada tipo de consulta ele retorna uma struct, e nessa struct está o resultado do que você consultou. Para maiores informações de uma olhada no www4.ad.siemens.de. Uma vez que você tem o status de um módulo, você pode fazer o que você quiser com ele. Desde bloquear uma lógica, até mesmo mandar uma informação para o SCADA.

Existem outros SFC/SFBs para diagnosticar erros e falhas, tipo erros em redes DPs e por ai vai. Como sempre de uma olhada na documentação do STEP7.

AGORA, se você usa o STEP7 em conjunto com o WinCC, eu sugiro que você não recrie a roda. Você pode utilizar o conceito de TIA (Totally Integrated Automation ), onde é possível abrir o Hardware Diagnostic do STEP7 direto do WinCC, e com isso visualizar na apartir do SCADA erros em seus módulos. É possível visualizar até mesmo a lógica do PLC diretamente no SCADA, usando funções com o Ladder Rung Jump ou então visualizar processos sequencias com o Pro-Agent/Sequential Function Chart(SFC) ou S7-Graph.
Ainda no caso do WinCC, existe um controle ActiveX da Siemens, o qual eu nunca usei, que pode ser integrado ao WinCC que irá exibir as mesmas informações disponíveis no Module Information do STEP7.

Bom, resumidamente é isso. Existem muitas outras maneiras de diagnosticar falhas, que variam de sistema para sistema, e estas são as formas que eu realizo os diagnósticos.

Abraços,

E bom uso.

Márcio Roberto

Quanto vale a sua informação? Parte 2 de ∞.

No post anterior dessa série, levantei a questão de como os sistemas de aquisição e armazenamento nos SCADAS são sub-utilizados. Na realidade eles são sub-utilizados, pois estes sistemas são configurados de forma que não geram informações com valor agregado aos seus consumidores.

Neste post, irei relatar um processo onde tentei convencer o cliente a como maximizar a utilização do SCADA, de forma que as informações pudessem ter valor agregado, sem ter que utilizar sistemas complexos na aquisição e armazenamento destas informações.
Neste projeto estava sendo utilizado a seguinte configuração:
WinCC 6.0
Banco de Dados: SQL Server 2000 (Nativo do WinCC)

A idéia básica de meus argumentos era demonstrar como diferentes configurações afetavam diretamente a quantidade de informações armazenadas, bem como os processos de visualização e análise das mesmas.

O cliente em si, é um grande player da área de energia, sendo que está acostumado a utilizar sistemas dedicados de análise de informações, tais como oscilopertubografos e dataloggers, e não via nas informações de curvas de tendências do SCADA grande importância, tanto é, que algumas configurações básicas, a princípio, poderiam atender as suas necessidades.
O grande problema é que a utilização desses sistemas de análises complexos em certos projetos é inviável, devido ao alto custo de aquisição e implementação dos mesmos, e principalmente pelo excesso de informações geradas nesses sistemas, que pode levar ao abandono no uso de tais ferramentas por pessoas com menor nível técnico, no caso, a grande maioria dos operadores. Logo o operador acaba por não utilizar nem as ferramentas do SCADA nem as ferramentas dos oscilopertubografos.

Como o SCADA utilizado era o WinCC, não entrarei em detalhes técnicos das configurações, caso exista um interesse das pessoas que acessam o blog, poderei demonstrar futuramente como fazer tais configurações.

Para demonstrar o efeito prático dessas configurações, cadastrei 3 informações no sistemas de aquisição e armazenamento (Tag Logging), sendo que as informações seriam aquisitadas do mesmo tag no PLC, no caso uma onda senoidal representando variações de tensão do sistema, sendo que o valor desse tag oscilava entre 13300 e 14300, com período de 45s. Cada informação cadastrada no Tag Logging recebe o nome de archive, logo temos os seguintes archives:

- Curva Tensão_Continuos = Aquisição e armazenamento de 1s;
- Curva Tensão_Média = Aquisição de 1s e armazenamento da média de 30 aquisições (intervalos de 30s);
- Curva Tensão_Evento = Aquisição e armazenamento de 1 s, sendo habilitado o armazenamento quando o valor ficava acima de 13700 e sendo desabilitado quando o valor ficava abaixo de 13500.

Quando definimos se uma informação tem valor agregado, devemos levar em consideração a forma como essa informação será consumida. Exemplo, a informação representará uma variação brusca num sistema estável ou a informação representará a variação normal de um sistema instável?
Se a informação representa uma variação brusca num sistema estável, faz sentido plotar um gráfico com longos períodos, de forma a constatar essas variações.
Se a informação representa a variação normal num sistema instável, não faz muito sentido plotar um gráfico com longos períodos, pois é bem provável que a própria variação da informação “polua” visualmente o gráfico e dessa forma, não é possível analisar visualmente o gráfico, reflita um pouco sobre isso.

Para ilustrar bem esse conceito, abaixo está representado o gráfico de tendência de algumas horas, sendo que neste gráfico estão plotadas as 3 informações. Veja o quão poluido está o gráfico.

 Curva de tendência com as 3 informações ao longo de algumas horas

Por esse gráfico, simplesmente não é possível determinar o que aconteceu no processo, logo não seria prático nesse caso, plotar esse gráfico com o período utilizado, independente de qual curva queria se analisar.

Logo, vamos dar um zoom num período qualquer e analisar as 3 curvas ao mesmo tempo.

Curva de tendência com as 3 informações aplicando-se o zoom durante um curto per�odo

Perceba que agora fica mais evidente as variações sobre as informações. Lembrando que as 3 informações apontam para o mesmo tag, o que muda é a forma com as mesmas estão sendo aquisitadas e armazenadas.
Observando-se a curva Tensão_Continuos, é possível observar as variações durante todo o período de aquisição.
Observando-se a curva Tensão_Média, é possível observar que existiram variações em determinados momentos do processo. Evidentemente que toda média, ou tecnicamente falando, todo filtro de média atrasa a variação sobre uma informação, este atraso vai depender de como a média está implementada e a taxa de variação dessa informação. O importante aqui, é observar que foi possível constatar a variação da informação, mesmo com o atraso.

Alguém deve estar se perguntando, mas está faltando uma curva, a curva Tensão_Evento. E a grande sacada dessa configuração esta em avaliar que esta informação só é armazenada quando o valor da informação fica entre 13500 e 13700, logo esta curva esta sendo representada no gráfico, porém como a taxa de aquisição  dessa informação é a mesma da Tensão_Continuos, elas estão sobrepostas, irei provar isso no próximo gráfico, veja você mesmo.

Curva de tendência com as informação de Tensão_Evento aplicando-se o zoom durante um curto per�odo

Se o intuito da configuração do SCADA era registrar quando o valor da informação ficava no período entre 13500 e 13700, essa seria a melhor configuração, pois otimiza o banco de dados, visto que o sistema somente irá armazenar informações no período exato da ocorrência e principalmente facilita e muito a visualização e análise dessa ocorrência por qualquer pessoa.

Só por curiosidade, com a configuração proposta o espaço necessário à aquisição de dados desse cliente despencou de 17GBytes (Não se engane, seriam 17GBytes por ano) para 1.4 GBytes, e olha que nem foram implementadas todas as sugestões que nós propomos.

Sim! Se você está achando que seria só isso que o sistema tem a oferecer, eu te digo, esqueça! Tem muito mais, seria possível cadastrar um grupo com várias informações, e com a simples mudança de um tag todos os valores desse grupo seriam salvos, ou seja, pode-se utilizar o SCADA como um Oscilopertubografo. Será que estou exagerando? Não, não estou, pois o WinCC aceita informações, qualquer que seja ela, com resolução de 1ms, logo, eventos, curvas de tendências e qualquer outra informação nas tabelas do WinCC, poderia auxiliar no processo de um trip/ocorrência. E para tanto não é necessária nenhuma licença adicional, nenhum software adicional. Estou falando do core básico do WinCC.

É possível até mesmo o WinCC receber estes dados prontinhos do CLP, na forma de buffer, restringindo o envio do buffer à 64kB por send!!!. Tá bom ou quer mais? Quer mais? É possível que o CLP leia o buffer de um datalogger, de um oscilopertubográfo e disponibilize no supervisório, tudo isso com resolução de 1ms real e não por polling. O que você prefere, polling ou change of state. Eu sempre fico com change of state, como nós programadores, gostamos de dizer, é o sistema mais elegante. Mais elegante e eficiente.

Bom, eu poderia parar por aqui, mas com eu sempre me empolgo quando o assunto é analise de informação ou tecnologia de informação, eu vou cutucar mais um pouquinho. E se você quisesse disponibilizar essas informações na web, ou mesmo verticalizar o acesso à essas informações, ou em último caso, se você quisesse simplesmente disponibilizar estas informações numa planilha Excel.

 Bom, agora eu paro por aqui, até por que ainda estou fazendo meus testes com alguns  Web Services, por outro lado existem algumas formas de retirar as informações do banco de dados que alguns já usam e outros não conhecem, porém tudo isso fica para um próximo post.

 É importante frisar que as informações apresentadas nas curvas de tendência não possuem nenhum tratamento gráfico, como filtros gráficos, ou consultas especiais em SQL, são dados puros, direto do banco. Se eu fosse apresentar as formas como podem ser realizadas estas funções no WinCC, além de escrever um post muito grande, sendo que este já é um exagero, os usuários de outros sistemas iam ficar chateados de ter que usar SCADAS somente como gerenciadores de telinhas. Um pouco de diversão não faz mal à ninguém.

Abraços,

Márcio Roberto

Publicado em CLP, PLC, SCADA, WinCC. 2 Comentários »

Quanto vale a sua informação? Parte 1 de ∞.

Senhores, lanço aqui um desafio, e peço que definam agora um peso para aquele sinal (booleano ou inteiro) que é gerado no seu processo e é disponibilizado na sua IHM, seja ela qual for. Peço também, que compare ao final deste post se o seu sinal realmente tinha o peso que você imaginava.

De cara, por que ainda chamamos um sinal de processo apenas de sinal, por que não utilizamos um conceito mais atual, algo como informação. Um sinal quase sempre é associado a uma lógica, enquanto uma informação talvez encaixe-se melhor nos conceitos de fluxo e está imerso num contexto. Dentro deste contexto encaixam-se as etapas de lógica, bem como as etapas de visualização e análise dessa informação.

Há alguns meses eu venho conversando com outras pessoas do meio industrial, e discutindo como são implementadas as rotinas de aquisição, visualização e análise das informações em seus projetos.
Quase sempre, 90% dos casos, usa-se sempre a aquisição por polling, sendo os dados classificados em prioritários e não prioritários, onde os dados prioritários possuem uma frequência de polling maior e os não prioritários possuem uma frequência de polling menor. Com isso, praticamente as necessidades do projeto tendem a ser atendidas. Será?

Não é raro encontrar aplicações que aquisitam informações, por exemplo, com intervalos de 500ms, e disponibilizam as mesmas em gráficos de tendência.
Nesses casos, para não sobrecarregar o sistema, o gráfico de tendência é configurado para exibir os últimos 5 minutos, o que matematicamente representaria 600 registros no banco de dados. Não vou entrar no mérito se estes registros serão compactados ou não no servidor de banco de dados.
Caso o usuário precise de uma informação histórica, que foi registrada no dia anterior, e o usuário não sabe o horário exato dessa ocorrência, é comum o usuário solicitar as últimas 24 horas de dados no gráfico de tendência, o que representa 172800 registros.
Se estiverem associadas nesta curva de tendência mais 3 informações, serão aquisitados do banco de dados 518400 registros.
O tempo necessário para aquisitar estes 518400 registros vai depender de como os mesmos estão sendo armazenados, ou o termo técnico mais correto, persistidos.
Se estiver sendo usado um servidor de banco de dados SGBD, com index nas tabelas, cache em memória RAM e otimização de SQL o tempo necessário será muito, mas muito menor que uma busca pura e simples a um arquivo TXT ou XML, porém será necessário um tempo para realizar esta consulta.

Muitas pessoas podem estar afirmando que neste caso, uma boa máquina servidora, talvez um servidor dedicado somente às informações históricas utilizando um SGBD parrudo (MS-SQL, ORACLE, POSTGREE ou mesmo o MY-SQL) poderia resolver este problema, diminuindo o tempo necessário à consulta no banco de dados. E a resposta é, provavelmente sim.
E se ao invés de apenas um usuário, o acesso sobre estas informações fosse realizado concorrentemente por 5, 10 usuários? Se fossem 10 usuários, seriam aquisitados 1728000 registros, logo, se incrementarmos a memória RAM do servidor, implementarmos um cache mais esperto e em último caso aumentarmos o poder de processamento do servidor, com dois ou mais processadores, esta necessidade não seria um fator complicante em nossos projetos, há não ser que caímos na lei de Moore e ajudariamos a engordar a fatura de empresas como Intel, Oracle e Fujitsu.

Talvez o ponto a ser analisado seja outro.
Você precisa dessa informação na sua IHM com intervalos de aquisição de 500ms?
Se você ainda precisa dessa informação com esta taxa de aquisição, será que ela precisa ser continuamente aquisitada e armazenada?
Será que se ela fosse aquisitada somente quando necessário já não atenderia as necessidades do seu projeto?

Como disse, a situação descrita acima não é fictícia, ela é real. Exemplificando, podemos considerar algumas grandezas elétricas, tais como tensão, corrente e potência. É comum que nossos clientes solicitem que essas grandezas sejam aquisitadas com uma frequência que permita registrar algumas perturbações leves em sua rede. Observe, que usei o termo leve no sentido de uma pequena variação, como nos momentos que uma determinada carga é ligada, e acaba por provocar variações nas grandezas citadas. Evidentemente, se queremos uma oscilografia real, com formas de ondas, detecção de surtos e sequenciamento de eventos, uma aquisição de dados por polling de 500ms seria totalmente inviável. Nestes casos, fala-se de interlavos menores a 1ms, e nesse ponto, somente relés de proteção, osciloperturbografos e poucos SCADAs/PLCs conseguiriam atender as necessidades.
Voltando no caso de nosso cliente, que só quer saber e registrar que algumas mudanças em seu sistema ocorreram, é bem provável que o SCADA fique aquisitando essas informações durante 24 horas, 7 dias por semana e 365 dias no ano, para simplesmente registrar informações que só serão úteis em 10 ou 20% dos casos, os outros 80% das informações serão consideradas puro lixo.
Lixo este, que só vai encarecer o custo de manuteção do seu sistema, que vai sobrecarregar o acesso às informações realmente importantes, e principalmente, que pode aumentar suas previsões durante a fase de proposta, e fazer com que o valor de sua proposta fique muito, mas muito superior ao do seu concorrente.

Na contra-mão dos nossos pensamentos, estão os nossos concorrentes. Eles não se preocuparam com essas peculiaridades, pois é bem provável que eles vão “desconsiderar” os fatos acima, e simplemente configurem o SCADA para aquisitar as informações em frequências menores. Com isso, toda a infra-estrutura necessária será menor, inclusive os tempos para aquisitar as informações no banco de dados. Alías, será que eles vão usar um banco de dados, ou vão gravar as informações um arquivo texto?
E o cliente, nisso tudo? O cliente, meus amigos, só vai descobrir isso quando precisar das informações no SCADA, e ai pode ser tarde demais.

Por isso, agora eu peço pra vocês analisarem. Aquela sua informação de processo, ainda tem o mesmo peso, ainda tem a mesma importância, ou até o mesmo, o mesmo custo-benefício que você definiu ao iniciar a leitura desse texto? Reflita sobre isso.

Nos próximos posts, eu vou citar alguns exemplos de como contornar esses pequenos inconvenientes, e quem sabe tentar demonstar por que alguns supervisórios servem para somente criar telinhas, e outros, além do fazer o trivial de qualquer sistema SCADA, ainda permitem criar sistemas de informações complexos e realmente úteis. Fica ao gosto do freguês.

Bom feriado a todos.

Publicado em CLP, PLC, SCADA, WinCC. 1 Comentário »

Horário de verão, o meu pior pesadelo.

Os estados das regiões Sul, Sudeste e Centro-Oeste, além do Distrito Federal, adiantaram os relógios em uma hora desde a meia-noite do sábado (04/11). É o início do horário de verão. Ficam de fora as regiões Norte e Nordeste. Isso porque estudos já comprovaram que a economia de energia nessas regiões é insignificante. O retorno do horário normal será apenas em 2007, no dia 25 de fevereiro.

Pois bem, esquecendo os aspectos econômicos e sociais, o que sobra para nós, desenvolvedores e mantenedores de sistemas que possuem base de dados?
Na minha opnião, somente dor de cabeça. Dor de cabeça, pois nossos clientes vão nos ligar correndo para adiantar os relógios de todos os sistemas (PLC, SCADA, IHM..) da planta.
Se a planta ainda não usa uma ferramentas de sincronização de tempo, como servidores NTP, GPS e outros, o trabalho pode ser bem árduo. Caso a planta tenha algum destes sistemas instalados, é bem provável que você possa configurar os dias para a troca do summertime/wintertime. Dessa forma você pode ficar tranquilo, curtindo as happy hours que agora tem mais uma hora de Sol.

Analisando tecnicamente o que está acontecendo nas bases de dados, podemos verificar que na mudança para o horário de verão, a sua base de dados terá um gap (salto/buraco) de 1 hora, o que não é problema, visto que sistemas de supervisão mais inteligentes podem indicar a existência do gap.
O grande problema é quando voltamos para o horário normal, ou seja quando atrasamos/voltamos o relógio em 1 hora. Nesse momento, teremos um overlap (sobreposição/reescrita) dos dados de 1 hora, o que é um problema, e somente alguns sistemas de supervisão indicam a existência do overlap. E todos os dados que foram armezenados à 1 hora, podem ser sobrescritos ou mesmo perdidos, dependendo do seu sistema. E se estes dados perdidos representavam informações importantes, como uma oscilografia, os dados de produção ou um log de eventos?

Em todo caso, eu utilizo e compartilho do mesmo pensamento de muitos DBAs(Database Administrators). “Nunca altere o horário da base de dados de um servidor”. Inclusive muitas concessionárias de energia utilizam esse conceito, visto que para efeito de tarifação o horário de ponta/fora de ponta é alterado, mas nenhum medidor de energia tem o seu relógio atualizado.

Reflitam sobre isso. No final quem deve decidir o que fazer é o cliente, mas ele pode ser melhor acessorado.

Abraços,

Márcio Roberto

Um bom site com exemplos de scripts para WinCC

Pessoal,

 O Diogo me solicitou um site com exemplos de scripts para o WinCC. Eu recomendo o site do Salma Ghafoor, que é um cara bem conceituado no fórum da Siemens. Visitem e aproveitem ambos os sites, que são repletos de bons exemplos e especialistas.

 Abraços,

 Márcio Roberto