Estrutura Analtica de Projeto (EAP) para projetos infra-estruturais em automao industrial integrada

Srgio Torres S Barretto (Petrobras) - sa.barretto@petrobras.com.br Cristiano Vasconcellos Ferreira (Cimatec) - cristiano@cimatec.fieb.org.br

Resumo A competitividade entre as empresas impe s mesmas uma necessidade cada vez maior de agilidade no fluxo de suas informaes. Quantitativos de produo e estoque, estatsticas de falhas e re-trabalhos ou quantidade de insumos consumidos em um processo so apenas alguns exemplos de informaes que influenciam no planejamento e nas decises estratgicas de uma empresa. Esta necessidade de rapidez na aquisio de informaes patrocina o conceito de automao integrada, que nada mais do que a simbiose das tecnologias em tempo real, pertinentes automao industrial e s tcnicas de desenvolvimento de sistemas, pertinentes disciplina de engenharia de software. Neste panorama, a questo da interoperabilidade ganha evidncia, j que as fontes de dados, instaladas na rea industrial das empresas, existem em sua heterogeneidade de padres e fabricantes. Isto faz com que a implementao da infra-estrutura, necessria para aquisio de dados, no seja executada de forma to trivial, necessitando da elaborao de um planejamento consistente como forma de reduzir os riscos de um projeto. Este documento tem como objetivo a apresentao de um modelo de uma Estrutura Analtica de Projeto (EAP), que atenda a projetos infra-estruturais destinados a aquisio de informaes, em tempo real, de uma planta de processo industrial. Palavras-chave: Planejamento de Projeto, Automao Industrial, Estrutura Analtica de Projeto. 1. Introduo Atualmente, a automao industrial uma realidade presente em muitas indstrias, facilitando a operao de plantas de processos, com a implementao dos sistemas supervisrios, que por sua vez so softwares destinados ao monitoramento e controle destas plantas (SILVEIRA & SANTOS, 1998). Processos industriais usualmente geram grandes massas de dados que so armazenados em repositrios especficos, conhecidos historiadores de dados de processo, que nada mais so do que bases de dados temporais. Dentre outras caractersticas, os historiadores de processo possuem a capacidade de armazenar grandes volumes de dados com respectiva ocupao de pequenos espaos em memrias de massa, isso graas aos eficientes algoritmos de compresso implementados por estes produtos. Estes dados so, em geral, utilizados pela equipe que gere o processo industrial, na alimentao de algoritmos de otimizao, cujo objetivo o aumento da eficincia do processo (TORRES & SANTOS & FONSECA, 2006). A diversidade de produtos de hardware e software, na rea de automao industrial, implementa um ambiente heterogneo nas plantas de processo das industrias, demandando uma certa complexidade em projetos de interoperabilidade, cujo objetivo a integrao entre as reas de gesto e operacional. Projetos com planejamentos deficientes tendem ao insucesso devido a intercorrncias que, se previamente analisadas, poderiam ser contornadas evitando muitas vezes perdas de produo ou prejuzos operacionais.

