Os Benefícios de Arquiteturas Baseadas em
Objeto para Sistemas de Supervisão e SCADA
Autor: Steven D. Garbrecht, Vice-Presidente de Marketing de Aplicativos Avançados e Software, Invensys Operations Management
Conteúdo:
1. Sumário Executivo
2. Introdução
3. Sistemas Baseados em Tag versus Baseados em Objeto
4. Objetos Ajudam a Incentivar a Consistência e Reforçar
Melhores Práticas
5. Desenvolva Uma Vez, Reutilize Muitas Vezes
6. Gráficos HMI Orientados em Objeto
7. Vantagens de Desenvolvimento de Arquiteturas
Baseadas em Objeto
8. Economias durante Ciclo de Vida
9. Desenvolvimento Baseado em Objeto é o Futuro
10. Sumário
1. Sumário Executivo
Atualmente, a maioria das instalações industriais usam os aplicativos SCADA e Supervisory HMI (interface homem-máquina) com base em arquiteturas tradicionais baseadas em tag. Contudo, as arquiteturas baseadas em objeto, prontamente disponíveis e tecnologicamente maduras, podem oferecer economias de custo de até 80% em sistemas baseados em tag. Cálculos de custo são explicados e demonstrados. Outros benefícios das arquiteturas baseadas em objeto incluem a aplicação mais fácil de melhores práticas em empresas industriais com diversos prédios, informações mais consistentes sobre o desempenho da planta e escalabilidade e mantenabilidade de sistema consideravelmente reforçadas.
2. Introdução
Arquiteturas de software baseadas em objeto estão disponíveis há muitos anos no mundo comercial de computadores. Agora essas arquiteturas estão sendo adotadas em aplicativos de controle de processo e SCADA para fornecer benefícios operacionais e de custo significativos. Neste relatório, vamos discutir o que são arquiteturas baseadas em objeto, como elas melhoram o desenvolvimento dos aplicativos HMI e SCADA e como você pode calcular as possíveis economias de custos sobre os sistemas tradicionais baseados em tag.
3. Sistemas Baseados em Tag versus Baseados em Objeto
i. Sistemas Baseados em Tag
Desde a origem de HMI baseadas em PC e sistemas de supervisão, a análise de acesso de dados de processo, de sequência de comando, de alarmes e dados foi baseada no conceito de tags. Esses sistemas usam uma lista “plana” de tags com hierarquia embutida, relações ou interdependências.
Alterações abrangentes e globais no banco de dados de um sistema de tag são normalmente feitas no aplicativo de forma externa, geralmente via arquivo de texto ou através de ferramentas como Microsoft Excel®. Uma vez
realizadas, as alterações são importadas para o banco de dados do aplicativo. A reutilização de engenharia em um sistema baseado em tag é normalmente instituída através de relações dinâmicas ou cliente-servidor. O sistema cria um gráfico comum contendo sequências de comandos que comutam tags em tempo real. Porque a estrutura do aplicativo é ”plana”, o usuário deve então alterar cada tag no sistema e analisar como a alteração afeta o resto do aplicativo.
A manutenção de aplicativos baseados em tag normalmente envolve a análise e atualização de tag por tag, o que pode consumir tempo significativo de trabalho. Visto que as alterações de sistema consomem tempo e geralmente envolvem o uso de melhorias de trabalho externas aos sistemas baseados em tag são limitadas.
ii. Sistemas Baseados em Objeto
O conceito de desenvolvimento orientado em objeto originou-se no mundo da tecnologia de informações (TI). A meta era fornecer ferramentas que livrassem o programador de tarefas de programa rotineiras e repetitivas, aumentando, ao mesmo tempo, a reutilização de código através de desenvolvimento de objetos de software comuns. Como era esperado, essas ferramentas não são ideais para o ambiente industrial. Em primeiro lugar, os integradores de sistema e engenheiros de produção geralmente não são programadores de computador. Além disso, existem algumas diferenças arquitetônicas importantes entre TI e aplicativos de automação de produção.
Por exemplo, os aplicativos de TI geralmente envolvem acessar o banco de dados a partir de interfaces baseadas em formas, não determinísticas, que realiza tarefas como banco online, relatório de negócios, gestão de RH, contabilidade financeira ou pesquisas estatísticas de informações.
De modo oposto, o controle de supervisão, os sistemas de execução de produção (MES) e aplicativos de inteligência de planta envolvem adquirir dados de processo em tempo real; realizar cálculos sofisticados para determinar fluxos e valores de produção; mostrar dados em tempo real em monitores de operadores ou relatórios de processo ou ferramentas de análise; e armazenar esses dados para processar historiadores ou banco de dados relacionados à produção.
Os dois ambientes são suficientemente diferentes para ditar que as ferramentas baseadas em objeto sejam construídas intencionalmente para o ambiente industrial. A ArchestrA® System Platform utiliza uma arquitetura
baseada em objeto que é chamada ArchestrA. Ela é especificamente projetada para clientes industriais que desenvolvem, gerenciam e mantêm sistemas de supervisão.
iii. Comparando os Dois Sistemas
A tabela a seguir compara arquitetura baseada em objeto com arquitetura baseada em tag.
Arquitetura Baseadas em Objeto
Arquitetura Baseadas em Tag
Desenvolvimento
Tempo Real
Desenvolvimento
Tempo Real
Estrutura do
Aplicativo
Hierárquica – Objetos criados usando metodologia de fluxo de trabalho orientado em objeto Hierárquica – Componentes representam dispositivos físicos e podem coordenar com componentes em computadores diferentes Hierárquica – Conteúdo gráfico, algumas vezes, criado usando orientação em objeto Plana – Exemplos monolíticos de software operam em uma/diversas máquina(s) como “aplicativos” separadasDesenvolvimento
Gráfico
Realizado por último ND Realizado primeiro ND
Sequência de
Comandos
Desenvolvida em modelos de objetos, depois implantada em um aplicativo de tempo de execução específico ND Desenvolvida separadamente, vinculada a uma interface gráfica NDPadrões
CumpridosEstritamente ND Não Cumpridos Estritamente ND
Alterações no
Aplicativo
Propagado a partir de modelos de objetos Objetos podem ser distribuídos, trocados ou aprimorados Baseado em gráficos ou alterações usando ferramentas como Excel Requer recompilação do aplicativoComo os
Dados são
Representados
Construtores lógicos como dispositivos físicos (p. ex., válvulas ou bombas) ou dispositivos lógicos (p. ex., malhas PID ou cálculos) são representados como objetosND Dispositivos gráficos
são representados como objetos ou tags
ND
4. Objetos Ajudam a Incentivar a Consistência e Reforçar Melhores Práticas
Em aplicativos SCADA baseados em objeto, os objetos de aplicativo contêm aspectos ou parâmetros associados com os ativos que representam. Por exemplo, um objeto de válvula pode conter todos os eventos, alarme, segurança, cálculos, coleta de dados, integrações, comunicações e sequência de dados com o ativo.
Os objetos não representam apenas os equipamentos da planta. Eles podem incluir cálculos, métodos de acesso a banco de dados, indicadores-chave de desempenho (KPIs), eventos de monitoramento de condição, operações de transferência de dados ERP, procedimentos de operador móvel, atividades de fluxo de trabalho e tarefas de MES. Todos esses objetos podem ser padronizados e utilizados em todos os aplicativos de supervisão para incentivar a consistência de design e operação do sistema.
Por exemplo, um objeto de solicitação de trabalho padronizado pode ser criado, depois adicionado a qualquer ativo da planta, tal como uma bomba, dentro de um aplicativo de supervisão, garantindo uma abordagem consistente e padronizada para solicitações de trabalho iniciais.
Figura 1: Um modelo de objeto contém informações valiosas sobre
Alarmes/Eventos, Segurança, Histórico, SCADA, Sequência de Comandos e Entradas/Saídas.
Instalações industriais controladas por um sistema de supervisão moderno compartilham um conjunto de características comuns: • Dispositivos e equipamentos da planta
• Procedimentos operacionais • Medições de processo • Cálculos
• Monitores gráficos de operador
Arquiteturas baseadas em objeto facilitam uma abordagem padrão para o desenho do sistema de supervisão, no qual as
funcionalidades do sistema como as características mencionadas acima podem ser encapsuladas em modelos de objetos, duplicadas e reunidas para formar um sistema de supervisão completo.
Entradas/saídas Objetos de válvula
Alarmes/Eventos
Sequência de Comandos
Segurança
Uma vantagem importante desta abordagem baseada em objeto é este conceito de modelos de objetos. A seguir uma representação gráfica de como os modelos de objeto conferem desenho de sistema rápido e propagação de alteração.
Figura 2: Réplica de Objetos e Propagação de Alteração
A primeira fileira da Figura 2 mostra a réplica de um modelo de objeto representando uma válvula de diafragma e todas as suas características inerentes. Réplica é o processo no quais instâncias de tempo real ou componentes são criados a partir de modelos de objetos. A fileira seguinte ilustra como uma alteração em uma característica da válvula (ativação manual para ativação mecânica) é propagada ao longo das instâncias de tempo real do objeto de válvula.
Esta relação pai/filho é um benefício importante da abordagem baseada em objeto. Alterações são propagadas automaticamente a todas as instâncias de tempo real do modelo de objeto, incluindo qualquer número de aplicativos de supervisão operantes em diferentes locais físicos. Ninguém precisa visitar cada local para realizar as alterações que atingir centenas, ou mesmo milhares, de instâncias de ativos comuns como uma válvula.
• A criação de aplicativo é otimizada usando modelos de objeto para gerar automaticamente componentes de tempo real • Alterações ao projeto são facilmente acomodadas fazendo alterações no modelo do objeto e permitindo que os
componentes herdem as alterações via propagação de alteração
• Alterações e expansões de sistema em andamento são fáceis e mais eficazes em termos de custo graças à réplica automática e à propagação de alteração
5. Desenvolva Uma Vez, Reutilize Muitas Vezes
A abordagem baseada em objeto da ArchestrA System Platform simplifica significativamente o desenvolvimento e manutenção do aplicativo. O Ambiente de Desenvolvimento Integrado (IDE) permite o uso da simples técnica do Windows de arrastar e soltar, clicar para selecionar ou preencher texto para criar e manipular objetos.
Na maioria dos casos, esta abordagem é muito mais fácil do que modificar as sequências de comando linha por linha. Além disso, o número de erros de sintaxe e tempo real é reduzido porque o IDE reforça regras específicas do sistema. Além disso, os usuários podem desenvolver modelos de objeto uma vez e depois utilizá-los novamente muitas vezes e muitos aplicativos diferentes, maximizando o retorno em engenharia.
Modelo de Objeto
(Desenvolvimento)
Componentes (Tempo real)
Réplica
Propagação
de Alteração
Válvula
de diafragma
de diafragma
Válvula
de diafragma
Válvula
de diafragma
Válvula
Válvula
6. Gráficos HMI Orientados em Objeto
O termo “gráficos orientados em objeto” tem sido usado no ambiente SCADA/HMI desde o início dos anos 90. Os gráficos
orientados em objeto permitem que os usuários construam um símbolo e o repliquem em um aplicativo HMI. Eles pode então editar o símbolo e distribuir facilmente as alterações a todos os símbolos semelhantes ao mesmo tempo.
Ao mesmo tempo que esta funcionalidade é útil, os aplicativos SCADA/HMI requerem mais do que gráficos. Grande parte do trabalho de desenvolvimento que é dedicada ao desenho de aplicativos de supervisão é gasta na criação de funcionalidades como:
• Monitoramento de alarme
• Sequência de comandos de animação
• Sequência de comandos de segurança
• Sequência de comandos de supervisão
• Armazenagem de dados históricos
• Integrações a outros aplicativos ou banco de dados • Detecção de evento
• Cálculos de fluxo e movimento • Integração de dispositivo • Fluxo de Trabalho
Para tornar concretos os benefícios de uma arquitetura baseada em objeto, o sistema SCADA/HMI precisa incluir todas essas funções ou recursos em modelos de objetos, incluindo gráficos.
7. Vantagens de Desenvolvimento de Arquiteturas Baseadas em Objeto
i. Arquiteturas Baseadas em Tag
Desde a origem da HMI baseada em PC e do software SCADA, os usuários construíram gráficos de operador e os vincularam às tags que representavam endereços em um PLC ou sistema de controle. Os passos abaixo representam o processo de desenvolvimento típico para um aplicativo SCADA tradicional, baseado em tag:
1. Utilização de computador de desenvolvimento único. 2. Gráficos e telas do operador são criadas para o aplicativo.
3. Definições de tag são importadas a partir de PLC ou configuradas manualmente.
4. Sequências de comando para alarme ou detecção de evento são definidas para cada tag. 5. Tags e entrada/saída associadas são vinculadas aos elementos gráficos.
6. Sequências de comando de animação gráfica são criadas.
7. Alterações ao sistema requerem que o aplicativo seja fechado, realizando alterações às muitas sequências de comando e referências de banco de dados de tag para habilitar a nova funcionalidade. O aplicativo é então reinstalado em cada estação de trabalho de operador.
i. Arquiteturas Baseadas em Objeto
As arquiteturas baseadas em objeto associadas com aplicativos de supervisão e SCADA/HMI foram introduzidas pela Wonderware®. A ArchestrA System Platform e sua principal ferramenta de desenvolvimento, o Ambiente de
Desenvolvimento Integrado (IDE), mudaram essencialmente a forma como os aplicativos de supervisão e SCADA/ HMI são desenvolvidos.
Utilizando o Ambiente de Desenvolvimento Integrado, o programador de aplicativo cria um modelo único de planta usando modelos de objetos reutilizáveis. O programador é então retirado de suas complexidades de ambiente informático e autorizado a se na modelagem da instalação de produção. O programador pode concentrar-se em diferentes ativos e processos de produção que abrangem o controle de supervisão de toda a planta.
Após o modelo da planta ser capturado, é fácil implantar as funções de controle de supervisão. Um pequeno investimento na criação de modelos de objeto rende grandes resultados em produtividade de engenharia. Criando um aplicativo de supervisão usando a ArchestrA System Platform envolve:
1. Uma pesquisa local conduzida para entender o layout da operação de produção ou processo.
2. Criação de uma lista de peças semelhantes de equipamentos/ativos. Áreas distintas de operação são identificadas. 3. Modelos de objeto são configurados para cada ativo comum na instalação, incluindo gráficos HMI. Este
passo importante permite que melhores práticas e padrões sejam criados para uso em todos os projetos de aplicativo futuros.
4. Modelos de objeto de componente ou dispositivo podem ser acomodados dentro um do outro para criar peças elaboradas de equipamentos.
5. Modelos de objeto de dispositivo possuem atributos que representam entrada/saída real disponível no PLC ou sistema de controle. Estes atributos são então vinculados à entrada/saída através de objetos de integração de dispositivo (DI Objects).
6. O aplicativo pode então ser montado no IDE usando operações simples de arrastar e soltar. 7. Os objetos do aplicativo são então atribuídos para grupos de segurança.
8. O modelo da planta criado no IDE pode agora ser implantado aos computadores que hospedarão o aplicativo. 9. Uma vez desenvolvido o aplicativo, a manutenção de sistema é fácil. As alterações realizadas em modelos de
objeto podem ser propagadas aos componentes secundários encontrados em aplicativos implantados.
8. Economias durante Ciclo de Vida
Arquiteturas baseadas em objeto podem fornecer economia significativa durante seu ciclo de vida todo. Essas economias podem ser categorizadas em quatro áreas básicas, conforme ilustradas na tabela a seguir.
Área de Economia
Explicação
Economias de Desenvolvimento Inicial
Relacionadas à Geração de Aplicativo
Isto representa as economias que resultam do tempo economizado quando usuários desenvolvem aplicativos definindo modelos de objeto uma vez e depois usando estes modelos diversas vezes.
Economias de Desenvolvimento Inicial
Relacionadas às Alterações de Aplicativo
Isto representa as economias de desenvolvimento obtidas através da capacidade de propagar alterações a partir de modelos de objeto para todas as instâncias de tempo real derivadas daqueles modelos. Quando diversas alterações de aplicativo são solicitadas durante o desenvolvimento, as economias podem, de fato, melhorar.
Economias de Manutenção Através do
Ciclo de Vida do Sistema
Usar um sistema distribuído reduz significativamente os custos através da capacidade de monitorar, alterar e implantar, de forma remota, o software para todos os computadores com HMI da rede. Isto é essencialmente importante para redes geograficamente distribuídas porque os usuários podem poupar tempo e dinheiro, eliminando a necessidade de mover-se até cada unidade para executar manutenção ou atualizações.
Economias em Todas as Unidades
Essas economias resultam da reutilização de modelos e aplicativos criados para este projeto em outros projetos. As empresas usam isto para incentivar padrões em seus projetos. Isto é particularmente benéfico para integradores de sistema, revendedores de valor agregado (VARs), fabricantes de equipamentos originais (OEMs), fabricantes de máquinas e operadores de fábrica.Daqui para ilustrar como o desenvolvimento baseado em objeto pode diminuir custos.
Vamos assumir que estamos desenvolvendo um aplicativo de supervisão de planta que possui, entre outras coisas, 27 válvulas de assento duplo, cada uma possuindo seis parâmetros de processo (entrada/saía) que serão monitorados. Eles são pontos de entrada/ saída no PLC que medem o desempenho deste valor.
Em um sistema tradicional baseado em tag, 162 tags (27 válvulas * 6 valores de parâmetros (entrada/saída) por valor) seriam criadas. Em um sistema SCADA baseado em objeto, um modelo de objeto de válvula comum é criado e objetos que representam cada válvula individual são demonstrados ou replicados a partir deste modelo de objeto. Agora assuma que isto leva 0,4 horas por tag para desenvolver o aplicativo usando um sistema SCADA tradicional baseado em tag. Isto não inclui gráficos de processo ou desenvolvimento lógico de controle de PLC. Vamos estimar que são necessárias duas horas para desenvolver um modelo de objeto da válvula e um adicional de 20% (ou 0,4 hora) por instância de objeto para customizar cada válvula individual no aplicativo. Exemplo de dispositivo:
Tipo de dispositivo
Número de Instâncias Entrada/Saída por Instância
Válvula de assento dupla 27 6
Estimativas Individuais:
Tipo de dispositivo
Número de Instâncias Entrada/Saída por Instância
Válvula de assento dupla 27 6
Lembre-se de que um Modelo de Objeto encapsula a sequência de comando, segurança, alarme, eventos, configuração de histórico e comunicações de dispositivos. Em um sistema baseado em tag, tudo isto precisa ser programado usando tags de memória adicionais. Agora vamos comparar o tempo total para desenvolver o aplicativo usando cada tipo de abordagem de desenvolvimento.
Esforço de Desenvolvimento Inicial:
HMI Tradicional, Baseado em Tag
SCADA Baseada em Componente
Economias
162 tags * 0,4 horas por tag = 64,8
horas (2 horas * 1Modelo de Objeto) + (27 Instân-cias de válvula * 0,4 horas por distância) = 12,8 horas
52 horas ou 80%
Isto é uma economia impressionante -- mesmo se você estimar metade deste número, você economiza 40% nos custos de desenvolvimento!
Agora o que acontece se for solicitado que uma alteração afete 10% do aplicativo? Usando desenvolvimento baseado em tag, é aceitável assumir que 10% do esforço gasto em desenvolvimento original seriam necessários para realizar as alterações. Contudo, usar desenvolvimento baseado em objeto, como a Wonderware ArchestrA System Plataform, o esforço de alteração de 10% somente precisa ser aplicado ao modelo de objeto – devido à relação pai-filho entre os objetos e componentes. Nesta situação, as economias adicionais podem ser calculadas da seguinte forma:
Esforço de Alteração no Aplicativo:
HMI Tradicional, Baseado em Tag
SCADA Baseada em Componente
Economias
64,8 horas * 10% alteração = 6,48 horas 2 horas por Modelo de Objeto * 10%
Invensys, o logo da Invensys, ArchestrA, Avantis, Eurotherm, Foxboro, IMServ, InFusion, SimSci-Esscor, Skelta, Triconex, e Wonderware são marcas da Invensys plc, suas subsidiárias ou afiliadas. Todas as outras marcas e nomes de produtos podem ser marcas comerciais de seus respectivos proprietários.
© 2012 Invensys Systems, Inc. Todos os direitos reservados. Nenhuma parte do material protegido por este copyright pode ser reproduzida ou utilizada de qualquer forma ou por qualquer meio, eletrônico ou mecânico, incluindo fotocópia, gravação, radiodifusão, ou por qualquer sistema de armazenagem e recuperação, sem a permissão expressa da Invensys Systems, Inc.
Invensys Operations Management • 5601 Granite Parkway III, #1000, Plano, TX 75024 • Tel.: (469) 365-6400 • Fax: (469) 365-6401 • iom.invensys.com
9. Desenvolvimento Baseado em Objeto é o Futuro
Arquiteturas baseadas em objeto fornecem vantagens atrativas no desenvolvimento e manutenção de sistemas de supervisão e SCADA. Ao avaliar arquiteturas é importante que os seguintes aspectos técnicos sejam considerados, incluindo:
• A ferramenta de desenvolvimento fornece um modelo realístico dos equipamentos da planta e áreas de produção, processos e linhas de produção?
• A segurança da rede pode ser facilmente integrada ao aplicativo, incluindo configuração de segurança centralizada? • Ela oferece conectividade flexível para dispositivo e ferramentas eficazes em termos de custo para comunicar-se por
interface com todos os dispositivos na planta? • Ela fornece utilidades de diagnóstico centralizadas?
• O ambiente de desenvolvimento consegue permitir o escalonamento de aplicativo a partir de um nó único para diversos nós, sem refazer a arquitetura de todo o aplicativo?
• Os aplicativos de HMI podem ser implantados remotamente para computadores de toda a rede?
• A ferramenta de desenvolvimento fornece um espaço unificado para nome que facilite a busca de tag em toda a rede PLC, tanto durante o tempo real como offline?
• Os carregamentos de computação podem ser distribuídos em diversos computadores?
• O sistema fornece redundância econômica usando tecnologia comercial de virtualização pronta para uso? • O subsistema do alarme é distribuído?
• O arquivamento histórico é definido durante o desenvolvimento de HMI ou é necessária uma ferramenta separada? Um sistema SCADA moderno deve ser capaz de oferecer todos os elementos acima.
10. Sumário
Condições econômicas que direcionadas a instalações industriais ditam que a produtividade de engenharia seja maximizada junto com a agilidade de produção. As atuais arquiteturas baseadas em objeto, para o desenvolvimento de aplicativos SCADA e de supervisão, oferecem até 80% de economia em custos de engenharia sobre arquiteturas baseadas em tag.
Ser capaz de construir uma vez e usar muitas vezes é muito importante para administrar os custos do projeto e o desenvolvimento baseado em objeto permite que melhores práticas sejam encapsuladas em aplicativos e padronizadas em toda a empresa. Sistemas baseados em objeto podem ser aprimorados rapidamente ou modificados para responder às condições do mercado – melhorando a agilidade. Além disso, os gráficos de processo baseados em objeto não só permitem a reutilização de engenharia, mas também fornecem aparência e comportamento uniformes que reduzem a necessidade de treinamento de operador e permite que os operadores aceitem fazer alterações no sistema com mais facilidade.
Um “espaço de nome” único permite que os sistemas de controle existentes sejam mantidos e aprimorados através de uma “camada” de supervisão baseada em objeto. Não há necessidade de “remover e substituir” sistemas existentes enquanto permite que novos recursos de sistema sejam adicionados por uma fração do custo de um novo sistema de supervisão.
Desse modo, arquiteturas baseadas em objeto são uma alternativa bastante atrativa aos sistemas baseados em tag e permitem economias de custo atrativas e flexibilidade operacional.
