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.

 

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.

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.

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

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.

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

10 motivos pra escolher Siemens

Eu aprendei a não entrar em certas discussões. Times, Política, Religião e principalmente fornecedores de automação, principalmente se for do tipo quem é melhor que quem.

A última vez que participei de uma discussão como essa, foi mais para me divertir, mas como a coisa tomou outro rumo expus os meus pensamentos, tudo começou assim:

---

Alguém já viu o CLP da Saia Burges ser programado com o STEP7? Crise de identidade? Talvez, mas por parte de quem? E pq será que a linguagem do SucoSoft da Moeller tem tantas funções semelhantes ao do STEP7.Não sei, to começando a achar que o mercado de programadores na Alemanha é meio restrito, isso se não for tudo farinha da mesma Índia, Paquistão…Mas vamos tentar.
1.Confiabilidade;
2.Versatilidade;
3.Liberdade;
4.Performance;
5.Possibilidade de ser tornar um sistema híbrido;
6.Conectividade;
7.Expansibilidade;
8.Real Redundância e HotStand-By;
9.Por ser alemão e não americano;
10.Incomodar a Rockwell.
11.Pq vc é programador de verdade e gosta de ser o senhor do seu destino. Me senti o Morpheus agora
Tá as últimas 3 eu forcei a barra.Sem criar polêmicas.Abraços,Márcio Roberto

---

Bom, não precisa nem dizer que criou polêmica, o que é bom. Acontece que foi exaltado as “vantagens” de um fornecedor nacional em relação a um fornecedor mundial. Tire as suas próprias conclusões, aqui vão as minhas:Respondendo de forma genérica algumas colocações.

1. O Brasil, assim como qualquer outro país pode participar sim do desenvolvimento de qualquer produto, mesmo estado o staff de desenvolvimento em outros países. Existem diversos produtos que foram desenvolvidos em conjunto com as matrizes. O que acontece, é que eu já vi filiais brasileiras quebrarem a cara, reclamando que precisavam de desenvolvimento de produtos que atendam o mercado interno, e a matriz trucar, bancando o desenvolvimento e no final das contas, não sair nada, ou sair a mesma coisa que seria feita fora.

2. Pode ser que eu não tenha participado efetivamente do desenvolvimento de produtos da Siemens, mas já relatei alguns Bugs no WinCC, que foram corrigidos em Service Packs, com certeza outras pessoas também encontram essas falhas, agora o que muda é a posição do desenvolvedor. Tentar corrigir o problema com soluções caseiras, ou relatar o problema e assim participar do desenvolvimento e melhoria do produto. Na Netdel, nos desenvolvemos diversos módulos para a área de energia, principalmente com Siemens, e nós já vimos alguns destes módulos serem reutilizados em outras empresas.

3. Faço minhas as palavras de um integrador do interior de SP, que com muita propriedade, afirma que seus clientes estão procurando mais soluções baseadas em Siemens e outras ditas “caras” ou “inviáveis” em outras épocas, pois com a queda do dolar, a briga por competitividade, as empresas vêem estes investimentos como a solução para a sua subexistência e se manterem competitivas. Logo a balaça do custo-benefício tende a se tornar mais equilibrada. Tanto é que empresas nacionais estão sendo forçadas a implementar novas funcionalidades e melhorias em seus produtos. Posso estar dizendo besteira, mas a Atos implementando a 61131-3 nos seus CLPs, quer brigar por um mercado que não é dela, ou manter um mercado que pode estar sendo invadido por empresas de fora?

4. Em relação aos manuais em outros idiomas, apesar de não ter inglês fluente, não vejo problemas nisso. Como se explica o fato da Índia ser umas das maiores potências em software, e eles não falam inglês. Mercado Globalizado, ame-o ou deixe-o.

5. Desculpe, mas por força do hábito, todas as vezes que eu preciso de suporte da Siemens mando e-mail pra Alemanha, e em 5 horas no máximo, devido ao fuso, eles respodem a minha solicitação, e quase sempre resolvem de primeira. Sendo que as dúvidas mais rotineiras, a Siemens Brasil mantém o mesmo padrão de atendimento.

6. Todos são iguais perante a justiça e olhe lá. Comparar técnicamente CLPs de grande porte importados (independente de fabricante) com os CLPs nacionais é um absurdo, não existem comparações. E mesmo entre CLP importados a linhagem européia é diferente da linhagem americana.

7. Custo, no meu ver, que é bastante limitado por trabalhar com poucos sistemas restritos na área de energia, está deixando de ser o diferencial na hora da aquisição de novos sistemas.

---

Pode ter certeza, o fórum ainda continua em aberto…

Por que será que todo mundo só gosta de Ladder?

Eu sempre me pergunto por que as pessoas viciam em programar o CLP em Ladder, quando geralmente o CLP que estão programando possue mais de uma linguagem.

O assunto é polêmico, e quase sempre acaba indo pro lado pessoal, mas verdade seja dita, cada linguagem atende a um propósito em especifíco. Não são raras as discussões em fóruns sobre o tema, aqui vai o meu post, em relação ao assunto e as possibilidades de programação dentro do ambiente da Siemens.

---

O pessoal bitola em Ladder ou acha que vai resolver todos os problemas em Lista.A grande sacada é variar, e principalmente usar conforme a necessidade.Bom, não tenho muito o que falar sobre outros PLCs que não sejam Siemens(S7-300/400). Mas quem quiser conversar, trocar umas idéias sobre as linguagens da 61131-3 no Step 7 é só mandar um post.

