Elipse Software

Os benefícios da padronização entre PLC e SCADA – além da norma IEC 61131-3

Impulsionados pela adoção de estratégias de transformação digital e indústria 4.0, o mercado de automação industrial para supervisão e controle continua em expansão, tanto no nível de equipamentos (instrumentação e controladores de processo) quanto no relacionado a softwares e sistemas (SCADA/DCS).

Segundo estudo da Top Market Research, somente o mercado de sistemas SCADA deve continuar crescendo globalmente a uma taxa de 7,6% pelo menos até 2026. Taxas ligeiramente inferiores são observadas para os mercados de controladores programáveis e DCS, mesmo com a constante oferta de novos tipos de hardwares e softwares que compõem o universo do IoT e IIoT.

Neste contexto, a construção de um ICS (Industrial Control System) moderno pode ser feita por diversos caminhos, sendo que, a depender do segmento e tipo de aplicação, cada sistema ou fabricante pode possuir pontos mais fortes ou fracos, sendo mais ou menos aderente às necessidades de cada perfil de cliente.

Porém, mesmo com todas estas opções, ainda temos duas filosofias principais e bastante distintas no universo dos ICS, que são a adoção de sistemas com hardware e software mais integrados conhecidos como DCS (Distributed Control Systems), além dos sistemas mais abertos e flexíveis dos SCADA.

Filosofia de um DCS

Tipicamente, um DCS oferece uma plataforma integrada onde há uma ferramenta de configuração da estratégia de controle (via PLCs ou PACs – Process Automation Controllers) que compartilha uma mesma base de dados com o sistema de supervisão. Um DCS geralmente oferece uma biblioteca de blocos de controle para funções específicas, que tem por objetivo fazer com que o usuário utilize recursos que já foram desenvolvidos e testados pelo fabricante, diminuindo assim os riscos de um projeto.

Estes recursos, entretanto, estão intimamente ligados aos PLCs/PACs fornecidos pelo próprio fabricante do DCS. Obviamente que, em um DCS, é possível fazer a conexão com controladores de outros fabricantes ou mesmo com equipamentos IoT, através de padrões como OPC e MQTT. Contudo, é de se esperar que o principal motivo de utilizar um DCS, que é a padronização e compartilhamento da base de dados entre hardware e software, caia por terra quando se utiliza um equipamento de outro fabricante.

Apesar de haver iniciativas como a norma IEC 61131-3 e organizações como o PLCOpen, sabemos que cada fabricante tem suas peculiaridades e que não é possível utilizar um programa de um controlador proveniente de um fabricante em outro ou mesmo importar facilmente as lógicas ou blocos, visto que não há compatibilidade direta de nomenclaturas, endereçamento e ferramentas entre os principais players do mercado.

Concluímos então que o uso de um DCS pode ser vantajoso do ponto de vista técnico quando se pretende utilizar os principais recursos de hardware e software de apenas um fabricante. Todavia esta filosofia tem pontos negativos, entre eles o “Vendor Lock-In”, que limita o cliente final a adquirir somente os produtos e serviços daquele fabricante específico sob pena de perder o principal benefício da escolha inicial, que era a padronização.

E no SCADA, como é?

Como já sabemos, um sistema SCADA não limita o usuário a um fabricante específico de controlador e permite a livre conexão a inúmeros tipos de equipamentos, mas isto também tem um preço, que é a falta de padronização.

Sistemas SCADA mais modernos oferecem alguns mecanismos para automatizar o sincronismo da base de dados de variáveis com alguns fabricantes de PLC´s, mas isto não resolve um dos principais problemas que é a falta de padronização desta base e o significado de cada componente.

A falta de padronização

