IBP109_09 METODOLOGIA PARA TESTES DE DESEMPENHO E CAPACIDADE DE SISTEMAS SCADA Gabriel Guieiro, Anderson Diniz

Copyright 2009, Instituto Brasileiro de Petrleo, Gs e Biocombustveis - IBP

Este Trabalho Tcnico foi preparado para apresentao no V Congresso Rio Automao, realizado nos dias 28 e 29 de maio de 2009, no Rio de Janeiro. Este Trabalho Tcnico foi selecionado para apresentao pelo Comit Tcnico do Evento, seguindo as informaes contidas na sinopse e no texto final submetido pelo(s) autor(es). O contedo do Trabalho Tcnico, como apresentado, no foi revisado pelo IBP. Os organizadores no iro traduzir ou corrigir os textos recebidos. O material conforme, apresentado, no necessariamente reflete as opinies do Instituto Brasileiro de Petrleo, Gs e Biocombustves, Scios e Representantes. de conhecimento e aprovao do(s) autor(es) que este Trabalho Tcnico seja publicado nos Anais do V Congresso Rio Automao.

Resumo
Este trabalho prope um estudo que determina o desempenho e a capacidade de expanso de sistemas SCADA antes da sua implementao. So descritos os passos e as caractersticas que devem ser observadas para a montagem da plataforma que simular o sistema final proposto, e os parmetros de desempenho a serem analisados.

Abstract
This paper proposes a study which determines the performance and capacity for expansion of SCADA systems prior to implementation. The steps and characteristics that must be met for the platform that simulate the final proposed system and the parameters of performance to be analyzed are described.

1. Introduo Avaliar o desempenho de um sistema de automao antes do incio do seu desenvolvimento de suma importncia. Possibilita antever os problemas. Outro parmetro essencial para o cliente final a capacidade de expanso futura do sistema. Normalmente os sistemas que fazem interface com o usurio final, tais como supervisrios e IHMs, so taxados como responsveis pelo mau desempenho do sistema como um todo, uma vez que a maioria dos problemas culmina na limitao da operabilidade destes. Em geral, os problemas surgem devido s seguintes causas: 1. 2. 3. Falha na definio da arquitetura ou na especificao dos elementos (supervisrio, CLP, switches) Falhas na definio ou na implementao da rea de interface CLP-supervisrio Expanso em um sistema de automao j consolidado. Muitas vezes ocorrem mudanas a partir do projeto original, que podem vir a sobrecarregar o sistema

Os itens a seguir descrevem os passos e as caractersticas que devem ser observadas para a montagem da plataforma que simular o sistema final proposto. Os testes a serem realizados nesta plataforma possibilitam uma anlise que compreende desde a rea de interface CLP-supervisrio, passando pelo funcionamento do protocolo de comunicao e configuraes dos elementos da rede, chegando at a implementao da base de dados do supervisrio. So tambm abordados os parmetros desempenho a serem avaliados.

______________________________ 1 Engenheiro de Controle e Automao VISION SISTEMAS INDUSTRIAIS 2 Gerente de Engenharia VISION SISTEMAS INDUSTRIAIS

V Congresso Rio Automao

2. A Metodologia A metodologia descrita neste artigo baseada em procedimentos prticos, realizados integralmente em ambiente anlogo ao que ser encontrado no sistema real portanto, simulado. Os testes so realizados para garantir a funcionalidade e a estabilidade do sistema em operao normal, permitir a otimizao dos recursos disponveis e atender aos requisitos do projeto. Alm da situao operacional normal, o sistema avaliado em condies sobrecarregadas para garantir um bom desempenho mesmo em situaes extremas. O teste de desempenho realizado conforme especificaes tcnicas do projeto e decorre em etapas, descritas sucintamente abaixo. Primeiramente realizado um levantamento da estrutura a ser utilizada e quais os requisitos de desempenho para o sistema. A partir da so estabelecidos os critrios tcnicos que sero utilizados como parmetros comparativos e de avaliao no fim do teste. Para simular o ambiente em bancada so desenvolvidas rotinas de simulao, coletados os dados do sistema e realizada a anlise dos resultados. Para realizar a coleta de dados do sistema em questo so utilizados, alm das ferramentas nativas dos hardwares de controle e do sistema de superviso, uma ferramenta de aquisio de pacotes de rede software sniffer freeware -, denominada WireShark. Atravs deste software foi possvel a obteno de raw data passvel de anlise. Por fim, realizada a emisso de relatrio de desempenho. Neste documento exposto qual o potencial da estrutura testada e quais alteraes exigidas em caso de uma expanso do sistema. 2.1 Levantamento

