pablo valerio pol´ ˆonia - connecting repositories · ned a resource oriented architecture (roa),...

UNIVERSIDADE FEDERAL DE SANTA CATARINAPROGRAMA DE POS-GRADUACAO EM ENGENHARIA DE

AUTOMACAO E SISTEMAS

Pablo Valerio Polonia

PROPOSTA DE ARQUITETURA ORIENTADA A RECURSOS PARASCADA NA WEB

Florianopolis

2011



Dissertacao submetida a Universidade Fe-deral de Santa Catarina para a obtencao doGrau de Mestre em Engenharia de Automacaoe SistemasOrientador: Max Hering de Queiroz, Dr.

Florianopolis

2011

Catalogacao na fonte elaborada pela biblioteca daUniversidade Federal de Santa Catarina

P778p Polonia, Pablo Valerio Proposta de arquitetura orientada a recursospara SCADA na Web [dissertacao] / Pablo Valerio Polonia ; orientador, Max Heringde Queiroz. - Florianopolis, SC, 2011. 145 p.: il., tabs.

Dissertacao (mestrado) - Universidade Federal de Santa Catarina, CentroTecnologico. Programa de Pos-Graduacao em Engenharia de Automacao e Sistemas.

Inclui referencias. 1. Engenharia de sistemas. 2. Sistemas operacionaisdistribuıdos (Computadores). 3. Arquitetura de computador.

4. Servicos da Web. 5. Engenharia de software. I. Queiroz, Max He-ring de. II. Universidade Federal de Santa Catarina. Programa de Pos-Graduacao emEngenharia de Automacao e Sistemas. III. Tıtulo.

CDU 621.3-231.2(021)



Esta Dissertacao foi julgada adequada para a obtencao do Tıtulo deMestre em Engenharia de Automacao e Sistemas, Area de Concentracao emControle Automacao e Sistemas e aprovada em sua forma final pelo Programade Pos-Graduacao em Engenharia de Automacao e Sistemas da UniversidadeFederal de Santa Catarina.

Florianopolis, 31 de Agosto 2011.

Jose Eduardo Ribeiro Cury, Dr.Coordenador do Programa de Pos-Graduacao

em Engenharia de Automacao e Sistemas

Max Hering de Queiroz, Dr.Orientador

Banca Examinadora:

Joni da Silva Fraga, Dr.

Ricardo Jose Rabelo, Dr.

Rosvelter Coelho da Costa, Dr.

Aos meus pais.

AGRADECIMENTOS

Primeiramente gostaria de agradecer aos meus pais, Divair e Emerson,por todo apoio que deram ao longo da minha formacao. Agradeco todo ocarinho e o esforco que fizeram para que eu pudesse ter acesso a uma boaeducacao em um paıs onde infelizmente este ainda e um privilegio de poucos.

Sou muito grato aos meus amigos do Edugraf, em especial ao Prof.Melgarejo pelas orientacoes e aos colegas Diego, Giovani, Lucas e Ricardopor todas as crıticas, sugestoes e tambem pela paciencia que tiveram em as-sistir todas as minhas apresentacoes. Fico feliz em poder aprender com vocestodos os dias.

Agradeco ao Prof. Max pela orientacao do trabalho e por todas ascrıticas realizadas. Tambem gostaria de agradecer a minha companheira Alinepelo amor e compreensao, e a todos os meus amigos que me ajudaram nestaempreitada. Por ultimo, agradeco a colaboracao dos demais professores, co-legas e servidores da UFSC.

A simplicidade e uma grande virtude, mas re-quer trabalho duro para alcanca-la e educacaopara aprecia-la. E para piorar as coisas: acomplexidade vende melhor.

Edsger Wybe Dijkstra

Resumo

Esta dissertacao descreve uma proposta de arquitetura de software para aplica-coes tıpicas de Sistemas de Supervisao e Aquisicao de Dados (SCADA), uti-lizando a World Wide Web como plataforma. O objetivo e mostrar como osrequisitos caracterısticos de aplicacoes SCADA podem ser incorporados emuma arquitetura condizente com os princıpios arquiteturais que fundamentama Web, dado que as arquiteturas comumente propostas para SCADA, basea-das em Chamadas Remota de Procedimento (RPC, na sigla em ingles), apre-sentam problemas de forte acoplamento, manutencao de estado e interfacesespecializadas, que dificultam uma integracao plena com a Web. Para isto eprojetada uma Arquitetura Orientada a Recursos (ROA, na sigla em ingles),que utiliza as tecnologias da Web (HTTP, URI e tipos de mıdia) de acordocom seus princıpios de arquitetura. A arquitetura e projetada utilizando comocenario uma Celula Flexıvel de Manufatura (CFM), ambiente caracterısticode um SCADA. As funcionalidades tıpicas de SCADA sao projetadas comorecursos e expostas para clientes que podem exibir sinoticos em uma IHM, es-perar pelo disparo de alarmes, controlar o processo, configurar dispositivos eabastecer com dados sistemas de MES/ERP. Uma implementacao e realizada,para demonstrar como se da a interacao entre aplicacoes na arquitetura. Nestaimplementacao um aplicativo SCADA (Mango M2M) teve sua arquitetura desoftware estudada e modificada para se adaptar as necessidades da arquiteturaproposta. Como resultado, obtem-se uma arquitetura que cobre os requisitostıpicos de aplicacoes SCADA, integrando-se a Web de forma condizente comseus princıpios arquiteturais. Posteriormente a arquitetura projetada e com-parada com uma arquitetura baseada em Web Services RPC e as diferencasem termos de integracao com a Web e no cumprimento dos requisitos tıpicosde SCADA sao analisadas.Palavras-chave: SCADA. Arquitetura de Software. Web. Servicos Web.REST. ROA.

Abstract

This dissertation describes a proposed software architecture for typical Su-pervisory Control and Data Acquisition (SCADA) systems, using the WorldWide Web as a platform. The goal is to show how the characteristic require-ments of SCADA can be incorporated into an architecture consistent with thearchitectural principles that underlie the Web, since the commonly proposedarchitectures for SCADA, based on Remote Procedure Call (RPC) have pro-blems with strong coupling, maintenance of state and interface specializationthat hinder full integration with the Web. For accomplishng this goal is desig-ned a Resource Oriented Architecture (ROA), which uses Web technologies(HTTP, URI, and media types) according to its architectural principles. Thearchitecture is designed from a characteristic SCADA environment, a Fle-xible Manufacturing Cell (FMC). Typical SCADA features are designed asresources for clients that can display synoptics on HMI, wait for an alarm tofire, control processes, configure devices and supply data for MES/ERP sys-tems. An implementation is carried out to demonstrate how the interactiontakes place between applications in the proposed architecture. In this imple-mentation a SCADA application (Mango M2M) had its software architecturestudied and modified to suit the needs of the architecture. As a result, the pro-posed architecture covers the typical requirements for SCADA applications,integrating the Web in a manner consistent with their architectural principles.Later the designed architecture is compared with an Web Services architec-ture based on RPC and the differences in terms of integration with the Weband in compliance with the requirements of typical SCADA are analyzed.Keywords: SCADA. Software Architecture. Web. Web Services. REST.ROA.

Sumario

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.4 Organizacao do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.1 Contextualizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2 Componentes de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.1 Dispositivos de Campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.2.2 Estacoes Remotas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.2.3 Estacoes Mestre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.2.4 Estacoes de Operacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.3 Tecnologias de Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.3.1 Historico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1.1 Primeira Geracao, Monolıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1.2 Segunda Geracao, Distribuıda . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.3.1.3 Terceira Geracao, Em Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.3.1.4 SCADA na Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4 Requisitos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4.1 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.1.1 Aquisicao de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.1.2 Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.4.1.3 Interface Homem Maquina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4.1.4 Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.4.1.5 Historico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.1.6 Alarmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.4.2 Requisitos Nao Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.2.1 Interoperabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.2.2 Portabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.4.2.3 Escalonabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.4.2.4 Confiabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.4.2.5 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.4.2.6 Tempo-real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.5 Conclusao do Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413 Arquitetura de Software e a Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1 A Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.2 Arquitetura de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2.1 Estilos Arquiteturais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3.1 Os Estilos de REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.1.1 Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.1.2 Sem-Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.3.1.3 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.1.4 Interface Uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.3.1.5 Sistema em Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.1.6 Codigo sob demanda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.3.2 Elementos Arquiteturais de REST . . . . . . . . . . . . . . . . . . . . . . . . 513.3.2.1 Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.3.2.2 Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.3.2.3 Conectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4 Arquitetura Orientada a Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.4.1 Conceitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.1.1 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.1.2 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.4.1.3 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.4.1.4 Aspectos de Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4.1.5 Representacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.4.2 Propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4.2.1 Enderecabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4.2.2 Sem-estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.4.2.3 Conectividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.2.4 Interface Uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593.4.3 Projeto de uma Arquitetura Orientada a Recursos . . . . . . . . . 593.4.3.1 Levantamento do conjunto de dados . . . . . . . . . . . . . . . . . . . . . . 603.4.3.2 Definicao dos Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.3.3 Escolha das URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.4.3.4 Exposicao de um subconjunto da interface uniforme . . . . . . . . . 613.4.3.5 Projeto das representacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.3.6 Integracao com outros recursos . . . . . . . . . . . . . . . . . . . . . . . . . . 613.4.3.7 Definicao das respostas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.5 Conclusao do Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624 Arquiteturas de Software para SCADA na Web . . . . . . . . . . . . . . . 654.1 Arquiteturas Baseadas em RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.2 OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674.3 OPC-UA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 694.4 DPWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

4.5 Arquiteturas Baseadas em RPC e sua Integracao com a Web . . . . . 704.6 Conclusao do Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 735 Proposta de Arquitetura Orientada a Recursos para SCADA na

Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 755.1 Arquitetura Orientada a Recursos para Aplicacoes Tıpicas de SCADA 755.1.1 Visao Geral da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 795.1.2 Projeto dos Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805.1.3 Aspectos de Seguranca e Confiabilidade . . . . . . . . . . . . . . . . . . . 905.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.2.1 Aplicacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 945.2.2 Implementacao no Mango M2M . . . . . . . . . . . . . . . . . . . . . . . . . 965.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1035.4 Conclusao do Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056 Estudo Comparativo de Arquiteturas para uma Aplicacao SCADA

na Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.1 A Aplicacao SCADA dos Tanques . . . . . . . . . . . . . . . . . . . . . . . . . . . 1076.2 Arquitetura de Web Services Baseada em RPC . . . . . . . . . . . . . . . . . 1086.3 Arquitetura Orientada a Recursos para Aplicacoes Tıpicas de SCADA1116.4 Analise Comparativa das Arquiteturas . . . . . . . . . . . . . . . . . . . . . . . . 1196.4.1 Integracao com a Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1206.4.2 Requisitos nao-funcionais de SCADA . . . . . . . . . . . . . . . . . . . . . 1236.5 Conclusao do Capıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1247 Conclusao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Referencias Bibliograficas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Lista de Figuras

Figura 1 Piramide da automacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 2 Hierarquia tıpica dos componentes de hardware em um SCADA 31Figura 3 Arquitetura de comunicacao tıpica de um SCADA da PrimeiraGeracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 4 Arquitetura de comunicacao tıpica de um SCADA da SegundaGeracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Figura 5 Arquitetura de comunicacao tıpica de um SCADA da TerceiraGeracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 6 Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figura 7 Cliente-Servidor-Sem-Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Figura 8 Cliente-Cache-Servidor-Sem-Estado . . . . . . . . . . . . . . . . . . . . . . . 49Figura 9 Cliente-Cache-Servidor-Sem-Estado-Uniformes . . . . . . . . . . . . 49Figura 10 Cliente-Cache-Servidor-Sem-Estado-Uniformes-Em-Camadas 50Figura 11 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Figura 12 Complexidade antes do surgimento do OPC . . . . . . . . . . . . . . . . 67Figura 13 Arquitetura baseada em OPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Figura 14 Celula de manufatura flexıvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Figura 15 Foto da CFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Figura 16 Organizacao dos componentes de hardware do SCADA naCFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Figura 17 CLP Altus PO 3147 usado na CFM . . . . . . . . . . . . . . . . . . . . . . . . 78Figura 18 Arquitetura ROA para aplicacoes tıpicas SCADA . . . . . . . . . . . 80Figura 19 Representacao da colecao de coletores . . . . . . . . . . . . . . . . . . . . . 83Figura 20 Representacao do coletor Modbus RTU . . . . . . . . . . . . . . . . . . . . 83Figura 21 Representacao XML alternativa do coletor Modbus RTU . . . . 83Figura 22 Representacao da colecao de variaveis . . . . . . . . . . . . . . . . . . . . . 85Figura 23 Representacao de uma variavel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Figura 24 Representacao da ultima leitura de uma variavel . . . . . . . . . . . . 87Figura 25 Representacao do historico de uma variavel . . . . . . . . . . . . . . . . 87Figura 26 Representacao de um alarme enviado pelo cliente . . . . . . . . . . . 88Figura 27 Representacao da colecao de alarmes . . . . . . . . . . . . . . . . . . . . . . 88Figura 28 Representacao de um alarme recebido do servidor . . . . . . . . . . 89

Figura 29 Representacao do disparo de um alarme . . . . . . . . . . . . . . . . . . . . 89Figura 30 Representacao do disparo de um alarme (quando ocorreramoutros disparos) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Figura 31 Representacao do historico de disparos de um alarme . . . . . . . 92Figura 32 Hierarquia de papeis para aplicacoes tıpicas SCADA . . . . . . . . 93Figura 33 Configuracao dos recursos para a CFM . . . . . . . . . . . . . . . . . . . . 95Figura 34 Sinotico da CFM desenvolvido em Telis . . . . . . . . . . . . . . . . . . . 97Figura 35 Padrao MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Figura 36 MVC no arcabouco Spring utilizado pelo Mango M2M. . . . . . 100Figura 37 Arquitetura de Software do Mango M2M . . . . . . . . . . . . . . . . . . 102Figura 38 Arquitetura de software do Mango M2M modificada . . . . . . . . 102Figura 39 Caso de uso envolvendo os operadores das plantas . . . . . . . . . . 108Figura 40 Interacao entre plantas e central . . . . . . . . . . . . . . . . . . . . . . . . . . . 109Figura 41 Arquitetura em nıvel de rede para o problema dos tanques . . . 110Figura 42 Diagrama de componentes da arquitetura . . . . . . . . . . . . . . . . . . . 111Figura 43 Diagrama de classes do sistema dos tanques . . . . . . . . . . . . . . . . 112Figura 44 Arquitetura ROA para a aplicacao dos tanques . . . . . . . . . . . . . . 113Figura 45 Sequencia de operacoes nos recursos para configuracao doprocesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114Figura 46 Criacao de pedido de transferencia solicitada pelo cliente MES115Figura 47 Representacao do pedido de transferencia atual . . . . . . . . . . . . . 116Figura 48 Sequencia de operacoes nos recursos para monitoramento deuma transferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117Figura 49 Sequencia de operacoes nos recursos para realizar uma trans-ferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Figura 50 Sequencia de operacoes nos recursos para parar uma trans-ferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119Figura 51 Sequencia de operacoes nos recursos para finalizar uma trans-ferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Lista de Tabelas

Tabela 1 Recursos de coleta de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Tabela 2 Interface dos recursos de coleta de dados . . . . . . . . . . . . . . . . . . . 82Tabela 3 Recursos de variaveis do processo . . . . . . . . . . . . . . . . . . . . . . . . . 84Tabela 4 Interface dos recursos de variaveis do processo . . . . . . . . . . . . . 85Tabela 5 Recursos de dados coletados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Tabela 6 Resumo do recursos projetados . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Tabela 7 Interface dos recursos de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . 93Tabela 8 Operacoes autorizadas sobre os recursos . . . . . . . . . . . . . . . . . . . 94Tabela 9 Recursos da planta de envio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Tabela 10 Recursos da planta de recebimento . . . . . . . . . . . . . . . . . . . . . . . . 114Tabela 11 Recurso de pedido do transferencia atual . . . . . . . . . . . . . . . . . . . 116Tabela 12 Comparacao entre as arquiteturas com relacao a integracaocom a Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Tabela 13 Comparacao entre as arquiteturas e requisitos nao-funcionaisde SCADA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

23

1 Introducao

1.1 Justificativa

Sistemas de Supervisao e Aquisicao de Dados (SCADA) sao sistemascomputacionais utilizados na coleta de informacoes, monitoramento e con-trole (BAILEY; WRIGHT, 2003). Esses sistemas possibilitam que operado-res supervisionem processos que muitas vezes estao localizados em regioeslongınquas ou de difıcil acesso, centralizando as informacoes coletadas eminterfaces que refletem o que esta acontecendo em campo. Sao amplamenteutilizados na industria e em servicos de utilidade publica, em areas como ma-nufatura, metalurgia, energia, agua e esgoto, gas e petroquımica (DANEELS;SALTER, 1999) (MORAES, 2005).

A expansao da Internet e a evolucao dos sistemas gerenciais e de pla-nejamento, como os Sistemas de Execucao da Manufatura (MES, na siglaem ingles) e os Sistemas Integrados de Gestao Empresarial (ERP, na siglaem ingles) tem trazido novas oportunidades para as industrias. Esse cenariotem motivado uma integracao entre os sistemas utilizados nos varios nıveis deuma dada organizacao, na qual as informacoes operacionais colhidas por umSCADA tem um peso importante na tomada de decisoes estrategicas (FA-VARETTO, 2001) (HOWELLS, 2000). A abertura dos mercados, atuacaode agencias reguladoras e a desregulamentacao de setores, tais como o daenergia eletrica, tem propiciado um interacao entre organizacoes. Esses fa-tores trazem novos desafios, pois a troca de informacoes passou a se dar emum nıvel que extrapola barreiras geograficas e organizacionais (QIU; GOOI,2000)(KHATIB et al., 2000).

Em paralelo, a World Wide Web, um sistema distribuıdo de alcancemundial, tem revolucionado a forma como pessoas, organizacoes e siste-mas geram, acessam, e compartilham informacoes (BERNERS-LEE, 2000).Esta rede tem se expandido rapidamente desde seu surgimento, agregandoinformacoes de sistemas heterogeneos sem a necessidade de qualquer tipo decontrole centralizado e com o cumprimento de requisitos de confiabilidadee seguranca (FIELDING; TAYLOR, 2002). Uma melhor compreensao dosconceitos que nortearam a Web tem fomentado o interesse da industria e daacademia nos ultimos anos, levando profissionais e pesquisadores a explora-rem as potencialidades da Web como uma plataforma para o desenvolvimentode aplicacoes distribuıdas (RICHARDSON; RUBY, 2007).

Observa-se que os sistemas SCADA tem feito uma transicao na dire-cao de possibilitar o seu uso como aplicativos Web (FAN; CHEDED; TO-

24

KER, 2005) (LI; SERIZAWA; KIUCHI, 2002) (QIU; GOOI, 2000) (KHA-TIB et al., 2000). Atualmente existem sistemas SCADA atraves dos quaisoperadores podem configurar sensores, enviar acoes de controle, gerenciaralarmes, visualizar sinoticos, etc. usando tao somente navegadores tıpicos daWeb(SEROTONIN, 2011). No entanto ainda e muito difıcil encontrar siste-mas SCADA que participem de forma plena da Web, nao tendo sido projeta-dos de acordo com seus princıpios de arquitetura de software. Um SCADAconstruıdo com base nestes princıpios poderia aproveitar-se da interopera-bilidade garantida pelas tecnologias abertas e padronizadas que sustentam aWeb, favorecendo a interacao com outras aplicacoes. Alem disso poderiase beneficiar de agentes intermediarios favorecendo aspectos relacionados aseguranca, escalonabilidade e performance (FIELDING, 2000).

Pode-se citar alguns trabalhos relacionados na literatura. As neces-sidades de dispor dados coletados por um SCADA para diferentes setoresde uma mesma organizacao sao exploradas em (ZECEVIC, 1998). Comosolucao os autores propoem a conexao das redes de comunicacao de SCADAcom a rede interna (Intranet) da organizacao, combinada ao uso de navegado-res Web como interface padrao para o acesso dessas informacoes. Tambemsao apontados os benefıcios do uso de tecnologias abertas e padronizadas nareducao dos custos e da dependencia de fabricantes de equipamentos.

Em (MEDIDA; SREEKUMAR; PRASAD, 1998), (QIU; GOOI, 2000)e (KHATIB et al., 2000) sao exploradas a vantagens de expor um SCADAna Internet, no sentido de disponibilizar acesso remoto e global das informa-coes coletadas pelos dispositivos de campo, que posteriormente podem serapresentadas atraves de navegadores na Web.

Uma analise do uso combinado das tecnologias Java e XML (Exten-sible Markup Language, na sigla em ingles) para favorecer requisitos de por-tabilidade, performance e interoperabilidade de sistemas SCADA na Web efeita em (FAN; CHEDED; TOKER, 2005). O trabalho traz aspectos conceitu-ais importantes, categorizando as aplicacoes de automacao industrial na Webcomo “habilitadas para Web” e as “integradas a Web”. O termo “habilitadas”para Web” se refere as aplicacoes que possuem uma interface grafica quepode ser acessada por um navegador, como as citadas nos trabalhos descri-tos anteriormente. Ja o termo “integradas a Web” e utilizado para aplicacoesdistribuıdas, compostas por diferentes subsistemas integrados por meio detecnologias Web. Outra contribuicao importante e o projeto de uma arquite-tura de software para uma aplicacao SCADA dita integrada a Web, baseadaem Web Services RPC.

25

1.2 Objetivos

Este trabalho tem como objetivo propor a integracao de aplicacoestıpicas de SCADA com a Web atraves de uma Arquitetura Orientada a Re-cursos (ROA, na sigla em ingles), buscando mostrar como requisitos carac-terısticos destes sistemas podem ser incorporadas por esta arquitetura.

Com base neste objetivo geral, pode-se citar os seguintes objetivosespecıficos:

• Analisar as arquiteturas de software comumente propostas para SCADA;

• Realizar uma implementacao da arquitetura atraves da modificacao deum aplicativo para SCADA;

• Desenvolver aplicacoes que se integrem com a arquitetura projetada,mostrando algumas de suas propriedades;

• Comparar a arquitetura projetada com uma arquitetura existente e re-presentativa das arquiteturas de software comumente propostas paraSCADA;

1.3 Metodologia

A metodologia utilizada durante a pesquisa compreendeu os seguintespassos:

• Revisao bibliografica acerca de SCADA, focando nos requisitos desoftware tıpicos destas aplicacoes;

• Revisao bibliografica sobre os princıpios de arquitetura de software quefundamentam a Web e arquiteturas condizentes com estes princıpios;

• Analise das arquiteturas de software comumente propostas para SCADAe as dificuldades que apresentam para realizar uma integracao com aWeb;

• Projeto e implementacao de uma arquitetura para aplicacoes tıpicas deSCADA condizente com os princıpios arquiteturais da Web;

• Comparacao da arquitetura projetada com uma existente buscando mos-trar as diferencas no cumprimento dos requisitos tıpicos de SCADA eem sua integracao com a Web;

• Avaliacao dos resultados;

26

1.4 Organizacao do Documento

Este documento esta organizado da seguinte forma: no Capıtulo 2e apresentada uma visao geral de SCADA, abrangendo seus conceitos, tec-nologias e requisitos tıpicos de software, levando em conta alguns aspectoshistoricos que demonstram a evolucao pela qual esta area tem passado.

No Capıtulo 3 sao apresentados conceitos da area de arquitetura desoftware, em sequencia e feita uma introducao sobre a Web e seus princıpiosde arquitetura, incorporados no estilo arquitetural REST. O capıtulo e con-cluıdo com a descricao de uma metodologia para o projeto de ArquiteturasOrientadas a Recursos, que incorporam as tecnologias da Web de forma con-dizente com seus prıncipios arquiteturais.

O Capıtulo 4 expoe uma analise sobre arquiteturas de software ba-seadas em RPC, onde sao explorados os pontos em que estas arquiteturas,predominantes em SCADA, divergem dos princıpios de arquitetura da Webdificultando sua integracao com a mesma.

No Capıtulo 5 e apresentado um estudo de caso envolvendo um am-biente tıpico de SCADA, uma CFM. Com base nessa CFM e projetada umaROA que abrange os requisitos tıpicos de uma aplicacao SCADA. Em seguidasao apresentadas algumas aplicacoes, descrita a implementacao e analisadosos resultados.

Em seguida no Capıtulo 6 e realizado um estudo comparativo entre aarquitetura projetada e uma arquitetura baseada em Web Services RPC. Asduas arquiteturas sao utilizadas para modelar uma aplicacao SCADA na Webe as diferencas em termos de integracao com a Web e no cumprimento dosrequisitos tıpicos de SCADA sao analisadas. Finalmente, apresentam-se asconclusoes da pesquisa no Capıtulo 7, bem como sugestoes para trabalhosfuturos.

27

2 SCADA

2.1 Contextualizacao

Aplicativos SCADA sao utilizados na supervisao e controle de proces-sos (BAILEY; WRIGHT, 2003). Sao amplamente empregados na industriae em servicos de utilidade publica, em areas como manufatura, metalurgia,energia, agua e esgoto, gas e petroquımica (DANEELS; SALTER, 1999) (MO-RAES, 2005). Podem variar em tamanho e complexidade, podendo ser utili-zados no monitoramento de processos que vao desde as condicoes ambientaisde uma sala, ou de todos os equipamentos de uma central de distribuicao deenergia eletrica (National Communications Systems, 2004).

Esses sistemas utilizam-se de telemetria, realizando a coleta de da-dos dos dispositivos de campo, muitas vezes geograficamente dispersos eas enviando para centrais de controle, onde sao processadas e armazenadas.Nestas centrais os operadores podem acompanhar o processo, visualizandoinformacoes por meio de sinoticos, tabelas e graficos que refletem o que estaacontecendo em campo. Por meio desta interface os operadores tambem po-dem eventualmente realizar alguma acao de controle, como a abertura de umavalvula ou a configuracao de um dispositivo de campo (BAILEY; WRIGHT,2003).

No contexto de outras aplicacoes de automacao industrial os siste-mas SCADA possuem um papel importante, que e o de fornecer os dadosde chao de fabrica para outras aplicacoes, alem de receberem comandos decontrole das mesmas. Neste sentido, um SCADA tem um papel operaci-onal, enquanto que aplicacoes como MES ou ERP tem um escopo mais es-trategico. Aplicacoes MES/EPS tem como finalidade o planejamento e o con-trole da producao, permitindo a gerencia de lotes de producao, alocacao derecursos, controle de qualidade, sequenciamento de operacoes, e permitindoa contabilizacao e o rastreamento de equipamentos e materia prima (FAVA-RETTO, 2001). Os Sistemas ERP envolvem decisoes estrategicas em umnıvel mais alto, pois integram todos os setores de organizacao, sejam eles ope-racionais, produtivos, administrativos ou comerciais (MARDEGAN; AZE-VEDO; OLIVEIRA, 2002). Essa divisao hierarquica de tarefas entre os siste-mas utilizados em uma organizacao e muito bem capturada pela piramide daautomacao, que pode ser vista na figura 1, adaptada de (HARJUNKOSKI;NYSTROM; HORCH, 2009). No nıvel mais baixo estao os sistemas que erelacionam com equipamentos de campo, como os sistemas de controle dis-tribuıdo e SCADA, enquanto que nos nıveis mais altos estao as aplicacoes

28

MES e ERP.Para cumprir com suas funcionalidades um sistema SCADA precisa

de um arranjo muitas vezes complexo de hardware, software e tecnologias decomunicacao (National Communications Systems, 2004), descrito a seguir.

Figura 1: Piramide da automacao

2.2 Componentes de Hardware

Na literatura sao utilizados alguns termos recorrentes para designaros componentes de hardware que fazem parte desses sistemas, de acordocom o papel que eles desempenham no fluxo das informacoes coletadas doprocesso. Esses componentes podem ser categorizados em dispositivos decampo, estacoes remotas, estacoes mestre e estacoes de operacao (KRUTZ,2005).

2.2.1 Dispositivos de Campo

Os dispositivos de campo podem ser divididos em sensores e atuado-res. Os sensores medem grandezas fısicas associadas ao processo, como atemperatura de uma caldeira, a pressao da agua em uma represa ou a tensaoem uma linha de transmissao de energia. Existe uma vasta gama de dispositi-vos com esse proposito que abarcam sensores de pressao, calor, proximidade,movimento, entre outros (National Communications Systems, 2004). Ja os

29

atuadores sao responsaveis pelo controle do processo, por exemplo atravesda abertura ou fechamento de valvulas, acionamento de motores ou fecha-mento de um contato eletrico. O tipo de sinal que os dispositivos de campotrabalham pode variar de sinais analogicos (contınuos) para sinais digitais(discretos).

Pode se notar uma certa tendencia da industria em tornar esses ins-trumentos de campo mais inteligentes, dotando-os de microprocessadoresque permitem o tratamento das informacoes, auto-calibragem e mesmo ainteracao com outros dispositivos atraves de protocolos de comunicacao (POPA;POPA; PATITOIU, 2007).

