Servidor TCP/IP Embarcado em Blocos de Função IEC 61499

Transcrição

1 UNIVERSIDADE FEDERAL DO ABC Curso de Pós-Graduação em Engenharia da Informação Cesar Celestino Peres Servidone Servidor TCP/IP Embarcado em Blocos de Função IEC Dissertação de Mestrado Santo André Agosto de 2012

2

3 Curso de Pós-Graduação em Engenharia da Informação Dissertação de Mestrado Cesar Celestino Peres Servidone Servidor TCP/IP Embarcado em Blocos de Função IEC Trabalho Apresentado como requisito parcial para obtenção do titulo de Mestre em Engenharia da Informação, sob orientação do Professor Dr. Nunzio Marco Torrisi. Santo André Agosto de 2012

4

5 Este exemplar foi revisado e alterado em relação à versão original, de acordo com as observações levantadas pela banca no dia da defesa, sob responsabilidade única do autor e com a anuência de seu orientador. Santo André, de de 20. Assinatura do autor: Assinatura do orientador:

6 Agradecimentos Agradeço a todos que colaboraram de forma direta ou indireta para a conclusão dessa dissertação de mestrado, especialmente meu orientador, Prof. Dr. Nunzio Torrisi, a Universidade Federal do ABC, e ao meu grande amor. i

7 ii Não são as respostas que movem o mundo, são as perguntas

8 Resumo A interoperabilidade de sistemas tornou-se crucial para que houvesse o avanço do controle distribuído, propiciando que sistemas concebessem resultados mais rápidos e seguros através da comunicação e execução de programas ao utilizar diferentes unidades funcionais, protocolos e linguagens usuais. Em 2005, a IEC foi desenvolvida para aprimorar e detalhar a linguagem de programação da IEC , especicamente o Bloco de Função - Function Block (FB). O FB é um elemento de linguagem de programação destinado à automação, padronizado pelas normas internacionais IEC e estendido na IEC Inúmeros avanços são apresentados na IEC em relação à especicação. Assim, um padrão aberto poderia ser utilizado para criar uma plataforma independente, o que poderia resolver as limitações da IEC , tornando mais fácil a portabilidade dos sistemas entre diferentes fabricantes e dispositivos, além de métodos de programação mais estruturado graças a lógica orientada a objetos. Neste projeto de pesquisa propõe-se um estudo teórico sobre o desenvolvimento de um servidor de comunicação TCP/IP, através de uma arquitetura para monitoração utilizando os FB IEC 61499, suprimindo as limitações da IEC O estudo visa a simplicar a arquitetura clássica de monitoramento através de servidores TCP/IP embarcados em FB. Com este modelo, o servidor de comunicação TCP/IP poderia ser disponibilizado como ferramenta para programas com suporte aos padrões IEC e embarcado em qualquer dispositivo com interface de rede do tipo IP. Esta solução propõe eliminar os gateways intermediários entre redes de campo e supervisão de processos, mantendo os padrões reconhecidos, como a IEC e a IEC Palavras-chave: Bloco de Função, Controlador Lógico Prográmavel, Servidor TCP, Monitoramento. iii

9

10 Abstract The interoperability between systems has become important for the advancement of distributed control, allowing systems to obtain results faster and safer through communication and implementation of programs to use dierent functional units, protocols and ordinary languages. In 2005, the IEC was developed to enhance and rene the programming language of IEC , specically the Function Blocks (FB). The FB is an element of the programming language for the automation, standardized by international standards IEC and extended IEC Many advances in IEC are shown in relation to the specication, and an open standard could be used to create a independent platform, which could solve the limitations of IEC , making the portability between dierent systems manufacturers and devices easier, and methods of programming more structured by the object-oriented logic. This research project proposes a theoretical study on the development of a TCP/IP communication server through an architectural approach for monitoring using the IEC FB, removing the limitations of IEC The study aims to simplify the classical architecture of monitoring via TCP/IP servers embedded in a FB. With this model, the TCP/IP communication server could be made available as a tool for programs that support the standard IEC and embedded in any device with IP based network interface. This solution proposes to remove the intermediaries gateways between eld and supervision processes, maintaining the standards IEC and IEC recognized. Keywords: Function Block, Programmable Logic Controller, TCP Server, Monitoring. v

11

12 Sumário Lista de Siglas Lista de Figuras Lista de Tabelas ix xi xiii 1 Introdução Contextualização Motivação Objetivos Trabalhos Publicados Metodologia Recursos Métodos Forma de Análise dos Resultados Organização Considerações sobre o estilo e formatação do texto Estado da Arte Normas internacionais Publicações não normativas e conferências IEC Parte 1 - Arquitetura Modelos de Referência da IEC Bloco de Função Distribuição Tipos de Blocos de Função Bloco de Função Básico - Basic Function Block Bloco de Função Composto - Composite Function Block Bloco de Função de Interface de Serviços - Service Interface Function Block vii

13 viii SUMÁRIO 4 PLC e Redes Industriais Arquitetura de um PLC padrão Evolução das Redes Industriais TCP/IP para aplicações industriais Camada de Rede Camada de Inter-rede Camada de Transporte Camada de Aplicação Integração dos Níveis das Redes Industriais Modelo ISA Segurança da Informação nas Redes Industriais Servidor de comunicação TCP/IP utilizando Blocos de Função IEC Arquitetura Proposta Integração entre as normas IEC e IEC Integração entre os Blocos de Função e as Tasks Serviços primitivos de comunicação para o servidor TCP Tempo de resposta estimado do servidor Considerações Finais Conclusões Contribuições Melhorias Trabalhos Futuros Referências Bibliográcas 51

14 Lista de Siglas AI Inteligência Articial (Articial Intelligence) AM Gestão de Ativos (Asset Management) ANN Redes Neurais Articiais (Articial Neural Network ) BFB Bloco de Função Básico (Basic Function Block) CFB Bloco de Função Composto (Composite Function Block ) CIA Condencialidade, Integridade e Disponibilidade (Condentiality, Integrity and Availability) CIP Protocolo Industrial Comum (Common Industrial Protocol ) CISC Conjunto Complexo de Execução do Computador (Complex Instruction Set Computer) ECC Diagrama de Execução e Controle (Execution Control Chart) ERP Planejamento de Recursos Empresariais (Enterprise Resource Planning) FAQ Perguntas mais Frequentes (Frequently Asked Questions) FB Bloco de Função (Function Block) FBD Descrição do Bloco de Função (Function Block Description) IEC Comissão Eletrotécnica Internacional (International Eletrotechnical Commission) IL Lista de Instrução (Instruction List) LAN Tecnologia de Rede Local (Local Area Network) IP Protocolo da Internet(Internet Protocol) IPMCS Projetos de Sistemas de Controle e Medição para Processos Industriais (Industrial-Process Measurement and Control Systems ) ISA Sociedade Internacional de Automação (International Society of Automation) LD Diagrama Escada (Ladder Diagram) LIMS Laboratório de Sistema de Informação Gerencial (Laboratory Information Management System) MES Sistemas de Execução da Manufatura (Manufacturing Execution Systems) MRP Recurso de Planejamento da Manufatura (Manufacturing Resourcing Planning) ix

15 x Capítulo 0. Lista de Siglas OLE Objetos Vinculados e Incorporados (Object Linking and Embedding) OPC OLE para Controle de Processos (OLE for Process Control ) OS Sistema Operacional (Operation System) OSI Interconexão de Sistemas Abertos (Open Systems Interconnection) PLC Controlador Lógico Programável (Programmable Logic Controller ) POU Unidades de Organização do Programa (Program Organization Unit) RTT Tempo de ida e volta (Round Trip Time) RISC Computador com Conjunto Reduzido de Instruções (Reduced Instruction Set Computer) SCADA Controle Supervisório e Aquisição de Dados (Supervisory Control and Data Acquisition) SFC Gráco Sequencial de Função (Sequential Function Chart) SIFB Bloco de Função de Interface de Serviço (Service Interface Function Block) SSL Camada Socket de Proteção (Secure Socket Layer) ST Texto Estruturado (Structure Text) TCP Protocolo de Controle de Transmissão (Transmission Control Protocol ) TI Tecnologia da Informação UDP Protocolo de Datagrama do Usuário (User Datagram Protocol ) UML Linguagem de Modelagem Unicada (Unied Modeling Language) XML Linguagem de Marcação Extensível (EXtensible Markup Language) WCET Pior Caso de Tempo de Execução (Worst Case Execution Time)

16 Lista de Figuras 2.1 Características que compõe o FB IEC (Adaptada de [IEC05a]) Trajetória das aplicações de AI em automação e controle Exemplo de sistema centralizado e distribuído Bloco de Função Tipico Classicação dos tipos de Blocos de Função IEC Aspecto de um Bloco de Função Básico Aplicação do Diagrama de Execução e Controle dentro de um Bloco de Função Básico. (Adaptada de [IEC05a]) Arquitetura de um Bloco de Função Composto Arquitetura de um Bloco de Função de Interface de Serviço Exemplo de arquitetura de hardware de um PLC Arquitetura de Software de um PLC padrão.(adaptada de [Bol06]) Evolução das redes de comunicação na industria Arquitetura TCP/IP Pirâmide dos níveis hierárquicos de sistemas industriais Comparação de objetivos de segurança das redes corporativas com as industriais. (Adaptada de [ISA07]) Software IEC e seu download no PLC Estrutura macro Servidor TCP em um PLC padrão IEC Disposição das tasks e FB compondo o servidor Trecho de código de um servidor TCP em um SIFB Serviços primitivos de um servidor de comunicação TCP Exemplicação do sistema de comunicação analisado xi

17

18 Lista de Tabelas 3.1 Descrição das variáveis para o Bloco Funcional de Comunicação Descrição dos eventos dos serviços primitivos para o Bloco Funcional de Comunicação Descrição dos estados alcançados pelo STATUS no servidor xiii

19