2. Reviso Bibliogrfica 2.1. Gerenciamento de Projetos 2.1.1. O Que um Projeto ? Para um melhor entendimento do que um projeto se fazem necessrios alguns questionamentos: por exemplo, a fabricao de um veculo um projeto? Inicialmente, pode parecer uma pergunta por demais simples, mas a resposta no, a fabricao de um veculo no um projeto. Segundo PMI (2004), um projeto um empreendimento temporrio cujo objetivo a gerao de um produto, servio ou resultado nico. Neste contexto, pode-se afirmar que a fabricao de um veculo um processo, uma operao continuada. Porm, o termo nico pode induzir a confuses, sendo assim pode-se considerar como projeto a elaborao de um modelo de determinado veculo, j que este empreendimento possui marcos bem definidos, tais como: datas de incio e fim, um elenco de atividades bem definidas com duraes determinadas, alm de uma lista dos recursos necessrios elaborao do produto. Segundo PMI (2004), a determinao das caractersticas e recursos necessrios gerao de um modelo de um produto se d atravs da elaborao progressiva, que consiste na execuo de etapas incrementais, especficas para o exame das necessidades e exigncias do produto do projeto, sendo estas necessidades monitoradas e atualizadas durante todo o ciclo de vida. Um projeto considerado bem sucedido quando atende, ou excede, as expectativas de seus stakeholders, que so as pessoas envolvidas com o projeto, ou seja, so pessoas que tem algo a ganhar ou perder com a consecuo do mesmo. Identificar os stakeholders no incio de um projeto uma tarefa importante, pois a descoberta tardia da excluso de uma pessoa, cuja funo fosse imprescindvel para o projeto, pode impactar e at mesmo inviabilizar a sua continuidade. Exemplos de stakeholders de um projeto: patrocinador do projeto, gerente do projeto, cliente, diretoria, gerentes executivos, gerentes de departamento, fornecedores, distribuidores, entre outros (HELDMAN, 2003). O atendimento s expectativas dos envolvidos pode ser considerada em trs dimenses basicamente: qualidade, custo e prazo. 2.1.2. O Que Gerenciamento de Projeto ? Aps a definio do que um projeto, e de seus stakeholders, no aconselhvel a conduo do projeto para sua fase de execuo sem antes elaborar um planejamento detalhado, caso contrrio corre-se o risco de, ao final do projeto, se ter um produto que no atenda s expectativas dos stakeholders. O gerenciamento de projetos um processo que envolve vrias atividades, incluindo planejamento, execuo e acompanhamento do progresso e desempenho do projeto (HELDMAN, 2003). 2.1.2.1 Fases do Gerenciamento de Projeto Independente da dimenso dos projetos, todos eles so divididos em fases e todos possuem um ciclo parecido. Por exemplo, no mnimo um projeto dever possuir uma fase de iniciao, uma ou mais fases intermedirias e um encerramento. O nmero de fases de um projeto depende de sua complexidade: quanto mais complexo, mais fases ele possui. O conjunto de todas as fases de um projeto recebe a denominao de ciclo de vida do projeto (HELDMAN, 2003). Segundo Heldman (2003), a concluso de cada fase fornece ao gerente do projeto e aos stakeholders uma perspectiva de avaliao, para determinar se o projeto deve avanar para a fase seguinte, ter anomalias diagnosticadas e corrigidas ou ser descontinuado. Em geral, o final de uma fase marca o incio da outra, sendo que o final de uma fase pode ser diagnosticado atravs da entrega de um ou mais resultados prticos especficos. Estes resultados podem incluir itens como documentos de elaborao, oramentos, desenhos

tcnicos, cronogramas, prottipos, entre outros, e devem ser tangveis e facilmente avaliados e comprovados. 2.1.2.2 Processos do Gerenciamento de Projeto PMI (2004) relaciona cinco processos para o gerenciamento de projetos que organizam e documentam todo o trabalho do projeto. A seguir faz-se uma breve aluso sobre cada um deles: Iniciao como o prprio nome j sugere, este processo ocorre no incio de um projeto, ou de uma fase do mesmo. Este processo confirma que um projeto, ou a fase seguinte do mesmo, deve ser iniciado. A iniciao tambm autoriza o comprometimento de recursos de uma organizao para execuo de um projeto ou fase. Planejamento um grupo de processos destinados formulao e reviso dos documentos utilizados durante todo o projeto. Este grupo de processos permite a identificao dos stakeholders e dos requisitos do projeto. O planejamento abrange todas as reas do gerenciamento de projetos, considerando oramentos, definio de atividades, planejamento de escopo, desenvolvimento de cronograma, identificao de riscos, recrutamento de equipe, planejamento de aquisies, dentre outras. Execuo grupo de sub-processos destinados a colocar em ao o planejamento de um projeto. na fase de execuo que o gerente de projeto aloca fisicamente e direciona os recursos comprometidos no planejamento, alm de enfrentar os conflitos de cumprimento de cronogramas. Controle este grupo de processos responsvel pela avaliao do desempenho verificando se o projeto est aderente ao seu plano. Se forem diagnosticados desvios, sero aplicadas aes corretivas a fim de sincronizar as atividades executadas com o plano do projeto. Este procedimento pode requisitar passagens adicionais pelo processo de planejamento para reajuste dos objetivos do projeto. Encerramento grupo de processos responsvel pela obteno do aceite e aprovaes formais dos stakeholders. Neste processo, so reunidas todas as informaes do projeto para referncias futuras. A anlise destas documentaes possibilitar a preveno de problemas em projetos futuros. 2.1.2.2.1 Planejamento de Projeto O planejamento um dos grupos de processos mais importantes de um projeto, pois quando bem feito ter uma contribuio significativa para o xito do mesmo. O primeiro dos processos de planejamento o planejamento de escopo, cuja sada, a especificao de escopo, a entrada para o seu segundo processo, que a definio de escopo. O planejamento de escopo tem suas entradas, ferramentas e sadas, dentre elas a j citada especificao de escopo e o plano de gerenciamento de escopo (PMI, 2004). Segundo Heldman (2003), mudanas no escopo de um projeto so eventos inevitveis e, como tal, devem ser gerenciadas. O plano de gerenciamento de escopo auxilia o gerente de projeto no tratamento destas mudanas, definindo um processo para incorporao ou tratamento das mesmas. J o PMI (2004) define como finalidade do plano de gerenciamento de escopo a anlise da confiabilidade e estabilidade do escopo do projeto, estabelecendo a probabilidade de mudanas no mesmo. A especificao de escopo tem por finalidade documentar as metas, os resultados prticos e os requisitos do projeto, para que sejam usados como linha base para futuras decises. A linha base do projeto, em caso de alteraes, permite a comparao com o que foi acordado no