2.2.2 Estacoes Remotas

Estacoes remotas, ou Remote Terminal Units (RTU, na sigla em ingles)sao dispositivos eletronicos programaveis cujo objetivo e realizar a comu-nicacao entre dispositivos de campo e estacoes mestre, coletando dados dossensores e repassando acoes de controle para os atuadores (WARD et al.,2004). O nome estacao remota esta relacionado ao fato de que geralmenteesses dispositivos estao em lugares remotos, distantes da central de controleonde se encontram os operadores (BAILEY; WRIGHT, 2003). RTUs sao do-tadas de microprocessadores e memoria, podendo ser programados para exe-cutar localmente algoritmos de controle (um laco de controle realimentadopor exemplo).

Muitas vezes Controladores Logico Programaveis (CLPs) sao utili-zados com o mesmo proposito dos RTU. CLPs sao utilizados para contro-lar diversos tipos de maquinas e processos, tendo sua programacao derivadada logica dos diagramas eletricos a reles, executando atraves de uma rotinacıclica de operacoes (SOUZA, 2005). De fato existe alguma confusao sobrea distincao entre CLPs e RTUs. Os primeiros surgiram em um contexto fabrilda automacao, possuindo capacidade de programacao e um menor necessi-dade de alcance na comunicacao, devido as distancias menores encontradasentre os dispositivos no chao de fabrica. Os RTUs sao oriundos dos primeirossistemas de telemetria, portanto a comunicacao a longas distancias era umrequisito crucial que superava a necessidade de esses dispositivos serem pro-gramaveis. Contudo, pode se observar que ambos foram evoluindo, suprindosuas deficiencias, fato que torna esta distincao hoje um tanto nebulosa (Nati-onal Communications Systems, 2004). Portanto daqui em diante quando forutilizado o termo estacao remota, este tambem estara abrangendo os CLPs.

A interface das estacoes remotas com os dispositivos de campo ge-ralmente e fısica, para tanto esses equipamentos sao dotados de modulos de

30

entrada e saıda analogicos e digitais. Ja a interacao com as estacoes mes-tre se da atraves de pilhas de protocolos de comunicacao comuns nos meiosindustrias, que serao detalhadas posteriormente.

2.2.3 Estacoes Mestre

As estacoes mestre sao computadores pessoais ou industriais, estesultimos possuindo maior robustez para resistir as condicoes adversas encon-tradas no chao de fabrica. Suas responsabilidades sao obter, processar e arma-zenar os dados oriundos das estacoes remotas assim como repassar comandosde controle para elas, o que geralmente e feito atraves de protocolos industri-ais. Por possuırem um maior poder computacional as estacoes mestre acabamtambem por concentrar grande parte das funcionalidades de software de umSCADA (National Communications Systems, 2004). Um SCADA pode terapenas uma estacao mestre ou entao varias, em uma arquitetura distribuıda demaquinas conectadas em rede (WARD et al., 2004).

2.2.4 Estacoes de Operacao

As interfaces homem-maquina (IHM), ou estacoes de operacao saocomputadores pessoais ou industriais que tornam possıvel a interacao de ope-radores humanos com os processos subjacentes. A estacao de operacao exe-cuta o software que apresenta uma interface grafica pela qual o operadorpode supervisionar e atuar sobre o processo. Em alguns casos a estacao deoperacao e estacao mestre sao a mesma maquina, contudo e comum que taisfuncionalidades estejam separadas em maquinas distintas (FAN; CHEDED;TOKER, 2004).

Como pode ser visto na descricao dos componentes de hardware deum SCADA, o fluxo das informacoes coletadas do processo segue um ca-minho hierarquico, fluindo dos sensores no nıvel mais baixo e proximo doprocesso supervisionadopara para as estacoes remota, mestre e de operacaorespectivamente. O sentido do fluxo e invertido quando se trata de algumaacao de controle efetuada pelo operador, a figura 2 ilustra esta organizacaohierarquica dos componentes de um SCADA.

31

Figura 2: Hierarquia tıpica dos componentes de hardware em um SCADA

2.3 Tecnologias de Comunicacao

As tecnologias de comunicacao sao as responsaveis pela troca de in-formacoes entre os componentes de um sistema SCADA. Essas tecnologiassempre tiveram uma atribuicao importante, principalmente devido a naturezadistribuıda de um SCADA, com seus dispositivos dispersos em campo (Na-tional Communications Systems, 2004). Para a comunicacao das estacoesremotas e mestre tipicamente sao utilizados protocolos de redes industriaiscomo o Modbus, DNP3, Fieldbus e Profibus ou entao algum protocolo pro-prietario. Estes protocolos sao empregados devido a necessidades intrınsecasdas aplicacoes do meio industrial, tais como controle de tempo real. Em umnıvel mais alto, as estacoes mestre e de operacoes se conectam atraves deredes locais, utilizando Ethernet ou Token Ring. O meio utilizado para estacomunicacao e algo que varia com o ambiente monitorado. Cabeamento emuito utilizado em fabricas onde as distancias entre os equipamentos e ge-ralmente pequena, entretanto quando existem pontos supervisionados que co-brem uma grande area a comunicacao via radio, telefonia ou mesmo satelite epreferida. Nos casos de comunicacao via radio frequencia, e muito comum asestacoes remotas se comunicarem entre si, atuando como repetidoras de sinal(KHATHAIR, 2006).

32

2.3.1 Historico

Os sistemas SCADA tiveram sua historia influenciada pelos avancosda tecnologia da informacao, principalmente no que diz respeito as tecnolo-gias de comunicacao. Nos ultimos anos estas mudancas tem sido aceleradasem virtude da penetracao das tecnologias de informacao neste domınio (FAN;CHEDED; TOKER, 2004). Conforme (National Communications Systems,2004), pode-se dividir a evolucao de SCADA com relacao a suas tecnologiasde comunicacao em tres geracoes, que sao descritas a seguir.

2.3.1.1 Primeira Geracao, Monolıtica

Os primeiros SCADA surgiram na decada de 60, quando a cena dacomputacao era dominada pelos Mainframes (FAN; CHEDED; TOKER, 2004).As redes de computadores praticamente nao existiam, portanto esses sis-temas eram centralizados em grandes maquinas com limitada capacidadede processamento e praticamente nenhuma conectividade. A excecao era acomunicacao fısica com os dispositivos de campo, e posteriormente com asestacoes remotas criadas com a evolucao do hardware. Os protocolos utili-zados eram proprietarios e extremamente simples, tendo como objetivo exclu-sivo a coleta de informacoes em campo, muitas vezes envolvendo comunicacaoa longas distancias via radio. A figura 3 adaptada de (National Communi-cations Systems, 2004) ilustra uma arquitetura de comunicacao tipıca de umSCADA da primeira geracao.

2.3.1.2 Segunda Geracao, Distribuıda

A proxima geracao foi influenciada pelos avancos da miniaturizacaoe das redes locais de computadores. Desta forma a arquitetura que antes eracentralizada passou a ser distribuıda, possibilitando a existencia de estacoesmestre e de operacao conectadas em rede. Diversas vantagens foram trazidasdevido a esse avanco, permitindo maior confiabilidade devido a possibilidadede redundancia e uma maior escalonabilidade devido a capacidade de distri-buir funcionalidades e carga em maquinas distintas (ZECEVIC, 1998).

Contudo os protocolos de comunicacao continuaram majoritariamenteproprietarios, isto acontecia porque a maioria dos fabricantes fornecia um pa-cote de solucoes que englobava componentes de hardware, software e co-municacoes, pouco interessando para esses a interoperabilidade com outrosfabricantes. A figura 4 adaptada de (National Communications Systems,

33

Figura 3: Arquitetura de comunicacao tıpica de um SCADA da PrimeiraGeracao

2004) mostra uma arquitetura de comunicacao tıpica de um SCADA da se-gunda geracao, exibindo a comunicacao entre estacoes mestre e de operacaoem rede local e entre estacoes remotas e estacao mestre via rede de longadistancia.

Figura 4: Arquitetura de comunicacao tıpica de um SCADA da SegundaGeracao

34

2.3.1.3 Terceira Geracao, Em Rede

A grande diferenca da geracao atual para a anterior e que esses siste-mas estao se tornando mais abertos. Os protocolos proprietarios estao sendogradualmente substituıdos por protocolos abertos e padronizados, favorecendoa interoperabilidade entre equipamentos de fabricantes distintos (MEDIDA;SREEKUMAR; PRASAD, 1998). Tal fato tem criado uma separacao maiorentre os nichos de mercado, permitindo que as empresas que desenvolvem osoftware por exemplo possam se focar somente neste aspecto, sem se preo-cupar com questoes de hardware ou sistema operacional (National Commu-nications Systems, 2004).

Outro aspecto desta abertura esta na transicao das redes locais pararedes de longa distancia na comunicacao entre as estacoes mestre, moti-vada pela necessidade de integracao entre sistemas geograficamente disper-sos (MEDIDA; SREEKUMAR; PRASAD, 1998) (QIU; GOOI, 2000) (KHA-TIB et al., 2000). Neste ambito a pilha TCP/IP da Internet tem sido primordialpara realizar esta integracao. Tais mudancas tambem tem penetrado gradual-mente nas estacoes remotas na medida em que as plataformas de hardwaree software utilizadas por elas tem evoluıdo, possibilitando o uso dos proto-colos da Internet nestes dispositivos (LI; SERIZAWA; KIUCHI, 2002). Nafigura 5 adaptada de (National Communications Systems, 2004) e ilustradauma arquitetura de comunicacao tıpica de um SCADA em rede, cujo pontode convergencia de interacao entre os equipamentos e a Internet.

2.3.1.4 SCADA na Web

Pode-se observar que os sistemas SCADA em rede tem feito umatransicao na direcao de possibilitar o seu uso como aplicativos na Web (FAN;CHEDED; TOKER, 2005) (LI; SERIZAWA; KIUCHI, 2002) (QIU; GOOI,2000) (KHATIB et al., 2000). Esta transicao tem sido motivada pela me-lhora de interoperabilidade que as tecnologias abertas e padronizadas da Webtrazem para a area (FAN; CHEDED; TOKER, 2005).

Uma das vantagens de utilizar tecnologias da Web em SCADA esta napadronizacao das interfaces graficas atraves de navegadores, substituindo tec-nologias proprietarias e dependentes de plataforma. Neste aspecto um avancorecente e a possibilidade de os navegadores serem atualizados atraves desolicitacoes assıncronas de informacao, sem que seja necessaria uma interacaodo usuario para isto (CHAU; KHAI, 2007). Combinando atualizacoes assıncro-nas, graficos vetoriais (FENG-PING; CHUN-HUA; JIAN, 2008) e codigomovel em Java (FAN; CHEDED; TOKER, 2004) e Java Script (WALLACE,

35

Figura 5: Arquitetura de comunicacao tıpica de um SCADA da TerceiraGeracao

2004) e possıvel o desenvolvimento de interfaces graficas dinamicas o sufici-ente para acompanhar processos tıpicos da industria.

Inicialmente o uso das tecnologias da Web em SCADA se limitava aapresentacao de interfaces graficas, estando estas aplicacoes apenas habilita-das para Web. Contudo, com o surgimento da linguagem de marcacao XMLe do conceito de servicos na Web novas oportunidades se apresentam, no sen-tido de realizar uma integracao entre aplicacoes atraves destas tecnologias,possibilitando o surgimento de sistemas SCADA nao so habilitados para aWeb, mas tambem integrados a ela (FAN; CHEDED; TOKER, 2005).

2.4 Requisitos de Software

Existe uma diversidade de aplicativos SCADA no mercado, cada umdeles possui particularidades em relacao as funcionalidades que oferece. Con-tudo, apesar destas especificidades, e possıvel obter um conjunto em comumde requisitos e funcionalidades para esse tipo de sistema (CASIMIRO, 1995).

Na engenharia de software os requisitos de um sistema podem ser di-vididos em funcionais e nao funcionais (GHEZZI; JAZAYERI; MANDRI-OLI, 2002). Os requisitos funcionais ditam o que o sistema deve fazer, ouseja quais funcionalidades deve prover. Enquanto isto, os requisitos nao fun-

36

cionais dizem respeito a propriedades de qualidade do sistema, tais comoseguranca e performance (BASS; CLEMENTS; KAZMAN, 2003). Esta di-visao sera adotada para descrever o escopo de cada requisito de SCADA.Primeiramente serao abordados os requisitos funcionais e em seguida os naofuncionais.

2.4.1 Requisitos Funcionais

2.4.1.1 Aquisicao de dados

A aquisicao de dados e o procedimento de coleta de informacoes so-bre o processo. Estas informacoes geralmente estao associadas a grandezasfısicas, como a temperatura capturada por um sensor ou a tensao eletrica emuma linha de transmissao. Outro tipo de informacao capturada e o estado deequipamentos de campo, por exemplo se uma valvula esta aberta ou fechadaou se um instrumento esta com defeito (GOMES, 2003).

O procedimento de aquisicao se da entre as estacoes mestre e as esta-coes remotas, que capturam dados atraves dos sensores. A forma como acon-tece a comunicacao entre esses componentes depende dos protocolos utiliza-dos, sendo tipicamente empregados protocolos industriais que possuem umadinamica mestre/escravo, onde as estacoes mestre solicitam dados periodi-camente das estacoes remotas. Sistemas SCADA encontrados no mercadogeralmente oferecem um conjunto abrangente de protocolos de comunicacaotais como Modbus, DNP3 e BACnet. Assim que sao capturadas estas in-formacoes sao mapeadas para entidades do sistema que representam as leitu-ras, agregando atributos como estampilhas de tempo.

A aquisicao de dados e uma funcionalidade essencial para qualquersistema SCADA, pois todas as outras funcionalidades dependem dos dadoscoletados dos dispositivos. Portanto e importante que os dados sejam cole-tados em uma frequencia que satisfaca as necessidades de monitoramento doprocesso. Outro requisito e a confiabilidade do canal de comunicacao entreas estacoes mestre e remotas, dado o emprego destes sistemas em aplicacoesde missao crıtica (GOMES, 2003).

2.4.1.2 Controle

As acoes de controle permitem que o operador possa atuar sobre oprocesso. Esse controle e efetuado atraves do envio de comandos das estacoesmestre para as estacoes remotas, que ao receberem os comandos acionam seus

37

atuadores. Em sua natureza o controle de SCADA difere dos algoritmos decontrole que executam nas estacoes remotas, sendo um controle em nıvel desupervisao (SOUZA, 2005). Acoes tıpicas que podem ser efetuadas pelosoperadores sao o estabelecimento de setpoints para os algoritmos de controlede nıvel mais baixo e a atuacao sobre o estado de equipamentos (o fechamentode uma valvula por exemplo).

2.4.1.3 Interface Homem Maquina

As interfaces homem-maquina, ou estacoes de operacao tornam possı-vel a interacao de operadores humanos com os processos subjacentes (BAI-LEY; WRIGHT, 2003). Uma representacao grafica “rica” do processo etradicionalmente uma preocupacao nos sistemas SCADA, que devem repre-senta-lo de uma forma intuitiva. A esta representacao grafica e dado o nomede sinotico, provendo ao operador uma visao geral dos processos atraves deanimacoes.

Alem de espelhar o comportamento de um processo estas interfacestambem permitem que um operador interaja atraves do envio de comandosde controle (GOMES, 2003). Uma facilidade oferecida neste contexto e ogerenciamento de ”receitas”, que permitem ao operador definir um conjuntode valores para determinadas variaveis. Receitas sao uteis pois permitema reutilizacao de configuracoes para um processo especifico, por exemploum operador pode definir uma receita para uma mistura quımica, definindovalores para variaveis de temperatura, pressao e os componentes utilizados.

Dada a diversidade de processos que um SCADA pode monitorar amaioria das interfaces permitem a edicao de sinoticos, possibilitando a perso-nalizacao das animacoes, imagens, sons, etc. Tambem fazem parte da inter-face grafica areas onde e possıvel visualizar e configurar os alarmes, geren-ciar dispositivos, visualizar relatorios que permitem a apresentacao de dadosem tabelas, graficos de diversas modalidades e ferramentas estatısticas comoacompanhamento da tendencia das variaveis monitoradas. (CASIMIRO, 1995).

2.4.1.4 Configuracao

Um SCADA e composto de diversos componentes, que devem ser or-ganizados e configurados de forma a cumprir com as necessidades da aplicacaoespecifica onde serao utilizados. Esse arranjo inclui componentes de soft-ware, dispositivos de hardware e infraestrutura de comunicacao.

Desta forma uma das funcionalidades destes sistemas e possibilitar a

38

configuracao do software para o processo que sera supervisionado. Entramnesta categoria o gerenciamento dos dispositivos que servirao como estacoesremotas, definicao das variaveis que serao monitoradas, taxas de aquisicaode dados, configuracao de alarmes e sinoticos (CASIMIRO, 1995). Taisconfiguracoes devem ser persistentes, sendo que alguns sistemas permitema exportacao destas configuracoes para formatos que possam ser consumidospor outras aplicacoes (SEROTONIN, 2011).

2.4.1.5 Historico

O historico se refere ao armazenamento e possibilidade de consulta deseries historias dos dados adquiridos do processo. Os dados coletados saoimportantes para a geracao de relatorios, graficos e tabelas e sao essenciaispara a realizacao de analises estatısticas como calculo de medias, varianciase previsoes atraves das curvas de tendencia (CASIMIRO, 1995).

2.4.1.6 Alarmes

Alarmes sao notificacoes que indicam que um determinado eventoocorreu no processo que esta sendo monitorado. A configuracao destes even-tos costuma seguir a mesma logica, onde variaveis monitoradas sao asso-ciadas a condicoes de disparo. Por exemplo, um operador pode associar avariavel pressao de um tanque a um limite, quando este valor for atingidosera gerado um alarme.

As condicoes mais comuns estao relacionadas com operacoes logicas,embora alguns sistemas permitam a elaboracao de condicoes mais elaboradascomo baseadas em calculos estatısticos e combinacoes de eventos (GOMES,2003). A definicao de prioridades para os alarmes tambem e uma funciona-lidade tipicamente empregada para facilitar seu gerenciamento pelos opera-dores, dado que alguns alarmes podem ser de suma importancia por estaremrelacionados a ocorrencia de situacoes crıticas. Alguns sistemas tambem per-mitem a geracao de alarmes a partir de eventos internos do proprio sistema (enao do processo), por exemplo a autenticacao de um usuario no sistema (SE-ROTONIN, 2011).

39

2.4.2 Requisitos Nao Funcionais

Existem propriedades que sao geralmente citadas como requisitos paraSCADA, abaixo serao descritas estas propriedades e suas motivacoes.

2.4.2.1 Interoperabilidade

Interoperabilidade e a capacidade de um sistema interagir com outrossistemas atraves da troca de informacoes (IEEE, 1991). Esta e uma propri-edade que vem sendo enfatizada dada a crescente necessidade de integracaoentre processos na industria, levando os aplicativos SCADA a interagiremcom sistemas de apoio a gestao ou sistemas situados em outras organiza-coes (FAVARETTO, 2001).

Para permitir esta interacao com outras aplicacoes um SCADA devedisponibilizar uma interface programavel acessıvel atraves da rede. Depen-dendo das necessidades da organizacao o acesso a esta interface pode estarconfinado a aplicacoes da rede local ou entao podem estar disponıveis atravesda Internet. Sistemas interoperaveis devem ter suporte para lidar com umagama variada de plataformas de hardware e software. Em SCADA esta temsido uma dificuldade devido a praticas como a adocao de tecnologias pro-prietarias e fechadas (URDANETA et al., 2007).

2.4.2.2 Portabilidade

A portabilidade e a capacidade de um sistema ser adaptado para execu-tar em diferentes ambientes de hardware e software (GHEZZI; JAZAYERI;MANDRIOLI, 2002). Em SCADA esta propriedade permite reduzir a de-pendencia do usuario do sistema de uma determinada plataforma de hard-ware ou software, agraciando-o com uma maior liberdade de escolha de for-necedores. Do ponto de vista dos desenvolvedores a portabilidade facilita aadaptacao do sistema para diferentes plataformas, ocasionando em uma maiorabrangencia de mercado (GOMES, 2003). A escolha por determinadas tec-nologias dependentes de plataformas especıficas e um problema constanteem SCADA, o padrao OPC baseado em DCOM e um exemplo, dada a suadependencia do sistema operacional Microsoft Windows.

40

2.4.2.3 Escalonabilidade

A escalonabilidade 1 em uma arquitetura de software esta relacionadacom capacidade que esta possui de suportar um numero grande de componen-tes ou interacoes entre eles (FIELDING, 2000). Sistema escalonaveis permi-tem que um aumento da demanda possa ser tratado com um aumento linear derecursos fısicos, sem que para isto seja necessario realizar alteracoes no soft-ware, com excecao de configuracoes para a utilizacao destes novos recursosfısicos (BRATAAS; HUGHES, 2004).

Aplicativos SCADA escalonaveis sao flexıveis o suficiente para se-rem utilizados em diferentes contextos, sejam estas exigentes ou nao quantoa carga requerida. Outro aspecto e que eles estao preparados para a expansaodos sistemas monitorados, por exemplo uma fabrica que aumentou consi-deravelmente o numero de equipamentos supervisionados (GOMES, 2003).Arquiteturas que gerenciam recursos de forma ineficiente, dificultando a dis-tribuicao de carga entre os componentes sao apontadas como causadoras deproblemas de escalonabilidade em aplicativos SCADA (URDANETA et al.,2007).

2.4.2.4 Confiabilidade

Confiabilidade e capacidade de um sistema continuar funcionando mes-mo apos a ocorrencia de falhas em seus componentes (PERRY; WOLF, 1992).A confiabilidade e muitas vezes ressaltada em SCADA devido ao uso des-tes sistemas em aplicacoes de missao crıtica que requerem alta disponibili-dade, como o monitoramento de centrais de distribuicao de energia eletricae agua (GOMES, 2003). Esta propriedade esta relacionada com os meca-nismos de redundancia e tolerancia a falhas utilizados no sistema, portantouma arquitetura de software deve suportar a introducao destes mecanismos,tornando possıvel melhorar a confiabilidade do sistema (URDANETA et al.,2007).

1O termo e oriundo do ingles scalability, sendo comumente traduzido na literatura decomputacao atraves do neologismo escalabilidade. Neste trabalho o termo escalonavel e pre-ferido em detrimento de escalavel, pois o primeiro significa ’algo passıvel de ser colocado emnıveis, etapas, escaloes, degraus’ enquanto que o segundo denota ’algo escalavel’, tal como umamontanha.

41

2.4.2.5 Seguranca

A seguranca esta relacionada com a capacidade do sistema em resistirao uso nao autorizado ao mesmo tempo que permite que usuarios legıtimosconsigam utiliza-lo. Esta propriedade pode ser caracterizada segundo a ha-bilidade que o sistema tem de fornecer mecanismos que fornecam disponi-bilidade, confidencialidade, integridade e nao repudio (BASS; CLEMENTS;KAZMAN, 2003).

Assim como a confiabilidade, esta e uma propriedade muito enfati-zada devido ao uso de SCADA em aplicacoes de missao crıtica, cujo impactode um ataque pode causar danos severos, tanto no aspecto humano comomaterial (GOMES, 2003). Em 2010 um ataque massivo foi realizado con-tra aplicacoes SCADA atraves do verme Stuxnet, colocando em evidencia avulnerabilidade destes sistemas (FALLIERE; MURCHU; CHIEN, 2010).

2.4.2.6 Tempo-real

Sistemas de tempo-real sao aqueles onde os aspectos temporais do seucomportamento fazem parte de sua especificacao. Um sistema com restricoesde tempo-real possui limites de tempo para a realizacao de suas tarefas, de-nominados deadlines (BERNAT; BURNS; LIAMOSI, 2001).

Alguns processos fısicos controlados por um sistema SCADA podempossuir necessidades de interacao em tempo real. Contudo esta restricao naoe constante, variando de processo para processo (DAWSON et al., 2006).Como as funcionalidades do SCADA estao associadas com a visualizacao dainformacao pelo operador e sua correspondente acao, os deadlines para estesprocessos costumam estar na casa dos segundos (GOMES, 2003). Neste sen-tido os deadlines tambem costumam ser soft, sendo que sua perda nao causaefeitos crıticos no sistema (BALASUBRAMANIAN et al., 2009). Devido anatureza nao-determinıstica da Internet nao esta no escopo deste trabalho tra-tar de aplicacoes SCADA cujos processos tenham requisitos de tempo real.

2.5 Conclusao do Capıtulo

Neste capıtulo foi apresentada uma visao geral de SCADA, abran-gendo seus principais conceitos, tecnologias e requisitos de software, levandoem conta alguns aspectos historicos que demonstram a evolucao pela qualesta area tem passado. No proximo capıtulo sera feita uma descricao da Webe uma introducao a conceitos da area de arquitetura de software, que servem

42

como base teorica da Arquitetura Orientada a Recursos.

43

3 Arquitetura de Software e a Web

3.1 A Web

A Web e um sistema distribuıdo de hipermıdia de alcance mundial querevolucionou a forma como pessoas, organizacoes e sistemas geram, aces-sam, e compartilham informacoes (BERNERS-LEE, 2000). Seu surgimentose deu em 1989, quando Tim Berner Lee viu a necessidade de compartilharinformacoes de pesquisadores da Organizacao Europeia para a Pesquisa Nu-clear (CERN, na sigla em ingles). Desde o princıpio seus requisitos eramdesafiadores, os pesquisadores utilizavam sistemas diferentes, estavam espa-lhados por diversos paıses da Europa e as informacoes compartilhadas naotinham um formato comum (BERNER-LEE, b). Os sistemas da epoca erammuito engessados para prover acesso a informacoes, que necessitavam se-guir uma estrutura pre-definida. A solucao foi utilizar o conceito de hiper-texto (NELSON, 1965), possibilitando que as informacoes fossem relaciona-das livremente e permitindo que o sistema se expandisse na medida em quenovas informacoes e relacionamentos eram incluıdos, sem que para isto fossenecessario qualquer tipo de controle centralizado (BERNER-LEE, a).

Entre 1990 e 1991 foram publicadas na Internet as primeiras versoesdas especificacoes que formam a base da Web: os Identificadores Universaisde Documentos (UDIs), que dariam origem aos Identificadores Uniformesde Recursos (URI), o Protocolo de Transporte de HiperTexto (HTTP) e aLinguagem de Marcacao de Hipertexto (HTML). Tambem foram divulgadaslivremente ferramentas que permitiam a qualquer indivıduo consumir, pro-duzir e hospedar informacoes na Web, atraves do primeiro navegador, editorde hipertexto e servidor Web respectivamente. Nestes primeiros anos a Webpassou a ser utilizada por pesquisadores do mundo todo, e suas especificacoespassaram a ser discutidas e modificadas colaborativamente, sendo criado em1994 o World Wide Web Consortium (W3C) (W3C, 2000).

Nos idos de 1993 ficou claro que a Web nao estaria confinada ao meioacademico quando indivıduos comecaram a utiliza-la para publicar seus sıtiospessoais e o mercado pelo seu uso comercial. A comunidade de desenvolve-dores e pesquisadores da Internet passou a temer que o crescimento exponen-cial da Web causasse um colapso em toda a rede. Apesar de a Web primordialter sido baseada em boas praticas de engenharia de software, como separacaode responsabilidades, simplicidade e generalidade, surgia a necessidade demelhoramentos em aspectos de escalonabilidade, performance e extensibili-dade para que problemas futuros pudessem ser evitados (FIELDING, 2000).

44

Todavia a Web nao possuıa uma descricao clara de sua arquitetura de soft-ware, o que dificultava o estabelecimento de uma filosofia comum pela qualseria guiado o seu projeto. Em seguida e apresentada a fundamentacao teoricasobre arquitetura de software, para que fiquem claros os princıpios que aju-daram a Web a continuar crescendo e mantendo suas boas propriedades.

3.2 Arquitetura de Software

Na medida em que cresce o tamanho e a complexidade de um sistema,e preciso tomar decisoes de projeto que vao alem da escolha de linguagens deprogramacao, algoritmos ou estruturas de dados (GARLAN; SHAW, 1993).Essas decisoes de projeto estao em um nıvel mais alto de abstracao, se preo-cupando com questoes relativas a organizacao geral do sistema, ou seja, coma sua arquitetura. De uma forma geral, uma arquitetura de software define oselementos que fazem parte de um sistema, incluindo a forma como estes ele-mentos se relacionam para cumprir com os requisitos para os quais o sistemafoi projetado (BASS; CLEMENTS; KAZMAN, 1997). Apesar do interesseda comunidade de pesquisadores de engenharia de software nesta area, existepouco consenso quanto a uma definicao precisa do termo arquitetura de soft-ware. Neste trabalho sera utilizada a definicao de (FIELDING, 2000), quedescreve uma terminologia auto-consistente para a area.