20 Capítulo 1 Introdução Atualmente, a aplicação de sistemas embarcados nos mais diversos equipamentos é bastante difundida nos segmentos industriais, automobilísticos e aeroespaciais. Recentemente, fabricantes têm desenvolvido sistemas inteligentes com softwares embarcados realizando a comunicação através de redes industriais com sistemas de controle e supervisão [AASZ04]. A norma IEC 61499, intitulada de Blocos de Função - (Function Blocks) [IEC05b], composta por quatro partes, dene a arquitetura sobre a utilização dos FB em sistemas de controle e automação. Os FB são elementos de linguagem de programação, sendo possível sua utilização em programas de software de automação e controle que respeitem a norma IEC Controladores Programáveis - (Programmable Controllers) [FAGS06]. Segundo [Chr08], os FB são aplicados em softwares e ferramentas de programação onde o hardware (PLCs, por exemplo) que os hospeda são desenvolvidos para o ambiente agressivo das aplicações industriais, nos quais os fatores mais relevantes são umidade, temperaturas elevadas, poeira e ruído eletromagnético. Os problemas de interoperabilidade entre os dispositivos na rede industrial tais como PLCs e servomotores com os sistemas de supervisão, Controle Supervisório e Aquisição de Dados (SCADA, do inglês Supervisory Control and Data Acquisition) e ou gerenciamento, Sistemas de Execução da Manufatura (MES, do inglês Manufacturing Execution Systems), são comuns. [TBPO07] cita em seu trabalho que a grande variedade de plataformas industriais pode resultar em problemas de incompatibilidade tendo em vista que cada fabricante ou plataforma adota seu próprio protocolo de comunicação. [WZ07] arma que as aplicações industriais necessitam de sistemas que forneçam segurança, seja no controle do processo ou na transmissão da informação, reduzindo os prejuízos devido às paradas de equipamentos e máquinas não previstas devido aos problemas de hardware e/ou software. 1

21 2 Capítulo 1. Introdução Contextualização A necessidade de interligar todos os níveis de uma planta industrial, permitindo com que o nível de gestão fabril obtivesse acesso aos dados de processo no instante em que ele ocorresse, foi uma motivação para que as redes industriais se integrassem às redes de Tecnologia da Informação (TI). Os diversos protocolos industriais possuíam formas distintas de se comunicar com outros níveis na rede e com as aplicações, sendo necessária a utilização de servidores de comunicação OLE para Controle de Processos (OPC, do inglês OLE for Process Control). Para o contexto deste trabalho de pesquisa, o conceito de aplicações de rede é desenvolvido admitindo-se que existam num ponto o cliente e em outro o servidor. Este último é responsável pelo fornecimento de quaisquer tipos de serviços aos seus clientes, desde que previamente congurado para o tipo de nalidade ao qual está sendo requisitado [Ste94]. Há na literatura uma quantidade considerável de trabalhos que abordam a utilização de softwares empregados nos FB IEC Existem trabalhos que apresentam propostas de se realizar a comunicação entre sistemas utilizando os blocos de função, tais como em [POM + 09], [DT08] e [Hag07]. Entretanto, estes trabalhos foram implementados em ambientes computacionais não destinados a área fabril, utilizando softwares e hardwares não padronizados para tal ambiente, e portanto, não possuem maiores detalhes sobre a aplicação de servidores de comunicação em sistemas padronizados para seu uso em sistemas industriais padronizados pela IEC Motivação A norma IEC foi estruturada com o objetivo de denir a arquitetura de componentes de software, padronizando as linguagens de programação dedicadas aos sistemas industriais. Estas linguagens eram simples e fáceis de serem implementadas, construídas para as necessidades especícas da indústria. A grande vantagem para o controle de sistemas industriais veio com isto. Contudo, diversos protocolos de comunicação de diferentes fabricantes foram implementados, tornando complexa a comunicação entre sistemas, além de aumentar os custos de licenças de softwares proprietários. No trabalho de [XYWS04] é citado um problema comumente encontrado na indústria, onde a integração dos dados da produção com o nível gerencial através do servidor OPC hospedado tipicamente em um microcomputador é oneroso devido às licenças de Sistemas Operacionais (OS, do inglês Operational System), desenvolvimento e a manutenção especializada na integração dos sistemas, tornando a solução inviável nanceiramente para pequenas empresas que possuem baixo capital de investimento. Com o advento da IEC 61499, problemas como os da portabilidade, interoperabilidade e exibilidade poderiam ser minimizados com a padronização dos ambientes externo e interno do FB, tornando simples a intercambialidade dos sistemas entre diferentes fabricantes e

22 Motivação 3 dispositivos, além de métodos de programação mais elementares, cuja lógica interna pode ser reutilizada de maneira mais segura através da lógica orientada a objetos. [ALT07] menciona que linguagens orientadas a objetos trazem como vantagem: Possibilidade de combinar um objeto a outros livremente de forma a produzir novos sistemas; A lógica dos elementos pode ser compreendida individualmente, o que torna o software mais simples; A propriedade intelectual é mantida pois sua lógica interna está inacessível para alterações não planejadas. A utilização de ferramentas apoiadas na norma IEC tem sido tema de congressos e revistas especializadas no assunto. As aplicações de FB em diversos ramos de atividade têm agregado conhecimento teórico e prático aos diversos segmentos de pesquisa da indústria [ST10]. A inserção na indústria dos padrões da IEC é necessária e a comunidade cientí- ca tem realizado esforços constantes para que a nova norma adentre nos diversos setores com o intuito de resolver os problemas causados pela falta da interoperabilidade. Todavia, a aceitação da norma pela indústria ainda é pequena, pois os custos de mudança dos sistemas já existentes são altos e desencoraja sua inserção no mercado. No trabalho realizado por [SCKP07], é mencionado que as empresas têm forte motivação para manter os dispositivos e ferramentas de software baseados em normas bem difundidas como a IEC Entretanto, uma solução possível para que a IEC rompa estes obstáculos seria a mescla dos conceitos e benefícios da IEC com sistemas da IEC , o que poderia vir a reduzir signicativamente os custos de investimentos em novos hardwares e softwares dedicados exclusivamente à nova norma. Portanto, uma solução híbrida traria benefícios aos setores industriais, alavancando a tecnologia de sistemas distribuídos. De acordo com a norma IEC [IEC03a], um dispositivo industrial pode atuar como um servidor na rede e, por meio desta, torna-se justicável a IEC como referência para desenvolver a arquitetura padrão de um FB com servidor TCP/IP embarcado. Servidores de Comunicação podem ser considerados como sistemas responsáveis pelos procedimentos de acesso à rede, provendo a interface entre dispositivos. Existe uma gama de tipos de protocolos de comunicação através da pilha TCP/IP. No meio industrial, ambos os protocolos da camada de transporte, Protocolo de Transmissão de Controle (TCP, do inglês Transmission Control Protocol ) e Protocolo de Datagrama do Usuário (UDP, do inglês User Datagram Protocol) são utilizados. Entretanto, devido as características intrínsecas de cada um dos protocolos, o TCP pode ser empregado em aplicações das quais não se exige tempo de envio e recebimentos pequenos, como na monitoração de variáveis por sistemas de gerenciamento e supervisão, o que não são atividades de alta criticidade, ou seja, não implicam em problemas de segurança física das instalações ou pessoas ligadas ao processo. O UDP

23 4 Capítulo 1. Introdução 1.4 pode ser utilizado na comunicação de alguns protocolos industriais para controle, devido as suas características para envio e recebimento de mensagens [ODV07]. Devido ao objetivo deste projeto de pesquisa ser de permitir que exista a interoperabilidade entre dispositivos industriais com outros níveis da rede seguindo o modelo ISA, atribui-se maior interesse no protocolo TCP pela padronização da comunicação utilizando o FB padrão. 1.3 Objetivos O objetivo principal deste trabalho foi de explorar a aplicação do FB IEC com o intuito de realizar a arquitetura do servidor de comunicação TCP/IP. Dentre os objetivos especícos, podem-se citar: Investigação da arquitetura de um servidor de comunicação TCP/IP; Realização do desenvolvimento dos serviços primitivos de comunicação utilizando a norma IEC como base Trabalhos Publicados Durante a realização deste projeto de pesquisa publicou-se ou foram aceitos os trabalhos a seguir em congressos cientícos internacionais, sendo eles: 1. Architecture of network Function Block for remote monitoring over IP [ST10]; 2. Design online control of biodiesel production using function block IEC and coriolis ow meter [Car10]; 3. Communication Server TCP/IP using Function Block IEC Metodologia Recursos Para a realização deste projeto foi necessário o uso das instalações do Laboratório de Informática da Universidade Federal do ABC, bem como o uso da estrutura e espaço previamente destinados para o desenvolvimento deste tipo de atividade Métodos Neste projeto realizou-se os algoritmos e diagramas de tempo aplicados às FB IEC Estes algoritmos respeitam a sequencia lógica do diagrama de tempo de serviços primitivos da IEC O modelo proposto foi analisado e comparado com o disponível nas literaturas da área.

24 Organização Forma de Análise dos Resultados Foi atribuída uma avaliação qualitativa para se avaliar o comportamento do servidor TCP/IP dentro de um programa IEC Tal avaliação estimou alguns fatores, tais como: Quantidade de clientes que o FB contendo o servidor pode se comunicar; Tempo estimado de varredura do programa; Tempo estimado total para a comunicação entre cliente e servidor. 1.5 Organização Este trabalho está organizado da seguinte forma. No capitulo 2 é apresentado o estado da arte. O capítulo 3 aborda a estrutura dos FB padronizados pela IEC 61499, necessário para o bom entendimento da norma e compreensão deste projeto de pesquisa. O capítulo 4 apresenta importantes conceitos sobre as redes de comunicação voltadas às aplicações industriais: sua evolução até a atualidade, a integração dos níveis de uma planta industrial, além de uma breve introdução sobre segurança da informação no ambiente fabril. Abordar sobre as particularidades do hardware e software dos PLCs. No capítulo 5 é demonstrada a solução proposta, bem como os resultados obtidos. Por m, no capítulo 6 são explanadas as conclusões deste projeto de pesquisa bem como a discussão sobre o tema abordado. 1.6 Considerações sobre o estilo e formatação do texto Para facilitar a leitura, optou-se por não traduzir termos ou siglas consagrados na língua inglesa, bem como não foi utilizado plural para algumas siglas, como por exemplo os function blocks abreviado por FB, e não FBs. 7