Quando desenvolvemos um ICS, considerando a programação de controladores e sistemas de supervisão e controle, apesar de podermos lançar mão de templates, exemplos e bibliotecas, não é obrigatório que sigamos um caminho específico em termos de organização desta base de dados ou mesmo de nomenclatura e significado. Geralmente, começamos com um projeto em branco, onde vamos copiando lógicas de outros projetos quando possível ou então é necessário contar com a experiência para prever o que será necessário em termos de lógicas para o programa do PLC e como isso será utilizado no nível do SCADA.

No nível do PLC, a norma IEC 61131-3 prevê uma separação entre a base de dados e as linguagens de programação, promovendo uma certa familiaridade do usuário e padronização na simbologia, mas ela não informa como o programa deve ser feito, principalmente se levarmos em conta as necessidades de cada segmento vertical, ou mesmo desejos do cliente, que podem ser informados ou descobertos em um momento tardio em relação ao andamento do projeto.

Interessante observar que este problema também ocorre nos DCS´s e outros sistemas híbridos, mas não é muito considerado por subentendermos que a plataforma oferece “blocos prontos”, mas que na verdade, pela própria natureza dos processos industriais, existem inúmeras particularidades a cada perfil de aplicação e cliente, fazendo com que os sistemas sejam sempre customizados. E esta customização abre espaço para a falta de padronização.

E por que isso é um problema?

A falta de padronização mencionada se torna mais evidente quando temos dificuldades para utilizar as informações coletadas ou executar funções esperadas pelo cliente. Temos aqui alguns exemplos de situações bastante comuns. Você se identifica com algumas delas?

– Nas lógicas de controle de equipamentos, não havia previsão de funcionalidades extra para os comandos, como intertravamentos, bloqueios, permissões e by-pass. Quando o cliente solicitou esta funcionalidade, o SCADA já estava com os tags endereçados e, para adicionar estas funcionalidades ao programa, teríamos que mudar os endereços dos tags já existentes ou alocar novos endereços bastante diferentes para os novos pontos, o que afeta a legibilidade do programa para outros responsáveis no futuro. A adição também resultou em retrabalhos que aumentaram o custo do projeto, que teriam sido minimizados se essa demanda tivesse sido planejada desde o início;

– Com o sistema pronto, o time de manutenção verificou que não haviam sido contempladas algumas features que facilitariam bastante o seu trabalho, como um sistema de controle de versões, relatórios de alterações e ferramentas de simulação. Como resultado, estes itens seriam deixados de lado na expectativa de que “não fariam muita falta” ou, em outros casos, foram adicionados posteriormente a um custo maior.

– Como parte de um projeto de transformação digital, o cliente gostaria de utilizar algoritmos de inteligência artificial para antecipar possíveis falhas nos equipamentos antes que elas ocorram. O projeto sofreu diversos atrasos devido, entre outros motivos, à falta de um padrão na base de dados do SCADA, onde pudessem ser identificadas as variáveis correspondentes à cada equipamento, ficando, a equipe de manutenção, com a tarefa futura de identificar, a cada novo equipamento que fosse adicionado, quais seriam as variáveis correspondentes. Também não havia uma ferramenta nativa que pudesse realizar esses cálculos e indicar com relatórios quais os ativos mais críticos.

Exemplos de solução

No segmento de automação predial, há um padrão fornecido pela ASHRAE (American Society of Heating, Refrigerating  and Air Conditioning Engineering) na norma 135 – BACnet® (depois ISO 16484-5), que prevê um protocolo específico e 60 tipos de objetos para as principais funções deste tipo de utilização, incluindo tópicos avançados, como o conceito de múltiplas prioridades de comando para cada usuário, um sistema de alarmes/eventos dentro dos controladores, programação horária e calendário.

Em tese, com um sistema SCADA e controladores de diferentes fabricantes, mas com uma boa compatibilidade com a norma, é possível ter um sistema com bons recursos e padronização, sem representar um “Vendor Lock-In”. Porém, equipamentos com BACnet tem um custo maior comparado a outros protocolos e não é uma solução genérica para qualquer tipo de processo.