Segundo (FIELDING, 2000) arquitetura de software e uma abstracaodos elementos em execucao de um sistema durante uma de suas fases deoperacao. Abstracao e um conceito chave, pois permite omitir os detalhes quenao sao necessarios para compreender o cerne da dinamica de um sistema.Neste sentido, aspectos de implementacao dos elementos que compoem umadada arquitetura, tais como a linguagem de programacao em que foram desen-volvidos, podem ser ignorados. Uma abstracao esta restrita a um determinadonıvel, sendo que um sistema pode possuir diversos nıveis de abstracao, cadaum com uma determinada arquitetura. A definicao tambem vincula o conceitode arquitetura diretamente com o sistema durante sua execucao, tornando-aindependente da parte estatica, presente em seu codigo fonte e em qualquerdescricao ou documentacao de seu projeto. Outro aspecto e que um sistemapode apresentar diferentes arquiteturas para cada fase de sua operacao, porexemplo as fases de inicializacao, processamento e finalizacao no ciclo devida de uma aplicacao.

Uma arquitetura de software e definida por uma configuracao de seuselementos. Estes elementos incluem componentes, dados e conectores. Oscomponentes sao unidades abstratas de software que possuem um estado in-terno e realizam a transformacao de dados atraves de sua interface (PERRY;

45

WOLF, 1992). O comportamento de um componente e definido pela suainterface, nao importando para outros componentes como se da a sua im-plementacao. Por exemplo, um componente que realiza uma soma pode serutilizado por outros componentes, basta que estes saibam como solicita-la,o que e expresso atraves de interface deste componente (por exemplo quaisparametros sao aceitos na soma). Neste sentido um componente atua comouma ”caixa preta”, com uma interface bem definida para que outros possamutilizar seus servicos. O nıvel de abstracao de uma arquitetura e delimitadopela interface exposta pelos seus componentes. Componentes por sua vezpodem ser implementados internamente a partir de outros componentes, ge-rando uma recursao que termina quando sao encontrados os componentesbasicos, aqueles que nao podem ser decompostos em outros menos abstratos.

Os conectores sao os mecanismos abstratos que mediam a comunicacaoentre os componentes (SHAW; CLEMENTS, 1997). Estes elementos atuamcomo uma “cola” que une os componentes de uma arquitetura (GARLAN;SHAW, 1993). Os componentes de uma arquitetura nem sempre estao lo-calizados em uma mesma maquina ou processo, portanto um conector podeenvolver a implementacao de algum protocolo de comunicacao, podendo uti-lizar mecanismos como troca de mensagens, fluxos de dados (streams) e RPCcom este proposito.

Dados sao os elementos de informacao trocados entre os componentesa partir de seus conectores (FIELDING, 2000). Os dados contem a informacaoque e transformada pelos componentes, sejam estas informacoes passadascomo parametros, sequencias de bytes ou atraves de objetos serializados.Uma distincao importante entre componentes e conectores e que os primeirosrealizam algum tipo de transformacao sobre os dados, enquanto os ultimosapenas os transferem entre os componentes.

As propriedades de uma arquitetura incluem tanto os aspectos funci-onais, que ditam o que o sistema deve fazer, quanto os nao funcionais, quedefinem caracterısticas desejadas tais como, performance, seguranca e flexibi-lidade. E possıvel favorecer determinadas propriedades atraves da introducaode restricoes nos componentes, conectores e dados e na forma como esteselementos se relacionam (FIELDING, 2000). Essas restricoes sao embasa-das em princıpios conhecidos de engenharia de software, como separacao deresponsabilidades. Diferentes domınios de aplicacao possuem diferentes ne-cessidades, de modo que algumas propriedades arquiteturais podem ser maisinteressantes para um domınio do que para outro, portanto o projeto de umaarquitetura deve ser guiado pela aplicacao de restricoes que favorecam as pro-priedades desejadas pelo domınio em questao.

46

3.2.1 Estilos Arquiteturais

Atraves da aplicacao de boas praticas de engenharia de software os de-senvolvedores passaram a perceber a existencia de determinados padroes noprojeto de arquiteturas, que passaram a ser descritos e categorizados (SHAW;CLEMENTS, 2006). Esses padroes entre arquiteturas distintas abstraem oque e essencialmente comum entre elas, e em uma analogia com os estilosarquitetonicos das construcoes levam o nome de estilos arquiteturais. Umestilo arquitetural e um conjunto de restricoes comuns aplicadas nas arqui-teturas que o seguem (FIELDING, 2000). Desta forma uma arquitetura desoftware pode ser vista com uma instancia de um dado estilo arquitetural.

Arquiteturas de software envolvem propriedades funcionais, portantoe complicado comparar arquiteturas de domınios de aplicacao diferentes. Poroutro lado os estilos abstraem estes aspectos funcionais, se concentrando naspropriedades que sao induzidas pelas restricoes utilizadas. Estilos podemser usados em diferentes domınios de aplicacao, e comparados de acordocom a relevancia das propriedades que eles favorecem para cada domınioespecıfico (FIELDING, 2000). Estilos tambem podem ser combinados, for-mando estilos hıbridos.

3.3 REST

Nos seus primordios a Web nao possuıa uma descricao clara e obje-tiva de sua arquitetura de software. Seu projeto era guiado por alguns textos ediscussoes publicadas na rede e a melhor descricao de sua arquitetura de soft-ware estava internalizada em implementacoes. Era necessario estabelecer ummodelo para a arquitetura de software da Web. Um modelo abstrato que for-malizasse os princıpios existentes, incorporando as modificacoes necessariospara os requisitos que se apresentavam e que pudesse ser utilizado para ava-liar modificacoes futuras. Tais necessidades motivaram o desenvolvimentodo estilo arquitetural REST.

O estilo REST e hıbrido, composto de diversos estilos arquiteturaispara aplicacoes em rede, que quando aplicados em conjunto favorecerem aspropriedades desejadas para um sistema distribuıdo de hipermıdia na escalada Internet, como a Web. A seguir sera apresentado um resumo da tese de (FI-ELDING, 2000), onde sao descritos os estilos arquiteturais que compoemREST.

47

3.3.1 Os Estilos de REST

3.3.1.1 Cliente-Servidor

O estilo cliente-servidor e muito popular para aplicacoes em rede,abrangendo uma vasta gama de aplicativos utilizados para correio eletronico,transferencia de arquivos, base de dados, terminais remotos, etc (DOLLI-MORE; KINDBERG; COULOURIS, 2005). Nesse estilo um componenteservidor oferece servicos e espera por requisicoes, que sao enviadas por com-ponentes clientes interessados nestes servicos. Ao receberem as requisicoesos servidores decidem se as rejeitam, ou se enviam uma resposta ao cli-ente que as enviou (FIELDING, 2000). Sua motivacao esta no princıpio daseparacao de responsabilidades, que restringe o papel de cada componente.Separando a gerencia da interface grafica do armazenamento dos dados epossıvel melhorar a portabilidade dos clientes e simplificar a implementacaodos componentes servidores, melhorando a escalonabilidade. Outra propri-edade reforcada e que os clientes e servidores podem evoluir de forma in-dependente, desta forma a implementacao de qualquer componente pode sertotalmente alterada, desde que a interface de comunicacao entre eles nao oseja. A figura 6 mostra o diagrama de um arquitetura estilo cliente-servidor,onde o componente cliente e representado pela elipse e o componente servi-dor pelo retangulo.

Figura 6: Cliente-Servidor

3.3.1.2 Sem-Estado

Ao estilo cliente-servidor adiciona-se tambem uma caracterıstica decomunicacao sem estado. No estilo cliente-servidor-sem-estado cada requisi-cao feita de um cliente deve conter toda a informacao necessaria para queo servidor possa compreende-la, evitando que o servidor necessite guardarqualquer contexto de uma interacao anterior (FIELDING, 2000). Essa restri-cao favorece a visibilidade, pois somente e necessario observar uma requisicao

48

para entender seu resultado no sistema. A escalonabilidade e melhorada poiso servidor nao necessita armazenar o estado compartilhado entre multiplasrequisicoes, facilitando a liberacao de recursos. Uma desvantagem desse es-tilo e a redundancia de dados, que precisam ser enviados novamente a cadarequisicao, ocupando mais a rede.

Figura 7: Cliente-Servidor-Sem-Estado

3.3.1.3 Cache

Com a combinacao dos estilos cliente-servidor-sem-estado e cachechega-se ao estilo cliente-com-cache-servidor-sem-Estado. Esse estilo buscamelhorar a eficiencia no uso da rede atraves da adicao de um conector decache, com ele requisicoes marcadas como passıveis de cache podem serreaproveitadas, eliminando assim a necessidade de realizacao de algumasinteracoes (FIELDING, 2000). Com a cache as propriedades de eficiencia,escalonabilidade e performance percebida pelo usuario sao melhoradas. Adesvantagem esta no fato de que informacoes em cache podem estar desa-tualizadas, reduzindo a confiabilidade destas informacoes. O estilo Cliente-Cache-Servidor-Sem-Estado pode ser visualizado na figura 8 onde os conec-tores de cache (cifrao) sao acrescentados aos componentes cliente.

3.3.1.4 Interface Uniforme

Aplicando o princıpio de generalizacao a interface dos componenteschega-se ao estilo cliente-com-cache-servidor-sem-estado com interface uni-forme. Atraves deste estilo a interface entre os componentes e uniformizada.Isto significa que existe uma forma padronizada de os componentes se comu-nicarem, que e a mesma para todos os componentes. A interface uniforme

49

Figura 8: Cliente-Cache-Servidor-Sem-Estado

favorece a simplicidade, pois nao e necessario lidar com as especificidadesdas interfaces arbitrarias. A visibilidade tambem e melhorada, pois existeuma semantica comum na comunicacao entre os componentes, que pode serverificada atraves da inspecao das mensagens trocadas entre eles. O pro-blema desta uniformizacao e que toda a troca de informacao e feita de umaforma generica ao inves de ser especıfica para cada necessidade, piorando aeficiencia em alguns casos atraves da transferencia de mais informacao doque e necessario. Outras restricoes comportamentais entre os componen-tes sao necessarias para que a interface seja uniforme: identificacao de re-cursos, manipulacao de recursos atraves de representacoes, mensagens auto-descritivas e hipermıdia(FIELDING, 2000). Estas restricoes serao apresenta-das nos elementos arquiteturais de REST, que serao descritos posteriormenteneste capıtulo. A uniformidade na comunicacao entre os componentes desteestilo de arquitetura pode ser visualizada no diagrama da figura 9 atraves daexistencia dos conectores genericos ligando os componentes.

Figura 9: Cliente-Cache-Servidor-Sem-Estado-Uniformes

50

3.3.1.5 Sistema em Camadas

Neste estilo o sistema e dividido em camadas, sendo que cada camadaso tem conhecimento da camada adjacente. Sua motivacao esta na separacaode responsabilidades, desacoplando as camadas nao adjacentes. Exemplosde sistemas em camadas podem ser encontrados em pilhas de protocolosde comunicacao, como o modelo OSI/ISO e a pilha TCP/IP (PUDER; RO-MER; PILHOFER, 2005). As camadas podem ser utilizadas para encapsularservicos legados, proteger novos servicos de clientes legados, melhorar a es-calonabilidade atraves da distribuicao de carga ou introduzirem polıticas deseguranca. A desvantagem deste estilo esta na adicao de latencia extra nacomunicacao entre as camadas, podendo causar um impacto negativo na per-formance. Este problema e contrabalanceado atraves do uso de componentesde cache compartilhadas, que permitem que clientes distintos possam reapro-veitar informacoes de uma cache comum, poupando novas requisicoes (FI-ELDING, 2000). A figura 10 ilustra o estilo em camadas, as camadas podemser vistas da esquerda para a direita iniciando nos clientes que originam asrequisicoes, passando por componentes intermediarios como proxies e ga-teways e terminando nos servidores de origem que fornecem os recursos.

Figura 10: Cliente-Cache-Servidor-Sem-Estado-Uniformes-Em-Camadas

3.3.1.6 Codigo sob demanda

Com a inclusao do estilo codigo sob demanda e possıvel agregar fun-cionalidades ao cliente atraves de codigo executavel fornecido pelo servidor.Esta capacidade permite uma simplificacao na implementacao dos clientes.A desvantagem esta na reducao da visibilidade, pois o codigo movel precisa

51

ser interpretado, tornando mais complexa a tarefa de descobrir quais sao seusresultados. O codigo sob demanda e a unica restricao arquitetural opcional deREST (FIELDING, 2000). Na Web o codigo sob demanda esta presente pormeio de JavaScript e das Applets Java. Na figura 11 o codigo sob demandae representado atraves das engrenagens e scripts circulando entre clientes eservidores.

Figura 11: REST

3.3.2 Elementos Arquiteturais de REST

Descritos os estilos que compoem REST, da-se prosseguimento com aapresentacao de seus elementos arquiteturais, ou seja, seus dados, conectorese componentes.

3.3.2.1 Dados

REST possui tres elementos de dados: recursos, identificadores de re-cursos e representacoes (FIELDING, 2000). Recurso e qualquer informacaoque possa ser nomeada. Qualquer conceito que possa ser referenciado atravesde hipermıdia se encaixa nesta definicao, seja ele um livro, uma fabrica, aimagem de uma cidade ou uma colecao de outros recursos. Recursos sao ma-peamentos que associam conceitos com um conjunto qualquer de entidades,estas entidades podem ser representacoes ou identificadores de recursos. Eimportante distinguir os recursos das entidades para as quais eles mapeiam.Por exemplo, um recurso que simboliza a ultima peca fabricada por umamaquina pode estar associado a diferentes pecas ao longo do tempo, o im-

52

portante e que a semantica associada a ele permaneca constante, ou seja, queele sempre esteja associado a ultima peca fabricada.

Identificadores de recursos sao os elementos responsaveis por nomeare enderecar recursos. A identificacao e unıvoca, ou seja, dois recursos naopodem possuir o mesmo identificador. Sao os identificadores que possibilitamque os recursos possam ser referenciados na interacao entre os componentesda arquitetura, permitindo que os clientes possam expressar quais recursosdesejam acessar, e aos servidores identificarem quais recursos estao sendorequisitados.

Os recursos se materializam atraves das representacoes. Uma repre-sentacao e uma sequencia qualquer de bytes e metadados que descrevem es-tes bytes. Os componentes manipulam os recursos atraves da transferencia derepresentacoes, que descrevem o estado atual ou desejado do recurso. Os me-tadados descrevem a representacao e o recurso, definindo por exemplo a acaodesejada em uma interacao com o recurso. Metadados tambem permitem aparametrizacao de requisicoes e respostas e aspectos de controle de cache.

3.3.2.2 Componentes

Os componentes de REST sao categorizados pelo papel que exercemno ambito geral da arquitetura. O componente agente de usuario utiliza oconector cliente para efetuar requisicoes e receber respostas. Um exemplode agente de usuario e o navegador Web que requisita recursos e renderizarepresentacoes, exibindo-as para um usuario. Um componente servidor deorigem utiliza um conector do tipo servidor e trata requisicoes de clientes.Este componente prove uma interface generica para os recursos que admi-nistra, sendo uma fonte de representacoes de recursos e o ultimo destino derequisicoes que busquem altera-los (FIELDING, 2000).

Os outros dois componentes, gateway e proxy, atuam ao mesmo tempocomo clientes e servidores, exercendo funcionalidades como encaminhamentode requisicoes e respostas, encapsulamento de outros servicos e implementacaode polıticas de seguranca. Mais especificamente, o proxy e um componenteintermediario explicitamente escolhido pelo cliente. Ja o gateway e utilizadopelo servidor de origem, de forma que o cliente nao precisa saber de suaexistencia. O gateway tambem e conhecido como proxy reverso.

53

3.3.2.3 Conectores

Os conectores provem uma interface uniforme para a manipulacao derecursos, encapsulando as atividades de acesso e transferencia de representa-coes. Os conectores fundamentais de REST sao o cliente e o servidor. Ocliente e quem inicia a comunicacao, efetuando uma requisicao, o servidorespera por conexoes e responde a requisicoes que estejam acessando seusservicos. Um componente pode possuir ambos os conectores (FIELDING,2000).

Conectores do tipo cache podem ser utilizados por clientes ou servido-res para armazenarem mensagens, reutilizando-as com objetivo de reduzir onumero de interacoes realizadas na rede. O conector resolvedor traduz identi-ficadores em enderecos de rede para estabelecer a interacao entre componen-tes. Ja o tunel possui a funcao de criar um caminho virtual para travessia deinformacoes de forma a transpor limites, como um firewall ou um roteador.

3.4 Arquitetura Orientada a Recursos

A Arquitetura Orientada a Recursos (ROA) e uma arquitetura guiadapelos princıpios de REST e baseada em tecnologias consolidadas da Webcomo HTTP, URI e tipos e mıdia (RICHARDSON; RUBY, 2007). Esta ar-quitetura surgiu das dificuldades que os desenvolvedores enfrentavam ao pro-jetar aplicacoes Web com base em REST. As dificuldades estao relacionadasao alto nıvel de abstracao dos princıpios de REST, que abrem um amplo ho-rizonte de possibilidades de projeto. Entre as dificuldades esta o fato de queREST nao esta vinculado com a Web e suas tecnologias, pois e um estilo ar-quitetural para sistemas de hipermıdia distribuıdos, dos quais a Web e umainstancia especifica. Deste fato se deriva diretamente outra dificuldade, quee como utilizar as tecnologias da Web de acordo com as restricoes do es-tilo REST. Das necessidades de uma abordagem mais concreta e pragmaticapara os problemas que se colocavam surgiu a ROA. Esta arquitetura segue osprincıpios de REST, mas esta vinculada com as tecnologias da Web como oprotocolo HTTP, URI e formatos de dados como XML, XHTML e JSON. Aseguir serao apresentados seus conceitos, tecnologias e propriedades.

54

3.4.1 Conceitos

3.4.1.1 Recursos

Os recursos sao o cerne da ROA, como seu seu proprio nome in-dica. Os recursos sao definidos a partir de conceitos existentes no domınio daaplicacao em questao. Por exemplo, em uma aplicacao sobre SCADA exis-tem conceitos especıficos, como equipamentos de campo, colecoes de dadosadquiridos e alarmes.

Colecoes de outros recursos sao recursos tıpicos, por exemplo a colecaode todos os equipamentos em uma planta, que mapearia para um conjunto deenlaces, cada qual apontando para o recurso de um equipamento. Resultadosde algoritmos tambem podem ser expostos como recursos, por exemplo umabusca por um determinado equipamento, ou uma filtragem do historico deaquisicao de dados de um CLP. Outro recurso comum neste tipo de arquite-tura e o ponto de entrada da aplicacao, que expoe uma colecao dos recursosda aplicacao, pelos quais um cliente pode navegar. O projetista tambem podedefinir diferentes graus de granularidade para um mesmo sistema, criando no-vos recursos ou fundindo recursos existentes conforme as suas necessidades.

3.4.1.2 URI

Cada recurso precisa ser identificado para que os diferentes compo-nentes interessados nele possam referencia-lo e interagirem com ele. O quedetermina que determinado conceito do sistema e um recurso e o fato de esteser identificado a partir de uma URI. Cada URI identifica unicamente um re-curso na Web e simultaneamente o torna enderecavel, possibilitando que eleseja manipulado. A relacao entre recurso e URI e uma relacao um para mui-tos, ou seja, um recurso pode ser referenciado por muitas URIs, mas uma URIso pode ser associada com um recurso.

Nesta arquitetura e aconselhado que sejam escolhidas URIs cujos no-mes possam ser associados ao significado dos recursos para o qual apon-tam. Por exemplo, a URI para o recurso da colecao de equipamentos deuma fabrica poderia ser: ”/fabrica/equipamentos”. A razao deste conselhode utilizar URIs descritivas esta no uso desses enderecos por pessoas. Alemdas maquinas que consomem informacoes, estao usuarios que podem memo-rizar facilmente uma URI que lembre algum conceito. Desta forma um dosobjetivos da ROA e construir recursos que possam ser bem aproveitados porpessoas e por maquinas.

55

3.4.1.3 HTTP

E necessario que exista um protocolo para que os componentes daarquitetura possam se comunicar, possibilitando que os componentes sirvam,acessem e modifiquem recursos. Para isto a ROA utiliza o protocolo HTTP,um protocolo de nıvel de aplicacao para sistemas de hipermıdia distribuıdosque forma a base de comunicacao de toda a Web.

O protocolo HTTP possui um estilo cliente-servidor, onde a interacaoentre os componentes se da atraves de um modelo requisicao/resposta. Osclientes realizam requisicoes para servidores, indicando o recurso nos qualestao interessados atraves de uma URI. Estas requisicoes tambem conteminformacoes a respeito da acao que o cliente deseja realizar sobre o recurso.Devido a sua interface uniforme o HTTP define um conjunto finito de opera-coes, com semantica determinada, que podem ser realizadas em qualquer re-curso da Web (FIELDING et al., 1999). Os metodos HTTP utilizados naROA, e suas semanticas sao descritos abaixo. Esta descricao sera mais de-talhada posteriormente, quando for apresentada a metodologia de projeto daROA.

* GET: Obtem a representacao de um recurso;

* PUT: Cria ou atualiza um recurso na URI especificada;

* POST: Cria recursos subordinados a URI especificada. Anexo de in-formacoes a um recurso existente ou submissao a um processamentode dados;

* DELETE: Remove um recurso;

Alem de indicarem os recursos e operacoes sobre eles, estas interacoesrealizam a troca de informacoes sobre os recursos. Isto e feito atraves derepresentacoes de recursos. Cada resposta possui uma representacao, porexemplo a resposta de uma requisicao GET contem a representacao do estadoatual do recurso requerido. Requisicoes que criam recursos, ou atualizamsuas informacoes, tais como PUT e POST tambem carregam representacoes,que descrevem o recurso criado ou os dados que serao atualizados.

As representacoes possuem formatos de dados, que podem variar entrediversos tipos de linguagens de marcacao (HTML, XML, XHTML), imagens(PNG, SVG), textos (TXT, CSV), entre muitos outros. Para distinguir entreos formatos o HTTP utiliza o conceito de tipo de mıdia (o ingles Media-type),herdeiro da especificacao MIME utilizada em correio eletronico. Atraves demetadados colocados nos cabecalhos das requisicoes e respostas, o HTTP

56

explicita o tipo de mıdia das representacoes. Isto possibilita que clientes pos-sam decidir o que fazer com a representacao de acordo com esta informacao.Outro aspecto e que clientes e servidores podem negociar conteudo, comos clientes expondo quais tipos de mıdia preferem, e os servidores expondoquais tipos de mıdia oferecem. Outros metadados tambem sao utilizados nasrequisicoes e respostas para fornecer informacoes sobre os componentes etambem controle de cache.

O HTTP e intrinsecamente sem-estado, portanto quando o cliente en-via uma requisicao HTTP, ele inclui toda a informacao necessaria para que oservidor satisfaca a requisicao. O servidor por sua vez nao necessita armaze-nar o contexto da comunicacao com cada um de seus clientes, podendo tratarcada requisicao como um evento isolado.

Outro aspecto do protocolo e o seu suporte a componentes intermedia-rios na comunicacao entre clientes e servidores. Esta caracterıstica permite aexistencia de proxies e gateways, possibilitando caches compartilhadas entreclientes distintos e tambem o encapsulamento de sistemas legados.

3.4.1.4 Aspectos de Seguranca

O protocolo HTTP possui mecanismos de autenticacao incorporadosa sua especificacao: os metodos Basic e Digest. Ambos metodos permitem autilizacao de credenciais com identificacao de usuario e senha, embutidas nasrequisicoes do protocolo em uma interacao com o servidor no estilo Desafio-Resposta (do ingles Challenge-Response). O que difere essencialmente nosmecanismos e a forma com que sao representadas as credenciais. O servidor,ao receber estas requisicoes pode confirmar ou negar o acesso de clientesaos recursos solicitados. As credenciais sao sempre enviadas nas requisicoes,nao existindo qualquer mecanismo nativo para manutencao de sessoes nestesmetodos, pois acrescentaria estado na comunicacao.

No metodo Basic a dinamica se da da seguinte forma. Quando ocliente nao utiliza as credenciais na requisicao para um recurso protegido,ele recebe uma resposta do servidor indicando que nao esta autorizado aacessa-lo (codigo HTTP 401) e informando-o atraves do cabecalho “WWW-Authenticate” que o metodo de autenticacao e o Basic. O parametro “Re-alm” tambem e informado na resposta, e permite ao servidor descrever gru-pos de recursos guardados por autenticacao, permitindo por exemplo que osclientes exibam aos usuarios a descricao do grupo e armazenem em cache asinformacoes para se autenticar nos mesmos (FRANKS et al., 1999). Quandorecebe esta negativa o cliente pode fazer uma nova requisicao, desta vez con-tendo as suas credenciais concatenadas e codificadas em Base64 no cabecalho

57

“Authorization”. O servidor por sua vez passa a aceitar o acesso ao recursoprotegido.

O metodo Digest surgiu porque a codificacao em Base64 empregadano HTTP Basic pode ser decodificada facilmente. De fato a intencao dacodificacao Base64 nao e tornar segura a transmissao das credenciais, massim possibilitar o uso de caracteres nao compatıveis com a codificacao per-mitida pelo HTTP. No Digest as credenciais sao protegidas em um esquemamais complexo que envolve a aplicacao de criptografia utilizando a funcaode hash MD5 (FRANKS et al., 1999). E importante frisar que somente ascredenciais sao protegidas por criptografia nesse esquema. Como veremos aseguir o uso de HTTPS suplanta a necessidade do Digest. Desta forma suavantagem fica restrita a contextos onde o overhead do HTTPS nao e desejado,mas formas mais seguras de esconder as credenciais sao necessarias.

Conhece-se por HTTPS o uso combinado do HTTP com os protoco-los SSL/TLS. Estes protocolos, utilizados na camada de transporte (TCP),possibilitam que toda comunicacao HTTP seja criptograda e realizada pormeio de um canal seguro, garantindo a confidencialidade e integridade dasinformacoes (DIERKS; ALLEN, 1999). Estes protocolos utilizam mecanis-mos de criptografia assimetrica que permitem a assinatura digital das mensa-gens. Atraves da assinatura digital a autenticidade das partes comunicantespode ser comprovada, e a integridade das mensagens garantida. Os protocolospermitem duas configuracoes, a mutua e a simples. Na configuracao mutuaclientes e servidores necessitam possuir certificados, utilizados na assinaturadigital das mensagens. Na simples somente o servidor necessita possuir ocertificado, sendo amplamente utilizada na Web. Neste caso, como formade garantir a autenticidade dos clientes, o HTTPS pode ser combinado aoesquema de autenticacao Basic.

Nao existe um padrao universal na Web para lidar com a questaoda autorizacao, embora existam propostas como o OAuth sendo utilizadaspela comunidade (HAMMER-LAHAV, 2010). Desta forma, geralmente cadaaplicacao acaba por definir seus proprios mecanimos para cumprir com esterequisito.

3.4.1.5 Representacoes

O principal criterio na escolha de representacoes e o tipo de repre-sentacao que os clientes desejam consumir. A ROA propoe que sejam uti-lizadas tipos de mıdia comuns da Web, tais como XML, XHTML, e JSON.Representacoes que permitam a inclusao de hipermıdia tambem sao acon-selhadas, pois permitem conectividade entre os recursos, conceito que sera

58

explorado posteriormente.

3.4.2 Propriedades

A ROA tambem define algumas propriedades que uma aplicacao quesegue esta arquitetura deve possuir: Enderecabilidade, Sem-estado, Conecti-vidade e Interface Uniforme.

3.4.2.1 Enderecabilidade

Aplicacoes enderecaveis expoem as informacoes que sao interessantespara seus clientes atraves de recursos na Web. Pelo fato de possuırem URIs,as informacoes tem um endereco certo onde podem ser acessadas. Pessoaspodem encontra-las navegando na Web, atraves de enlaces nas representacoesde outros recursos. Encontrado um endereco, este pode ser referenciadas emnovos recursos, salvo nos favoritos do navegador, ou mesmo anotado em umpapel como um lembrete. Outras aplicacoes tambem podem se beneficiardesta enderecabilidade, guardando enderecos para verificar informacoes pe-riodicamente, e seguindo enlaces automaticamente como fazem os chamados”crawlers”, robos que sao muito usados em motores de busca.

3.4.2.2 Sem-estado

A propriedade sem-estado e diretamente derivada do estilo arquitetu-ral REST. A enfase da ROA esta no uso correto do protocolo HTTP, sem autilizacao de mecanismos que implementem sessoes. E importante esclare-cer que o conceito de estado se refere ao estado do cliente em relacao coma aplicacao. Por exemplo, ao navegar na Web um cliente segue uma seriede enlaces, cada acesso representa um acesso a um recurso. Informacoescomo quais recursos o cliente ja visitou e a ordem em que foram acessadossao ignoradas pelo servidor em uma aplicacao sem-estado. Sendo assim, seexiste algum interesse neste tipo de informacao ela deve ser guardada pelocliente. Isto evita a complexidade adicional que o servidor teria, dado que se-ria necessario analisar o historico de requisicoes para tomar qualquer decisao.Alem de trazer complicacoes, manter estado traz problemas de performance,pois e preciso guardar o contexto de cada cliente no servidor.