25

26 Capítulo 2 Estado da Arte Este capítulo aborda a fundamentação teórica sobre sistemas voltados às redes de comunicação industriais. Dividiu-se em duas categorias para apresentação do assunto: Referências às normas de padronização internacionais para sintaxe e semântica para desenvolvimento de hardware e software para sistemas industriais; abordar as publicações em revistas e congressos mais relevantes na área e publicações não normativas que auxiliam no embasamento deste trabalho de pesquisa. 2.1 Normas internacionais O padrão é um conjunto de melhores práticas que estabelece as regras e diretrizes técnicas, as quais possibilitam a transmissão de informações e dos conhecimentos adquiridos, além de ser um guia para desenvolvimento de hardware e software quando tratando-se de projetos de engenharia [Ara98]. A necessidade de padronização no âmbito industrial deve-se a fatores diversos, como: Garantir a qualidade do hardware/software desenvolvido; Viabilizar a produção de equipamentos em larga escala; Interoperabilidade em hardwares e software distintos. Distintas instituições de padronização propagaram informes, manuais e normas técnicas com as melhores práticas com o intuito de se desenvolver software para aplicações industriais. Órgãos reconhecidos internacionalmente, tais como o Instituto de Engenheiros Elétricos e Eletrônicos - (Institute of Electrical and Electronics Engineers - IEEE), a Organização Internacional de Padronizações / Comissão Internacional Eletrotécnica - (International Organization for Standardization / International Electrotechnical Commission - ISO/IEC) e a Sociedade de Automação Internacional - (International Society of Automation - ISA), são responsáveis pela publicação de diversos manuais, relatórios e métodos para processos industriais, tais como a norma ISA 95 - Integração de Sistemas de Controle-Empresa 7

27 8 Capítulo 2. Estado da Arte 2.1 (Enterprise-Control System Integration) [ISA08], entre outras. A ISO/IEC, publicou normas como a série que compõe a IEC [IEC03b], intitulada de Controladores Programáveis (Programmable controllers), dividida em sete partes: IEC : Informações Gerais - (General information) (2003): Contém denições gerais e funcionalidades típicas, as quais estabelecem o conceito básico de arquitetura de hardware e software de um PLC, bem como as denições para os termos técnicos expostos nas normas subsequentes a esta [IEC03c]; IEC : Requerimentos de Equipamentos e Testes - (Equipment requirements and tests) (2003): Estabelece os requisitos mínimos necessários para os desenvolvimentos nos quesitos elétrico, mecânicos e funcionais, além de estabelecer valores para compatibilidade eletromagnética e testes aplicáveis aos dispositivos industriais [IEC03d]; IEC : Linguagens de Programação - (Programming languages) (2003): A estrutura de software e as linguagens de programação são denidas por intermédio de denições formais e semânticas, além de exemplos ilustrativos. Nesta parte da norma, são abordadas as cinco principais linguagens de programação voltadas à automação e controle [IEC03e], sendo elas: Descrição do Bloco de Função - Function Block Discription (FBD): Esta linguagem é orientada a objetos e faz uso do diagrama de blocos para realizar a lógica de controle; Lista de Instruções - Instruction List (IL): Esta linguagem utiliza listas de instruções para realizar o controle do sistema; Diagrama Escada - (Ladder Diagram) (LD): Linguagem que utiliza elementos grácos, em forma de diagramas de contatos, para representação da lógica do programa; Texto Estruturado - (Structured Text) (ST): Linguagem de programação textual utilizando controle de sub-programas e seleção para representar o algoritmo do programa; Gráco de Função Sequencial - Sequential Function Chart - (SFC); Misto entre linguagens grácas e textuais utilizando transições e passos para demonstrar a estrutura da lógica do software desenvolvido.. IEC : Parâmetros de Usuários - (Users guidelines) (2003): Esta parte fornece um roteiro para auxiliar o usuário de sistemas industriais em todas as etapas de um projeto de automação [IEC03f]; IEC : Comunicação - (Communications) (2003): Estabelece regras para a comunicação entre PLCs de diferentes fabricantes e dispositivos diversos [IEC03a];

28 Normas internacionais 9 IEC : Linguagem de Controle Fuzzy - (Fuzzy Control Language) (2003): O objetivo desta parte da norma é prover para fabricantes e usuários o comum entendimento da integração de aplicações de controle fuzzy baseados na IEC [IEC03g]; IEC : Parâmetros para aplicação e implementação de linguagens de programação para Controladores Lógico Programáveis - (Guidelines for the application and implementation of programming languages for Programmable Logic Controllers) (2003): Este documento inclui diretrizes de implementação, instruções de utilização pelo usuário nal, am de esclarecer dúvidas referente a IEC [IEC03h]. Conforme discutido anteriormente, os modelos primitivos de FB foram incorporados primeiramente na norma IEC , e logo após, mediante as necessidades intrínsecas de detalhamento da arquitetura e aplicações da FB zeram com que a IEC fosse elaborada, trazendo preceitos atuais de implementação de software [Vya09]. Contudo, o FB abordado por ambas as normas já criava formatação no início dos anos 90, quando o IEC- TC 65: Projetos de Sistemas de Controle e Medição para Processos Industriais, (IPMCS, do inglês Industrial Process Measurement and Control Systems ) propôs uma arquitetura de FB tratados genericamente. A IEC Blocos de Função -(Function Blocks) é composta por 4 partes, listadas a seguir: IEC : Arquitetura - (Architecture) (2005): Esta parte da norma expõe os requisitos gerais (escopo, referências normativas, denições, modelos de referência e diretrizes para suas aplicações em sistemas de automação e controle) e regras para a declaração de FB, referente ao comportamento das instâncias. Também é especicado o uso de FB para a comunicação e gerenciamento de aplicações, recursos e dispositivos de IPMCS [IEC05a]; IEC : Requisitos de Ferramentas de Software - (Software Tool Requirements) (2005): Dene os requisitos das ferramentas de software que auxiliem o desenvolvimento das projetos de IPMCS, incluindo a especicação de tipos de FB, recursos e dispositivos, além da análise, validação, conguração, implementação, operação e manutenção destes sistemas. Esta parte da norma também dene os requisitos para que ferramentas de software de diferentes fabricantes possam transmitir dados entre eles [IEC05c]; IEC : Tutorial - (Tutorial information ) (2005): Nesta parte da norma são tratadas as Frequently Asked Questions (FAQ) sobre a série da IEC 61499, bem como exemplos de utilização de FB com o intuito de solucionar questões comumente encontradas em automação e controle [IEC05d]; IEC : Regras para Pers de Aderência à Norma - (Rules for Compliance Pro- les) (2005): Esta parte da norma dene os procedimentos para desenvolvimento de

29 10 Capítulo 2. Estado da Arte 2.1 pers de aderência, os quais especica as características da IEC e a serem implementadas para prover os atributos de: interoperabilidade entre dispositivos e portabilidade do conteúdo programado entre ferramentas de software de fabricantes distintos [IEC05e]. As características inerentes que compõe a IEC demonstradas na gura 2.1, demonstram vantagens quando comparado a antiga norma IEC , pode-se citar: Interoperabilidade: É a capacidade de dispositivos distintos trabalharem em conjunto para executar funções previstas na conguração do sistema; Portabilidade: Origina-se quando duas ou mais ferramentas de software interpretam e aceitam corretamente bibliotecas produzidas por outros software; Congurabilidade: É a característica que um dispositivo tem de ser congurado por distintas ferramentas de software. Figura 2.1: Características que compõe o FB IEC (Adaptada de [IEC05a]) Além das normas já mencionadas, muitas outras foram geradas a m de se padronizar as melhores práticas para se desenvolver e implementar hardware e software para ambientes industriais, impactando na redução de custos operacionais e garantindo a qualidade e segurança, direta e indiretamente. Citam-se: IEC 61508: Segurança Funcional de Elétrica/Eletrônica/Eletrônica Programavel (E/E/PE) Sistemas Relacionados com Segurança - (Functional safety of electrical/electronic/ programmable electronic (E/E/PE) safety-related systems)(2010): Esta norma é a principal referência para segurança em sistemas elétricos e de instrumentação. Dividida em sete partes, propõe as regras e caracterizações para analises de áreas de risco, desenvolvendo quesitos de segurança e implementação nestas áreas classicadas. [IEC10];