Outra proposta interessante é o uso do OPC UA diretamente nos controladores, mas que também carece de um padrão específico de modelagem em termos de objetos e propriedades, já que o OPC UA é bastante genérico neste sentido.

A proposição da Elipse

Partindo do princípio de que a Elipse é uma tradicional desenvolvedora de sistemas SCADA, mas não de PLCs e PACs, realizamos um estudo para avaliar se havia alguma forma de propormos uma espécie de template para o desenvolvimento dos programas em controladores de processo, que fosse independente de fabricantes, mas que, ao mesmo tempo, proporcionasse ganhos de produtividade, flexibilidade e a diminuição de riscos dos projetos de automação, permitindo que algumas funcionalidades mais comumente presentes em DCS´s pudessem também ser obtidas no Elipse E3.

Dentro deste escopo, não estamos nos propondo a realizar a programação direta dos controladores de diferentes fabricantes, pois esta tarefa seria muito complexa pela ausência de padrões neste nível de utilização – mas sim da estruturação da base de dados do PLC em áreas específicas e com a previsão de diversas funcionalidades bastante úteis, que, caso seja seguida desde o início do projeto, ofereça uma série de benefícios “out-of-the-box”, ou seja, o sistema nasce com estes recursos desde a sua primeira versão.

Algumas das funcionalidades buscadas foram:

– Definição de estruturas (objetos) que representassem qualquer tipo de processo (contínuo, discreto ou batelada);

– Tratamento padrão para variáveis analógicas: escalas, filtros, banda morta, alarmes, simulações;

– Representação genérica para equipamentos, que permita declarar estados, comandos, intertravamentos, permissões e alertas, dentre outras funções, mas não impeça a utilização de outros blocos nativos do fabricante internamente para funções de tipos específicos de equipamentos;

– Suporte a funções de PID, Horímetros e Contadores;

– Controle de versões.

Elipse FlexControl

Metodologia de desenvolvimento para qualquer tipo de controlador e bibliotecas para os principais controladores do mercado

O resultado deste estudo foi a criação do Elipse FlexControl. O produto oferece uma metodologia de desenvolvimento para qualquer tipo de controlador e bibliotecas para os principais controladores do mercado. O objetivo é que as funcionalidades mencionadas anteriormente estejam presentes no sistema, independente da marca do controlador que está sendo utilizado, inclusive com diversos fabricantes sendo suportados simultaneamente.

A filosofia desenvolvida está baseada em uma orientação a objetos, tanto no lado do PLC como no SCADA. Pela experiência com diversos tipos de sistemas, chegamos à conclusão de que apenas 7 tipos de objetos eram suficientes para representar qualquer tipo de processo contínuo e discreto. A representação de processos batelada com base na norma ISA S88 envolve alguns objetos adicionais. Deixaremos para apresentá-los em um segundo artigo da série.

Desta forma, os 7 objetos especificados para o FlexControl são: Controlador, Analógica, Parâmetro, PID, Equipamento, Totalizador e Digitais.

No PLC, podemos alocar estes objetos em áreas contínuas ou independentes de forma que esta área alocada já preveja expansões futuras de forma que possam ser configuradas com o sistema em execução, sem a necessidade de realização de um upload fora do modo RUN da CPU.

Cada um dos objetos possui propriedades internas e externas. As propriedades externas são aquelas reservadas para troca de dados com o E3, formando assim uma área de transferência padronizada.

Para adaptar este padrão para diferentes tipos de PLC´s e protocolos, é possível definir, por controlador, se uma determinada propriedade de cada tipo de objeto está sendo usada. Além disso, podem ser usados diferentes tipos de endereçamento:

– Simbólico: utilizado quando o PLC suporta o endereçamento através de objetos e endereços textuais (ex: Objeto.Propriedade).

– Por Entidade: utilizado quando temos endereços numéricos e nos casos em que todos os atributos de um tipo de objeto estejam dentro de uma mesma área de memória.

