IEC 61850

Você já esteve as voltas com o tal de 61850 (meia um oitocentos e cinquenta)?

Muita gente já esteve, e ao se deparar com o 61850 tiveram uma série de perguntas.

“O que é este 61850?”

“Como é que eu vou ‘ligar’ estes relês com 61850 ao meu supervisório?”

“Meu gerente disse que está ampliando a subestação e vem tudo com o 61850! O meu supervisório não tem este driver. Como eu faço?”

Primeiro, o 61850 é um protocolo de comunicação desenvolvido pelo comitê técnico 57 (TC57) da International Electrotechnical Commission (IEC), e se tornou uma norma internacional.

O IEC é uma associação de padronização na qual desenvolvedores, fabricantes de equipamentos e usuários, em cooperação e através de consenso, desenvolvem normas e padronização de tecnologias elétricas e eletrônicas para uso e aplicação pela comunidade.

Assim que ficou pronta, fabricantes de equipamentos e desenvolvedores de softwares foram implementando o 61850 em seus produtos. A aceitação por parte dos usuários foi rápida em virtude dos benefícios gerados no emprego do novo padrão.

O sucesso do protocolo IEC 61850 junto aos usuários deve-se principalmente à:

- padronização de nomes para as variáveis (não são usados endereços neste protocolo);

- o dispositivo fornece a lista de tags (não é necessário digitar uma lista de tags);

- facilidade de integrar com os supervisório e outros softwares;

- facilidade e rapidez na colocação em operação.

A Exata vem ajudando seus clientes na implantação de sistemas baseados em IEC 61850 desde 2009, e tem larga experiência na aplicação desta tecnologia.

São mais de 100 servidores OPC DA com driver cliente IEC 61850 MMS implantados e operando em projetos de todos os portes.

Se você tem dúvidas na aplicação do protocolo IEC 61850, fale conosco!

Conexão entre chão de fábrica e sistemas MES e ERP

Autor: Maria Alice Duarte, Exata Sistemas de Automação Ltda. 

O ambiente da automação industrial e o ambiente de produção estão cada vez mais complexos. Eles usam diferentes tipos de equipamentos juntamente com diversos aplicativos de software - cada um com uma finalidade diferente. Sendo que tudo tem que trabalhar em conjunto para atingir os objetivos de produção. Os dados gerados por esses sistemas são cada vez mais importantes para as empresas. 

É no chão de fábrica que nasce a informação. Os dados são produzidos por equipamentos como: Sistemas de Controle Distribuído (SDCD), Controladores Lógicos Programáveis (CLP), Controladores Programáveis para Automação (PAC), dispositivos de Controle Numérico Computadorizado (CNC), ou algum outro tipo de dispositivo, sensor ou sistema. Estes equipamentos estão normalmente controlados e monitorados por Interface Homem Máquina (HMI) e/ou por aplicativos de Supervisão, Controle e Aquisição de Dados (SCADA). Os dados estão no contexto de operação do processo.

Acima do chão de fábrica, encontram-se os aplicativos conhecidos como Manufacturing Execution Systems (MES). Esses aplicativos existem para ajudar na gestão das operaçõesde produção, incluindo Programação e Otimização, Processamento de Pedidos, Gerenciamento de batelada, Controle Avançado de Processo e Business Intelligence. Os dados são contextualizados para este tipo de aplicativo.

No nível mais alto de uma organização, encontram-se os aplicativos de gestão empresarial, chamados Enterprise Resource Planning (ERP). Estes aplicativos integram todos os dados e processos de uma organização, possibilitando a automação e armazenamento de todas as informações de negócios. Incluem: Gerenciamento da Cadeia de Suprimento (SCM - Supply Chain Management), Planejamento dos Recursos de Manufatura (MRP - Manufacturing Resource Planning), Finanças (FRM – Financial Resource Management), Gestão de Relacionamento com o Cliente (CRM - Customer Relationship Management) e Gerenciamento de Ativos (Asset Management). 

