Máquinas, plantas de processo e outros equipamentos podem, se apresentarem mau funcionamento, apresentar riscos de eventos perigosos, como incêndios, explosões, overdoses de radiação e partes móveis. Uma das maneiras pelas quais essas plantas, equipamentos e máquinas podem funcionar mal é por falhas de dispositivos eletromecânicos, eletrônicos e eletrônicos programáveis ​​(E/E/PE) usados ​​no projeto de seus sistemas de controle ou segurança. Essas falhas podem surgir tanto de falhas físicas no dispositivo (por exemplo, de desgaste ocorrendo aleatoriamente no tempo (falhas aleatórias de hardware)); ou de falhas sistemáticas (por exemplo, erros cometidos na especificação e projeto de um sistema que causam falha devido a (1) alguma combinação particular de entradas, (2) alguma condição ambiental (3) entradas incorretas ou incompletas de sensores, ( 4) entrada de dados incompleta ou errônea pelos operadores e (5) possíveis falhas sistemáticas devido a um design de interface ruim).

Falhas de sistemas relacionadas à segurança

Este artigo aborda a segurança funcional de sistemas de controle relacionados à segurança e considera os requisitos técnicos de hardware e software necessários para atingir a integridade de segurança necessária. A abordagem geral está de acordo com o padrão proposto da Comissão Eletrotécnica Internacional IEC 1508, Partes 2 e 3 (IEC 1993). O objetivo geral do projeto de norma internacional IEC 1508, Segurança Funcional: Sistemas Relacionados à Segurança, é garantir que a planta e o equipamento possam ser automatizados com segurança. Um objetivo fundamental no desenvolvimento do padrão internacional proposto é prevenir ou minimizar a frequência de:

• falhas de sistemas de controle desencadeando outros eventos que, por sua vez, podem levar a perigo (por exemplo, sistema de controle falha, controle é perdido, processo fica fora de controle resultando em incêndio, liberação de materiais tóxicos, etc.)
• falhas nos sistemas de alarme e monitoramento para que os operadores não recebam informações de forma que possam ser rapidamente identificadas e compreendidas para realizar as ações de emergência necessárias
• falhas não detectadas em sistemas de proteção, tornando-os indisponíveis quando necessário para uma ação de segurança (por exemplo, um cartão de entrada com falha em um sistema de desligamento de emergência).

O artigo “Sistemas elétricos, eletrônicos e eletrônicos programáveis ​​relacionados à segurança” estabelece a abordagem geral de gerenciamento de segurança incorporada na Parte 1 da IEC 1508 para garantir a segurança dos sistemas de controle e proteção que são importantes para a segurança. Este artigo descreve o projeto de engenharia conceitual geral necessário para reduzir o risco de um acidente a um nível aceitável, incluindo a função de qualquer sistema de controle ou proteção baseado na tecnologia E/E/PE.

Na figura 1, o risco do equipamento, planta de processo ou máquina (geralmente referido como equipamento sob controle (EUC) sem dispositivos de proteção) é marcado em uma extremidade da Escala de Risco EUC, e o nível alvo de risco necessário para atender ao nível de segurança exigido está na outra extremidade. No meio, é mostrada a combinação de sistemas relacionados à segurança e instalações externas de redução de risco necessárias para compensar a redução de risco necessária. Estes podem ser de vários tipos – mecânicos (por exemplo, válvulas de alívio de pressão), hidráulicos, pneumáticos, físicos, bem como sistemas E/E/PE. A Figura 2 enfatiza o papel de cada camada de segurança na proteção do EUC à medida que o acidente avança.

Figura 1. Redução de riscos: Conceitos gerais

Figura 2. Modelo geral: camadas de proteção

Desde que uma análise de perigo e risco tenha sido realizada no EUC conforme exigido na Parte 1 da IEC 1508, o projeto conceitual geral para segurança foi estabelecido e, portanto, as funções necessárias e a meta de Nível de Integridade de Segurança (SIL) para qualquer E/E/ O sistema de controle ou proteção PE foi definido. A meta de nível de integridade de segurança é definida com relação a uma medida de falha de meta (consulte a tabela 1).

Tabela 1. Níveis de integridade de segurança para sistemas de proteção: medidas de falha alvo