– Por Atributo: utilizado com endereços numéricos e cada atributo de um tipo de objeto estão em áreas de memória diferentes.

– Misto: utilizado quando alguns atributos estão endereçados por entidade e outros de forma separada.

Criação do Programa do Controlador para o FlexControl

Uma vez definidos quais são os objetos e consequentemente a área de transferência entre o SCADA e o PLC, o programa do PLC deve explorar a configuração de cada objeto que é realizada pelo E3 em tempo de execução.

Como exemplo, caso o usuário, através das telas de configuração do FlexControl, informe que uma determinada analógica possui uma escala de conversão, esta informação é escrita na área de transferência, de forma que a analógica no PLC passa então a obedecer a essa configuração.

Para tornar a implementação mais robusta, fornecemos uma biblioteca com os principais blocos já prontos para utilizar todas as funcionalidades que podem ser configuradas, em especial para os objetos Analógicas, Totalizadores e PID.

Isto não impede, entretanto, a utilização de outros blocos disponíveis no controlador (Function Blocks) para as lógicas necessárias, desde que se mantenha a área de troca de dados com o SCADA inalterada.

No caso do objeto equipamento, isto fica mais evidente. Ele é uma entidade genérica que deve ser utilizado para representar um ativo ou conjunto de ativos, que envolvem estados, comandos, intertravamentos, permissões, alertas e defeitos, dentre outras funções, como a associação de analógicas e horímetros.

Configuração dos Objetos em Execução

Ao reservar as áreas dos objetos com uma quantidade sobressalente no PLC, é possível que, nas telas de configuração do FlexControl, estes objetos sejam configurados em tempo de execução, sendo escritas as configurações para cada objeto no controlador.

Este processo de cadastro, portanto, realiza três funções:

• Salva a configuração do objeto na base de dados do FlexControl, fazendo controle de versão a cada alteração;
• Cria os tags de comunicação para o objeto, conforme as regras de endereçamento, caso ainda não existam;
• Realiza o Deploy para o PLC, isto é, envia a nova configuração do objeto através de escritas nos tags correspondentes aos parâmetros – lembrando que alguns dos tags de cada objeto são de apenas leitura, outros de leitura e escrita, sendo, nestes últimos, onde informamos ao PLC as configurações.

Vejam que a metodologia proposta não impede a utilização de diversos outros recursos na arquitetura de controle, como:

– O uso de blocos do fabricante do PLC para funções específicas, desde que a área de transferência de dados entre as entidades e o Elipse E3 seja mantida. Esta área já foi planejada para suportar um extenso conjunto de configurações, que podem então ser repassadas pelo programa do PLC para outros blocos internos;

– O uso de equipamentos e controladores para áreas classificadas como safety (SIL 2, SIL 3);

– O uso de barramentos (Fieldbuses) e instrumentos inteligentes, inclusive com o uso de ferramentas abertas para FDT/DTM como o PACTware;

Outro benefício desta padronização é que permite o fornecimento de aplicações mais testadas para este perfil de uso, como, por exemplo, um maior detalhamento da arquitetura de cyber-segurança e a conformidade com a norma ISA 62443, como boas práticas de configuração e utilização de antivírus.

Utilização dos dados para Transformação Digital

Um outro grande benefício do FlexControl é que a plataforma já inclui uma licença do Elipse Plant Manager (EPM) para o tratamento dos dados coletados, com o objetivo de explorar todo o potencial da informação para ações de eficiência operacional e transformação digital.

Os objetos FlexControl são sincronizados automaticamente com o EPM, permitindo que sejam aplicados diversos tipos de cálculos e algoritmos de inteligência com base no tipo de cada ativo.

Esses indicadores podem retornar ao FlexControl na forma de setpoints ou de indicações de ações ao operador,  serem utilizados de diversas outras formas, como para integração com outros sistemas, exibição no aplicativo móvel Elipse Mobile ou no portal de dashboards do EPM.

Saiba mais sobre o FlexControl neste link.