Nesta etapa do procedimento feito o levantamento das especificaes tcnicas do projeto. Faz parte desse levantamento a definio dos seguintes itens: Arquitetura do sistema Protocolos de comunicao Redundncia Estruturao de base de dados Configurao dos drivers de comunicao Configurao da comunicao dos controladores Estruturao da programao dos controladores e do sistema de superviso Taxas de compresso e armazenamento de dados Compondo, desta forma, a estrutura definida para o sistema. Outro ponto relevante a ser especificado o que se refere ao cenrio de operao e sua expectativa de desempenho. preciso que esteja claro sob quais condies o sistema vai operar (em relao quantidade de equipamentos, ocupao de memria do CLP, taxas de comunicao e.g.) e qual o seu comportamento esperado. Esta situao servir de referncia para comparaes e ser denominada operao nominal do sistema. 2.2 Definio dos Critrios Tcnicos para Avaliao de Desempenho do Sistema

Para avaliar o desempenho de maneira sistemtica, so definidos alguns parmetros relevantes que abrangem vrios aspectos do sistema. Dentre eles destacam-se: Scan do CLP; Ocupao da Rede (Pacotes/tempo e Bytes/tempo); Round Trip Time (RTT) dos pacotes provenientes da comunicao Servidor CLP; Tempo de resposta a Comando de um equipamento. E, para estes parmetros, so modificadas algumas variveis conforme abaixo: Taxa de leitura (OPC ou driver dedicado); Quantidade de Servidores ligados rede (comunicando com os CLPs); Quantidade de CLPs ligados rede; Ocupao dos recursos dos servidores (memria e processamento). Gerando, assim, uma viso do quo ofensor cada parmetro e qual o peso deste na condio geral da rede. Para incluir um critrio dentre os que sero avaliados, importante que sua incluso seja justificada tecnicamente e que seja passvel de mensurao.
2

V Congresso Rio Automao

Figura 1 - Diagrama de incluso de critrio de avaliao Cada critrio deve possuir: Justificativa Tcnica Forma de Obteno Avaliao A justificativa tcnica pretende firmar o porqu da incluso do critrio. A forma de obteno deve ser previamente estabelecida, evitando que o critrio no seja avaliado por haver impossibilidade de mensurao. O modo de avaliao pode ser respaldado por normas tcnicas, artigos, manuais de fabricante ou outros meios que estabeleam limites quantitativos para os critrios. Meios empricos para determinar faixas aceitveis de operao devem ser utilizados com cautela e precisam ter seu funcionamento detalhado. Vrios critrios podem ser propostos, mas os que tm obteno difcil ou inferencial devem ser inicialmente preteridos. 3. Teste de Desempenho em Plataforma O teste de plataforma consiste em realizar uma simulao do ambiente que ser encontrado no sistema final. Desta forma, os dispositivos tais como computadores, CLPs, switchs, etc. devem ser idnticos aos definidos no projeto original. A configurao dos drivers e softwares devem tambm seguir essa regra.

3.1.

Definio da Arquitetura da Plataforma de Teste Tendo como objetivo a simulao do ambiente da planta, montada uma estrutura anloga detalhada anteriormente, no levantamento e definio da arquitetura do sistema. A complexidade e detalhamento desta estrutura so proporcionais ao nvel de fidelidade que se deseja obter, contemplando, principalmente os elementos principais - como CLP, servidores de superviso e Switches.

V Congresso Rio Automao

Figura 2 - Exemplo de Arquitetura Montada em Bancada para realizao dos Testes A realizao criteriosa desta etapa crucial e reflete diretamente nos resultados da anlise do sistema constitudo. Uma montagem coerente permite que os dados gerados sejam confiveis e representem de maneira fidedigna o sistema a ser implantado.

3.2.

Aplicativos de Teste e Configurao (CLP e Sistema de Superviso)