Nível de integridade de segurança                        Modo de operação sob demanda (Probabilidade de falha em executar sua função de projeto sob demanda)

4 10^-5 ≤ × 10^-4

3 10^-4 ≤ × 10^-3

2 10^-3 ≤ × 10^-2

1 10^-2 ≤ × 10^-1 

Sistemas de Proteção

Este documento descreve os requisitos técnicos que o projetista de um sistema relacionado à segurança E/E/PE deve considerar para satisfazer a meta de Nível de Integridade de Segurança exigida. O foco está em um sistema de proteção típico que utiliza eletrônica programável para permitir uma discussão mais aprofundada dos principais problemas com pouca perda em geral. Um sistema de proteção típico é mostrado na figura 3, que descreve um sistema de segurança de canal único com um desligamento secundário ativado por meio de um dispositivo de diagnóstico. Em operação normal, a condição insegura do EUC (por exemplo, excesso de velocidade em uma máquina, alta temperatura em uma planta química) será detectada pelo sensor e transmitida à eletrônica programável, que comandará os atuadores (através dos relés de saída) para colocar o sistema em um estado seguro (por exemplo, desenergizando o motor elétrico da máquina, abrindo uma válvula para aliviar a pressão).

Figura 3. Sistema de proteção típico

Mas e se houver falhas nos componentes do sistema de proteção? Esta é a função do desligamento secundário, que é ativado pelo recurso de diagnóstico (autoverificação) deste projeto. No entanto, o sistema não é totalmente à prova de falhas, pois o projeto tem apenas uma certa probabilidade de estar disponível quando solicitado a realizar sua função de segurança (ele tem uma certa probabilidade de falha sob demanda ou um certo nível de integridade de segurança). Por exemplo, o projeto acima pode ser capaz de detectar e tolerar certos tipos de falha da placa de saída, mas não seria capaz de resistir a uma falha da placa de entrada. Portanto, sua integridade de segurança será muito menor do que a de um projeto com uma placa de entrada de maior confiabilidade, diagnósticos aprimorados ou alguma combinação destes.

Existem outras causas possíveis de falhas do cartão, incluindo falhas físicas “tradicionais” no hardware, falhas sistemáticas, incluindo erros na especificação de requisitos, falhas de implementação no software e proteção inadequada contra condições ambientais (por exemplo, umidade). O diagnóstico neste projeto de canal único pode não cobrir todos esses tipos de falhas e, portanto, isso limitará o nível de integridade de segurança alcançado na prática. (A cobertura é uma medida da porcentagem de falhas que um projeto pode detectar e lidar com segurança.)

Requerimentos técnicos

As partes 2 e 3 do rascunho da IEC 1508 fornecem uma estrutura para identificar as várias causas potenciais de falha em hardware e software e para selecionar recursos de projeto que superem essas causas potenciais de falha apropriadas ao nível de integridade de segurança exigido do sistema relacionado à segurança. Por exemplo, a abordagem técnica geral para o sistema de proteção na figura 3 é mostrada na figura 4. A figura indica as duas estratégias básicas para superar faltas e falhas: (1) prevenção de falhas, onde são tomados cuidados para evitar a criação de falhas; e (2) tolerância ao erro, onde o design é criado especificamente para tolerar falhas especificadas. O sistema de canal único mencionado acima é um exemplo de projeto tolerante a falhas (limitado), em que os diagnósticos são usados ​​para detectar certas falhas e colocar o sistema em um estado seguro antes que ocorra uma falha perigosa.

Figura 4. Especificação de projeto: solução de projeto

prevenção de falhas

A prevenção de falhas tenta evitar que falhas sejam introduzidas em um sistema. A abordagem principal é usar um método sistemático de gerenciamento do projeto para que a segurança seja tratada como uma qualidade definível e gerenciável de um sistema, durante o projeto e, posteriormente, durante a operação e manutenção. A abordagem, que é semelhante à garantia de qualidade, é baseada no conceito de feedback e envolve: (1) planejamento (definição de objetivos de segurança, identificando as formas e meios para atingir os objetivos); (2) medição realização em relação ao plano durante a implementação e (3) aplicar retornos para corrigir quaisquer desvios. As revisões de projeto são um bom exemplo de uma técnica de prevenção de falhas. Na IEC 1508, essa abordagem de “qualidade” para evitar falhas é facilitada pelos requisitos para usar um ciclo de vida de segurança e empregar procedimentos de gerenciamento de segurança para hardware e software. Para o último, eles geralmente se manifestam como procedimentos de garantia de qualidade de software, como os descritos na ISO 9000-3 (1990).