30 Publicações não normativas e conferências 11 IEC 61784: Redes de Comunicação Industrial (Industrial Communication Networks) (2007): Esta norma detalha um conjunto de pers de protocolos de comunicação para utilização na arquitetura de dispositivos que tem a necessidade de comunicação industrial [IEC07]. 2.2 Publicações não normativas e conferências A utilização de ferramentas apoiadas na norma IEC tem sido tema de congressos, jornais e revistas especializadas no assunto. As aplicações de FB em diversos ramos de atividade têm agregado conhecimento teórico e prático aos diversos segmentos de pesquisa da indústria. No trabalho de [FAGS06] é citado que o FB possui características que o torna bastante atrativo em software de automação. A motivação para tal baseia-se na alegação de que a norma IEC prevê que o FB possua arquitetura externa e interna distintas, além da possibilidade de sua lógica interna ser estruturada em quaisquer linguagens de programação de alto nível e/ou estabelecidas pela IEC O trabalho de [POM + 09] buscou focar-se na integração de uma interface de comunicação OPC desenvolvida para atuar em conjunto com os FB IEC A arquitetura da aplicação baseava-se no software Tempo de Execução do Bloco de Função (FBDK, do inglês Function Block Run Time) desenvolvido por um dos principais colaboradores na construção da norma, o pesquisador James H. Christensen [Chr08]. Esta ferramenta de software baseada sob a plataforma Java, atuava no OS Windows, possuindo modelos de FB e possibilidade de simulação da lógica de uma cadeia de FB. Os autores realizaram estudos sobre a comunicação de entre os dois computadores, ambos com a mesma arquitetura de hardware e software instalados, divergindo apenas sobre a utilização dos protocolos de comunicação aplicados, fazendo-se necessário o uso do OPC Classic. Contudo, seu uso restringia-se a sistemas não padronizados e suscetíveis a falhas devido as características de construção do OS escolhido. A contribuição desta aplicação para o meio acadêmico foi de grande importância, pois trouxe a possibilidade de novos estudos de comunicação com as aplicações da norma IEC No setor automotivo, o controle distribuído também é enfatizado na arquitetura de software de transmissão de dados baseadas na norma IEC A busca por eciência nas redes de comunicação baseada em dispositivos que permitam o encapsulamento de sua lógica foi a motivação para o trabalho [ZHD05]. Esta abordagem trouxe como benefícios a reutilização de componentes, exibilidade e independência de hardware, já que a solução é padrão, proporcionando maior segurança no emprego do FB. No trabalho de [DT05], foram ilustradas aplicações de controle distribuído baseadas na IEC 61499, executadas sobre o OS Linux. A proposta arma que o envio de informações de processo são enviadas em microssegundos e demonstra métricas de desempenho para contribuir com a alegação apresentada. Segundo os autores, até aquele momento, aplicações

31 12 Capítulo 2. Estado da Arte 2.2 desenvolvidas em ambiente Linux não disponibilizavam os dados na rede a tempo suciente para realizar atividades de controle em robótica, automação de máquinas industriais e sistemas de aeronaves. A evolução da utilização de Inteligencia Articial (AI, do inglês Articial Intelligence) na área de sistemas de automação e controle pode ser contemplada na gura 2.2, na qual três épocas distintas são referenciadas. O primeiro ano apresentado, 1980, delimita a AI aplicada a software de controle. A padronização das linguagens de programação voltadas à automação possibilitou que a AI pudesse ser embarcada em FB, representando o segundo marco temporal. Atualmente, as pesquisas de AI embarcadas em FB IEC ganham destaque no meio acadêmico, sendo este último o terceiro marco. Figura 2.2: Trajetória das aplicações de AI em automação e controle Mediante a linha do tempo demonstrada acima, serão apresentadas as pesquisas de relevância de AI na área industrial. Em sistemas de controle [YKMA99], AI foi aplicada na simulação numérica do processo de controle com o objetivo de avaliá-lo e controlá-lo através de um microcomputador. A utilização de FB em Redes Neurais Articiais (ANN, do inglês Articial Neural Network) vem sendo foco em trabalhos de pesquisa devido à exibilidade na montagem da arquitetura da rede, visto que é possível conectar vários FB uns aos outros. De acordo com [Vya12], a AI de um dispositivo incorporado em uma máquina aumenta signicativamente sua importância, pois amplia sua funcionalidade, aumentando o seu desempenho e conabilidade. O autor diz que um software de PLC desenvolvido em ST para a aquisição de dados de um scanner, por exemplo, deveria ser reescrito completamente se o dispositivo fosse trocado por um similar de outro fabricante. Portanto, sua proposta foi de embarcar AI a um FB IEC que poderia ser substituído facilmente na estrutura do software sem ter que alterá-lo em grandes partes. Este FB faria a comunicação entre os dispositivos industriais no chão-de-fábrica, tornando o sistema distribuído. No trabalho publicado por [WZ07], é demonstrada a utilização da IEC embarcando o Protocolo Industrial Comum (CIP, do inglês Common Industrial Protocol ), assim vericando a funcionalidade deste novo método. Deste modo, aplicando esta mesma analogia de comunicação, faz-se a modelagem das FB através das RdP, como máquina de estado, assim utilizando a ideia de [VD10] para modelar e conrmar a simplicação e a utilização das propriedades da RdP para validar a nova concepção. Em [Ins] é encontrada a denição sobre o que é e como atuam os principais OS, fazendo-se uma comparação entre os OS tradicionais, demonstrando as principais vantagens e desvan-

32 Publicações não normativas e conferências 13 tagens em se utilizar tais plataformas. De acordo com os autores, sistemas como Microsoft Windows e MacOs podem ser usados como plataformas para desenvolvimento e aplicações de sistemas de automação desde que tais sistemas não sejam críticos, ou seja, deve-se utilizar estas plataformas em sistemas onde a segurança não esteja em pauta, pois não há garantias que o sistema utilizado estará sempre operante e disponível. Também é citado no trabalho que os OS não seguem integralmente as regras que o programador aplica em seu algoritmo, pois a função principal dos OS são de otimizar a grande variedade de aplicações e processos simultaneamente. Portanto, tasks com menor prioridade podem ser executadas antes de outras com maior prioridade, tornando o sistema não conável para aplicações de controle. A crescente complexidade de sistemas de automação ocasiona impacto nas medições de comunicações entre periféricos. Devido a este problema, no trabalho de [SZ10] foram demonstrados métodos para cálculos do tempo de varredura em sistemas distribuídos baseados em rede ethernet, utilizando o conceito do Pior Caso do Tempo de Execução (WCET, do inglês Worst Case Execution Time). Também foi alvo de estudo a melhora de desempenho de comunicação através do agrupamento das mensagens na rede.

33

34 Capítulo 3 IEC A IEC foi desenvolvida como uma referência para arquitetura de sistemas de controle exíveis, modulares e distribuídos. Ela expõe uma arquitetura genérica que poderia ser utilizada para uma gama de padrões, ou seja, PLCs, dispositivos inteligentes, protocolos de comunicação e portanto, poderia ser considerado como o elemento essencial no IPMCS [Chr08]. Com o intuito de beneciar o bom entendimento deste projeto de pesquisa serão realçados neste capítulo os tópicos mais relevantes da parte 1 da norma IEC já introduzida no item Estado da Arte. 3.1 Parte 1 - Arquitetura Na parte 1 da norma são expostos modelos de referência de FB onde obtêm-se a abstração e os conceitos primordiais para entendimento e discernimento sobre suas classes e aplicações Modelos de Referência da IEC Sistema Pode ser considerado como um ou mais conjuntos de elementos da IPMCS que são relacionados e interligados entre si através de uma rede. Nesta conguração a aplicação pode ser alocada em um dispositivo, conforme demonstrado pela letra "Z"na gura 3.1, bem como ser distribuída entre diversos dispositivos conforme demonstrado pela aplicação simbolizada pela letra "A"da gura 3.1. No modelo proposto pela norma o controle pode ser realizado em um dispositivo e as entradas e saídas da aplicação podem estar concentradas em outro dispositivo, por exemplo Dispositivo É uma entidade física apta a realizar uma ou mais funções. É previsto que um dispositivo deva possuir uma ou mais interfaces de comunicação e ou processo. A interface de comuni- 15

35 16 Capítulo 3. IEC Figura 3.1: Exemplo de sistema centralizado e distribuído. cação apresenta um mapeamento entre o recurso e as informações transmitidas na rede. Os serviços realizados por esta interface podem ser de apoio à programação como diagnóstico e conguração. A interface de processo realiza o mapeamento entre os sinais físicos (I/Os, medidas analógicas, entre outros) e os recursos. Os valores dos sinais físicos são apresentadas para o recurso em forma de eventos ou dados Recurso É denido como uma unidade funcional hospedada em um dispositivo. Tal unidade funcional mantém as aplicações do sistema. É pressuposto pela norma que um recurso possa ser apagado, congurado e inicializado sem afetar outros recursos do dispositivo. A função de um recurso é a de receber e tratar os dados das interfaces, bem como fornecer de volta os dados correlatos. O controle da transferência de dados entre uma rede de FB também é atribuído ao recurso, de acordo com a chegada dos eventos e prioridades de execução Aplicação Consiste de uma rede de FB sendo que o nó pode ser denido como uma subaplicação parametrizada. Os ramos da rede são as conexões de dados ou eventos entre os FB. A aplicação pode ser partilhada entre recursos de um ou mais dispositivos. A aplicação em conjunto com o recurso executa ações pertinentes em réplica aos eventos recebidos. As ações podem ser de execução dos algoritmos dos FB, interações com as interfaces de processamento e de comunicação, além da modicação do valor das variáveis.

36 Parte 1 - Arquitetura Bloco de Função Baseado em evento dirigido (event-driven), o Bloco de Função possui interface externa contendo variáveis de entrada e saída, eventos de entrada e saída, bem como as variáveis internas e descrição da lógica contida. O aspecto externo de um FB genérico pode ser visualizado na gura 3.2. A arquitetura de software de um FB é comparada a de um circuito integrado, pois sua lógica é estruturada internamente reiterando o encapsulamento da lógica e seu comportamento tratando-a similarmente a entidades físicas, ou seja, circuitos eletrônicos. Segundo a descrição de [Chr08], as variáveis de entrada são escritas externamente e lidas internamente ao FB. O autor ressalta também sobre o uso de variáveis diretas de entrada e saída (through variables) que podem ser compartilhadas entre diversos FB. O uso deste tipo de variável é destinado quando se deseja que todos os FB conectados a ela acessem o valor da variável conectada à primeira entrada da cadeia. Destaca-se que as variáveis de interface (entrada, saída e through variables) de um FB podem ser interligadas unicamente se seus tipos de dados forem compatíveis. A atuação interna dos FB pode ser especicada para obedecer a critérios de eventos, tempo contínuo e tempo discreto e suas instâncias mantêm a persistência das informações de seu estado interno. Figura 3.2: Bloco de Função Tipico Distribuição O objetivo desta etapa da norma é exemplicar que um FB de uma aplicação pode ser distribuído em mais de um dispositivo ou recurso. Contudo, apesar de distribuídos, os FB mantém sua concepção original inalterada Estado Operacional É o estado de uma unidade funcional (aplicação, recurso ou dispositivo) a qual realiza o gerenciamento das ações permitidas, vindo ao encontro com o andamento atual no qual esteja o projeto (desenvolvimento, start up ou comissionamento e operação). Portanto, os estados de uma unidade funcional podem ser denidos como carregado, congurado e parado.