incio do projeto, estabelecendo um entendimento, entre os stakeholders e a equipe do projeto, no que se refere aos requisitos e resultados prticos esperados. A especificao de escopo deve contemplar a justificativa para execuo do projeto, a descrio, to detalhada quanto possvel, do produto final, os resultados prticos esperados e os objetivos do projeto (PMI, 2004). Uma pesquisa realizada pelo Project Management Institute com mais de 80 empresas no Brasil dos segmentos de construo, finanas e seguros, petrleo, gs e energia, servios, tecnologia da informao, telecomunicaes, automobilstico, cosmticos e alimentcios, entre outros indicou que os problemas mais crticos so no cumprimentos de prazos e problemas de comunicao, como mostrado na figura 1. Portanto, o planejamento de projetos assume papel fundamental para atendimento das expectativas dos stackholders.

Figura 1- Problemas mais comuns ocorridos em projetos, segundo pesquisa do PMI.

Portanto, o planejamento de projeto fundamental, porque os projetos geralmente no terminam no prazo, ocorrem alteraes de escopo, ocorrem conflitos entre recursos humanos, os recursos so escassos, podem ocorrer problemas de qualidade, se tem dificuldade de integrar partes, ocorrem problemas de comunicao e todo projeto tem um risco associado. 2.1.2.2.1.1 Estrutura Analtica de Projeto (EAP) No processo de definio de escopo, segundo processo do grupo de planejamento, os resultados prticos so subdivididos em componentes menores e gerenciveis, no intuito de facilitar o planejamento das tarefas e atividades do projeto. Esta subdiviso em componentes menores denominada de decomposio. A decomposio aprimora alguns aspectos do planejamento, dentre eles, as estimativas, pois mais fcil realizar estimativas, de custo e prazo sobre componentes operacionais menores, do que realiz-las sobre resultados prticos maiores e mais complexos. A decomposio juntamente com os modelos de planos de estruturas compem as ferramentas e tcnicas do processo de definio de escopo, que trabalham em conjunto para facilitar a criao da EAP (HELDMAN, 2003). Segundo Heldman (2003), a morfologia de uma EAP semelhante a de uma rvore genealgica, j que formada de uma hierarquia de resultados prticos, resultados prticos subalternos e atividades decorrentes destes resultados. A hierarquia da EAP subdividida em vrios nveis. O nvel 1 a raiz da rvore e os demais nveis so resultantes da implementao da tcnica de decomposio, at serem geradas as atividades que, por sua vez, so eventos decorrentes de resultados que no podem mais ser mais decompostos. Na figura 2 pode-se observar uma EAP.

A meta da EAP subdividir o projeto at o momento em que seja possvel atribuir a uma pessoa, ou equipe especialista, a responsabilidade sobre um componente da rvore. Este nvel mais inferior de um ramo de resultados recebe a denominao de pacote de trabalho, observado no nvel 4 da EAP disposta na figura 2. As atribuies so mais bem resolvidas em nvel de pacote de trabalho, porm podem-se atribuir responsabilidades em qualquer nvel da EAP. Por exemplo, ainda na figura 2, pode-se atribuir a uma pessoa, ou equipe especfica, a responsabilidade pela execuo do resultado prtico 1 do nvel 2 e todos os seus desdobramentos. No nvel de pacote de trabalho de uma EAP onde ocorrem as estimativas de custo, tempo e recursos (HELDMAN, 2003). A EAP deve compor o escopo completo do trabalho necessrio para a concluso do projeto, o trabalho no includo em uma EAP est fora do escopo oficial do mesmo, isto pode induzir a estimativas inexatas de custo, tempo ou recursos. Definies deficientes de escopo podem levar a construo de uma EAP degradada que, por sua vez, resultar em custo final realizado mais alto do que o previsto, devido necessidade de adio de mais horas de trabalho ao projeto para a execuo do trabalho no planejado previamente (HELDMAN, 2003). Segundo Heldman (2003), em uma EAP os resultados prticos so representados como nomes prprios e as atividades atravs de verbos ou palavras que representem aes. Estas atividades no necessariamente tm que estar organizadas em ordem seqencial de execuo, pois as questes de ordenao e precedncia de atividades so pertinentes a um outro processo de planejamento, o desenvolvimento do cronograma, onde serviro de insumos as atividades geradas no pacote de trabalho da EAP.