Além disso, as Partes 2 e 3 da IEC 1508 (relativas a hardware e software, respectivamente) classificam certas técnicas ou medidas que são consideradas úteis para evitar falhas durante as várias fases do ciclo de vida de segurança. A Tabela 2 apresenta um exemplo da Parte 3 para a fase de projeto e desenvolvimento do software. O projetista usaria a tabela para auxiliar na seleção de técnicas de prevenção de falhas, dependendo do Nível de Integridade de Segurança exigido. Com cada técnica ou medida nas tabelas, há uma recomendação para cada Nível de Integridade de Segurança, de 1 a 4. A gama de recomendações abrange Altamente Recomendado (HR), Recomendado (R), Neutro - nem a favor nem contra (—) e Não recomendado (NR).

Tabela 2. Projeto e desenvolvimento de software

RH = altamente recomendado; R = recomendado; NR = não recomendado;— = neutro: a técnica/medida não é nem a favor nem contra o SIL.
Observação: uma técnica/medida numerada deve ser selecionada de acordo com o nível de integridade de segurança.

Tolerância ao erro

A IEC 1508 requer níveis crescentes de tolerância a falhas à medida que a meta de integridade de segurança aumenta. A norma reconhece, no entanto, que a tolerância a falhas é mais importante quando os sistemas (e os componentes que compõem esses sistemas) são complexos (designados como Tipo B na IEC 1508). Para sistemas menos complexos e “bem comprovados”, o grau de tolerância a falhas pode ser relaxado.

Tolerância contra falhas aleatórias de hardware

A Tabela 3 mostra os requisitos para tolerância a falhas contra falhas aleatórias de hardware em componentes de hardware complexos (por exemplo, microprocessadores) quando usado em um sistema de proteção como mostrado na figura 3. O projetista pode precisar considerar uma combinação apropriada de diagnóstico, tolerância a falhas e verificações manuais de prova para superar esta classe de falha, dependendo do Nível de Integridade de Segurança exigido.

Tabela 3. Nível de Integridade de Segurança - Requisitos de falha para componentes Tipo B¹

1 Falhas não detectadas relacionadas à segurança devem ser detectadas pela verificação de prova.

2 Para componentes sem cobertura de diagnóstico médio on-line, o sistema deve ser capaz de executar a função de segurança na presença de uma única falha. Falhas não detectadas relacionadas à segurança devem ser detectadas pela verificação de prova.

3 Para componentes com alta cobertura de diagnóstico on-line, o sistema deve ser capaz de realizar a função de segurança na presença de uma única falha. Para componentes sem alta cobertura de diagnóstico on-line, o sistema deve ser capaz de executar a função de segurança na presença de duas falhas. Falhas não detectadas relacionadas à segurança devem ser detectadas pela verificação de prova.

4 Os componentes devem ser capazes de realizar a função de segurança na presença de duas falhas. As falhas devem ser detectadas com alta cobertura de diagnóstico on-line. Falhas não detectadas relacionadas à segurança devem ser detectadas pela verificação de prova. A análise quantitativa de hardware deve ser baseada em suposições de pior caso.

¹Componentes cujos modos de falha não são bem definidos ou testáveis, ou para os quais existem dados de falha ruins da experiência de campo (por exemplo, componentes eletrônicos programáveis).

A IEC 1508 ajuda o projetista fornecendo tabelas de especificações de projeto (consulte a tabela 4) com parâmetros de projeto indexados em relação ao Nível de Integridade de Segurança para diversas arquiteturas de sistemas de proteção comumente usados.

Tabela 4. Requisitos para Nível de Integridade de Segurança 2 - Arquiteturas de sistemas eletrônicos programáveis ​​para sistemas de proteção