37 18 Capítulo 3. IEC Após terem sido introduzidas as principais denições da norma faz-se necessário conhecer os tipos de blocos de função padronizados, bem como suas subaplicações. Tais conceitos serão abordados na próxima subseção com o intuito de prover um melhor entendimento sobre o projeto de pesquisa Tipos de Blocos de Função Os Blocos de Função são identicados através de suas instâncias, pelo tipo de categoria pertencente, bem como o tipo e ordem dos eventos incidentes sobre eles. As categorias são denominadas pelas suas respectivas espécies, sendo classicas pela IEC em: Blocos de Função Básicos (BFB, do inglês Basic Function Blocks), Blocos de Função Compostos (CFB, do inglês Composite Function Block ) e os Blocos de Função de Interface de Serviços (SIFB, do inglês Service Interface Function Block ). A gura 3.3 exemplica as categorias dos blocos de função e suas subclassicações. Figura 3.3: Classicação dos tipos de Blocos de Função IEC A seguir será detalhado o funcionamento interno e externo de cada um dos tipos dos Blocos de Função abordados acima, bem como suas respectivas subaplicações Bloco de Função Básico - Basic Function Block O Bloco de Função Básico pode ser denido como uma das ramicações dos FB. Estruturado a partir de seu algoritmo seguindo o Diagrama de Execução e Controle (ECC, do inglês Execution Control Chart), ou seja, máquina de estados padrão a qual dene a sequência nita de operações. O ECC mapeia os possíveis estados cruzando-os com os valores de entrada e saída além dos eventos atrelados a elas. A estrutura de um BFB pode ser visualizada na gura 3.4.

38 Parte 1 - Arquitetura 19 Figura 3.4: Aspecto de um Bloco de Função Básico Diagrama de Execução e Controle - Execution Control Chart O ECC é constituído de estados, ações e transições. Na arquitetura interna do BFB é estabelecida sua lógica de funcionamento através de linguagens estabelecidas pela IEC , já mencionadas anteriormente. Contudo, a IEC não proíbe que outros tipos de linguagens possam ser usadas na aplicação. O algoritmo desenvolvido segue o critério da máquina de estado conectado a uma classe pertencente ao ECC elaborado, o qual faz o envio e recebimento dos eventos/dados a cada transição da máquina de estados, portanto, o ECC está diretamente ligado à lógica da BFB. A estrutura do ECC descrito por [IEC05a] pode ser descrita abaixo: "ECC could have graphical or textual representation of the causal relationships among events at the event inputs and event outputs of a function block and the execution of the function block's algorithms, using execution control states, execution control transitions, and execution control actions". O comportamento de um BFB, dado pelo ECC, pode ser demonstrado através da Linguagem de Modelagem Unicada (UML, do inglês Unied Modeling Language) por intermédio de uma máquina de estados nita. Desta forma, os estados são demonstrados pelo (EC State), sendo sempre o estado inicial chamado (START). As transições entre estados - (EC Transition) representam os eventos e as condições que provocam a mudança de estado. A ação - (EC Action) é utilizada para denotar o algoritmo que deve ser executado nesse estado e quais eventos devem sofrer atualização [Vya12]. A gura 3.5 demonstra um BFB e à sua direita ao ECC correspondente. O algoritmo desenvolvido neste exemplo está associado às entradas do tipo BOOL, sendo elas: E-HABILITA e HABILITA. Para o caso de ser selecionada a entrada HABILITA associada ao evento de entrada EI, gerará no evento de saída EO o nível lógico 1. Portanto, os eventos de entrada e saída são utilizados para sinalizar que a FB está pronta para execução da lógica, bem como sua sinalização referente à lógica ocorrida.

39 20 Capítulo 3. IEC Figura 3.5: Aplicação do Diagrama de Execução e Controle dentro de um Bloco de Função Básico. (Adaptada de [IEC05a]) Bloco de Função Composto - Composite Function Block O Bloco de Função Composto é constituído por dois ou mais FB alocados em sua arquitetura interior. O objetivo é de que aja uma rede de FB interna conectando-a às entradas e saídas externas de acordo com a necessidade e a lógica desejada. Portanto, o CFB assemelha-se externamente ao BFB, contudo, sua aplicação não é tão ampla de tal forma que seus eventos não podem ser ligados a dados. Sua estrutura pode ser vista na gura 3.6. Figura 3.6: Arquitetura de um Bloco de Função Composto Bloco de Função de Interface de Serviços - Service Interface Function Block O acesso às portas de comunicação é realizado pelo Bloco de função de interface de serviço (SIFB). Este mecanismo proporciona uma interface padrão, independentemente da

40 Parte 1 - Arquitetura 21 aplicação. De acordo com [POM + 09], o SIFB é a interface entre a aplicação e a função de mapeamento de um recurso. Ele é responsável por fornecer um ou mais serviços para uma aplicação baseado no gerenciamento de serviços às suas entradas e saídas de dados/eventos. A modelagem da capacidade funcional de um recurso, ou seja, o diagrama de comunicação estabelecido pelo SIFB é descrita através de uma sequência primitiva de serviços cujo objetivo é proporcionar uma representação abstrata da interação entre recurso e a aplicação. Os serviços primitivos são representações das ações dos eventos de comunicação. Cada evento, chamado também de primitiva, especica a ação a ser executada ou informa o resultado de uma ação previamente solicitada. A primitiva pode transportar os parâmetros necessários para desempenhar suas funções. A IEC faz menção de seu uso para estabelecer a especicação dos serviços de comunicação para os SIFB de forma a estabelecer um mapeamento ilustrando um caminho sequencial de dependência de eventos. Estes serviços seguem o modelo gráco proposto pela norma IEC 10731, indicados por setas horizontais cujos nomes dos eventos aparecem adjacentes às setas do gráco. A SIFB é dividida em duas subclassicações, sendo elas: Bloco Funcional de Comunicação - Communication Function Block Representa a interface entre as funções de mapeamento de comunicação e as aplicações. A tabela 3.1 especica a semântica padrão aplicada para as variáveis de entrada e saída do Bloco funcional de comunicação. A arquitetura gráca é semelhante da BFB e pode ser vista na gura 3.7, assim como o diagrama de sequência temporal genérico. Tabela 3.1: Descrição das variáveis para o Bloco Funcional de Comunicação Variável Tipo Descrição PARAMS Entrada Usado na identicação do tipo do protocolo de comunicação SD-m Entrada É atualizado com o dado a ser transferido RD-n Saída É atualizado com o dado recebido do dispositivo remoto STATUS Saída Representa o estado atual da conexão A tabela 5.1 expõe a semântica dos serviços primitivos do Bloco de Função de comunicação utilizado para estabelecer os eventos referente a abertura e fechamento da conexão entre dois ou mais dispositivos na rede. Os eventos representados por REQ, CNF, IND e RSP são utilizados para a sincronização da transferência dos dados representados pelas entradas SD e saídas RD Bloco Funcional de Gerenciamento - Management Function Block Executa funções em um recurso ou dispositivo. Estas funções podem ser de apagar, criar, inicializar, parar, bem como gerar noticação de mudanças de estado.

41 22 Capítulo 3. IEC Tabela 3.2: Descrição dos eventos dos serviços primitivos para o Bloco Funcional de Comunicação Evento Tipo Descrição INIT+ Entrada Requisição para modo de escuta ou abertura da conexão INIT- Entrada Requisição para fechamento da conexão INITO+ Saída Indica que a conexão foi bem sucedida INITO- Saída Indica conexão mal sucedida ou nalizada REQ+ Entrada Requisição de transferência de dados habilitada REQ- Entrada Requisição de Transferência de dados desabilitada CNF+ Saída Conrmação de que houve sucesso na transmissão CNF- Saída Indicação de que houve falha na transmissão IND+ Entrada Indicação de dados recebidos com sucesso IND- Entrada Indicação de que dados recebidos vieram corrompidos RSP+ Saída Resposta de requisição foi enviado RSP- Saída Resposta de requisição não foi executada Figura 3.7: Arquitetura de um Bloco de Função de Interface de Serviço

