Sie sind auf Seite 1von 97

Sistema de Automao de Processo Colaborativo

1.1. Introduo
A automao de processos industriais suporta a estocagem, transporte e transformao de matrias primas em produtos uteis. (Ver Fig. 1.1).

Fig. 1. Processo tpico

Processos podem ser classificados como contnuos ou bateladas. Processos bateladas so caracterizados pela produo de uma dada quantidade de produto em etapas (e.g., bolos ou cerveja ou remdios). Processos contnuos transformam matrias primas em produtos acabados ou semiacabados usualmente em um processo uniforme, sem transitrios ou etapas. Processo contnuo: refinaria de petrleo, papel e celulose, minerao, gerao de energia eltrica. Sensores so usados para obter informao acerca do processo e atuadores podem ser usados para influenciar o processo. Automao de processo geralmente mostrada em pirmide com vrias camadas. (Ver Fig.1. 2). Tais pirmides relacionam a hierarquia de gerenciamento de uma empresa e mostra como a informao cada vez mais condensada.

Fig. 1.2. Pirmide de automao

No nvel mais baixo da pirmide, esto as medies das variveis do processo, tais como presso, temperatura, vazo e nvel, que trata dos valores numricos. Nos nveis mais elevados tratase de conceitos como controle, qualidade, programao, produtividade. Nos nveis inferiores

trabalha-se em tempo real, com tempos de respostas de segundos e at milissegundos e nos nveis superiores os tempos de respostas aumentam, podendo estender de horas at semanas. O fato crucial e que vrias camadas diferentes, com diferentes exigncias existem e requerem a interao todos entre si. A norma srie ISA S-95 contem a definio mais aceita das diferentes camadas de automao. (Fig. 1.3). Em muitas reas de aplicao os algoritmos de controle so desenvolvidos e o algoritmo relativamente simples PID suficiente para a maioria das tarefas de controle. Enquanto o controle nos nveis 2,1,0 bem administrado, a integrao dos nveis mais altos agora se torna cada vez mais importante na tarefa de otimizao da produo.

Fig. 1.3. Nveis de um modelo hierrquico funcional da ISA S-95

A maior alterao na melhoria do desempenho de planta futura vir da maior importncia do operador. O operador est se tornando um trabalhador do conhecimento com o poder da informao. Esta proliferao da informao est permitindo as estruturas organizacionais fiquem planas, transferindo a autoridade e responsabilidade associada com a distribuio da informao para nveis mais baixos. Um maior grau de coordenao nos nveis mais baixos , portanto requerido. Outro fator importante na melhoria do desempenho da planta est fornecendo uma plataforma unificada para a produo e manuteno que tambm automatiza as transaes entre o sistema de automao e o Sistema de Gerenciamento da Manuteno Computadorizada (CMMS). Como as capacidades dos sistemas convencionais de controle distribudo (SDCD) no so mais suficientes para cobrir todas as reas relevantes da automao do processo, uma nova gerao de sistemas foi criada. O conceito de Sistema de Automao de Processo Colaborativa (CPAS) foi desenvolvido pela Automation Research Corporation (ARC). Um aspecto chave de um CPAS a habilidade de apresentar a informao em contexto para a pessoa certa, no tempo certo de qualquer ponto dentro do sistema, para incluir um nico ambiente, unificado para a apresentao da informao para o operador. Alm disso, uma vantagem chave de um CPAS a habilidade de estender seu alcance alm das capacidades tradicionais de um SDCD para incluir funes tais como gerenciamento da produo, segurana e controle crtico da produo, controle avanado, 2

gerenciamento da informao, instrumentao inteligente, drivers inteligentes, centros de controle de motores, gerenciamento de ativos e gerenciamento da documentao. A instrumentao inteligente inclui microprocessador digital que tem uma funcionalidade muito mais do que apenas medir, mas sua funcionalidade inclui gerenciamento do instrumento, calibrao, autodiagnstico. Segurana e controle esto interligados e incorporados dentro da mesma arquitetura, fornecendo um ambiente de sistema com alta integridade comum para o controle da produo, superviso da segurana e monitorao da produo. Esta arquitetura fornece a opo de combinar as funes de controle e segurana dentro do mesmo controlador ou mantendo as funes de controle e segurana separadas dentro do mesmo sistema. Com aplicaes de segurana e processo executando dentro do mesmo ambiente do sistema, e mesmo dentro do mesmo controlador, um CPAS pode oferecer segurana, interao instantnea entre aplicaes. As caractersticas importantes do CPAS incluem: 1. Extensvel 2. Modelo de dados comum 3. Adaptvel atravs de configurao 4. Verso simples da verdade 5. Interopervel 6. Adoo padro 7. Suporte multifornecedor 8. Segurana e confiabilidade 9. Suporte do contexto acionvel 10. Suporte do conhecimento no local Os vrios fornecedores de programas podem gerenciar parte da funcionalidade do sistema, mas nenhum fornecedor de programa capaz de gerenciar o escopo inteiro de um CPAS. Assim o projeto da arquitetura de aplicao crucial para o sucesso do projeto. As tendncias mais importantes que promovem mudana no desenvolvimento da automao incluem: 1. Globalizao 2. Economia em rede 3. Desenvolvimento sustentvel.

1.2. Indstrias e utilidades


Introduo
O foco deste trabalho a automao de processos industriais. Muitos desses processos transformam matrias primas (como madeira, ferro, ouro, leo cru, nafta) em produtos refinados (como papel, ao, gasolina, etileno). Usualmente isso feito por produo contnua em grande escala e essas indstrias so chamadas de indstrias pesadas. Geralmente, fluxos de materiais correm 24 horas por dia. Outro tipo de processo o de batelada, onde os ingredientes so processados em vasos e depois movidos para a prxima fase de produo, como em indstria farmacutica, de alimentos e bebidas. Produo de leo cru e minerao so exemplos de processos de transporte, no transformativos, que tambm so controlados por um CPAS. A automao de processos industriais usualmente requer uma grande quantidade de sinais analgicos e malhas de controle fechadas. Os modelos de processo so geralmente complexos, baseados em equaes diferenciais no lineares. Em muitos casos os modelos suficientemente precisos desses processos no podem ser obtidos com esforo razovel e por isso so aplicadas malhas de controle fechadas baseadas em realimentao negativa.

Energia eltrica
Plantas de gerao de energia eltrica transformam combustveis fosseis, combustveis nucleares ou energia renovvel como vento ou gua em energia eltrica. Modernas estaes de produo de energia com baixa emisso de gases formam o futuro da gerao de energia eltrica. Uma planta tpica de 770 MW queima 55 kg de carvo por segundo em uma temperatura de 1350 oC, com uma eficincia tpica de 50 %. Essa planta deve satisfazer vrias exigncias relacionadas com eficincia, segurana, no poluente, pequena emisso de CO2. Essas exigncias s so conseguidas com automao correta.

leo e gs
A indstria de petrleo pode ser dividida nos seguintes segmentos: Upstream (Explorao e produo) Explorao, desenvolvimento e produo de leo cru e gs natural. As caractersticas tpicas so: 1. Ambiente hostil e adverso, 2. Limites de temperatura extremos 3. Espao limitado. Cada vez mais operaes de plataforma (offshore) so supervisionadas remotamente de centros de operao em terra (on shore). Exigncias requeridas: 1. Alta segurana 2. Mxima disponibilidade 3. Extrema robustez 4. Projeto compacto, modular e escalvel. Downstream (Refino) Tanques de armazenamento de leo, refinarias, distribuidores e consumidores. Refinarias convertem leo cru em componentes como: gasolina, leo diesel, querosene, leo combustvel, asfalto, etc. As refinarias devem operar na mxima capacidade sem qualquer interrupo por longos perodos de tempo. Uma grande refinaria pode produzir 300 L de gasolina por segundo. CPAS ajuda a garantir a eficincia de operao e caratersticas do produto, segurana e com o mnimo de poluio e emissores de CO2. Pipelines Oleodutos movem leo cru dos poos em terra ou plataformas no mar para terminais e refinarias e depois movem os derivados de petrleo para os postos de distribuio e consumidores.

Transporte martimo Esse segmento envolve todos os aspectos de transportar o petrleo e seus derivados por gua, incluindo operaes do porto, combate a incndio no navio e a resposta a vazamentos. Os navios petroleiros e metaneiros fazem parte desse segmento.

Polos petroqumicos
O petrleo e seus derivados so tambm matrias primas para muitos produtos qumicos, incluindo farmacuticos, solventes, fertilizantes, pesticidas e plsticos. O gs natural liquefeito (GNL) gs natural que foi convertido para a forma liquida para facilidade de armazenamento e transporte. Polo petroqumico um conjunto de indstrias interligadas por tubulaes, quando e onde uma indstria fornece matria prima para outras indstrias. O ncleo seminal de um polo petroqumico sua Central de Matrias Primas, cuja matria prima a nafta e cujos produtos finais so o etileno e aromticos, que sero matrias primas para as indstrias de segunda gerao. Os produtos das indstrias de segunda gerao sero matrias primas para as indstrias de terceira gerao, chamadas de indstrias de transformao. Em um polo petroqumico, CPAS ajuda a otimizar operaes, eliminar perdas, melhorar a qualidade, fazer a medio dos produtos transferidos entre as diferentes indstrias do polo e fazer a comunicao de informao e satisfazer as exigncias legais de meio ambiente.

Indstria Qumica
Em 2007, a produo total da indstria qumica foi estimada em pouco mais de US$ 3 trilhes (ICCA, 2008). A indstria petroqumica iniciou a revoluo de plsticos e materiais: qumica fina e especial com uma grande variedade de produtos, tanto para itens do consumidor como para aplicaes industriais, incluindo ingredientes ativos para proteo de agricultura e intermedirios para farmacuticos. Tinturas sintticas para produo txtil. O maior crescimento ocorre na sia emergente (China, Coreia) As estratgias efetivas da indstria qumica e petroqumica so: Oferecer produtos e novos e melhorados Oferecer produtos de qualidade Oferecer produtos personalizados Melhorar servio do comprador Estabelecer grandes sites integrados de fabricao. Essas companhias precisam melhorar seus processos de fabricao, que incluem melhor engenharia, melhor automao, integrao maior entre fabricao e negcios e melhor utilizao dos ativos de fabricao. Todas essas melhorias s podem ser conseguidas atravs de melhor automao atravs de CPAS. Outras indstrias envolvem Bebidas e Alimentos, Minerao e Siderurgia, Farmacutica, Papel e Celulose, gua e efluentes, Cimento

1.3. Histria dos Sistemas de Automao de Processo


Introduo
Historicamente, a produo de bens como papel ou ferro foi feita manualmente por artesoes e envolvia pouca ou nenhuma automao. Mais tarde, a energia elica (vento) e da gua foi transformada em energia rotacional, que foi a primeira fase da automao. Equipamentos de processo, tais como vlvulas tinham que ser operados manualmente e instrumentos locais, como termmetros e manmetros eram lidos diretamente pelos operadores. A inveno da mquina a vapor no sculo XVIII foi uma base importante da industrializao. Mais tarde, controladores pneumticos (1940) e eletrnicos (1950) foram introduzidos. Por volta de 1800, foi inventado um sistema com cartes perfurados para controlar o projeto de txteis produzidos, por Jacquard Loom. O elo com processo de batelada controlado por computador digital moderno j est claramente visvel. Aps a inveno do computador eletrnico digital, circa 1950, foi introduzido o sistema de controle baseado em computador. A automao com controladores computadorizados foi desenvolvida em trs diferentes ramos: Na indstria automobilstica (processo discreto) com o uso do Controlador Lgico Programvel (CLP) (1968). Enquanto isso, foi introduzido na indstria petroqumica o primeiro sistema com Controle Digital Distribudo (SDCD) (1973) e o Controle Supervisrio e Aquisio de Dados (SCADA) (1984) veio para atender um nicho de mercado com processos menores e mais simples. Os sistemas tinham muito em comum, mas as exigncias e caractersticas das indstrias automobilstica e petroqumica eram muito diferentes e as solues foram historicamente diferentes: SDCD usado para controlar processos grandes e complexos, com muitas malhas de controle fechadas com algoritmo PID, como refinarias e polos petroqumicos. SCADA para controlar processos simples, com muito controle discreto e poucas malhas de controle PID, como transporte de fluidos, processos de batelada, distribuio de energia eltrica e distribuio de gua. CLP para fazer controle discreto, tipicamente para fazer o alarme e intertravamento de todos os processos envolvidos, grandes e pequenos, simples e complexos. O CLP foi beneficiado pelas exigncias legais que no permitem que o mesmo sistema faa o controle e a sua segurana. Atualmente, as tecnologias de rede e computador digital esto consolidadas e dominadas e os limites entre as aplicaes de SDCD e SCADA esto confusos. Cada rea tem suas exigncias especficas, mas todas compartilham um grande conjunto de exigncias comuns que podem ser suportadas pela mesma tecnologia.

Controlador Lgico Programvel (CLP)


Em 1968, General Motors fez uma concorrncia pblica de um sistema eletrnico que substitusse os circuitos lgicos feitos por reles eletromagnticos, que eram usados comumente em automao. Em resposta e ganhando a concorrncia, a Modicon (Modulalr Digital Controller) desenvolveu o primeiro oCLP. O CLP a tecnologia industrial mais longeva e bem sucedida da histria da automao moderna. Uma das linguagens usadas para programar um CLP a chamada lgica ladder, que tenta diretamente emular as conhecidas estruturas lgicas ladder baseadas em rel. Um CLP modular (Fig. 1.7) combina um mdulo CPU com um nmero flexvel de mdulos de entrada analgicos ou discretos atravs de um barramento backplane. Entradas digitais entram atravs da porta de comunicao da CPU ou atravs de mdulo de comunicao digital. Como a entrada digital bidirecional ( entrada e sada simultaneamente) ela no possui mdulo de entrada ou mdulo de sada, mas mdulo de comunicao digital. Um CLP projetado para mltiplos arranjos de entrada e sada (i/o), faixas estendidas de temperatura, imunidade a rudo eltrico e resistncia a vibrao. (Fig. 1.8). Programas para controlar o processo ou a mquina so tipicamente armazenados em memria no voltil (EEPROM).

Fig. 1.7. CLP modular