Cada nível desempenha um papel específico no funcionamento de toda a empresa, e embora separados, precisam compartilhar maioria das informações.

No chão de fábrica a maior parte dos equipamentos e aplicativos são capazes de trocar informações entre si, principalmente graças ao uso da tecnologia OPC. O OPC Clássico foi concebido especificamente para o nível de automação industrial / produção com o objetivo de interligar os aplicativos de software rodando em computadores baseados no Windows com os equipamentos de chão de fábrica. 

E os aplicativos de negócios, MES e ERP? O que está sendo feito para permitir a comunicação entre chão de fábrica, MES e ERP? Existe um padrão que a indústria e os fornecedores de software de negócios adotaram ou podem adotar? 

A integração entre os aplicativos de negócios e o ambiente de produção ainda é um processo ad-hoc, ou seja, é uma solução destinada a atender a uma necessidade específica ou resolver um problema, não sendo aplicável a outros casos. Os fornecedores dos aplicativos de MES e ERP, normalmente não estão familiarizados com padrões específicos da automação, como o OPC Clássico, ou estão menos inclinados a adotá-los. A fim de integrar o chão de fábrica aos aplicativos de negócios, a TI e/ou os Integradores de sistemas precisam desenvolver conectores para estes aplicativos trocarem as informações necessárias. Além disso, eles têm que consolidar e estruturar os dados ao longo do caminho, a fim de atender aos requisitos dos diferentes aplicativos de negócios. Esta pode ser uma tarefa demorada para desenvolver e testar. E esta forma de integração na maioria das vezes não pode ser reutilizada.

Felizmente, fornecedores de equipamentos e aplicativos para automação industrial têm trabalhado em conjunto para simplificar a integração entre os aplicativos de negócios e o chão de fábrica. Este processo de simplificação tem sido gradual ao longo dos últimos anos.

A primeira etapa foi a comunicação entre os equipamentos de chão de fábrica e os aplicativos de automação através do OPC Clássico. O OPC Clássico tem especificações para acesso a dados em tempo real (DA), acesso a dados históricos (HDA) e alarmes e eventos (A&E), que são amplamente aceitas na automação. Porém, cada especificação usa um conjunto de serviços para a troca de dados. Em uma segunda etapa, a especificação para acesso a dados em tempo real (DA) do OPC Clássico começou ser adotada na integração entre o chão de fábrica e os aplicativos de negócios.

A Unified Architecture (UA), a mais recente geração da tecnologia OPC, define um conjunto genérico de serviços que fornecem acesso a qualquer tipo de dado em conformidade com as diretrizes básicas definidas pela norma. 

O principal objetivo do OPC UA é manter todas as funcionalidades do OPC Clássico, mudando a tecnologia COM/DCOM da Microsoft para tecnologia de Web Services. Ao usar a tecnologia de Web Services, o OPC UA torna-se independente de plataforma e pode ser usando em situações onde o OPC Clássico não pode. O OPC UA pode ser perfeitamente integrado a aplicativos MES e ERP. Estejam estes sistemas operando em sistemas Unix / Linux usando Java, ou em controladores e dispositivos inteligentes com sistemas operacionais específicos com capacidade de processamento em tempo real. Além disso, o OPC UA tem segurança incorporada, uma exigência que se tornou cada vez mais importante em ambientes onde os dados de chão de fábrica devem ser acessados a partir da rede corporativa.

O OPC Clássico tem um modelo muito simples de dados baseado simplesmente na hierarquia de tags. Já o OPC UA fornece um modelo rico de informações usando técnicas de orientação a objetos. Além de fornecer o valor de uma variável e sua unidade de engenharia, o OPC UA permite identificar o tipo específico de sensor de temperatura utilizado para obter a medição. Esta informação é útil em situações típicas do OPC Clássico, porque os componentes de software e de configuração apresentados numa estação de trabalho podem ser usados para os outros dispositivos do mesmo tipo existentes no sistema. Além disso, esta informação pode também ser utilizada pelos aplicativos de MES e ERP, contribuindo para a integração de dados sem a necessidade de fornecer uma lista de tags com a especificação de cada um.