Figura 2 Modelo de EAP

2.2. Automao Industrial No sculo XVIII, com o advento da Revoluo Industrial, a sociedade transcendeu de um modelo de subsistncia agrcola para um modelo sistematicamente industrializado, voltado ao consumo. A mquina substituiu o trabalho humano em diversos setores. Desde ento a produtividade ganhou projeo, determinando quais empresas sobreviveriam no mercado. Empresas que tivessem seus parques equipados com mquinas a vapor se sobressaiam mais que as concorrentes que se utilizassem somente de mo de obra (SILVEIRA & SANTOS,1998). A introduo do computador no processo industrial, na segunda metade do sculo XX, promoveu um novo enfoque para a competitividade, pois possibilitou a execuo de um melhor planejamento de controle da produo. A introduo do Sistema Digital de Controle Distribudo (SDCD), juntamente com a instrumentao eletrnica, facilitou a centralizao do controle de plantas de produo. A automao do processo viabilizou a integrao da planta industrial com a rea corporativa das empresas, estimulando o nascimento de um novo conceito: o da automao integrada. Esta, por sua vez, demandou alta disponibilidade de

comunicao de dados, por parte das empresas, para suportar o processamento distribudo. Define-se como automao todo sistema suportado por computadores, que substitua o trabalho humano, visando solues rpidas de baixo custo para atingir objetivos complexos. Este panorama estende do conceito de automao para: automao de escritrio, automao bancria, automao de aeroportos, automao industrial, entre outras, cada uma com estgios diversificados de complexidade e diferentes formas de implementao fsica (MORAES & CASTRUCCI, 2001). Uma planta de processo industrial possui diferentes nveis de automao, os quais esto representados na pirmide de automao descrita na figura 3. A seguir apresenta-se uma breve descrio dos nveis da pirmide de automao segundo Morais e Castrucci (2001): Nvel 1: a camada de controle, onde esto localizados os instrumentos e equipamentos da planta de processo, o cho de fbrica propriamente dito. Nvel 2: esta camada hospeda os softwares de superviso de processo. Nvel 3: constitudo por bancos de dados, responsvel pelo armazenamento das informaes disponibilizadas pelo nvel 2. Nesta camada, esto implementados os indicadores de produo e qualidade, estatsticas do processo e os algoritmos de otimizao. Nvel 4: aqui so elaborados a programao e o planejamento de controle da produo, com base nos dados de processo historiados no nvel 3. Nvel 5: o nvel de gesto da empresa. Nesta camada so executados softwares de apoio decisrio, gesto financeira, vendas, gesto de pessoal, entre outros. Definem-se aqui os planos estratgicos e de desdobramento de metas, baseados em informaes oriundas do processo industrial e tambm de mercado.

Figura 3 Pirmide de Automao Fonte: Moraes e Castrucci (2001)

A automao industrial est relacionada a sistemas dotados de realimentao e controle. Diante disto, outro conceito existente passa ento a ganhar evidncia: a otimizao, que consiste em anlise das sries histricas de variveis de processo, a fim de aumentar a eficincia da planta. Estas sries histricas so obtidas a partir de dados oriundos dos SDCDs, armazenados em historiadores de processos.