Ah, apesar de usar nomes diferentes, aqui vão as 5 linguagens da Siemens dentro da 61131-3

FBD (Diagrama de Blocos)
LAD (Ladder)
STL (Lista de instruções)
S7-Graph e SFC (são duas, mas no fundo é Graph 7)
SCL (Pascal ou texto estruturado)

Fora isso ainda tem CFC e HI-Graph (redes de Petri).

Ah, mas é bom lembrar, que no fundo no fundo essas linguagens são sempre front-end para lista de instruções.

Abraços,

Márcio Roberto

Analisando o status de uma conexão do WinCC – Publicado na comunidade do Orkut

Outro dia, o Guilherme me questionou como avaliar o status de uma conexão do WinCC, aqui vai a minha resposta:

---

Prezado Guilherme,Você pode avaliar o status da conexão, bem como outras informações de cada TAG, através das função GetTagXXXState().
Exemplo:
GetTagBitState(Tag_Name,lp_dwstate) onde:
lp_dwstate é um pointer para uma DWORD aonde será retornado o status do TAG, podendo ser:
Value (decimal) Value (hexdecimal) Significance
0 0×0000 No error
1 0×0001 No connection to partner established
2 0×0002 Protocol error
4 0×0004 Network component defect
8 0×0008 Exceeded configured upper limit
16 0×0010 Below configured lower limit
32 0×0020 Exceeded format limit
64 0×0040 Below format limit
128 0×0080 Conversion error
256 0×0100 Initialization value of tag
512 0×0200 Replacement value of tag
1024 0×0400 Addressing error in channel
2048 0×0800 Tag not found or non-existent
4096 0×1000 Access to tag rejected
8192 0×2000 Timeout, no response from channel
16384 0×4000 Server not available.Ou você usa o Wizard “Create Redundant Connection” para criar os tags de status de canal conexão que você tem, aí você vai ter diversos tags pra avaliar o status da conexão.

Abraços e bom uso.

Márcio Roberto

Alarmes no WinCC com servidores redundantes – Publicado na comunidade do WinCC

Quem já utilizou o WinCC, sabe como é fácil criar e gerenciar alarmes através do Alarm Logging. O Difícil é trabalhar com os alarmes em servidores redundantes, quer dizer, nem é tão difícil assim, veja como fazer.

Quando se trabalha com dois servidores redundantes é necessário que a estampa de tempo de toda e qualquer informação que seja armazenda no BD, seja igual em ambos os servidores redundantes.

O Xis é como fazer isso. A melhor maneira, se você estiver utilizando WinCC com STEP7, é usar o AS-OS Object Engineering, que vem junto com WinCC. Com ele é fácil você criar objetos e funções que integram os dois sistemas.

No caso, com essa ferramenta você pode usar o sistema de Message do PLC, aonde as mensagens, seja de alarme ou evento, são geradas no PLC e são enviadas aos servidores com a estampa de tempo do PLC.

Procure no site www4.ad.siemens.de referências a Message System e Alarm_8 no STEP 7. Eu uso e funciona muito bem.

Existe a opção da redundância de sincronização online de uma faixa de messagens, vou ser bem sincero, no manual diz que funciona, mas eu nunca usei. Tanto que deixo desabilitada nas opções de redundância.

Abraços,

Márcio Roberto

Funcionamento do WinCC – Publicado na Comunidade do WinCC

Certo dia uma pessoa me questionou sobre o que é o WinCC e como ele funcionava. Aqui vai a minha resposta:

---

Marcelo,Não dá para dizer como “todo” o WinCC Funciona em uma simples página, mas de forma básica vamos tentar.
O WinCC é uma supervisório com base de dados em tempo real, até a versão 5.1 o banco de dados era o Sybase Anywhere, apartir da 6.0 é o MS-SQL Server.
O WinCC é composto por módulos, sendo os principais:

• WinCC Explorer: É o gerenciador dos módulos. Basicamente utilizado para “acessar” outros módulos.
• DM (Data Manager): É através do Data Manager que você cadastra e configura os tags, que podem ser internos (sem conexão com o processo) e externos (com conexão com o processo). O processo de cadastrar os tags varia de driver para driver. O DM é que será o responsável por solicitar ao driver os tags necessários para animar uma tela, plotar um gráfico, etc…
• Alarm Logging: Módulo para cadastrar e gerenciar os alarmes do sistema.
• Tag Logging: Módulo para cadastrar e gerenciar e disparar as rotinas para armazenar os tags em períodos/situações previamente configuradas.
• Graphic Designer: Editor de telas;
• Global Script: Editor de Scripts/Funções.

Em modo configuração, estes módulos são utilizados para configurar/cadastrar e no modo Runtime estes módulos irão solicitar informações(tags) ao DM e executar as funções/rotinas neles cadastradas.

Além destes módulos existem outros módulos (Server, Redundancy, Picture Tree Manager e outros chamados ADD-ON) para facilitar determinadas funções ou implementar recursos não previstos pela Siemens.

Para maiores informações visite o site:
www4.ad.siemens.de. Se possível tente fazer um curso na Siemens.

Espero ter ajudado, mas como disse, é impossível falar sobre o WinCC todo em apenas um tópico.

Abraços,

Márcio