59

3.4.2.3 Conectividade

Os recursos da aplicacao devem estar conectados atraves de enlacesem suas representacoes. Desta forma os clientes podem escolher qual seraseu proximo passo, ou seja o proximo estado da aplicacao. Esta propriedadeconfere a uma aplicacao orientada a recursos o aspecto de uma teia, que podeestar ligada inclusive a outras aplicacoes, ou recursos quaisquer da Web.

3.4.2.4 Interface Uniforme

Operacoes sobre os recursos sao realizadas atraves dos metodos HTTP.A interface para o acesso e manipulacao dos recursos e uniforme, permitindoque exista um “vocabulario” comum, com o qual e possıvel interagir comqualquer recurso na Web. A seguir sao descritos os metodos HTTP utilizadosna ROA e suas semanticas.

Qualquer recurso para o qual seja possıvel a um cliente obter umarepresentacao deve expor o metodo GET. Os outros metodos servem paramodificar os recursos. O metodo PUT recebe uma representacao e e res-ponsavel por criar um recurso na URI especificada, ou entao atualizar a suarepresentacao caso ja exista um recurso nesta URI. O metodo POST e res-ponsavel por criar recursos subordinados ao recurso informado na URI, ainclusao de um item em um recurso de colecao e um exemplo comum deuso do metodo POST. Outros usos existem, como por exemplo anexar maisinformacao a um recurso existente, ou submeter um bloco de dados a umprocessamento qualquer.

A diferenca sutil entre os metodos PUT e POST para criacao e atu-alizacao de recursos esta no significado da URI indicada pelo cliente na re-quisicao. No caso do metodo POST esta URI representa um ponto de pro-cessamento da requisicao, mas nao necessariamente ela indica a URI ondeo recurso sera criado ou atualizado, cuja responsabilidade e inteiramente doservidor que gerencia este recurso. No metodo PUT, a URI especificada pelocliente na requisicao obrigatoriamente define o endereco onde este cliente es-pera que esteja o recurso apos o processamento da requisicao pelo servidor. Ometodo DELETE por sua vez tem como proposito remover um dado recurso.

3.4.3 Projeto de uma Arquitetura Orientada a Recursos

Um metodologia para o projeto de ROAs e apresentada em (RICHARD-SON; RUBY, 2007). Este metodo e baseado em uma serie de observacoes

60

pragmaticas de como transformar os requisitos de uma aplicacao em recursosda Web. A metodologia define uma sequencia de etapas, que tem como obje-tivo o projeto de uma ROA a partir de um conjunto de funcionalidades de umdado domınio de aplicacao. A seguir serao descritas estas etapas, explicandoas decisoes de projeto envolvidas em cada uma delas.

3.4.3.1 Levantamento do conjunto de dados

O primeiro passo no projeto de uma ROA esta no levantamento deseu conjunto de dados. Nesta fase do projeto deve-se analisar o domınio deaplicacao, identificando qualquer informacao que possa vir a ser util paraseus clientes. Por exemplo, uma aplicacao sobre SCADA poderia fornecerinformacoes a respeito dos equipamentos de campo, alarmes, ultimos dadosadquiridos por um dado equipamento e historico de dados. O importantenesta etapa e definir quais sao as informacoes disponibilizadas, como estasinformacoes serao disponibilizadas e um assunto para os proximos passos.

3.4.3.2 Definicao dos Recursos

Com o conjunto de dados definido o proximo passo e expor estasinformacoes como recursos. Uma ideia similar a da modelagem orientadaa objetos pode ser aplicada. A ideia envolve a identificacao de sujeitos pre-sentes no vocabulario comum do domınio de aplicacao, por exemplo: equi-pamento, alarme, historico, ultima leitura. Esses sujeitos sao um bom in-dicativo de quais sao os recursos envolvidos em uma aplicacao. Outros re-cursos tıpicos sao os relacionados com colecoes e resultados de algoritmos,por exemplo uma lista de todos os equipamentos ou o historico dos dadoscoletados por um sensor na ultima semana.

3.4.3.3 Escolha das URIs

Existem algumas decisoes na escolha de URIs que sao considera-das boas praticas, uma delas e a utilizacao do simbolo “/” em recursos quepossuem alguma relacao hierarquica. Por exemplo o recurso de todos osequipamentos de uma fabrica poderia ser identificado por ”/equipamentos”,enquanto que “/equipamento/grua” poderia identificar um equipamento es-pecıfico, no caso uma grua. Outra boa pratica e o uso de URIs que possamser facilmente compreendidas por pessoas, ajudando usuarios finais e proje-

61

tistas da arquitetura a entenderem de forma intuitiva os conceitos envolvidosem cada recurso.

3.4.3.4 Exposicao de um subconjunto da interface uniforme

Apos definir como um recurso sera identificado e necessario espe-cificar quais sao as operacoes possıveis que um cliente pode efetuar nesterecurso. Este passo se resume a definir o subconjunto de metodos da in-terface uniforme do protocolo HTTP pelas quais sera possıvel manipular orecurso. Qualquer recurso para o qual seja possıvel a um cliente obter umarepresentacao deve expor o metodo GET. A Alteracao de Recursos e reali-zada atraves do metodo PUT. A criacao pode ser feita por POST ou PUT,dependendo de quem (cliente ou servidor) e o responsavel por definir a URIonde o recurso e criado. Ja o metodo DELETE deve ser exposto por recursosque permitam sua remocao.

3.4.3.5 Projeto das representacoes

Neste passo devem ser definidas quais informacoes representam cadarecurso, assim como o formato utilizado para representa-las. No ambito doformato, a logica esta na selecao de tipos de mıdia padronizados da web(como o HTML e XML), que satisfacam as necessidades dos clientes e ser-vidores envolvidos. Diferentes representacoes podem ser definidas para ummesmo recurso, de forma que clientes podem aproveitar deste aspecto atravesda tecnica de negociacao de conteudo do protocolo HTTP.

3.4.3.6 Integracao com outros recursos

Definidas as representacoes o proximo passo e interligar os recursoscom outros. Esta associacao pode ser feita com qualquer recurso julgadointeressante, seja ele um recurso do sistema que esta sendo projetado ou ex-terno a ele. Recursos sao relacionados entre si atraves de enlaces presentesnas suas representacoes, portando a escolha de representacoes que permitamhipermıdia(como XML, HTML e XHTML) no passo anterior e crucial parauma boa conectividade.

62

3.4.3.7 Definicao das respostas

Nesta etapa e definida a interacao entre cliente e servidor, ou seja,como se dao os dialogos de requisicao/resposta entre eles. Deve ser respeitadoo protocolo HTTP, que define metadados como os codigos de resposta deacordo com a requisicao que foi feita, alem de estabelecidas quais podemser as representacoes enviadas no conteudo de cada resposta. Neste pontodevem se pensar nos casos onde as mensagens sao processados com sucessopelos componentes, assim como nos casos onde ocorre algum erro. Nos casoonde houve alguma falha deve ser informado qual o componente (cliente ouservidor) foi o responsavel pelo erro. Um resumo do procedimento completopresente na metodologia para projetar uma arquitetura orientada a recursos apartir de um dado domınio de aplicacao e apresentado abaixo:

1. Levantamento do conjunto de dados

2. Definicao dos recursos, e para cada recurso:

3. Nomear o Recurso com URIs;

4. Expor um Subconjunto da Interface Uniforme;

5. Projetar as Representacoes;

6. Integrar com Outros Recursos;

7. Definir Respostas;


Neste capıtulo foi apresentada uma descricao da Web e dos conceitosda area de arquitetura de software que fundamentam seus prıncipios de arqui-tetura. Na descricao da Web foi abordado seu historico e as motivacoes quelevaram a elaboracao de um estilo arquitetural que favorecesse seus requisi-tos. Em seguida foram apresentados os principais conceitos de arquiteturade software, incluindo a terminologia presente no referencial teorico da area.Com base nestes conceitos chega-se ao estilo arquitetural REST, o estilo ar-quitetural hıbrido que fundamenta os prıncipios arquiteturais da Web. Porfim conclui-se o capıtulo com a descricao da ROA, proposta como uma abor-dagem pragmatica que incorpora as tecnologias da Web como HTTP, URIe tipos de mıdia em conformidade com o estilo REST. O capıtulo seguinteexpoe uma analise sobre arquiteturas de software baseadas em RPC onde sao

63

explorados os pontos em que estas arquiteturas, predominantes em SCADA,divergem dos princıpios arquitetonicos da Web dificultando sua integracaocom a mesma.

65

4 Arquiteturas de Software para SCADA naWeb

Pode-se observar que os sistemas SCADA tem feito uma transicao nadirecao de possibilitar o seu uso como aplicativos Web. No entanto aindae muito difıcil encontrar sistemas SCADA que participem de forma plenada Web, nao tendo sido projetados de acordo com os princıpios de arqui-tetura de software descritos no capıtulo anterior. Na industria predominamabordagens baseadas em RPC para o desenvolvimento destes sistemas, prin-cipalmente devido a influencia do OPC, que se tornou um padrao de factona industria (HONG; JIANHUA, 2006)(KAPSALIS; KOUBIAS; PAPADO-POULOS, 2002)(TORRISI; OLIVEIRA, 2008). Neste capıtulo, serao apre-sentadas arquiteturas para SCADA explorados os pontos em que estas arqui-teturas divergem dos princıpios da Web.

4.1 Arquiteturas Baseadas em RPC

O RPC e um mecanismo para comunicacao entre aplicacoes distribu-ıdas (DOLLIMORE; KINDBERG; COULOURIS, 2005). As ideias em tornodeste paradigma sao discutidas desde os anos 70 (WHITE, 1976), sendo aformalizacao de seus prıncipios creditada a (BIRRELL; NELSON, 1984). Osconceitos do RPC sao centrados na abstracao das chamadas de procedimento,presentes em linguagens de programacao como C e Pascal. Procedimentossao trechos de codigo que cumprem com determinada tarefa, podendo serchamados em diferentes pontos de um programa. Quando um procedimentoe chamado, aquele que o chamou passa para ele um conjunto de parametros,o fluxo de execucao e entao transferido para o procedimento chamado, que iraefetuar uma computacao utilizando estes parametros. Efetuada a computacao,o fluxo de execucao e devolvido para o componente que o chamou, junta-mente com o resultado da operacao.

O mecanismo para chamadas remotas e similar, a diferenca e que oscomponentes se encontram distribuıdos em nos de uma rede. Chamadas re-motas tem uma dinamica de requisicao/resposta, sendo efetuadas por umcomponente solicitante atraves do envio de uma mensagem de requisicao, quecontem o procedimento solicitado juntamente com os dados dos parametros.O receptor da mensagem extrai os parametros da requisicao, executa o pro-cedimento solicitado, e envia uma mensagem de resposta contendo os dadosdo resultado da computacao. Geralmente esta comunicacao e feita de formasıncrona, onde o componente que chamou o procedimento fica bloqueado en-

66

quanto nao receber uma resposta (BIRRELL; NELSON, 1984).A similaridade entre chamadas locais e remotas levou a integracao

de RPC com as linguagens de programacao. Esta integracao permite quecomponentes se comuniquem da mesma forma, independentemente se estaolocalizados em um mesmo no ou em nos distintos da rede, propriedade conhe-cida como transparencia de localizacao (DOLLIMORE; KINDBERG; COU-LOURIS, 2005). Com a transparencia de localizacao, o programador podedesenvolver codigo de forma usual atraves de procedimentos, enquanto umacamada de software, conhecida como middleware, cuida de todas as respon-sabilidades relacionadas com a comunicacao remota.

Nos termos de arquitetura de software, o RPC se faz presente nos co-nectores, fornecendo o mecanismo de comunicacao entre os componentes.Ele e tipicamente empregado em arquiteturas de software em rede que se-guem o estilo cliente-servidor. Neste estilo um servidor fornece seus servicosatraves de seu conector RPC, expondo um conjunto de procedimentos quepoderao ser requisitados por seus clientes. A implementacao dos conecto-res atraves de componentes locais denominados stubs permite o tratamentodas chamadas remotas como se fossem locais, garantindo a transparencia delocalizacao. No conector do cliente um stub recebe as chamadas locais e deveconhecer a interface do servidor para que possa empacotar os parametros e re-alizar as chamadas remotas. No conector do servidor um stub tem como res-ponsabilidade desempacotar estes parametros e enviar respostas com dadosempacotados para seus clientes. Muitas vezes sao empregadas ferramentasde geracao de codigo, para poupar o programador do trabalho relacionado aodesenvolvimento dos stubs. Estas ferramentas tipicamente utilizam lingua-gens que descrevem a interface dos componentes, denominadas linguagensde descricao de interface (PRYCE, 1998).

Com o passar dos anos o paradigma de programacao procedural foisendo substituıdo pela orientacao a objetos, e o desenvolvimento de siste-mas orientados a objetos distribuıdos passou tomar a cena nos anos 90 com osurgimento de tecnologias como Common Object Request Broker Architec-ture (CORBA, da sigla em ingles) e o Distributed Component Object Model(DCOM, da sigla em ingles). Apesar de serem baseados em um novo para-digma, estes sistemas utilizavam praticamente os mesmos conceitos oriundosdo RPC tais como os stubs e as linguagens de descricao de interface, com aprincipal diferenca que as chamadas de procedimentos remotos foram subs-tituıdas por invocacoes remotas de metodos. Fruto desta geracao, a tecnologiaDCOM causou um grande impacto no mundo de SCADA, pois foi com basenela que foi elaborada a especificacao do OPC. O OPC e considerado umpadrao de facto para a area, por este motivo uma visao geral dele sera apre-sentada a seguir.

67

4.2 OPC

O OPC e um conjunto de especificacoes para automacao industrial,que define a troca de informacoes entre equipamentos. Tais equipamentospodem ser dispositivos de campo, estacoes remotas, estacoes mestre ou inter-faces homem maquina. Os dados trocados entre eles sao tıpicos de aplicacoesSCADA, como dados adquiridos de campo, series historicas, alarmes e co-mandos de controle (HONG; JIANHUA, 2006).

Seu surgimento se deu nos anos 90, motivado pela diversidade deequipamentos e protocolos de comunicacao existentes na automacao indus-trial, combinada com a ausencia de qualquer forma de padronizacao para estacomunicacao. Este cenario, onde cada equipamento era acessado de umaforma distinta, gerava problemas. Cada fabricante oferecia solucoes com-pletas de hardware e software, baseadas em protocolos proprietarios que naopermitiam interoperabilidade, limitando as opcoes de escolha das industrias.Outro aspecto estava nas dificuldades encontradas pelo mercado de software,que precisava desenvolver diferentes drivers para cada equipamento ou proto-colo encontrado nas plantas, gerando custo e complexidade (TU et al., 2010).Este cenario esta exposto na figura 12 (HONG; JIANHUA, 2006), onde tresaplicacoes se comunicam com equipamentos distintos, e para isto necessitamde tres drivers diferentes.

Figura 12: Complexidade antes do surgimento do OPC

O OPC propoem a adocao de interfaces padronizadas para a comu-nicacao entre os componentes de software. A comunicacao ocorre no estilocliente-servidor, onde os clientes sao as aplicacoes interessadas nos dados for-necidos pelos dispositivos (eg: uma interface homem maquina). Um servidorOPC expoe uma interface padronizada para o acesso aos dados dos dispo-sitivos, desta forma os clientes podem ter acesso as informacoes pelas quais

68

estao interessados sem precisarem conhecer a especificidades de cada equipa-mento. Para implementar o acesso a estas informacoes em cada equipamento,o servidor se comunica com drivers OPC fornecidos pelos fabricante. A figura13 (HONG; JIANHUA, 2006) ilustra como o OPC soluciona os problemas docaso exposto anteriormente.

Figura 13: Arquitetura baseada em OPC

As especificacoes do OPC sao baseadas na tecnologia DCOM, da Mi-crosoft. O DCOM e um padrao para comunicacao entre objetos distribuıdos,baseado no seu predecessor, o Component Object Model (COM), surgido danecessidade de comunicacao entre aplicacoes na plataforma Windows(PRYCE, 1998). Arquiteturas de software baseadas no estilo de objetos dis-tribuıdos decompoem as aplicacoes em um conjunto de objetos, que colabo-ram entre si. Cada objeto e uma entidade que possui um estado interno e da-dos, que so podem ser acessados ou alterados atraves de operacoes (tambemconhecidas como metodos). As operacoes definem a interface dos objetos,e sao a forma com que os objetos se comunicam. Quando as interacoes saoremotas, as chamadas seguem um modelo requisicao/resposta e devem trans-portar os parametros da solicitacao e da resposta. A principal diferenca entreobjetos distribuıdos e o RPC procedural esta na gerencia de referencias e co-leta de lixo (FIELDING, 2000).

A tecnologia DCOM estabelece uma linguagem, a Microsoft Inter-face Definition Language (MIDL), que serve para descrever as interfaces doscomponentes. Alem de servir como documentacao, a MIDL e utilizada nageracao de codigo fonte nas linguagens C/C++, automatizando a criacao dosstubs utilizados na comunicacao. A comunicacao entre os objetos por suavez, se da atraves do protocolo ORPC (Object RPC).

O OPC e formado por um conjunto de especificacoes, cada uma delas

69

abrange determinadas funcionalidades da uma aplicacao de automacao indus-trial. Cada especificacao determina classes de objetos, e suas interfaces. OOPC-DA define interfaces para acesso a dados adquiridos por equipamen-tos dotados de sensores, tais como CLPs e RTUs. A especificacao OPC-HDA define o acesso a series historicas. Ja o gerenciamento de alarmes eeventos e responsabilidade da especificacao OPC-AE. Existem tambem ou-tras especificacoes, que abarcam funcionalidades, como receitas e comandosde controle(TU et al., 2010).

Apesar de sua predominancia em SCADA, existem limitacoes no OPCque o impede de suprir as novas necessidades que vem se apresentando paraarea. Entre os problemas esta a questao da interoperabilidade e independenciade plataforma. A tecnologia DCOM e fortemente vinculada ao sistema ope-racional Windows, limitando seu uso em outras plataformas. Outra questaoe a comunicacao na Internet, dado que o protocolo utilizado pelo OPC e fre-quentemente bloqueado por firewalls. Por ser totalmente desvinculado daWeb, tambem existe um fator que acaba por isolar as aplicacoes OPC do res-tante do mundo, limitando a integracao com sistemas de MES, ERP entreoutros(TU et al., 2010).

4.3 OPC-UA

As limitacoes do padrao OPC motivaram a criacao de um novo padrao,o OPC Unified Architecture (OPC-UA). O nome “unificado” do OPC-UAse refere a unificacao de todas as especificacoes de interfaces (OPC-DA,OPC-HDA, OPC-AE. . . ), simplificando a arquitetura (HADLICH, 2006). Aespecificacao do OPC-UA e recente, tendo sido publicada em 2006, e atu-almente esta em fase de pesquisas e adocao pela industria (HANNELIUS;SALMENPERA; KUIKKA, 2008).

O OPC-UA eliminou os problemas de dependencia de plataforma etrouxe os conceitos do OPC para Web, atraves de uma abordagem baseada napilha de Web Services. Em termos de arquitetura de software o estilo baseadoem objetos distribuıdos foi mantido. As maiores mudancas estao nas tecno-logias utilizadas, apoiadas em padroes da Web. As mensagens passaram a serdescritas na linguagem XML, atraves do protocolo SOAP. Os protocolos pro-prietarios do DCOM foram abandonados, e o HTTP passou a ser adotado parao transporte das mensagens. As interfaces passaram a ser definidas atraves deWeb Service Description Language (WSDL), uma linguagem de descricaopara Web Services. A especificacao inclui uma forma de representar modelossemanticos de dados atraves de uma hierarquia extensıvel de tipos, permi-tindo que nichos especıficos da industria especifiquem seus proprios padroes

70

de dados. O uso destas tecnologias trouxe um avanco, melhorando aspectosde interoperabilidade, e trazendo os sistemas desenvolvidos mais proximosde uma integracao com a Web.

4.4 DPWS

Devices Profile for Web Services (DPWS da sigla em ingles) e umaespecificacao baseada em um subconjunto da pilha de Web Services direci-onada para comunicacao em dispositivos com restricoes de recursos compu-tacionais (OASIS, 2006). Seu foco e direcionado ao nıvel dos dispositivos,lidando com questoes como descoberta dinamica e propagacao de eventos.Nesta linha o DPWS se apresenta como um sucessor do padrao UPnP (Uni-versal Plug and Play) na comunicacao descentralizada entre dispositos, fre-quentemente empregada em areas como domotica e computacao ubıqua (SLE-MAN; MOELLER, 2008).

Ao contrario do OPC-UA, o DPWS se origina de uma area mais proxi-ma da TI convencional do que da informatica industrial. O OPC-UA e ori-entado para servir como uma interface para que aplicacoes de mais alto nıvelcomo IHM, MES e ERP possam obter dados oriundos do nıvel onde se en-contram os dispositivos de campo. Desta forma o OPC-UA possui um focomais direcionado para as funcionalidades das aplicacoes SCADA do queo DPWS (CANDIDO et al., 2010). Como o DPWS e o OPC-UA com-partilham a pilha de especificacoes de Web Services existem propostas deuma integracao destas abordagens, buscando cobrir os requisitos dos diferen-tes nıveis da automacao industrial (BONY; HARNISCHFEGER; JAMMES,2011) (IZAGUIRRE; LOBOV; LASTRA, 2011).

4.5 Arquiteturas Baseadas em RPC e sua Integracao com a Web

Padroes como o OPC-UA foram influenciados pela leva de tecnolo-gias de Web Services, surgidas no final dos anos 90. Os Web Services temcomo objetivo criar padroes para que aplicacoes desenvolvidas em diferen-tes plataformas pudessem interoperar (W3C, 2004). Estes padroes se apoiamem tecnologias da Web, especificamente o XML e o HTTP, como solucoespara os problemas de interoperabilidade enfrentados com os sistemas de ob-jetos distribuıdos CORBA e DCOM. A primeira especificacao publicada comeste proposito foi o XML-RPC, lancado em 1998. O XML-RPC e umaespecificacao para realizacao de RPC utilizando XML para a codificacao dasmensagens, e o protocolo HTTP para os transporte destas mensagens atraves

71

da Web (WINER, 1999). O XML-RPC trouxe um novo folego para o RPC,levando seus conceitos para a Web. Pouco depois do lancamento do XML-RPC foi publicada a primeira versao do SOAP, que assim como XML-RPC,definia padroes para realizar RPC na Web utilizando XML e HTTP (BOXKAKIVAYA, 1999).

Ao longo dos anos o SOAP e seus derivados da pilha de especificacoesde Web Services ganharam espaco, e fizeram um esforco para generalizar asespecificacoes, permitindo outros estilos de comunicacao que nao fossem osdo RPC. O problema das arquiteturas baseadas em RPC para a Web e que elasutilizam tecnologias como o XML e HTTP de uma forma nao condizente comos princıpios de arquitetura da Web. Desta forma, requisitos importantes daWeb, como evolucao independente, visibilidade das interacoes e escalonabi-lidade podem ser prejudicados.

Um dos problemas e a questao do acoplamento. Um dos princıpiosfundamentais da engenharia de software esta no desenvolvimento de sistemasmodulares que apresentem alta coesao e fraco acoplamento (MYERS, 1978).O acoplamento e uma propriedade que representa a interdependencia entremodulos, sendo que um acoplamento fraco e considerado benefico por faci-litar a compreensao, testabilidade e evolucao de um sistema (GHEZZI; JA-ZAYERI; MANDRIOLI, 2002). De uma forma geral, a literatura de Web Ser-vices caracteriza os sistemas com acoplamento fraco como aqueles onde dife-rentes servicos interoperam atraves de um pequeno conjunto de pressupostose, portanto, o impacto de mudancas e limitado e os servicos podem evoluirindependentemente (KAYE, 2003). O acoplamento forte nas aplicacoes dis-tribuıdas tipicamente as torna engessadas para se adaptarem a mudancas, pre-judicando a evolucao independente dos sistemas e implicando em um formade cooperacao mais burocratica com outras aplicacoes (PAUTASSO; WILDE,2009).

Arquiteturas baseadas em RPC compartilham um modelo comum dedados entre as aplicacoes. Isto implica que as mensagens trocadas entre oscomponentes contem as entidades internas destes sistemas codificadas de al-guma forma (objetos de domınio serializados por exemplo). A existenciadeste modelo de dados compartilhado introduz um forte acoplamento, poisqualquer mudanca na definicao do modelo deve ser replicada entre todas aspartes envolvidas. Quando existem poucos servicos sobre o controle de umamesma organizacao este nao parece um problema tao grande, mas ele crescede magnitude na medida em que mais organizacoes passam a cooperar. NoHTTP nao existe a dependencia de um modelo de dados compartilhado. Asmensagens trocadas entre os componentes sao direcionadas a recursos, quepossuem representacoes com formatos de dados padronizados atraves de ti-pos de mıdia. Os clientes podem escolher entre diferentes representacoes,

72

nao dependendo de qualquer formato especıfico. Estas representacoes podemser processados de forma padronizada, sendo que existem muitas bibliotecasde software disponıveis para seu processamento, nao criando dependencia deferramentas especificas (VINOSKI, 2008a).

O acoplamento tambem se manifesta atraves das interfaces especiali-zadas fornecidas pelos componentes de uma arquitetura baseada RPC. Nes-tas arquiteturas, os componentes se comunicam pela rede atraves do usode uma Application Programming Interface (do ingles API) local, formadapelos stubs. Esta API e responsavel pela transparencia de localizacao, esua implementacao realiza a comunicacao remota. O problema esta na de-pendencia de uma infraestrutura de software comum e dependente da aplicacaoentre os componentes. Em uma arquitetura orientada a recursos nao existeesta dependencia, dado que toda interacao se da diretamente atraves do pro-tocolo HTTP, independente de especificidades da aplicacao (PAUTASSO;WILDE, 2009).

Outro aspecto prejudicado nas arquiteturas baseadas em RPC e a vi-sibilidade das interacoes entre os componentes. A visibilidade se refere ahabilidade de um componente monitorar ou mediar uma interacao entre doisoutros componentes (FIELDING, 2000). A visibilidade pode ajudar na per-formance possibilitando a existencia de caches compartilhados, escalonabi-lidade por meio de sistemas em camadas e a seguranca atraves de firewalls.Nas arquiteturas baseadas em RPC as interfaces dos componentes nao pos-suem uma interface uniforme, desta forma cada aplicacao acaba por definirum conjunto de operacoes e um modelo de dados especifico para si propria.Isto prejudica a visibilidade, pois os componentes intermediarios precisamconhecer a semantica especifica de cada aplicacao com qual se relacionam, oque se torna inviavel em escalas como a da Web (VINOSKI, 2008b).

A falta de visibilidade nas interacoes dificulta o processamento dasmensagens por componentes intermediarios. As caches sao um exemplodestes componentes (VINOSKI, 2008b). Porem sem saber a semantica daoperacao e sem informacoes de controle presentes nas mensagens (como adata de vencimento da cache) uma cache nao pode atuar. O uso de cache ecrıtico para sistemas distribuıdos em larga escala na Web, e sua nao utilizacaoimpacta em propriedades importantes como a performance percebida pelousuario e a escalonabilidade.

Outra decisao arquitetural que pode prejudicar a visibilidade nas in-teracoes e que aplicacoes baseadas em RPC podem manter estado entre asinteracoes. Desta forma um componente que deseje descobrir o propositode uma mensagem pode ter que inspecionar todo o historico de mensagensanteriores a ela. Manter estado na comunicacao tambem causa impactos naescalonabilidade, pois o servidor necessita armazenar este estado para cada

73

cliente (FIELDING, 2000).Serendipidade e um neologismo derivado da palavra inglesa “seren-

dipity” definida como a habilidade de atrair ou descobrir coisas uteis poracaso (NEWMAN et al., 2002). No contexto dos sistemas distribuıdos estee um termo que vem sendo explorado nos ultimos anos para designar o usode um servico de formas que nao foram planejadas durante o seu projeto.O uso recente dos “mashups” na Web, aplicacoes que combinam dados eservicos de outras aplicacoes para seus propositos sao um exemplo praticodesta propriedade (RAZA; HUSSAIN; CHANG, 2008). Arquiteturas base-adas em RPC dificultam o reuso dos servicos, pois nada se pode assumir apriori sobre suas interfaces. Outra questao e que a ausencia da hipermıdiaacaba por criar servicos desconectados uns dos outros, evitando que um cli-ente descubra novos servicos por acaso atraves da navegacao pelos enlaces(VINOSKI, 2008b).