2.2.1. Historiadores de Processo Em um panorama automatizado, a eficincia de uma planta passa a ganhar vulto, j que isso pode ser traduzido como a maximizao da capacidade produtiva ao menor custo possvel. Diversas ocorrncias afetam a eficincia de uma planta de processo: o desgaste dos equipamentos, flutuaes nas especificaes dos insumos, alterao dos parmetros ambientais etc. O acompanhamento da eficincia de uma planta industrial apenas com base em informaes oriundas dos controladores e unidades de campo, instaladas no nvel 2 da pirmide de automao, seria uma atividade excessivamente extenuante. Os Plant Information Management System (PIMS), ou historiadores de processo, foram desenvolvidos para servirem de repositrios de dados utilizados pelos algoritmos de otimizao de processos industriais. Devido aos seus eficientes algoritmos de compresso (da ordem de 10:1), so capazes de armazenar grandes volumes de dados, por perodos mdios de at 15 anos, a um custo de memria de massa relativamente baixo. Estas ferramentas tambm tm a capacidade de recuperar dados armazenados com extrema eficincia, podendo, por exemplo, montar um grfico com dados histricos , de uma mesma varivel de processo, e compar-lo com valores atuais com extrema rapidez (TORRES & SANTOS & FONSECA, 2006). Os PIMSs integram o nvel 3 da pirmide de automao historiando dados, oriundos de diferentes fontes, formando sries histricas dos valores das variveis dos processos industriais. Os PIMSs, alm de possibilitarem a visualizao dos dados de processo em tempo real, tambm podem disponibilizar a informao em todos os nveis da pirmide, a partir do momento que qualquer usurio, devidamente autorizado, pode ter acesso a suas informaes da rea de processo (TORRES & SANTOS & FONSECA). Bosco (2003) afirma que, diante deste panorama, um PIMS tem duas funes bsicas em uma empresa: Promover a integrao entre as reas de gesto e operacional Armazenar as sries temporais das variveis de processo no intuito de facilitar o processo de otimizao de plantas industriais. 2.2.2. Automao integrada Nas ltimas duas dcadas, centenas de fabricantes, de hardware e software, introduziram no mercado uma diversidade de sistemas fechados e proprietrios. Este comportamento criou ento um problema: a dependncia tecnolgica, pois a partir do momento que uma empresa optava por determinada tecnologia de automao, as mudanas tornavam-se inviabilizadas por seu alto custo. Devido a isto, era ento mais barato continuar mantendo a linha tecnolgica escolhida. Outro aspecto a ser observado era que estes pacotes de automao proprietrios no conversavam com os sistemas corporativos das empresas, ou pelo menos a implementao destas interfaces no era executada de forma to trivial, dificultando a integrao das informaes operacionais e corporativas (GOMES, 2005). A necessidade de um planejamento global de produo mais preciso, aliado a informaes sobre limitaes operacionais e capacidade produtiva, passaram a ser essenciais para a elaborao de um planejamento estratgico e procedimentos gerenciais de uma empresa, facilitando tambm a concepo de novas tcnicas de controle operacional e administrativo (SILVEIRA & SANTOS, 1998). Este contexto estimulou a formulao do conceito de automao integrada que, como o prprio nome j diz, a integrao de informaes provenientes da linha de produo com dados dos sistemas corporativos, permitindo a obteno instantnea de informaes que antes levavam um tempo demasiado longo para serem geradas. Ainda de acordo com Silveira e Santos (1998), os diversos fabricantes de produtos para automao industrial partiram para o desenvolvimento de padres arquiteturais abertos que facilitassem a implementao da interoperabilidade, atributo indispensvel neste novo cenrio.

2.2.2.1. OLE for Process Control (OPC) O OPC um padro de interconectividade entre sistemas de controle de processo, desenvolvido a partir da tecnologia Object Linking Embedding (OLE) e mantido pela OPC Foundation, uma organizao sem fins lucrativos, integrada por centenas de empresas, cujo interesse a interoperabilidade entre fontes de dados heterogneas, pertinentes a plantas de processos industriais (OPC TUTORIAL, 2005). Uma rede de automao industrial composta de vrios dispositivos destinados ao monitoramento e controle do processo, entre eles: Controladores Lgicos Programveis (CLP), Interfaces Homem-Mquina (IHM), bases de dados e unidades de campo. As interfaces destes dispositivos podem ser implementadas atravs de conexes do tipo serial, Ethernet, rdio enlace, etc. que por sua vez operam sob sistemas operacionais diversos, tais como: Windows, VMS, DOS e Unix. Os ambientes proprietrios possuem um forte acoplamento entre seus dispositivos, o que impe aos seus usurios a necessidade de recorrerem aos seus fornecedores sempre que houver demandas por mudanas no modelo de processo implementado. O padro OPC, por ser uma arquitetura aberta, promove o desacoplamento entre dispositivos componentes do processo, modularizando o ambiente, tornando-o escalvel e facilitando a integrao de informaes (OPC TUTORIAL, 2005). A figura 4 dispe um ambiente de automao dotado de trs tipos distintos de fontes de dados: CLPs, bases temporais e IHMs. Para integrar este ambiente, foram desenvolvidas duas aplicaes, A e B, desenvolvidas em plataformas tambm distintas. Para conectar as fontes, as aplicaes utilizam drivers proprietrios, disponibilizados no mercado, sendo um driver para cada tipo de fonte de dados. Neste modelo arquitetural, observa-se que o mesmo dado de processo gerado duas vezes em cada fonte, acarretando impacto no seu desempenho. Este efeito tende a se agravar, a medida que se diversifica o nmero de plataformas de desenvolvimento que se conectam s fontes de dados (OPC TUTORIAL, 2005).