O aplicativo de teste para CLP desenvolvido considerando a rea de interface com o sistema de superviso e estruturao bsica de programao. A proposta ao se desenvolver o programa de teste obter uma estrutura simulada do sistema atravs de uma rotina tpica simples, que possa ser replicada de modo a simular vrios dispositivos realizando comunicao com o sistema de superviso. Com isso possvel mensurar o desempenho do sistema na situao nominal e em seu comportamento quando submetida utilizao acima da nominal. O mesmo ocorre no aplicativo do sistema de superviso. A confeco das telas e de seus equipamentos deve ser compatvel com o sistema real e deve ser considerada a capacidade de extrapolar o projeto inicial. A lgica intrnseca aos equipamentos no precisa ser demasiadamente fiel, porm fatores como taxa de atualizao de estados, envio de comandos e, quando houver, taxa de historiamento de dados so requisitos primrios para se obter uma simulao fidedigna.

3.3.

Obteno e Anlise dos Dados Obtidos da Simulao

Estabelecida a estrutura de testes, so formalizadas maneiras de se mensurar cada um dos critrios propostos. Estas formas de medida dos parmetros devem ser realizadas de maneira coerente, permitindo uma comparao dos valores entre as diferentes configuraes propostas (utilizao nominal do sistema e acima desta). A tabela a seguir exibe um exemplo de anlise comparativa entre os critrios, quando se aumenta o nmero de equipamentos programados no CLP e supervisrio (de 400 at 2000 equipamentos): Teste Critrio

400 Eqp

800 Eqp

1200 Eqp

1600 Eqp

2000 Eqp

V Congresso Rio Automao Scan CLP Ocupao da banda de comunicao Tempo (mdio) de resposta de um comando pelos clientes Tempo (mdio) de resposta de um comando pelos servidores 80 ms 30% 0.5s 0.6s 157 ms 60% 0.5s 0.7s 236 ms 85% 0.5s 0.7s 316 ms 95% 0.7s 0.7s 391 ms 100% (Overlap) 41.4s N/A

Tabela 1 Exemplo de anlise comparativa entre critrios Outro ponto interessante criar maneiras de se realizar a medida de determinado critrio o que demonstrar maior influncia no desempenho, por exemplo de maneira redundante. Isto permite validar a medida, aumentando a confiabilidade dos resultados. H diversos softwares no mercado capazes de avaliar diversos dos parmetros que poderiam ser propostos. O software freeware j citado (WireShark) uma poderosa ferramenta no que se refere a prover raw data dos pacotes de comunicao. Uma vez coletados estes dados, possvel identificar a maneira como se d a comunicao e, a partir da, consolidar a avaliao do critrio em questo.

Figure 3- Exemplo da interpretao do modo como se d a comunicao de um protocolo proprietrio

Podem ser criados programas simples para manipulao destes dados coletados devido grande quantidade de pacotes de rede coletada. Grficos e anlises estatsticas podem ser gerados para o melhor entendimento e uma apresentao mais clara dos resultados. Alguns critrios normalmente estabelecidos e suas formas de obteno so exibidos na tabela abaixo:

Critrio

Forma de Obteno

Observao Normalmente os softwares de programao de CLP

Scan do CLP

Software de Programao do CLP

disponibilizam, quando em modo online, parmetros (inclusive o scan) a cerca do funcionamento do mesmo.

V Congresso Rio Automao Os software WireShark disponibiliza Ocupao da Rede Software Sniffer a taxa de ocupao de rede a qual ele est conectado. Anlise dos pacotes de dados, providos pelo software Sniffer. Tempo de resposta a um Comando dado, no sistema supervisrio. Mtodo alternativo: Log de Operao do Sistema de Superviso no envio e no recebimento do status do estado preciso identificar, dentre os pacotes trocados na comunicao, qual representa eventos de tramitao de dados, tais quais ACK, envio de dados, etc.