Este capıtulo realizou uma analise sobre arquiteturas de software paraSCADA na Web. Primeiramente foram descritos os conceitos das arquitetu-ras baseadas em RPC, predominantes em SCADA. Em seguida foram apre-sentadas as tecnologias OPC e OPC-UA, baseadas em RPC e populares emaplicacoes SCADA. Posteriormente foi feita uma analise das arquiteturas ba-seadas em RPC com relacao a sua integracao com a Web. Nesta analiseforam levantados os problemas de escalonabilidade, visibilidade e evolucaoindependente que as arquiteturas baseadas em RPC enfrentam quando utili-zadas na Web, causados pelo forte acoplamento, interfaces especializadas emanutencao de estado. No capıtulo seguinte sera projetada uma arquiteturapara aplicacoes tıpicas de SCADA, condizente com princıpios de arquiteturaque fundamentam a Web.

75

5 Proposta de Arquitetura Orientada aRecursos para SCADA na Web

Neste capıtulo mostra-se como uma aplicacao SCADA tıpica pode serorganizada de forma que seus requisitos sejam atendidos dentro dos princıpiosarquiteturais que fundamentam a Web. Conforme foi visto no capıtulo 2, sis-temas SCADA possuem um conjunto de funcionalidades em comum, taiscomo aquisicao de dados, configuracoes, historicos e alarmes. A ideia geralda proposta e explorar como estas funcionalidades podem ser atendidas poruma ROA atraves de um estudo de caso, tomando como cenario um ambientecaracterıstico de SCADA.

Primeiramente e feita uma descricao do objeto de estudo: uma CFMutilizada na simulacao de processos fabris. Sao levantadas as informacoesrelativas a CFM e ao processo em si, e alguns cenarios que exemplificamsituacoes tıpicas de uma aplicacao SCADA sao ilustrados.

Para o projeto da arquitetura e aplicada a metodologia orientada a re-cursos descrita no capıtulo 3. Inicia-se com uma visao geral da arquitetura,em seguida as informacoes da CFM e do processo em si sao utilizadas no pro-jeto dos recursos. A descricao do projeto e realizada de forma incremental,onde novos recursos sao criados na medida em que as funcionalidades tıpicasde SCADA sao incorporadas na arquitetura.

Os requisitos nao funcionais geralmente enfatizados em SCADA tam-bem sao levados em conta no projeto da arquitetura. Com o objetivo de mos-trar aspectos de interoperabilidade, simplicidade e portabilidade foi realizadauma implementacao, que possibilitou que fossem desenvolvidas aplicacoesque interagem com os recursos projetados. Esta implementacao foi realizadaatraves da modificacao de um software livre para SCADA: o Mango M2M,que teve sua arquitetura de software adaptada para as necessidades da arqui-tetura proposta. Segue-se agora com a descricao do estudo de caso.

5.1 Arquitetura Orientada a Recursos para Aplicacoes Tıpicas de SCADA

As CFMs sao parte integrante de um Sistema Flexıvel de Manufatura(FMS, na sigla em ingles). FMSs sao sistemas de producao altamente auto-matizados, capazes de produzir uma grande variedade de diferentes pecase produtos usando o mesmo equipamento e sistema de controle (CHAN;CHAN, 2004). A CFM utilizada no estudo de caso foi construıda pelo Ins-tituto Federal de Santa Catarina (IFSC) para o DAS/UFSC com objetivos

76

didaticos, sendo uma plataforma para simulacao de processos de manufaturaautomatizados (BENTO et al., 2007). A celula e composta por uma garra,uma mesa rotativa, dois alimentadores, tres depositos e quatro estacoes de tra-balho que efetuam as operacoes de furacao, solda, teste e retrabalho de pecas.Um desenho esquematico pode ser visto na figura 14 (GARCIA; QUEIROZ,2009), enquanto que uma foto da celula e sua bancada sao exibidas nas figuras15.

Comportamentos distintos podem ser apresentados pela celula, con-forme sua programacao. Neste estudo de caso utiliza-se do trabalho (GAR-CIA; QUEIROZ, 2009), onde um comportamento e proposto para a celula,modelado a partir da teoria de controle supervisorio modular local (QUEI-ROZ; CURY, 2000). De acordo com o comportamento proposto, a celuladeve furar e soldar pecas depositadas na mesa pela garra, que pode retirar es-tas pecas dos alimentadores de pecas novas e retrabalhadas. Ao final do pro-cesso a peca e testada em busca de imperfeicoes e depositada pela garra emum dos armazens disponıveis. Pecas aprovadas sao depositadas no armazemde aprovadas, pecas que reprovam no teste e que foram retiradas do alimenta-dor de pecas novas sao depositadas no armazem de retrabalho enquanto queas provenientes do alimentador de pecas retrabalhadas sao armazenadas noarmazem reprovadas.

Figura 14: Celula de manufatura flexıvel

A organizacao dos equipamentos na CFM e tıpica de um SCADA,pois estao presentes os dispositivos de campo, representados por sensores

77

Figura 15: Foto da CFM

e atuadores, uma estacao remota, constituıda por um CLP, e estacoes mes-tre e de operacao identificadas por computadores. A figura 16 ilustra estaorganizacao.

Os sensores identificam a chegada de uma peca nos alimentadorese armazens, e reconhecem se os equipamentos estao operando (estacoes defuracao, solda, teste e motores da garra e da mesa). Atuadores estao presen-tes para acionar os motores e estacoes. Somente os sensores de chegada depeca influenciam no controle supervisorio da planta, os demais sao utilizadospara fins de monitoramento

O CLP visto na figura 17 foi utilizado para efetuar a aquisicao de dadose o controle dos equipamentos, atraves da ligacao de suas entradas e saıdasnos sensores e atuadores da CFM. Este equipamento possui suporte ao proto-colo Modbus (Modbus Organization, 2011) que permite a leitura e escrita dedados em sua memoria (Altus, 2011), possibilitando o controle e supervisaopelo SCADA. O algoritmo de controle supervisorio que coordena o compor-tamento da CFM foi programado em sua memoria, e nao deve ser confundidocom o controle exercido pelo SCADA. Para se comunicar com o CLP o com-putador foi ligado a porta serial do equipamento.

78

Figura 16: Organizacao dos componentes de hardware do SCADA na CFM

Figura 17: CLP Altus PO 3147 usado na CFM

79

5.1.1 Visao Geral da Arquitetura

Com base nos componentes encontrados tipicamente em SCADA epossıvel delinear uma visao geral de uma arquitetura que os integre na Web.Nesta arquitetura ilustrada pela figura 18 estao presentes os servidores SCADA,responsaveis por expor na Web os recursos para as aplicacoes clientes. Os re-cursos sao a interface das aplicacoes clientes para com as funcionalidadestıpicas de SCADA, como historico de dados e alarmes.

No contexto dos componentes de hardware encontrados em SCADAestes servidores estarao ambientados tıpicamente nas estacoes mestre, quepossuem recursos computacionais suficientes para executar um servidor HTTP,como e o caso dos computadores da CFM. Entretanto, a arquitetura tambemesta preparada para suportar estacoes remotas que atuem como servidoresSCADA. Tais estacoes remotas trazem oportunidades interessantes, forne-cendo acesso via Web as suas configuracoes e dados coletados.

Outro aspecto essencial e incluir na arquitetura aqueles dispositivosque nao estao habilitados para a Web. Entram neste grupo todas as estacoesremotas que por necessidades do ambiente industrial (tempo-real por exem-plo), limitacoes de plataforma, ou falta de recursos computacionais nao saocapazes de se comunicar via HTTP. Um exemplo deste caso e o CLP da CFM,que se comunica atraves do protocolo Modbus RTU e nao tem capacidade deexecutar um servidor HTTP. Para lidar com esta questao podem ser utilizadosgateways, responsaveis por fazer a ponte entre o protocolo nativo do disposi-tivo e a Web. O gateway fornece uma interface Web para aplicacoes cliente eencapsula a comunicacao com o dispositivo incompatıvel com a Web.

As aplicacoes clientes podem ser classificadas de acordo com seus ob-jetivos quanto aos recursos fornecidos pelos servidores. A aplicacao utilizadapelo operador da CFM pode acessar os recursos para montar uma IHM como sinotico da celula, configurar o CLP e atuar sobre o processo. Para uma in-terface grafica mais dinamica, a aplicacao do operador pode aproveitar-se decodigo movel residente no servidor (como JavaScript ou Applets Java) paraenriquecer as capacidades do navegador. O cliente tambem pode se benefi-ciar de um conector de cache para evitar a realizacao de algumas requisicoes,melhorando a performance percebida pelo usuario.

Aplicacoes MES podem se interessar por dados historicos, como con-tagens de pecas para controle de qualidade, enquanto que uma aplicacao ERPpode utilizar as mesmas informacoes para realizar controle de estoque e agen-dar novas compras. Tambem podem existir aplicacoes interessadas em even-tos especıficos, como a quebra de um equipamento, o que pode ser realizadoatraves da espera pelo disparo de alarmes.

Como a arquitetura proposta esta fundamentada nos prıncipios de ar-

80

quitetura da Web, podem ser incluıdos componentes intermediarios entre cli-entes e servidores. Uma cache compartilhada pode ser instalada entre clientesde uma mesma rede, de forma que os recursos acessados sao salvos na cachemelhorando a perfomance e a escalonabilidade. Um proxy de autenticacaotambem pode ser incluıdo com o objetivo de adicionar credenciais de autenticacaonas requisicoes nao autenticadas, desacoplando funcionalidades.

Figura 18: Arquitetura ROA para aplicacoes tıpicas SCADA

5.1.2 Projeto dos Recursos

Na visao geral da arquitetura estao presentes os componentes e conec-tores, segue-se com o projeto dos recursos e suas representacoes, que consti-tuem os dados trocados entre os componentes. Para projetar os recursos saoutilizados dados do domınio em questao, desta forma sao recapituladas asfuncionalidades tıpicas de SCADA.

Um dos requisitos tıpicos de SCADA e a possibilidade de configuraros dispositivos coletores de dados de acordo com as necessidades do pro-cesso onde serao utilizados. Na CFM, o CLP possui diversos parametrosde configuracao para realizar a aquisicao de dados. Em outros casos, como

81

Recurso URIColecao de coletores de dados /coletores

Um coletor de dados /coletor/{id}

Tabela 1: Recursos de coleta de dados

uma fabrica, poderiam existir diversos dispositivos de aquisicao de dados(CLPs ou sensores inteligentes), cada qual com seu proprio protocolo decomunicacao e parametros configuracao especıficos.

Cada dispositivo de coleta de dados (ou simplesmente coletor) e mode-lado como um recurso, tendo como informacoes o protocolo de comunicacaoutilizado, parametros de configuracao e estado de operacao (ativo ou inativo).Um recurso de colecao tambem e definido, contendo enlaces para todos oscoletores existentes. Na tabela 1 os recursos relacionados aos coletores e suasURIs.

Para estes recursos e natural que se permita obter as informacoes deuma colecao de coletores ou de um determinado coletor especıfico. Estasinformacoes podem ser apresentadas em uma interface grafica qualquer, ondeum tecnico poderia saber quais sao, e como estao configurados os coletoresde dados do processo supervisionado. Desta forma e natural que estes recur-sos implementem o metodo GET, permitindo que clientes possam obter suasinformacoes.

As necessidades do processo podem se alterar e novos dispositivos po-dem ser adicionados ou removidos do sistema. Portanto deve ser possıvel queclientes criem coletores de dados, atualizem as configuracoes de um coletorexistente ou removam um coletor que nao seja mais necessario.

A criacao de um coletor e realizada atraves da inclusao do coletorna colecao. Isto e realizado atraves de um requisicao POST no recurso dacolecao de coletores, tendo como representacao as informacoes do coletorque o cliente deseja criar. A escolha do metodo POST ao inves do PUT nocaso da criacao se da pois e o servidor o responsavel por definir a URI onde orecurso sera criado. Por exemplo, se um cliente enviar uma requisicao POSTcontendo uma representacao valida de um coletor para a URI do recurso dacolecao de coletores, o servidor podera responder que conseguiu criar o re-curso (codigo HTTP 201) e na representacao da resposta incluir a URI ondeeste recurso foi criado, como: ”/coletores/1”(onde o numero 1 e um identifi-cador unico definido pelo servidor).

Um coletor pode ter as suas configuracoes atualizadas atraves de umarequisicao PUT, contendo uma representacao com as informacoes de con-figuracao desejadas. Por exemplo, o tecnico da celula pode julgar que a

82

Recurso GET POST PUT DELETEColecao de coletores de dados X X

Um coletor de dados X X X

Tabela 2: Interface dos recursos de coleta de dados

frequencia de aquisicao de dados do coletor Modbus esta muito baixa, e de-seja atualiza-la, para isto ele utiliza uma aplicacao cliente que realiza umarequisicao PUT no recurso do coletor, informando na sua representacao afrequencia desejada. Da mesma forma o coletor pode ter a sua aquisicao dedados ativada ou desativada, o que pode ser necessario para alguma manu-tencao. No caso do coletor nao ser mais necessario para o sistema, ele podeser removido atraves de uma requisicao DELETE. Os metodos da interfaceuniforme definidos para os recursos de coleta de dados podem ser vistos nana tabela 2.

No projeto das representacoes fornecidas pelos recursos, a primeiradecisao e escolher os tipos de mıdia que serao utilizados. O formato JSONfoi escolhido devido a sua simplicidade, por ser compacto e facilmente lidopor humanos e interpretado por maquinas. Por ser um subconjunto da lin-guagem JavaScript este formato e interpretado nativamente por todos os na-vegadores que a suportam, sem a necessidade de bibliotecas adicionais pararealizacao do parsing.O formato JSON possui duas estruturas, uma colecaode pares chave/valor (equivalente a um objeto ou tabela associativa em outraslinguagens) ou uma lista ordenada de valores. Cada valor pode por sua vezassumir diferentes tipos: textual, numerico, booleano, objeto ou lista(JSON,2010).

Tipos de mıdia adicionais tambem podem ser definidos para cada re-curso, fornecendo opcao para que cada cliente especifique qual o formatomais apropriado para ele. Este mecanismo e conhecido como negociacao deconteudo, e e parte integrante da especificacao do protocolo HTTP. Nela o cli-ente pode especificar o cabecalho “Accept” nas suas requisicoes, fornecendoos tipos de mıdia preferidos para que o servidor possa decidir o que fazer.

Definido o tipo de mıdia, resta especificar quais dados serao embutidosem cada representacao. A representacao da colecao de coletores nao necessitamais informacao do que uma lista com os enlaces para cada coletor. Ja arepresentacao de um coletor deve fornecer todas as informacoes a respeito domesmo, tais como: o protocolo utilizado, configuracoes e se o mesmo estaativo ou inativo. Exemplos das representacoes da colecao de coletores e deum coletor Modbus configurado para adquirir dados do CLP da CFM por servistos nas figuras 19 e 20. Na figura 21 um exemplo de como ficaria uma

83

representacao alternativa do recurso de coletor, no formato XML.

"coletores": [

{"nome" : CLP, "uri": "/coletor/1"}

]

Figura 19: Representacao da colecao de coletores

{

"nome":CLP,

"protocolo": "ModbusRTU",

"taxaDeAtualizac~ao":500,

"taxaDeBaud":9600,

"timeout":500,

"portaSerial":COM1,

"ativo": "sim",

}

Figura 20: Representacao do coletor Modbus RTU

<coletor>

<nome>CLP</nome>

<protocolo>ModbusRTU</protocolo>

<taxaDeAtualizac~ao>500</taxaDeAtualizac~ao>

<taxaDeBaud>9600</taxaDeBaud>

<timeout>500</timeout>

<portaSerial>COM1</portaSerial>

<ativo>sim</ativo>

</coletor>

Figura 21: Representacao XML alternativa do coletor Modbus RTU

Outra funcionalidade tıpica de SCADA diz respeito a configuracaode quais dados serao coletados. Na celula existem diversas variaveis quepodem ser monitoradas, tambem conhecidas por outros termos, como enti-dades telemetradas (GOMES, 2003), pontos (SEROTONIN, 2011) (NationalCommunications Systems, 2004) ou etiquetas (tags)(ADAMO et al., 2007).Exemplos de variaveis que podem ser colhidas da CFM sao: o estado atualdos equipamentos (garra, mesa e as estacoes de furacao, solda e teste de qua-lidade) e a contagem de pecas que foram aprovadas, reprovadas ou enviadaspara retrabalho.

84

Recurso URIColecao de variaveis /variaveis

Uma variavel /variavel/{idDaVariavel}

Tabela 3: Recursos de variaveis do processo

Cada variavel e associada a um tipo de dado, que classifica os valo-res possıveis que ela pode assumir, tais como dados booleanos, numericos,enumeracoes e imagens. No caso da CFM, a contagem de pecas pode serclassificada como um valor numerico, enquanto que a informacao de que de-terminado equipamento esta ligado ou desligado e um valor booleano.

Acoes de controle permitem que o operador possa atuar sobre o pro-cesso. Estas acoes geralmente sao atribuıdas as variaveis. Por exemplo umoperador da celula poderia ligar ou desligar a furadeira enviando um comandode controle para a variavel que a representa.

Como os dados sao adquiridos pelo dispositivo coletor tambem setorna importante especificar como a variavel pode ser localizada nos dadoscolhidos por ele. Na CFM o protocolo Modbus utilizado pelo CLP possuiuma forma particular de enderecamento, onde trechos da memoria do dis-positivo servidor sao expostos para os clientes. Permitindo que um clienteque esta interessado em uma informacao defina parametros como faixa deregistradores, tipo do dado (por exemplo binario ou um inteiro sem sinal) edeslocamento de endereco que resultam na informacao que sera lida ou es-crita.

Com esta analise, podem ser definidos alguns novos recursos. Cadavariavel do processo por si so e um recurso com informacoes como nome, tipode dado e especificacoes de como podem ser lidas pelo coletor. Uma colecaode variaveis tambem e um recurso necessario, por listar todas as variaveisexistentes no processo. Na tabela 3 os recursos relacionados as variaveis doprocesso e suas URIs.

Informacoes associadas a esses recursos podem ser obtidas pelos cli-entes, pois permitem que saibam quais sao as variaveis supervisionadas equal a semantica de cada uma delas, portanto o metodo GET deve ser expostopara esses recursos. Tambem interessa a tecnicos e operadores possuirem acapacidade de criar, modificar e excluir variaveis. Desta forma sao expostasas operacoes POST, PUT e DELETE. Novas variaveis sao criadas atraves dometodo POST na colecao de variaveis, enquanto que uma variavel pode sermodificada ou removida atraves das operacoes PUT e DELETE, respectiva-mente. Acoes de controle tambem podem ser efetuadas atraves da operacaoPUT, especificando na representacao da variavel os parametros da acao de

85

Recurso GET POST PUT DELETEColecao de variaveis X

Uma variavel X X X

Tabela 4: Interface dos recursos de variaveis do processo

controle. Os metodos da interface uniforme definidos para os recursos po-dem ser vistos na tabela 4.

O proximo passo e escolher como serao as representacoes para osrecursos. Na definicao dos recursos relacionados aos coletores foi esco-lhido o tipo de mıdia JSON, que sera mantido, portanto basta escolher quaisinformacoes estarao presentes em cada representacao. As representacoes decolecoes de variaveis nao necessitam de mais informacoes do que uma listacom os enlaces para cada variavel. A representacao de uma variavel fornecetodas as informacoes da mesma, tais como: nome, descricao, tipo de dados,endereco no coletor e enlaces para seus recursos de ultima leitura e historico.Exemplos de representacoes da colecao de variaveis e da variavel da conta-gem de pecas aprovadas da celula podem ser vistos nas figuras 22 e 23.

"variaveis": [

{"nome" : pecasAprovadas, "uri": "/variavel/1"}

{"nome" : pecasReprovadas, "uri": "/variavel/2"}

{"nome" : pecasDeRetrabalho, "uri": "/variavel/3"}

{"nome" : pecasNovas, "uri": "/variavel/4"}

{"nome" : furadeira, "uri": "/variavel/5"}

{"nome" : solda, "uri": "/variavel/6"}

{"nome" : teste, "uri": "/variavel/7"}

{"nome" : mesaGirando, "uri": "/variavel/8"}

{"nome" : garraPegandoPeca, "uri": "/variavel/9"}

{"nome" : garraSeMovendo, "uri": "/variavel/10"}

]

Figura 22: Representacao da colecao de variaveis

Modelados os recursos dos coletores e variaveis estao cobertos osaspectos de configuracao da aquisicao de dados. Contudo os dados cole-tados propriamente ditos tambem devem ser expostos para os clientes. Osdados coletados estao diretamente associados as variaveis configuradas paraaquisicao, sendo portanto recursos subordinados a estas. A ultima leitura deuma variavel pode ser modelada com um recurso, pois permite o acompanha-

86

{

"nome":contagemDePecasAprovadas,

"coletor":"/coletor/1",

"tipoDeDado": "booleano",

"offset":22,

"habilitada":true

"ultimaLeitura": "/variavel/1/ultimaLeitura"

"historico": "/variavel/1/historico"

}

Figura 23: Representacao de uma variavel

mento do estado atual do processo supervisionado. Na tabela 5 esta expostoo recurso de ultima leitura e sua URI.

Um cliente pode obter a ultima leitura da variavel atraves do metodoGET. Outras operacoes (POST, PUT e DELETE) nao sao expostas, poistrata-se de um recurso somente para leitura, nao fazendo sentido qualqueroutra operacao. Os clientes monitoram as variaveis atraves de sucessivasrequisicoes GET, em uma tecnica conhecida como varredura cıclica (”Pol-ling”). Na figura 24 a representacao da ultima leitura da variavel contagemde pecas aprovadas, que possui como informacoes um valor associado a umaestampilha de tempo.

Outro requisito tıpico e o historico dos dados coletados. Este historicopode possibilitar que clientes possam utilizar estes dados na montagem de umgrafico ou na plotagem de uma curva de tendencia. Assim como a ultima lei-tura, o historico esta subordinado a variavel monitorada. Alguns clientes pos-sivelmente vao se interessar somente por um subconjunto do historico, por-tanto torna-se importante definir um recurso que represente o historico dentrode um determinado intervalo de tempo, especificado pelo cliente atraves deuma URI.

Da mesma forma que no recurso de ultima leitura, somente o metodoGET e exposto pelos recursos de historico. A representacao do recurso dehistorico e uma colecao de leituras, cada uma contendo um valor, acompa-nhado do instante de tempo de sua coleta. Na figura 25 exemplos de umarepresentacao do historico da variavel contagem de pecas aprovadas em umdeterminado intervalo de tempo.

Muitas vezes pode ocorrer de nao haver uma nova leitura para o cli-ente. Para evitar transferencia desnecessaria de informacoes, amenizando osproblemas da varredura cıclica, pode-se utilizar o mecanismo de GET con-dicional. No GET condicional o cliente informa atraves do cabecalho HTTP“If-Modified-Since” uma estampilha com o instante de tempo da ultima lei-

87

Recurso URIUltima leitura de variavel /variavel/{id}/ultimaLeitura

Historico de variavel /variavel/{id}/historicoHistorico de variavel por intervalo /variaveis/{id}/historico/{inicio},{fim}

Tabela 5: Recursos de dados coletados

{

"instante": "31-07-2011 23:04:02",

"valor": 30

}

Figura 24: Representacao da ultima leitura de uma variavel

tura que ele possui. O servidor, ao receber a requisicao, analisa se houveuma nova leitura depois do instante informado pelo cliente, caso exista, umarepresentacao da nova leitura e enviada, com o cabecalho “Last-Modified”ajustado com o instante da ultima leitura. Caso nao exista uma nova leitura,uma representacao vazia e enviada como resposta, com o codigo HTTP 304,informando que o recurso nao foi modificado. Ao receber essa resposta de re-curso nao modificado, o cliente pode utilizar as informacoes presentes em seucache local. Este mecanismo de GET condicional tambem pode ser utilizadoem outros recursos caso seja necessario.

Alarmes sao conceitos comuns em SCADA, pois indicam a ocorrenciade eventos inesperados no processo que esta sendo monitorado. As condicoesde disparo dos alarmes estao associadas a variaveis do processo supervisio-nado, sendo expressas atraves de expressoes logico-matematicas como igual-dade e desigualdade de valores e mudanca de estado. A existencia de nıveisde prioridade para os alarmes e importante, pois permite ao operador saberquais alarmes demandam uma maior atencao, por exemplo quando ocorrealguma situacao crıtica que necessita de um tratamento prioritario.

"leituras": [

{"instante": "31-07-2011 22:12:02", "valor": 30}

{"instante": "31-07-2011 22:08:02", "valor": 29}

{"instante": "31-07-2011 22:04:02", "valor": 28}

]

Figura 25: Representacao do historico de uma variavel

88

Assim como na aquisicao de dados, um dos aspectos fundamentaisquanto aos alarmes e a possibilidade de configura-los para o processo que estasendo monitorado. Neste ambito, deve ser possıvel visualizar e determinarquais sao as condicoes alarmantes, ou seja, aquelas que disparam alarmes.Um recurso de colecao de todos os alarmes configurados para o processopode ser criado com este proposito.

Tambem deve ser possıvel criar novos alarmes, por exemplo, o ge-rente de producao da fabrica deseja saber quando a contagem de pecas re-trabalhadas chegar a tres, para que possa reclamar da qualidade das pecasbrutas. A criacao de novos alarmes e realizada atraves de uma requisicaoPOST na colecao de alarmes, onde o cliente especifica na representacao en-viada as condicoes de disparo, um texto descrevendo o alarme e a priori-dade dos alarmes que serao disparados. Na figura 26 o exemplo de comoseria a representacao enviada pelo aplicativo cliente utilizado pelo gerente deproducao.

{

"nome": "numeroDePecasEmRetrabalhoIgualATres",

"condic~ao": "numeroDePecasEmRetrabalho=3",

"descric~ao": "tres pecas em retrabalho",

"prioridade": "URGENTE",

}

Figura 26: Representacao de um alarme enviado pelo cliente

Ao efetuar uma requisicao GET no recurso da colecao dos alarmes, ocliente tera como resultado uma listagem das URIs de cada recurso de alarmeque foi criado, podendo exibir esta listagem na interface grafica por exemplo.A representacao de uma colecao de alarmes contendo tres alarmes pode servista na figura 27.

alarmes: [

{"nome": "tresEmRetrabalho", "uri": "/alarme/1"},

{"nome": "mesaParouDeGirar", "uri": "/alarme/2"},

{"nome": "pecaReprovada", "uri":"/alarme/3"},

]

Figura 27: Representacao da colecao de alarmes

Cada recurso de alarme e identificado unicamente em sua URI porum numero qualquer determinado pelo servidor. A representacao do recursode alarme reflete a representacao enviada pelo cliente em sua criacao, com

89

a adicao da informacao de quando o alarme foi criado, e de um enlace parao recurso que representa o disparo do alarme. Na figura 28 pode ser vista arepresentacao do alarme criado no exemplo.

{

"nome": "numeroDePecasEmRetrabalhoIgualATres",

"condic~ao": "numeroDePecasEmRetrabalho=3",

"descric~ao": "pecas em retrabalho chegaram a 3",

"prioridade": "URGENTE",

"criadoEm": "20-07-2011 22:00:00",

"disparo": "/alarme/1/disparo",

}

Figura 28: Representacao de um alarme recebido do servidor

Contudo, e preciso que exista um mecanismo para avisar os clientesdo disparo dos alarmes. Tal comportamento pode ser modelado atraves deum recurso para o disparo do alarme (presente na representacao do alarme).Ao efetuar uma requisicao GET no recurso de disparo, o cliente fica aguar-dando o recebimento de uma resposta, assim que a condicao estabelecida parao disparo do alarme se cumpre, o servidor envia como resposta para o clienteuma representacao com dados como: o instante em que o alarme disparou,sua prioridade e a descricao do disparo. Esta tecnica onde o servidor aguardaate que tenha alguma informacao disponıvel para responder ao cliente e umavariante da varredura cıclica. Ela e conhecida como “Long Polling” e fazparte um conjunto de tecnicas conhecidas como Comet (BOZDAG; MES-BAH; DEURSEN, 2007), utilizadas para implementar esta dinamica ondeclientes HTTP esperam por notificacoes do servidor, sem que para isso preci-sem de um conector de servidor.

{

"instante": "12-07-2011 12:12:01",

"prioridade"": "URGENTE",

"descric~ao": "tres pecas em retrabalho"

}

Figura 29: Representacao do disparo de um alarme

Suponha que gerente de producao queira ser alarmado todas as vezesque uma peca e depositada no armazem de reprovadas. Pecas podem tersido depositadas no armazem de reprovadas no intervalo de tempo que iniciano instante em que o cliente recebeu a ultima resposta e termina no instante

90

em que o servidor recebe a proxima requisicao. Este caso pode ser cobertoatraves do uso dos cabecalhos HTTP, o cliente indica o instante de tempoem que recebeu o ultimo alarme atraves do cabecalho “If-modified-since”, oservidor por sua vez, ao receber a requisicao, verifica se disparou o alarmeem que o cliente esta interessado entre o instante informado pelo cliente oinstante atual. Caso algum alarme tenha disparado neste intervalo, o instantedo disparo mais recente e enviado na representacao e no cabecalho “Last-modified” da resposta. Ao receber a resposta o cliente utiliza o cabecalho“Last-modified” nela presente para atualizar o cabecalho “If-modified-since”para uma proxima requisicao. Para informar ao cliente de todos os disparosocorridos entre as requisicoes tambem e incluıdo um enlace para o recursode historico de disparos, presente na representacao da figura de exemplo 30atraves do atributo de enlace ”alarmesNaoObtidos”.