Figura 4 Arquitetura Proprietria

Figura 5 Arquitetura OPC

Na arquitetura disposta na figura 5, observam-se trs OPC Servers distintos, conectados um a cada fonte de dados. Estes servidores so em geral disponibilizados no mercado pelos prprios fornecedores das fontes. A camada de acesso a dados das aplicaes A e B, neste contexto, foi desenvolvida implementando interfaces OPC Clients, tambm disponibilizadas no mercado pelos fornecedores das plataformas de desenvolvimento de aplicaes. A conexo OPC Server/OPC Client, por ser derivada da tecnologia OLE, uma arquitetura cliente/servidor. Sendo assim, o dado de processo gerado na fonte apenas uma vez e disponibilizado pelo servidor para todos os clientes a ele conectados. Por este motivo, esta implementao arquitetural promove um aumento de desempenho em relao situao exposta na figura 4. Alm disso, este modelo demonstra-se ser mais escalvel, j que, para disponibilizar as informaes operacionais em um novo ambiente de desenvolvimento de sistemas, basta adquirir, do respectivo fornecedor, o OPC Client deste ambiente (OPC TUTORIAL, 2005).

3. Abordagem Proposta A abordagem proposta apresentada por meio do modelo arquitetural disposto na figura 6. Neste modelo, observa-se uma instalao onde sua malha de controle pode ser centralizada em um SDCD ou, distribuda pelas unidades de campo em uma arquitetura supervisria. Um PIMS implementado para o armazenamento das variveis do processo, as quais sero monitoradas pelo nvel 5 da pirmide de automao. A interface do SDCD/Supervisrio com o PIMS implementada atravs de um padro arquitetural OPC. Um OPC Server adquirido, do fornecedor do SDCD/Supervisrio e instalado na mquina de superviso, da mesma forma que adquirida um OPC Client, do fornecedor do historiador, e instalado no servidor PIMS.

Figura 6 Modelo arquitetura de automao integrada

Figura 7 EAP para projetos de Automao Integrada

Um projeto de automao integrada um projeto interdisciplinar, envolvendo uma srie de atividades, as quais citam-se os principais grupos: infra-estrutura de Tecnologia de Informao (TI), infra-estrutura de Telecomunicaes (TCOM), desenvolvimento de sistemas e segurana de informao. Neste documento, sero evidenciadas a instalao do PIMS e sua conexo com a camada de superviso, ou seja, ser focalizado o planejamento para viabilizao da infra-estrutura que possibilitar a comunicao entre os nveis 2 e 3 da pirmide de automao. Como se v na EAP disposta na figura 7, um projeto infra-estrutural de automao integrada, por tcnica de decomposio, pode ser subdividido em 5 resultados prticos, os quais compem o nvel 1 da EAP: levantamento, solicitao de propostas a fornecedores,