42 Capítulo 4 PLC e Redes Industriais 4.1 Arquitetura de um PLC padrão O hardware de um PLC ilustrado na gura 4.1 é basicamente constituído de fonte de alimentação, Unidade Central de Processamento - ( CPU, do inglês Central Process Unit), memórias dos tipos xo e volátil, terminais de entradas e saídas e módulo de comunicação, sendo este último opcional. A capacidade e características que compreendem o PLC são proporcionais a velocidade e característica do processador empregado conforme armado em [Bol06], onde é demonstrada a arquitetura comumente utilizada para construção do hardware do PLC, sendo este conhecido como arquitetura de Computadores com Conjunto Reduzido de Instruções - (RISC, do inglês Reduced Instruction Set Computer. Não é mandatório pela norma que o PLC deva utilizar esta arquitetura, contudo o desempenho satisfatório aliados a custos de fabricação tornaram a arquitetura RISC fortemente empregadas neste tipo de aplicação. De acordo com a IEC , um PLC pode ser denido como um equipamento eletrônico, com arquitetura de hardware e software destinado às aplicações industriais. O PLC é amplamente aceito em automação e controle motivado pela garantia de que o processo de produção de um sistema de manufatura continuará em funcionamento ainda que esteja sobre fatores adversos de clima, ruidos e demais interpéries [YZ10]. A arquitetura RISC foi desenvolvida com um quadro simplicado de instruções, cujo objetivo seria reduzir o tempo de execução de programas. No trabalho de [WHSS03] é mencionado que um programa com menos instruções ocupa menos espaço de memória e portanto um hardware mais sucinto poderia ser empregado, proporcionando um menor custo de fabricação e obtendo um bom desempenho quando comparado a arquitetura de Computadores com Conjunto Complexo de Instruções - (CISC, do inglês Complex Instruction Set Computer). Na gura 4.2 é possível observar a estrutura de software padronizada de um PLC. O quadro que compõe a área denominada conguração é denido como elemento de linguagem que corresponde a um sistema de um PLC. Compondo a conguração tem-se um ou mais 23

43 24 Capítulo 4. PLC e Redes Industriais 4.1 Figura 4.1: Exemplo de arquitetura de hardware de um PLC. Figura 4.2: Arquitetura de Software de um PLC padrão.(adaptada de [Bol06]) recursos, um ou mais programas, zero ou mais (tasks) e zero ou mais FB, ou seja, o software do PLC não obrigatoriamente deve possuir FB ou outros elementos de linguagem da IEC O recurso corresponde as funções de: processamentos de sinais, interface homem máquina e interface de sensores e atuadores. Estas funções são oriundas de eventos externos ao PLC, onde o recurso é responsável por receber, processar e enviar informações para as

44 Evolução das Redes Industriais 25 entradas e saídas físicas. Em [YZ10] uma task é descrita como sendo o elemento de controle periódico de um grupo de variáveis associado às Unidades de Organização de um Programa - ( POU, do inglês Program Organization Units). É atribuído em uma task os níveis de prioridade a cada grupo de variáveis, determinando seu tempo de varredura no programa e a prioridade de rotinas internas no PLC e podem ser classicadas em três tipos: cíclico, evento e interrupção. Cada variável interna é associada a um peso, ou seja, a sua prioridade de execução que dene sua classicação na varredura do programa. Tasks cíclicas são trechos do programa onde ocorre a varredura das variáveis em um intervalo de tempo pré determinado. Em casos onde o tempo limite de varredura seja ultrapassado o watchdog será acionado causando um alarme no PLC. A norma IEC expõe o watchdog como sendo um temporizador que é reiniciado regularmente a cada término de varredura do programa. Nas tasks direcionadas à eventos, a execução das variáveis do programa ocorrem imediatamente após advir um evento externo ao programa. As tasks orientadas à interrupções são executadas quando rotinas são chamadas, pausando momentaneamente a task em execução naquele instante e iniciando sua rotina de maior prioridade. Os PLCs podem suportar duas formas de controle em sua lógica interna, estabelecidos pela IEC : paramétrico e intertravado [IEC03e]. O controle paramétrico ocorre quando o PLC é direcionado a escrever valores em variáveis internas. Isto ocorre quando um programa ou aplicação executa a solicitação. O acesso a tais variáveis é controlado pelo PLC que as armazena. O controle intertravado é o método proposto pela norma que descreve como um dispositivo pode executar funções de escrita/leitura em outro dispositivo conectado a uma rede. Um exemplo prático pode ser observado quando o cliente solicita ao servidor para executar uma operação e informá-lo sobre o resultado da operação. Há dois aspectos deste serviço, a sincronização dos dados entre cliente e servidor e a troca de informações entre eles. No controle intertravado, essa troca de dados ocorre em pontos de sincronização na aplicação do programa. 4.2 Evolução das Redes Industriais As redes de comunicação são utilizadas no meio industrial desde os anos 40. Entretanto, nesta década, a comunicação se dava de forma discreta, ou seja, através de dispositivos eletromecânicos, os quais simbolizavam nível lógico 1 quando acionados e nível lógico 0 quando desacionados. Após duas décadas, nos anos 60, já se utilizava sinais analógicos de tensão e corrente (0-10V e 4-20mA) para medir grandezas físicas, como pressão, temperatura e vazão, bem como atuar instrumentos no campo com o intuito de controlá-los. Estas grandezas eram convertidas para corrente ou tensão através de circuitos eletrônicos dedicados [Kam96]. A imunidade desta tecnologia a interferências eletromagnéticas proporcionou sua popularização

45 26 Capítulo 4. PLC e Redes Industriais 4.2 até a atualidade. Utiliza-se 1 par de os para transmissão da informação. Sua arquitetura prevê a ligação ponto-a-ponto para cada dispositivo até o controlador. Com o advento dos computadores nos anos 70, pensou-se em seu uso para monitoração e controle de processos. Desta maneira, diversas etapas de controle poderiam ser concentradas em um único local, diferenciando sua forma de atuação, adaptando-se melhor as necessidades de seu respectivo processo. O intuito de redução de custos de infraestrutura foi uma das motivações para o advento da tecnologia Fieldbus. [SW03] cita em seu trabalho que o termo Fieldbus é utilizado para discriminar uma família de protocolos de comunicação que foram desenvolvidos especialmente para superar as limitações físicas e de desempenho de redes analógicas. Tais famílias de protocolos possuem vantagens quando comparado ao sinal analógico para transmissão dos dados de processo, pois nesta arquitetura utiliza-se um par de os para comunicação, e devido ao endereçamento dos dispositivos na rede, é empregada sua ligação em série. Passível de controlar vários pontos na rede, a tecnologia Fieldbus veio agregar robustez e exibilidade as malhas de controle de uma planta industrial [SMS10]. A rede Ethernet é a Tecnologia de Rede Local - (LAN, do inglês Local Area Network), padronizada pela IEEE Padrão para Tecnologia da Informação - Redes Locais e Metropolitanas - Requesitos Especícos - Parte 3 - (Standard for Information Technology - Local and metropolitan area networks - Specic requeriments-part 3) [IEE09], utilizada na automação de escritórios para estabelecer a comunicação entre computadores, servidores, impressoras e outros [ST10]. Seu nascimento ocorreu praticamente no mesmo período que a rede Fieldbus, entretanto, seu uso destinava-se somente a aplicações residenciais e de escritório. Na virada do século XX, iniciavam-se as primeiras soluções para Ethernet em aplicações industriais, desenvolvidas utilizando por exemplo, os padrões HSE, EtherNet/IP, PROFINET e Ethercat [JSW07]. Alguns problemas foram detectados no início da Ethernet para o uso industrial, como: rede não determinística, integridade dos dados não garantida pelo protocolo de comunicação, susceptibilidade a ruídos eletromagnéticos e etc. Porém, os protocolos citados acima prometiam à sua maneira resolver os problemas citados por hardware e/ou software. O emprego e interesse da rede Ethernet nos segmentos industriais para a monitoração e controle de malhas de processo ganhou grande repercussão e utilização, e isto deve-se ao seu baixo custo de instalação e manutenção, alta velocidade e desempenho, além da sua forte consolidação tecnológica no mercado [MTT03]. Atualmente, as redes corporativas são predominantemente baseadas em Ethernet e no padrão TCP/IP. A utilização do TCP/IP também está presente no ambiente industrial, sendo empregado em equipamentos e dispositivos industriais [MTT03]. Contudo, muitas vezes são necessários gateways 1 para a conversão de protocolos sob a prerrogativa de propiciar uma interface comum a todos os níveis hierárquicos da rede industrial, pois a interoperabilidade 1 Gateway é um dispositivo intermediário, frequentemente empregado para interligar redes, separar domínios até mesmo para traduzir protocolos.

46 TCP/IP para aplicações industriais 27 entre dispositivos industriais e corporativos não ocorre de forma natural. Segundo [TBPO07], basicamente o conceito de interoperabilidade pode ser denido como a capacidade de um sistema de trabalhar com outros sistemas sem esforços adicionais do cliente. Figura 4.3: Evolução das redes de comunicação na industria A gura 4.3 retrata o cenário tecnológico dos últimos 70 anos, desde os anos 40. De acordo com [Lew01], o crescente progresso na funcionalidade dos sistemas de controle distribuídos deve-se pelos avanços tecnológicos de hardware e software. Devido a importância do padrão TCP/IP em ambientes industriais, descreveremos na próxima seção as principais características do protocolo TCP/IP. 4.3 TCP/IP para aplicações industriais A arquitetura TCP/IP possui diversos fatores favoráveis para sua utilização no meio industrial. De forma sucinta, podem-se listar os itens a seguir como sendo motivacionais. Interoperabilidade entre equipamentos; Aumento da quantidade de informações trafegadas pela rede; Amplamente utilizado em redes de computadores. O TCP/IP foi constituído com o objetivo de interligar diferentes tecnologias de redes, projetado para ser um padrão de uso exclusivo das forças armadas norte americanas. Após alguns anos, seu uso tornou-se de domínio público e sua aplicação foi adicionada à diversos fabricantes de software, possibilitando sua popularização nas redes de computadores. A estrutura do TCP/IP como conhecemos atualmente, foi motivada com o intuito de proporcionar a comunicação entre computadores de diferentes redes, em longas distâncias para aplicações do departamento de defesa dos Estados Unidos. Com este novo padrão, esperava-se interconectar várias redes ao mesmo tempo, proporcionando serviços de dados, voz e imagem. Atualmente, a normatização da arquitetura TCP/IP está estruturada em documentos conhecidos como Requisitos para Comentários - (RFC, do inglês Request for Comments). O modelo TCP/IP é constituido em quatro camadas de pilhas de protocolos demonstradas na gura 4.4. O detalhamento de cada uma das camadas faz-se necessário e elas serão explanadas nas próximas subseções.

47 28 Capítulo 4. PLC e Redes Industriais 4.3 Figura 4.4: Arquitetura TCP/IP O uso da arquitetura TCP/IP no meio industrial não ocorre naturalmente, pois tradicionalmente esta arquitetura é incorporada às redes corporativas (não determinísticas). Desta forma, foi-se necessário a adaptação da rede para atender os pré-requisitos industriais, ou seja, redes determinísticas. Para que isto fosse possível, a inserção de switchs com particularidades intrínsecas às necessidades industriais foi necessária. O switch utilizado para tais aplicações possui portas individuais e a possibilidade de parametrização do tempo de espera das mensagens. Faz uso de encaminhamento inteligente de mensagens, particionando a rede em domínios de colisão. O determinismo da rede é possível com a arquitetura TCP/IP pois utiliza-se o protocolo de acesso ao meio (CSMA/CD, do inglês Carrier Sense with Multiple Access and Collision Detection) para controlar e acessar o meio de transmissão. Desta maneira, é possível detectar a colisão entre pacotes na transmissão da informação, quando um ou mais dispositivos desejam, ao mesmo tempo, transmitir dados Camada de Rede A camada um, Rede, determina qual o meio físico, bem como o tipo de enlace utilizado na rede TCP/IP para a comunicação entre dispositivos. Nesta camada, os padrões industriais optam pela utilização da Ethernet IEEE como o meio físico de transporte da informação. O acesso ao meio é realizado pelo protocolo CSMA/CD, contudo, o meio físico varia, podendo ser desenvolvido com bras ópticas ou cabos UTP blindado, por exemplo Camada de Inter-rede Esta camada é responsável por transmitir a informação de um ponto a outro através dos pacotes, sendo ou não pertencente a mesma rede. O protocolo mais difundido nesta camada é o Protocolo da Internet (IP, do inglês, Internet Protocol). Não há garantias de entrega

48 TCP/IP para aplicações industriais 29 do pacote, sendo esta a função das camadas acima. Sua contribuição é de prover a melhor maneira de transportar as informações de um ponto a outro. O IP utiliza o endereçamento decimal, por exemplo , para demonstrar os quatro bytes de endereço entre a rede e o host Camada de Transporte Esta camada é composta basicamente por dois protocolos comumente utilizados: TCP que é orientado a conexão e o UDP que por sua vez não utiliza algoritmos orientados à conexão. A função da camada de transporte é de estabelecer a conexão entre as duas ou mais portas que trocarão informações. Nas sub-seções a seguir serão explanadas com maiores detalhes os protocolos UDP e TCP para que se tenha melhor compreensão sobre a arquitetura desenvolvida para o servidor de comunicação deste projeto de pesquisa. É importante enfatizar que ambos os protocolos podem e são utilizados em redes industriais, sendo cada um empregado de acordo com suas distintas nalidades Protocolo UDP O protocolo UDP permite que a aplicação escreva um datagrama 3 e envie ao seu destino pré-determinado. Ele não possui entrega conável dos dados, ou seja, não é previsto que exista um algoritmo que gerencie a troca de pacotes de um ponto a outro. Sua utilização é motivada para troca de informações em tempo real, frequentemente utilizados em sistemas de vídeo e áudio. Durante a conexão, o UDP troca menos pacotes que o TCP, o que torna-o mais rápido Protocolo TCP O TCP é um protocolo que possui a função de controle de congestionamento na rede e teve ramicações signicantes ao longo dos anos sobre sua arquitetura de controle de tráfego. Seu desempenho vai de acordo com o tipo e a quantidade de dados transmitidos. O TCP atua na camada de transporte propiciando entrega conável dos dados a partir das técnicas de uxo, número de sequência, reconhecimentos e temporizadores, o que propõe a entrega correta e ordenada dos dados. As características inerentes do TCP são: conabilidade, entrega ordenada dos dados, controle de uxo, possibilidade de transferência simultânea entre cliente e servidor. Existem diversos modelos de mecanismo de controle de tráfego, ou seja diversos tipos de protocolos TCP, contudo, o mais usual é o modelo TCP Tahoe. Os modelos de protocolo TCP possuem em sua essência três estágios em uma conexão listadas na sub-seções a seguir. 2 Host pode ser denido como um elemento conectado a rede, por exemplo um microcomputador. 3 Datagrama consiste de um pacote contendo cabeçalho e áreas de dados.

49 30 Capítulo 4. PLC e Redes Industriais Abertura da Conexão Para que ocorra a abertura da conexão é necessário que exista num ponto o cliente e um outro ponto o servidor. A sequência da abertura da conexão obedece as seguintes diretrizes: O servidor entra no estado de escuta, estando apto a receber pedidos de conexão. O cliente por sua vez, solicita a abertura da conexão através do envio de um pacote TCP com a ag Synchronise (SYN), esperando que o servidor aceite a conexão e envie um pacote SYN + Acknowledgement (ACK). O cliente ao receber a conrmação do servidor, transmite um novo pacote ACK para conrmação da aceitação Transferência de dados Nesta etapa vários mecanismos são implementados para assegurar a robustez e conabilidade para entrega ordenada dos pacotes. O protocolo TCP é constituído por no mínimo slow-start e congestion avoidance, porém, há uma gama de possibilidades adicionais nas diversas ramicações do TCP, considerando-o como um padrão aberto, ou seja, qualquer programador pode adicionar algoritmos de controle adicionais para melhorar seu código de acordo com sua aplicação. O slow start incrementa o tamanho da janela de congestionamento de um segmento a cada ACK enquanto o tamanho da janela for menor que o limiar. Quando a janela de transmissão alcança o valor limiar ou ocorre a perda de pacotes, inicia-se a fase de prevenção de congestionamento, daí o nome congestion avoidance, que incrementa a janela linearmente de um segmento pelo Tempo de Ida e Volta Round Trip Time - (RTT) até que ocorra um evento de congestionamento. A partir deste momento, a janela é ajustada para 1 segmento e o algoritmo slow-start prossegue com o controle da comunicação Fechamento da Conexão O encerramento da conexão é constituído por um conjunto de fases, sendo que cada lado é responsável pelo seu encerramento. Portanto, quando se almeja fechar a conexão, envia-se um pacote com a ag Finish (FIN) e deve receber um pacote com a ag ACK. Para ambos os lados, cliente e servidor, a diretriz é a mesma. As características de construção mencionadas acima determinam o TCP como não sendo a melhor escolha para controle de processos industriais, pois a criticidade do processo demanda troca de informações em curtos espaços de tempo, o que não acontece no TCP devido aos efeitos de latência na rede. Contudo, para sistemas que envolvam apenas a monitoração das variáveis o protocolo TCP é frequentemente utilizado e torna-se uma ótima alternativa para transmitir informações com conabilidade. O Protocolo UDP, por sua vez é empregado no controle de sistemas de manufatura e no trabalho de [ODV07] é mencionado seu uso. Nele são abordados os conceitos do padrão proprietário EtherNet/IP e o protocolo CIP que utilizam o UDP para envio e recebimento dos pacotes.

50 Integração dos Níveis das Redes Industriais Camada de Aplicação A camada de aplicação é a camada que uma aplicação utiliza para se comunicar através de uma rede com outros programas. Processos que rodam nessa camada são especícos da aplicação. Alguns programas especícos são levados em conta nessa camada. Eles provêem serviços que suportam diretamente aplicações do usuário. Esses programas e seus correspondentes protocolos incluem o HyperText Transfer Protocol (HTTP) utilizado para a comunicação de sítios web, comunicando na linguagem HTML, File Transfer Protocol (FTP) usado na transferência de arquivos, Simple Mail Transfer Protocol (SMTP) usado para envio de s através da internet, Secure Shell (SSH) para login remoto e Domain Name System (DNS) realiza a tradução de um nome de domínio para endereço IP, entre outros. 4.4 Integração dos Níveis das Redes Industriais Redes de comunicação para automação industrial são comumente construídas de forma hierárquica, cujo objetivo é de interligar todos os componentes atuantes tanto direta quanto indiretamente ao ambiente industrial. Permitem a conexão com dispositivos de chão de fábrica, como válvulas e sensores, sistemas de controle utilizando PLCs, sistemas supervisórios até a rede corporativa da empresa. Com a aquisição dos dados de produção torna-se possível realizar o gerenciamento da informação de uma planta industrial [HH07]. [Tor11] e [YLD + 09] citam que o sistema de comunicação entre os dispositivos em uma rede industrial é vital para troca de informações e monitoramento dos equipamentos e da produção. Também é armado que o monitoramento das variáveis de processo traz benefícios nanceiros e permite melhor planejamento de mão-de-obra, de material e de manutenção na planta industrial. O gerenciamento da informação reúne um conjunto de recursos para que a gestão do processo ocorra. Incluem-se: Sistema de Gerenciamento de Banco de Dados; Redes de Comunicação; Controle do Processo; Otimização do Processo; Sistema de Suporte de Decisão. A gestão é caracterizada basicamente pelo controle do processo, gerenciamento do produto na linha de produção/montagem e dados para estratégias de negócios. No entanto, todos estes componentes não são interligados diretamente. Basicamente, os níveis hierárquicos são separados por gateways e servidores. A ISA 95 propõe um modelo geral de projeto das redes industriais que será explicado no próximo tópico.

51 32 Capítulo 4. PLC e Redes Industriais Modelo ISA A norma ISA 95 - (2008) foi desenvolvida com o objetivo de delinear a organização de processos industriais, a qual rege os preceitos da integração dos sistemas de gerenciamento das informações da empresa com os sistemas de instrumentação e controle no chão-de-fábrica. Através dela foi possível uma gestão mais ecaz da cadeia de suprimentos. De acordo com [ISA08], a estrutura hierárquica das redes de comunicação industrial pode ser denida em cinco níveis mostrados na gura 4.5, os quais serão explicados em maiores detalhes nos tópicos a seguir. Figura 4.5: Pirâmide dos níveis hierárquicos de sistemas industriais Nível 0 - Dispositivos de Campo Este nível dene os processos físicos de uma planta de manufatura. Basicamente estruturado por dispositivos industriais, tais como motores, transdutores, válvulas e sensores Nível 1 - Controle O nível 1 é denido pelas atividades de detecção e manipulação dos processos físicos, ou seja, cuida da comunicação dos dispositivos de controle com sistemas de instrumentação e coleta de dados, além de gerir seu controle. A transmissão de dados é dedicada ao ambiente industrial, onde são utilizadas distintas tecnologias de comunicação, tais como analógica, digital e redes Fieldbus [YLD + 09]. Os dispositivos industriais interagem rapidamente com o processo e podem tomar decisões em tempos muito pequenos, na ordem de micro segundos. Este curto tempo de decisão é obtido devido à forma de construção de hardware e software dedicados [LTJ09] Nível 2 - Supervisão Neste nível são executadas as atividades de monitoramento dos processos físicos. Composto pelo servidor de comunicação instalado em um microcomputador, frequentemente instalado em conjunto com interface OPC [SG06] e o sistema SCADA. O sistema SCADA é destinado ao monitoramento e, em alguns casos, ao controle das variáveis de processo. O objetivo de um sistema SCADA é proporcionar ao operador uma

52 Segurança da Informação nas Redes Industriais 33 interface amigável, capaz de fornecer os principais eventos acontecidos na planta industrial. A visualização das variáveis de processo é gráca e pode ser parametrizada manualmente pelo operador, sendo que as decisões de controle vitais a produção são decididas pelos dispositivos inteligentes do nível 1. A transmissão de dados deste nível com os outros pode ser atualizada em horas, minutos e segundos Nível 3 - Planejamento Neste nível ocorre o planejamento da produção através de sistemas de Recurso de Planejamento da Manufatura - (MRP, do inglês Manufacturing Resourcing Planning) com a função de coordenar a produção, dar assistência às atividades produtivas e cuidar da obtenção de recursos para atividades da produção. A atualização deste nível com os demais pode acontecer de horas a dias Nível 4 - Gerenciamento No nível de gerenciamento toda a informação coletada da produção pode ser armazenada em banco de dados, além de ser utilizada para gerar grácos e relatórios por softwares de gerenciamento. Na gura 4.5, pode-se observar que os níveis 2 e 3 enviam as informações dos dados da produção para o software de gestão, localizado no nível 4. O objetivo deste software é integrar todos os dados e processos da instituição em um único sistema, possibilitando o armazenamento e automação de todas as informações geradas pelos departamentos da indústria. Um exemplo do emprego desta integração pode ser visto na linha de produção, onde ela pode ser elevada ou diminuída de acordo com a quantidade de ordens de venda de um determinado produto. Após o detalhamento sobre os níveis de rede em uma planta de manufatura, serão abordados conceitos sobre segurança das informações no ambiente industrial e corporativo, demonstrando suas principais diferenças e objetivos. 4.5 Segurança da Informação nas Redes Industriais De acordo com [SEN10], a segurança da informação pode ser denida como um conjunto adequado de controles, cujo objetivo é proteger as informações contra ameaças diversas. Padronizada pela IEC/ISO 27002, intitulada de Tecnologia da informação - Técnicas de segurança - Código de prática para a gestão de segurança da informação - Information technology - Security techniques - Code of practice for information security management veio em substituição da IEC/ISO 61784, cujo objetivo é estabelecer padrões e procedimentos para a segurança da informação. Uma violação intencional da segurança de uma rede é conhecida como ataque. A possibilidade de interconectar redes industriais às redes IP públicas e corporativas põem em risco

53 34 Capítulo 4. PLC e Redes Industriais 4.5 sua segurança, deixando o sistema suscetível a ataques diversos, tais como: espionagem, sabotagem, vandalismo, vírus de computador entre outras ameaças. Portanto, sempre que o cenário de comunicação ocorrer em redes IP públicas é de vital importância a inserção de segurança de rede. Os ataques podem ser intencionados por pessoas de dentro ou fora de uma planta industrial [Tor11]. O objetivo da segurança de sistemas industriais está na automação de dispositivos, tais como os PLCs, sendo estes de suma importância no controle de processos. Apesar das particularidades das redes industriais, as ameaças de segurança devem ser consideradas e analisadas com a mesma prudência que uma rede corporativa. Segundo o trabalho de [SEN10], alega-se que devido a característica dos sistemas de controle e supervisão, um número considerável de normas, diretrizes e regulamentos tem sido elaborados descrevendo assuntos relacionados a segurança de redes industriais dada sua importância na área, sendo [ISA07] e [ISA04] algumas destas normas. A norma IEC propõe três premissas como objetivo para a segurança da informação, chamada de CIA Condencialidade, Integridade e Disponibilidade - ( do inglês, Condentiality, Integrity and Availability). Em redes corporativas, o foco principal é a condencialidade, logo após vem a integridade da informação em segundo plano e por m a disponibilidade como sendo a de menor prioridade. Todavia, em automação industrial as prioridades para estes objetivos não são similares [ISA04]. O conceito da CIA pode ser visualizado abaixo. Condencialidade: Garantir que as informações sejam acessíveis apenas àqueles autorizados a terem acesso; Integridade: Manter íntegras e exatas as informações e métodos de processamento; Disponibilidade: Garantir que os usuários autorizados tenham acesso às informações e ativos associados quando necessário. Figura 4.6: Comparação de objetivos de segurança das redes corporativas com as industriais. (Adaptada de [ISA07]) A segurança para a automação industrial zela pela manutenção da disponibilidade de todos os componentes do sistema, frequentemente sendo a disponibilidade a de maior importância para o sistema. A prioridade para a integridade dos dados vem em segunda posição

54 Segurança da Informação nas Redes Industriais 35 devido ao risco inerente de máquinas industriais e linhas de processo para o patrimônio da companhia e a integridade física do operador. Em último plano vem a condencialidade, pois os dados trafegados na rede industrial costumam não estar trabalhados e necessitam ser analisados dentro do próprio sistema. A gura 4.6 retrata este cenário de comparação dos objetivos de segurança entre as redes corporativas e públicas (tradicionais de TI) com as industriais. Um sistema computacional está sempre suscetível a ameaças que interferem nos preceitos relatados acima. Estas ameaças comumente estão associadas a ataques aplicados a rede. Pessoas que conheçam as características do sistema poderiam explorar suas vulnerabilidades com o intuito de acometer danos algumas vezes irreversíveis, causando prejuízos à corporação. As técnicas para invasão de sistemas são variadas, das quais pode-se citar cavalos de troia, BackDoor, vírus, entre outras [DNVHC05]. Tendo realizado a explicação geral sobre os assuntos mais relevantes para este projeto de pesquisa, o próximo capitulo detalhará o desenvolvimento do servidor de comunicação proposto.

55

56 Capítulo 5 Servidor de comunicação TCP/IP utilizando Blocos de Função IEC Neste capítulo será apresentado o modelo proposto de servidor TCP utilizando os Blocos de Função IEC voltado à monitoração de dados de processo por sistemas de supervisão e gerenciamento. Dentre os principais temas expostos, estão a arquitetura do servidor de comunicação integrando as normas IEC e IEC , bem como o algoritmo desenvolvido, o mapeamento dos serviços primitivos de comunicação do TCP aplicando os conceitos da IEC para o SIFB, além dos tempos de resposta do servidor TCP. 5.1 Arquitetura Proposta Integração entre as normas IEC e IEC A sequência genérica da aplicação do servidor TCP em um dispositivo industrial é demonstrada na gura 5.1. Pode-se vericar que após o desenvolvimento do SIFB IEC dentro do ambiente do software IEC , é realizado o download do programa no PLC. Ao aplicar o SIFB já testado e certicado no software do PLC é possível minimizar o tempo de desenvolvimento e de teste da lógica do trecho do programa correspondente, aumentando a conabilidade e segurança do software empregado, pois o algoritmo interno do SIFB permanece inalterado. A arquitetura proposta compondo o PLC e as estruturas de programa da IEC e IEC pode ser visualizada na gura 5.2. Utilizaram-se duas tasks dedicadas para o servidor, sendo elas: Task-Cíclica e Task-Evento, as quais seguem as semânticas da IEC Os FB aplicados neste sistema operam em conjunto com as tasks com o objetivo de não interferir no desempenho do PLC. A cada FB foi entregue uma função distinta, sendo: escrita FB-WRT, leitura FB-RD e gerenciamento da conexão TCP SIFB-SVR. Todos os FB estão alocados no mesmo programa do PLC, sendo função das respectivas tasks a determinação das prioridades de rotinas no PLC, bem como seu tempo de execução no 37

57 38 Capítulo 5. Servidor de comunicação TCP/IP utilizando Blocos de Função IEC Figura 5.1: Software IEC e seu download no PLC. programa para cada FB. Para iniciar e nalizar a rotina principal da task direcionada a eventos Task-Evento, o processador do PLC trata a abertura da conexão executando múltiplos threads. Entretanto, como a leitura e a escrita dos dados são realizadas por uma task temporal, o processador do PLC pode ser menos requisitado, colaborando para uma melhora de desempenho no hardware e justicando a necessidade de se manter o socket e os I/Os em diferentes tasks. Embora a interrupção no programa para a requisição de aberturas de conexão seja mais eciente (pois trabalha de forma assíncrona), seu uso deve ser restringido devido à diminuição de desempenho ocasionada pela intervenção direta do processador, conforme é armado em [Sta11]. Desta forma, o watchdog responsável pelo acompanhamento do tempo de execução do programa não seria acionado, pois não haveria falhas e seriam mantidas intactas as funções de controle do PLC. Em [Men02] é citado que a taxa de processamento do servidor pode ser diminuída bem como o tempo de resposta, reduzindo proporcionalmente a taxa do servidor. Com o objetivo de poupar os recursos da CPU do PLC e impedir falhas devido a vários pedidos de conexão simultâneos, xou-se em uma conexão por vez a ser aceita. Portanto, o servidor passa a ter a estrutura iterativa. Figura 5.2: Estrutura macro Servidor TCP em um PLC padrão IEC