{

"instante": "12-07-2011 12:12:01",

"prioridade"": "URGENTE",

"descric~aoDeDisparo": "peca reprovada",

"alarmesN~aoObtidos" :

"/alarme/1/historico/22-07-2011 11:40:19,

22-07-2011:11:42:06"

}

Figura 30: Representacao do disparo de um alarme (quando ocorreram outrosdisparos)

O historico dos disparos de alarme tem por finalidade registrar todosos disparos de um alarme em um dado intervalo de tempo. Este recurso podeinteressar tanto a um cliente que queira saber quais disparos ocorreram entreduas requisicoes, como a um tecnico que precisa fazer uma auditoria ou ava-liar o desempenho da celula. Na figura 31 a representacao do historico de umalarme. Com este historico dos disparos de alarmes estao cobertas as funcio-nalidades tıpicas de SCADA. A tabela 6 resume todos os recursos que foramprojetados, mostrando suas URIs e quais metodos da interface uniforme saoexpostos para cada um deles.

5.1.3 Aspectos de Seguranca e Confiabilidade

A seguranca e uma propriedade indispensavel para SCADA, dado ocarater estrategico que estes sistema possuem. A arquitetura orientada a re-cursos possui mecanismos para prover seguranca para seus usuarios, descritos

91

Rec

urso

UR

IG

ET

POST

PUT

DE

LE

TE

Col

ecao

deco

leto

res

/col

etor

esX

XC

olet

or/c

olet

or/{

id}

XX

XC

olec

aode

vari

avei

s/v

aria

veis

XX

Var

iave

l/v

aria

veis

/{id}

XX

XU

ltim

ale

itura

deum

ava

riav

el/v

aria

veis

/{id}/

ultim

aLei

tura

XH

isto

rico

deum

ava

rıav

el/v

aria

veis

/{id}/

hist

oric

oX

His

tori

code

uma

varı

avel

emum

inte

rval

o/v

aria

veis

/{id}/

hist

oric

o/{i

nter

valo}

XA

larm

es/a

larm

esX

XA

larm

e/a

larm

es/{

id}

XX

XD

ispa

rode

Ala

rme

/ala

rmes

/{id}/

disp

aro

XH

isto

rico

dedi

spar

osde

umal

arm

e/a

larm

es/{

id}/

hist

oric

oX

His

tori

code

disp

aros

deum

alar

me

emum

inte

rval

o/a

larm

es/{

id}/

hist

oric

o/{i

nter

valo}

X

Tabe

la6:

Res

umo

dore

curs

ospr

ojet

ados

92

disparos: [

{ "instante": "22-07-2011 11:42:06,

"prioridade": "INFORMATIVA"},

{ "instante": "22-07-2011 11:42:56,

"prioridade": "INFORMATIVA"}

]

Figura 31: Representacao do historico de disparos de um alarme

em detalhes no capıtulo 3.Na arquitetura proposta optou-se por utilizar HTTPS (com assinatura

digital) e HTTP Basic para prover autenticacao, integridade e confidencia-lidade para os recursos projetados. Para a autorizacao foi desenvolvido umsistema de papeis para a aplicacao da CFM, baseado no modelo RBAC (Role-based access control) (FERRAIOLO; CUGINI; KUHN, 1995).

No modelo RBAC sao designados diferentes papeis para os usuariosdo sistema de uma organizacao, sendo que cada papel possui permissoes dis-tintas para realizar operacoes sobre os objetos do sistema. Em organizacoesindustriais novos usuarios podem ser contratados, demitidos e trocarem defuncao, desta forma o modelo RBAC traz a flexibilidade necessaria para queas aplicacoes SCADA se adaptem as este ambiente dinamico (GOLONKA;GONZALEZ-BERGES, 2009).

Os papeis utilizados na arquitetura baseiam-se em um modelo RBACproposto para SCADA em (MAJDALAWIEH; PARISI-PRESICCE; SANDHU,2007), adaptado para a granularidade dos recursos. Nesta adaptacao os recur-sos sao mapeados para os objetos do modelo RBAC, desta forma os papeis deusuarios possuem permissoes distintas em relacao as operacoes possıveis nosrecursos.

Foram definidos cinco papeis com diferentes permissoes. O papel deoperador esta associado a visualizacao da IHM, portanto possui permissao deleitura a todos os recursos. O supervisor representa o papel de um operadorcom permissao de realizar acoes de controle e configurar alarmes. Ao papelde tecnico sao atribuıdas as operacoes de configuracao. O usuario externorepresenta o papel de um sistema externo interagindo com os recursos deum SCADA, possuindo permissao de leitura a todos os recursos. O gerentepossui autorizacao total para realizar qualquer operacao em qualquer recurso.Esta hierarquia de papeis pode ser visualizada na figura 32.

Para que modelo acima funcione e necessario que o gerente do SCADApossa criar novos usuarios, remover usuarios existentes ou atualizar o papelde um usuario que trocou de funcao. Para isto foram projetados novos re-cursos. O recurso da colecao de usuarios permite que o gerente crie novos

93

Recurso GET POST PUT DELETEUsuarios X X

Um usuario X X X

Tabela 7: Interface dos recursos de usuarios

usuarios atraves de uma requisicao POST. O recurso de usuario permite queo administrador atualize o papel deste usuario ou o remova do sistema. Estesrecursos estao descritos na tabela 7, juntamente com as operacoes que nelespodem ser realizadas.

A tabela 8 sintetiza as permissoes que cada papel possui em relacaoaos recursos projetados. Nela cada recurso e listado em uma linha, sendoque nas colunas sao especificadas as operacoes que podem ser realizadas norecurso. Os papeis que podem realizar as operacoes sao especificados nascelulas, atraves da inicial do nome do papel. Por exemplo em todas as celulasonde esta presente a letra ”O” significa que a operacao da coluna pode serrealizada no recurso especificado na linha pelo papel de Operador.

Figura 32: Hierarquia de papeis para aplicacoes tıpicas SCADA

A confiabilidade e muitas vezes ressaltada em SCADA devido ao usodestes sistemas em aplicacoes de missao crıtica que requerem alta disponibi-lidade. Embora nao tenha sido tratado na arquitetura projetada, nao existe

94

Recurso GET POST PUT DELETEColecao de coletores G,T,S,O,E G,T

Coletor G,T,S,O,E G,T G,TVariaveis do processo G,T,S,O,E G,T,S

Uma variavel G,T,S,O,E G,T,S G,T,SUltima leitura de uma variavel G,T,S,O,E

Historico de uma variavel G,T,S,O,EHistorico de variavel em um intervalo G,T,S,O,E

Colecao de alarmes G,T,S,O,E G,T,S,OAlarme G,T,S,O,E G,T,S,O G,T,S,O

Disparo de alarme G,T,S,O,EHistorico de disparos G,T,S,O,E

Historico de disparos em um intervalo G,T,S,O,EUsuarios G GUsuario G G G

Tabela 8: Operacoes autorizadas sobre os recursos

impedimento dentro dos princıpios de arquitetura da Web de se construirum sistema que cumpra com este requisito de forma satisfatoria. O Harc(do ingles, Highly-Available Robust Co-scheduler) por exemplo, permite aalocacao de recursos em Grids atraves de um abordagem orientada a re-cursos(MACLAREN; KEOWN, 2006). Na Web, sistemas como o GoogleAnalytics possuem APIs REST que utilizam o servico Chubby, que atravesde Paxos fornece a confiabilidade necessaria (CHANG et al., 2008).

5.2 Implementacao

5.2.1 Aplicacoes

De forma a exemplificar as vantagens desta arquitetura, foram desen-volvidas duas aplicacoes clientes: uma aplicacao que configura os recursospara a aquisicao de dados da CFM e um sinotico para mostrar o estado atualda mesma. Tais aplicacoes mostram as capacidades de interacao com outrasaplicacoes que a arquitetura proposta possui, assim como seus aspectos desimplicidade e portabilidade.

A aplicacao responsavel pela configuracao dos recursos da celula foiescrita na linguagem Java. Essa aplicacao atua como um cliente, possuindoum conector HTTP que realiza requisicoes POST para o servidor que hos-

95

peda os recursos. As representacoes utilizadas nas requisicoes possuem asinformacoes necessarias para configurar a aquisicao de dados na celula.

O primeiro recurso criado e um recurso de coletor, contendo as confi-guracoes para que o CLP colete os dados atraves do protocolo Modbus RTU.Depois de criado o coletor sao criados os recursos das variaveis do processo,que fornecem informacoes sobre a contagem de pecas aprovadas, reprova-das ou enviadas para retrabalho e tambem sobre os equipamentos presentesna celula (garra, mesa, furadeira, solda e teste de qualidade). Ao final daexecucao do programa, todos os recursos foram criados, e o SCADA estaconfigurado para coletar dados da celula, podendo iniciar seu funcionamento.Esta aplicacao evidencia os aspectos de configuracao da celula, que podemser realizados por qualquer aplicacao que possua um conector HTTP cliente.Outras aplicacoes poderiam ser utilizadas com este proposito, como qualquernavegador Web ou entao uma ferramenta de linha de comando como o cURL.A figura 33 mostra como uma aplicacao qualquer na Web pode configurara CFM, onde cada requisicao POST para criacao dos recursos e atrelada aconfiguracao de um dos dispositivos da celula.

Figura 33: Configuracao dos recursos para a CFM

A outra aplicacao desenvolvida e um sinotico que exibe em uma in-terface grafica o estado atual dos equipamentos da celula, mostrando se estaoligados ou desligados, permitindo acompanhar o estado atual do processo. Aaplicacao foi escrita na linguagem de programacao Telis, desenvolvida peloEdugraf. Telis e uma linguagem e um ambiente de programacao de propositoeducacional, direcionados para o aprendizado da programacao, sendo utili-

96

zada na disciplina introdutoria de programacao do curso de Automacao eSistemas da UFSC (PIERI et al., 2009). Programas escritos em Telis, deno-minados apliques, podem ser executados em qualquer maquina que disponhade um navegador Web com a possibilidade de rodar ”applets”Java.

O sinotico e um aplique Telis que exibe uma foto da celula como ima-gem de fundo e figuras de pequenas lampadas sobre cada equipamento, con-forme pode ser verificado na figura 34. Quando o equipamento esta em ativi-dade a sua lampada fica ligada, e desligada caso contrario. Para implementareste comportamento cada equipamento foi modelado como um ator, entidadecomputacional autonoma com memoria e linha de execucao propria. Cadaator verifica periodicamente se houve uma mudanca de estado no recurso as-sociado a variavel que corresponde ao equipamento, fornecendo a respostagrafica necessaria. Os atores se comunicam com a celula atraves da primitiva”obter”, realizando requisicoes GET na URI recursos de ultima leitura dasvariaveis. Do ponto de vista da performance, o sinotico desenvolvido podeacompanhar o estado da CFM de forma satisfatoria.

O aspecto mais interessante do desenvolvimento desta aplicacao foi aforma simples com o qual foi possıvel interagir com os recursos. Cada lei-tura de variavel pode ser obtida atraves de uma requisicao GET em sua URI.Esta abordagem permite que qualquer aplicacao Web possa interagir comos recursos, dado que a operacao GET e a mais basica operacao do HTTP.Alem disso, qualquer outro recurso na Web pode referenciar as informacoesda CFM atraves de enlaces, que podem ser seguidos por aplicacoes clientes,guardados em cache ou armazenados para interacoes futuras.

5.2.2 Implementacao no Mango M2M

Foi realizada uma implementacao parcial da arquitetura apresentadaanteriormente, com o objetivo de possibilitar que as aplicacoes clientes inte-rajam com os recursos. Para isto foi modificada a arquitetura de um softwarelivre para SCADA.

A escolha de modificar um SCADA existente ao inves de desenvolverum novo teve uma motivacao pragmatica, que foi o aproveitamento de todauma infraestrutura de software fornecida para a aquisicao e armazenamentode dados. O aproveitamento desta infraestrutura possibilitou que o foco dotrabalho fosse direcionado ao projeto dos recursos, evitando que questoes denıvel mais baixo de abstracao (como a implementacao da aquisicao de dadosvia Modbus) se colocassem como problemas. Outra motivacao foi estudara arquitetura de software de um aplicativo SCADA existente e analisar asmodificacoes necessarias para que os recursos pudessem ser implementados.

97

Figura 34: Sinotico da CFM desenvolvido em Telis

O software objeto desta implementacao foi o Mango M2M. O Mangoe definido como um software para “Machine-to-Machine (M2M), controle in-dustrial, SCADA e domotica (automacao residencial)” (SEROTONIN, 2011).No contexto de aplicacoes SCADA ele fornece fornece as funcionalidadestıpicas destes sistemas, tais como aquisicao de dados de dispositivos atravesde protocolos de comunicacao utilizados na automacao industrial (Modbus,DPN3, OPC), historicos, alarmes (chamados de eventos), e uma interfacegrafica dinamica com sinoticos e graficos.

O Mango e ambientado na Web e multiplataforma, sendo que todasas suas funcionalidades podem ser acessadas a partir de um navegador. Estefator influenciou na sua escolha como objeto de estudo, pois se trata de umSCADA moderno, que utiliza tecnologias da Web. Outro fator decisivo na suaescolha e o fato de ser software livre (licenca GNU GPL versao 3.0), tendo seucodigo fonte aberto para modificacoes, tendo recebido diversas contribuicoesde indivıduos e empresas ao longo dos anos de atividade do projeto. O Mangopossui todos os direitos reservados pela Serotonin Software, que durante opresente trabalho acabou por encerrar o projeto do software.

Para estudar a arquitetura de software do Mango foi necessario buscardocumentacao de referencia. Embora nao exista uma documentacao oficialde sua arquitetura de software, foi possıvel encontrar em (JUHASZ, 2009)um documento onde sao descritos alguns aspectos de sua arquitetura. Outrasfontes de referencia foram o sıtio oficial do projeto (SEROTONIN, 2011)

98

e principalmente o proprio codigo fonte do software que e disponibilizadopublicamente.

O Mango M2M possui uma arquitetura de software distribuıda quesegue o estilo cliente-servidor e utiliza o protocolo HTTP para comunicacao.O cliente executa no navegador e tem suas funcionalidades extendidas atravesde codigo movel JavaScript. O codigo do lado do servidor e implementadoem Java atraves da tecnologia de Servlets, que tratam requisicoes HTTP. AsServlets podem executar em diferentes servidores Web, denominados ServletContainers. No caso o Mango e ambientado no servidor Apache Tomcat.Devido aos fatores mencionados o Mango pode ser executado em sistemasque possuam uma maquina virtual Java compatıvel e os requisitos mınimosde hardware exigidos.

A interacao entre cliente e servidor se da atraves de RPC sobre HTTP.Os servicos definidos no servidor sao nitidamente orientados para somentesuprir as necessidades da interface grafica utilizada pelo cliente. O processose inicia com o cliente requisitando as paginas HTML da interface grafica,sendo que cada funcionalidade (historico, sinotico e alarmes) e apresentadaem uma pagina diferente. As paginas possuem nela embutidas o codigo JavaScript responsavel por tratar acoes do usuario e atualizar periodicamente osseus componentes graficos em decorrencia de mudancas de estado no servidor(a chegada de um novo alarme por exemplo). A atualizacao periodica seda atraves de requisicoes HTTP assıncronas, utilizando a tecnica do ”LongPolling”.

Para realizar a interacao entre cliente e servidor o Mango utiliza a bi-blioteca DWR (Direct Web Remoting) (DWR, 2010). O DWR e usado paragerar codigo Java Script para realizar RPC no cliente (navegador) a partir declasses escritas em Java, no lado do servidor. Desta forma o DWR atua comouma ferramenta tıpica de aplicacoes RPC, gerando os stubs do lado do clientee integrando-o aos servicos expostos por uma API ambientada no servidor.As chamadas de procedimento com informacoes como o nome do metodo in-vocado e seus parametros, assim como suas respostas, sao codificadas atravesde Java Script e transportadas embutidas em requisicoes HTTP POST.

Em relacao a seguranca e mencionado ser possıvel configura-lo parafuncionar com SSL, criptografando a comunicacao (SEROTONIN, 2011),embora nenhum exemplo deste uso tenha sido encontrado. O acesso ao sis-tema e protegido atraves de um esquema de autenticacao e autorizacao proprios,implementado atraves sessoes HTTP. Cada usuario que autentica no sistemainicia uma sessao, que e persistida no servidor. No servidor tambem saoarmazenadas informacoes relativas ao ultimo estado do cliente, para que so-mente sejam enviadas as informacoes que ele ainda nao possui no caso dasatualizacoes periodicas. Desta forma fica evidente a manutencao do estado

99

da aplicacao no servidor.Atraves desta analise da arquitetura distribuıda do Mango foi possıvel

encontrar divergencias em relacao ao estilo da Web. Sua arquitetura violaespectos importantes, apesar de seguir um estilo cliente-servidor com HTTP.A interacao atraves de RPC viola o prıncipio da interface uniforme e abusado metodo POST, que deve ser utilizado somente com propositos especificos.Portanto, assim como foi analisado em detalhes no capıtulo 4, o protocoloHTTP nao e utilizado como um protocolo de aplicacao, e sim como um proto-colo de transporte. Outro aspecto esta na manutencao de estado da aplicacaono servidor, prejudicando a escalonabilidade e visibilidade das interacoes.

Descrita a arquitetura distribuıda do Mango, e expostas as suas limita-coes, passa-se agora a uma analise de como essa arquitetura e implementadano componente do servidor. Essa analise tem como objetivo a implementacaoda arquitetura orientada a recursos atraves da modificacao da arquitetura exis-tente.

A arquitetura interna do Mango foi implementada a partir do para-digma orientado a objetos e esta estruturada segundo o padrao de proje-tos MVC (do ingles, Model View Controller) (JUHASZ, 2009). O obje-tivo do MVC e separar as responsabilidades referentes a logica de domıniodas responsabilidades de apresentacao das informacoes. No padrao MVCclassico existem tres tipos de componentes cada qual com suas responsabi-lidades. O modelo e composto por objetos que encapsulam as informacoessobre o domınio de aplicacao. O papel da visao esta na apresentacao destasinformacoes na interface com o usuario. Ja o controle e responsavel por tra-tar as acoes efetuadas pelo usuario, manipulando o modelo e atualizando avisao (FOWLER, 2002). A figura 35 (FOWLER, 2002) ilustra os componen-tes presentes no MVC e como eles se relacionam.

Figura 35: Padrao MVC

100

Um aspecto da separacao de responsabilidades presentes no MVC erelacao de dependencia entre seus componentes. A visao depende do modelomas nao o inverso, o que implica que o modelo pode evoluir de forma in-dependente. Uma das vantagens deste desacoplamento e que a visao podeser alterada sem que o modelo o seja, outro aspecto e a possibilidade deutilizacao de multiplas visoes para um mesmo modelo. O MVC esta presenteno Mango atraves de um modulo do arcabouco de codigo aberto Spring, uti-lizado em aplicacoes Web (SPRING, 2010). Fazendo uma correspondenciacom o padrao MVC temos a visao do Mango como suas paginas web, querepresentam a interface com o usuario. Ja os controladores sao Servlets res-ponsaveis por tratar as requisicoes HTTP efetuadas pelos clientes, escolhendoa visao que deve ser apresentada na resposta e preenchendo-a com dadosoriundos do modelo. A figura 36 (SPRING, 2010) mostra como se da estainteracao entre os componentes MVC no arcabouco Spring.

Figura 36: MVC no arcabouco Spring utilizado pelo Mango M2M

Quando uma requisicao e efetuada pelo navegador ela e tratada peloApache Tomcat, que a direciona para a Servlet do Mango que atua comoum Front Controller (FOWLER, 2002), implementando o padrao de mesmonome. O Front Controller centraliza o processamento das requisicoes e asdireciona para outros controladores (outras Servlets) e retornando a respostapara o cliente. Este redirecionamento e realizado de acordo com o padrao pre-sente na URI. Por exemplo, uma requisicao que contenha em sua URI o ca-minho ”/dwr”e delegada para o controlador responsavel pelo processamentodas chamadas RPC via DWR, enquanto que uma requisicao cuja URI contemo sufixo ”htm”e direcionada para o controlador do Spring, responsavel pelaobtencao das paginas HTML.

O controlador do Spring por sua vez tambem e um Front Controller,

101

delegando as requisicoes para outros controladores de acordo com a paginasolicitada. Cada um destes controladores instancıa os objetos de domınio,obtendo as informacoes necessarias do modelo. Estas informacoes sao en-capsuladas em objetos e repassadas novamente para o Front Controller, quepor sua vez o envia para o componente View Template, que ira escolher avisao requisitada e montar a pagina de acordo com as informacoes recebidas.

O modelo do Mango e estruturado em camadas. A camada do modelodo domınio e composta dos objetos que representam as entidades presentesno sistema. Abaixo da camada dos objetos do domınio esta uma camada deacesso a dados que permite obter e persistir informacoes da base de dadosrelacional (Apache Derby) que o Mango utiliza. Camadas de acesso a dadosem geral oferecem servicos de acesso a fontes de dados para seus clientes,abstraindo destes a forma como estes dados sao acessados (FOWLER, 2002).Este desacoplamento permite que a forma de acesso aos dados possa ser alte-rada sem que a logica do domınio da aplicacao o seja.

A camada de acesso a dados do Mango e composta por objetos queimplementam o padrao de projeto DAO (do ingles, Data Access Object). UmDAO e um objeto que possui uma interface de acesso a dados, tipicamenteoferecendo servicos de criacao, consulta, atualizacao e remocao (CRUD) dosobjetos do domınio (ALUR et al., 2003). No Mango os DAOs sao utiliza-dos em conjunto com o padrao DTO (Data Transfer Objects, na sigla emingles). DTOs sao objetos utilizados para transferir dados entre sistemas ousubsistemas. Os DTOs do Mango sao objetos serializaveis que encapsulaminformacoes referentes a objetos de domınio, e sao utilizados em todas as ca-madas do sistema. Na figura 37 e exposta a arquitetura de software interna aocomponente servidor do Mango.

Encerrada a analise da arquitetura interna do componente servidor doMango passa-se a descricao das modificacoes realizadas para implementaros recursos. O que interessa nesta implementacao e a infraestrutura de soft-ware que o Mango prove para aquisicao e armazenamento de dados. Destaforma as partes de sua arquitetura que estao relacionadas a interface graficanao interessam a esta implementacao. Outra parte que pode ser descartadae o modulo para comunicacao via RPC (DWR) por se tratar de uma aborda-gem de arquitetura distribuıda que difere da arquitetura orientada a recursosprojetada.

Isolando as partes desnecessarias resta um nucleo que contem toda ainfraestrutura de software para aquisicao e armazenamento dos dados. Estenucleo e composto pela parte do modelo, no contexto do padrao MVC e in-clui as camadas do modelo do domınio e acesso aos dados. Por cima destascamadas foi implementada uma camada de recursos, especificada pelo pro-jeto descrito anteriormente. A figura 38 ilustra a arquitetura modificada, com

102

Figura 37: Arquitetura de Software do Mango M2M

a camada de recursos sobre as outras.

Figura 38: Arquitetura de software do Mango M2M modificada

No modelo do domınio estao todas as classes que representam con-ceitos importantes do sistema. No caso alguns conceitos sao fundamentaispara a aquisicao de dados: os Data Sources e Data Points. Os Data Sourcesrepresentam as fontes de informacao, sendo responsaveis por adquirir da-dos do processo. Existem diferentes tipos de Data Sources, cada um delesassociado a um protocolo especıfico de comunicacao, possuindo diferentesparametros de configuracao. Os Data Points por sua vez estao relacionados avariaveis do processo que deseja-se monitorar. Cada Data Point esta associ-ado a configuracoes especıficas do protocolo de seu Data Source, que indicamcomo a informacao pode ser encontrada nos dados adquiridos. Entre os tipos

103

de Data Sources e Data Points estao os para comunicacao Modbus Serial, quesao utilizados na comunicacao com o CLP da celula.

Deste modo, pode-se aproveitar as classes do modelo do domınio as-sociadas aos Data Sources e Data Points para coletar dados do processo efornece-los aos recursos. Em um processo inverso, dados tambem sao aceitospelos recursos e repassados para a camada de acesso aos dados, para per-sistencia. Portanto uma transformacao dos dados tornou-se necessaria, sejado modelo do Mango para as representacoes dos recursos ou entao vice versa.

As requisicoes para os recursos sao tratadas por uma nova Servlet.Quando uma requisicao possui o prefixo ”/recursos”em sua URI ela e dele-gada pelo Front Controller do Mango para esta Servlet. A Servlet tambematua como um Front Controller, escolhendo a classe responsavel por tratara requisicao de acordo com o recurso solicitado. Atraves desta abordagemfoi possıvel “ativar” os recursos em uma instalacao existente do Mango semgrandes esforcos, incluindo a nova Servlet e seu mapeamento de URI naconfiguracao do mesmo. Outro resultado alcancado foi o de ter a implementa-cao da ROA funcionando em paralelo com o Mango de forma harmoniosa.

5.3 Resultados

Os recursos projetados cobriram os requisitos funcionais tıpicos deaplicacoes SCADA. A aquisicao de dados foi proporcionada pelos recursosde coletores e variaveis do processo. As funcoes de historico foram cobertaspelos recursos relacionados ao historico de variaveis coletadas e alarmes. Aconfiguracao de dispositivos, variaveis e alarmes se deu atraves da possibi-lidade de criar, modificar e remover estes recursos. O controle em nıvel desupervisao foi associado a modificacao do estado dos recursos de variaveis.Ja a IHM foi delegada aos clientes, dentro do princıpio da separacao de res-ponsabilidades.

O recurso do disparo do alarme possibilitou que clientes possam sernotificados da ocorrencia de situacoes incomuns no processo. E necessarioobservar que a tecnica do “Long Polling” empregada necessita que uma co-nexao HTTP persistente seja mantida enquanto o alarme nao for disparado.Os navegadores possuem um limite configuravel no numero de conexoesque podem manter com cada domınio, portanto pode ser necessario que estenumero de conexoes seja aumentado dependendo do numero de alarmes queo cliente deseja esperar que disparem. Dependendo da forma como sao ge-renciadas estas conexoes persistentes pelo servidor este pode se tornar umproblema de escala. Esta abordagem para os alarmes possui a limitacao ca-racterıstica do “polling”, que e a defesagem entre a ocorrencia do evento, e

104

seu conhecimento por parte dos interessados (BOZDAG; MESBAH; DEUR-SEN, 2007). Estilos arquiteturais baseados em eventos, como o Publish-Subscribe (EUGSTER et al., 2003) possivelmente se adaptem melhor a natu-reza dos alarmes, ficando seu estudo como uma ideia para trabalhos futuros.

A abordagem para possibilitar a aquisicao de dados da estacao remota(CLP) foi encapsular a comunicacao com o mesma na estacao mestre. Aestacao mestre atuou como um gateway para se comunicar com a estacaoremota. Espera-se que seja possıvel aplicar a mesma abordagem em outrosaplicacoes de SCADA, dado que as estacoes remotas geralmente possuem re-cursos de hardware limitados e utilizam protocolos industriais incompatıveiscom a Web.

Os requisitos nao funcionais tıpicos de SCADA sao contemplados pelaarquitetura. A interoperabilidade e favorecida atraves do uso de tecnologiasabertas da Web, como o protocolo HTTP, URI e tipos de mıdia. O princıpioda interface uniforme tambem favorece esta propriedade no contexto da Web,pois possibilita que aplicacoes interajam com a arquitetura de uma forma pa-dronizada e condizente com a especificacao do HTTP. A possibilidade deexistencia de diversos tipos de mıdia nas representacoes dos recursos tambemtraz flexibilidade, no sentido de permitir que as necessidades de diferentes cli-entes possam ser satisfeitas.

A arquitetura e portavel, pois pode ser executada em diferentes ambi-entes de hardware e software, sob a condicao de que suportem as tecnologiasda Web. Este requisito foi evidenciado na implementacao que utiliza um am-biente de execucao multiplataforma.

A escalonabilidade e favorecida pelo fato de a arquitetura estar em-basada nos estilos arquiteturais que fundamentam a Web (cliente com cache,servidor sem-estado). Caches compartilhadas, previstas pelo estilo de siste-mas em camadas tambem podem ser facilmente incorporados a arquitetura,fator que tambem contribui para a escalonabilidade.

Atraves da implementacao foram desenvolvidas aplicacoes clientespara interagir com os recursos. Estas aplicacoes possibilitaram a configuracaodo CLP utilizado para aquisicao de dados e a exibicao de um sinotico em umnavegador. Os experimentos evidenciaram a interoperabilidade, portabilidadee simplicidade da arquitetura projetada.