A primeira coluna da tabela representa arquiteturas com vários graus de tolerância a falhas. Em geral, as arquiteturas localizadas perto da parte inferior da tabela têm um grau mais alto de tolerância a falhas do que aquelas próximas ao topo. Um sistema 1oo2 (um em dois) é capaz de resistir a qualquer falha, assim como 2oo3.

A segunda coluna descreve a cobertura percentual de qualquer diagnóstico interno. Quanto mais alto o nível dos diagnósticos, mais falhas serão detectadas. Em um sistema de proteção, isso é importante porque, desde que o componente defeituoso (por exemplo, um cartão de entrada) seja reparado dentro de um prazo razoável (geralmente 8 horas), há pouca perda na segurança funcional. (Nota: este não seria o caso de um sistema de controle contínuo, porque qualquer falha provavelmente causará uma condição insegura imediata e o potencial para um incidente.)

A terceira coluna mostra o intervalo entre os testes de prova. Estes são testes especiais que devem ser realizados para exercitar completamente o sistema de proteção para garantir que não haja falhas latentes. Normalmente, eles são executados pelo fornecedor do equipamento durante os períodos de desligamento da planta.

A quarta coluna mostra a taxa de disparo espúrio. Um disparo espúrio é aquele que faz com que a planta ou equipamento desligue quando não há desvio de processo. O preço da segurança costuma ser uma taxa de disparo espúrio mais alta. Um sistema de proteção redundante simples - 1oo2 - tem, com todos os outros fatores de projeto inalterados, um nível de integridade de segurança mais alto, mas também uma taxa de disparo espúrio mais alta do que um sistema de canal único (1oo1).

Se uma das arquiteturas da tabela não estiver sendo utilizada ou se o projetista quiser fazer uma análise mais fundamental, a IEC 1508 permite essa alternativa. Técnicas de engenharia de confiabilidade, como modelagem de Markov, podem então ser usadas para calcular o elemento de hardware do Nível de Integridade de Segurança (Johnson 1989; Goble 1992).

Tolerância contra falhas sistemáticas e de causa comum

Essa classe de falha é muito importante em sistemas de segurança e é o fator limitante na obtenção da integridade de segurança. Em um sistema redundante, um componente ou subsistema, ou mesmo todo o sistema, é duplicado para obter alta confiabilidade a partir de peças de baixa confiabilidade. A melhoria da confiabilidade ocorre porque, estatisticamente, a chance de dois sistemas falharem simultaneamente por falhas aleatórias será o produto das confiabilidades dos sistemas individuais e, portanto, muito menor. Por outro lado, falhas sistemáticas e de causa comum fazem com que sistemas redundantes falhem coincidentemente quando, por exemplo, um erro de especificação no software faz com que as partes duplicadas falhem ao mesmo tempo. Outro exemplo seria a falha de uma fonte de alimentação comum para um sistema redundante.

A IEC 1508 fornece tabelas de técnicas de engenharia classificadas em relação ao Nível de Integridade de Segurança considerado eficaz no fornecimento de proteção contra falhas sistemáticas e de causa comum.

Exemplos de técnicas que fornecem defesas contra falhas sistemáticas são diversidade e redundância analítica. A base da diversidade é que, se um projetista implementa um segundo canal em um sistema redundante usando uma tecnologia ou linguagem de software diferente, as falhas nos canais redundantes podem ser consideradas independentes (isto é, uma baixa probabilidade de falha acidental). No entanto, particularmente na área de sistemas baseados em software, há algumas sugestões de que essa técnica pode não ser eficaz, pois a maioria dos erros está na especificação. A redundância analítica tenta explorar informações redundantes na planta ou na máquina para identificar falhas. Para as outras causas de falha sistemática – por exemplo, tensões externas – a norma fornece tabelas com recomendações sobre boas práticas de engenharia (por exemplo, separação de cabos de sinal e de energia) indexadas em relação ao Nível de Integridade de Segurança.

Conclusões

Os sistemas baseados em computador oferecem muitas vantagens - não apenas econômicas, mas também o potencial para melhorar a segurança. No entanto, a atenção aos detalhes necessária para realizar esse potencial é significativamente maior do que no caso de componentes de sistemas convencionais. Este artigo delineou os principais requisitos técnicos que um designer precisa levar em consideração para explorar com sucesso essa tecnologia.

Voltar