Atravs da identificao da Atualizao de dados (cclico) Anlise dos dados providos pelo software Sniffer comunicao, possvel estabelecer de quanto em quanto tempo requerida a atualizao dos estados. Tabela 2- Exemplos de critrios a serem mensurados e suas formas de obteno Uma das questes importantes que cercam o teste a que se refere escalabilidade, ou seja, qual o potencial de crescimento do sistema. Algumas perguntas devem ser respondidas ao fim do teste de plataforma, tais como: Qual a limite seguro para a operabilidade do sistema no que se refere a nmero de equipamentos, ocupao de memria do CLP, ocupao de banda de rede, etc.? Quais so as mudanas a serem feitas em uma possvel expanso do sistema? At que ponto a arquitetura atual atende minhas expectativas de desempenho e possibilidade de expanso? Portanto, respondendo a estas perguntas atravs da avaliao dos critrios estabelecidos, possvel gerar um documento que contenha, alm dos resultados dos testes, uma concluso tcnica que avalie as possibilidades quanto ao desempenho, possibilidade e adequao a possveis expanses. 4. APLICAO PRTICA A aplicao descrita a seguir se trata de um teste que foi utilizado como referncia na estruturao de um sistema SCADA a ser implantado. O sistema em questo pertence a uma empresa de bioenergia e possua diversos pontos passveis de expanso. Por esta razo, o teste de desempenho, alm de nortear o desenvolvimento do projeto de automao, foi crucial na determinao dos limites de expanso do sistema. A anlise teve seu foco na avaliao de desempenho dos dispositivos especificados para o projeto: o servidor de superviso, os CLPs e o switch, alm dos componentes de software envolvidos como o supervisrio e o driver de comunicao (OPC). 4.1 Levantamento O primeiro passo foi obter a arquitetura definida para o projeto. No caso em questo a arquitetura utilizada apresentava uma topologia cliente-servidor, utilizando a seguinte arquitetura (simplificada, visando atender os propsitos de anlise) exibida abaixo.

V Congresso Rio Automao

Figure 4 - Arquitetura SCADA cliente-servidor especificada para o projeto

O foco do teste era verificar o desempenho do sistema, alm de determinar um horizonte de expanso sem alterar a arquitetura ou substituir os dispositivos.

4.2 Definio dos Critrios de Avaliao Para atender s solicitaes, foram criados alguns critrios para avaliao do sistema. A tabela a seguir os apresenta, seguido de sua justificativa tcnica, forma de obteno e parmetro de avaliao. Critrio Justificativa Tcnica Diretamente ligado ao desempenho do sistema, reflete a rapidez da execuo das rotinas programadas. Quando encontrada em valores altos extremamente prejudicial ao processo de comunicao, ocorrendo overlap quando em 100%. Consiste no tempo de ida e volta de um pacote de comunicao. A avaliao do tempo mdio deste critrio est ligada a performance do sistema como um todo. Este parmetro rene diversos processos de comunicao entre o CLP e o sistema supervisrio. Forma de Obteno Atravs do software de programao do CLP, que fornece essa informao quando em modo online. Parmetro de Avaliao Para a aplicao a que se destinava, foram almejados valores menores que 150 milissegundos. Inferior a 10% por segmento para nvel de controle e 35% por segmento para o nvel de superviso [Fonseca, 2004] Considerando que o RTT representa apenas uma das etapas que constituem o ciclo de comunicao, foi estabelecido, para o caso em questo, um RTT abaixo de 50 milissegundos aceitvel. Para a aplicao a que se destinava, foram almejados valores menores que 1 segundo.

Scan do CLP

Ocupao da Rede

O software sniffer utilizado possui ferramentas grficas e numricas para exibir este parmetro. A partir dos dados obtidos atravs de coletas de pacotes com o software sniffer possvel determinar este parmetro. O prprio software prov esta informao em forma grfica. A partir dos dados obtidos atravs de coletas de pacotes com o software sniffer possvel determinar este parmetro.

Round Trip Time (RTT) mdio

Tempo de resposta a um comando

V Congresso Rio Automao A partir dos dados obtidos atravs de coletas de pacotes com o software sniffer possvel determinar este parmetro.

Tempo entre as requisies de atualizao de estado de equipamento. Desempenho dos servidores de superviso (Utilizao de memria e processamento)

Este parmetro rene diversos processos de comunicao entre o CLP e o sistema supervisrio.

Para a aplicao a que se destinava, foram almejados valores menores que 2 segundos. [Fonseca, 2004] Utilizao de memria mxima inferior a 90%. Uso mdio do processador abaixo dos 70%. [Fonseca, 2004]