A seguranca, mencionada frequentemente na literatura sobre SCADA,foi coberta atraves do HTTPS, combinado com autenticacao HTTP Basice do modelo RBAC para autorizacao. Uma limitacao da abordagem paraseguranca e que o HTTPS garante somente a comunicacao segura ponto aponto entre os componentes. Este fato tras algumas implicacoes dada a na-tureza em camadas da Web. Um cliente que quiser se comunicar com umservidor e tiver que passar por componentes intermediarios, nao tem outra al-

105

ternativa a nao ser confiar nos intermediarios. Isto pode causar problemas, porexemplo um proxy malicioso poderia ao receber uma requisicao via conexaosegura, repassa-la para um componente nao autorizado.

Mecanismos de tolerancia a faltas para garantir a confiabilidade daarquitetura nao foram implementados, devido ao escopo deste trabalho. Con-tudo foi possıvel mostrar atraves de algumas referencias bibliograficas queeste requisito pode ser cumprido dentro dos princıpios arquiteturais da Web.Com relacao ao tempo-real, a arquitetura projetada nao e apropriada para pro-cessos que apresentam este requisito devido a natureza nao-determinıstica daInternet.

A implementacao contribuiu para mostrar como e estruturada a arqui-tetura de software de um SCADA existente para a Web. O Mango M2M,aplicativo objeto do estudo, possui escassa documentacao no que se refere asua arquitetura, portanto a analise que foi realizada pode ser utilizada por de-senvolvedores interessados no sistema. Outro ponto que pode ser destacado,foi a abordagem de realizar modificacoes na arquitetura do Mango para queos recursos pudessem ser implementados, aproveitando toda a infraestruturafornecida para a aquisicao e armazenamento dos dados.


Neste capıtulo foi apresentada a proposta de ROA para aplicacoestıpicas de SCADA, mostrando como os requisitos destas aplicacoes podemser atendidos dentro dos princıpios arquiteturais que fundamentam a Web.Primeiramente foi exposta uma visao geral da arquitetura, onde foram iden-tificados os componentes presentes nas aplicacoes SCADA e como estes po-dem ser mapeados para os componentes encontrados na Web. Em seguidafoi realizado o projeto dos recursos, com base na metodologia ROA, mos-trando como as funcionalidades tıpicas de SCADA sao cumpridas. Com oobjetivo de expor algumas propriedades foi realizada uma implementacao,que possibilitou que fossem desenvolvidas aplicacoes que interagem com osrecursos projetados. No final do capıtulo foram apresentados alguns dos re-sultados extraıdos da arquitetura. No capıtulo seguinte a arquitetura projetadasera comparada com uma arquitetura existente, buscando mostrar algumascontribuicoes e limitacoes do trabalho.

107

6 Estudo Comparativo de Arquiteturas parauma Aplicacao SCADA na Web

Neste capıtulo e feito um estudo comparativo entre duas arquiteturasde software para uma aplicacao SCADA na Web. Primeiramente e apresen-tada a aplicacao SCADA, o processo de transferencia de um lıquido entre tan-ques. Em seguida sao descritas duas arquiteturas que modelam esta aplicacao,uma baseada em Web Services RPC e a arquitetura ROA descrita no capıtuloanterior. As duas abordagens sao entao analisadas e comparadas com basenos requisitos tıpicos de aplicacoes SCADA e no quao integradas elas saocom a Web. O capıtulo e concluıdo com os resultados desta analise.

6.1 A Aplicacao SCADA dos Tanques

Uma analise do uso combinado das tecnologias Java, XML para fa-vorecer requisitos de portabilidade, performance e interoperabilidade de sis-temas SCADA na Web e feita em (FAN; CHEDED; TOKER, 2005). Nessetrabalho e apresentado um exemplo de aplicacao SCADA integrada com aWeb, o processo de transferencia de um lıquido entre tanques.

A transferencia acontece de uma planta de origem para uma planta dedestino. A planta de origem possui um tanque e uma bomba, que e utili-zada para retirar o liquido deste tanque enviando-o atraves de um duto paraa planta de destino. A planta de destino possui um tanque de compensacaopara lidar com variacoes de pressao e um tanque de recepcao, onde o liquidoe depositado. A central de transferencia e responsavel por realizar pedidos detransferencia e pela supervisao de todo processo. As plantas de envio e rece-bimento gerenciam os pedidos, e realizam a transferencia atraves do controlede seus equipamentos (valvulas e bombas). O processo e supervisionado porum operador em uma central de transferencias e por operadores nas plantasde origem e recepcao.

Cada operador possui um papel, exercendo diferentes funcionalidadesconforme pode ser observado no diagrama de casos de uso da figura 39 (FAN;CHEDED; TOKER, 2005). O operador na central de transferencias podecriar pedidos de transferencia com um determinado volume e monitorar oprocesso. O operador da planta de envio pode iniciar, supervisionar ou pararum envio assim que o volume requisitado tiver sido transferido. Ao operadorna central de recebimento cabe preparar a planta para o recebimento, iniciareste processo, supervisiona-lo e encerra-lo.

108

A interacao entre os operadores e as plantas de envio e recebimentoe tıpica de aplicacoes SCADA. Nessa interacao os operadores monitoram oestado dos equipamentos (valvulas, tanques e bomba) e efetuam acoes decontrole sobre eles para coordenar a transferencia entre os tanques. O papeldo operador na central de transferencia e o de criar pedidos de transferencia,uma funcionalidade tıpica de aplicacoes MES (MESA, 1997), pois trata-se deuma acao de planejamento que sera executada pelos operadores do SCADAnas plantas.

Figura 39: Caso de uso envolvendo os operadores das plantas

6.2 Arquitetura de Web Services Baseada em RPC

Na arquitetura proposta em (FAN; CHEDED; TOKER, 2005) a aplicacaodos tanques e dividida em componentes de transferencia, envio e recepcao.Os componentes estao localizados em diferentes nos de uma rede conformeilustrado na figura 40 (FAN; CHEDED; TOKER, 2004). A interacao entre oscomponentes acontece atraves da troca de mensagens utilizando o protocolo

109

HTTP. Tambem e possıvel verificar a partir da figura que os componentes deenvio e recebimento interagem localmente com os equipamentos em suas res-pectivas plantas, implementando a transferencia do lıquido entre os tanques.

Figura 40: Interacao entre plantas e central

Os componentes sao organizados no estilo cliente-servidor, onde tresclientes se comunicam com tres servidores, correspondentes a central de trans-ferencia e as plantas de envio e recebimento. A interacao entre clientes eservidores se da atraves de conectores RPC, que trocam mensagens SOAPtransportadas atraves do protocolo HTTP. A IHM e apresentada nos navega-dores dos operadores atraves de codigo movel (Applets Java) baixado dosservidores. A figura 41 ilustra os componentes e conectores da arquite-tura. Analisando as restricoes arquiteturais empregadas podemos classificaresta arquitetura como possuindo um estilo cliente-servidor sem-estado comcodigo movel.

O diagrama de componentes da figura 42 (FAN; CHEDED; TOKER,2004) apresenta um nıvel mais baixo de abstracao da arquitetura, mostrandocomo os componentes sao implementados. Os componentes Dispatching,Shipping e Receiving representam respectivamente os componentes de trans-ferencia, envio e recepcao. Os componentes DispatchingBusinessWebSer-vice, ShippingBusinessWebService e ReceivingBusinessWebService sao res-ponsaveis pelos envio e recebimento dos pedidos de transferencia. O com-

110

Figura 41: Arquitetura em nıvel de rede para o problema dos tanques

ponente DispatchingControlWebService e responsavel pelo monitoramentodo processo de transferencia na central. Ja os componentes ShippingCon-trolWebService e ReceivingControlWebService realizam o processo envio erecebimento respectivamente, efetuando o controle dos equipamentos (bombae valvulas dos tanques).

Nesta interacao baseada em RPC cada componente possui dois conec-tores, um cliente e um servidor, podendo receber chamadas remotas de pro-cedimento e tambem realiza-las. Observando o componente ShippingCon-trolWebService e possivel visualizar como se da esta comunicacao com osdemais componentes. Para se comunicar com os componentes Dispatching-ControlWebService e ReceivingControlWebService ele utiliza dois conecto-res clientes, o ProxyReceivingControlWS e o ProxyShippingControlWS, querealizam as chamadas de procedimento remotas para estes componentes. Parareceber as chamadas ele utiliza um conector de servidor, chamado de In-terfaceDispatchingControlWS. Estes conectores sao os stubs que provem aimplementacao necessaria para a comunicacao atraves da rede e interpretacaodas mensagens SOAP.

A modelagem orientada a objetos do sistema pode ser vista no di-agrama de classes da figura 43 (FAN; CHEDED; TOKER, 2004). Os com-ponentes DispatchingControlWebService, ShippingControlWebService e Re-ceivingControlWebService sao objetos da classe ControlWebService. Parasupervisionar e controlar os equipamentos eles trocam mensagens locais comobjetos das classes Pump e Tank, que fazem interface com a bomba e o tanque

111

Figura 42: Diagrama de componentes da arquitetura

respectivamente. O processo de monitoramento nas plantas acontece atravesda varredura cıclica do estado dos equipamentos (mensagens para os obje-tos das classes pump e tanque) que e realizada pelos objetos da classe Con-trolWebService. Assim que ocorrem atualizacoes estes objetos avisam o na-vegador atraves de chamadas remotas do procedimento updateHMI.

6.3 Arquitetura Orientada a Recursos para Aplicacoes Tıpicas de SCADA

Passa-se agora para a modelagem da aplicacao dos tanques utilizandoa arquitetura ROA para aplicacoes tıpicas de SCADA descrita no capıtuloanterior. Nesta linha a arquitetura da aplicacao dos tanques pode ser definidacomo uma configuracao especıfica da arquitetura geral para aplicacoes tıpicasde SCADA da figura 18, ou seja, um arranjo de seus componente, conectorese dados.

Na arquitetura as plantas podem assumir o papel de servidores de ori-gem, que expoe recursos com os quais os operadores interagem atraves dos

112

Figura 43: Diagrama de classes do sistema dos tanques

seus agentes de usuario (navegadores). A aplicacao MES que gerencia ospedidos de transferencia e incluıda como outro agente de usuario interessadonos recursos oferecidos pelas plantas. Como ultimo detalhe, para favorecera escalonabilidade e performance do sistema e incluıda uma cache comparti-lhada entre os clientes. A figura 44 ilustra a arquitetura proposta.

Definidos os componentes e conectores, passa-se agora para a selecaodos recursos que irao cobrir as funcionalidades da aplicacao. Os dispositivosde campo utilizados para adquirir dados e controlar as valvulas e a bombaforam modelados como coletores, o que permite que suas configuracoes deaquisicao possam ser lidas ou alteradas atraves da Web. Os equipamentos nasplantas (valvulas e bomba) foram modelados como variaveis do processo, oque torna possıvel a realizacao de operacoes de controle sobre os equipamen-tos, como abrir e fechar uma valvula ou ativar e desativar o funcionamentoda bomba. As informacoes do nıvel e volume dos tanques tambem sao mode-ladas como variaveis do processo, desta forma e possıvel consultar a ultimaleitura e historico destas informacoes. O mapeamento entre os equipamentos

113

Figura 44: Arquitetura ROA para a aplicacao dos tanques

Recurso URIDispositivo de aquisicao da planta de envio /coletor/rtu

Volume do tanque de envio /variavel/volumeDoTanqueNıvel do tanque de envio /variavel/nivelDoTanque

Valvula de saıda /variavel/valvulaDeSaidaBomba /variavel/bomba

Tabela 9: Recursos da planta de envio

das plantas de envio e recebimento e os recursos pode ser visto nas tabelas 9e 10.

O processo de criacao dos recursos dos coletores e das variaveis paraesta aplicacao e realizado pelos navegadores dos operadores das plantas, querealizam requisicoes POST para os servidores que hospedam os recursos. Asrepresentacoes utilizadas nas requisicoes possuem as informacoes necessariaspara criacao dos recursos. Os primeiros recursos criados sao os dos coletores,depois sao criados os recursos das variaveis para os equipamentos e dadossobre os tanques. A sequencia de operacoes para criacao dos recursos podeser vista na figura 45.

A interacao entre as plantas e a central de transferencias se da atravesdos pedidos de transferencias. Um operador na central de transferencias podecriar um pedido de transferencia, solicitando que um volume seja transferidoda planta de envio para a planta de recebimento. O operador pode monitorar oestado deste pedido para saber quando o mesmo foi concluıdo. Os operadoresdas plantas por sua vez monitoram o ultimo pedido feito na central de trans-

114

Recurso URIRTU da planta de recebimento /coletor/rtu

Volume do tanque de recebimento /variavel/volumeDoTanque1Nıvel do tanque de recebimento /variavel/nivelDoTanque1

Valvula de entrada do tanque de recebimento /variavel/valvulaDeEntradaDoTanque1Volume do tanque de compensacao /variavel/volumeDoTanque2Nıvel do tanque de compensacao /variavel/nivelDoTanque2

Valvula de entrada do tanque de compensacao /variavel/valvulaDeEntradaDoTanque2

Tabela 10: Recursos da planta de recebimento

Figura 45: Sequencia de operacoes nos recursos para configuracao do pro-cesso

115

ferencia, e quando existe um novo pedido interagem para que a transferenciaseja realizada.

A arquitetura ROA para aplicacoes tıpicas de SCADA nao possui ne-nhum recurso que se encaixe com o conceito dos pedidos de transferencia,como exposto anteriormente este conceito esta relacionado com aplicacoestıpicas MES, e portanto fora do escopo deste trabalho. Entretanto para de-monstrar como se da uma integracao MES/SCADA nesta arquitetura iremosprojetar um recurso que serve como ponte entre os dois sistemas. Para istofoi projetado o recurso que representa um pedido de transferencia feito pelocliente MES para o SCADA. Este pedido pode ser criado atraves de umarequisicao PUT, pois o cliente tem o controle da URI onde o recurso e criado.A figura 46 ilustra como o cliente MES pode criar o pedido de transferenciaenviando as requisicoes PUT para os servidores localizados nas plantas.

Figura 46: Criacao de pedido de transferencia solicitada pelo cliente MES

Depois de criado, um pedido pode ter o seu estado atualizado. So-mente uma transferencia pode ocorrer ao mesmo tempo, por isto qualquertentativa de criar um novo pedido enquanto o pedido atual ainda nao foiconcluıdo ocasionara em um erro. O recurso do pedido atual, sua URI eas operacoes que podem ser realizadas nele podem ser vistos na tabela 11. Arepresentacao do recurso do pedido de transferencia possui como informacoeso instante de sua criacao, o volume requisitado para transferencia, um estado(novo, em andamento, parado e completo) e o instante da ultima transicao de

116

Recurso URI GET POST PUT DELETEPedido de transferencia atual /pedidoAtual X X

Tabela 11: Recurso de pedido do transferencia atual

estado, conforme pode ser visto na figura 47.

{

"iniciado": "31-07-2011 23:04:02",

"volumeRequisitado": "50",

"estado": novo,

"ultimaAlterac~ao": "31-07-2011 23:04:02",

}

Figura 47: Representacao do pedido de transferencia atual

Os clientes das plantas e da central monitoram o estado do pedidode transferencia atual e dos equipamentos atraves de sucessivas requisicoesGET nos recursos associados. As informacoes obtidas das representacoes dosrecursos podem ser utilizadas para montar um sinotico, que reflete o estadoatual da transferencia para os operadores. O processo de monitoramento,incluindo uma sequencia de operacoes GET nos recursos e exibido na figura48. A possibilidade de uso de codigo movel (Applets ou Javascript) permitea construcao de interfaces graficas dinamicas atraves do uso de requisicoesHTTP assıncronas.

O processo de transferencia ocorre da seguinte forma: os operadoresnas plantas monitoram o recurso do pedido de transferencia atual, verificandose este e um novo pedido, se sim, eles iniciam o processo de transferencia.Quando o operador na planta de recebimento descobre o novo pedido, eleabre a valvula de entrada do seu tanque de recebimento, atualiza o estado dopedido de transferencia sinalizando que o mesmo esta em andamento e criaum alarme que ira disparar quando o operador de envio fechar sua valvula,ou seja quando a transferencia for finalizada. Ao descobrir que a valvulana planta de recebimento esta aberta o operador na planta de envio obtema ultima leitura do volume do tanque da planta de recebimento, criando umalarme que ira disparar quando o volume do tanque da planta de recebimentoatingir o esperado, notificando-o da necessidade de encerrar a transferencia.Depois de criar o alarme ele abre a valvula de saıda do seu tanque, iniciao funcionamento da bomba e atualiza o estado do pedido de transferencia,sinalizando o seu andamento. A figura 49 ilustra como se da este processo

117

Figura 48: Sequencia de operacoes nos recursos para monitoramento de umatransferencia

atraves da sequencia de operacoes nos recursos.A transferencia pode ser parada pelo operador na planta de envio. Para

parar uma transferencia o operador na planta de envio sinaliza o fechamentoda valvula de saıda do tanque e a interrupcao do funcionamento da bomba.Esta sequencia de operacoes e ilustrada pela figura 50.

Quando o volume requisitado no pedido de transferencia e atingido,o operador na planta de envio deve parar de transferir. Esta situacao ocorreatraves do disparo do alarme criado pelo operador da planta de envio, quesinaliza que o tanque na planta de recebimento esta com o volume solici-tado. Ao receber este alarme o operador na planta de envio solicita que atransferencia pare, e ao receber a confirmacao de que a transferencia parouo operador na central de recebimento pode dar a transferencia como encer-rada, fechando a valvula de entrada do tanque e atualizando o pedido atual,marcando-o como completo. Esta sequencia de operacoes e ilustrada pelafigura 51.

Finalizada a descricao de como os recursos projetados cobrem os re-quisitos funcionais da aplicacao do tanques, passa-se agora para uma analisecomparativa das arquiteturas. Esta analise busca explicitar as diferencas ar-quiteturais entre elas, mostrando o impacto destas diferencas em relacao aos

118

Figura 49: Sequencia de operacoes nos recursos para realizar uma trans-ferencia

requisitos tıpicos de SCADA e integracao com a Web. A fundamentacaodesta analise esta presente no capıtulo 4 onde sao analisados os aspectos deintegracao com a Web das arquiteturas baseadas em RPC.

119

Figura 50: Sequencia de operacoes nos recursos para parar uma transferencia

Figura 51: Sequencia de operacoes nos recursos para finalizar uma trans-ferencia

6.4 Analise Comparativa das Arquiteturas

As arquiteturas apresentadas possuem algumas semelhancas, pois com-partilham um estilo arquitetural cliente-servidor sem-estado com codigo movel.Ambas se comunicam atraves do HTTP e utilizam URI para identificar os

120

destinos das requisicoes (sejam servicos ou recursos). Entretanto a arquite-tura ROA difere da arquitetura de Web Services RPC pois possui interfaceuniforme, cache e sistema em camadas.

A restricao da interface uniforme torna as duas abordagens diferentesem termos de modelagem. Na abordagem de Web Services RPC cada com-ponente servidor expoe uma serie de procedimentos (startShipping, stopShip-ping, startReceiving. . . ) que podem ser invocados pelos clientes. Alguns des-tes procedimentos recebem como parametros objetos do modelo do domınioda aplicacao. A interacao entre os componentes se da atraves de envelopesSOAP, transportados atraves do protocolo HTTP. Desta forma os metodosHTTP utilizados nas requisicoes pouco importam, pois a semantica das opera-coes efetuadas esta descrita no conteudo dos envelopes.

Na ROA cada recurso e exposto no servidor atraves de sua URI. Cli-entes interessados em acessar ou manipular um recurso podem escolher entreum conjunto limitado de operacoes do HTTP, cada qual com uma semanticadefinida pelo protocolo. A troca de dados entre cliente e servidor se daatraves de representacoes de recursos, e o cliente pode explorar outros recur-sos atraves da navegacao pelos enlaces presentes nestas representacoes. Estadinamica de interacao entre os componentes, que envolve a identificacao derecursos por URIs, manipulacao de recursos atraves de representacoes, men-sagens auto-descritivas e hipermıdia e o que lhe confere a interface uniforme.Como consequencia de sua interface uniforme a ROA consegue desfrutar deuma maior integracao com a Web, conforme foi levantado no capıtulo 4, econforme sera exemplificado a seguir.

6.4.1 Integracao com a Web

Um ponto que distingue as arquiteturas quanto a sua integracao com aWeb e a possibilidade de utilizar cache e componentes intermediarios. Casoas informacoes da aplicacao dos tanques fossem disponibilizadas publica-mente na Web, poderiam haver problemas relacionados a escalonabilidadese aumentasse muito o numero de clientes ou se ocorressem fenomenos desobrecarga transiente. A ROA pode lidar com esses problemas atraves dosmecanismos de cache presentes no HTTP. Para isto, alem dos conectoresde cache dos clientes e servidores, podem ser utilizados componentes inter-mediarios atuando como caches compartilhadas entre diferentes clientes.

Como as mensagens sao auto-descritivas os componentes intermedia-rios tem como saber a semantica de cada operacao realizada, fazendo quea cache funcione corretamente. Desta forma respostas para operacoes se-guras (FIELDING et al., 1999) como o metodo GET podem ser guardadas

121

em cache e enviadas aos clientes caso o recurso nao tenha sido atualizado(o que pode ser verificado atraves dos cabecalhos HTTP), melhorando a per-formance percebida pelo usuario e a escalonabilidade. Ja as operacoes naoseguras (PUT, POST e DELETE) que alteram o estado dos recursos, tem seuefeito esperado, invalidando qualquer resposta guardada em cache para o re-curso em questao. Mais caches podem ser adicionadas na medida que cresceo numero de clientes interessados nos recursos.

O problema da abordagem de Web Services RPC e que suas mensa-gens nao podem ser totalmente compreendidas pelas caches e intermediariosem geral como proxies e gateways. Por nao existir uma interface uniforme, oscomponentes intermediarios teriam que se valer de informacoes externas aoprotocolo HTTP e especıficas da aplicacao em questao para decidir o efeitodas mensagens. Seria necessario por exemplo que uma cache compartilhadasoubesse qual e a semantica dos procedimentos startShipping, stopShippinge updateHMI e se estes sao seguros ou nao, para que possa decidir se umaresposta pode ser guardada em cache, ou mesmo para determinar se estesprocedimentos invalidam respostas na cache.

A existencia de enlaces nas representacoes tambem e um diferencialda ROA, pois permite que os recursos da aplicacao possam ser integrados deforma trivial a outros recursos da Web. Os enlaces permitem que qualquer cli-ente da Web possa vir a descobrir um enlace para a aplicacao, explorando-aincrementalmente atraves da navegacao pelos enlaces subsequentes. Na abor-dagem de Web Services RPC nao existem estas ligacoes entre os servicos, deforma que o cliente precisa conhecer a priori a interface e endereco do servi-dor, assim como a ordem correta das operacoes que deseja realizar.

Outro ponto e a questao da evolucao independente, um dos requisi-tos da Web. Na abordagem de Web Services RPC os componentes neces-sitam compartilhar uma infraestrutura de software (os stubs) especıfica decada aplicacao para que possam ser comunicar. Por exemplo, para que ocomponente shippingControlWS possa se comunicar com o componente re-ceivingControlWS ele depende do stub proxyReceivingControlWS, que atuacomo um conector cliente, enviando chamadas remotas para o conector servi-dor do componente receivingControlWS. Como e possıvel notar as interfacesdos componentes estao intrinsecamente ligadas, sendo necessario que cadacliente possua um conector especıfico para se comunicar com cada servidor.

Esta dependencia introduz um forte acoplamento na arquitetura. Mu-dancas na interface dos componentes muitas vezes tornam necessario que osstubs sejam gerados e publicados novamente para que seja mantida a compa-tibilidade. O custo deste acoplamento cresce com o numero de componentesenvolvidos, comprometendo a evolucao independente. Alem disso na Web oscomponentes podem estar sob domınio de organizacoes diferentes, tornando

122

o controle destas mudancas problematico.Outro aspecto do acoplamento esta no compartilhamento de um mo-

delo de dados comum. Na arquitetura de Web Services isto e visıvel atravesda troca de objetos da classe Order entre os componentes. Para realizar estatroca, os objetos desta classe sao codificados em documentos XML, sendo no-vamente transformados em objetos assim que recebidos pelos stubs de seusdestinatarios. Desta forma mudancas no modelo de dados devem ser refleti-das em todos os componentes que compartilham objetos desta classe, assimcomo nos stubs que realizam a conversao/desconversao destes objetos em do-cumentos XML.

Na ROA os componentes nao estao acoplados a uma infraestrutura desoftware especıfica da aplicacao para que possam se comunicar. A comunica-cao entre os componentes se da atraves de conectores HTTP genericos. Istoimplica que qualquer cliente dotado de um conector HTTP (qualquer nave-gador por exemplo) pode usufruir dos recursos das plantas, ou de qualqueroutro servidor da Web, nao sendo necessaria recompilacao ou instalacao demodulo adicional.

Tambem nao existe a dependencia de um modelo de dados compar-tilhado ou de um formato de dados especıfico como o XML, dado que osclientes podem escolher diferentes representacoes para o mesmo recurso, eprocessa-las atraves de bibliotecas existentes para o tipo de mıdia escolhido.Neste caso o fraco acoplamento da arquitetura traz vantagens quando se tratade um ambiente heterogeneo como e o da Web, onde existem clientes comdiferentes necessidades e em evolucao constante.

A desvantagem da interface uniforme e que ela pode degradar a eficien-cia, pois as informacoes sao transferidas de forma padronizada ao inves deespecificamente para as necessidades de cada aplicacao (FIELDING, 2000).Na aplicacao dos tanques este aspecto fica claro quando sao utilizadas asoperacoes PUT, sendo necessario enviar na representacao o estado completodo recurso que se deseja atualizar. Na abordagem RPC as atualizacoes saoefetuadas por procedimentos como startShipping que atualizam o estado doservidor sem que sejam enviados parametros de atualizacao na requisicao.

Outro ponto esta no numero de requisicoes efetuadas para se cumprircom determinada funcionalidade, que foi maior na arquitetura ROA. Contudoeste fato esta mais relacionado com a granularidade dos recursos da modela-gem proposta do que com a interface uniforme propriamente dita.

As diferencas entre as arquiteturas quanto a sua integracao com a Webestao sintetizadas na tabela 12, onde podem ser vistos quais aspectos da Websao aproveitados por cada uma delas. Na tabela e possıvel verificar que arqui-teturas de Web Services RPC se aproveitam parcialmente das caracterısticasda Web, utilizando-a basicamente para o transporte de suas mensagens. Por

123

Aspecto da Web Web Services RPC ROAHTTP X XURI X X

Tipos de mıdia XComponentes intermediarios X

Enlaces XCache X

Tabela 12: Comparacao entre as arquiteturas com relacao a integracao com aWeb

outro lado a ROA consegue se aproveitar da Web como o um todo, pois elafoi projetada com base nos mesmos princıpios de arquitetura.

6.4.2 Requisitos nao-funcionais de SCADA

Conforme foi possıvel observar existem diferencas entre as duas abor-dagens que impactam na forma na qual elas se integram com a Web. Contudo,e importante direcionar esta analise para que possamos comparar as arqui-teturas em relacao aos requisitos tıpicos de SCADA, expostos no capıtulo2. Como a arquitetura de Web Services RPC nao foi implementada, nao foipossıvel realizar experimentos que a comparem com a ROA no cumprimentodos requisitos funcionais tıpicos de SCADA. Portanto a analise sera feita so-mente com relacao aos requisitos nao-funcionais, ou seja: interoperabilidade,portabilidade, escalonabilidade, confiabilidade e seguranca.

Ambas as arquiteturas usam o protocolo HTTP para a troca de mensa-gens alem de permitirem a utilizacao de formatos de dados independentes deplataforma como o XML. Portanto ambas as arquiteturas sao independentesde plataforma especıfica e possibilitam que aplicacoes em plataformas hete-rogeneas interajam, sendo equivalentes nos quesitos de interoperabilidade eportabilidade.

Com relacao a escalonabilidade a arquitetura ROA e favorecida pelosestilos arquiteturais da Web. Os servidores nao necessitam armazenar estadoentre multiplas requisicoes, facilitando a liberacao de recursos. Conectores decache podem ser utilizados por clientes e servidores, diminuindo o numero deinteracoes com a rede. Alem disso, caches compartilhadas podem ser facil-mente incorporadas para lidar com o aumento no numero de clientes ou pro-blemas de sobrecarga transiente. Ja a arquitetura de Web Services RPC naopossui uma interface uniforme, o que dificulta o processamento de suas men-

124

sagens pelos conectores de cache e componentes intermediarios, conformefoi descrito anteriormente.

A seguranca da arquitetura ROA foi coberta atraves do HTTPS, com-binado com autenticacao HTTP Basic e um sistema de papeis para autorizacao.Estes mecanismos possibilitam que as propriedades de disponibilidade, con-fidencialidade, integridade possam ser cumpridas pela arquitetura. Uma li-mitacao desta abordagem e que o HTTPS garante somente a comunicacaosegura ponto a ponto entre os componentes. Esta limitacao implica que cli-entes e servidores precisam confiar nos componentes intermediarios para queestes possam atuar.