A medida que mais empresas implementarem a tecnologia OPC UA, os usuários finais irão começar a perceber os seus benefícios. Eles serão capazes de desfrutar da simplicidade de conectar sistemas diferentes (CLPs, SDCDs, SCADA, MES, ERP), permitindo que coexistam com segurança. 

Banco de Dados Relacional ou Historiador em Tempo Real para registrar dados de processo?

por Robert McIlvride, Cogent Real-Time Systems Inc.

Alguns anos atrás, quando morava em uma parte do mundo onde os computadores pessoais eram um fenômeno relativamente novo, eu estava em um escritório observando uma secretária ocupada digitando em seu novo PC. Ela estava emocionada de ter essa ferramenta poderosa para usar. "Olha!" ela disse, emocionada. "Agora eu posso escrever e corrigir o meu trabalho tão facilmente!" Eu olhei para a tela, e tive de sorrir. Ela estava redigindo uma carta inteira dentro de uma única célula de uma planilha do Excel. 

O que determina a ferramenta certa para o trabalho? Para aquela secretária, a ferramenta correta era a única que ela sabia usar. Mas qual é a ferramenta certa para registrar dados de um aplicativo de controle de processo? Algumas vezes, um arquivo CSV é tudo que se faz necessário. Às vezes, o Excel atende à necessidade. Muitas vezes, porém, os engenheiros e integradores de sistemas precisam usar um banco de dados relacional ou um historiador em tempo real para registrar de forma permanente os dados do processo.

Bancos de dados relacionais têm a vantagem de disponibilidade e familiaridade. SQL Server, MySQL, Oracle, ou qualquer outro banco de dados relacional, incluindo o Microsoft Access, geralmente já estão instalados na empresa. Eles oferecem uma interface comum,ODBC, e o departamento de TI é familiarizado com eles. Não é surpresa ver bancos de dados relacionais sendo utilizados para registrar dados de processo, especialmente quando as solicitações por dados provêm de gestores familiarizados com este tipo de banco de dados. 

Mas um banco de dados relacional pode não ser a escolha ideal para todas as aplicações de 

controle de processo. Projetado para atender as necessidades de empresas e bancos para 

armazenar dados transacionais, os bancos de dados relacionais são otimizados para a análise de relações complexas entre os dados. Esses bancos de dados concentram a sua capacidade de processamento sobre esses relacionamentos, porque os dados propriamente ditos, são atualizados com pouca frequência, geralmente em termos de segundos, minutos ou horas. Enquanto a capacidade de análise é boa para aplicações de negócios, aplicações de controle de processo, normalmente, não precisam dele. O que elas precisam é de velocidade.

Um historiador em tempo real, por outro lado, é como um gravador de voo para processar dados. Ao invés de relacional, é um banco de dados temporal, que armazena seus registros em um arquivo simples, com apenas o nome, valor, qualidade, data e horário para um ponto de dado. O historiador é projetado para ter velocidade no armazenamento e na recuperação de seus dados, e normalmente consegue processar milhões de transações por segundo. Este tipo de desempenho é importante para processos com variáveis que mudam seus valores diversas vezes por segundo, e onde a captura de todos os eventos no decorrer de um turno de oito horas é vital. 

Apesar das vantagens de desempenho de um historiador em tempo real, algumas empresas optam por utilizar bancos de dados relacionais para registrar os dados de processo. Isso é totalmente compreensível, já que essa é a ferramenta com a qual a equipe de TI e a alta gerência da empresa estão mais familiarizados. Mas há três razões importantes pelas quais essa abordagem pode não ser suficiente.