O mau dimensionamento dos servidores de Atravs de ferramentas do superviso pode culminar Windows em m operabilidade do sistema. Table 3- Listagem dos critrios propostos

Uma vez definidos os critrios e estabelecidas suas formas de obteno, inicia-se o teste de plataforma.

4.3

Teste de Desempenho em Plataforma 4.3.1. Definio da Arquitetura da Plataforma de Teste

Auxiliado pela simplicidade da arquitetura do sistema em questo, foi possvel realizar uma montagem idntica proposta para o projeto. Porm o objetivo vislumbrar possveis expanses e, para isso, foram alocados outros dispositivos, de modo a simular o comportamento do sistema aps uma futura expanso.

Figure 5 - Montagem da arquitetura do teste de plataforma

4.3.2.

Aplicativos de Teste e Configurao (CLP e Sistema de Superviso)

Montada a plataforma para testes, iniciou-se o processo de desenvolvimento dos aplicativos de testes e de configurao dos softwares e dispositivos. Os servidores de superviso receberam o aplicativo supervisrio e as configuraes especificadas em projeto, assim como o cliente e servidores OPC. Nestes ltimos a taxa de leitura foi iniciada com valores de amostragem de 1 segundo, que seriam aumentadas para verificao de impacto deste parmetro no desempenho do sistema.
8

V Congresso Rio Automao A configurao original tambm foi realizada no CLP, definindo a ocupao da rea de memria condizente com a aplicao, parcela de processamento destinada comunicao (estabelecida, no caso, em 20%). O programa de teste do CLP executa uma rotina que ocasiona, para todas as reas de interface, uma variao do estado lgico dos bits das palavras de cada equipamento em uma taxa que pode ser alterada em funo da necessidade dos testes. Foi desenvolvido um tpico de programao para o programa de teste que associado a um equipamento simulando a rea de interface no CLP.O tpico foi programado em um FB (Function Block) nomeado FB2. O motivo pelo qual se utilizou o Function Block foi a possibilidade de fazer um instancializao da rea de interface possibilitando associar, a cada equipamento, uma rea de interface especfica em um DB (Data Block).

Figure 6 - Tpico de Programao do Teste de desempenho

Em sintonia com o programa do CLP foi desenvolvido no supervisrio uma interface capaz de simular a ao dos equipamentos programados no CLP. Esta interface possibilita assegurar que todos os equipamentos esto funcionando de acordo com sua programao e qual o efeito desta no desempenho do software de superviso.
9

V Congresso Rio Automao

Figure 7 - Tela do sistema de superviso responsvel por representar a aplicao de projeto

No switch a configurao default foi mantida por estar especificada em projeto. Os meios fsicos rede ethernet foram realizados a exemplo do sistema especificado. 4.3.3. Obteno e Anlise dos Dados Obtidos da Simulao

Uma vez montada e configurada a plataforma de testes, foi configurado um notebook, onde foi instalado o software sniffer WireShark. O WireShark um programa usado por administradores de redes e usurios avanados que desejam monitorar o trfego de uma rede, analisando os pacotes de dados. Visando causar o menor efeito de carga possvel, o notebook (coletor) foi conectado junto a uma porta livre do switch. Como o notebook no era integrante de nenhuma das comunicaes entre CLP e supervisrio o mesmo s era percebido na rede quando era enviado um pacote em broadcast. Entretanto, o WireShark teve de ser configurado em modo promscuo para conseguir ler pacotes provenientes da comunicao exclusiva entre cliente e servidor.

Figure 8 - Estrutura montada para realizar coleta de pacotes de dados.

10