Na abordagem de Web Services RPC proposta por (FAN; CHEDED;TOKER, 2005) as tecnologias da Web (como o SSL) sao citadas como solucaopara o requisito de seguranca. O SSL e um dos protocolos de transporte se-guros que podem ser utilizados com o HTTPS, sendo portanto a abordagemequivalente em termos de seguranca. Contudo, dentro da mesma linha deWeb Services adotada pelo autor existe a especificacao WS-Security, quepermite seguranca fim-a-fim para as mensagens. Desta forma, utilizandoWS-Security podem existir intermediarios sem que seja necessario que es-tes sejam confiaveis. Ja em relacao a confiabilidade ambas as arquiteturassao equivalentes, pois permitem que mecanismos de tolerancia a faltas sejamincorporados a elas.

As diferencas entre as arquiteturas em relacao aos requisitos nao-funci-onais tıpicos de aplicacoes SCADA estao sintetizadas na tabela 13. Na tabelae possıvel verificar que as abordagens sao equivalentes em termos de inte-roperabilidade, portabilidade e confiabilidade, mas diferem nos aspectos deescalonabilidade e seguranca. No quesito da escalonabilidade as caches fa-vorecem a ROA. Ja o suporte a seguranca da abordagem de Web Services emais completo, pois permite seguranca fim-a-fim das mensagens.

Com base nesta analise pode-se chegar a algumas conclusoes. Casosomente os requisitos nao-funcionais de SCADA sejam levados em conta, asabordagens se equilibram, sendo o fiel da balanca a escolha entre a segurancafim-a-fim e uma maior escalonabilidade. Entretanto na questao de integracaocom a Web a arquitetura ROA apresenta mais vantagens do que a de WebServices RPC.


Neste capıtulo foi apresentado um estudo comparativo entre arquite-turas de software para uma aplicacao SCADA na Web. Primeiramente foidescrita a aplicacao da transferencia entre tanques, sendo propostas duas ar-

125

Requisito Web Services RPC ROAInteroperabilidade Tecnologias da Web Tecnologias da Web

Portabilidade Tecnologias da Web Tecnologias da WebEscalonabilidade Sem cache Com cacheConfiabilidade Tolerancia a faltas Tolerancia a faltas

Seguranca Fim-a-fim Ponto-a-ponto

Tabela 13: Comparacao entre as arquiteturas e requisitos nao-funcionais deSCADA

quiteturas que modelam as funcionalidades desta aplicacao. As duas arqui-teturas foram entao comparadas com base em sua integracao com a Web eno cumprimento dos requisitos nao-funcionais tıpicos de SCADA. Por fimconcluiu-se que a ROA aproveita melhor os recursos da Web, e que ambas asarquiteturas apresentam um equilıbrio em relacao ao cumprimento dos requi-sitos nao-funcionais tıpicos de SCADA.

127

7 Conclusao

Esta dissertacao mostrou como uma aplicacao SCADA tıpica pode serprojetada de forma que seus requisitos sejam atendidos dentro dos princıpiosarquiteturais que fundamentam a Web. Foram analisadas as arquiteturas desoftware comumente propostas para SCADA, e as dificuldades que essas ar-quiteturas, baseadas em RPC, apresentam para realizar uma integracao coma Web, devido a questoes como acoplamento forte, manutencao de estado euso de interfaces especializadas.

Tomando como cenario uma CFM, ambiente tıpico da industria, foiprojetada uma Arquitetura Orientada a Recursos que englobou as funciona-lidades geralmente oferecidas por aplicacoes SCADA: aquisicao de dados,controle em nıvel de supervisao, configuracoes, historicos, alarmes e IHMs.As funcionalidades foram cobertas de forma satisfatoria, com excecao dosalarmes, cuja abordagem baseada em “polling” possui algumas limitacoes deescalonabilidade.

Na abordagem desenvolvida as funcionalidades foram modeladas porum conjunto de recursos, expostos atraves de servidores HTTP, que atuamcomo a interface publica do SCADA para aplicacoes clientes. Para lidar comdispositivos que nao possuem suporte ao HTTP o servidor pode atuar comoum gateway na comunicacao com as estacoes remotas em campo. Os clientespodem exibir sinoticos em uma IHM para operadores, esperar pelo disparo dealarmes, controlar o processo, configurar dispositivos e abastecer com dadossistemas de MES/ERP. A arquitetura tambem permite a inclusao de compone-nentes intermediarios como os proxies e caches, podendo favorecer aspectosde escalabilidade.

Os requisitos nao funcionais geralmente enfatizados em SCADA saocontemplados pela arquitetura. A interoperabilidade e portabilidade sao fa-vorecidas atraves do uso de tecnologias abertas da Web. A seguranca foicoberta atraves do HTTPS, combinado com autenticacao HTTP Basic e pelomodelo RBAC na autorizacao. A escalabilidade e favorecida pelo fato de aarquitetura estar embasada nos estilos arquiteturais que fundamentam a Web.Mecanismos para prover confiabilidade nao foram implementados, contudofoi mostrado que os mesmos podem ser incorporados na arquitetura. Proces-sos com requisitos de tempo-real nao foram cobertos pela arquitetura devidoa natureza nao-determinıstica da Internet.

Atraves de uma implementacao foram desenvolvidas aplicacoes cli-entes para interagir com os recursos. Estas aplicacoes mostraram aspectosde simplicidade, portabilidade e interoperabilidade da arquitetura. A im-plementacao tambem contribuiu tambem para mostrar como e estruturada a

128

arquitetura de software de um aplicativo SCADA existente para a Web, oMango M2M.

Na comparacao com uma arquitetura existente, foram mostrados osaspectos de integracao com a Web que diferenciam a abordagem ROA dasarquiteturas baseadas em RPC, devido ao seu suporte a tipos de mıdia, ca-che, componentes intermediarios e enlaces. Nesta analise tambem foi mos-trado que ambas as abordagens possuem suporte equivalente aos requisitotıpicos de SCADA nos aspectos da interoperabilidade, portabilidade e con-fiabilidade, mas diferem em termos de escalonabilidade e seguranca. Outroaspecto interessante da analise foi demonstrar que a arquitetura pode modelaros requisitos de outra aplicacao SCADA, expondo sua flexibilidade.

Dentre trabalhos futuros que podem ser desenvolvidos encontram-se:

• Avaliacao da arquitetura para outras aplicacoes tıpicas de SCADA.Nesta avaliacao podem surgir novos requisitos a serem incorporados,possibilitando que a arquitetura seja extendida, tornando-a mais flexıvel.

• Realizacao de experimentos que avaliem quantitativamente aspectos deperformance e escalonabilidade da implementacao da arquitetura, dadoque a analise realizada foi feita somente com base em criterios qualita-tivos.

• Estudo e implementacao de ferramentas para utilizar a arquitetura naeducacao de engenharia, em especial na integracao com linguagens deprogramacao de proposito educacional e redes sociais.

• Implementacao de mecanismos para prover confiabilidade para a arqui-tetura, tais como algoritmos de tolerancia a faltas.

• Estudo mais aprofundado dos aspectos de seguranca da arquitetura,tais como mecanismos de gerenciamento de chaves criptograficas epolıticas de controle de acesso.

• Integracao de tecnologias de Syndication como o padrao Atom na ar-quitetura (SAYRE, 2005).

• Estudo de alternativas para o funcionamento dos alarmes, dado que aabordagem proposta possui algumas limitacoes. Neste aspecto pode-sedestacar a avaliacao de estilos de arquitetura baseados em eventos nocumprimento desta funcionalidade.

• Muitos esforcos estao centrados em torno de criar grandes redes dedispositivos inteligentes, encontradas no mundo fısico. Abordagens re-centes propoem a integracao destes dispositivos com a Web, formando

129

uma “Web das coisas” (GUINARD; TRIFA; WILDE, 2010). Estudar aintegracao da arquitetura proposta para SCADA com estas abordagensparece promissor.

131

Referencias Bibliograficas

ADAMO, F. et al. Scada/hmi systems in advanced educational courses.Instrumentation and Measurement, IEEE Transactions on, v. 56, n. 1, p. 4–10, feb. 2007. ISSN 0018-9456.

Altus. ”Manual de Utilizacao PO3047/PO3147/PO324 UCPs Serie Ponto”.[S.l.], 2011.

ALUR, D. et al. Core J2EE Patterns (Core Design Series): Best Practicesand Design Strategies. Mountain View, CA, USA: Sun Microsystems, Inc.,2003. ISBN 0131422464.

BAILEY, D.; WRIGHT, E. Practical SCADA for industry. [S.l.]: Newnes,2003. ISBN 0750658053.

BALASUBRAMANIAN, J. et al. Adaptive failover for real-time middlewarewith passive replication. In: IEEE. 15th IEEE Real-Time and EmbeddedTechnology and Applications Symposium. [S.l.], 2009. p. 118–127.

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture inPractice. [S.l.]: Addison-Wesley Professional, 1997. ISBN 0201199300.

BASS, L.; CLEMENTS, P.; KAZMAN, R. Software Architecture inPractice. 2. ed. Boston, MA, USA: Addison-Wesley Longman PublishingCo., Inc., 2003. ISBN 0321154959.

BENTO, D. et al. Maquete de uma Celula Flexıvel de Manufatura. 2007.

BERNAT, G.; BURNS, A.; LIAMOSI, A. Weakly hard real-time systems.Computers, IEEE Transactions on, IEEE, v. 50, n. 4, p. 308–321, 2001.

BERNER-LEE, T. Information management: A proposal.Http://www.w3.org/History/1989/proposal.html.

BERNER-LEE, T. The world wide web: A very short personal history.Http://www.w3.org/People/Berners-Lee/ShortHistory.html.

BERNERS-LEE, T. Weaving the Web: The Original Design and UltimateDestiny of the World Wide Web. [S.l.]: Harper Paperbacks, 2000. ISBN006251587X.

BIRRELL, A. D.; NELSON, B. J. Implementing remote procedure calls.ACM Transactions on Computer Systems, v. 2, p. 39–59, 1984.

132

BONY, B.; HARNISCHFEGER, M.; JAMMES, F. Convergence of opcua and dpws with a cross-domain data model. In: Industrial Informatics(INDIN), 2011 9th IEEE International Conference on. [S.l.: s.n.], 2011. p.187 –192.

BOX KAKIVAYA, e. a. Soap: Simple object access protocol.Http://scripting.com/misc/soap1.txt. 1999.

BOZDAG, E.; MESBAH, A.; DEURSEN, A. V. A comparison of push andpull techniques for ajax. In: IEEE. Web Site Evolution, 2007. WSE 2007. 9thIEEE International Workshop on. [S.l.], 2007. p. 15–22.

BRATAAS, G.; HUGHES, P. Exploring architectural scalability. In:Proceedings of the 4th international workshop on Software and performance.New York, NY, USA: ACM, 2004. (WOSP ’04), p. 125–129. ISBN1-58113-673-0.

CANDIDO, G. et al. Soa at device level in the industrial domain: Assessmentof opc ua and dpws specifications. In: Industrial Informatics (INDIN), 20108th IEEE International Conference on. [S.l.: s.n.], 2010. p. 598 –603.

CASIMIRO, A. Uma Panoramica Sobre Sistemas SCADA. [S.l.], 1995.

CHAN, F.; CHAN, H. A comprehensive survey and future trend ofsimulation study on fms scheduling. Journal of Intelligent Manufacturing,Springer, v. 15, n. 1, p. 87–102, 2004.

CHANG, F. et al. Bigtable: A distributed storage system for structured data.ACM Transactions on Computer Systems (TOCS), ACM, v. 26, n. 2, p. 1–26,2008.

CHAU, T.; KHAI, N. Web-based data monitoring and supervisory control.In: Proceedings of the int. conference ISEE. [S.l.: s.n.], 2007.

DANEELS, A.; SALTER, W. What is SCADA? In: Proceedings on theInternational Conference on Accelerator and Large Experimental PhysicsControl System, Trieste, Italy. [S.l.: s.n.], 1999.

DAWSON, R. et al. Skma: a key management architecture for scada systems.In: AUSTRALIAN COMPUTER SOCIETY, INC. Proceedings of the 2006Australasian workshops on Grid computing and e-research-Volume 54.[S.l.], 2006. p. 183–192.

DIERKS, T.; ALLEN, C. The TLS Protocol Version 1.0. United States: RFCEditor, 1999.

133

DOLLIMORE, J.; KINDBERG, T.; COULOURIS, G. Distributed Systems:Concepts and Design (4th Edition). [S.l.]: Addison Wesley, 2005. ISBN0321263545.

DWR. DWR Documentation. 2010. Disponıvel em:http://directwebremoting.org/dwr/ Acessado em: 07 de Outubro de2010. Disponıvel em: <http://directwebremoting.org/dwr>.

EUGSTER, P. et al. The many faces of publish/subscribe. ACM ComputingSurveys (CSUR), ACM, v. 35, n. 2, p. 114–131, 2003.

FALLIERE, N.; MURCHU, L.; CHIEN, E. W32. stuxnet dossier. SymantecSecurity Response,[Online], Accessed, v. 14, 2010.

FAN, R.; CHEDED, L.; TOKER, O. Investigation Of Internet-Based SCADASystems: Design and Applications. Dissertacao (Mestrado) — King FahdUniversity Of Petroleum Minerals, 2004.

FAN, R.; CHEDED, L.; TOKER, O. Internet-based scada: a new approachusing java and xml. Computing Control Engineering Journal, v. 16, n. 5, p.22 – 26, oct.-nov. 2005. ISSN 0956-3385.

FAVARETTO, F. Contribuicao ao Processo de Gestao da Producao pelautilizacao da coleta de dados de chao de fabrica. Tese (Doutorado) —Universidade de Sao Paulo, 2001.

FENG-PING, Y.; CHUN-HUA, F.; JIAN, W. Design of a software ofdrawing monitoring graphics based on java and svg [j]. Relay, 2008.

FERRAIOLO, D.; CUGINI, J.; KUHN, D. Role-based access control (rbac):Features and motivations. In: Proceedings of 11th Annual Computer SecurityApplication Conference. [S.l.: s.n.], 1995. p. 11–15.

FIELDING, R. et al. Hypertext Transfer Protocol – HTTP/1.1. 1999. RFC2616. Available from http://www.ietf.org/rfc/rfc2616.txt. Disponıvel em:<http://www.ietf.org/rfc/rfc2616.txt>.

FIELDING, R. T. Architectural styles and the design of network-basedsoftware architectures. Tese (Doutorado) — University of California, Irvine,2000. AAI9980887.

FIELDING, R. T.; TAYLOR, R. N. Principled design of the modern webarchitecture. ACM Trans. Internet Technol., ACM, New York, NY, USA,v. 2, p. 115–150, May 2002. ISSN 1533-5399.

134

FOWLER, M. Patterns of Enterprise Application Architecture. Boston,MA, USA: Addison-Wesley Longman Publishing Co., Inc., 2002. ISBN0321127420.

FRANKS, J. et al. HTTP Authentication: Basic and Digest AccessAuthentication. United States: RFC Editor, 1999.

GARCIA, Y.; QUEIROZ, M. H. Formal synthesis, simulation andautomatic code generation of supervisory control for a manufacturing cell.International Congress of Mechanical Engineering, 2009.

GARLAN, D.; SHAW, M. An introduction to software architecture.Advances in software engineering and knowledge engineering, Singapore,v. 1, p. 1–40, 1993.

GHEZZI, C.; JAZAYERI, M.; MANDRIOLI, D. Fundamentals of SoftwareEngineering. 2nd. ed. Upper Saddle River, NJ, USA: Prentice Hall PTR,2002. ISBN 0133056996.

GOLONKA, P.; GONZALEZ-BERGES, M. Integrated access control forpvss-based scada systems at cern. In: ICALEPCS. [S.l.], 2009.

GOMES, M. F. P. Canal SCADA na Web. Dissertacao (Mestrado) —Universidade do Porto, 2003.

GUINARD, D.; TRIFA, V.; WILDE, E. A resource oriented architecture forthe web of things. In: IEEE. Internet of Things (IOT), 2010. [S.l.], 2010.p. 1–8.

HADLICH, T. Providing device integration with opc ua. In: IndustrialInformatics, 2006 IEEE International Conference on. [S.l.: s.n.], 2006. p.263 –268.

HAMMER-LAHAV, E. The oauth 1.0 protocol. 2010.

HANNELIUS, T.; SALMENPERA, M.; KUIKKA, S. Roadmap to adoptingopc ua. In: IEEE. Industrial Informatics, 2008. INDIN 2008. 6th IEEEInternational Conference on. [S.l.], 2008. p. 756–761.

HARJUNKOSKI, I.; NYSTROM, R.; HORCH, A. Integration of schedulingand control–theory or practice? Computers Chemical Engineering,v. 33, n. 12, p. 1909 – 1918, 2009. ISSN 0098-1354. FOCAPO 2008 -Selected Papers from the Fifth International Conference on Foundations ofComputer-Aided Process Operations.

135

HONG, X.; JIANHUA, W. Using standard components in automationindustry: A study on opc specification. Computer Standards & Interfaces,Elsevier, v. 28, n. 4, p. 386–395, 2006.

HOWELLS, R. Erp needs shop-floor data. Manufacturing Engineering, vol.125, n. Issue 4, p. 54, 7 , 2c, 2000.

IEEE. Ieee Standard Computer Dictionary. City: Inst of Elect Electronic,1991. ISBN 1559370793.

IZAGUIRRE, M. J. A. G.; LOBOV, A.; LASTRA, J. L. M. Opc-ua and dpwsinteroperability for factory floor monitoring using complex event processing.In: Industrial Informatics (INDIN), 2011 9th IEEE International Conferenceon. [S.l.: s.n.], 2011. p. 205 –211.

JSON. JSON. 2010. http://www.json.org/.

JUHASZ, B. Developing M2M Applications With Mango. [S.l.], 2009.

KAPSALIS, V.; KOUBIAS, S.; PAPADOPOULOS, G. Opc-sms: a wirelessgateway to opc-based data sources. Computer Standards & Interfaces,Elsevier, v. 24, n. 5, p. 437451, 2002.

KAYE, D. Loosely Coupled: The Missing Pieces of Web Services. [S.l.]:RDS Press, 2003. ISBN 1881378241.

KHATHAIR, A. Y. Design and Implementation of Web Based SCADA.Dissertacao (Mestrado) — Nahrain University, 2006.

KHATIB, A. et al. Thoughts on future Internet based power systeminformation network architecture. In: IEEE. Power Engineering SocietySummer Meeting, 2000. IEEE. [S.l.], 2000. v. 1, p. 155–160. ISBN0780364201.

KRUTZ, R. L. Securing SCADA Systems. [S.l.]: Wiley, 2005. ISBN9780764597879.

LI, D.; SERIZAWA, Y.; KIUCHI, M. Concept design for a web-basedsupervisory control and data-acquisition (scada) system. In: Transmissionand Distribution Conference and Exhibition 2002: Asia Pacific. IEEE/PES.[S.l.: s.n.], 2002. v. 1, p. 32 – 36 vol.1.

MACLAREN, J.; KEOWN, M. M. HARC: A Highly-Available RobustCo-scheduler, submitted to the 5th UK e-Science All Hands Meeting. 2006.

136

MAJDALAWIEH, M.; PARISI-PRESICCE, F.; SANDHU, R. Rbac modelfor scada. Innovative Algorithms and Techniques in Automation, IndustrialElectronics and Telecommunications, Springer, p. 329–335, 2007.

MARDEGAN, R.; AZEVEDO, R.; OLIVEIRA, J. Os benefıcios da coletaautomatica de dados do chao de fabrica para o processo de negocio gestao dademanda. XXII Encontro Nacional de Engenharia de Producao, 2002.

MEDIDA, S.; SREEKUMAR, N.; PRASAD, K. SCADA-EMS on theInternet. In: IEEE. Energy Management and Power Delivery, 1998.Proceedings of EMPD’98. 1998 International Conference on. [S.l.], 1998.v. 2, p. 656–660. ISBN 0780344952.

MESA, I. Mes explained: A high level vision. MESA International WhitePaper6, v. 1, p. 25, 1997.

Modbus Organization. Modbus Technical Resources. [S.l.], 2011.

MORAES, P. M. Scada, model data combine to provide real-timecommercial supervision at petrobras. Pipeline Gas Journal, 2005.

MYERS, G. J. Composite Structure Design. New York, NY, USA: JohnWiley & Sons, Inc., 1978. ISBN 0442805845.

National Communications Systems. Supervisory Control and DataAcquisition (SCADA) Systems. [S.l.], 2004.

NELSON, T. H. Complex information processing: a file structure for thecomplex, the changing and the indeterminate. In: Proceedings of the 196520th national conference. New York, NY, USA: ACM, 1965. (ACM ’65), p.84–100.

NEWMAN, M. W. et al. Designing for serendipity: supporting end-userconfiguration of ubiquitous computing environments. In: Proceedings ofthe 4th conference on Designing interactive systems: processes, practices,methods, and techniques. New York, NY, USA: ACM, 2002. (DIS ’02), p.147–156. ISBN 1-58113-515-7.

OASIS. OASIS Web Services Discovery and Web Services Devices Profile(WS-DD) Technical Committee. http://www.oasis-open.org/committees/ws-dd/charter.php: OASIS, 2006.

PAUTASSO, C.; WILDE, E. Why is the web loosely coupled?: amulti-faceted metric for service design. In: Proceedings of the 18thinternational conference on World wide web. New York, NY, USA: ACM,2009. (WWW ’09), p. 911–920. ISBN 978-1-60558-487-4.

137

PERRY, D.; WOLF, A. Foundations for the study of software architecture.ACM SIGSOFT Software Engineering Notes, ACM, v. 17, n. 4, p. 40–52,1992.

PIERI, G. et al. Telis: a programming tool set for beginners. In: 8thInternational Information and Telecommunication Technologies Symposium.[S.l.: s.n.], 2009.

POPA, M.; POPA, A.; PATITOIU, C. A web connected smart sensor. In:Applied Computational Intelligence and Informatics, 2007. SACI ’07. 4thInternational Symposium on. [S.l.: s.n.], 2007. p. 105 –110.

PRYCE, N. G. Component Interaction in Distributed Systems. 1998.

PUDER, A.; ROMER, K.; PILHOFER, F. Distributed Systems Architecture:A Middleware Approach. San Francisco, CA, USA: Morgan KaufmannPublishers Inc., 2005. ISBN 1558606483.

QIU, B.; GOOI, H. Web-based scada display systems (wsds) for access viainternet. Power Systems, IEEE Transactions on, v. 15, n. 2, p. 681 –686, may2000. ISSN 0885-8950.

QUEIROZ, M. H. D.; CURY, J. E. R. Modular supervisory control of largescale discrete event systems. In: In Discrete Event Systems: Analysis andControl. Proc. WODES 2000. [S.l.]: Kluwer Academic, 2000. p. 103–110.

RAZA, M.; HUSSAIN, F. k.; CHANG, E. A methodology for quality-basedmashup of data sources. In: Proceedings of the 10th InternationalConference on Information Integration and Web-based Applications &Services. New York, NY, USA: ACM, 2008. (iiWAS ’08), p. 528–533. ISBN978-1-60558-349-5.

RICHARDSON, L.; RUBY, S. Restful Web Services. [S.l.]: O’Reilly Media,2007. ISBN 0596529260.

SAYRE, R. Atom: The standard in syndication. Internet Computing, IEEE,IEEE, v. 9, n. 4, p. 71–78, 2005.

SEROTONIN. Mango M2M. 2011. Disponıvel em:http://mango.serotoninsoftware.com Acessado em: 31 de Janeiro de2011. Disponıvel em: <http://mango.serotoninsoftware.com/>.

SHAW, M.; CLEMENTS, P. A field guide to boxology: Preliminaryclassification of architectural styles for software systems. In: PUBLISHEDBY THE IEEE COMPUTER SOCIETY. compsac. [S.l.], 1997. p. 6.

138

SHAW, M.; CLEMENTS, P. The golden age of software architecture. IEEESoftware, IEEE Computer Society, Los Alamitos, CA, USA, v. 23, p. 31–39,2006. ISSN 0740-7459.

SLEMAN, A.; MOELLER, R. Integration of wireless sensor networkservices into other home and industrial networks; using device profile forweb services (dpws). In: Information and Communication Technologies:From Theory to Applications, 2008. ICTTA 2008. 3rd InternationalConference on. [S.l.: s.n.], 2008. p. 1 –5.

SOUZA, R. B. de. Uma Arquitetura para Sistemas Supervisorios Industriaise sua Aplicacao em Processos de Elevacao Artificial de Petroleo. Dissertacao(Mestrado) — UFRN, 2005.

SPRING. Spring Reference Documentation. 2010. Disponıvel em:http://www.springsource.org/documentation Acessado em: 07 de Outubro de2010. Disponıvel em: <http://www.springsource.org/documentation>.

TORRISI, N.; OLIVEIRA, J. Remote control of cnc machines using thecyberopc communication system over public networks. The InternationalJournal of Advanced Manufacturing Technology, Springer London, v. 39, p.570–577, 2008. ISSN 0268-3768. 10.1007/s00170-007-1244-0.

TU, N. T. T. et al. Research and development of opc client-serverarchitectures for manufacturing and process automation. In: Proceedingsof the 2010 Symposium on Information and Communication Technology.New York, NY, USA: ACM, 2010. (SoICT ’10), p. 163–170. ISBN978-1-4503-0105-3.

URDANETA, G. et al. A reference software architecture for the developmentof industrial automation high-level applications in the petroleum industry.Comput. Ind., Elsevier Science Publishers B. V., Amsterdam, TheNetherlands, The Netherlands, v. 58, p. 35–45, January 2007. ISSN0166-3615.

VINOSKI, S. Demystifying restful data coupling. IEEE Internet Computing,IEEE Educational Activities Department, Piscataway, NJ, USA, v. 12, p.87–90, March 2008a. ISSN 1089-7801.

VINOSKI, S. Serendipitous reuse. IEEE Internet Computing, IEEEEducational Activities Department, Piscataway, NJ, USA, v. 12, p. 84–87,January 2008b. ISSN 1089-7801.

W3C. A little history of the world wide web.Http://www.w3.org/History.html. 2000.

139

W3C. Web Services Architecture. [S.l.], February 2004.

WALLACE, D. Smart fields come of age with internet-based scada. Pipeline& gas journal, Oildom Publishing Co, 14515 Briar Hills Parkway, Houston,TX, 77077, USA,, v. 231, n. 2, p. 27–27, 2004.

WARD, M. P. et al. An architectural framework for describing supervisorycontrol and data acquisition (scada) systems, (master’s thesis, navalpostgraduate school. In: 69 PAGE INTENTIONALLY LEFT BLANK 70 ASCADA MAC PREFIXES A.1 NMAP-MAC-PREFIXES FILE This. [S.l.:s.n.], 2004.

WHITE, J. E. A high-level framework for network-based resource sharing.In: Proceedings of the June 7-10, 1976, national computer conference andexposition. New York, NY, USA: ACM, 1976. (AFIPS ’76), p. 561–570.Disponıvel em: <http://doi.acm.org/10.1145/1499799.1499878>.

WINER, D. Dave’s history of soap.Http://www.xmlrpc.com/stories/storyReader555.1999.

ZECEVIC, G. Web based interface to scada system. In: Power SystemTechnology, 1998. Proceedings. POWERCON ’98. 1998 InternationalConference on. [S.l.: s.n.], 1998. v. 2, p. 1218 –1221 vol.2.

141

Glossario

API Application Programming Interface. 66

CFM Celula Flexıvel de Manufatura. 20CORBA Common Object Request Broker Archi-

tecture. 60CSV Comma-separated Values. 51

DAO Data Access Object. 96DCOM Distributed Component Object Model. 60DNP3 Distributed Network Protocol. 30DPWS Devices Profile for Web Services. 64DTO Data Transfer Object. 96DWR Direct Web Remoting. 93

ERP Enterprise Resource Planning. 17

FMS Flexible Manufacturing System. 69

HTTP HyperText Transfer Protocol. 37

IHM Interface Homem-Maquina. 24

JSON JavaScript Object Notation. 49

M2M Machine to Machine. 69MES Manufacturing Execution Systems. 17MVC Model View Controller. 94

OPC-UA OPC Unified Architecture. 64

PNG Portable Network Graphics. 51

REST Representational State Transfer. 20ROA Resource Oriented Architecture. 18RPC Remote Procedure Calls. 18RTU Remote Terminal Unit. 23

142

SCADA Supervisory Control and Data Aquisition.17

SSL Secure Sockets Layer. 52SVG Scalable Vector Graphics. 51

TLS Transport Layer Security. 52

URI Uniform Resource Identifier. 37

XML Extensible Markup Language. 18

pablo valerio pol´ ˆonia - connecting repositories · ned a resource oriented architecture (roa),...

Documents