aquisies, testes e implantao. No nvel seguinte ao de levantamento, obtm-se o pacote de trabalho subalterno, que contm as atividades a serem executadas. Estas, por sua vez, recebero suas atribuies de responsabilidades e sofrero estimativas. Comportamento semelhante observa-se nos resultados de teste e implantao. J o resultado prtico solicitao de propostas a fornecedores pde ser decomposto em mais trs subgrupos de resultados, a citar: viagens, hardware e software, os quais, cada um, gera um pacote de trabalho no nvel seguinte; subdiviso similar ocorre em aquisies. A seguir, faz-se uma descrio dos resultados prticos de um projeto desta natureza e as atividades de seus respectivos pacotes de trabalho: Resultado prtico: levantamento Levantar requisitos: levantar detalhadamente todos os requisitos dos clientes, evidenciando suas expectativas com relao ao projeto. Tambm deve ser efetuado um levantamento de campo, mapeando toda infra-estrutura de superviso existente na planta de processo, disponibilidade de comunicao em rede, implantao de firewalls, espao fsico para os servidores, pontos estabilizados de energia eltrica, climatizao, etc. Definir arquitetura: de posse dos dados do levantamento, desenhar uma arquitetura que possibilite o armazenamento de dados do processo industrial. Nesta arquitetura deveram estar modelados todos os hardwares e softwares necessrios consecuo do projeto, levando em conta suas compatibilidades. Por exemplo, podem acontecer situaes, principalmente em supervisrios de verses antigas, em que haja a necessidade de adquirir sistemas operacionais que no sejam instalveis em mquinas atualmente disponveis no mercado. Sendo assim, tero que ser previstas no modelo mquinas compatveis com estes sistemas. Validar arquitetura: aps a modelagem arquitetural, devero ser mapeados todos os fornecedores envolvidos no modelo em questo, para posterior envio da arquitetura para validao dos mesmos. Os fornecedores analisaro o modelo e emitiro um parecer tcnico que o substancie, ou sugira alteraes. Estas devem ser implementadas pelo responsvel da atividade, repetindo este ciclo at a estabilizao do modelo. Resultado prtico: solicitao de propostas a fornecedores (viagens, hardware, software e servios) Solicitar propostas: aps a estabilizao do modelo arquitetural, devero ser solicitadas propostas de servios aos fornecedores. Nestas propostas, devero constar custos e prazos para entregas dos produtos, quer sejam eles hardware, softwares ou servios contratados, tais como: servios de instalao e configurao de hardware ou software. Nos casos de contratao de servios, devero constar nas propostas todos os custos de deslocamento e hospedagens. importante que as propostas enviadas contemplem garantias de que os produtos adquiridos sejam aderentes ao modelo arquitetural enviado previamente. Nas propostas, tambm devero ser especificadas as compatibilidades dos hardwares e software constantes no modelo arquitetural. Os pacotes de trabalho da figura 7 exemplificam algumas das atividades que compem este resultado prtico, necessrio implementao de um padro arquitetural OPC. Porm, de acordo com o resultado do levantamento, mais aquisies podero ser determinadas para o projeto. Resultado prtico: aquisies (contrato de suporte) Contratar suporte PIMS: esta atividade necessria continuidade operacional do PIMS, logo, dever ser prevista, cotada junto ao fornecedor do PIMS e efetivamente contratada at o final do projeto.

Resultado prtico: aquisies (hardware, software, contrato de suporte) Comprar produtos: devero ser acionadas todas as compras: hardware, software e servios. Todos os produtos determinados no modelo arquitetural devero ser adquiridos obedecendo aos critrios descritos nas propostas enviadas pelos fornecedores identificados no projeto. Na figura 7, descrevem-se algumas aquisies necessrias implementao de uma arquitetura OPC. Resultado prtico: teste Testar servio PIMS: devero ser solicitadas e testadas verses de teste do servidor PIMS, para comprovao da compatibilidade do software com o hardware especificado no modelo. Em casos de anomalias diagnosticadas, as garantias das propostas enviadas pelos fornecedores envolvidos no diagnstico devero ser acionadas, a fim de se identificar as causas e solucionar os problemas isolados. De acordo com o resultado dos testes, alteraes podem ser sugeridas no modelo arquitetural. Testar conexo OPC Server e Client: estabilizada a configurao da infra-estrutura do PIMS, deve-se solicitar ao fornecedor do mesmo uma verso de teste do seu OPC Client e providenciar junto ao fornecedor do supervisrio/SDCD uma verso de teste do OPC Server. Deve ser viabilizado o teste de conexo dos dois servios para verificar a aderncia do resultado obtido com o descrito nas propostas de ambos os fornecedores. Em caso de constatao de anomalias, procedimento idntico ao descrito na atividade testar servio PIMS deve ser seguido. Resultado prtico: implantao Instalar Produtos: aps a concluso das atividades citadas anteriormente, devem ser instalados em produo os hardwares definitivos, os softwares que provem os servios OPC Server e Client e efetuada a configurao dos mesmos, tudo executado segundo as especificaes do modelo arquitetural atualizado. Se por um acaso ainda for diagnosticada alguma anomalia, devero ser acionadas as garantias constantes em propostas e registro da anomalia para futuras ocorrncias. Na EAP disposta na figura 7, exemplificam-se algumas atividades para implantao em produo de um modelo arquitetural OPC. 4. Consideraes e Direes para Futuras Pesquisas O modelo de EAP proposto para projetos de automao integrada est sendo implantado na Petrobras S/A, empresa brasileira de prospeco de petrleo e produo de energia, por seu segmento TI regional Bahia/Norte, facilitando a centralizao de dados de vrias unidades de processos, dispersas pelo territrio nacional, em um nico PIMS, com disponibilizao de informaes em arquitetura aberta. O modelo de EAP proposto pressupe que estejam cumpridos todos os requisitos de TCOM (disponibilidade de rede, interfaces de comunicao com a camada de superviso, etc.), segurana de informao (firewalls, esquemas de antivrus, redundncias, no-brakes,etc.), fontes estabilizadas para alimentao de energia eltrica, espao fsico e climatizao. Durante o levantamento, se forem constatadas no conformidades em qualquer um destes requisitos, ou quaisquer outros que por ventura venham a ser diagnosticados, isto implicar na necessidade do detalhamento dos mesmos, na EAP proposta, na forma de novos resultados prticos de primeiro nvel. Apesar do OPC ser um padro arquitetural apoiado e divulgado pela OPC Foundation constatou-se, durante os projetos de implantao infra-estrutural, nuances entre as conexes OPC Servers e Client, dos diversos fornecedores de sistemas de superviso. Foram observadas diferentes configuraes de hardware e vrias questes pertinentes compatibilidade de software, dependendo do sistema de superviso instalado na planta