1. Um historiador em tempo real registra todas as alterações de valor de um ponto, mesmo quando os valores mudam rapidamente. Utilizando algoritmos de armazenagem altamente eficientes, o conjunto completo de dados pode ser armazenado por longos períodos de tempo. Em um banco de dados relacional, em contrapartida, se faz necessário eliminar alguns ou a maioria dos dados à medida que estão sendo registados, uma vez que não está otimizado para o armazenamento de dados em alta velocidade. Infelizmente, os dados são eliminados independentemente da sua importância. Assim, você pode acabar registrando variações rotineiras e jogando fora eventos não usuais que poderiam conduzir a uma condição de alarme. Além de detectar todas as mudanças, grandes ou pequenas, a capacidade de um historiador em tempo real para um alto volume de dados é útil para detectar tendências sutis que podem aparecer apenas após um longo período de meses ou anos.
2. Uma grande vantagem de um historiador em tempo real é a sua capacidade nativa para processar as consultas com base no tempo. Por exemplo, talvez seja necessário o desvio padrão de um ponto que muda, em média, 25 vezes por segundo, em janelas de 10 segundos, para os dois últimos minutos. Um bom historiador irá fornecer uma maneira fácil de apresentar tal consulta, e retornará os resultados rapidamente, utilizando muito pouco os recursos do sistema. Consultas pré-construídas normalmente permitem selecionar qualquer período de tempo, desde de alguns segundos até semanas ou mais, e recuperar médias, percentuais de boa e má qualidade, correlações de tempo, regressões, desvios-padrão, e assim por diante. Tudo isso pode ser possível através de consultas SQL em um banco de dados relacional, mas com muito mais esforço de programação e maior utilização de recursos do sistema.
3. As duas vantagens acima de um historiador em tempo real podem talvez ser melhor apreciadas quando se trabalha com indicadores de tendência em tempo real. Calcular e apresentar uma linha em movimento que se atualiza várias vezes por segundo não exige apenas a capacidade de registrar todos os pontos de dados em tempo real, mas também a de recupera-los rapidamente e repetidamente para a sua apresentação em tempo real. E se um usuário quer avançar e retroceder no tempo através do conjunto de dados, uma vez que o mesmo está sendo armazenado, o historiador tem de ser capaz de gerenciar consultas rápidas e contínuas para o conjunto de dados. Este tipo de tarefa é difícil para um banco de dados relacional de prateleira, a menos que a taxa de atualização da tela seja extremamente lenta. 

Mesmo com esses pontos em mente, há muitas aplicações para as quais o registro de dados de processo em um banco de dados relacional funciona muito bem. Na verdade, às vezes armazenar os dados em um arquivo CSV é suficiente. Para ser justo, estes não são realmente o mesmo nível de equívoco de tecnologia como o de escrever uma carta comercial completa em uma única célula de uma planilha. O integrador de sistemas bem informado ou engenheiro vai entender os valores de cada abordagem, vai olhar para as necessidades do projeto e dos recursos disponíveis, e empregar a ferramenta certa para o trabalho.

____________________________________________________________________________________________

Fundada em 1995, Sistemas de Tempo Real Cogent é líder em integração de dados em tempo real entre Windows, Linux e sistemas QNX. Entre os clientes estão o Banco do Canadá, Cadbury Chocolate e a Agência Espacial Europeia. Cogent utiliza sua experiência em comunicação de dados em tempo real para fornecer a próxima geração de produtos OPC. Para mais informações, entre em contato com a Cogent info@cogent.ca ou visite o web site em www.opcdatahub.com. 

Traduzido por Exata Sistemas de Automação Ltda, distribuidora exclusiva da Cogent no Brasil. A Exata atua no mercado brasileiro desde 1984 como fornecedora de soluções de automação e de comunicação, com uma equipe altamente qualificada para ministrar treinamento e suporte técnico para as ferramentas da Cogent. Para mais informações, acesse: www.exatasistemas.com.br