No ncleo central de um CLP h uma ou vrias unidades CPU (Unidade Central de Processamento). O CLP recebe medies do processo atravs dos mdulos de entrada. Os resultados da lgica de controle so ento escritos para os cartes de sada. Uma alternativa integrar as redes de campo digitais. Dependendo do tamanho do processo, determina-se o nmero de mdulos de entrada ou sada. Um CLP no possui interface humano mquina (IHM), nem teclado, nem monitor, nem drive de disco rgido ou mouse e projetado para rodar sob condies industriais. O programa lgico de controle usualmente desenvolvido em um equipamento de programao (que pode ser um notebook ou laptop). Este programa ento carregado (uploaded) no CLP no incio e depois pode ser reprogramado. O CLP opera separado e independente desse programador. Cada ciclo de um programa do CLP (Fig. 9) comea com a leitura dos valores de entrada dos mdulos de entrada na memria. No passo seguinte, o programa lgico executado. Finalmente, os valores das variveis de sada so escritas nos mdulos de sada. Os tempos de varredura diferem entre as indstrias, mas um segundo um tempo tpico para um ciclo ou varredura (scan). Se mais passos de programa precisam ser executados do que o realizado em um ciclo, mdulos adicionais ou mais rpidos precisam ser introduzidos. Uma associao multivendedor sem fins lucrativos, PLCopen (http://www.plcopen.org) promove o desenvolvimento de programas compatveis para CLPs. O principal foco da PLCopen a norma IEC 61 131-3. (Ref. 4).

Fig. 1.9. Execuo cclica do CLP 7

Fig. 1.11. Gaveta com fonte, CPU e mdulos de entrada sada do CLP

Sistemas de controle distribudos (DCS)


O primeiro sistema com computador de controle industrial foi usado pelo Texaco Co. em Port Arthur, TX, em uma refinaria com um RW 300 da Ramo-Wooldridge, em maro de 1959. O controle era feito atravs de uma malha fechada de controle. A primeira proposta seria para controle digital direto de uma planta qumica inteira, sem uso de qualquer sistema de controle intermedirio analgico, eletrnico ou pneumtico, foi feito pela ICI (Imperial Chemical Industry) no incio dos anos 1960. O primeiro sistema digital de controle distribudo foi introduzido pela Honeywell em 1973, que veio substituir o sistema analgico da Foxboro, tambm distribudo e modular, chamado de SPEC 200. A partir do TDC 2000, o SDCD se tornou a tecnologia padro para controle de grandes e complexos processos industriais, como polos petroqumicos, refinarias de petrleo, siderurgias e minerao. Os primeiros SDCDs eram sistemas fechados, monolticos de um nico fornecedor; o que raramente acontece atualmente. Alm dos controladores de automao, um SDCD inclui servidores de aplicao, tais como historiador de processo, vrias estaes de trabalho, redes e outros mdulos necessrios para formar um sistema completo (Ver Fig. 1.10 e Fig. 1.11).

Fig. 1.10. Sistema digital de controle distribudo

Fig. 1.11. SDCD integrado ao sistema de industrial e de negcios

Os avanos rpidos nas tecnologias de hardware e software tem tornado difuso o limite entre os sistemas descritos como SDCD e SCADA (CLP + PC). Por exemplo, a programao conforme IEC 61 131-3, que se originou do CLP e tambm aplicada em SDCD. (Fig. 1.12).

Fig. 1.12. Conceitos de separao do SDCD e SCADA (CLP + PC)

Controle Supervisrio e Aquisio de Dados (SCADA)


O sistema de Controle Supervisrio e Aquisio de Dados (Supervisory Control and Data Acquisition SCADA) usado para controlar processos em tempo real que so geograficamente distribudos, como oleodutos, distribuio de energia eltrica, distribuio de gua e redes de gs natural. SCADA tambm usado para controlar processos pequenos como produo e transporte de leo e gs natural, unidade de regenerao de gs natural, que ainda so plantas muito menores e mais simples do que aquelas controladas por SDCD. Historicamente, sistemas SCADA coletam dados analgicos e discretos de terminais remotos (RTU Remote Terminal Unit), geralmente sobre conexes de banda estreita como linhas de telefone e transfere instrues simples de uma unidade terminal mestre (MTU master terminal unit) para uma RTU. A transferncia feita atravs de uma infraestrutura de comunicao confivel e rpida, como via rdio ou satlite, distancias geogrficas requerem arquiteturas cada vez menos especiais. No futuro, a diferenciao entre CLP, SDCD e SCADA ficar cada vez menos ntida. Cada uma dessas tecnologias tem suas razes histricas em diferentes domnios, mas as exigncias gerais que devem ser satisfeitas por cada uma fica cada vez mais igual.

Sistema de Automao de Processo Colaborativo (CPAS)


Hoje, as plantas exigem sistemas oferecendo mais do que apenas controle distribudo. Estes sistemas devem ser capazes de integrar todos os tipos de aplicaes relevantes, como Controle de Processo Avanado ou Gerenciamento da Informao e para suportar um alto nvel de colaborao.

10

1.4. Sistema de Automao de Processo Colaborativo (CPAS)


Introduo
O conceito CPAS (Collaborative Process Automation System) a viso do grupo ARC (Automation Research Corporation) de como sistemas de automao de processo devem mudar e desenvolver atravs da dcada atual. Ele no descreve nenhum particular sistema disponvel comercialmente. A tecnologia usada em CPAS disponvel e testada e aprovada, ela no est em tudo disponvel em qualquer oferta particular, mas disponvel atravs de todos os sistemas. Inicialmente, CPAS deve ser considerado como um ambiente que permite aplicaes incluindo Controle de Processo, Controle Avanado de Processo e Gerenciamento de Operaes complementadas por aplicaes humanas importantes tais como suporte de deciso e anlise avanada. CPAS vai de sensores e atuadores at interfaces ERP (Enterprise Resource Planning) e para ficar simples e descomplicada, ela no reconhece programas tais como MS ou IHM do SCADA como subsistemas, mas, em vez disso, CPAS enderea tais como classes de aplicao. Dentro das restries da norma de programao e configurao IEC 61 131-3, CPAS incorpora um nico modelo com processamento distribudo. CPAS acionado por dados, todos digitais e baseados em normas internacionais verdadeiras. CPAS inerentemente robusto, possui alta exatido com baixo custo total de propriedade (Total Cost of Ownership TCO) e suporta um alto nvel de colaborao.

Trajetria do CPAS
CPAS o produto de vrias dcadas de evoluo tecnolgica da automao de processo, cada um com suas caractersticas e foco especficos. (Fig. 1.12)

Fig. 1.12. Evoluo de sistemas de automao

CIM Fabricao Integrada por Computador (1960) A discusso da viso CPAS comea com a introduo da Fabricao Integrada por Computador (CIM Computer Integrated Manufacturing). Isto foi frente de seu tempo e foi largamente um exerccio acadmico porque as tecnologias de computador e redes ainda no conseguiam suportar essa tecnologia. Ela era focada em aplicaes supervisrias e seu principal valor era validar o que fosse possvel e estabelecer o estagio para futuros desenvolvimentos.

11

SDCD - Sistema Digital de Controle Distribudo (1970) A dcada centrada em sistema trouxe o microprocessador e automao distribuda do processo na forma do primeiro sistema digital de controle distribudo (SDCD). Ele marcou a transio do analgico para a tecnologia digital mais precisa e poderosa e utilizou comunicao com passagem de tokem IEEE 802.4 por causa de seu determinismo. Estes sistemas eram essencialmente proprietrios por natureza, com comunicao fechada. Dcada de sistemas abertos centrados em rede (1980) A prxima dcada comeou a enderear a natureza proprietria dos sistemas e trouxe o sistema aberto centrado em rede com muito da tecnologia associada desenvolvida pelo Departamento de Defesa dos EUA. Foi desenvolvido o primeiro sistema operacional aberto baseado em norma, Unix. E mais importante, foi criada o estado da arte da tecnologia de rede baseada em norma, a Ethernet TCP-IP IEEE 802.3. Alm de utilizar a passagem de tokem, ela utiliza algoritmo de coliso. Esta tecnologia de rede possibilitou a computao cliente-servidor e a Internet e o CPAS com acesso global aos dados. A maioria dos fornecedores de sistemas de automao demorou em usar Ethernet porque eles assumiam que ela no era determinstica suficiente. Mais tarde foi provado que isso no era o caso. Esta dcada viu a introduo do primeiro Historiador de Dados de Processo comercialmente disponvel e como a maioria dos sistemas de controle de processo no usavam Ethernet, a maioria dos sistemas se tornaram centrados no historiador com relao ao acesso dos dados para aplicaes supervisrias. A ethernet TCP-IP se tornou presente em todos os lugares como o estado da arte da infraestrutura de rede para automao de processo e sistemas empresariais. Dcada centrada na Aplicao (1990) Uma fundao comum para rede tornou possvel incorporar informao e controle de processo no mesmo ambiente de aplicao e assim tornou possvel a prxima dcada centrada na Aplicao. Ela tambm herdou o desktop Windows da Microsoft como veculo de apresentao. Isto marca o ponto na evoluo da automao tecnolgica do processo onde o foco muda da tecnologia centrada em rede para a tecnologia que facilita o uso de aplicaes. Muitos avanos nesta dcada foram construdos com a tecnologia Internet. Provavelmente o mais importante como a Ethernet e TCP-IP possibilitou o conceito de Infraestrutura de Informao Comum. Em essncia, isso colapsou a arquitetura convencional do SDCD em uma rede comum permitindo o controle de processo e as aplicaes supervisrias interagirem em configuraes de automao exatamente do mesmo modo oque as aplicaes de Internet interagem. Ela tambm forneceu um veculo para integrar a tecnologia de fieldbus baseada em normas na mesma infraestrutura e para trocar dados usando os mesmos mecanismos. O Gerenciamento do Objeto (no confundir com programao orientada para objeto) um maior beneficirio dessa tecnologia. Ele descreve a habilidade para organizar dados relacionados e informao em uma estrutura comum e executar funes de nvel mais elevado nele e interagir com ele como uma entidade definida. Isto a parte bsica de sucesso do CPAS. Exemplos do uso do gerenciamento de objeto podem ser agrupar objetos associados com uma operao de unidade e executar funes globais tais como supresso de alarme com uma nica ao ou para criar herana ou associao entre objetos diferentes. Isto uma capacidade muitssimo importante quando o processo a ser controlado funcionalmente decomposto por funes avanadas. At essa dcada, havia um nmero ilimitado de enfoques para descrever, projetar, interfacear e programar aplicaes. Nesta dcada foi criado o modelo de referncia comum para estruturar aplicaes de controle de processo a srie de normas ISA S 88 que aplicvel a controle de processos contnuos, de batelada e discretos. Esta dcada tambm trouxe um modelo de referncia para aplicaes de gerenciamento de operaes (normas da srie ISA S 95). Finalmente ela trouxe uma norma internacional que organiza e prescreve o uso das linguagens e configurao de controle de processo mais comumente usadas (IEC 61 131). Manuteno o segundo maior custo controlvel em uma planta de processo e o fato que manuteno preditiva tenha um dcimo do custo da manuteno de rotina dirigiu a necessidade

12

para aplicaes de Gerenciamento de Ativos da Planta (PAM Plant Asset Management). Tudo isso essencialmente extenses do sistema de controle e tem sido incorporado na maioria dos sistemas de automao de processo com diferentes nveis de sucesso. O Gerenciamento de Ativos da Planta comeou como uma facilidade de manuteno para equipamentos de campo da automao, mas agora tem um alcance dentro dos ativos da automao bem como esses ativos que a automao controla. Com o uso da Tecnologia de Informao (TI) nos sistemas de controle de processo, foi inevitvel que escolha da interface humano-mquina tenha sido o MS Windows com a tecnologia de OLE para Controle de Processo (OPC). OPC a base para interfacear aplicaes baseadas no MS Windows com dados organizados e disparatados e a informao. OPC foi reconhecido como um protocolo de comunicao padro de facto para aplicaes no crticas. Dcada centrada nos Negcios (2000) As quatro dcadas anteriores foram um precursor para a Dcada Centrada em Negcios, porque neste ponto o foco muda da tecnologia possvel para como usar a tecnologia disponvel e provada para melhorar o desempenho dos negcios.

Aparecimento do CPAS
Quando os benefcios de utilizar as tecnologias de informao em plantas de processo se tornaram bvios, as grandes companhias de automao de processo todas trouxeram novos sistemas para o mercado, marcando a evoluo para a prxima gerao e para os atuais sistemas de automao. Cada um diferente, baseado em como um fornecedor especfico via os problemas a serem resolvidos e sua soluo estabelecida para esses problemas. Isso levou para um perodo de confuso para os usurios, e foi necessrio criar a viso de um sistema que suportasse Controle de Processo, Controle Avanado de Processo e Gerenciamento de Operao complementado pelas aplicaes humanas como suporte de deciso e anlise avanada. Era desejvel que essa viso inclusse princpios gerais de orientao e tambm fornecesse detalhe suficiente para permitir discusses internas profundas bem como discusses produtivas de soluo de problemas com fornecedores externos. Este esforo se tornou o Sistema de Automao de Processo Colaborativo, CPAS. Os princpios de orientao so os seguintes, entre outros: 1. A proposio de valor da automao deve ser baseada em melhorias mensurveis no Retorno de Ativos que ela controla. 2. A automao deve facilitar uma cultura de Melhoria Contnua. 3. A execuo sem falha da estratgia de automao mandatria. 4. Tudo que deveria ser automatizado ser automatizado. 5. A viso ir entregar o mais baixo Custo Total de Propriedade. 6. Deve haver uma Infraestrutura Comum baseada em normas. 7. No deve haver barreiras artificiais para a informao, como gateways ou dispositivos de rede. Era claro que o desafio era entregar uma capacidade que facilitasse o desempenho dos negcios. No lado das exigncias, estes fatores de negcios incluam: melhoria da eficincia operacional, aumento da utilizao de ativos, diminuio dos custos variveis, diminuio dos tempos de parada no-programada, preservao dos ativos capitais e reduo dos custos fixos. No lado da soluo, eles equacionaram para melhorar a eficincia humana, valorizao do pessoal e da automao com informao preditiva e possibilitando colaborao e sincronizao de uma perspectiva em tempo real em termos de ciclo de produo, uma perspectiva que anteriormente no existia.

13

Vises CPAS: funcional, lgica, aplicao padro e aplicaes avanadas


Viso funcional Quando se olha um CPAS de um ponto de vista funcional, (Fig. 1.13) h somente dois sistemas em uma planta de processo: o sistema de negcios e o sistema de automao, cada um com diferentes classes de aplicao. CPAS um sistema de automao, no hierrquico como era o Sistema de Controle de Processo Bsico (BPCS) do passado. Isto porque o uso da Ethernet TCP-IP permite isso para colapsar em um nico backbone de comunicao com todas as aplicaes, incluindo os equipamentos de campo, sejam capazes de trocar dados e informao sem barreiras. Isso satisfaz o principio do CPAS de uma infraestrutura comum, funcionalmente transparente, logicamente concisa e baseada em normas, TCP-IP inclui um protocolo e gerencia as comunicaes. Isso satisfaz o principio CPAS de ausncia de barreiras artificiais para a informao. Porm, h algumas boas razes para ter alguma estrutura, tais como consistncia, operao determinstica e clareza. Como tem sido dito, esta estrutura fornecida pelas aplicaes de Controle de Processo pelo modelo de referncia ISA 88 e para Gerenciamento de Operaes pelo modelo de referncia ISA 95. Uma terceira norma internacional usada para programao e configurao: IEC 61 131-2, que organiza e define o uso das quatro linguagens de controle de processo mais comumente usadas (diagrama ladder, diagrama de blocos de funo, texto estruturado e lista de instrues). Estas normas facilitam e contribuem para o principio de execuo sem falha do CPAS. H tambm outra dimenso para gerenciamento de dados e informao atravs do CPAS e isso o Acesso Global de Dados (GDA Global Data Access). O Gerenciamento de Objeto (OM Object Management) possibilita o Acesso Global de Dados (GDA), que requer que cada elemento do CPAS seja enderevel como um objeto com um nome nico. Isso tem o benefcio de acessar os dados diretamente da fonte e no requer armazenamento intermedirio dos dados. Sempre se tem o dado mais recente. Diferente dos sistemas baseados em tag, que requerem que os caminhos entre fontes intermedirias de dados (tabelas de dados intermedirios escaneados) e consumidores de dados criados durante o estagio de configurao, CPAS utiliza a ltima tecnologia de link dinmico e publica/subscreve. Isso simplifica muito o processo de configurao porque os objetos podem ser acessados usando seus descritores nicos em operao (run time). Ele tambm faz o local da fonte independente, que fornece mais flexibilidade em juntar e mover componentes i/o. Alm disso, este sistema executa sua prpria organizao e trabalho (housekeeping) quando as mudanas so feitas. Em sistemas baseados em tag, o custo da documentao pode aumentar exponencialmente com o nmero de componentes ativos do sistema. Como a tecnologia de aplicao est avanando ao longo de linhas objetos, sistemas baseados em objeto fornecem mais ambientes nativos para aplicaes futuras. Em sistemas baseados em tag, as estratgias de controle so limitadas capacidade do controlador que eles residem dentro. Como os sistemas baseados em objeto so independentes do hardware, eles so mais extensveis e a extensividade somente envolve a adio do hardware abaixo. Este custo usualmente se relaciona com o valor incremental. A qualidade dos dados vai para o corao do desempenho do sistema. CPAS usa tags de qualidade para transportar o valor dos dados. Se um dado for corrompido, ele tagueado para operaes futuras e essas operaes so suspensas, alarmadas ou alguma ao alternativa tomada. Em termos de redundncia, CPAS considera isso como um passo adicional, usando operao Tolerante a Falha: se uma falha ocorre no processador primrio, o processador secundrio nunca mais do que uma operao atrs. Tambm, como o sistema suporta Acesso Global de Dados, no h um armazenamento intermedirio, todos os dados so trocados em paralelo. Isto a ltima novidade em redundncia de software.

14

Fig. 1.13. Viso funcional do CPAS

Viso lgica Pode-se discutir a arquitetura CPAS de uma perspectiva lgica (Fig. 1.14). No centro desta viso est a Infraestrutura da informao comum (Fig. 1.15), que anteriormente foi chamada de backbone nica de comunicao. Como a Ethernet TCP IP se tornou o protocolo de rede padro para uso pessoal, fabricao e negcios, ela pode ser chamada como o backbone nico de comunicao. Obviamente, componentes de segurana fornecem a separao, mas virtualmente, ela um backbone comum. Desde que esta arquitetura baseada em norma, ela ter um longo ciclo de vida e pela primeira vez, ela suportar um enfoque evolucionrio para atualizao (upgrade) de sistema e novas geraes subsequentes de sistema inevitavelmente chegaro ao mercado por fornecedores. No passado, isso era apenas substituio. Essa arquitetura capaz de suportar uma grande variedade de funcionalidade. Por exemplo, o advento de LAN (Local Area Network) baseada em wireless ir encontrar esta arquitetura nativa para interfacear com ela. As redes de campo baseadas em normas, como FOUNDATION Fieldbus (controle de processo), Profibus (controle lgico) sero facilmente interfaceadas atravs de equipamentos de link. Instrumentos com aplicao especfica, tais como, anlise, monitoramento de mquinas rotativas, rastreadores e outros tambm podem ser facilmente interfaceados. Servidores de aplicao suportando aplicaes crticas sero interfaceados atravs de canais redundantes e aplicaes no crticas sero interfaceadas atravs de OPC. E finalmente, desde que todos eles compartilham o mesmo backbone lgico, o Sistema de Negcios pode comunicar nativamente com os Sistemas Automticos.

15

Fig. 1.14. Viso lgica do CPAS

Fig. 1.15. Componentes da Infraestrutura da Informao Comum

Embora CPAS seja um nico modelo com processamento distribudo, a norma de configurao IEC 61 131 utilizada no CPAS requer o uso de servios comuns, principalmente Gerenciamento de Sistema e Tempo Mestre. Gerenciamento de Sistema a facilidade que monitora a sade do sistema e reporta qualquer anormalidade. O Tempo Mestre a base de todo tempo estampado no sistema; ele sincronizado com o tempo do protocolo de rede em TCP-IP. Estes dois sistemas compartilham sistemas residentes na estao no sistema e h uma proviso para cada um ser automaticamente reconstitudo em uma estao backup se a estao principal falhar.

16

Viso de aplicao de norma A viso de aplicao uma referncia das aplicaes nas reas de Gerenciamento de Operao e Controle de Processo. A viso de Aplicao de Norma do CPAS (Fig. 1.16) mostra alguns de outros princpios. A viso de aplicao de norma constituda de aplicaes que suportam os princpios CPAS, que so divididos em funes de tempo real e funo quase tempo real. A organizao da funcionalidade de tempo real baseada no quadro de controle tendo todas as responsabilidades manuais automatizadas, o que permite o operador se tornar envolvido no controle do processo por exceo.

Fig. 1.16 Viso de Aplicao de Norma

Monitorao e controle do processo Visualizao de progresso e desempenho a habilidade do sistema derivar o desempenho corrente e fornecer uma nica viso desse desempenho, geralmente referido como uma verso simples da verdade. Troubleshooting prioriza a responsabilidade do operador de campo, com o operador de painel ficando envolvido quando requerido. Monitorao do desempenho relaciona o Gerenciamento do Desempenho de Tempo real. Melhores prticas de procedimento relacionada com a Automao do Procedimento. Uma alta percentagem de eventos e muitos desligamentos no programados so causados pela falha de seguir os procedimentos prescritos. A capacidade de efetivamente automatizar esses procedimentos uma parte crtica do CPAS. Perspectiva Operacional A perda de operadores experientes uma situao sria e os melhores operadores esto se tornando cada vez mais raros. A Perspectiva Operacional descreve a capacidade do sistema para relacionar a operao corrente ou possveis mudanas na operao com o cenrio de risco derivado com a tecnologia de sistema expert. O objetivo que todos operadores trabalhem como os melhores operadores. Gerenciamento da Operao Benchmarking da Estratgia de Fabricao Muitos usurios tem alguma forma de um Carto de Score para medir o desempenho contra objetivos; esta aplicao faz isso.

17

Treinamento do Operador Esta funo uma parte do Programa de Excelncia Operacional do usurio. Gerenciamento do Desempenho O gerenciamento do desempenho tem mudado consideravelmente com as ferramentas atuais disponveis. Facilidade de Gerenciamento do Processo do Trabalho CPAS tem um principio fundamental de automatizar tudo que possa ser automatizado; isso se aplica tanto aos processos de trabalho como para as tarefas manuais. Gerenciamento de Situao Crtica a conveno na indstria se referir aos eventos que levam s maiores perdas econmicas, desligamentos no programados ou situaes HSE (Health and Safety Executive) como incidentes. Esses incidentes tm sido historicamente quase impossvel de se prever e extremamente difcil para as plantas se recuperarem deles. Porm, usando sensores disponveis baratos e sem fio para coletar grande quantidade de dados do processo e do ativo, combinado com software preditivo analtico recentemente desenvolvido para os dados do processo, agora prtico prever e prevenir a maioria desses incidentes. Essa tecnologia pode, com um alto nvel de certeza, prever um grande incidente ou em tempo para um operador atuar e evitar o incidente ou, se ele no puder ser evitado, ser mitigado significativamente em suas consequncias. Aplicaes avanadas do CPAS H vrias aplicaes avanadas que so consideradas criticamente importantes, como: Viso comum/Verso simples da verdade Se as pessoas esto trabalhando efetivamente h uma necessidade crescente para elas terem informao exata e no tempo adequado. E se seu trabalho envolve colaborao com outros, ento elas precisam olhar a mesma informao. Isto referido como uma simples verso da verdade (Fig. 1.17). o valor da informao diretamente proporcional a como recente a informao e como largamente ela disponvel para suportar colaborao. Este nvel de disponibilidade de informao no sempre o mesmo caso. Pesquisas mostram que em uma planta tpica de processo, somente 5% do pessoal tem a informao que elas precisam para fazer seu trabalho. CPAS suporta uma simples verso da verdade usada passivamente em poucas pessoas para persistentemente em estaes analticas fazerem suporte avanado de deciso. Uso de informao passiva usualmente se refere a tomada de deciso no local (ad hoc). Neste caso, a informao relevante obtida, a deciso tomada e ento a informao repassada e no retida. Uso de informao persistente usualmente se relaciona a funes de anlise feitas sobre informao arquivada; neste caso os resultados so tambm retidos em armazenamento persistente. Informao acionvel Sistemas de automao rotineiramente entregam dados demais e muito pouca informao e isso no auxiliado pela Infraestrutura da Informao Comum. Isto particularmente verdade quando a automao dos processos requerida. Nesses casos, crtico obter uma perspectiva entre vrias dimenses para tomar a deciso correta. Se o trabalho no caso automatizar uma procedimento manual complexo ou dar a responsabilidade para este procedimento a um operador sem experincia, porque no h um operador experiente, o desafio o mesmo: como pode o procedimento ser executado corretamente em um ambiente dinmico se o contexto exato no conhecido?

18

Fig. 1.17. Verso simples da verdade

CPAS suporta a tomada de deciso correta baseada em dados acessados do Modelo de Dados (algumas vezes Meta Dados), o ponto que se tem agora no processo do trabalho, um entendimento exato dos ativos da planta que esto disponveis e finalmente a aplicao que ser usando o contexto, tudo com tempo comum e garantia que dados de boa qualidade esto sendo processados. (Fig. 1.18).

Fig. 1.18. Contexto acionvel comum

Gerenciamento do Desempenho em Tempo Real No passado, o desempenho era definido como produzir uma quantidade finita de um produto especfico em um tempo determinado, com todos os objetivos estabelecidos no incio do turno de trabalho. Atualmente, alm disso, se monitora o desempenho da planta em tempo real e continuamente avalia se pode fazer melhor, ou se houver um problema, como se pode recuperar no final do turno. Isto referido como Gerenciamento do Desempenho em Tempo Real (RPM) (Fig. 1.19) e est embutido no conceito de Custo Baseado na Atividade (ABC Activity Based

19

Costing). ABC requer a medio da taxa de produo e um entendimento do custo da produo para ter um entendimento da taxa em que valor est sendo adicionado. Esse conceito tem sido usado em fabricao discreta por muitos anos por que todos esses valores so conhecidos, mas no em processos contnuos, porque o valor dos produtos intermedirios no conhecido. Tem sido sempre desejvel gerenciar operaes de planta de processo em tempo real, mas fornecendo aos operadores as ferramentas tem sido um desafio. Agora que o gerenciamento de desempenho em tempo real tem tornado crtico, ferramentas ficaram disponveis para fazer uma decomposio funcional do processo, correlacionar o processo com as responsabilidades do operador e fornecer um entendimento do desempenho do operador bem como o desempenho do processo, tudo em tempo real. Estas ferramentas incluem modelagem rigorosa, balano de material e ferramentas de otimizao. CPAS projetado para suportar essa tecnologia.

Posio do CPAS
CPAS atualmente um simples modelo com processamento distribudo e servios compartilhados. baseado na norma de configurao IEC 61 131-3. Junto com todos os grandes sistemas de controle de processo, CPAS no um sistema verdadeiro de controle distribudo. CPAS distribudo, mas no independente; todas as partes do sistema so dependentes dos servios compartilhados. A prxima gerao de CPAS ir continuar suportando Controle de Processo, Gerenciamento de Operaes e Suporte Avanado de Decises, mas ele no far isso como um simples modelo com processamento distribudo separado em componentes autnomos robustos. Esses componentes sero distribudos e baseados na nova norma de configurao e programao: IEC 61 499, que no requer servios compartilhados e ela ser autnoma porque ela ir suportar a nova norma de tecnologia Fundao para Agentes Fsicos Inteligentes (FIPA Foundation for Intelligent Physical Agents).

20

2.1. Arquitetura do CPAS


Introduo
A automao de processo uma tarefa complexa requerendo a integrao suave de uma grande variedade de sistemas e fontes de informao diferentes. As seguintes caractersticas e exigncias so fundamentais para uma arquitetura CPAS: Integrao Tarefas tpicas como operao, engenharia, manuteno e gerenciamento da informao devem todas serem disponveis de um ambiente integrado. Deve ser possvel integrar as melhores ferramentas externas. Escalabilidade e flexibilidade Para minimizar os custos do ciclo de vida do sistema, o projeto deve permitir a adio incremental fcil de desempenho e funcionalidade quando necessrio. Proteo do investimento A arquitetura deve garantir que as melhorias futuras nas tecnologias do sistema no comprometam o investimento atual e ir fornecer aos usurios a habilidade de melhorar seu sistema atual com aplicaes futuras de melhoria da qualidade. A arquitetura deve ser aberta e baseada em normas. Proteo (security) Proteo a condio de ser protegido contra perigos com um nfase no perigo que vem de fora. Exemplos de proteo contra vrus de programa e ataques terroristas (?). Segurana (safety) Segurana a condio de ser protegido contra perigo, com um nfase no perigo oque vem de dentro. Exemplos de segurana so proteo contra acidentes e bugs de programa e uso de equipamentos Ex. Rastreabilidade (traceability) Rastreabilidade a habilidade de reconstruir cada passo da produo. Isto requerido tanto por exigncias legais como uma base importante para melhoria da produo. Diagnstico Autodiagnstico compreensivo em todo sistema e caractersticas de relatrio resultam em facilidade de manuteno e mxima disponibilidade do sistema. Gerenciamento do Sistema Completo Facilidade de setup e manuteno garante operaes seguras e confiveis. Previsibilidade (Dependability ) Previsibilidade a qualidade de um sistema atingir um comportamento predefinido em face de falhas de suas partes. Ela engloba segurana, disponibilidade, mantenabilidade e confiabilidade (reliability). Disponibilidade ininterrupta Em muitas plantas uma reduo ou parada de produo tem grandes custos associados. Por exemplo, refinarias de petrleo e central de matria prima de polo petroqumico devem rodar por muitos anos sem interrupo. Isto significa que um CPAS precisar ser projetado de modo que upgrades e manuteno possam ser feitos sem perturbar a produo. Globalizao Na atual economia globalizada, um CPAS deve ser disponvel em qualquer parte do mundo e deve operar com diferentes ajustes regionais como idioma, fontes, tempo e formato de dados diferentes.

Orientao por objeto


Um problema central para CPAS a necessidade de manipular grandes nmeros de itens e sua informao relacionada. Esses itens incluem sensores, atuadores e controladores. Em uma grande planta, h dezenas de milhares desses itens devem ser organizados. A cincia de computador que comeou na dcada de 1960 desenvolveu conceitos para orientao para objeto que so agora padro na maioria das linguagens de programao moderna e sistemas operacionais. A maioria desses conceitos incorporada no CPAS. Geraes anteriores de CPAS tm manipulado os itens em longas listas e as diferentes aplicaes eram completamente isoladas entre si. Como padronizado pela IEC 61 346, objetos relacionam dados da planta (aspectos), para especificar ativos da planta (Fig. 2.1). Por exemplo, aspectos so itens de informao associados como definies de I/O, desenhos de engenharia, grficos do processo, relatrios, tendncias, etc. que so atribudos a cada objeto no sistema. Aspecto de navegao de objetos de apresenta a facilidade inteira da produo em um modo consistente e fcil de ver. Isso permite um nico ambiente de janela incluir equipamentos de campo

21

inteligentes, funes de gerenciamento de ativos da planta, gerenciamento da informao, gerenciamento de bateladas, sistemas de segurana e sistemas de execuo de fabricao (MES Manufacturing Execution System).

Fig. 2.1. Mapeamento de ativos da planta para objetos programas

Aspectos especficos como Gerenciamento de Ativos da Planta podem ser adicionados ao sistema posteriormente quando requerido. O Modelo Aspecto Objeto pode integrar dados de sistemas externos como planejamento de fonte da empresa (ERP Enterprise Resource Planning) ou sistemas de gerenciamento de manuteno computadorizada (CMMS). Assim que tais itens sejam mapeados no Modelo do Aspecto do Objeto eles so disponveis para todos os outros aspectos. O Modelo do Aspecto do Objeto pode servir como base para a integrao de diferentes aplicaes: 1. Seja um objeto representando uma bomba com um aspecto de monitorao de ativo; a bomba requer a data da ltima manuteno como a base de um algoritmo de diagnstico. 2. Esse aspecto agora tenta encontrar um aspecto CMMS sobre o mesmo objeto. 3. Se ele for encontrado, o monitor do ativo conecta ao aspecto CMMS e pergunta pela data da ltima manuteno. 4. O monitor de ativo ento roda o algoritmo de diagnstico. 5. Se um problema for encontrado o aspecto do monitor de ativo automaticamente abre um tquete de manuteno no aspecto CMMS. Esse exemplo demonstra como solues mais genricas podem ser implementadas. Obviamente, deve ser possvel acessar diretamente o sistema CMMS, mas tal soluo seria muito especfica do projeto e no aceitvel como uma soluo geral. O acesso informao abstrata possvel com um Modelo de Aspecto Objeto permite uma integrao modular de aplicaes.

22

2.3. Normas industriais e interfaces abertas


Introduo
Historicamente, sistemas de automao de processo (PAS) eram monolticos, baseados em aplicao com tecnologia proprietria. Quando a tecnologia avanou e amadureceu, tornou-se claro que o uso de normas e interfaces abertas ofereciam vantagens importantes: Custo de propriedade total reduzido Proteo de investimento. Quando o PAS descontinuado ou no mais suportado, se torna cada vez mais difcil ampliar e manter as instalaes existentes. Custo de treinamento reduzido. Se o pessoal foi treinado para operar e cuidar de uma norma, ele pode trabalhar com equipamentos de diferentes fornecedores aderindo a esta norma. No caso de equipamento proprietrio, necessrio um novo treinamento para cada fornecedor. Flexibilidade de arquitetura. Um PAS monoltico oferece apenas as possibilidades previstas pelo fornecedor do PAS. Tudo o mais requer ou desenvolvimentos do comprador muito elevados ou impossvel. Melhorias evolucionrias As plantas de produo industrial mudam ao longo do tempo, estratgias de controle se alteram, novos conhecimentos so desenvolvidos e novas ferramentas aparecem. Um exemplo a substituio de equipamentos obsoletos das estaes de operao. O custo de reparo de estaes com 15 ou 20 anos de idade to alto que as estaes devem ser substitudas por outras de outra gerao mais nova. Um PAS monoltico requer a substituio de todo o sistema, incluindo a camada de controladores, mesmo se essa camada estiver ainda trabalhando idealmente. Normas e interfaces abertas permitem adaptar um CPAS quando melhorias evolucionarias se tornarem desejveis. Interoperabilidade As plantas de produo atuais usualmente ainda possuem vrias ilhas de informao, onde diferentes sistemas no so capazes de facilmente trocar informao, embora essa troca seja muito benfica para a produo. Fornecedores misturados Se uma planta de produo padroniza uma tecnologia proprietria de um nico fornecedor, isto significa que assim que a deciso tomada, ela pode ser revisada apenas com alto custo, porque a maioria dos equipamentos deve ser substituda. Provavelmente os custos de peas de reposio ou de ampliao tambm sero maiores, pois o fornecedor sabe que o comprador no tem outra escolha. Quando h vrias normas e interfaces disponveis fornecidas por vrias empresas, o usurio final sempre poder combinar os melhores componentes de diferentes fornecedores de automao. Intercambiabilidade Se componentes padronizados de diferentes fornecedores podem ser usados, a competio resultante leva a maior qualidade e menor custo. Se um componente no mais fabricado, ele pode ser substitudo por um componente diferente de outro fornecedor. Como estas vantagens so significativas, modernos CPAS so baseados pesadamente em normas. Normas promovem escolhas, aumentam desempenho e reduzem riscos e custos. Um grande nmero de normas existe, tanto para automao de processo como para trocar informao. As mais importantes normas relacionadas com automao e redes industriais sero vistas superficialmente agora e aqui.

23

Normas gerais com alta relevncia para automao de processo


XML A Linguagem Markup Extensvel (Extensible Markup Language XML) um formato de texto simples e flexvel que se torna uma regra crescentemente importante na troca de uma grande variedade de dados. A W3C (World Wide Web Consortium) criou, desenvolveu e mantem a especificao XML (w3c.org/xml). A W3C tambm o principal centro para desenvolver outras especificaes industriais que so baseadas em XML. XML usada mais e mais no contexto de automao de processo. Exemplos notveis so: ISA 95 OPC UA AutomationML XML oferece um enfoque altamente padronizado para armazenar dados estruturados e tem um excelente suporte de todos os tipos de ferramentas. Sistemas modernos de base de dados incluem mais e mais suporte para XML. Esquema XML Um esquema XML pode ser usado para expressar um conjunto de regras para as quais um documento XML deve estar conforme para ser considerado valido de acordo com esse esquema. As regras fornecem um meio para definir a estrutura, contedo e semntica dos documentos XML. Uma popular e expressiva linguagem esquema XML, XML Schema (com letra maiscula) mantida pela W3C (www.w3c.org/XML/Schema). Uma instancia SML Schema uma Definio XML Schema (XSD) e tipicamente tem a extenso de arquivo .xsd. Suporte para validar documentos XML contra esquemas pode ser feito por ferramentas tais como editores ou browsers XML. Tecnologias Internet Com o triunfo da Internet na vida diria, h tanto momento atrs das tecnologias e normas bsicas da Internet que so fortemente usadas em automao de processo. Pessoal est usando a Internet para fazer coisas e ferramentas poderosas e tcnicas existem que podem ser reusadas para automao de processo. HTML A Linguagem Markup Hipertexto (HyperText Markup Language HTML) foi criada pelos fundadores da W3C e agora uma norma, ISO/IEC 15 445. HTML permite os usurios especificar interfaces baseadas na web. Um exemplo onde HTML pode ser usada em automao de processo na configurao de estaes de trabalho com GUI (Graphical User Interface) para equipamentos inteligentes, que poderiam no ter seu prprio display. Muitos dos sensores atuais contem um microcomputador para adicionar caractersticas como calibrao e diagnstico, mas adicionar um display dedicado seria muito caro. Em tal caso, o equipamento pode implementar um pequeno servidor web e oferecer a interface via HMTL sobre a rede. Outro exemplo a interface de usurio fazendo a informao de processo disponvel em cada computador padro conectado rede. HTTP O Protocolo de Transferncia de Hipertexto (Hypertext Transfer Protocol HTTP) um protocolo de comunicao para a transferncia de informao atravs de redes de computador. Ele foi desenvolvido pela IETF (Internet Engineering Task Force) e W3C. um protocolo genrico, sem estado, que pode ser usado para muitas tarefas alm de seu uso para hipertexto, como nomear servidores e sistemas de gerenciamento de objeto distribudos, atravs da extenso de seus mtodos requeridos, cdigos de erros e headers (ver http://tools.ietf.org/html/rfc2616). Microsoft COM A tecnologia Microsoft Component Objet Model (COM) foi publicada em 1993 e permite componentes de software se comunicar com cada outro. COM a parte central dos sistemas operacionais da Microsoft como XP e Vista. COM pode ser usada para criar componentes de software 24

reusveis, lincar componentes juntos com aplicaes embutidas e ter as vantagens dos servios Windows. COM a base tecnolgica para o sucesso das normas OPC DA, AE e HDA. Uma interface COM uma coleo de mtodos logicamente relacionados. A interface COM um contrato abstrato sobre a funcionalidade que pode ser fornecida por um servidor COM. Ela define que mtodos precisam ser disponveis e que parmetros os mtodos devem ter, mas ela no diz nada sobre como os mtodos poderiam ser implementados. Um servidor COM um componente de software binrio que expe os parmetros definidos na interface e pe uma implementao concreta atrs. Um cliente COM uma aplicao que chama mtodos de um servidor COM (Fig. 2.16). Um servidor COM pode rodar: 1. No processo do cliente COM. 2. Em um executvel separado na mesma mquina do cliente COM 3. Em um executvel em uma mquina diferente (DCOM requerido). COM foi substitudo pela .NET Common Language Runtime que fornece integrao bidirecional transparente com COM. COM disponvel apenas em sistemas operacionais Microsoft mas pode ser adicionado a outros sistemas operacionais com a ajuda de pacotes de terceira parte. COM permanece uma tecnologia vivel com uma importante base de software.

Fig. 2.16. Aplicao cliente usando Componente COM

SQL Structured Query Language (SQL) uma linguagem de computador para database projetada para a recuperao e gerenciamento de dados em sistemas de gerenciamento de dados relacional (RDBMS). A norma ISO/IEC 9 075 define a linguagem SQL. Bases de dados populares SQL so disponveis da Oracle, Microsoft, IBM e Sun. Muitos fornecedores adicionam extenses proprietrias para SQL.

Normas de Automao de Processo


Fieldbuses digitais No passado, os equipamentos de campo eram conectados atravs de cabos analgicos com 4 a 20 mA cc para o PAS. Cartes e mdulos especiais de i/o convertem esse sinal analgico para digital. Embora a conexo analgica ainda seja uma opo, barramentos de campo (fieldbuses) digitais so cada vez mais usados. Um fieldbus um barramento de dados digitais para comunicao com equipamentos industriais de instrumentao e controle, tais como transmissores, atuadores e controladores. Os fieldbuses mais importantes e usados em automao de processo so: PROFIBUS, FOUNDATION Fieldbus e HART. PROFIBUS PROFIBUS DP (Decentralized Peripherals) usado para operar sensores e atuadores atravs de um controlador centralizado na tecnologia de produo. PROFIBUS PA (Process Automation) usado para monitorar equipamentos de medio atravs de um sistema de controle de processo em engenharia de processo. PROFIBUS padronizado pela norma ISO/IEC 61 158 e IEC 61 784 (ver www.profibus.com).

25

FOUNDATION Fieldbus FOUNDATION Fieldbus fornece um protocolo de comunicao para controle e sistemas de instrumentao em que cada equipamento tem sua prpria inteligncia e comunica atravs de um sistema de comunicao digital, serial, bidirecional. FOUNDATION Fieldbus H1 projetada para operar sobre uma fiao existente de par tranado com alimentao de 24 V cc e sinal no mesmo fio, rodando em 31.25 kbaud. O meio por fibra ptica opcional. FOUNDATION Fieldbus HSE (High Speed Ethernet) ou FOUNDATION Fieldbus H2 idealmente conveniente como a parte mais importante (backbone) de controle. Rodando em 100 Mbaud, a tecnologia projetada para equipamento, subsistema e integrao ode sistema (ver www.fieldbus.org). HART Highway Addressable Remote Transducer (HART) um protocolo de comunicao de campo mestre-escravo. A maioria de equipamentos de campo analgicos instalados em plantas de todo o mundo podem ser convertidas em HART. O protocolo HART faz uso da norma Bell 202 Frequency Shift Keying (FSK) para superpor o sinal de comunicao digital de baixo nvel sobre o sinal analgico de 4 a 20 mA cc. O protocolo HART se comunica com velocidade de 1200 bauds sem interromper o sinal de 4 a 20 mA e permite uma aplicao de mestre (host) para obter dois ou mais atualizaes digitais por segundo de um equipamento de campo. Como o sinal digital FSK de fase contnua, no h interferncia com o sinal de 4 a 20 mA cc (ver www.harcomm2.org). O protocolo HART foi desenvolvido originalmente pela Fisher-Rosemount para atualizar instalaes com comunicao analgica de 4 a 20 mA com comunicao de dados digital. Atualmente, o protocolo pertence HART Communication Foundation. Para se usar o protocolo HART os mdulos i/o devem ser habilitados para HART. WirelessHART projetado para enderear as necessidades da indstria de processo para simples, confivel e segura comunicao digital wireless. Configurao de equipamento de campo Uma grande planta tpica possui cerca de vrios milhares de equipamentos digitais de campo. A antiga instrumentao analgica de instrumentos de campo requeria acesso fsico ao equipamento, que poderia estar at 3 km de distncia, para calibrao e diagnstico. O instrumento digital de campo oferece a grande convenincia de ter essas tarefas feitas remotamente; porm o gerenciamento de um grande nmero de diferentes equipamentos de diferentes fornecedores ainda permanece um desafio e problema. H normas que ajudam a gerenciar diferentes equipamentos com as mesmas ferramentas suportam uma engenharia e manuteno eficientes. FDT/DTM A tecnologia Field Device Tool (FDT) padroniza a interface de comunicao entre equipamentos de campo e sistemas. A caracterstica chave sua independncia do protocolo de comunicao e do ambiente do software do equipamento de campo ou do sistema host (ver www.fdt-jig.org). FDT permite qualquer equipamento ser acessado de qualquer host atravs de qualquer protocolo. Um Device Type Manager (DTM) um driver de equipamento usualmente fornecido pelo fabricante do equipamento. DTM pode variar de uma simples interface grfica do usurio (GUI) para ajustar os parmetros do equipamento at uma aplicao altamente sofisticada capaz de fazer clculos complexos em tempo real para fins de diagnstico e manuteno. EDDL Electronic Device Description Language (EDDL) uma linguagem para descrever as propriedades de componentes de sistema de automao. EDDL pode descrever: 1. Parmetros do equipamento e suas dependncias 2. Funes do equipamento, como modo de simulao e calibrao 3. Representaes grficas, como menus 4. Interaes com equipamentos de controle 5. Representaes grficas

26

Armazenamento persistente de dados permite equipamentos armazenar dados em uma aplicao host sem requerer as convenes de reconhecimento para salvar os dados sob o sistema host. EDDL aplicvel a vrios protocolos de comunicao (ver www.eddl.org). FDI Future Device Integration (FDI) usa um subconjunto da tecnologia OPC UA dentro de uma arquitetura cliente-servidor. FDI combina as vantagens das tecnologias FDT e EDDL. A arquitetura FDI planejada ser desenvolvida com as seguintes recomendaes: 1. Arquitetura cliente servidor 2. Plataforma e sistema operacional independentes 3. Sistema host independente 4. Compatvel com descries de equipamento baseadas em DDL e DTM existentes 5. Aplicvel a qualquer tecnologia de comunicao de equipamento de campo 6. Aplicvel para topologias de rede hierrquica e heterognea 7. Uma especificao aberta e se torna uma norma internacional.

OPC
Em 1996 a primeira norma OPC - Object Linking and Embedding (OLE) para Process Control (PC) (OPC = OLE + PC) foi desenvolvida por vrios fornecedores de automao junto com a Microsoft. A norma baseada no Microsoft COM e descreve como as aplicaes devem trocar dados em tempo real sobre uma plataforma Microsoft. Como a OPC era uma boa soluo para um problema urgente, a norma foi rapidamente suportada por mais e mais sistemas de automao e fornecedores de produto. A Fundao OPC (www.opcfoundation.org) possui mais de 400 membros no mundo. A primeira norma OPC chamada OPC Specification agora chamada de OPC Data Access Specification ou OPCP DA. A norma OPC Unified Architecture (OPC UA), publicada inicialmente em 2006 independente da tecnologia Microsoft. As existentes OPC DA,OPC AE e OPC HDA so agora chamadas OPC Classic. Servidores OPC Classic trabalham apenas em sistemas operacionais da Microsoft. Antes da era OPC, cada aplicao que necessitasse acessar dados de algum sistema ou equipamento externo tinha de usar drivers e protocolos especficos (Fig. 2.19). Isso significava um grande trabalho do usurio, que ainda era caro e susceptvel a erro. Com OPC, um servidor OPC pode ser oferecido pelo fornecedor do equipamento ou sistema, mas ele pode tambm ser fornecido por uma terceira parte fornecedora de software. O servidor OPC pode ser acessado com mtodos padronizados como especificados em vrias normas, de modo que uma aplicao de cliente que capaz de acessar OPC pode se comunicar imediatamente com todos os equipamentos e sistemas fornecendo um servidor OPC. Enquanto a ideia original atrs do OPC era fornecer comunicao padronizada entre equipamentos e aplicaes, ele agora tambm usado como uma interface entre aplicaes. O termo servidor OPC no significa que ele deve rodar em um equipamento servidor dedicado. Vrios servidores OPC poderiam rodar em uma mesma mquina e os clientes e servidores OPC podem rodar bem na mesma mquina. OPC DA OPC Data Access fornece a funcionalidade bsica para ler e escrever dados de vrios equipamentos de uma rede atravs de um conjunto padro de interfaces. Um servidor OPC DA contem uma lista simples ou estruturada de itens OPC. Usualmente esses itens correspondem a tags ou pontos i/o. Cliente OPC pode folhear (browse) o servidor OPC e ver quais itens so disponveis. O objetivo o OPC Data Access fornecer as interfaces para aquisio de dados em suporte de uma arquitetura vertical (serve dados de um equipamento para uma aplicao cliente em um computador de nvel mais alto) (OPC Foundation Data Access Custom Interface Standard V3.00). Um item OPC contem um tempo estampado e um flag para qualidade dos dados. Vrios modos de subscrever os itens OPC so disponveis, por exemplo, assncrono ou cclico.

27

Fig. 2.19. Aplicaes se comunicando com equipamento com e sem OPC

OPC HDA OPC Historical Data Access (OPC Historical Data Access Specification Version 1.2) expande a capacidade do OPC DA, que est focado nos dados atuais, para linha de tempo de dados histricos.

IEC 61 131-3
No passado, cada fornecedor de sistema de automao de processo criava uma diferente linguagem de programao para seu sistema. Isto significava que os programas eram associados somente a estes sistemas desse fornecedor e desenvolvedor de software tinha de ser retreinado para cada sistema diferente. A norma internacional ISO/IEC 61 131-3 define linguagens de programao para controladores programveis. Embora os programas da IEC 61 131-3 no possam ser transferidos diretamente entre sistemas de diferentes fornecedores, ele suporta a transferncia de treinamento e know-how entre os sistemas.

IEC 61 850 - Redes de Comunicao e Sistemas para Automao de Utilidade de Casa de Fora IEC/EM 61 508 - Sistema Instrumentado de Segurana IEC 62 264 (ANSI ISA 95) - Integrao Sistema Controle - Enterprise IEC 61 512 (ISA 88) - Controle Batelada

28

2.5. Automao previsvel (dependable)


Introduo
Previsibilidade (dependability) a qualidade de um sistema atingir um comportamento predefinido em face de falhas de suas partes componentes. Previsibilidade engloba: segurana, disponibilidade, confiabilidade e mantenabilidade. Tambm chamada de RAMS (Reliability, Availability, Maintainability, Safety). A previsibilidade uma exigncia importante nos sistemas de automao. 1. A primeira exigncia a segurana, ou seja, garantir que uma falha do sistema de controle no vai causar dano s pessoas, ao meio ambiente e propriedade da empresa. 2. A segunda exigncia a disponibilidade, i.e., a falha do sistema de controle no deve interromper a produo quase nunca (ou mesmo nunca). 3. A terceira exigncia a confiabilidade, que expressa quo frequentemente o sistema falha; se houver redundncia, a falha de um sistema com reserva no ir imediatamente levar para uma perda de disponibilidade, mas frequentes chamadas para manuteno so indesejveis. 4. A quarta exigncia a mantenabilidade, que visa reduzir os tempos de parada ou mesmo levar esse tempo para zero. Solues para garantir segurana e disponibilidade so uma parte importante das ofertas do CPAS. Embora os princpios de operao variem, as arquiteturas previsveis podem ser divididas em um nmero relativamente pequeno de tipos. Porm, tem sido reconhecido que solues gerais so complexas e caras e que os sistemas de automao devem ser tolerantes a falha para satisfazer as necessidades especficas da planta. Isso significa que muitos mecanismos de tolerncia falha no so transparentes para o programador da aplicao e assim h custos adicionais de engenharia. Um conhecimento profundo e preciso da planta necessrio, quando um dos fatores mais limitantes a no confiabilidade do equipamento redundante que foi especificamente introduzido para aumentar a tolerncia falha.

Tipos de planta e arquitetura do computador Tipos e estados de planta


Um CPAS contem controladores interligados com sensores e atuadores sobre os sistemas de comunicao. Um componente do sistema de automao pode falhar em um nmero de modos que pode ser condensado em duas classes: 1. Quebra da integridade: o sistema entrega sadas erradas, ou em valor ou no tempo. 2. Quebra da persistncia: o sistema deixa de entregar sadas usveis. Essas propriedades se aplicam a controladores lgico programveis, sistemas de comunicao e dispositivos de entrada sada. Sero consideradas apenas as falhas do controlador, desde que ele representa os trs modos de interesse (processamento, comunicao e armazenamento) para todos os outros subsistemas, de modo que os princpios se aplicam aos outros componentes de modo mais simples. O que acontece planta no caso de falha depende do tipo de falha e das caractersticas da planta. O assunto mais importante depois da ocorrncia de uma falha se a planta ainda est segura (i.e., no entra um estado onde ocorre grande perigo ou dano). A distino entre falhas seguras e falhas inseguras pode somente ser feita depois de uma anlise da planta. Se um sistema de automao entrega dados errados (quebra de integridade), algumas plantas respondero a tais quebras com alguma produo fora de especificao, causando pequeno dano, mas outras plantas no toleram quebra de integridade de nenhum modo. Por exemplo, uma subestao eltrica no ir tolerar que uma chave seja operada por um controlador em falha. Plantas geralmente incorporam protees (i.e., alguma redundncia) para mitigar a falha de um controlador. Por exemplo, pela deteco de um erro no controlador, um mecanismo de emergncia pode desligar uma parte da planta, levando-a para um estado seguro, preferivelmente

29

de modo passivo. Tambm, testes de plausibilidade de alto nvel pode garantir segurana evitando operaes potencialmente perigosas, sem identificar sua causa. No exemplo da subestao, mecanismos de intertravamento iro evitar uma chave de ser operada atravs de um controlador em falha se isso danificar a subestao. Se um sistema de automao no gera dados usveis (quebra de persistncia), algumas plantas iro sofrer perdas de produo, mas outras iro ficar inseguras, se no forem controladas. Por exemplo, um avio pode tolerar comandos errticos durante poucos segundos, desde que o fluxo de dados usveis seja restaurado rapidamente. Para esse tipo de processo, que no possui posio segura, segurana uma questo de persistncia. Quando uma funo de proteo falha, uma quebra de persistncia implica um perigo de segurana, desde que a planta no est mais protegida e deve ser desligada se no for reparada dentro de determinado tempo, causando perda de produo e diminuindo a disponibilidade. O fator de projeto importante quanto tempo uma planta pode tolerar um defeito de seu computador de controle sem desligar (indo para o estado de desligado seguro) ou sem sofrer dano. Este parmetro chamado de tempo de graa (grace time) e especfico para cada planta. Valores de tempo de graa so mostrados na Tab. 2.1. Indstria de processo Processos qumicos Montagem de veculo Mquina impressora Subestao eltrica 10 s 1s 100 ms 20 ms 4 ms Tab. 2.1. Tempos de graa

Quando o sistema de automao tolerante falha, ele pode suportar um nmero de falhas antes de causar um desligamento. Sem reparo, porm a planta inevitavelmente ir desligar. Em uma planta que opera 24 horas por dia, como uma subestao ou uma planta de processo qumico contnuo, a reintegrao de componentes reparados sem parada uma necessidade para garantir a disponibilidade. A taxinomia de modos de falha relacionados com a segurana e recomendaes dada em vrias normas, a mais comum sendo IEC 61 508: Functional safety of electrical, electronic, programmable electronic safety-related systems e IEC 61 511: Safety instrumented systems for the process industry sector.

Sistemas de Alta Integridade


A primeira exigncia de um controlador manter a integridade dos dados em caso de falha de um de seus componentes. O comportamento ideal falha-silenciosa, em que o controlador no gera nenhum dado na sada e comporte passivamente na rede de comunicao. Este comportamento s vezes chamado erradamente de falha segura. Para conseguir arduamente esse comportamento, os controladores so projetados com vrios mecanismos de deteco de erro e confinamento de falha, como temporizador watch dog, partio de memria, verificaes de plausibilidade, verificaes de memria e verificaes aritmticas. Mesmo esses diagnsticos intensivos no conseguem evitar dados falsos de escapar do controlador durante um determinado tempo, desde que os diagnsticos no esto atuando continuamente. Sistemas incorporando diagnstico extensivo so chamados de sistemas 1001D (Fig. 2.27). Para fornecer integridade completa, necessrio usar duplicao (redundncia) e comparao, uma configurao em que cada operao do controlador trabalhador constantemente verificada por outro controlador, o controlador verificador (Fig. 2.28).

30

Fig. 2.27. Controlador simplex (1oo1D)

Fig. 2.28. Duplicao e comparao (2oo2)

O controlador verificador preferivelmente no idntico ao controlador trabalhador, para reduzir a probabilidade de erros sistemticos (redundncia e diversidade). Isso se aplica principalmente a erros de software. Por exemplo, usam sistemas operacionais diferentes no controlador trabalhador e no controlador verificador para fornecer cobertura de alta integridade.

Sistemas persistentes
Sistemas persistentes se baseiam e confiam na redundncia funcional para substituir um componentes operacional em falha. Fig. 2.30 mostra a configurao principal. Um controlador trabalhador substitudo por um controlador reserva com a mesma funcionalidade; detectores de erro permitem a lgica de falha escolher qual controlador deve ser confiado. Inserir equipamento redundante no suficiente, este equipamento deve tambm ser atualizado (carregado com o mesmo estado) com a unidade que ele substitui, seno a falha no ser sem tranco e pode resultar em quebra da integridade. H dois mtodos de fazer o backup corretamente atualizado: standby e workby (Fig. 2.31). Em standby, somente uma unidade est trabalhando e ela mantem a outra unidade atualizada transferindo seu estado atravs de um link de alta velocidade para a unidade reserva, que passiva. A atualizao no contnua, mas s ocorre em determinados pontos de verificao na

31

execuo do trabalhador. Quando a deteco de erro sinaliza que o trabalhador falhou, a unidade reserva entra e comea a operar do ltimo ponto de verificao corretamente recebido. A vantagem do standby que a operao e programao do trabalhador no so fortemente influenciadas pela presena do backup, exceto pelo tempo que ele leva para transferir as mudanas de estado. A desvantagem que a falha leva algum tempo; valores tpicos do atraso so da ordem de 10 a 100 ms.

Fig. 2.30. Controladores persistentes (1oo2D)

Em workby, ambas as unidades so sincronizadas e trabalham em paralelo. Isto significa que, ambas recebem as mesmas entradas e sincronizam suas transies atravs de um link de alta velocidade. Ambas as unidades so iguais, indistinguveis, a planta pode selecionar qualquer uma das duas quando os detectores de erro no sinalizam um erro. A vantagem do workby que a transferncia na falha suave completamente. De um ponto de vista de confiabilidade, workby permite redundncia constantemente exercitando e portando no cobre falhas escondidas. Outra vantagem da configurao workby que essa configurao pode ser usada para duplicao e comparao, e, portanto tambm fornece integridade. Os sinais podem ser bloqueados em caso ode discrepncia sempre que uma unidade no declarada em falha. A desvantagem do workby que os controladores devem ser perfeitamente sincronizados em sua operao e em particular seus circuitos de interrupo e clocks. Isso tem pequeno impacto na velocidade, mas um grande impacto no sistema operacional. Muitos sistemas de automao operam no principio de standby, desde que um sistema simplex (sem redundncia) pode evoluir para um sistema duplex (redundante) sem grande reengenharia e partes redundantes da planta podem ser conectadas facilmente para no redundantes. Por exemplo, a famlia ABB 800xA usa extensivamente este mtodo para controladores, sistemas de comunicao e mdulos i/o, como Fig. 2.32 mostra para um sistema de automao consistindo de partes duplicadas e simplex. A parte simplex pode entretanto fornecer redundncia atravs de mdulos i/o duplicados. Tanto o standby como o workby compartilham um desafio comum: reintegrao das partes reparadas em um sistema rodando continuamente. A mquina rodando deve ensinar a substituio at a substituio ser capar de operar como uma reserva ainda. Isto cria um pico de carga no controlador que ou fica mais lento durante um intervalo de tempo ou demora a reserva a potncia de computao, justo para os objetivos dessa situao pouco frequente.

32

Fig. 2.31. Standby e workby

Sistemas de alta integridade e persistentes


Quando nem dados errados e nem perda de dados tolervel, ocultar o erro necessrio. Mascarar ou ocultar parcialmente possvel com uma configurao workby, pois no caso de discrepncia entre o controlador trabalhador e o co-trabalhador, os sinais de sada podem ser bloqueados at que uma unidade seja identificada como em falha. Persistncia , entretanto, a perda enquanto o diagnstico est sendo feito. A soluo clssica para a integridade e a persistncia, tambm chamada de controladores confiveis (reliable) a triplicao e votao (Redundncia Modular Triplicada ou Triplicated Modular Redundancy - TMR), um mtodo usado desde o inicio da computao, por exemplo, no foguete Saturno V enviado para a lua. Aqui, trs unidades operam em workby e um sistema de votao toma a maioria (Fig. 2.33).

Fig. 2.33. TMR ou 2003v TMR tem a vantagem de ocultar toda falha. As desvantagens do TMR so: 1. Altssimo custo, pois os processadores so triplicados, h um circuito de votao, links de sincronizao e fontes reservas.

33

2. A sincronizao perfeita dos trs controladores requer um consenso complicado e apresenta desafios tcnicos quando uma unidade tem que ser substituda e reintegrada. 3. Um conjunto de trs controladores falha, no mnimo, trs vezes mais frequentemente que um nico controlador, embora as consequncias de falha sejam bem controladas. 4. TMR requer desenvolvimento especial. H fornecedores especializados, como Triconex e ABB, que possuem sistemas de segurana para redundncia tripla. Para superar a necessidade de desenvolvimento especial, pode-se tambm configurar controladores em alta integridade em QUAD. Estes pares podem ser operados em workby ou em standby.

Fig. 2.35. Sistema QUAD ou 2oo4.

34

2.6. Escalabilidade e versatilidade


Introduo
A escalabilidade de um sistema sua habilidade de ou manipular quantidades crescentes de trabalho de modo suave ou ser facilmente aumentado. A escalabilidade permite o sistema crescer com as necessidades do usurio, proteger seu investimento e garantir abertura para futuras melhorias. Versatilidade significa que o mesmo sistema pode ser usado para automatizar um grande espectro de processos, com diferentes enfoques e exigncias de automao, dependendo de: Indstria leo e gs Potncia Papel e celulose Tamanho Nmero de pontos i/o Nmero de malhas fechadas de controle Nmero de usurios Desempenho Resoluo de armazenamento e horizonte Taxa de amostragem Comunicao de dados Complexidade Algoritmos de controle Interfaces entre mdulos Oramento disponvel Muitos outros fatores bvio que uma pequena cervejaria tem diferentes exigncias e caractersticas de automao que uma grande refinaria. Na cervejaria, o usurio quer uma soluo barata e fcil de engenharia, enquanto na refinaria, o principal foco colocado na segurana e disponibilidade. Se um CPAS formatado para um caso de uso especfico, ele pode ser altamente otimizado para este caso particular, porm ele ser provavelmente restrito a este pequeno nicho. Por outro lado, um sistema de tamanho nico para todos os CPAS tambm significa um compromisso; assim muito importante que o CPAS possa ser customizado para as necessidades de diferentes indstrias. O objetivo fazer um ncleo do CPAS comum e reusvel to grande quanto possvel, de modo que este relativamente pequeno trabalho de customizao permanea. Bons exemplos so os sistemas instrumentados de segurana (SIS), que precisam estar de conformidade com as normas IEC 61 508 e 61 511. Elas incluem aplicaes crticas de segurana tais como sistemas de desligamento ode emergncia, sistemas de deteco de fogo e gs, gerenciamento de fogo. No passado, SIS eram implantados com sistemas totalmente separados. Modernos CPAS oferecem uma arquitetura de sistema nico, unificado e de alta integridade, cobrindo ambas as solues de SIS e controle de processo. Esta arquitetura unificada e de alta integridade reduz a dualidade e os custos associados do ciclo de vida de manter o controle de processo separado dos sistemas SIS. A engenharia de projeto, treinamento, operaes, manuteno e peas de reposio podem ser otimizados atravs do uso de arquitetura comum.

35

Valores da escalabilidade e versatilidade


A principal razo para projetar para escalabilidade e versatilidade reduzir custos e esforos. Grandes mudanas nos objetivos dos negcios inevitavelmente ocorrem, mas permitindo atualizaes iterativas e mais fceis e adies podem reduzir o custo e o esforo dessas alteraes. Padronizao Muitas empresas operam um grande portflio de processo com exigncias muito diferentes. Por exemplo, uma planta petroqumica pode incluir uma planta geradora de energia eltrica. Uma empresa qumica pode operar tanto pequenos processos em batelada como grandes processos contnuos. A opo de utilizar o mesmo CPAS para uso diferente tem as seguintes vantagens: 1. Menor treinamento requerido porque o know-how e a percia podem ser transferidos entre as instalaes. 2. Menor quantidade de peas de reposio 3. As instalaes do CPAS podem ser mantidas pelo mesmo pessoal especializado. 4. As solues desenvolvidas para o usurio para um caso particular podem ser facilmente transferidas para outras instalaes se o mesmo CPAS est sendo usado. Potencial para crescimento Muitas vezes uma boa estratgia comear um novo produto pequeno, com risco limitado. Se o novo produto tiver sucesso, a demanda aumenta e sua produo deve ser aumentada. Isso significa um monte de retrabalho e custos extras se houver gargalos que forcem o usurio a mudar para um CPAS diferente cada vez que a produo aumentada. Muitas empresas querem comear simples e pequenas e depois adicionar mais funcionalidade avanada de automao. Por exemplo, eles podem querer adicionar um sistema para Gerenciamento de Ativos ou uma soluo de Gerenciamento da Informao. No aceitvel que cada nova funcionalidade requeira um retrabalho completo do sistema de automao. Produo em massa reduz custo Os principais blocos de custos de um CPAS incluem: 1. Desenvolvimento 2. Teste 3. Marketing 4. Treinamento 5. Manuteno e atualizao Se vrias realizaes especiais de CPAS completamente separados precisam ter engenharias, isto significa lotes de trabalho duplicados e por isso custo muito mais elevado. Como consequncia, o vendedor no pode gastar muitas fontes para cada CPAS especfico. Para atender exigncias diferentes de diferentes indstrias, a personalizao (customizao) inevitvel. Para evitar adicionar trabalho duplicado sem valor, o ncleo comum do CPAS deve ser maximizado e a personalizao requerida deve ser minimizada.

Projeto para escalabilidade


Os gargalos centrais tais como nmero mximo de pontos i/o, o nmero mximo de clientes ou tudo isso, podem impor limites escalabilidade de um CPAS. Tal gargalo precisa ser evitado usando um projeto modular, quando mdulos podem ser adicionados sob demanda para aumentar o desempenho ou funcionalidade. Fontes centrais como conexes de rede precisam ser dimensionadas de modo que elas possam suportar sistemas maiores. O espectro entre projeto de automao pequeno/simples e grande/complexo grande e difcil de satisfazer pela mesma arquitetura de CPAS. Para permitir o uso de uma nica arquitetura bsica, a despeito dos custos adicionais, os fornecedores de CPAS podem oferecer projetos menos caros, para projetos pequenos/simples. Mesmo se tal soluo seja mais cara e complexa que dedicar sistemas de automao mais complexos, sua escalabilidade compensa quando vista em um contexto maior.

36

Fig. 2.38. O conceito objeto permite adio de funcionalidade sob demanda

Projeto para versatilidade


Versatilidade chama por solues genricas e configurveis. Solues dedicadas para casos especficos devem ser evitadas. Em vez disso, o ncleo do CPAS precisa fornecer um esquema genrico que possa ser personalizado para diferentes necessidades. Por exemplo, a camada dedicada ao trabalho deve ser otimizada para uma indstria especfica (e.g., planta petroqumica) por que todas as outras indstrias iro ter dificuldades em adaptar para tal configurao. Em vez disso, o ncleo do CPAS necessita fornecer mecanismos configurveis de modo que as camadas personalizadas possam ser fornecidas para indstrias diferentes. O conceito aspecto objeto (Fig. 2.38) permite adicionar aspectos especficos sob demanda; por exemplo, assumindo que uma planta quer adicionar a funcionalidade de monitorar ativos para sua j existente soluo, isso ser facilmente adicionado aos objetos existentes. Em muitos casos, isso pode ser feito em poucos locais centrais e assim automaticamente herdado para todos os objetos relevantes. Os aspectos de monitor ativos pode conseguir informao do contexto de outros aspectos do mesmo objeto.

37

2.8. Segurana Parmetro chave na engenharia de controle


Introduo
No desenvolvimento atual na engenharia de automao e de controle h uma forte tendncia que a segurana uma disciplina essencial e inevitvel no desenvolvimento, produo, engenharia e servio do sistema. A demanda pelos usurios por conformidade s normas de segurana aplicveis, tais como IEC 61 508, IEC 61 511, IEC 62 061 e ISO 13 849, fora os fabricantes de equipamento e fornecedores de sistemas a implementar as caractersticas de segurana requeridas. No ambiente de engenharia crescentemente multidisciplinar e em face da complexidade cada vez maior do sistema, h uma necessidade crescente para todos os engenheiros e tcnicos envolvidos na engenharia do processo a cuidar das implicaes de projeto e operao de sistemas seguros. Isto inclui conhecimento das normas de segurana relevantes, desenvolvimento de segurana, engenharia de segurana e servio de segurana, para o qual um entendimento slido e uso flexvel de enfoques de engenharia para sistemas incluindo hardware e software so precondies indispensveis.

Segurana, segurana funcional e quatro componentes de realizao


Baseada na norma IEC 61 508, segurana a liberdade de risco inaceitvel de dano fsico ou de perigo para a sade de pessoas, ou diretamente ou indiretamente, como resultado de dano propriedade ou ao meio ambiente (IEC 61 508-4 1998). Segurana funcional parte da segurana total relacionando o equipamento ou processo sob controle ao sistema de controle correspondente, que depende do funcionamento correto do sistema relacionado com a segurana. Por exemplo, um equipamento de proteo de temperatura, usando um sensor termal nos enrolamentos de um motor eltrico usado para desligar o motor antes que ele fique superaquecido, um exemplo de segurana funcional. Mas fornecendo isolao especial para suportar alta temperatura no um exemplo de segurana funcional, embora seja ainda uma instancia de segurana e possa proteger contra exatamente o mesmo perigo. Uma funo de segurana tem o objetivo de conseguir ou manter o estado seguro do processo ou equipamento sob controle, em relao a um evento perigoso especfico. O estado seguro o estado do processo ou operao do equipamento onde o evento perigoso no pode ocorrer. Segurana absoluta, onde o risco completamente eliminado, pode nunca ser conseguido com esforo e custo aceitveis. O risco pode apenas ser reduzido a um nvel aceitvel. Segurana funcional baseada na norma IEC 61 508 usa nvel de integridade de segurana (safety integrity level SIL) para medir a confiabilidade pretendida de um sistema ou funo. H quatro nveis definidos de SIL, com SIL 4 fornecendo a mais alta confiabilidade e SIL 1 a mais baixa. Um SIL determinado baseando-se no nmero de medidas qualitativas e quantitativas. Um sistema relativo segurana que implanta segurana funcional e fornece conformidade s normas de segurana relativas suposto mostrar evidencia convencimento para os corpos responsveis de autoridade e certificao baseado em tais medidas. Exemplos de medidas qualitativas: 1. Programa temporal e monitorao de sequncia 2. Verificao da plausibilidade e valor limite 3. Superviso de memria varivel e invarivel 4. Monitorao do fluxo de dados As medidas quantitativas incluem a probabilidade de falha para executar uma funo de segurana (PFD) e aa probabilidade falha por hora (PFH). A realizao de segurana funcional necessita de quatro componentes chave: 1. Gerenciamento da segurana funcional 2. Medidas de segurana do produto no sistema 3. Caso de segurana 4. Competncia

38

Fig. 2.47 ilustra a estrutura da reduo de risco.

Medidas de segurana no sistema Um sistema relacionado com a segurana necessita realizar as medidas de segurana requeridas, que so necessrias para reduzir os riscos perigosos e atingir o nvel de integridade de segurana estabelecido. Um enfoque arquitetural apropriado necessrio para enderear os desafios tais como deteco de falha, isolao e reao. Alm disso, algumas limitaes da arquitetura, tais como exigncia de tempo real, concorrncia, disponibilidade, confiabilidade e compromisso entre custo do sistema e custo de engenharia so fatores tcnicos de econmicos essenciais para um sistema relativo segurana. Gerenciamento da segurana funcional Um sistema relativo segurana deve ser confivel. Suas falhas devem ser tratadas com base no nvel de integridade de segurana estabelecido. Duas categorias de falha so introduzidas em segurana funcional: falha aleatria e falha sistemtica de equipamento. Falha aleatria do equipamento ocorre em tempo esprio e resulta de um ou mais mecanismos de degradao no equipamento. Falha sistemtica est relacionada de um modo determinstico a certas causas em especificao, projeto, montagem, fabricao, configurao, comissionamento, operao, manuteno e suporte. O assunto chave no gerenciamento da segurana funcional tratar das falhas sistemticas nas diferentes fases do ciclo de vida do produto como configurao, instalao, comissionamento e operao. Gerenciamento verificvel e controlvel, incluindo um desenvolvimento consistente e um processo de engenharia com enfoques apropriados para especificao, projeto, montagem, verificao, validao e documentao, crucial para se conseguir a segurana funcional. Uma ferramenta de engenharia de conformidade com o SIL uma medida eficiente para evitar falhas em engenharia. Caso de segurana Um caso de segurana um conjunto de evidcia reivindicvel para os argumentos que suportam o preenchimento de uma exigncia gerencial ou tcnica relacionada com segurana de um modo capaz de convencer um assessor de segurana. Identificao, coleo e documentao so requeridas para criar um caso de segurana. Uma tcnica de documentao conveniente necessria. Competncia A eficincia das medidas ser severamente limitada se o pessoal responsvel por sua realizao no tiver a competncia requerida. Realizao da segurana funcional uma prtica multidisciplinar, que necessita ao apenas de competncia tcnica compreensiva, mas tambm habilidades de gerenciamento substanciais. Competncia tcnica cobre conhecimento das normas de segurana relativas, capacidade em conceito e projeto da arquitetura e tcnicas de documentao

39

sistemas e estruturadas, enquanto as habilidades de gerenciamento incluem a superviso e controle sistemticos das atividades relacionadas com segurana requeridas, bem como a percepo e manipulao de fatores humanos.

SIS
Sistema instrumentado de segurana (SIS) uma forma de realizao de segurana funcional para processos industriais tais como refinaria de petrleo, gerao de energia e reaes qumicas. Um SIS formalmente definido na norma IEC 61 508 como um sistema distinto, confivel usado para proteger um processo para evitar uma liberao catastrfica de produtos txicos, inflamveis ou explosivos. Um SIS executa funes instrumentadas especficas de segurana (SIF) para atingir ou manter um estado seguro de um processo quando condies de processo inaceitveis ou perigosas forem detectadas. Sistemas instrumentados de segurana so: 1. Sistemas de desligamento de emergncia de processo 2. Sistemas de desligamento de processo 3. Sistemas de intertravamento 4. Sistemas de proteo de alta presso 5. Sistemas de proteo de oleodutos 6. Sistemas de deteco de fogo e gs A operao correta de um SIS requer uma srie de partes de equipamento funcionarem corretamente. Um SIS possui sensores capazes de detectar condies operacionais anormais, tais como alta vazo, baixo nvel ou posio incorreta da vlvula. Uma interface de entrada conecta o sensor com um resolvedor de lgica, que processa o sinal do sensor e muda suas sadas de acordo com a lgica definida pelo usurio. O resolvedor de lgica pode ser eltrico, eletrnico ou equipamento de eletrnica programvel, tal como um controlador single loop, um controlador lgico programvel (CLP) ou circuito integrado de aplicao especfica (ASIC). O sinal do resolvedor de lgica ir atuar no elemento final, tal como contator, vlvula, solenide, atravs de uma interface de sada. O sistema de suporte relacionado para configurao e parametrizao deve ser projetado para fornecer a integridade e confiabilidade requeridas. Limites da arquitetura Um sistema relacionada com segurana deve ser capaz de enderear um conjunto de desafios de arquitetura, que precisa ser considerado no projeto e engenharia de um SIS. Disponibilidade Disponibilidade uma medida que define a probabilidade de um processo ser opervel. A disponibilidade de um sistema de controle de processo pode ser aumentada atravs do uso paralelo de componentes do sistema ou redundncia. Em muitos casos, disponibilidade contrrio doe segurana. Um SIS projetado para atingir ou manter o estado seguro de um processo, que tipicamente significa que os processos relativos sejam requeridos para parar e assim no mais operar ou ser disponvel. Por isso, importante no desenvolvimento e engenharia da segurana considerar a disponibilidade. Um bom SIS deve ser capaz de fornecer um bom compromisso entre disponibilidade e segurana. Integrao Integrao significa que o mesmo equipamento do sistema, a mesma ferramenta de engenharia e a mesma interface humano mquina (IHM) sejam usados para o Sistema de Controle do Processo Bsico (BPCS) e SIS. Tradicionalmente, o BPCS e SIS so separados um do outro. A tendncia recente mostra que mais e mais sistemas so integrados juntos so usados. Isto significa que eles usam o mesmo equipamento, IHM e ferramenta de engenharia. Isto ir reduzir o custo do equipamento, o esforo para fazer engenharia, configurao, comissionamento e operao; porm, em uma soluo integrada crucial garantir a independncia lgica das partes relacionadas com segurana e as partes relacionadas com a no-segurana.

40

Independncia lgica Independncia lgica significa que falhas no sistema de no segurana no levam a falhas do sistema relacionado com a segurana, de modo que o SIS no pode satisfazer sua funo de proteger o processo sob controle dos perigos. A independncia lgica pode ser conseguida atravs de parties de fontes e tempo (i.e., deve-se garantir que um SIS ir usar as fontes e tempo requeridos para fazer suas funes de segurana. A independncia lgica tambm pode ser conseguida se todas as falhas nas partes relacionadas com a no segurana que esto relacionadas para executar as funes instrumentadas de segurana sejam diretamente ou indiretamente detectadas e controladas corretamente. Medidas de integridade de segurana Medidas de integridade de segurana so aquelas que devem ser executadas para conseguir o nvel de integridade de segurana desejado. A norma IEC 61 508 especifica um conjunto de medidas de segurana com uma especificao para cada medida. A Tab. 2.3 d alguns exemplos dessas medidas. necessrio considerar essas medidas no nvel da arquitetura para mostrar qualquer limite estrutural que possa ter um impacto global na realizao de todo o sistema. Modularidade Modularidade um modo de gerenciar a complexidade de um sistema e tambm fornecer a flexibilidade necessria para aplicaes de segurana. A norma IEC 61 508 prope o uso de subsistemas para construir a arquitetura do sistema. Alm dos princpios normais de modularidade, tais como funes claramente definidas do subsistema com interfaces que so to simples quanto possvel, tambm necessrio considerar a reusabilidade e os casos de segurana relacionados com cada subsistema. Subsistemas conformes com o SIL, que no apenas incluem revolvedores de lgica, mas tambm instrumentos de campo, mdulos i/o e atuadores, ajudar a reduzir o esforo requerido para construir uma malha de segurana completa. Gerenciamento e engenharia de segurana funcional Para enderear a variedade de exigncias de um SIS precisa de flexibilidade e adaptabilidade, que podem ser conseguidas por um ambiente de engenharia conforme com o SIL. Adicionalmente, o ambiente de engenharia de segurana de auxiliar a enderear de modo eficiente as exigncias do gerenciamento da segurana funcional, que cobre o sistema inteiro de segurana, ciclo de vida do planejamento, atravs do projeto e gerenciamento da biblioteca, para comissionamento e suporte. Um conjunto de medidas para evitar falhas sistemticas deve ser realizado no sistema de engenharia. Conceitos e medidas de segurana, tais como salvaguarda para evitar falhas sistemticas devido a configurao de conformidade com no-SIL, so necessrias. Uma vez identificada como aplicao de segurana, o sistema de engenharia automaticamente ir limitar as escolhas de configurao do usurio e ir evitar paradas se as exigncias SIL no forem satisfeitas. Alm da capacidade de engenharia de conformidade com SIL para a configurao de aplicaes de segurana, o sistema de engenharia tambm deve fornece norma de conformidade SIL e biblioteca de aplicaes especficas. Normas de segurana funcional As normas de segurana funcional tem uma grande influncia no projeto da arquitetura do sistema de um SIS. Normas de segurana podem ser classificadas como normas bsicas de segurana e normas especficas de segurana. A Tab. 2.4 mostra o panorama dessas normas mais importantes que devem ser consideradas.

41

Tab. 2.3. Medidas de integridade de segurana

Tab. 2.4. Normas de segurana

42

Componentes tpicos de um SIS A Fig. 2.48 ilustra a arquitetura tpica de um SIS, que inclui uma sistema instrumentado para proteger um processo sob controle de perigos e um sistema de engenharia e um sistema de controle de processo bsico (BPCS) para controle padro do processo. Tradicionalmente, o BPCS tem ficado separado do SIS para garantir a independncia das partes relacionadas com segurana das partes relacionadas com a no-segurana. Esta soluo normalmente requer alto custo de sistema e mais engenharia de sistema e esforo de manuteno. Alm das funes regulares de engenharia, o sistema de engenharia deve fornecer caractersticas para suportar o gerencial da segurana funcional para evitar falhas sistemticas, que, como j dito, podem ocorrer em engenharia de aplicao de segurana, incluindo especificao, planejamento, projeto, gerenciamento de biblioteca, comissionamento e suporte. Ele deve mostrar capacidade no gerenciamento dos dados crticos de segurana, configurao e entrega dos casos de segurana requeridos.

Fig. 2.48. Arquitetura de SIS com ambiente de engenharia

Arquiteturas alternativas Os SIS podem ter trs diferentes arquiteturas: separadas, interfaceadas e integradas. Cada uma tem suas vantagens e desvantagens, que devem ser consideradas no projeto de um SIS. Os parmetros a considerar na seleo da melhor arquitetura so: custo, erro de causa comum e nvel de esforo de engenharia, aprendizagem, treinamento, manuteno. Arquitetura separada O sistema bsico de controle de processo (BPCS) e o sistema instrumentado de segurana (SIS) so de diferentes fornecedores e tem dois sistemas de engenharia diferentes. Essa arquitetura j foi a soluo preferida para muitas aplicaes que precisavam satisfazer as exigncias de

43

segurana. Por causa doso diferentes fornecedores e diferentes sistemas de engenharia, a arquitetura normalmente tem alto custo, muito trabalho de engenharia, treinamento e esforo de manuteno, resultando em alto custo operacional. A principal vantagem dessa arquitetura que a menos susceptvel a erros de causa comum, pois os sistemas so totalmente separados e independentes. Fig. 2.49 mostra a arquitetura separada.

Fig. 2.49. Arquitetura separada

Arquitetura interfaceada O BPCS e o SIS so fornecidos pelo mesmo fabricante, porm eles no so intercambiveis, embora eles sejam muito parecidos. H duas ferramentas de engenharia separadas, embora similares, uma para o BPCS e o SIS. Os dois sistemas PBCS e SIS compartilham a mesma estao de desenvolvimento e os mesmos tipos de fiao. A principal vantagem dessa arquitetura que menos susceptvel a erros de causa comum, por causa da diversidade interna e softwares de diagnstico. Fig. 2.50 mostra a arquitetura interfaceada.

Fig. 2.51. Arquitetura interfaceada

44

Arquitetura integrada Esta a soluo totalmente integrada, com a mesma ferramenta de engenharia, desenvolvimento e estao de operao. Os dois sistemas BPCS e SIS so fornecidos pelo mesmo fabricante e instalados na mesma unidade fsica. Nessa configurao integrao, a probabilidade de erro de causa comum alta. Fig. 2.51 mostra a arquitetura integrada.

Fig. 2.51. Arquitetura integrada

Concluso
A segurana funcional no apenas uma caracterstica de um sistema, mas tambm uma capacidade de processo relacionado com desenvolvimento que aplicado para desenvolver um sistema com exigncias de segurana. O gerenciamento da segurana funcional crucial para evitar falhas sistemticas no sistema. Para o desenvolvimento de um sistema relacionado com segurana, importante considerar os limites da arquitetura associada. Disponibilidade, integrao, flexibilidade, adaptabilidade, independncia, medidas de integridade de segurana e normas relacionadas segurana so alguns fatores que precisam ser considerados no desenvolvimento. Arquiteturas separadas, interfaceadas e integradas so alternativas bem conhecidas.

45

3.1. Engenharia
Introduo
Um projeto de engenharia pode consistir em construir uma nova planta de gerao de energia, para atender a crescente demanda de energia de um pas, uma refinaria de petrleo para produzir gasolina, leo diesel, gs liquefeito de petrleo e outros derivados ou uma planta farmacutica para produo de um novo remdio. A realizao terminada quando uma termeltrica gera 500 MW de energia eltrica, a refinaria produz 100 mil litros de gasolina por dia ou a indstria farmacutica produz uma grande quantidade de matria prima na forma de p para ser usado na produo de comprimidos de remdio. Todas essas plantas tem algo em comum: devem atender normas legais de segurana para o meio ambiente, deve ser em um local onde as pessoas possam trabalhar em segurana, alm de ser alta eficiente e produtiva. Todas essas plantas requerem energia eltrica, calor em forma de vapor, telecomunicao, informao, climatizao, tratamento de efluentes na sada, tratamento de gua na entrada, transporte, infraestrutura, utilidades e, certamente, as matrias prima apropriadas. Em geral, o atendimento a essas necessidades requer competncia em entender e capturar as exigncias, planejar e projetar, para a realizao dos planos em software e hardware e finalmente comissionar, testar e partir a planta. Quando se pensa em to diferentes pessoas que so necessrias para construir uma residncia, claro que construir uma planta industrial requer muito mais gente envolvida, cada uma tendo competncias tcnicas diferentes e complementares para satisfazer essas tarefas. Mas, no mnimo no mesmo nvel, elas precisam da habilidade de se comunicar, entender as dependncias e interfaces com o trabalho das outras pessoas. Alm disso, elas devem tratar de grandes quantidades de dados, ter um modo cuidadoso de trabalhar para permitir mudana de gerenciamento, entender as diferenas culturais e ter a determinao de tratar as situaes repetitivas e as desafiadoras no padro. A tenso e a felicidade de centenas de pessoas que contribuem para um projeto no momento de partida de uma nova planta so indescritveis, e o autor sentiu isso na partida do polo de Camaari, na dcada de 1970.

Fig. 3.1. Plataforma de petrleo, planta de fertilizantes e petroqumica

46

CPAS no contexto da engenharia da planta


A Engenharia do Sistema de Automao sempre incorporada em uma srie de passos de trabalho mais complexos. A deciso de construir uma nova planta usualmente feita pela empresa que quer finalmente possuir uma. Essa empresa chamada de proprietrio/operador e pode decidir em contratar uma ou vrias empresas de engenharia para executar o processo completo de construir uma planta de processo. Essa empresa chamada de um EPC (Engineering, Procurement and Construction). O contratante EPC decide que partes do trabalho sero executadas por ele mesmo e quais sero subcontratadas para outros. Em muitos casos, o subcontratantes ainda tem parceiros que faro parte de seu trabalho. O fornecedor do sistema de automao usualmente no papel de um subcontratante. Para se ter um bom entendimento dos vrios passos de engenharia de hardware e software requeridos para o sistema de automao, importante olhar sua posio dentro do projeto do sistema global. Embora diferentes subdivises possveis de projeto sejam possveis, as oito mostradas na Fig. 3.2 so comumente usadas: 1. Engenharia final e projeto (Front-end engineering and design FEED) 2. Site e edifcios 3. Equipamento do processo 4. Transporte e armazenagem 5. Sistema eltrico 6. Instalao dos edifcios 7. Instrumentao de campo 8. CPAS Na primeira fase, FEED, o proprietrio/operador decide acerca dos detalhes tcnicos do processo (segurana, P&ID), implicaes legais (localizao, contratos) e assuntos organizacionais (finanas, cronograma, parceiros do projeto, processo de cotaes). Todas as outras fases seguintes so usualmente e altamente paralelas e cada uma influencia a outra. Elas comeam com os parmetros espaciais durante a camada Site e Edifcios (terraplanagem, fundaes, ruas) e o planejamento dos edifcios (paredes, tetos e estruturas metlicas). Em paralelo aos detalhes de construo, a camada Equipamentos de Processo detalhada com os principais objetivos da planta: turbinas, geradores, compressores, bombas, colunas de destilao, reatores, fornos, caldeiras, trocadores de calor, fermentares, separadores, e muito mais.

Fig. 3.2. Fases de trabalho de um projeto

47

Assim que os detalhes e locais do equipamento do processo sejam decididos, os equipamentos passivos (Transporte e armazenagem) podem ser planejados para conectar e suportar o equipamento do processo. Exemplos so: tanques, vasos, tubulaes, esteiras. Em um passo posterior do planejamento do equipamento secundrio, necessrio para eletrificao, controle e suporte para os humanos, partidas. Equipamento secundrio inclui o Sistema Eltrico, compreendendo: transformadores, disjuntores, fontes de alimentao, drives, fiao eltrica, aterramento, proteo contra raios, etc. A camada Instalao dos Edifcios um termo guarda-chuva para a alimentao e fornecimento de gua, luz, ar, aquecimento/resfriamento, redes para IT, facilidades sanitrias, comunicao (telefone, alto-falantes) e sistemas de proteo (security): cmaras, sensores de proximidade. Algum tempo aps estas fases comearem, a engenharia para o sistema de automao, que ir medir e controlar os parmetros do processo, partidas, paradas. Esta fase compreende duas partes: Instrumentao de Campo (sensores e transmissores para presso, temperatura, vazo, nvel e anlise, atuadores tais como vlvulas e bombas) incluindo comunicao de campo (como as redes fieldbus) e o CPAS, que inclui sistema de controle, gerenciamento da informao, controle de batelada, listagens e solues avanadas como MES (Manufacturing Execution Systems) e PPS (Production Planning Systems). O termo clssico I&C que era usado antigamente para Instrumentao (de campo) e Controle agora substitudo por Instrumentao (de campo) e CPAS. O fato que o sistema de automao projetado no ltimo estgio resulta no desafio que todas as exigncias e alteraes de projeto (incluindo os erros) das outras fases devem ser consideradas. Adicionalmente, CPAS, a despeito de ser a tecnologia mais nova, tem rapidamente desenvolvido em sendo a janela para o site e o processo. Naturalmente, as exigncias para integrao com Instalao do Prdio e Eltrica expandem os desafios, aumentando as interdependncias e outras exigncias e assim aumentando a complexidade da engenharia do CPAS. Isso explica por que hoje I&C constitui 10 a 20% do custo total do projeto para uma nova planta.

Fatores afetando a engenharia de Instrumentao e Controle (I&C)


A estrutura bsica de um CPAS em todas as plantas de processo comparvel. Porm, cada planta nica. Assim, projetos I&C, sendo negcios de sistemas requerem mais ou menos solues individuais para cuidar das especificaes de cada projeto. Elas incluem: Campo verde ou marrom Somente metade dos gastos mundiais em projetos I&C com instalaes completamente novas (chamados de projetos de campo verde). Muitos dos projetos so relativos a modernizao, atualizao (retrofit), adaptao ou expanso de plantas existentes (chamados de campo marrom). Projetos de campo marrons usualmente s aplicam a partes de uma planta completa (e.g., IHM), enquanto deixando a maior parte dela inaltervel (.e.g. instrumentao de campo). Porm, necessrio um esforo adicional para atualizar a documentao para refletir todas as mudanas feitas na planta nos ltimos tempos de operao e modificao. Tamanho da planta O tamanho de uma planta pode ser medido por seu tamanho espacial, por seu custo de construo ou pelo nmero de pontos de entrada e sada (i/o). Em primeira ordem, esse nmero corresponde ao nmero de tags, pontos ou equipamentos do processo (ou analgicos ou discretos). Em um nvel mais detalhado, necessrio diferenciar pontos i/o com fiao fsica, pontos i/o em redes digitais e pontos i/o em software das unidades pacote tais como servidores OPC. O tamanho mdio de todos os projetos I&C cerca de 1000 i/o, com uma faixa de menor que 100 para pequenos projetos, para refinarias sendo os projetos maiores, com cerca de 100 000 pontos i/o (2007). H uma tendncia mundial de se ter projetos cada vez maiores. Quanto maior o projeto, maior a exigncia de se ter eficincia na manipulao de dados e se ter uma engenharia paralela multiusuria.

48

Escopo da entrega O contratante EPC pode subcontratar outra empresa para fazer tudo de uma pequena parte do sistema de controle at os sistemas completos de I&C e eltrica. Naturalmente, um projeto com um grande escopo suporta mais potencial de otimizao e um diferente fluxo de trabalho do que um projeto mais simples e menor, que requer menor tempo de execuo. Mesmo assim, as tarefas que devem ser feitas permanecem as mesmas, independente de quem vai execut-las. Local da planta Outro fator importante de influncia o local da planta. Pode-se imaginar que testar um sistema I&C para uma plataforma offshore de petrleo mais simples e barato em terra. H plantas de papel e hidreltricas que esto localizadas no meio de nada e conveniente usar partes prmontadas. Sempre lembrar que em todo lugar do mundo h normas e leis regulando e exigindo certificados ambientais. Exigncias da empresa Muitos proprietrios/operadores, bem como subcontratantes I&C, tero exigncias de acordo com sua estratgia de negcios e preferencias (e.g., escolha de hardware, protocolos de comunicao ou ferramentas). Grandes companhias de automao poderia usar uma equipe de especialistas globalmente distribuda, enquanto as empresas menores teriam uma equipe concentrada em um local. Domnio Um fator que pode fazer uma grande diferena o domnio. Sero vistos as exigncias que so comuns a todas as indstrias de processo e utilidades. Porm, interessante mencionar algumas destas especificaes: Instalao de leo e gs lida com materiais explosivos e inflamveis e assim tem exigncias fortes para a segurana. A frao da segurana i/o para deteco de fogo e gs pode ser to alta quanto 50% de todas i/o. Esta uma razo por que as refinarias esto entre as maiores plantas para contagem de i/o. instalaes de plataformas de explorao e produo de leo e gs so menos padronizadas devido a variedade na composio do leo e nas condies martimas. Todas plataformas, porm possuem espao reduzido, resultado em uma alta densidade de equipamentos e instrumentos. Oleodutos e gasodutos podem se estender por milhares de kilmetros com a necessidade de monitorao remota. Farmacuticas e indstrias de alimentos e bebidas apresentam alta demanda por rastreabilidade e validade das informaes. 30% do trabalho gasto em documentao. A diversidade dos produtos resulta em algum tipo de batelada e os processos so semi-contnuos e assim o cdigo de controle tem alta relao de sequencias de controle. Plantas qumicas tem um alto nmero de sensores e instrumentos de anlise para qualidade do produto e monitorao de emisso e assim 50% dos dados transmitidos so em valores analgicos do processo. A diversidade dos produtos e plantas pode ser muito alta. Como o processo completamente selado, os edifcios geralmente degeneram para estruturas metlicas abertas com tubulaes anexadas a eles. Exigncias de segurana so crescentes. O estado seguro de uma planta no poderia ser desligado, como em outras plantas, mas, e.g., resfriar ativamente um vaso para parar uma reao qumica em si. Indstria de papel e celulosa tem exigncias de alta qualidade combinada com altas velocidades em demandas muito rpidas (milissegundos) com medio em linha (e.g., espessura de papel), controle (e.g. presso do rolo) e comunicao. Simulao avanada de processo e comissionamento virtual requerem know-how especfico do processo, mesmo que seja altamente padronizada. Minerao trata de prospeco para obter, pulverizar e transportar minrio ou pedra. As dimenses espaciais podem ser muito grandes, requerendo atuadores, transportadoras, comunicao e localizao (GPS). A soluo em si pode ser altamente padronizada.

49

Utilidades tais como gua transportada ou tratada pode ter uma grande distribuio espacial. Isto resulta em um grande nmero de atuadores (e.g., bombas) e demanda por monitorao e operao remota. A despeito de todas as diferenas, as tarefas bsicas em todos os domnios mencionados so ainda to comparveis que normas gerais para comunicao, visualizao e engenharia tem se tornado largamente aceito e os fornecedores de sistemas de automao esto convergindo em direo do suprimento de uma faixa completa de indstrias com um conjunto de hardware e ferramentas.

Tarefas da engenharia I&C


As principais fontes que descrevem as fases da engenharia so, conforme NAMUR NA 35 (2003): 1. 2. 3. 4. 5. 6. 7. Determinao bsica Engenharia preliminar Engenharia bsica Engenharia de detalhamento Construo Comissionamento Trmino do projeto

Manipulao de dados

Fig. 3.4. Grfico esquemtico do Plano do Projeto I&C

50

Fig. 3.6. Exemplo de hardware do sistema de controle

Fig. 3.7. Painis cegos, sistema de comunicao e display

51

3.2. Programao Lgica de Controle


Introduo
A atividade central de um projeto de automao a criao da funcionalidade de controle, como estabelecido nas Folhas de Especificao dos Instrumentos e outros documentos. Para executar o cdigo de controle existem vrias alternativas, chamadas de linguagens. Quando os sistemas de controle de processo programvel apareceram nos anos 1960 e 1970, cada fabricante de equipamento desenvolvia sua prpria linguagem para realizar a funcionalidade. Alguns fabricantes de controlador lgico programvel (CLP) escolhiam uma linguagem de programao similar lgica de rel, que era conhecida pelos eletricistas e chama-se ladder. Outros usavam linguagens textuais, similares a programao de computador pessoal, como Assembler ou Basic. Para processos discretos, o fluxo de controle era representado de um modo grfico. Isso resultou em uma variedade de linguagens de programao. Porm, para o usurio e operador da planta, benfico ter uma linguagem compatvel e padronizada. As vantagens so: esforo de treinamento reduzido para o pessoal de manuteno, facilidade de troca de fornecedor e de equipamento, reuso de solues atravs de plataformas e simplificao de migrao entre sistemas. Por essa razo, em 1993, a ISO/IEC publicou a norma 61 131, incluindo quatro linguagens de programao. Alguns consideram cinco linguagens, considerando a ferramenta de programa SFC (Sequential Functional Chart) como linguagem.

IEC 61 131-3
A norma IEC 61 131 uma norma internacional sobre controladores programveis em um aspecto amplo e consistindo de oito partes: definies, exigncias e testes, linguagens, recomendaes, comunicaes, lgica fuzzy e guia para aplicao e realizao de linguagens. A parte 3, chamada de linguagens de programao, define quatro (ou cinco) linguagens com regras sintticas e semnticas, conjuntos de elementos de programao, testes aplicveis e meios pelos quais o bsico pode ser expandido pelos fabricantes. Todas as quatro linguagens tem em comum os seguintes elementos: 1. Tipos de dados O tipo de dados especifica o tamanho e significado do contedo da varivel. H quatro tipos de dados (o nmero entre parntesis d o consumo de memria em bits). 1. Dado tipo Bit; BOOL (1), BYTE/CHAR (8), WORD (16), DWORD (32) e LWORD (64. 2. Tipos aritmticos: SINT (8), INT (16), DINT (32), LINT (64), REAL (32) e LREAL (64). Os tipos inteiros podem ser com sinal (signed, SINT) ou sem sinal (unsigned) UINT (8). 3. Tipos de tempo: DATE (16), TIME (32) e TIME_OF_DAY (32). 4. Tipos de dados multielemento (alternativamente composto ou derivado) que requerem a especificao do consumo de memria durante a programao: ARRAY, STRUCT e STRING.

Fig. 3.17. Classificao das linguagens de programao digital

52

2. Variveis Variveis precisam ser declaradas (tipo de dado, nome ou endereo), ter escopo (local, global, entrada, sada, comportamento de partida) e inicializada (existem valores iniciais default). Exemplos de declaraes so mostrados na Tab. 3.1. 3. Unidades de organizao de programa Funes calculam e retornam exatamente um valor resultado, baseado em um ou mais valores de entrada. Elas so chamadas de blocos de funo internos e no possuem memria interna. Funes so geralmente fornecidas pelo fabricante do CPAS como os menores blocos funcionais construtivos. Blocos de funo podem calcular e retornar mais do que um valor e podem armazenar estados internos mesmo depois que o bloco de funo tenha sado (funo memria). Uma segunda chamada com os mesmos parmetros de entrada pode assim levar a um resultado diferente. Blocos de funo so instanciados dentro de programas ou outros blocos de funo e so geralmente definidos pelo usurio. Programa o nvel topo lgico do conjunto de todos os elementos e constri o processamento do sinal pretendido. Programas so chamados de fontes internas.

Exemplo
VAR AT %MW48 : INT; AUTO : BOOL :=1; NAME STRING[10]:

Explicao
Aloca um valor inteiro de 16 bits no local (memria) 48. aloca memria dinmica para uma varivel booleana simblica AUTO com valor inicial = TRUE. Aloca memria dinmica para conter um string com um comprimento mximo de 10 caracteres. O string inicial deixado para default (vazio com comprimento 0).

END_VAR

Grupo de funo
Controle lgico Lgica binria Temporizadores Contadores Processamento ode dados Funes matemticas

Exemplos (funo ou bloco de funo)


AND, OR, NOT, XOR, elementos biestveis Temporizador TON e TOF Contador UP e DOWN

Manipulao de dados Sinal analgico Funes de interface Entrada/sada Converso BCD Outros sistemas Comunicao IHM Display, comandos Impressoras Mensagens, relatrios Memria de massa Logging Nota: a funcionalidade oferecida nas quatro linguagens, porm a sintaxe varia.

Aritmtica bsica: ADD, SUB, MUL, ABS, DIV, MOD Aritmtica estendida: SQRT, trigonometria e logaritmo Comparadores: maior que, menor que, igual, maior ou igual a, menor ou igual a, no igual Seletor: MAX, MIN, MUX, SEL, LIMIT Tipo de converso, mover, desviar (shift), formatar PID, integrao, filtro (no como norma)

53

4. Elementos de configurao Os elementos de configurao para memria e execuo do cdigo: fontes, caminhos de acesso e tarefas. 5. Instanciao Instanciao a possibilidade de derivar novos tipos de dados, funes, blocos de funo, i.e., definir novidades baseadas na norma. Cada uma das quatro linguagens possui suas prprias caractersticas em uso regional, sintaxe e possibilidades para controlar a ordem dos eventos. Exemplos de diferenas funcionais so jump condicional e no condicional para um dada etiqueta (label), malhas (FOR, WHILE, REPEAT), parntesis (IF ... THEN ... ELSE), arranjo de matrizes e multitarefa. Geralmente as linguagens textuais (Texto Estruturado, ST e Lista de Instrues, IL) tem mais poder de modelagem, que significa que o cdigo grfico pode ser transladado em linguagem textual, mas no necessariamente a linguagem textual pode ser transladada em linguagem grfica. Somente quando certas regras (limitaes) so seguidas possvel converter automaticamente uma linguagem em outra. Lista de Instrues (IL) - A linguagem Lista de Instrues uma linguagem de programao textual parecida com Assembler. Ela lista uma sequncia de instrues simples, prxima ao conjunto de instrues do processador. IL oferece manipulao de bit em um nico registro aritmtico. IL aplicada principalmente para pequenas aplicaes e seu uso cada vez menos comum. Texto Estruturado (ST) uma linguagem procedural que oferece funcionalidade em alto nvel de abstrao, comparvel ao Pascal. Sua flexibilidade a torna conveniente para as definies de novos blocos de funo (derivados). Diagrama ladder (LD) tem origem nos esquemas de fiao de lgica de rel, um formato que os eletricistas conhecem. A rede grfica assim representa um fluxo de potncia anlogo potncia eltrica em sistemas de rel. LD a linguagem preferida dos americanos. Diagrama de blocos de funo (FBD) uma linguagem grfica padronizada representando o fluxo do sinal entre elementos de um sistema de processamento de sinais. FBD a linguagem preferida dos europeus. A FBD uma linguagem intuitiva, fcil de entender e assim til para comunicao, documentao, teste e manuteno da lgica do controle. H ainda uma ferramenta de programao chamada de Sequential Function Chart (SFC) que alguns consideram uma linguagem. SFC uma representao de um fluxo de atividade e por passos. Ele compreende dois elementos de linguagem principais para ordenar programas ou blocos de funo. Como os elementos da SFC requerem armazenagem de informao de estado interno, as funes no podem ser estruturadas usando SFC.

Tendncias em linguagens de programao de controle


Para o CLP, h um claro compromisso para as quatro linguagens contidas na norma. Algumas empresas oferecem ambientes de programao IEC 61 131-3 independente do hardware a serem usadas atravs de diferentes plataformas de hardware, que suportam fcil migrao. Possibilidades para programar novos blocos de funo ou programas completos em linguagens de alto nvel, como C, C++ ou Java, est em moda. Com CPAS diferente. Mesmo que todos os fornecedores ofeream uma ou mais linguagens de programao similares entre si na IEC 61 131-3, eles geralmente quebram a compatibilidade oferecendo especificaes diferenciadas para otimizar a usabilidade, funcionalidade ou desempenho. Por exemplo, FOUNDATION Fieldbus (FF) usa programa estilo bloco de funo mas adiciona a possibilidade de fcil distribuio da funcionalidade de controle entre todos os dispositivos da rede FF: controladores, transmissores ou posicionadores de vlvula. Tentativas de padronizar as funcionalidades do controle distribudo no topo de IEC 61 131-3, como na IEC 61 499, ainda no est bem difundidas. Quanto maior os programas de controle, mais importante ter uma boa (explcita) documentao do cdigo de controle, como tambm entender facilmente o cdigo (documentao

54

implcita). Isto pode ser suportado por recomendaes de programao, favorecendo programao grfica (FBD) e promovendo conceitos que so conhecidos da orientao de objeto: estruturao hierrquica, modularizao e encapsulao. A funcionalidade encapsulada coletada em bibliotecas que podem ser reusadas (copiadas ou instanciada) muitas vezes, sendo otimizada e pr-testada antes do uso. Bibliotecas podem ter diferente granularidade: 1. Bibliotecas de baixo nvel oferecem elementos para cada elemento final de controle. Isto inclui, por exemplo, um transmissor de temperatura incluindo scaling, lgica de intertravamento, alarme, manipulao de ponto de ajuste e faceplate. 2. Biblioteca de alto nvel pode oferecer um controle outlet (com sensor, PID e atuador) ou um separador centrfugo completo.

Fig. 3.18. Declarao do Bloco de Funo MY_CMD e suas variveis em forma grfica (esquerda) e forma equivalente textual (direita).

Fig. 3.19. Quatro realizaes equivalentes do Corpo do Bloco de Funo MY_CMD

55

3.3. Unidades funcionais do CPAS


Introduo
O controle automtico de uma planta industrial , primeira vista, muito complexo. Plantas tpicas tm um sistema de controle instalado que compreende vrias centenas e dezenas de milhares de variveis medidas, monitoradas e controladas (pontos i/o). Dependendo do tipo da planta, sinais analgicos e discretos e sinais de entrada e de sada, todos so usados. Tipicamente, h mais sinais discretos (sadas de chave) do que analgicos e h maior quantidade de sinais de entradas do que de sadas, significando oque h maior nmero de malhas abertas do que fechadas de controle a realimentao negativa. Propor uma aplicao de controle funcional para uma planta, bem como um enfoque bem estruturado, inclui satisfazer as seguintes exigncias: Aderncia especificao a aplicao resultante deve satisfazer as especificaes definidas na funo da planta. Em alguns casos, isso implica tambm estar de conformidade com normas e regulamentos e mesmo certificao. Operabilidade a aplicao deve ser opervel, no somente no caso de modo totalmente automtico, mas tambm em qualquer situao da operao da planta, incluindo manuteno, procedimentos de recuperao, calibrao, parametrizao. Mantenabilidade Deve ser possvel manter a aplicao atravs de todo ciclo de vida da planta, que normalmente maior do que qualquer ciclo de vida de software. Projetar a funcionalidade da aplicao em um cdigo de bloco instanciado resultar na estrutura desejada. Quando no desenvolvimento do software para aplicaes IT tradicionais, uma decomposio funcional necessria. No caso de automao, o enfoque apresentado segue a funcionalidade da planta e a hierarquia de controle. Uma definio bem estruturada da funcionalidade da automao um passo chave para se conseguir os objetivos propostos. Em um segundo passo, deve-se tambm olhar alguns aspectos de realizao. Ainda, olhando nas prticas de desenvolvimento de software, deve-se derivar alguns dos conceitos propostos da programao orientada para objeto (grfica). Esta tcnica muito usada e pode ser facilmente aplicada para o desenvolvimento de software de automao.

Projeto de automao
O objetivo de um sistema de automao operar uma planta ou partes de uma planta, de modo automtico. Embora isso parea uma observao acaciana, ela precisa de alguma explicao: Planta Uma planta completa difcil de rodar sempre automaticamente. H sempre processos que esto fora do objetivo da automao (.e.g., fornecimento de matria prima) ou diferentes sees da planta so automatizadas, porm nem toda a planta o . Sistemas diferentes de automao podem ser aplicados no gerenciamento do almoxarifado, produo, expedio, manuteno, utilidades. Estas reas da planta so coordenadas pela interao do operador. Operao Mesmo se uma planta totalmente automatizada, para a maioria de suas partes, seus principais modos operacionais esto rodando automaticamente. Uma planta pode partir e parar automaticamente, ela pode produzir automaticamente, mas cobrir todos os modos possveis de operao pelas funes automticas excede a capacidade de um sistema de automao, por mais completo que ele seja. Situaes anormais no so sempre cobertas, em muitos casos. Se um equipamento deixa de funcionar, a planta ou para ou requer a ateno do operador para completar uma operao ou desliga de modo seguro o equipamento em questo. Automaticamente Em muitas plantas, o operador ainda o responsvel pela operao correta da planta. Alguns conceitos operacionais requerem a liberao manual do operador para o prximo passo de um

56

processo de batelada ou para inicializar operaes baseadas em sua observao ou em procedimentos de operao definidos fora do sistema de automao. Instrues tais como garantir que nenhuma pessoa esteja perto do equipamento quando na partida so frequentemente verificadas pelo pessoal e precisam ser confirmadas para o sistema de automao. Mesmo em uma planta totalmente automatizada, alguma interao manual do operador pode ser requerida, como tomar conhecimento de alarme, passar de automtico para manual, testar lgica do sistema, dar o reset da operao, fazer by pass de proteo na partida. O projeto do sistema de automao precisa considerar todos estes aspectos, permitindo a interao manual com o sistema de automao em diferentes nveis da hierarquia de controle: operao manual, partida de uma funo, desligamento de uma unidade. Como a interao manual sempre carrega o risco do erro humano devem ser tomadas medidas no sistema de automao para evitar interaes perigosas e suportar o operador mesmo em tarefas manuais. Essas condies limites devem ser consideradas quando projetando uma soluo de automao segura e confivel.

Hierarquia de controle
Sistemas de automao so projetados tipicamente de modo hierrquico. (Fig. 3.21). Da interao direta com um equipamento no campo at a operao automtica da planta, uma hierarquia completa de equipamentos, funes de processo e subsistemas ajuda a alocar a funo de automao onde a informao apropriada estiver disponvel. Interao manual A interao manual no equipamento normalmente disponvel em um nvel similar, e.g., painel de operao do equipamento ou no faceplate da varivel de processo ou do equipamento na tela do monitor. Estados de alarme, indicadores de distrbios ou informao detalhada do status (ligado-desligado, bom-ruim, aberto-fechado), tudo isso pode ser lido do display de operao. Trabalhando neste nvel de interao normalmente apenas disponvel para o pessoal de manuteno e no requerido durante a operao normal da planta.

Fig. 3.21. Hierarquia da automao de uma planta

O nvel mais baixo de automao em um sistema controlar um equipamento isolado ou uma malha sozinha. As aplicaes so dominadas por duas famlias de malha: Controle discreto ou binrio um equipamento (bomba, motor) ligado ou desligado ou vlvula liga-desliga (aberta ou fechada).

57

Controle analgico ou contnuo uma varivel de processo controlada para um ponto de ajuste por meio de um equipamento tipicamente analgico que pode estar de modo estvel em qualquer ponto entre 0% a 100%, como vlvula de controle, inversor de frequncia, potencimetro. Alm de fechar a malha, em controle discreto liga-desliga ou em controle contnuo atravs do algoritmo PID, o controle do equipamento pode ter sua funcionalidade estendida como: 1. Sinal de intertravamento evita que o equipamento opere em condies indesejadas 2. Diagnstico detecta o comportamento imprprio do equipamento 3. Interface de operao e alarme representao virtual do equipamento na estao de operao. O controle do equipamento normalmente feito usando bibliotecas padro que fornecem toda a funcionalidade desejada requerida. Estas bibliotecas so normalmente especficas para determinada indstria (leo e gs, petroqumica, papel e celulosa, minerao e siderurgia, alimentos e farmacutica). Se o controle de uma planta deixado para malhas individuais, o nvel de automao fica muito baixo, e planta ainda requer muita interao manual com o operador para partir e parar de modo correto. A coordenao de malhas individuais o principal componente de uma planta totalmente automatizada. Para estruturar a funo global da planta, ela hierarquicamente divida em um nmero de funes que compreendem um nmero limitado de malhas e medies individuais, e executar uma funo de processo especfica. Estas funes so assim coordenadas em um nvel mais alto e podem ser combinadas em funes mais complexas, compreendendo subsistemas, reas da planta e mesmo unidades da planta. A decomposio funcional apropriada do software de automao em funes gerenciveis est no ncleo de cada grande problema de automao.

Projeto funcional
O primeiro passo no projeto a decomposio funcional. Se o processo enfocado olhando o hardware instalado, fica muito fcil identificar sistemas e subsistemas quando o equipamento do processo agrupado junto. Se esses sistemas forem fornecidos separadamente (compressor, bomba, caldeira), esse enfoque conveniente. Esse enfoque realmente requerido quando o controle desse subsistema especfico para ser feito localmente, i.e., perto ou dentro do subsistema. O tamanho de uma seo do processo no importa no primeiro passo; uma decomposio funcional requerida no prximo passo. Se observado nessa decomposio que razovel decomp-la em divises menores, deve-se subdividi-la. Para isso, deve-se: 1. Identificar um sistema de acordo com a estrutura do processo. 2. Identificar claramente todas as interfaces entre o sistema total e o sistema de controle (sensores e atuadores). Cada sinal i/o na planta deve pertencer exatamente a uma seo, subsistema ou sistema. Estes sinais ento se tornam parte desse subsistema. 3. Identificar a funo do sistema de um ponto de vista do processo (fornecer vapor, fornecer energia termal, alimentar de ar o sistema). 4. Identificar a funo do sistema de um ponto de vista de automao. Assim que o escopo das funes tenha sido definido, o prximo passo projetar a funcionalidade do controle. Muitas funes de um processo tm uma interface de controle simples: a funo pode ser ou ligado ou desligado. Estes so os dois nicos estados da funo e ela pode ser chaveada entre eles. Um processo mais complexo no est simplesmente ligado ou desligado, mas pode incluir sequencias de vrios ou at infinitos estados. Entre a partida e parada de um processo h a funo operao. Funes analgicas tm um parmetro adicional em seu estado ligado que controla sua funo: o ponto de ajuste analgico. Essas funes normalmente tm estados ligado e desligado e pode ser partido e parado, mas quando em operao, um valor desejado pode ser estabelecido adicionalmente.

58

Mesmo uma funo com somente dois estados em regime (ligado-desligado, paradorodando) pode ter mais estados internos que precisam ser considerados. Uma funo pode ser trazida de um estado desligado para ligado com procedimentos mais complexos de automao. Haver um transiente partindo para uma grande quantidade de tempo e tambm no estado parando quando sendo desligado. Se o processo for interrompido durante um desses estados transientes, podem acontecer duas coisas: pode ser um estado indefinido, com algum equipamento na posio desligado e outro em ligado ou se um estado indefinido no permitido ou encontra um comportamento inesperado, ele pode desligar, i.e., trazido para um estado seguro de qualquer estado onde estiver. Em muitos exemplos, o estado tripado no idntico ao estado desligado. A funo precisa assim ser trazida para o estado desligado de um modo controlado. Funes com dois ou mais estados em regime so menos frequentemente observadas. A extenso de dois ou mais estados ligeiramente mais complexa: quando h apenas dois estados a funo sempre trazida de um estado inicial para o oposto, em multiestado e dependendo do estado inicial, funes podem requerer diferentes esquemas de automao quando trazidas para o mesmo estado alvo. Quando h apenas dois estados, sistema binrio, o contrrio de aberto fechado e o contrrio de fechado aberto. No processo contnuo, quando o dispositivo pode assumir infinitos estados, o contrrio e aberto no-aberto (e no fechado) e o contrrio de fechado no-fechado (e no aberto). Em controle binrio como no controle analgico, para fechar a malha em qualquer nvel, deve haver realimentao negativa (feedback). Desde que somente a funo em questo pode decidir se est operacional adequadamente, a funo feedback precisa ser criada para qualquer funo que aceita comandos ou pontos de ajuste. Esse feedback reflete o estado da funo com relao a determinados comandos ou pontos de ajuste. A funo feedback assim usada por funes de proximidade ou superviso para detectar se um comando foi executado corretamente. O tpico uso da funo feedback em controle sequencial, onde ares da planta so iniciadas em sequncia definida. A funo seguinte usualmente s pode iniciar quando a funo anterior terminar corretamente sua operao. Alm da informao se uma funo est corretamente partida ou parada, as funes podem fornecer informao acerca dos distrbios. Esta informao fornecida ao operador tipicamente na forma de alarmes. Porm, como as funes de aproximao ou superviso no podem acessar a informao de alarme, tambm fornecida a informao de diagnstico por um sinal de funo feedback. A partida e parada de uma planta so geralmente feitas atravs de vrios passos, com funes de processo partindo to logo a funo anterior estiver corretamente terminada. Em vez de programar manualmente a interdependncia entre as funes, esse procedimento sequencial coordenado por meio da ferramenta de programao da IEC 61 131-3 chamada Sequential Function Chart. Essa ferramenta permite a programao de estados finitos da mquina, onde as transies de estado s podem ocorrer quando as condies de transio forem satisfeitas. Sequncias so usadas tipicamente para partir ou parar uma funo, rea da planta ou planta. A funo controlada tem dois estados, ligado ou desligado, onde o estado transio iniciado por um comando ligado ou desligado feito por meio de um sequenciador. Como a planta pode ser operada em modo manual sob algumas circunstncias (manuteno, recuperao de falha), o estado inicial de uma funo pode no ser conhecido inicialmente. Seus equipamentos podem estar em um conjunto de estados que no esto de conformidade com os estados de ligado ou desligado. Neste caso, uma funo de inicializao pode ser usada para trazer a funo para um estado seguro e definido. Frequentemente, o sequenciar desligado pode ser usado para fazer a inicializao. Se uma funo tem vrios estados estveis, a funo apropriada de automao pode ser realizada com um sequenciador por transio de estado permitida. Um sequenciador em si pode ser operado manualmente.

59

Tab. 3.3. Troca de informao

Variaes funcionais e reuso


Um aspecto importante de uma decomposio funcional hierrquica projetada conseguir robustez contra mudanas e aumentar a possibilidade de reuso dos componentes de software. Reuso possvel em diferentes nveis e pode significar a cpia pura de uma verso anterior, cdigo de funo encapsulada, usando templates, etc. Reuso pode significar usar uma pea de software de um projeto anterior ou em um diferente contexto. Pode-se ter vrios escopos de reuso: Procedimentos padro funes que so usadas em numerosos locais independente dos processo ou funo relativa. Eles so limitados em complexidade, mas mais largos em aplicabilidade. Essas funes so tipicamente mantidas como bibliotecas. Em muitos casos, eles so comuns dentro de uma indstria. Variantes funcionalidade que pode ser disponvel como variantes diferentes. Mdulos com a mesma funcionalidade, mas com internos diferentes, podem ser trocados ou diferentes realizaes da mesma funo de processo (e.g., hidrulica ou eltrica) podem ser escolhida em um projeto. O beneficio do reuso nesse caso vem com a estabilidade da aplicao includa, que permanece inalterada para qualquer variante usado. Unidades e subsistemas funcionais funes so comuns em diferentes tipos de plantas, e.g., compressor de certo tipo, bomba, digestor, moinho, coluna de destilao. O reuso potencial de um componente reusvel coberto por uma norma. Cobertura quanto o projeto coberto por um mdulo padro. Frequncia do reuso quantas vezes um mdulo padro pode ser usado. Alta cobertura usualmente significa uma frequncia de reuso mais baixa desde que a probabilidade mais alta que um projeto atual difere em algum detalhe do mdulo padro e precisa de algumas modificaes. Por outro lado, o maior benefcio conseguir com uma alta cobertura e uma alta frequncia de reuso. Como isso raramente possvel, a determinao do tamanho do mdulo critica para o sucesso do enfoque modular. Gerenciamento da Mudana geralmente uma das tarefas mais desafiadoras no projeto de automao. Mudanas na documentao de entrada quando ocorre o desenvolvimento da planta e mudanas no projeto da planta tem um efeito imediato no sistema de automao.

60

Olhando alm de um projeto em uma srie global de instalaes, em muitas indstrias o projeto da planta permanece similar, mas adaptado para exigncias especficas de um determinado servio. Isso pode significar que algumas funes podem ser realizadas de modo diferentes enquanto mantendo a mesma estrutura global. Um dos desafios chave para uma aplicao de automao com relao s modificaes da planta rastrear a influncia da mudana e assim adaptar todos os componentes para acomodar a funcionalmente mudada. A decomposio funcional adequada e a encapsulao uma tcnica chave aplicada para reduzir o impacto de uma modificao. SE outras funes no se baseiam em sinais internos ou variveis de um subsistema, mas na informao fornecida pela funo de um subsistema encapsulado, a mudana pode ser bem tambm encapsulada. Desde que outras partes do software somente se baseiam em um pedao de informao que foi derivada de medies, o efeito de uma mudana pode ser mantido local criando novamente esse pedao de informao no contexto da funo mudada. Mudando a realizao da funo no processo no tem um efeito na automao do subsistema em questo, mas fechando a funcionalidade do sistema de automao permanece inalterada. Combinando um conjunto de funes encapsuladas previamente definidas em uma aplicao de projeto ajuda o engenheiro focar no trabalho de integrao e no nos detalhes da funo do objeto. O nvel de abstrao da tarefa feita pela engenharia pode ser aumentado concentrando no aspecto de engenharia da integrao do sistema e no no nvel de programao da aplicao. Os dois enfoques, manter constante a estrutura da planta variando a realizao de uma seo do processo ou combinar funes predefinidas para formar uma aplicao especfica de processo, se baseiam pesadamente em um componente chave da realizao funcional do sistema de automao: interfaces estveis. Se as interfaces entre funes so definidas cedo no projeto ou pode mesmo ser padronizada completamente a traves de uma famlia de tipos de planta, variaes no projeto podem mais facilmente ser alocadas, testadas no contexto requerido e comissionadas. Quanto projetando as interfaces de operao (runtime) de uma funo, as exigncias da informao definem o esquema do que uma funo precisa conhecer acerca de seu controle. Complementar a isso, necessrio definir que informao acerca de uma funo requerida por seu ambiente. Uma boa classificao da informao trocada por uma funo e seu ambiente mostrada na Tab. 3.3. A informao trocada entre duas funes deve refletir o nvel de abstrao neste contexto funcional e no assumir o comportamento interno de uma das funes. Alm da informao dinmica que um objeto requer para suas tarefas de automao, ele pode tambm necessitar alguma informao esttica que seja disponvel na engenharia ou somente no estagio de configurao. Essa informao pode ser dada na forma de parmetros que podem somente ser mudados atravs de ferramenta de engenharia e no necessariamente fornecidos continuamente na operao (runtime). Exemplos para ajuste de parmetros durante a configurao do objeto so: parmetros do ganho do controlador, constantes da planta, faixas de medio. Ver Fig. 3.23. Esses parmetros so normalmente estabelecidos no estgio de engenharia e somente mudados durante comissionamento ou manuteno. Similar aos parmetros que so estabelecidos apenas em instncias especficas por especialistas, um objeto pode fornecer informao de diagnstico para o pessoal de manuteno. E aqui no requerido que essa informao seja continuamente transmitida atravs de todo sistema. Ela pode ser acessada somente em caso de mau funcionamento ou para remover erros do mdulo defeituoso.

61

Tab. 3.3. Troca de informao

De uma perspectiva funcional, qualquer coisa que evita uma funo de ser executada corretamente classificada como distrbio. O mais simples monitoramento de distrbio assim comum a todas as funes: um comando para atingir certo estado que foi recebido, mas a funo no chega ao estado desejado dentro de um tempo razovel. Todas as funes requerem comandos de entrada que disparam transies de estado, bem como sinais de realimentao de estado que indicam se o estado foi alcanado, essa funo supervisria genrica pode sempre ser acrescentada. Anlise mais detalhada da funo em falha pode necessitar de ser realizada, dependendo da funcionalidade desejada.

Fig. 3.23. Interfaces de funo

62

Um caso especial de sinais de diagnstico as variveis que so usadas como alarme. Essas variveis tm uma faixa de operao normal e um estado de alarme, i.e., se a varivel excede os ajustes limites de alarme (ou em caso de varivel binaria, chaves do estado normal para o estado de alarme), um alarme aparece e mostrado na estao de operao a ser investigado e reconhecido. Dependendo da filosofia de alarme, pode ser desejvel para a funo levantar um sumario de alarme no estado funo, que permite operador ento penetrar na lista de alarme para esta funo especfica para diagnosticar a razo da falha da funo.

Funcionalidade
A funcionalidade de um mdulo define como ele manipula suas estruturas subordinadas de automao ou sua seo do processo. A funcionalidade do mdulo desenvolvida baseada no comportamento desejado do processo controlado. A principal funcionalidade define o comportamento do mdulo, assumindo que todos os equipamentos do processo esto trabalhando corretamente. Cada uma das funes fornecidas deve estar disponvel para um comando externo e cada funo deve retornar um valor de status quando e se a funo estiver completada corretamente. Em muitos casos, a decomposio funcional de uma planta resulta em uma funo por mdulo (frio, quente, alimentao de ar, etc.). Ela fornece assim os comandos para chavear esta funo em ON ou OFF e retorna os sinais de feedback correspondentes. Sistemas de automao mais avanados no somente manipulam operaes normais, mas tambm fornecem um meio para evitar que os distrbios desliguem o processo automaticamente. A aplicao tpica desliga a funo de um modo seguro. Outras funes de manipulao de distrbio so equipamentos de falha segura at redundante ou chaveando para uma funo de backup. Manipular distrbios no cdigo automao normalmente mais complexo do que funo no disturbada e muitas vezes feito por falhas mais crticas ou previsveis. Alm da operao normal e manipulao de distrbio, pode ser razovel acrescentar comissionamento ou suporte de teste para uma funo processo. Muito frequentemente, comissionamento assumido estar trabalhando, ou diretamente interagindo com as variveis de processo ou manualmente controle equipamentos individuais ou forando variveis do controlador usando a funo comissionamento da ferramenta de engenharia. Isso pode resultar em situaes perigosas, desde que intertravamentos de segurana podem deixar de funcionar desse modo. Um modo mais seguro fornecer funcionalidade especfica que suporte comissionamento da planta. Se o comissionamento requer ferramentas bem definidas para sintonizar controladores ou estabelecer pontos de ajuste, essas ferramentas podem ser fornecidas em cdigo de comissionamento adicional que pode ser acessado da estao de operao e no da ferramenta de engenharia. Para reduzir a carga do controlador durante a operao normal, o cdigo de comissionamento pode ser removido da aplicao quando a planta estiver operacional ou ele pode ser desabilitado. Para remover adequadamente o cdigo, encapsulao e modularizao so essenciais para no danificar o resto da aplicao nessa operao.

63

Exemplo: tanque de lquido aquecido aplicao dos conceitos


Para operar, um processo requer um lquido a uma determinada temperatura. Este lquido aquecido em um tanque. O tanque possui os seguintes componentes: Tanque, com indicadores de nvel baixo, normal e alto. Aquecedor, que esquenta o lquido do tanque. Ele est localizado abaixo do indicador de baixo, i.e., o aquecedor no deve estar abaixo desse limite. Bomba, que alimenta o tanque com lquido frio. Vlvula de dreno, que esvazia o tanque completamente quando aberta. Tubulao para o processo onde o lquido quente consumido. O uso do liquido controlado pelo processo de consumo. Esse processo chamado de tanque com lquido aquecido.

Fig. 3.20. Sistema de tanque de lquido aquecido Ambiente do processo Considerando o ambiente do processo, o tanque recebe lquido do tanque de lquido frio. O excesso de lquido realimentao ao tanque de lquido frio. O lquido aquecido fornecido ao processo consumidor atravs de uma vlvula de controle. Decomposio funcional O primeiro passo na decomposio funcional do definir a funo de cada equipamento em questo. A funo global do sistema completo fornecer lquido aquecido para o processo consumidor, qualquer que ele seja. A funo do subsistema tanque ento definida como fornecer lquido quente ao processo consumidor. A funo global produzir produto acabado , portanto dividida em trs funes: 1. Fornecer lquido frio para o tanque de lquido aquecido 64

2. Fornecer lquido quente para o processo consumidor 3. Produto do processo Um diagrama funcional pode assim parecer com o mostrado na Fig. 3.24. Ainda faltam as interfaces entre as funes.

Fig. 3.24. Diagrama funcional do tanque

Encapsulamento do estado O primeiro passo definir os estados internos da funo. A frase definindo a funo: fornecer lquido aquecido pode ter apenas dois estados: 1. Sim a funo fornece lquido aquecido 2. No a funo no fornece lquido aquecido. Esses dois estados podem ser assumidos a corresponder a um estado ligado e um estado desligado da funo. Interfaces Para definir as interfaces, seguir a classificao como descrito na Tab. 3.4.

Tab. 3.4. Definio de interface para a funo tanque de lquido aquecido

65

Alocao de equipamento Agora se deve fazer a correspondncia entre equipamentos e funes. Para fornecer a funcionalidade desejada, a funo fornecer lquido aquecido precisa ser capaz de: 1. Controlar o nvel do lquido no tanque. Assim, a bomba de alimentao, a vlvula de dreno e a medio de nvel precisam ser parte da funo. 2. Aquecer o lquido. O aquecedor assim precisa ser parte da funo. Agora, deve-se atribuir a vlvula de controle para a funo produto do processo, pois ela pode controlar o nvel dentro de sua prpria funcionalidade sem trocar informao com qualquer outra funo. Realizao da funo Depois de definir as interfaces e alocar os equipamentos para a funo, toda informao disponvel para realmente projetar a funo, i.e., o controlador que mantem o nvel e a temperatura dentro da constante tanque de lquido aquecido. Como h apenas trs variveis binarias que indicam o nvel do tanque, o controle de nvel fica simples. Um controlador de dois estgios mais fcil de realizar, ligando a bomba quando o nvel estiver baixo e desligando a bomba quando o nvel estiver alto. O aquecedor pode ser ligado assim que houver lquido suficiente no tanque (nvel mnimo atingido) e ele precisa ser desligado se o nvel do tanque ficar abaixo do limite mnimo por algum tempo. Variaes funcionais A informao se o lquido quente disponvel para o processo consumidor no deve afetar o nvel do tanque diretamente. Em vez disso, a funo tanque deve fornecer o sinal lquido quente disponvel (que composto do nvel do tanque e a medio de temperatura). No caso onde no houver tanque, mas apenas um aquecedor de vazo contnuo, o sinal lquido quente disponvel ainda vivel, mas no em forma de nvel de lquido; em vez disso talvez derivado de uma medio de vazo. A funo do processo consumidor, portanto no precisa ser mudada quando a funo alimentao modificada e os dois variantes fornecem a mesma informao mas no a mesma varivel.

Concluses
Reusar funes de automao difcil, mesmo no incio de um projeto. As exigncias do projeto so satisfeitas de modo to eficiente quanto possvel, enquanto o reuso deixado para o pessoal trabalho no prximo projeto. Se eles puderem facilmente usar o que foi feito anteriormente, melhor ser. Assim, introduzir o enfoque de unidade funcional possibilita a capacidade de reuso no software de automao desde o incio. O enfoque estruturado favorece a reusabilidade da soluo de engenharia e tambm torna a soluo mais estvel dentro do projeto. A aplicao se torna menos sensvel s alteraes posteriores na rea do processo e mais fcil fazer os testes e o comissionamento. Mais ainda, se a metodologia introduzida na organizao, as aplicaes sero mais fceis de manter, desde que elas seguem um esquema de projeto comum. Uma vez introduzida, uma organizao pode comear construindo bibliotecas de solues de automao que reduzam o esforo de engenharia em novas aplicaes. Se essas bibliotecas estiverem realimentando experincias de plantas, pode-se conseguir um aumento contnuo na qualidade.

66

4.1. Alarmes e eventos


Introduo
A interpretao intuitiva da apalavra alarme requer ateno. Infelizmente, em muitas plantas atuais a situao muito diferente, com milhares de alarmes gerados diariamente, muitos deles no tendo nenhum valor til para os operadores. Em automao de processo, os termos alarme e evento no so totalmente definidos. A especificao da Fundao OPC para Alarme e Evento (OPC AE) a norma mais comumente usada para comunicar alarmes e eventos entre diferentes mdulos. OPC AE define um alarme como um caso especial de uma condio em que se pensa que anormal e requer ao especial do operador. Alarmes precisam ser reconhecidos pelo operador. reas de interesse incluem limites de segurana do equipamento, deteco de evento e situaes anormais. Alm dos operadores, outras aplicaes de cliente podem coletar e registrar alar e evento para auditoria ou comparao subsequentes com outros dados histricos (especificao OPC AE 1.1) OPC AE define evento como uma ocorrncia importante detectvel que pode estar ou no associada com uma condio e no requer a ao do operador. Eventos no podem ser reconhecidos pelo operador. Um evento um ponto singular no tempo enquanto um alarme tem um inicio e um fio (geralmente chamado de retorno ao normal, RTN return to normal). Eventos tpicos que podem ser associados com um alarme so: incio, conhecimento e fim do alarme (Fig. 4.1). Recomendaes como EEMUA (Engineering Equipment & Materials Users Association) enfatizam o fato que a habilidade do humano processar mensagens limitada. Deste ponto de vista, um alarme tudo que trazido para a ateno do operador, seja uma entrada em uma lista, um som de sirene em uma sala de controle ou uma alterao de cor no display grfico e requer ao do operador no processo para restaurar a condio normal.

Fig. 4.1. Diagrama de estado mostrando transies entre estados de alarme

A Fig. 4.2 mostra as camadas tpicas envolvidas com alarmes. A fonte de alarme mais comum so os blocos de funo em cdigo de aplicao rodando em controladores de automao. OPC AE define trs tipos diferentes de eventos: 1. Eventos relacionados com condio (tipicamente associados com alarmes) representam transies de estado. Um exemplo um valor de presso excedendo um determinado limite. O alarme ativado quando o limite excedido e retorna ao normal quando a presso cai novamente abaixo do limite

67

2. Eventos relacionados com rastreamento podem representar pontos singulares no tempo. Um exemplo a mensagem que um operador recebe quando abre ou fecha uma vlvula. 3. Eventos simples representam tudo o mais.

Fontes de alarme e evento


Fontes tpicas de alarme e evento em um CPAS so: Controladores de automao (.e.g., temperatura muito alta) Unidades de hardware como transmissores de campo Aplicaes de software como equipamento supervisionando monitores de ativos O sistema em si (disco cheio, servio indisponvel, etc.) Alarmes do processo (como temperatura muito alta) so executados um nvel acima dos controladores de automao. Existem duas motivaes: o O controlador de automao pode no ter suficiente recurso (processamento) para realizar a lgica do alarme ou no oferece a funcionalidade de alarme em si. o A separao da lgica de controle e lgica do alarme pode resultar em uma lgica de alarme mais transparente, seno o operador deveria ser forado a descer para a lgica do processo para entender os detalhes da lgica de alarme. Usualmente a interface para todas essas diferentes fontes o OPC AE. Uma grande planta tem vrios servidores OPC AE diferentes de diferentes fabricantes com diferentes filosofias. uma tarefa do CPAS harmonizar as fontes heterogneas de alarme e garantir que cada alarme est direcionado para os recipientes que precisam conhecer os alarmes. Alarmes de processo so geralmente gerados em controladores de automao. Tipicamente as variveis de processo como presso, temperatura, nvel e vazo so comparadas com pontos de ajuste (limites) de alto ou baixo. Assim que um limite tem sido excedido um alarme gerado. Para uma nica varivel de processo vrios alarmes podem ser configurados, tais como baixo (L), muito baixo (LL), muitssimo baixo (LLL), alto (H), muito alto (HH) e muitssimo alto (HHH). Tipicamente, tem-se H e L para alarme, HH e LL para intertravamento e LLL e HHH para intertravamento de nvel de abandono do local. Na Fig. 4.2, o parmetro FilterTime determinar por quanto tempo o sinal deve desviar antes que haja uma alterao, porque seno cada pequeno desvio iria causar novo alarme (glitching). Por isso os filtros devem ser configurados corretamente. associado a intertravamento

Fig. 4.2. Arquitetura do sistema de alarme

68

Indicadores de alarme
Historicamente, os alarmes eram indicados em painis anunciadores especiais. CPAS modernos oferecem vrios indicadores de alarme baseados em software, mas a habilidade de usar hardware especial como impressoras, buzinas e lmpadas continua importante. Indicadores de alarme incluem: Listas de alarme e eventos Bandas de alarme, que sumariza uma lista de alarme e fornece um link para o display correspondente da lista de alarme. O nmero de uma banda de alarme representa o nmero de alarmes atualmente no reconhecidos na lista correspondente. A cor da banda de alarme mostra a mais alta prioridade do alarme ativo no momento. Barras de sequncia de alarme um display do status, onde os alarmes mais recentes so mostrados horizontalmente da direita para a esquerda na ordem se sua ocorrncia. A barra de sequncia de alarme permite chamar o menu de contexto para o alarme, conhecimento do alarme e vista de detalhes adicionais. Indicadores de alarme em elementos de display Displays de alarme dedicado espacial o antigo painel anunciador de alarme tinha a vantagem de um alarme sempre aparecia no mesmo local e a dedicao espacial suporta referncia de ateno. Em sistemas modernos com monitores, a dedicao espacial perdida. Assim, importante fornecer um display panormico (e.g., uma grande tela) que contenha indicadores continuamente visveis dedicados espacialmente para os alarmes mais importantes. Impressora de alarme o modo tradicional de relacionar em lista os alarmes era imprimindo os alarmes em papel, em uma impressora matricial. Em algumas salas de controle o rudo gerado pela impressora matricial era uma indicao de como o processo estava operando: bem ou mal. As desvantagens da impressora de alarme so: 1. Requer um suprimento constante de papel e tinta 2. As (grandes) pilhas de papel devem ser arquivadas e recuperadas quando necessrio 3. Impressoras requerem manuteno e monitorao. Por causa dessas desvantagens, a impressora est sendo substituda por base de dados. Historiados de alarme so usualmente parte do mdulo do Gerenciamento da Informao. Alarmes e eventos so armazenados em uma base de dados e podem ser recuperados para todos os tipos de relatrios. Historiador de alarme a base para uma anlise detalhada de alarme. Alarmes audveis e externos Alarmes ativos no reconhecidos podem gerar um som na estao de operao local (e.g., tocar um arquivo mp3). Tais alarmes podem ser configurados para serem silenciados isolados na estao de operao local ou globalmente de todas as estaes. Se so usadas buzinas ou lmpadas para indicar o alarme, isso pode ser feito com funo de alarme externa, que direciona o sinal de alarme para pontos i/o especialmente configurados. E-mail informao de alarme detalhada enviada para endereo configurvel de e-mail. Tipicamente e-mail usado para tarefas relacionadas com manuteno que no requerem uma resposta imediata. Por exemplo, um e-mail pode ser usado para notificar um centro de servio externo que um equipamento necessita de inspeo mais detalhada. E-mail pode ser tambm usado para iniciar workflow, e.g., insere tarefas em listas de tarefas (ToDo). Notificao a sistemas externos, por exemplo, Sistema de Gerenciamento de Manuteno Computadorizado (CMMS) como uma base de seu trabalho de manuteno. Nenhuma manuteno, seja inspeo, reparo ou reconfigurao, pode ser feita sem uma ordem de servio no CMMS. Assim, alarmes relacionados com manuteno requerendo uma ao de manuteno podem automaticamente criar uma ordem de servio no CMMS para iniciar um workflow correspondente.

Interagindo com alarmes


O workflow padro com alarmes pode ser explicado com a ajuda do seguinte exemplo:

69

1. Ativao - Por exemplo, o nvel de um tubulo de caldeira sobe acima de um limite de alarme. Se nenhuma ao for tomada, o lquido pode extravasar. 2. Conhecimento - O operador ou a operadora sinaliza que ele ou ela tomou conhecimento do alarme e tomou a responsabilidade de resolver o problema. O conhecimento do alarme torna-se imediatamente visvel em todas as estaes de operao onde ele apareceu e foi mostrado. Geralmente alarme no reconhecido fica piscando. 3. Operador resolve o problema - O operador ou a operadora poderia acionar o faceplate de uma vlvula para abri-la ou fecha-la ou poderia se comunicar com operador de campo para atuar manualmente na vlvula. Se a razo do alarme no clara, o operador deve antes diagnosticar o problema. s vezes, o operador no consegue resolver o problema, mas precisa encaminhar o problema para o pessoal de manuteno. 4. Retorno ao normal - O nvel cai abaixo do limite de alarme e o alarme desativado. Se o alarme relacionado com segurana (e.g., se o lquido explosivo), um limite de segurana do SIS precisa ser feito automaticamente para garantir que o nvel da caldeira nunca atingir o nvel muito alto, se necessrio desligando automaticamente a planta. Uma planta no pode ser projetada de modo que a segurana se baseia apenas na reao correta do operador a um alarme relativo segurana (IEC 61 508 e IEC 61 511). Menu de contexto Quando um alarme aparece em uma lista de alarmes, as questes que aparecem so: 1. Por que este alarme foi ativado? 2. O que o display de tendncia relacionado mostra? 3. Problemas similares j ocorreram no passado? 4. Quando foi feita a ltima manuteno neste instrumento ou equipamento? 5. Onde se pode encontrar documentao para entender o problema e o equipamento melhor? 6. Que faceplate na tela deve ser usada para resolver o problema? Um CPAS precisa tornar estas informaes disponveis apenas pelo simples click no alarme e ativando o menu de contexto. Desistncia (shelving) s vezes alarmes chamam a ateno odo operador ativando a buzina e adicionando vrias entradas para a lista de alarme, que podem no ter nenhum sentido na situao corrente, e.g., porque o equipamento est atualmente em manuteno ou porque o equipamento sabido estar em falha, mas no pode ser reparo imediatamente. A facilidade de desistncia de um alarme permite o operador tirar o alarme, que significa colocar o alarme temporariamente fora. Os alarmes desativados temporariamente devem ser revistos periodicamente para garantir que eles no foram esquecidos. O CPAS deve suportar um gerenciamento sistemtico de alterao de alarmes desativados temporariamente fornecendo lembretes peridicos e mecanismos de aprovao. Desativamento (disable) Desativar um alarme significa desligar o alarme. Isto pode fazer sentido, porque s vezes os alarmes no tm nenhum valor para os operadores. Por exemplo, um equipamento defeituoso pode gerar milhares de alarmes por dia, mas no pode ser substitudo at a prxima parada programada de manuteno, que ocorrer daqui a alguns meses. muito importante que o alarme seja reativado, quando o equipamento for substitudo. Muitas vezes o valor do alarme muda ao longo do tempo, e.g., quando partes adicionais do processo so ativadas ou se o processo est operando de modo diferente. Outro problema que alguns alarmes no sistema poderiam ser muito bem engenheirados, com muitas razes atrs deles, enquanto outros alarmes so configurados apenas como default.

70

importante ter uma boa e confivel documentao disponvel mostrando as razes atrs de cada alarme configurado e um sistema de gerenciamento de alterao adequado. Em alguns CPAS, alarmes desativados so ainda gerados e disponveis para listagem, enquanto em outros, os alarmes so tratados como no existentes. Desistir e desativar alarmes so tarefas que devem ser feitas apenas por pessoal autorizado e com o conhecimento suficiente requerido. Comentrios A facilidade do comentrio permite o operador anexar comentrios aos alarmes. Esses comentrios so disponveis sempre que o alarme estiver ativo e pode ser listado no historiador de alarme. Posteriormente, todos os comentrios anexados a um alarme podem ser recuperados e poderiam ajudar a diagnosticar o problema atual. Comentrios de alarme tambm ajudar a construir o conhecimento explicito acerta do que est acontecendo na planta e so uma base importante para a competncia e melhoria contnua do operador.

Caractersticas do sistema de alarme


Escondido Alarmes escondidos tm uma visibilidade reduzida. Eles no chamam a ateno do operador em primeiro lugar, mas alarmes escondidos ainda so disponveis se explicitamente requerido. Para um diagnstico detalhado e profundo, o operador pode ver todos os alarmes, incluindo os escondidos. Alarme escondido realizado de modo transparente na camada de alarme do sistema acima do controlador. As regras tpicas para esconder o alarme so: Se A estiver ativo, no mostrar B ou C Se estado = partida, no mostrar D, E, F, G. A lista de alarme pode ser configurada para excluir alarmes escondidos. Pelo click no boto, os alarmes escondidos podem ser de novo includos. Fig. 4.4 mostra como os alarmes desabilitados, escondidos e removidos cooperam na tarefa correta de fazer alarme.

Fig. 4.4. Remoo dos alarmes em diferentes estgios

Filtro CPAS modernos oferecem mecanismos de filtro poderosos. Alguns SDCD antigos tinham apenas uma nica lista de alarme mostrando todos os alarmes no sistema. As mais altas taxas de alarmes e a crescente capacidade de diagnstico dos sistemas modernos fazem tal enfoque

71

impraticvel. Um CPAS permite configurar listas especficas de alarme para objetivos especiais. Os mais importantes critrios para filtro incluem: Grupo alvo (operao, manuteno, sistema) Prioridade (urgncia e importncia). Alarmes durante os distrbios do processo podem requerer diferentes focos do operador daqueles alarmes durante operao normal e suave. Alarmes usados para sintonia fina e otimizao do processo no fazem sentido durante os distrbios do processo, quando importante focalizar primeiro os assuntos mais importantes. rea do processo. Muitas vezes diferentes operadores so responsveis por diferentes reas do processo. Seu foco principal os alarmes para essas reas, mas alarmes de outras reas poderiam ser relevantes tambm se as houver relaes causais com estas reas. Muitas outras listas de alarme de objetivo especial, baseadas em atributos especficos do vendedor. Prioridades Cada alarme deve ter um valor de prioridade atribudo, que indica sua urgncia e importncia. Prioridades bem estabelecidas pela engenharia ajudam os operadores focalizarem nos assuntos mais importantes primeiro. Em muitas plantas existentes, as prioridades de alarmes no so bem atribudas ou no so usadas simplesmente. Em tais casos, deixado para o operador decidir se um alarme importante ou no. Usualmente, os valores de prioridade so mapeados para diferentes cores. Em muitos casos a prioridade atribuda a um alarme esttica, embora seja teoricamente possvel calcular valores de prioridade dependente da situao. A norma OPC AE usa o termo severidade como sinnimo e permite o uso de valores de prioridade entre 1 e 1000. Isto infeliz, pois muitos humanos no podem distinguir entre tantos nveis de prioridade. A recomendao EEMUA 191 recomenda o uso de somente trs diferentes prioridades: alta, mdia e baixa. Prioridade crtica pode ser atribuda a alguns poucos alarmes como uma exceo.

Tab. 4.1. Exemplo de mapeamento de prioridade Severidade OPC 800 1000 600 800 < 600 Severidade OPC Alta Mdia Baixa Prioridade passada 1 2 3 900 700 500 Prioridade mapeada

Prioridades de alarme so definidas na fonte e por isso nem sempre possvel garantir uma consistncia. Por exemplo, uma parte do sistema poderia usar as prioridades 1, 2 e 3 para alto, mdio e baixo, enquanto outra parte do sistema poderia ter outro mapeamento (Ver Tab. 4.1). Tais inconsistncias so confusas e at perigosas. Um CPAS que integra alarmes vindo de diferentes partes do sistema deve ser capaz de harmonizar a atribuio de prioridade. No exemplo da tabela, o CPAS poderia remapear as prioridades 1, 2 e 3 para as prioridades 900, 700 e 500. As prioridades devem ser definidas a priori durante a engenharia da planta para indicar que alarmes so mais urgentes e importantes que outros. Usualmente, h uma tendncia de atribuir prioridade mais elevada que a necessria, exagerando o nmero de alarmes de alta prioridade. EEMUA 191 recomenda para uma distribuio de 5% alta, 15% mdio e 80% de baixa prioridade. Tal distribuio permite os operadores ficarem relaxados para a maioria dos alarmes. Se um dos (raros) alarmes de alta prioridade ocorrer, os operadores devem devotar sua ateno plena para o alarme. 72

Uma atribuio de prioridade correta requer muito conhecimento de vrios assuntos multidisciplinares. No fcil e muito demorado e requer muita discusso atribuir prioridades aos alarmes. Quando no feito esse necessrio trabalho de engenharia de atribuir urgncia e importncia aos alarmes, essa tarefa deixada para o operador decidir, s vezes, sem experincia e conhecimento prvio. uma questo bsica do ARC CPAS que os operadores devem ter suporte para tomar decises consistentes e deve-se fornecer aos operadores uma atribuio de prioridade de alarme bem fundamentada na engenharia. Os valores de prioridade de alarme devem ser sistematicamente atribudos, baseando-se em: custo para a segurana, impacto ambiental e dano ao equipamento. O ponto chave que a atribuio feita sistematicamente a partir do ponto de vista do operador e que a distribuio de prioridade resultante calculada.

Fig. 4.1. Atribuio de prioridades conforme EEMUA 191

Atributos especficos do vendedor No passado, os alarmes possuam poucos atributos fixados, tais como tempo estampado, nome do tag e mensagem. A quantidade de informao era limitada pelo equipamento tpico de sada, que inclua telas com 80 caracteres ou linhas de impresso com 120 caracteres. A informao era suficiente para uma anlise post mortem tpica: o que, quando e em que sequncia aconteceu? A especificao OPC AE define vrios atributos padro, mas permite que os servidores OPC AE possam definir os chamados atributos especficos do vendedor, onde informao adicional pode ser anexada aos alarmes. Por exemplo, um atributo AREAS poderia conter strings com os normas de todas as reas que o alarme pertence. Atributos especficos do vendedor podem ser armazenados em databases e permitir anlise mais avanada de alarmes passados. Categorias Categorias definem agrupamentos de alarmes e eventos suportados poro um servidor OPC AE. A Foundation OPC sugere usar as seguintes categorias: Nvel, Desvio, Discreto, Estatstico, Falha de Sistema, Falha de Equipamento, Status de Batelada, Mensagem do Sistema, Mudana de Processo, Configurao de Sistema, Controle Avanado, Comunicao. Mas, para cada servidor OPC AE definir suas prprias categorias, Categorias so usadas para agrupar e filtrar alarmes e eventos. Elas so a ferramenta mais comum para separar alarmes de diferentes grupos de usurio, para dirigir alarmes para operadores e pessoal de manuteno.

73

6.1. Operao eficiente


Introduo
estimado que a indstria de processo mundial perde US$20 bilhes ou 5% de sua produo anual, devido a paradas no programadas e produto fora de especificao. ARC estima que quase 80% dessas perdas so evitveis e 40% so principalmente resultado de erro de operao. Hoje a maioria dos processos automatizada. Usualmente uma planta pode operar com uma frao do nvel de pessoal requerido h 30 anos atrs. Mas em muitos casos, vises de plantas totalmente automatizadas que podem ser operadas completamente sem humanos no se tornou verdade. Pessoal bem treinado e competente continua sendo uma condio necessria para o sucesso da operao do processo e melhoria da automao . Por exemplo, uma aeronave moderna poderia voar 100% automaticamente, mas muitos passageiros hesitariam em voar sem um piloto a bordo. (J ficam receosos quando o piloto pilota). A aterrisagem de emergncia de um avio com as duas turbinas quebradas no Rio Hudson em 2009 (que deixou de ser aterrisagem por ter sido na gua) um exemplo de como o operador humano pode resolver situaes que no podem ser tratadas pela automao. No caso de corrida de Frmula 1, claro que somente o melhor sistema global humano-mquina (combinao de pessoal, carro e piloto) ir ganhar a corrida. Razes tpicas para a importncia do operador incluem: 1. A habilidade de supervisionar processo e automao e manipular situaes imprevistas pelos projetistas do sistema de automao. A capacidade criativa do operador humano e a habilidade para tratar situaes mal definidas ou novas tornam o operador humano insubstituvel. 2. A habilidade de identificar problemas que esto comeando to cedo quanto possvel e resolver esses problemas antes que eles provoquem risco. 3. A habilidade de iniciar e organizar atividades de manuteno. Embora a manuteno seja tradicionalmente feita por outro pessoal, h uma tendncia existente de integrar as atividades de operao e manuteno. 4. A capacidade de manipular tarefas que no podem ser efetivamente automatizada por causa de custo. Este tipicamente um ponto de vista de engenharia. Um sistema que fornece tanto automao quanto possvel, deixando apenas o resto para o operador humano, provavelmente no ir usar o potencial pleno do operador humano. Operador humano em sistemas de automao industrial altamente complexo contnua a ter uma funo central e essencial entender e maximizar a colaborao entre o sistema de controle e o operador humano. Adotar um enfoque de projeto sistemtico importante por razes de segurana e desempenho timo do sistema. Em um projeto de automao o investimento nas estaes de operao da sala de controle, engenharia de display e alarme, interfaces com operador, telas, etc., significativo e deve se atribuir igual importncia aos investimentos em lgica de controle (alarme e intertravamento, algoritmos, sequncias). A maioria das plantas atuais altamente automatizada e o trabalho do operador supervisionar o processo e seu controle e sua automao. No h um nico termo bem estabelecido identificando a interface entre o CPAS e o operador. O termo inicial foi interface Homem-Mquina. Hoje se fala em Interface/Interao Humano-Computador. O controle de processo possui exigncias especficas e algumas partes da interao poderiam no ser com o computador, mas com o processo (sensores, vlvulas, atuadores). Por exemplo, um operador poderia chamar outro operador e pedir para ele (ou ela) fechar uma vlvula manualmente. Realimentao como rudo, vibraes, cheiros ou vises podem ser uma base importante para decises, mas poderiam no estar disponveis do computador. Muitos processos tm dinmica inerente complexa geralmente ditando as aes e reaes dos operadores. No existe um boto de voltar atrs (undo) para abrir uma vlvula. Outros termos que descrevem a interao especfica entre operador, CPAS e processo mais precisamente so Interface Humano-Mquina (IHM), Interface Humano-Sistema (HSI), Interface 74

Homem-Mquina (MMI). O preferido seria Interface Humano-Sistema, pois enfatiza o fato que a interao pode incluir vrios humanos (homens e mulheres), mquinas, computadores, processo e sistemas. Nos tempos antigos de baixos nveis de automao, operadores eram diretamente envolvidos com a fsica da planta. Por exemplo, quando eles abriam manualmente uma grande vlvula eles poderiam diretamente sentir as grandes foras envolvidas. Em uma planta altamente automatizada, a operao muito mais abstrata e virtual e no caso de operao remota, as operaes so completamente separadas do processo em si. Nestas circunstncias, o controle de processo se torna um vdeo game. Clicar em um pequeno cone na tela poderia ter consequncias severas no processo. Essa perda do contato direto com o processo precisa ser cuidadosamente balanceada por treinamento sistemtico.

Fig. 6.1. Processo tpico controlado pela Automao e supervisionado pelo Operador humano

Alguns operadores tm at medo de interagir com o processo, porque eles sabem que suas aes podem ter grandes consequncias financeiras ou mesmo impactar a segurana do processo. Uma parada no programada de uma grande planta pode custar prejuzo de centenas de milhares de dlares. Essa a ironia da automao: durante a operao normal a automao faz tudo e desacopla o operador do processo, enquanto que durante os distrbios do processo o operador sozinho precisa entender e gerenciar uma mitigao e recuperao do processo altamente complexas. No pior caso, os trabalhos do operador so tediosos, mas muito responsveis, com pouca oportunidade de adquirir ou manter as qualidades requeridas para manipular as responsabilidades. Se a automao falha, alguns operadores no esto suficientemente preparados para substituir a automao. Muitos processos so operados em torno do relgio. Operadores trabalham em turnos, oito horas ou mais por dia, semana por semana, ano por ano (2000 horas por ano). Isso tem vrias consequncias importantes: 1. Operadores da sala de controle ficam muito tempo envolvidos com a IHM. Erros de projeto iro desperdiar muito desempenho e podem levar a problemas de sade. Por exemplo, quando os operadores so continuamente submetidos a stress.

75

2. A operao do processo um trabalho de equipe. Grandes plantas requerem muitos operadores trabalhando em paralelo. Diferentes turnos precisam se comunicar e o pessoal de manuteno precisa cooperar com o pessoal de operao mutuamente. 3. Aps operar um processo por muitos anos, operadores se tornam especialistas com necessidades especficas. Isso uma razo a mais para os operadores se envolverem no projeto de interface IHM. Geralmente h uma diferena entre como a interao foi originalmente planejada e como a operao real do dia a dia. Exemplos so taxas de alarme que so muito grandes para serem manipuladas, telas coloridas e bonitas que so apenas para serem mostradas aos visitantes importantes, mas raramente so ousadas para operao real. O agitador se move, o flare parece fogo vivo, mas isso s consome memria do processor, torna mais lento o sistema e serve pouco para a operao, principalmente nas emergncias. algo de um paradoxo que o operador da sala de controle geralmente considerado o elo mais fraco da corrente controle e segurana, enquanto simultaneamente formando o recurso mais flexvel para monitorar e melhorar o processo, e mais importante ainda, a ferramenta de anlise mais sofisticada, potencialmente capaz de diagnosticar e prever problemas de processo afetando a segurana de pessoas, meio ambiente e propriedade da empresa (nesta ordem). Em muitos perfis de incidentes, o operador tem minutos (e at horas) para diagnosticar e corrigir problemas, mas por um nmero de razes, ele deixa de fazer isso. importante reconhecer que o operador no est necessariamente em falha nesses casos e para estes eventos evolurem, vrias camadas de proteo precisam falhar. Mesmo assim, o operador tinha a oportunidade de evitar ou mitigar a ltima consequncia do evento e deixou de fazer isso. Anlise de vrios perfis de incidentes nos ltimos 25 anos anteriores de registros e anlise revela um nmero de falhas do ambiente de operao. Isso pode ser caracterizado como: Projeto do trabalho Isso inclui o reconhecimento e documentao de todas as tarefas que o operador deve fazer. Nveis de conduta e perfis de competncia esto diretamente associados com o projeto do trabalho apropriado e exato. Do mesmo modo, o projeto da IHM e a sala de controle requer que as vrias tarefas que o operador deve executar esto totalmente documentadas. Projeto da sala de controle O projeto da sala de controle em si pode ter um grande impacto (positivo ou negativo) no desempenho da equipe de operao. Interface Humano-Sistema (HSI) O HSI um elemento crtico em fornecer o desempenho requerido do operador. O HSI deve suportar o operador em todos os modos de operao e manter o operador totalmente informado da situao operacional atual (conscincia situacional). Perda da conscincia situacional pela equipe de operao geralmente conduz a um incidente maior. Sistemas de alarme O sistema de alarme um elemento chave da HSI e da operao em si da planta. Falha do sistema de alarme por deixar de reconhecer ou agir em funo do alarme, ou simplesmente por causa de um alarme falso negativo ou por causa de supresso do alarme, implicado na maioria dos incidentes e acidentes ocorridos na automao de processo. Treinamento e competncia Claramente a competncia do operador e da equipe de operao tem um grande impacto na eficincia da equipe em tomar as decises certas na hora certa para a operao efetiva. Competncia se adquire lentamente com a experincia e mais rapidamente com treinamento correto.

76

Comunicaes crticas de segurana Comunicao uma funo chave para o operador da sala de controle. H comunicaes associadas com a eficincia da operao e outras relacionadas diretamente com a segurana e requerem ter maior cuidado e gerenciamento. O exemplo mais frequente de comunicao crtica de segurana a troca e passagem de turnos dos operadores. Porm, a comunicao para baixo e para cima na cadeia direta de gerenciamento e superviso, entre operadores da mesma sala de controle ou a comunicao com outras equipes de outros locais no podem ser esquecida. Procedimentos Procedimentos e seus mecanismos de suporte associados (como checklist) so vitais para garantir consistncia de operao e para suportar o operador em atividades que podem ser feitas raramente. O melhor sistema de gerenciar procedimento usado para registrar o aprendizado e o suporte do processo de melhoria contnua. Alerta e fadiga Fadiga um problema acumulativo que contribui para colocar em risco a planta quando seus efeitos se acumulam ao longo do tempo. A fadiga total que estressa o operador deve ser considerada, incluindo atividades parcialmente relacionadas com a estao de operao e atividades totalmente desconectadas com a estao de operao, mas ainda relevantes, tais como padres de sono associados com o lazer ou atividades da famlia.

Caractersticas do operador humano


Quando o operador humano no se encaixa bem no mundo de frmulas matemticas, os engenheiros tm uma tendncia de ignorar assuntos relacionados com o operador humano. Entendendo algumas caractersticas do operador humano ajuda a projetar melhor a HSI, salas de controle e tarefas de operao. H trs tipos de comportamento ou processos psicolgicos apresentados no processamento da informao do operador: comportamento baseado na habilidade, regra e conhecimento (skill, rule e knowledge SRK). Um comportamento baseado na habilidade representa um tipo de comportamento que requer pouco ou nenhum controle consciente para fazer ou executar uma ao assim que a inteno formada. O desempenho suave, automtico e consiste de padres altamente integrados de comportamento. Em plantas modernas, a maioria das tarefas que requerem comportamento baseado na habilidade (como controle manual) tem sido automatizada. Muitas tarefas tpicas do operador requerem comportamento em nveis mais elevados. Comportamento baseado em regras caracterizado pelo uso de regras e procedimentos para selecionar uma srie de aes em uma situao familiar de trabalho. As regras podem ser um conjunto de instrues adquirido pelo operador atravs da experincia, atravs de treinamento ou passado por supervisores e operadores mais experientes. Comportamento baseado em conhecimento deve ser empregado quando a situao nova e inesperada. Operadores precisam entender os princpios e as leis fundamentais que governam o processo. Como os operadores precisam formar objetivos especficos baseados em sua anlise corrente do sistema, a quantidade de trabalho cognitivo tipicamente maior do que quando usando comportamentos baseados em habilidade e regras. Outro fato muito importante que a capacidade da memria humana de curto prazo limitada em torno de (7 2) itens. Isto significa que um projeto de IHM no deve sobrecarregar a memria de curto prazo do operador, forando-o a lembrar de vrios valores do processo. Tambm, a capacidade humana de ser interrompida por alarmes limitada. Enfoques modernos consideram essa limitao e usam-na para estabelecer valores alvo para o sistema de automao. O estudo do erro humano um campo de pesquisa muito ativo, incluindo trabalho relacionado com os limites da memria e ateno humanas e tambm para reconhecer preconceitos cognitivos. Preconceitos cognitivos so estratgias que so uteis e geralmente corretas, mas que podem levar a padres sistemticos de erro. Um exemplo de preconceito cognitivo a

77

disponibilidade heurstica. Isto significa que muitas decises so tomadas em base de informao que prontamente disponvel em vez de uma avaliao lgica de todas as alternativas (fora da vista, fora da mente). Se a informao somente disponvel em displays no correntemente mostrados, provvel que essa informao no ser includa no processo de tomada de deciso. No apenas o fator individual, mas tambm os fatores sistmicos e sociais do erro humano devem ser investigados.

Fig. 6.2. Comportamentos baseado em conhecimento, regras e habilidade

CPAS objetivos para o operador humano


A conscincia situacional a percepo de elementos no ambiente dentro de um volume de tempo e espao, a compreenso de seu significado e a projetao de seu status no futuro prximo. um objetivo chave de o CPAS ajudar o operador a manter sua conscincia situacional. Por exemplo, grandes telas de display que mostram a informao chave do processo no mesmo local fsico (geralmente chamada de SDCV: spatially dedicated and continuously visible espacialmente dedicado e continuamente visvel) so um modo de suportar a conscincia situacional. Muitos processos rodam suavemente por longos perodos de tempo sem requerer qualquer interveno do operador. No fcil manter vigilncia suficiente em tais condies. s vezes, tarefas artificiais como periodicamente preencher formulrios so introduzidas para manter a vigilncia do operador. Poderia ser que algum sintoma fcil de ver indique a chegada de um problema. Se o operador detecta esses sintomas suficientemente cedo, pode-se evitar um evento custoso, como uma parada no programada. Um princpio importante para manter um alto nvel de vigilncia evitar alarmes falsos positivos. Se o operador confia em seu sistema de alarme, um alarme ativado mais provavelmente causa de uma ao do operador. Plantas so operadas por equipes. Pessoal de operao e o pessoal de manuteno precisam trabalhar de modo junto e coordenado. Turnos precisam ser revezados de modo harmonioso (anlogo passagem de basto em uma corrida de revezamento). Um CPAS precisa suportar esse tipo de trabalho em equipe e fluxo de trabalho. A segurana pode ser aumentada acionando vrias camadas de segurana (IEC 61 511, 2003) (Fig. 6.3). Uma dessas camadas de segurana o operador humano e sua habilidade de levar o processo de volta ao estado normal. Nenhuma camada isolada pode ser perfeita e sem falha, mas a combinao de vrias camadas pode resultar em um nvel de segurana suficiente e satisfatrio.

78

Se os problemas que aparecem podem ser detectados e eliminados logo pelo operador, as camadas de proteo como sistema de desligamento automtico no precisam ser acionadas. Se paradas e partidas podem ser evitadas, isso resulta em segurana adicional, pois essas fases so geralmente crticas. claro que evitar paradas programadas aumenta segurana e tambm tem benefcios econmicos.

Modos de operao
O operador de processo e os associados sistema de controle e ambiente da sala de controle tipicamente funcionam em um dos trs modos dependendo das circunstancias de operao. Estes trs modos de operao so: 1. Normal 2. Anormal planejado 3. Anormal no planejado A operao normal est associada com as operaes de rotina. A tarefa do operador e o sistema de controle a de controlar e monitorar a operao do processo. A operao normal da planta feita em modo automtico para o operador e requer muito pouco conhecimento. Na operao normal automtica no necessrio o operador entender as implicaes globais das vrias interaes que esto ocorrendo em qualquer tempo. No esquema SRK (habilidade, regras e conhecimento), este nvel de operao corresponde ao comportamento baseado em habilidade. O operador tipicamente suportado pelo treinamento bsico, objetivos operacionais e manuais operacionais padro genricos.

Fig. Camadas de proteo (IEC 61 511-1)

A operao anormal planejada associada com operaes que no so rotina, mas so previstas e programadas. Exemplos de operao anormal planejada: partida e parada, manuteno programada e modos de operao anormais (operao manual substituindo a operao automtica de uma malha de controle). Algumas operaes de batelada, particularmente intervenes manuais no totalmente automatizadas ou sequenciadas, podem tambm ser tomadas como operao

79

anormal planejada. Uma caracterstica importante da operao anormal planejada que ela prevista pelo projeto e pela operao do processo e que ela planejada. A funo do operador gerenciar, intervir e geralmente se comunicar com outros operadores fora da sala de controle ou com o pessoal da manuteno. A operao anormal planejada dominada pelo conhecimento baseado em regras. Insight mais sofisticado nas interaes do equipamento e processo requerido pelo operador, suportado por procedimentos e checklist, que reduzem a necessidade de experincia direta permitindo a experincia e conhecimento de outro pessoal (usualmente mais experiente e qualificado) a ser trazido para a tarefa. Operao anormal no planejada associada com desvios imprevistos e no planejados da operao normal ou programada. Como o processo ou a planta est em modo no previsto pelo projetista do processo, pode haver um suporte limitado ou nenhum para o operador. O trabalho do operador consiste em diagnosticar e gerenciar a situao. O operador requer considervel conhecimento dos princpios fundamentais do processo, limites dos equipamentos, condies perigosas e sistemas de proteo e um entendimento sofisticado das interaes potenciais. O modo de operao anormal no planejada requer que o operador exiba comportamento baseado em conhecimento, geralmente suportado por procedimento ou mesmo experincia anterior. Correo dos distrbios pode requerer que o operador reduza ou finalmente pare parte ou toda a planta, de modo que importante que o operador tenha autoridade e confiana para tomar essa deciso onde necessrio. Grandes plantas ou processos podem estar em um ou mais desses modos simultaneamente. Uma unidade pode operar normalmente, talvez outra unidade esteja em manuteno, enquanto outra esteja com problemas. Operadores e equipes de operao devem estar altura de tratar estes diferentes e complexos cenrios para que uma variedade de mecanismos de suporte possa ou no possa estar disponvel.

Projeto do trabalho
comum para o operador da sala de controle ter um trabalho complexo, estendendo alm do bvio controle e monitorao do processo. igualmente comum para o ambiente da sala de controle, a IHM e o treinamento dado para o operador estender somente para operar o processo em modo normal. Atividades que o operador da sala de controle comumente faz, alm de operar o processo em modo normal, tipicamente incluem: 1. Parada e partida de unidades e equipamentos (bombas, compressores, caldeiras) 2. Diagnstico e gerenciamento de falhas ou distrbios no processo 3. Otimizao do processo 4. Emisso e gerenciamento de Ordens de Trabalho (Permisses de Trabalho) 5. Gerenciamento do acesso planta e sala de controle 6. Atendimento do telefone 7. Tarefas de manuteno coordenada 8. Coordenao de respostas de emergncia 9. Comunicao e delegao 10. Registro e logging de eventos e desvios importantes Avaliao formal, projeto e documentao das vrias atividades que o operador deve fazer constitui o primeiro passo necessrio para garantir que o operador est bem equipado para desempenhar essas atividades. Tcnicas avanadas, como Anlise de Tarefas Hierrquicas pode ajudar a entender e documentar a totalidade do trabalho do operador.

Projeto da sala de controle


O projeto da sala de controle em si tem um efeito dramtico no desempenho do operador e da equipe de operao. A norma ISO 11 064 (1999) contem recomendaes de projeto com exigncias corretamente especificadas e a mais larga viso possvel da funo da sala de controle.

80

A fase da anlise do trabalho ir indicar as vrias tarefas que o operador e a equipe de operao devem fazer. A norma ISO 11 064 define a sala de controle tem termos de zonas de tarefas onde vrias atividades so executadas. Alm das tarefas especficas baseadas na operao (e.g., controle de processo, edio de permisses, coordenao da resposta de emergncia) deve se considerar a atividades domesticas: banheiros, pias de limpeza, vestirio, guarda volumes, etc. A sala de controle ser o foco do projeto. O projeto da sala de controle representa um compromisso entre exigncias conflitantes. Por exemplo, um projeto de bancada de controle linear excelente para operaes onde as equipes de operao compartilham equipamentos e interfaces, mas ruim para o contato visual direto entre operadores. O nmero de operadores, o tipo de tarefas a serem feitas, a hierarquia de gerenciamento e superviso, tudo isso tem um impacto no layout da sala de controle. Assuntos como controle do acesso, iluminao, ar condicionado (HVAC Heating, ventilating and air conditioning aquecimento, ventilao e ar condicionado) e o ambiente de reunio tambm tero um impacto na eficincia da equipe da sala de controle, bem como de sua sade e bem estar global. O projeto da sala de controle precisa incorporar espao suficiente para trabalho com papel, procedimentos e instrumentos e outros itens requerendo espao de mesa, mesmo como conceito de sala de controle sem papel. Finalmente, a seleo dos itens da moblia no fixa (mveis) tem um impacto importante no desempenho, sade e bem estar dos operadores. Itens tais como cadeiras so sujeitos a uma taxa significativamente maior de uso do que em um ambiente normal de escritrio. Uma cadeira de escritrio ser ajustada s ocasionalmente, talvez uma nica vez para o primeiro usurio. Uma cadeira da sala de controle ser ajustada para cada turno (todos os operadores no possuem a mesma altura) e ser usada, claro, 24 horas por dia. Seleo cuidadosa de mveis especializados ir evitar problemas ou falhas prematuras.

Projeto da IHM
O projeto da IHM uma contribuio importante para a eficincia do operador em tomar decises corretas no tempo certo. O operador tipicamente tem vrias interfaces, mesmo em uma sala de controle integrada moderna e pode estar envolvido com um ou mais sistemas baseados em monitor, telefones, rdios, sistemas de segurana, sistemas de acesso, etc. A maioria das Interfaces de operao modernas segue o modelo MS Windows, usualmente rodando com um sistema operacional baseado em Windows. O operador vai precisar de um teclado e mouse (ou apontador similar, como trackball). uma boa prtica fornecer um nico teclado e mouse que possa ser focado em vrias telas arranjadas em um conjunto (cluster). Em sistemas mais novos, a combinao de telas pode eliminar a borda ou interface da tela para permitir grficos e janelas espalharem em mais de uma tela sem uma descontinuidade notvel na juno. (Fig. 6.4). Isso particularmente efetivo em sistemas baseados em projeo. Onde disponvel, a tela pode ser considerada como uma rea de tela contigua de estado real onde o operador pode posicionar a janela para atender sua necessidade imediata. O nmero de telas (ou estado real total) deve ser escolhido para considerar todas as tarefas relevantes que o operador deve fazer. A sada do projeto do trabalho formal fornecer a informao necessria para permitir essa tomada de deciso. Por exemplo, se o operador precisa monitorar a partida de duas unidades separadas (com grfico especfico baseado em tarefa) enquanto vendo a operao normal do resto da planta (possivelmente requerendo duas telas grficas), ento a interface do operador deve consistir de um mnimo de 4 telas. Layouts de agrupamento de telas pode ter profundidade simples ou dual. A escolha do layout pode impactar o tamanho da estao de operao global e linhas potenciais de vista dentro da sala de controle. EEMUA 201 (2002) e ISO 11 064 (1999) contem orientao no projeto de estaes de operao. H numerosas teorias e normas escritas para o projeto e realizao da IHM do sistema de controle, porm todas elas representam um compromisso de uma forma ou outra.

81

Muitos fabricantes de sistema de controle tm um enfoque integrado para o veja e sinta da IHM, baseado em torno de uma combinao do MS Windows e uma srie de normas grficas e cdigos de projeto baseados em normas internacionais e compatibilidade com sistemas de controle anteriores do fabricante. Estas normas so geralmente embutidas em bibliotecas grficas que podem reduzir substancialmente o tempo de configurao e, portanto o custo total do sistema. Esse enfoque baseado em biblioteca pode tambm fornecer um beneficio em todo ciclo de vida do sistema, garantindo que modificaes e pequenos projetos so entregues de um modo consistente com a realizao original. Uma exigncia mandatria da interface do operador a consistncia na apresentao de dados. Os comportamentos da cor, formato e dinmica da interface devem ser definidos, documentados e consistentes em tudo. Consistncia da apresentao de dados permite o operador assimilar os dados de modo mais rpido e exato e tambm ajuda o operador extrapolar de dados e circunstncias bem conhecidos em resposta a dados apresentados s raramente.

Fig. 6.4. Moderna estao de operao com telas grficas

A escolha final da paleta de cores representa um compromisso entre facilidade de uso, cores com baixo estresse (cores frias) e alto contraste (tipicamente com background neutro, preto ou cinza escuro). A densidade dos dados mostrados na tela representa um compromisso entre a necessidade de o operador monitorar a mxima quantidade de informao da planta e a habilidade do operador ler de modo confortvel e sem ambiguidade as altas densidades de informao alfanumrica e grfica. As necessidades de operadores mais velhos com a deteriorao natural da viso devem tambm ser consideradas. A norma ISO 11 064 contem recomendaes relacionadas com tamanho da fonte baseado no ngulo visual. A IHM baseada em tela tem sido um padro nos ltimos 40 anos e provavelmente vai permanecer por muito tempo. H vrias caractersticas de interface baseada em tela que devem ser entendidas pelos projetistas e pelos operadores. Diferente das interfaces de operao baseadas em painel que foram substitudos pelos monitores, a IHM baseada em tela esconde muito do processo para o operador em qualquer tempo. As telas formam uma janela que pode ser superposta no processo pelo operador atravs da navegao de vista a vista, mas isso limita naturalmente a conscincia do operador. Esse efeito chamado de buraco da fechadura torna difcil para o operador manter uma vista geral de todo o processo. 82

O projeto da interface do operador influencia a habilidade de o operador fazer a operao em modo normal, anormal planejado e anormal no planejado. Um projeto correto de interface melhora o desempenho do operador, um projeto ruim pode diminuir significativamente o desempenho do operador. A caracterstica desejada da interface do operador ir variar de acordo com o modo de operao. Em operao normal o operador monitorar um grande nmero de variveis, algumas ou todas que esto em controle automtico. Os objetivos so de otimizar a eficincia e qualidade do produto e garantir que no haja desvios significativos das condies ideais de operao. Os bons operadores estaro patrulhando suas interfaces ao invs de estar contando com o sistema de alarme para alerta de problemas potenciais. Desse modo, possvel para o operador monitorar um alto nmero de variveis de modo efetivo. A apresentao de dados ir mostrar desvio da operao normal e idealmente dar os avisos avanados ao operador dos problemas que podem aparecer. Devem ser usadas tcnicas como display de tendncia mostrando os limites de alto e baixo de operao ou dados analgicos em grande quantidade destacando com cor os desvios. Em operao anormal planejada, o operador est monitorando, controlando ou comunicando operaes descontnuas, preferivelmente de acordo com um procedimento de operao especfico. A IHM deve fornecer ao operador toda informao necessria para desempenhar a funo sem a necessidade de toda hora mudar a tela. Isto permite o mnimo de rea da tela a ser dedicada para a tarefa, permitindo as atividades de operao normal ser executadas simultaneamente sem perder a vista ou a tarefa normal ou a tarefa anormal planejada. Pode ser necessrio o uso de grficos especficos baseados em tarefa, que alinham com o procedimento associado governando a tarefa. Os intertravamentos de processo e outros alarmes so geralmente uma caracterstica da operao anormal planejada e onde os estados possveis desses intertravamentos necessitem ser incorporados em grficos baseados em tarefa para ajudar no diagnstico de problema. Operao anormal planejada pode durar um perodo de tempo considervel, potencialmente podendo estender de um turno para outro. A IHM deve idealmente ajudar um operador em rapidamente saber em que operao o processo est. Pode se usar tcnicas como checklist baseada em tela (alinhando com o procedimento relevante), displays de estado da unidade e displays de status detalhado do equipamento (que pode estar escondido em operao normal). comum que o operador da sala de controle esteja tambm monitorando o resto do processo, enquanto supervisionando ou fazendo operaes anormais planejadas. O trabalho deve ser projetado de modo que no sobrecarregue o operador ou a equipe de operao. Deve haver telas em nmero suficiente para permitir que todas as tarefas planejadas sejam feitas simultaneamente. Em operao anormal no planejada, o operador confronta com circunstancias que podem ser nicas, imprevisveis e fora de sua experincia. Como a situao imprevisvel, este modo de operao o mais difcil de projetar, planejar e administrar. O papel da IHM na operao anormal no planejada mostrar a mxima informao ao operador para o melhor diagnstico de um problema complexo e envolvente, dando-lhe a mxima conscincia da situao. A equipe de operao estar tratando do problema, de modo que a IHM precisa suportar comunicao e colaborao. Grandes telas vistas por toda a equipe de operao podem facilitar a viso comum necessria para ajudar a comunicao baseada em equipe. uma reclamao comum que em operao anormal no planejada a IHM fornece uma quantidade sem fim de detalhes, mas deixa de mostrar a informao querida e requerida. A dinmica da viso panormica simples do processo deve ser fornecida, tais como balano de massa, mostrando inventario de cada unidade e os fluxos de processo entre eles. importante que todos os caminhos potenciais sejam mostrados no grfico e que eles no sejam simplificados demais, pois isso pode levar a alguns cenrios que seriam ignorados pela equipe de operao. Grficos de tendncia podem ajudar o processo no diagnstico quando usados em conjunto com telas tipo panormicas.

83

Pode tambm ser conveniente usar vistas alternativas de fluxos do equipamento ou processo. Por exemplo, onde um sistema de transferncia de calor usado para fornecer o aquecimento e resfriamento para o processo, geralmente integrado com o diagrama P&I e portanto integrado no grfico do processo. Quando diagnosticando problemas do processo, pode ser til ter uma viso de todo o sistema de aquecimento escondido pelos detalhes do processo. Quando o processo move para um modo anormal no planejado, ele pode entrar em um modo de operao de desligamento automtico onde uma ou mais unidades desligada pelo SIS (Sistema Instrumentado de Segurana) independente. Assim que isso ocorrer, o trabalho do operador pode mudar de fazer diagnstico para garantir que o processo tenha sido colocado no estado seguro necessrio pelo SIS. Diagrama simples de status indicando o estado seguro desejado com comparao com o estado real do processo pode rapidamente destacar os desvios requerendo interveno manual.

Fig. Estao de trabalho (IHM) com tela grande

Anlise de tarefa da operao


A norma IEC 11 064 e a recomendao EEMUA 201 enfatizam a importncia de uma boa anlise de tarefa do operador de painel. A anlise da tarefa o estudo de como uma tarefa feita, incluindo uma descrio detalhada das atividades manual e mental e duraes da tarefa e elemento, frequncia de tarefas e qualquer outro fator nico envolvido na execuo de uma dada tarefa.

Projeto da Interface Ecolgica


O Projeto da Interface Ecolgica (EID) um enfoque relativamente novo para projetar interfaces para sistemas grandes e complexos. O termo EID foi cunhado em 1989 e reflete as limitaes do ambiente de trabalho de um modo que perceptivelmente disponvel para o pessoal que o usa. Reduzindo a carga mental e suportando o raciocnio baseado no conhecimento, EID pretende melhorar o desempenho do usurio e a confiabilidade global do sistema para eventos antecipados e no antecipados em um sistema complexo. EID ficou popular, particularmente onde h uma alta probabilidade de operao em modo anormal no planejado onde o operador requerido aplicar um algo grau de conhecimento e diagnstico. Porm, no prtico reservar as 84

tcnicas de EID para esse modo de operao e a interface inteira pode ser projetada de acordo com tcnicas e princpios envolvidos no EIS. Porm, isso pode conflitar com os princpios de projeto do fabricante do sistema ou bibliotecas de normas.

Participao do operador no projeto da IHM


A norma ISO 11 064-1 recomenda a participao do operador de projeto da sala de controle, para incluir a IHM. um enfoque estrutural em que os futuros usurios so envolvidos no projeto. A participao do usurio atravs de todo processo de projeto essencial para otimizar a interao humano-sistema a longo prazo induzindo um senso de propriedade no projeto. Alm disso, operadores experientes podem oferecer contribuio valiosa emprica ao projeto da IHM. Sua experincia prtica nem sempre documentada ou bem conhecida pelos projetistas. Engenharia da usabilidade Para as aplicaes de desenvolvimento de software, a engenharia da usabilidade foi estabelecida h 20 anos e ajuda a criar interfaces amigveis que permitem ao usurio desempenhar suas tarefas de modo eficiente. Muitos desses princpios podem ser encontrados na norma ISO 9241: 1. Fazer prottipo 2. Envolvimento do usurio 3. Revises especialistas 4. Teste A engenharia da usabilidade consegue realimentao dos usurios reais o mais cedo possvel e as perguntas so para resolver problemas com interfaces reais ou prottipos. Usualmente mais fcil e barato fazer mudanas nas primeiras fases do projeto e problemas de usabilidade encontrados muito tarde so mais difceis de corrigir. Objetivos mensurveis ajudam a focar o projeto da IHM em usabilidade. Exemplos de tais objetivos seriam: Media menor que um alarme durante 10 minutos em operao normal Pacotes de software podem ser instalados e configurados por um engenheiro de projeto em menos de 30 minutos. Operadores especificam IHM com uma avaliao de um mnimo de 4 em 5 na escala de satisfao.

Recomendaes de IHM
Recomendaes e normas capturam as melhores prticas e ajudam a projetar melhor a IHM. Em uma IHM industrial h 4 camadas diferentes de recomendaes: 1. Recomendaes gerais so baseadas nas caractersticas do conhecimento humano e aplicam a todas IHM, incluindo a IHM da sala de controle industrial. Exemplos de tais recomendaes so: ISO 9241 e Microsoft Official Guidelines for User Interface Developers and Designers (1999). 2. Recomendaes especficas s indstrias, como EEMUA 201 ou ISO 11 064, que foca as especificaes do controle de processo industrial. 3. Muitas companhias de produo possuem suas prprias recomendaes internas que definem assuntos como cor de fundo, logotipos, fontes usadas para estaes de operao. Petrobras, Braskem, Vale possuem suas prprias recomendaes. 4. Em alguns casos, plantas ou sites individuais criam recomendaes especficas. O sistema de alarme um subitem importante da IHM no controle de processo e deve ser tratado como tal.

Recomendaes do Sistema Windows


Como a maioria das estaes de operao atuais rodam o sistema operacional Windows da Microsoft, o guia geral publicado pela Microsoft (1999) deve ser aplicado onde fizer sentido. Ele consiste de 4 partes: 1. Fundamentos do projeto para interao do usurio 2. Componentes de interface do Windows

85

3. Especificaes de projeto e recomendaes 4. Apndices e referncias Muitos operadores rodam computadores em casa e esperam consistncia com o que usam em casa com o ambiente de trabalho. Microsoft tem um mercado muito mais amplo (escritrio, residncias) em mente quando escreveu o guia, de modo que nem tudo encaixa 100% situao muito especial do controle de processo, que representa somente uma frao pequena do mercado para a Microsoft. No futuro, provvel que novas normas desenvolvam outras aplicaes de uso geral (e.g., web e telefones inteligentes) sejam absorvidas pelo CPAS.

ISO 9241
A norma ISO 9241 foi originalmente chamada Ergonomic requirements for office work with visual display terminals e foi renomeada para Ergonomic of Human System Interaction. A norma vlida para todos os tipos de reas de aplicao, no apenas em CPAS. A norma 9241 consiste das seguintes partes:

Parte 1 Parte 2 Parte 4 Parte 5 Parte 6 Parte 9 Parte 11 Parte 12 Parte 13 Parte 14 Parte 15 Parte 16 Parte 17 Parte 18 Parte 110 Parte 151 Parte 171 Parte 300 Parte 302 Parte 303 Parte 304 Parte 305 Parte 306 Parte 307 Parte 308 Parte 309 Parte 400 Parte 410

Introduo geral Guia sobre exigncias da tarefa Exigncias de teclado Layout da estao de trabalho e exigncias de postura Guia sobre ambiente de trabalho Exigncias para dispositivos de entrada diferentes de teclado Guia sobre usabilidade Apresentao da informao Guia do usurio Dilogos de menu Dilogos de comando Dilogos de manipulao direta Dilogos de preenchimento de formulrios Guia de acessibilidade para equipamento ICT e servios Princpios de dilogo Guia sobre interfaces de usurio de World Wide Web (WWW) Guia sobre acessibilidade de software Introduo s exigncias de display visual eletrnico Terminologia para display visual eletrnico Exigncias para display visual eletrnico Mtodos de teste de desempenho do usurio para display visual eletrnico Mtodos de teste de laboratrio ptico para display visual eletrnico Mtodos de avaliao de campo para display visual eletrnico Mtodos de anlise e conformidade para display visual eletrnico Display emissor-eletrnico por conduo de superfcie (SED) Display com diodo emissor de luz orgnico Princpios e exigncias para dispositivos de entrada fsicos Critrios de projeto para dispositivos de entrada fsicos

Como um exemplo de como a norma ISO 9241 pode ser aplicada, a parte 12 trata do uso de cores. recomendado que a cor nunca seja o nico meio de codificao porque algumas pessoas discriminam as cores de modo pobre ou no podem discriminar na base de cor ao todo (e.g., homens daltnicos). A cor deve ser redundante com alguma outra tcnica de codificao.

86

A importante parte 110: Princpios de dilogo define os seguintes princpios: 1. Convenincia da tarefa 2. Autodescrio 3. Conformidade com expectativas do usurio 4. Convenincia do aprendizado 5. Controlabilidade 6. Tolerncia ao erro 7. Convenincia para individualizao ISO 11 064 A norma ISO 11 064: Projeto ergonmico para centros de controle consiste em 7 partes: Parte 1 Parte 2 Parte 3 Parte 4 Parte 5 Parte 6 Parte 7 Princpios de projeto de centros de controle Princpios para arranjo de sutes de controle Layout da sala de controle Layout e dimenses das estaes de trabalho Displays e controles Exigncias ambientais para centros de controle Princpios para avaliao de centros de controle

A parte 1 define os seguintes princpios de projeto: 1. Aplica um enfoque de projeto centrado no humano 2. Integra a ergonomia na prtica de engenharia 3. Melhora o projeto atravs da iterao 4. Conduz anlise situacional 5. Conduz anlise de tarefas 6. Projeta sistemas tolerantes a erro 7. Garante participao do usurio 8. Forma uma equipe de projeto interdisciplinar 9. Documento a base ergonmica do projeto EEMUA 201 O guia EEMUA 201: Painis de controle de planta de processo utilizando interfaces humano-computador (2002) tem o seguinte escopo: 1. Os fatores a considerar quando projeto um HCI para processos industriais 2. Hierarquias de display 3. Projeto do formato do display da tela 4. Projeto da sala de controle Os princpios chave de projeto definidos na EEMUA 201 so: 1. A principal funo da HCI apresentar ao operador uma interface consistente, fcil de usar, que fornea a funcionalidade de monitorar e controlar em todas as condies da planta. 2. Uma anlise de tarefa deve ser feita para capturar o escopo global da tarefa do operador. 3. Envolvimento obrigatrio e completo do usurio final no projeto detalhado do formato do display e o projeto completo do sistema. 4. O nmero de telas fsicas fornecidas no HCI deve permitir o acesso completo a toda informao e controle necessrio em todas as circunstancias de operao. 5. O projeto HCI deve permitir para um formato de display panormico da planta permanentemente visvel 6. Acesso contnuo indicao de alarme. 7. Capacidade de expandir o nmero de telas fsicas deve ser embutida no projeto original.

87

Concluso
Em concluso, pode parecer que o operador parcialmente responsvel por ou est implicado com quase todo evento na indstria de processo. Enquanto isso indubitavelmente verdade em um nvel superficial, duas coisas devem ser lembradas: O operador o produto de muitos elementos, tais como treinamento, experincia, superviso, procedimentos e outros elementos de suporte, IHM, sistema de alarme, cultura e ambiente onde ele trabalha. O pessoal de operao consciente e quando ocorrem erros, geralmente geralmente em busca de produo ou qualidade. importante lembrar que enquanto a indstria de processo, seus reguladores associados e mesmo a mdia so timas para registrar as raras instncias onde e quando as coisas vo dramaticamente erradas, eles so coletivamente mais omissos em registrar onde as coisas vo bem. Para cada acidente ou evento, h circunstancias no faladas onde o operador da sala de controle toma a deciso correta no tempo certo que salva vidas, mantem o ambiente ou contribui para o lucro da planta. O operador humano tem uma tarefa importante na superviso e controle de processos complexos altamente automatizados. Elevando os nveis de automao, uso de tecnologia de computador e redues de pessoal tem tornado o trabalho mais abstrato e tem desacoplado o operador do processo fsico. Em caso de eventos imprevisveis, a criatividade e flexibilidade do operador humano so requeridas para ainda manter o processo sob controle. Treinamento sistemtico e IHM de alta qualidade para suportar o operador durante operao anormal no planejada so essenciais. O conhecimento das caractersticas humanas e as normas e recomendaes relacionadas ajudam os projetistas a criar IHM e salas de controle de alta qualidade.

88

6.2. Gerenciamento do alarme


Sistemas de alarme
O conceito de alarme (francs para a larme) que significa s armas muito antigo e origina do conceito militar onde um guarda avisa a seus colegas de um evento de um ataque. Tambm, em controle de processo, alarme tem uma tradio muita longa (e.g., um apito indicando que uma gua est fervendo na chaleira). Plantas antigas usavam painis com lmpadas incandescentes e buzinas para alarmar os operadores. O entendimento intuitivo que em caso de um alarme o operador humano deve tomar alguma ao. Dessa perspectiva, alarmes so um limite importante entre automao e operao humana. A superviso de um processo usualmente suportada por um sistema de alarme. Teoricamente, cada alarme simples deve ser valioso para o operador e requer ao do operador (EEMUA 919, 2007). Um alarme falso negativo definido como a ausncia de um alarme quando ocorre um evento perigoso vlido e um alarme falso positivo quando o alarme acionado, mas no h nenhuma coisa perigosa ocorrida. EEMUA 191 chama isso de alarme sem sentido. O alarme falso positivo tambm chamado falha segura do alarme e o alarme falso negativo tambm chamado de falha perigosa do alarme. Esses dois tipos de falhas determinam a qualidade de um sistema de alarme. A qualidade do sistema de alarme resulta da qualidade dos componentes fsicos (sensores) e principalmente do esforo despendido para fazer a engenharia do alarme. Um sistema de alarme perfeito no tem nem alarme falso negativo e nem alarme falso positivo. Na prtica, ocorre menos alarme falso negativo (falha perigosa) e ocorre mais alarme falso positivo. Pesquisas recentes de sistemas de alarme tm focalizado em eliminar alarme falso positivo (embora sendo falhas seguras so mais frequentes). EEMUA 191 tem enfatizado o fato que a capacidade humana de absorver alarmes limitada. Se esse limite excedido por perodos mais longos de tempo, provvel que alarmes importantes sejam desprezados e em casos extremos, todo o sistema de alarme poderia ser mais ou menos ignorado. Fig. 6.5. mostra a tarefa supervisria de controle do operador com um foco no suporte de um sistema de alarme. claro que o operador tem muito mais tarefas do que apenas reagir aos alarmes. Essas tarefas so interrompidas e perturbadas pelos alarmes. No ocaso ode alarmes vlidos isto inevitvel, mas no caso de alarme falso positivo essas interrupes aumentam o custo do sistema de m qualidade do alarme. Interrupes frequentes tambm podem afetar a sade da operao.

Fig. 6.5. Sistema global humano-mquina

89

comum quando h muito alarmes sonoros, eles serem desligados. De fato, em muitas salas de controle os alarmes sonoros tm sido desligados completamente, porque se no o nvel de rudo fica intolervel. Taxas de alarmes que s constantemente altas distraem operadores, diminui a vigilncia e confiana, abaixa a tenso situacional e sobrecarrega a memria imediata do operador. Como consequncia, os operadores podem desprezar alarmes vlidos que esto em indicao recentes do aparecimento de problemas. Grande nmero de alarmes falso positivo diminui o valor de alarmes importantes porque os operadores esto menos capazes de absorver os alarmes vlidos. Sistemas automticos podem ser subutilizados ou desabilitados por causa da falta de confiana, como no caso de sistemas de alarme que frequentemente do alarmes falsos. Em muitas salas de controle se pode facilmente encontrar sintomas de sistemas de alarme de baixa qualidade, como: 1. Telas esto sempre cheias de alarmes novos chegando em alta velocidade (tanto em operao normal e aps distrbios na planta). 2. Alarmes permanecendo por longos perodos (dias, semanas e mesmo anos). 3. Alarmes so reconhecidos em conjunto e sem nenhuma considerao (reconhecimento cego). 4. Operadores no do valor ao sistema de alarme como suporte de suas tarefas. 5. Alarmes sonoros so desabilitados porque eles estariam poluindo a sala de controle com rudo constante.

Por que plantas geram tantos alarmes


Com sistemas modernos de controle, incluindo CPAS, ficou muito fcil configurar grande nmero de alarmes isolados. Se o enfoque tomado sem considerar o sistema global, mas se configura dispositivo de alarme por dispositivo, sinal por sinal, isso pode levar cacofonia de alarmes, minuindo o valor de alarmes validos requerendo ao do operador. Sistemas podem gerar grande nmero de alarmes (mais de 2000 alarmes por dia tpico para muitas plantas) durante operao normal e mesmo durante distrbios de processos. Os instrumentos modernos de campo podem gerar uma grande faixa de mensagens de diagnstico, que so geralmente tomadas como alarmes. Sistemas modernos de controle permitem configurao de grupos de alarmes e eventos do usurio alvo, de modo que mensagens de manuteno sem importncia direta para os operadores so apresentados apenas para o pessoal de manuteno. Porm, tais mensagens so geralmente enviadas simplesmente para todo mundo, incluindo os operadores. Sensores com defeito geralmente geram altas taxas de alarme ON-OFF-ON. Nem sempre possvel substituir ou consertar rapidamente esses sensores pois eles podem ser inacessveis (projeto ruim). Se tais alarmes so desabilitados, o Gerenciamento de Mudana precisa ser aplicado, porque seno ele poderia esquecer-se de habilitar o alarme de novo assim que o sensor fosse reparado. A configurao de muitas malhas de controle muitas vezes est longe de timo. Tais malhas podem acionar atuadores em posio extrema que poderia resultar em alarmes. Muitos blocos de funo para malhas de controle possuem funes de diagnstico que podem gerar alarmes. Uma anlise sistemtica de alarmes relacionados com malhas de controle pode ser usada para identificar candidatos para monitorar ou sintonizar a malha. s vezes alarmes especiais so configurados durante a fase de comissionamento. Assim que feito o comissionamento, muitos desses alarmes no fazem mais sentido, mas nunca so removidos. Atualmente, sistemas de controle permitem a configurao de vrios diferentes alarmes para cada tag, por exemplo: 1. Alarmes de limite baixo e alto com trs nveis cada (L, LL, LLL, H, HH e HHH) 2. Taxa de variao, diminuindo ou aumentando 3. Alarmes de desvio do ponto de ajuste 4. Alarmes de valores ruins

90

Normas e recomendaes de gerenciamento de alarme


Uma anlise completa de acidentes como a exploso na Refinaria Texaco em Milford Haven tem mostrado claramente que gerenciamento ruim de alarme tem contribudo para acidentes. Em Milford Haven, os operadores tinham 275 alarmes diferentes nos ltimos 11 minutos antes da exploso. Por isso, autoridades de vrios pases (UK, Noruega) requerem que plantas com segurana crtica tenham gerenciamento sistemtico de alarmes. Se situaes crticas podem ser evitadas pelos operadores estabilizando o processo de modo que no precise usar o sistema de desligamento de emergncia, isto no apenas aumenta a segurana da planta, mas tem em muitos casos altos benefcios econmicos, porque cada parada no programada pode ser muito cara. O aumento da segurana a ponta visvel do iceberg, mas melhor gerenciamento de alarme ajuda a rodar melhor a planta. O documento mais influente para gerenciamento de alarme tem sido sem dvida a recomendao EEMUA 191. ISA tambm publicou recentemente a norma ISA 18.2 (2009), mesmo j existindo a norma ISA 18.1 sobre anunciadores de alarme. Outra recomendao recente para gerenciamento de alarme so as normas NAMUR NA 102 (2008) e Norwegian YA 711 (2001). EEMUA 191 Em 1999, a EEMUA (Engineering Equipment and Materials Users Association) produziu sua publicao 191: Sistemas de alarme, um guia para projetar, gerenciar e procurar. EEMUA uma associao industrial sem fins lucrativos que existe para beneficiar empresas que possuem ou operam plantas industriais. EEMUA 191 se tornou uma norma mundial padro de facto para gerenciamento de alarme. As ideias chave na recomendao so que cada alarme deve ser til e relevante para o operador e que no deve haver alarme sem uma resposta predefinida do operador. A expectativa comum que operadores nunca devem ignorar alarmes importantes impraticvel se novos alarmes chegam muito rapidamente, dia por dia, 8 horas por turno. EEMUA 191 recomenda que a taxa de alarme em operao normal deve ser abaixo de um alarme em cada 10 minutos. EEMUA 191, que foi atualizada em 2007, uma recomendao para Gerenciamento de Alarme e no mandatria. O documento reconhecido por vrios corpos regulatrios como boa prtica. EEMUA 191 foca nas capacidades de processamento da informao do operador, enfatizando a usabilidade de um sistema de alarme da perspectiva do operador. O documento somente disponvel em papel e pode ser comprado em www.eemua.org. ISA 18.2 Por vrios anos, um comit ISA focou no desenvolvimento da norma chamada ISA 18.2: Gerenciamento de Sistemas de Alarme para as Indstrias de Processo. O comit tem larga representao de usurios, fornecedores e consultores. A norma ISA 18.2 incorpora trabalho e ideias da EEMUA 191 e uma norma (no uma recomendao, como a EEMUA 191) e provvel que ela se torne uma norma mundial, substituindo a EEMUA 191, para gerenciamento de alarme. O escopo da ISA 18.2 estabelecer terminologia e prticas para sistemas de alarme, incluindo definies, projeto, instalao, operao, manuteno e modificao e processos de trabalho para manter eficientemente um sistema de alarme ao longo do tempo. Gerenciamento de sistema de alarme inclui vrios processos de trabalho atravs do ciclo de vida do sistema de alarme. NAMUR NA 102 NAMUR (Associao Internacional de Usurio para Automao em Indstrias de Processo) NA 102 estabelece um procedimento para projetar gerenciamento ode alarme dentro de um sistema de controle de processo, comeando de uma viso holstica do processo. Enquanto ela inclui sinais de mensagem, seu principal foco est em alarmes. Durante a engenharia e fase de montagem, o documento deve ser usado como um guia geral, baseado em que parte de uma especificao individual PAS pode ser derivado formatando-a para encaixar uma unidade particular do equipamento. Durante a operao da planta, ela serve como um guia para servio e manuteno, bem como para sinalizar a otimizao do sistema. Ela tambm fornece informao para fabricantes 91

de sistema de controle de processo em como estender as funes do produto. NAMUR NA 102 descreve um exemplo de planta onde a realizao do gerenciamento de alarme resultou em um aumento global da eficincia do equipamento por mais de 5%.

Filosofia de alarme na planta inteira


Um documento da filosofia do alarme global da planta descreve como os alarmes devem trabalhar em uma planta. muito importante ver um documento escrito descrevendo uma filosofia consistente de alarme global da planta. Detalhes podem ser encontrados na EEMUA 191. Itens no documento incluiriam: 1. Qualidade requerida do sistema de alarme. Valores alvo para Indicadores de Desempenho Chave (Key Performance Indicators - KPI) e quando e como esses KPIs so medidos. 2. Nome do gerente responsvel pela qualidade do sistema de alarme. 3. Critrios de seleo do que alarmado e do que no alarmado. 4. As diferentes prioridades usadas e seus significados associados, regras para como prioridades de alarme so sistematicamente atribudas. 5. Gerenciamento de Mudana para parmetros de configurao de alarme.

Harmonizao e coerncia do sistema de alarme


Diferentes partes da planta so comumente automatizadas em diferentes pocas, com sistemas diferentes por diferentes empresas. As filosofias atrs dos sistemas de alarmes para estas partes diferentes podem ser muito diferentes. Quando acontece que um nico operador seja responsvel pela superviso de diferentes partes da planta, inconsistncias podem ser muito confusas e ser perigosas. Por exemplo, se o valor de prioridade 1 significa alto em uma parte da planta e baixo em outro, isso pode perigosamente mal entendido. O CPAS deve suportar a harmonizao de diferentes fontes de alarme permitindo o remapeamento de valores de prioridade por que por razes tcnicas ou organizacionais nem sempre possvel harmonizar os ajustes diretamente em todas as fontes.

Mtrica da qualidade do sistema de alarme


No passado era difcil avaliar a qualidade de um sistema de alarme. Quando a tecnologia atual comeou a gerar mais e mais alarmes, muitas plantas aceitaram taxas de alarme excessivamente altas. Investimentos em sistemas de alarme eram difceis de justificar porque as melhorias potenciais eram difceis de quantificar. Foi um grande avano quando em 1999 a EEMUA especificou vrios indicadores de desempenho mensurvel que podem ser usados para comparar e avaliar o desempenho do sistema de alarme da planta. Por exemplo: 1. Taxa de alarme mdia a longo prazo em operao de regime permanente. 2. Nmero de alarmes durante os primeiros 10 minutos aps um grande distrbio na planta. 3. Distribuio da prioridade de alarme: alta (5 %), mdia (15 %) e baixa (80 %). 4. Nmero mdio de alarmes persistentes. Estas KPIs fceis de medir no garantem automaticamente um bom sistema de alarme, mas elas so ferramentas teis para se conseguir uma melhoria qualidade do sistema de alarme.

Melhoria da qualidade do sistema de alarme


Os passos bsicos da melhoria da qualidade do sistema de alarme so: 1. Registrar todos os alarmes e eventos em uma database como base para anlise posterior. Muitos sistemas de alarme incluem um mdulo de logging de alarme. Impressoras de alarme como ainda encontradas em algumas plantas so difceis e caras de manter e essencialmente enterram informao valiosa acerca da histria da planta em grandes pilhas de papel que ningum vai ler.

92

2. Medir as taxas de alarme e outros KPIs de alarme e compar-los com recomendaes de normas ou guias ou valores de plantas de referncia. O enfoque global pode ser decidido baseado nesses KPIs. 3. s vezes possvel melhorar o sistema de alarme significativamente com relativamente pouco esforo. Poucos alarmes podem ser responsveis por uma grande parte da carga de alarme global. Eliminar alarmes sem importncia, atravs de: a. Sintonia de malhas de controle b. Ajuste de limites de alarme, ajustes de filtro e histerese. c. Substituio de sensores defeituosos. d. Configurao de alarmes que no requerem ao do operador como eventos ou remov-los. 4. Racionalizao do alarme o processo de rever alarmes contra os princpios da filosofia de alarme e determinando e documentando a razo e exigncias de projeto para o alarme. Isso inclui a base para o ajuste de alarme, as consequncias de desvio e ao corretiva que deve ser tomada pelo operador. Racionalizao tambm inclui a prioridade de um alarme baseando-se no mecanismo definido na filosofia de alarme ou sua remoo. 5. Garantir que alarmes sejam manipulados no tempo correto. Alarmes ficando durante dias, semanas ou menos so geralmente uma indicao de uma cultura aceitando risco e qualidade insuficiente. 6. Medir o KPI do alarme regularmente para garantir que eles permanecem na rea alvo desejada. Quando a planta se modifica ao longo do tempo, importante estabelecer o Gerenciamento de Alarme como parte dos procedimentos da planta. Gerenciamento de alarme sistemtico usualmente revela os pontos fracos na planta e pode assim ajudar diretamente na melhoria do desempenho da planta. A ajuda ao operador dada pelo sistema de alarme de alta qualidade melhorar ainda mais o desempenho da planta.

Gerenciamento de Mudana na configurao de alarme


A seguinte informao deve ser registrada quando mudanas de alarme forem aprovadas: razo, data, responsvel pela mudana, natureza da mudana e treinamento para aqueles afetados. Normas de sade e segurana, como OSHA 1910.119 (1996) e IEC 61 511 (2003) exigem realizao de mecanismos para Gerenciamento de Mudana. Mesmo mudanas pequenas, locais e temporrias devem ser consideradas. Deve-se periodicamente comparar os parmetros de configurao de alarme aprovados com os parmetros atualmente ativos na CPAS. Isso ajuda a manter a integridade do sistema de alarme. Todas as diferenas entre os ajustes ativos aprovados e atuais so automaticamente detectados e trazidos para a ateno da pessoa apropriada para reviso.

Alarme avanado
Geralmente, o sistema de alarme mais simples pode ser capaz de conseguir o resultado operacional desejado, a melhor chance de se ter um benefcio sustentvel e sucesso. Quando se pensar em usar sistemas de alarme melhorados e avanados deve-se avaliar os benefcios esperados em segurana, proteo do meio ambiente ou outros critrios contra a complexidade crescente do projeto do sistema, realizao e manuteno. Pode acontecer que adicionar um sistema muito complexo e no transparente resulta em complicar e sobrecarregar o sistema de alarme do operador. Endereamento de alarme Nos sistemas de alarme antigos todos os alarmes eram apresentados aos operadores, geralmente em uma nica lista de alarmes. O CPAS contem mecanismos de distribuio que permitem o endereamento de alarmes especficos para grupos de usurio especficos. Cada grupo de usurios, como engenheiros de sistema, operadores, pessoal de manuteno e engenheiros de

93

aplicao, cada um pode ter suas listas de alarme apropriadas e dedicadas mostrando apenas os alarmes relacionados com sua funo. Alarmes especficos podem ser distribudos s pessoas por email ou mensagens de SMS (Short Message Service). Por exemplo, a mensagem que as horas de operao de um motor foram excedidas e deve ser feita a manuteno do motor importante apenas para o pessoal de manuteno e no importa aos operadores. Usualmente a atribuio de alarmes para grupos feita com a ajuda da categoria do evento, mas outros atributos do evento podem tambm ser usados. Filtro do alarme CPAS permite configurar listas de alarme muito diferentes e definir filtro complexo para cada lista. Deve ser claramente visvel que a configurao de filtro realmente usada e somente um limitado conjunto de ajustes de filtro consistentes deve ser usado. Se os operadores forem capazes de fazer mudanas individuais nos ajustes de filtro isso resultar em confuso perigosa uma vez que a lista de alarme usada por um operador que desconhece a mudana da configurao do filtro. Ocultando alarme Esconder alarme usado em reas de processo ou objetos para esconder alarmes que no so de interesse em um estagio ou rea especfica. Regras de alarme podem ser definidas de modo que certos alarmes sero escondidos, dependendo do estado do processo ou de outros alarmes ativos. Alarmes escondidos tm uma visibilidade reduzida, mas ainda esto disponveis se requerido explicitamente.

Fig. 6.6. Gerenciamento e configurao de alarmes

Suspenso temporria do alarme (shelving) Desistncia (Shelving) de alarme uma facilidade onde o operador capaz de evitar temporariamente que um alarme seja mostrado quando ele causar aborrecimento. Um alarme suspenso ser removido da lista e no ser reanunciado at que a desistncia seja removida. Mesmo em sistemas de alarme com uma muito alta qualidade, quando operando em condies normais, alto nmero de alarmes recorrentes pode ser criado, devido, por exemplo, a instrumentos com defeito ou equipamento em manuteno. Desabilitar tal alarme totalmente incorreria no risco que o alarme no seja reabilitado uma vez que o problema tenha sido resolvido. importante garantir que alarmes suspensos nunca sejam esquecidos e que todo o pessoal afetado por esse alarme tenha conhecimento do fato que o alarme foi suspenso. Isto pode ser feito por reviso forada de todos os alarmes suspensos e associando um temporizador com cada alarme suspenso. Todos os alarmes suspensos devem ser periodicamente revistos.

94

Agrupando alarmes Um nico equipamento pode gerar vrios alarmes com causas inter-relacionadas. s vezes somente um desses alarmes ser ativado (e.g., temperatura muito alta), mas no caso de um problema maior, vrios alarmes sero ativados. Por exemplo, se um compressor cai (tripped), alarmes detalhados dos internos do compressor so de interesse somente quando especificamente diagnosticando esse compressor. Na lista geral de alarmes, um alarme indicando que o compressor foi tripado suficiente e qualquer alarme adicional mais detalhado ir apenas distrair a ateno do operador. Qualquer alarme mais detalhado do compressor deve ser agrupado sob o alarme de trip geral e somente mostrado se especificamente requerido. Disperso da carga do alarme A capacidade humana de absorver alarmes limitada. Se a taxa de alarme mais alta do que esse limite, a estratgia atual de muito operadores ignorar alguns ou at todos os alarmes. EEMUA 191 discute um conceito de pesquisa chamado disperso automtica da carga de alarme. A ideia que o sistema de alarme automaticamente limite a taxa de display do alarme que um operador pode cuidar. Uma crtica a esse enfoque que nem sempre provavelmente transparente para o operador por que o sistema de alarme apresenta diferentes alarmes em certo ponto. Uma melhor alternativa realizada em muitas plantas pode ser usar disperso manual da carga de alarme. Isso significa que o operador pode selecionar um filtro definido que mostra somente os alarmes mais importantes. Tal filtro depende de uma boa classificao dos alarmes. Se forem usadas prioridades de alarme, os alarmes mais importantes e urgentes teriam a mais alta prioridade atribuda. Supresso de alarmes de reas fora de servio Em muitas plantas alguns dos alarmes falsos vm de reas de processo que atualmente no esto sendo usadas ou esto em manuteno. Um CPAS permite esconder ou desabilitar tais alarmes. Deve ser garantido que os alarmes sero visveis ainda assim que a manuteno terminar. Assim, essas mudanas da configurao de alarme deve ser parte do sistema de Gerenciamento de Mudana. Se reas fora de servio podem ser determinadas pelo CMMS (Computerized Maintenance Management System), essa informao pode ser usada para esconder os alarmes correspondentes. Alarmes baseados em estado A prtica padro em CPAS atuais gerenciando processos contnuos usar limites de alarme estticos. Em alguns casos faria sentido usar limites flexveis, dependendo da situao. Por exemplo, o limite de temperatura do rolamento pode ser estabelecido dependendo da temperatura externa porque em dia de inverno, os limites podem ser estabelecidos mais baixos. No inverno um alarme de temperatura em 90 oC poderia trabalhar bem, mas no vero o mesmo alarme de temperatura resulta em muitos alarmes falsos. Obviamente CPAS permite calcular limites de alarme baseando em frmulas fsicas que fazem sentido de um pontoo de vista cientifico, mas, na prtica, isso raramente feito. Muitos alarmes so projetados para estado de regime apenas, mas muitas vezes a partida e a parada so as fases mais difceis de um ponto de vista operacional e durante essas tarefas o operador requer a mnima distrao. Alarmes que fazem sentido apenas no estado de regime permanente devem ser escondidos durante partida e parada. Estados podem ser determinados atravs de uma varivel calculada ou pela indicao do operador. Isso tambm vlido para processos de batelada, especialmente aqueles que rodam muitas receitas (EEMUA 191).

95

Siglas
APC Advanced Process Control API Application Programming Interface (API American Petroleum Institute) ASCII American Standard Code for Information Interchange B2MML Business To Manufacturing Markup Language BPCS Basic Process Control System CAE Computer Aided Engineering CIM Computer Integrated Manufacturing CMMS Computerized Maintenance Management System COM Component Object Model CORBA Common Object Request Broker Architecture COTS Commercial Off The Shelf CPAS Collaborative Process Automation System CPM Collaborative Production Management CPU Central Processing Unit CSV Comma Separated Values DCOM Distributed COM DCS Distributed Control System DoS Denial-of-Service DTM Device Type Manager EAM Enterprise Asset Management EDDL electronic Device Description Language EEMUA - Engineering Equipment & Materials Users Association EPC Engineering, Procurement and Construction FDA Food and Drug Administration FDS Field Device Specification HAZOP Hazard and Operability Study HMI Human Machine Interface HW hardware IEC International Electrical Commission ISO International Standardization Organization MES Manufacturing Execution Systems PPS Production Planning Systems SAT Site Acceptance Test SW software URS User Requirement Specification

96

Referncias Bibliogrficas
1. ANSI/ISA-95.00.01-2010 (IEC 62264-1 Mod): Enterprise-Control System Integration, Part 1: Models and Terminology 2. ANSI/ISA-95.00.02-2010 (IEC 62264-2 Mod): Enterprise-Control System Integration, Part 2: Object Model Attributes. 3. ISA 95-00-3 - 2005: Enterprise-Control System, Integration Part 3: Activity, Models of Manufacturing, Operations Management. 4. IEC 61 131-3: Programmable controllers Part 3: Programming languages. (2003). 5. ANSI/ISA 88.01.1995: Batch Control Part 1: Models and Terminology. 6. ANSI/ISA 88.02.2001: Batch Control Part 2: Data structures and guidelines for languages.

Collaborative Process Automation Systems.docx

11

26 NOV 13

97

Das könnte Ihnen auch gefallen