V Congresso Rio Automao Estabelecida a estrutura de coleta de dados, foram realizados diversos testes, variando os parmetros do supervisrio e do CLP, visando levar o sistema a condio de operao extrema, alm do exigido em caso de uma expanso. Os parmetros que sofrem variao so listados a seguir: Parmetro Excurso 2 a 4 (incremento de 1 em 1) Nmero de servidores de superviso 2 a 4 (incremento de 1 em 1) Nmero de CLPs 400 a 800 (incremento de 200 em 200) Nmero de equipamentos programados 1s a 0.1s (0.1s, 0.2s e 1s) Taxa de Leitura do cliente OPC Tabela 4- Variao dos parmetros de anlise Desta forma, o sistema inicial, que contava com uma programao de 400 equipamentos nos dois CLPs instalados, com taxa de leitura de 1s no cliente OPC configurados em duas estaes de superviso foi testado para em uma situao limite que impunha mais do dobro de complexidade. Devido a grande quantidade de dados gerados pelo WireShark, se fez necessrio a criao de uma ferramenta de tratamento destes dados, capaz de realizar, alm da identificao das informaes codificadas no protocolo de comunicao, a anlise estatstica destes dados, transformando, portanto, massa de dados em informao til. Depois de realizados os testes considerando as diferentes condies e coletado os dados, foi possvel, estabelecer comparaes entre as situaes e os critrios propostos. Critrio 1 Ocupao de Rede Mesmo avaliando este critrio para o pior caso (2 CLPs e 2 estaes de superviso, executando rotinas de 800 equipamentos a taxa de ocupao de rede no ultrapassou 6% de utilizao, considerando valores de picos de utilizao.

Figure 9 - Taxa de utilizao da rede no pior caso Critrio 2 Scan do CLP O scan do CLP se mostrou sensvel ao aumento do nmero de equipamentos programados e ao nmero de servidores na rede. Porm este fator tambm no foi alterado de maneira significativa com a imposio de parmetros mais rigorosos. O scan oscilou dentro da margem aceitvel e atingiu, no mximo, 106 milissegundos.

Figure 10 - Variao do scan do CLP (em ms) com variao dos parmetros

Critrio 3 Round Trip Time (RTT)

11

V Congresso Rio Automao O RTT avaliado em todas as situaes se mostrou dentro dos limites aceitveis propostos na avaliao deste critrio (RTT mdio abaixo de 50 milissegundos), salvo o pior caso testado, onde a rede contava com quatro servidores de superviso e quatro CLPs conectados rede. Neste caso a mdia do RTT oscilou pouco acima dos 50 milissegundos, com alguns parcos pontos fora do padro, como pode ser visto no grfico de disperso abaixo.

Figure 11 - Comportamento do RTT mensurado no pior caso

Critrio 4 Tempo de Resposta a um comando O tempo de resposta ao comando foi avaliado de duas maneiras distintas: Atravs da gravao de log no supervisrio logo aps o envio de comando e logo aps o recebimento da mudana de estado do equipamento; Analisado os dados providos em pacotes de dados pelo WireShark. Identificados os pacotes de envio de comando e de recebimento de uma alterao do status do estado do equipamento avaliado possvel determinar esse critrio. E os resultados obtidos foram bons at no pior caso, havendo pouca divergncia entre as duas maneiras de se mensurar o parmetro, o que aumenta a confiabilidade da medida. Os valores encontrados atendem as premissas de desempenho.

12

V Congresso Rio Automao

Figure 12 - Variao do tempo de resposta ao comando (em ms) com variao dos parmetros Critrio 5 Tempo entre as requisies de atualizao de estado de equipamento O tempo entre as requisies de atualizao foram mensuradas utilizando-se, exclusivamente, os estudos dos dados provenientes das coletas do software WireShark pela ferramenta de compilao de dados desenvolvida especialmente para este fim. O resultado encontrado obtido avaliando quando o supervisrio solicita o estado de um equipamento para atualiz-lo na tela sem que tenha sido dado comando para este. Cada pacote monitorado e contado os intervalos de tempo entre as requisies efetivamente atendidas pelo CLP. Feito isso por um tempo considervel (10 minutos, aproximadamente) feita a mdia simples dos valores encontrados. O resultado encontrado fica dentro dos valores estipulados, exceto nos dois piores casos, onde o tempo excede 2 segundos, mostrando uma sensibilidade ao nmero de equipamentos programados e, principalmente, a quantidade de servidores na rede.

Figure 13 - Tempo entre as requisies de atualizao de estado (em ms) com a variao dos parmetros

Atravs da anlise destes resultados aconselhvel que caso o sistema sofra uma expanso que se faa necessrio haver mais estaes de superviso, que a opo seja feita, se possvel, acrescentando mais clientes. A soluo mais adequada, pois os clientes de superviso realizam a leitura dos dados do servidor. Deste modo o impacto na comunicao CLP Superviso diminudo consideravelmente. Critrio 6 Desempenho dos servidores de superviso (Utilizao de memria e processamento)
13

V Congresso Rio Automao Este critrio se mostrou ter a caracterstica menos exigida pelo sistema. Os servidores especificados lidaram com facilidade com o processamento ficou quase todo o tempo abaixo de 10% - e uso de memria exigido. Caracterstica CPU Mem RAM Espao em Disco Especificao AMD Athlon 64 X2 DUAL 2.1 GHz 2 Gb 250 Gb

Tabela 5 - Configurao dos Servidores utilizados O pior caso foi encontrado quando dois servidores de superviso comunicavam simultaneamente com quatro CLPs com uma taxa de leitura do servidor OPC por parte do cliente OPC de 100 milissegundos. O nmero de clientes na rede no se mostrou um fator ofensor considervel e sim a taxa de leitura do cliente OPC e o nmero de CLPs na rede.

Figure 14 - Desempenho dos servidores de superviso. Uso de memria.

Gerao do documento de anlise do desempenho No documento emitido a cerca deste sistema coloca de forma prtica e legvel os resultados encontrados na anlise das coletas de dados. Isto , aprova a especificao realizada para o funcionamento nominal do sistema e apontam os limites em relao ao nmero de dispositivos, taxas de comunicao, configuraes de softwares de superviso, entre outros parmetros, alm de ditar, baseando-se nos testes de plataforma, quais as melhores formas de se adequar o sistema a uma futura expanso. Um exemplo claro disso pode ser exposto atravs da avaliao do critrio de Tempo entre as requisies de atualizao de estado, que se mostrou sensvel ao nmero de servidores operando em comunicao simultnea, sugerindo a implantao de clientes de superviso, em detrimento adio de novos servidores de superviso em caso de ampliao do sistema. 5. Concluso Neste trabalho foi apresentada a metodologia para testes de desempenho de sistemas SCADA. O resultado da anlise dos dados obtidos no teste possibilita direcionar a implementao dos sistemas e determinar os seus limites quanto expanso, sugerindo alteraes quando necessrio, que vo desde pequenos ajustes em aplicativos (supervisrio, CLP, e.g), chegando at a reformulao da arquitetura, garantindo assim o desempenho satisfatrio do sistema e disponibilizando informaes para expanses futuras da planta. O estudo prov, ainda, que um documento referncia seja gerado, norteando as futuras expanses e impondo limites de utilizao confivel da estrutura SCADA. Alm disso, em caso de problemas posteriores ligados ao desempenho, permite que a equipe de manuteno exclua as causas ligadas utilizao do sistema em regime indevido (diferente do especificado ou fora do limite de expanso determinado).

6 - Referncias Bibliogrficas
14

V Congresso Rio Automao

Manual do software WireShark Manual do software iFIX 4.0 Manual do hardware CLP Siemens S7-300 Manual do hardware CLP Siemens S7-400 FONSECA, M.O.F. Desempenho de sistemas de automao mtricas e prticas, VIII Seminrio de Automao de Processos, Associao Brasileira de Metalurgia e Materiais. BRITTAIN, Hank Performance Assessment for Management, ISA Show Houston Fall 2003 MARQUES, R.M.M. Relatrio de Desempenho do Cimplicity Utilizando o Performance Monitor OPC Server Computer Networks, a systems approach, Larry and Peterson. Ed. Morgan Kaufmann 6.1 Referncias de Aplicaes Prticas FIAGRIL Sistema de Controle e Superviso do Biodiesel e Bacia de Tanques, Lucas do Rio Verde, MT. Metodologia aplicada para testes de desempenho antes da implementao do sistema de controle e superviso. AGRENCO Sistema de Controle e Superviso do Complexo Industrial de Extrao de leo de Soja, Biodiesel e Cogerao de Energia, Alto-Araguaia, MT. Metodologia aplicada para testes de desempenho antes da implementao do sistema de controle e superviso. Rede de Automao do Terminal da Ilha Guaba VALE Mangaratiba, RJ (Porto de Despacho de Minrio). Metodologia aplicada em diversos pontos da rede e provendo ganho expressivo em alguns critrios ao se implementar solues propostas.

15