operacional a qual se desejava adquirir os dados de processo. Isto faz com que os resultados prticos relacionados modelagem arquitetural e validao dos fornecedores, incluindo suas garantias, tenham uma maior relevncia no planejamento do projeto, pois incompatibilidades verificadas na execuo, aps a aquisio dos produtos e sem garantias especficas, podero onerar os custos de realizao do projeto a tal ponto de poder causar o cancelamento do projeto. Embora no seja foco deste documento, no conformidades relacionadas com questes de segurana devem ser tratadas com mxima prioridade no projeto, j que antes do advento da automao integrada, os nveis 1 e 2 da pirmide de automao eram naturalmente isolados dos nveis restantes. Os projetos de integrao, por sua vez, promovem uma conexo fsica entre as redes de automao e corporativa. Sendo assim, First Process Control & SCADA Security Summit (2006) orienta que cuidados tm que ser tomados no que se refere aos controles de acesso s redes, incluindo acesso fsico, implementao de polticas de antivrus, monitoramento e defesa contra intrusos. Este item pode se demonstrar por demais complexo podendo gerar um projeto s para a rea de segurana. Sendo assim, direciona-se este planejamento para trabalhos futuros, bem como algumas questes, as quais se encontram dispostas a seguir: detalhamento do processo de elaborao do cronograma de projetos relacionados automao integrada; Planejamento de desenvolvimento de aplicaes que disponibilizem em arquitetura portvel dados de processos industriais conjugados com dados corporativos.

Referncias Bibliogrficas BOSCO, Flvio. O que vem depois do SDCD. Revista Petro & Qumica. N. 247, abr. 2003. Disponvel em: <http://www.editoravalete.com.br/site%5Fpetroquimica/edicoes/ed_247/ ed_247.html>. Acesso em: 06 mai. 2007. FIRST PROCESS CONTROL & SCADA SECURITY SUMMIT 2006, 01., 2006, FloridaUSA. Anais... Florida:SANS Institute, 2006. 1v. GOMES, Bruno Souza. Integrao industrial, a terceira revoluo. Rio de Janeiro, mai. 2005. Disponvel em: <http://www.firjan.org.br/notas/media/integrind.pdf>. Acesso em: 07 jun. 2007. HELDMAN, Kim. Gerncia de Projetos. 3.ed. Rio de Janeiro:Editora Campus, 2003. MORAES, Ccero Couto de.; CASTRUCCI, Plnio de Lauro. Engenharia de Automao Industrial. 1.ed. Rio de Janeiro: LCT, 2001. OPC TUTORIAL. Understanding OPC. Matrikon, 2005. 6 mdulos (20 min), son., color. Disponvel em: < http://www.matrikonopc.com/resources/opc-tutorials.aspx>. Acesso em: 15 mar. 2007. PMI. PM-BOK Guide. 3.ed. Pennsylvania:PMI, 2004. SILVEIRA, Paulo R.; SANTOS, Winderson E. Automao e Controle Discreto. 5.ed. Tatuap: rica, 1998. TORRES, B. S.; SANTOS, D. G. dos; FONSECA, M. de O. Implementao de estratgias de controle multimalha utilizando a norma IEC 61131-3 e ferramentas PIMS. Disponvel em: <http://plcopen.org/pc2/Implementing_Multiloop_Control_Strategy_using_ IEC61131.PDF>. Acesso em: 06 nov. 2006.