Introdução

O gerenciamento de alarmes refere-se ao projeto, implementação, operação e manutenção

eficazes de alarmes de fábricas / processos industriais. O gerenciamento de alarmes é
necessário em um ambiente de planta de processo controlado por um operador usando
um sistema de controle, como um DCS ou um Controlador lógico programável (PLC). Os
alarmes são acionados quando o valor do processo se desvia das condições operacionais
normais, isto é, na ocorrência de situações operacionais anormais. Uma situação anormal
ocorre quando uma perturbação em um processo faz com que as operações da fábrica se
desviem do seu estado operacional normal, exigindo intervenção humana. A incapacidade
de diagnosticar e controlar situações anormais tem um impacto de bilhões de dólares na
economia. O gerenciamento de alarmes visa basicamente evitar, ou pelo menos minimizar,
perdas físicas e econômicas por meio da intervenção do operador em resposta à condição
que foi alarmada.

O gerenciamento de alarmes refere-se aos processos e práticas para determinar,

documentar, projetar, monitorar e manter as mensagens de alarme dos sistemas de
automação e segurança de processos. Na realidade, o gerenciamento de alarmes nem
sempre consegue isso porque são projetados incorretamente, mal documentados,
alterados sem uma revisão adequada ou falham em fornecer informações suficientes ao
operador. Um sistema de alarme eficaz é parte essencial de um processo seguro e
confiável. Sistemas de alarme projetados incorretamente e com mau funcionamento
podem ter sérias conseqüências e levar a alarmes ineficazes; o que, por sua vez, leva a
inundações de alarmes, alto número de alarmes permanentes, priorização inadequada de
alarmes e ação inadequada ou nenhuma ação de alarme.

Um exemplo da implementação da
filosofia de gerenciamento de
alarmes é o Sistema de Alarme de
Extensão (EAS), que transfere
alarmes e informações do sistema
de monitoramento e alarme para
oficiais de serviço em Wheelhouse,
ECR, cabines de oficiais, áreas
públicas, CCR e cabines
selecionadas. O sistema de alarme
de ramal contém painéis de alarme
de ramal que exibem alarmes
ativados, identificando os oficiais de
plantão e a responsabilidade de
localização do manuseio de alarmes
e permitem a resposta do operador.

Um típico sistema de alarme de

extensão é apresentado na Figura
ao lado:
Os alarmes no sistema de alarme de extensão (EAS) são geralmente agrupados. Um
exemplo desses grupos de alarme é apresentado na tabela abaixo:

Planta de Operações em processamento de Óleo e Gás

Cada empresa operacional que utiliza um sistema SCADA(é um acrônimo para

"Supervisory Control and Data Acquisition"), utilizado em sistemas de controle industrial )
deve ter um plano de gerenciamento de alarmes por escrito para fornecer uma resposta
eficaz do operador aos alarmes. O plano de uma empresa operacional deve incluir
provisões para (ANSI / ISA – 18.2, 2009):

 Analise as operações de alarme relacionadas à segurança do SCADA usando um

processo que garante que os alarmes sejam precisos e ofereça suporte a operações
seguras de tubulação;

 Identifique pelo menos uma vez em cada mês do calendário os pontos que afetam a
segurança que foram retirados da varredura no host SCADA, tiveram alarmes
inibidos, geraram alarmes falsos ou tiveram valores forçados ou manuais por
períodos de tempo superiores ao necessário para a manutenção ou operação
associada actividades;

 Verifique os valores corretos dos pontos de ajuste e descrições de alarmes

relacionados à segurança pelo menos uma vez a cada ano civil, mas a intervalos não
superiores a 15 meses;

 Revise o plano de gerenciamento de alarmes exigido por este parágrafo pelo menos
uma vez a cada ano civil, mas a intervalos não superiores a 15 meses, para
determinar a eficácia do plano;

 Monitorar o conteúdo e o volume da atividade geral direcionada e exigida a cada

operador pelo menos uma vez a cada ano civil, mas a intervalos não superiores a 15
meses, que garantirão aos controladores tempo suficiente para analisar e reagir aos
alarmes recebidos; e por fim abordar as deficiências identificadas através da
implementação.
ANSI / ISA – 18.2 (2009) atualizada para IEC 62682:2014, aborda o desenvolvimento,
design, instalação e gerenciamento de sistemas de alarme nas indústrias de processo. O
gerenciamento do sistema de alarme inclui vários processos de trabalho ao longo do ciclo
de vida do sistema de alarme. Esta norma define a terminologia e os modelos para
desenvolver um sistema de alarme e define os processos de trabalho recomendados para
manter efetivamente o sistema de alarme durante todo o ciclo de vida.

Os estágios do ciclo de vida do gerenciamento de alarmes são:

a. Filosofia de alarme

b. Identificação

c. Racionalização

d. Projeto detalhado

e. Implementação

f. Operação

g. Manutenção

h. Acompanhamento e avaliação

i. Gerenciamento de mudança

j. Auditar

Filosofia de Alarme
É necessário um planejamento básico antes de projetar um novo sistema de alarme ou
modificar um sistema existente. Geralmente, o primeiro passo é o desenvolvimento de uma
filosofia de alarme que documenta os objetivos do sistema de alarme e os processos para
atingir esses objetivos. Para novos sistemas, a filosofia de alarme serve como base para o
documento de especificação de requisitos de sistema de alarme.

A filosofia começa com as definições básicas e as estende às definições operacionais. A

definição de prioridades de alarme, classes, métricas de desempenho, limites de
desempenho e requisitos de relatório são determinados com base nos objetivos, definições
e princípios. Os esquemas para apresentação de indicações de alarme na interface
homem-máquina (HMI), incluindo o uso de prioridades, também são definidos na filosofia
de alarme, que deve ser consistente com o design geral da HMI (Interface homem-
máquina. Uma HMI é um aplicativo de software que apresenta informações a um operador
ou usuário sobre o estado de um processo).

A filosofia especifica os processos usados para cada um dos estágios do ciclo de vida,
como o limite para o processo de gerenciamento de mudanças e os requisitos específicos
para mudanças, e é mantida para garantir um gerenciamento consistente de alarmes
durante todo o ciclo de vida do sistema de alarmes.
The development of the alarm system requirements specification is included in the
philosophy stage of the life cycle. Most of the specification is system independent and can
be the basis for determining which systems most closely meet the requirements. The
specification typically goes into more detail than the alarm philosophy and may provide
specific guidance for system design.

A filosofia especifica os processos usados para cada um dos estágios do ciclo de vida,
como o limite para o processo de gerenciamento de mudanças e os requisitos específicos
para mudanças, e é mantida para garantir um gerenciamento consistente de alarmes
durante todo o ciclo de vida do sistema de alarmes.

O desenvolvimento da especificação de requisitos do sistema de alarme está incluído no

estágio de filosofia do ciclo de vida. A maior parte da especificação é independente do
sistema e pode ser a base para determinar quais sistemas atendem melhor aos requisitos.
A especificação normalmente entra em mais detalhes do que a filosofia de alarme e pode
fornecer orientações específicas para o projeto do sistema.

Identification.
O estágio de identificação é um ponto de coleta para possíveis alarmes propostos por
qualquer um dos vários métodos para determinar que um alarme pode ser necessário.
Esses métodos são definidos fora deste padrão, portanto o estágio de identificação é
representado como um processo predefinido no ciclo de vida. Os métodos podem ser
formais, como PHA, especificações de requisitos de segurança, recomendações de uma
investigação de incidentes, boas práticas de fabricação, permissões ambientais,
desenvolvimento de P&ID (diagrama de tubulação e instrumentação) ou revisões de
procedimentos operacionais. Modificações de processo e testes operacionais também
podem gerar a necessidade de alarmes ou modificações. Algumas alterações de alarme
serão identificadas no monitoramento de rotina do desempenho do sistema de alarme.
Nesta fase, a necessidade de um alarme foi identificada e está pronta para ser
racionalizada.

Racionalização
O estágio de racionalização reconcilia a necessidade identificada de um alarme ou
alteração do sistema de alarme com os princípios da filosofia de alarme. As etapas podem
ser concluídas em um processo ou sequencialmente. O produto da racionalização é uma
documentação clara do alarme, incluindo quaisquer técnicas avançadas de alarme, que
podem ser usadas para concluir o projeto.

Racionalização é o processo de aplicar os requisitos para um alarme e gerar a

documentação de suporte, como a base para o ponto de ajuste do alarme, a conseqüência
e a ação corretiva que pode ser executada pelo operador.

A racionalização inclui a priorização de um alarme com base no método definido na filosofia

do alarme. Freqüentemente, a prioridade se baseia nas consequências do alarme e no
tempo de resposta permitido.

A racionalização também inclui a atividade de classificação durante a qual um alarme é

atribuído a uma ou mais classes para designar requisitos (por exemplo, requisitos de
design, teste, treinamento ou relatório). O tipo de conseqüências de um alarme
racionalizado, ou outros critérios, pode ser usado para separar os alarmes em classes,
conforme definido na filosofia do alarme.

Os resultados da racionalização são documentados, normalmente no banco de dados de

alarmes mestre (isto é, um documento ou arquivo aprovado), que é mantido por toda a vida
útil do sistema de alarme.

Projeto Detalhado
Na fase de projeto, os atributos de alarme são especificados e projetados com base nos
requisitos determinados pela racionalização. Existem três áreas de design: design básico
de alarme, design de IHM e design de técnicas avançadas de alarme.

O design básico de cada alarme segue as orientações com base no tipo de alarme e no
sistema de controle específico.

O design da HMI inclui exibição e aviso para os alarmes, incluindo as indicações de

prioridade do alarme.

Técnicas avançadas de alarme são funções adicionais que melhoram a eficácia do sistema
de alarme além do design básico de alarme e IHM. Esses métodos incluem priorização
dinâmica e alarmante com base no estado.

Implementação
Na fase de implementação, as atividades necessárias para instalar um alarme ou sistema
de alarme e trazê-lo ao status operacional são concluídas. A implementação de um novo
alarme ou de um novo sistema de alarme inclui a instalação física e lógica e a verificação
funcional do sistema.

Como os operadores são uma parte essencial do sistema de alarme, o treinamento do

operador é uma atividade importante durante a implementação. O teste de novos alarmes
geralmente é um requisito de implementação.

A documentação para treinamento, teste e comissionamento pode variar de acordo com a

classificação definida na filosofia de alarme.

Manutenção
No estágio de manutenção, o alarme ou sistema de alarme não está operacional, mas está
sendo testado ou reparado. A manutenção periódica (por exemplo, teste de instrumentos)
é necessária para garantir que o sistema de alarme funcione conforme projetado.

Monitoramento e Avaliação
No estágio de monitoramento e avaliação, o desempenho geral do sistema de alarme e
dos alarmes individuais é monitorado continuamente em relação às metas de desempenho
estabelecidas na filosofia do alarme. O monitoramento e a avaliação dos dados do estágio
de operação podem desencadear trabalhos de manutenção ou identificar a necessidade
de alterações no sistema de alarme ou nos procedimentos operacionais. O monitoramento
e a avaliação dos dados do estágio de manutenção fornecem uma indicação da eficiência
da manutenção. O desempenho geral do sistema de alarme também é monitorado e
avaliado em relação aos objetivos da filosofia de alarme. Sem monitorar, é provável que
um sistema de alarme seja degradado.

Gerenciamento de mudança
No estágio de gerenciamento de mudanças, modificações no sistema de alarme são
propostas e aprovadas. O processo de mudança deve seguir cada um dos estágios do
ciclo de vida, desde a identificação até a implementação.

Auditoria
No estágio de auditoria, são realizadas revisões periódicas para manter a integridade do
sistema de alarme e dos processos de gerenciamento de alarme. Auditorias de
desempenho do sistema podem revelar lacunas não aparentes no monitoramento de
rotina. A execução contra a filosofia de alarme é auditada para identificar melhorias no
sistema, como modificações na filosofia de alarme. As auditorias também podem identificar
a necessidade de aumentar a disciplina da organização para seguir a filosofia do alarme.
Análise de causa raiz

A análise de causa raiz será usada no gerenciamento de alarmes para identificar

equipamentos ou sistemas com defeito. A aplicação da análise de causa raiz ao
gerenciamento de alarmes é particularmente relevante porque o gerenciamento de alarmes
também enfrenta um número esmagadoramente grande de alarmes.

A Análise de Causa Raiz (RCA) tem sido historicamente usada para identificar os fatores
mais básicos que contribuíram para um incidente, por exemplo, após um acidente com um
tanque, a Equipe de Segurança usará normalmente a análise de causa raiz para identificar
por que o acidente havia acontecido, para que acidentes semelhantes pudessam ser
evitados no futuro.
Porque a prevenção de acidentes semelhantes tenha sido fundamental para análise de
causa, foi necessário que as causas-raiz sejam fatores sobre os quais se tem controle.
Uma causa raiz é a causa mais básica que pode ser razoavelmente identificada e que o
gerenciamento tem controle para corrigir. A análise de causa raiz é a tarefa de identificar
causas raiz.

As três palavras-chave na definição de causas principais são básicas, razoáveis e corretas:

As causas-raiz devem ser tão básicas (ou específicas) que é possível corrigi-las. Por outro
lado, dado que a solução é o ponto principal, não é razoável dividir ainda mais as causas-
raiz em causas mais básicas. Consequentemente, essas causas mais básicas não são
causas-raiz, e as causas-raiz estão no nível "mais alto" onde a fixação é possível. Por fim,
observe que um único incidente pode ter várias causas raiz.

No gerenciamento de problemas, os alarmes indicam problemas na operação de

equipamentos ou operaçõesd, como falhas de hardware ou software, degradação do
desempenho ou configurações incorretas.
Como os componentes são altamente interdependentes, um problema em um componente
se propaga para todos os componentes transitivamente dependentes. Como
consequência, um problema que afeta qualquer componente único
pode prejudicar muitos outros componentes, muitos dos quais relatam seu
comprometimento por meio de alarmes. O objetivo do gerenciamento de alarmes é avaliar
esses alarmes e identificar o problema original. Esse problema é chamado de causa raiz e
sua correção elimina claramente as deficiências e alarmes associados. Finalmente, a
tarefa de identificar causas raiz é chamada de análise de causa raiz.

O exemplo da Figura abaixo ilustra os desafios da análise de causa raiz.

A Figura mostra uma rede que consiste em três roteadores (ou seja, R1, R2, R3), três LANs
(ou seja, A, B, C) e um banco de dados do servidor de banco de dados. Presume-se que
os clientes do banco de dados sejam distribuídos pelas três LANs. A figura mostra como
um problema no módulo de memória do roteador R1 se propaga pela rede.
Especificamente, suponha que no roteador R1, a célula de memória que armazena o custo
do link R1 → R3 falhe e indique erroneamente um valor extremamente alto. Nenhum
alarme é emitido para este evento, mas o protocolo de roteamento reage roteando todo o
futuro tráfego A-C sobre o roteador R2. Como conseqüência, o roteador R2 fica
congestionado, o que resulta em alarmes. Além disso, a conectividade de LAN C degrada
e banco de dados
transações por clientes de banco de dados remoto duram mais. Isso aumenta o número
de interrupções de transação emitidas para liberar bloqueios de banco de dados que foram
retidos por muito tempo. O número aumentado de interrupções de transações é relatado
por alarmes adicionais. Observe que todos os alarmes neste exemplo relatam sintomas da
causa raiz (a célula de memória com falha) e não da causa raiz. Além disso, é provável
que o roteador R2 e os clientes do banco de dados disparem vários alarmes para relatar
seu comprometimento, o que pode desencadear uma inundação de alarme. Essa
tendência de gerar muitos alarmes que estão remotamente relacionados à causa raiz real,
tornam a análise de causa raiz uma tarefa desafiadora.

Em resumo, a análise da causa raiz no gerenciamento de rede aspira a identificar o (s)

ponto (s) de partida da cadeia de propagação de. Este é um exemplo do problema geral
de inferência abdutiva, que é o processo de raciocinar dos efeitos às causas. Muitos
sistemas de gerenciamento de alarmes fazem inferência abdutiva em duas etapas:
primeiro, modelam a propagação de causa-efeito em redes e, em seguida, buscam
heuristicamente esse modelo em busca de causas-raiz plausíveis que expliquem os
alarmes observados de outros sistemas.

Os sistemas exigem que o usuário codifique seu conhecimento sobre a análise de causa
raiz em regras especializadas do sistema. Assim, o problema da inferência abdutiva é
descarregado para o usuário. Outros sistemas ainda implementam a análise de causa raiz
por meio de raciocínio baseado em casos ou livros de códigos.

Usando mineração de dados para manipulação de alarmes

Primeiro, lembre-se da distinção entre alarmes e tipos de alarmes. Alarmes são as
mensagens que um IDS aciona para relatar violações de segurança.
O tipo de alarme, por outro lado, é o atributo que especifica a violação de segurança real
(por exemplo, inundação de SYN, verificação de host, estouro de buffer etc.) relatada por
um alarme. Lembre-se também de que t [Ai] indica o valor que o atributo Ai assume na
tupla t.
01) Modelo Manganaris - é regras de associação para construir um sistema de
detecção de anomalias de "segundo nível" que descarta alarmes "normais" e, assim,
reduz a carga de trabalho do operador.
02) Implicitamente, este trabalho assume que os alarmes "normais" são sempre falsos
positivos. O modelo de referência do comportamento normal do alarme é aprendido
em duas etapas. Primeiro, um fluxo ordenado de tempo de alarmes históricos é
particionado em rajadas, e segundo, as regras de associação são extraídas dessas
rajadas. As regras de associação resultantes constituem o modelo de referência do
comportamento normal do alarme. No tempo de execução, os alarmes são
comparados com esse modelo de referência e os que são consistentes com ele são
considerados normais / benignos e são descartados.
Mais precisamente, oo modelo Manganaris de alarmes são como tuplas (t, A), onde t
é um timestamp e A é um tipo de alarme.
03) Modelo Clifton and Gengo - utiliza a mineração de dados para encontrar padrões
de alarme que um especialista humano possa entender e agir. Mais precisamente,
minam regras de episódio de registros históricos de alarmes e use essas regras de
episódio para orientar a construção de regras de filtragem personalizadas, que
descartam automaticamente falsos positivos.

Alarm Correction
Os sistemas de correlação de alarmes (ACSs) detectam alarmes em tempo real e
automatizam parte do processo de investigação de alarmes. Mais precisamente, os ACSs
tentam agrupar alarmes para que os alarmes do mesmo grupo pertençam ao mesmo
fenômeno (por exemplo, o mesmo problema). Então, apenas os grupos de alarme são
encaminhados para o operador humano. Dessa maneira, os ACSs oferecem uma visão
mais resumida dos problemas de segurança levantados por um Gerador de Defeitos ou
Problemas. Além disso, eles facilitam a distinção entre ameaças reais à segurança e falsos
positivos.
As considerações a seguir mostram a necessidade do novo método de cluster off-line para
Estudo da Análise de Risco (HAZOP)
Devido a rigorosos requisitos em tempo real, os ACSs podem executar apenas uma
quantidade limitada de análises. Por exemplo, considere um fenômeno que ocorre apenas
aos sábados (por exemplo, falsos positivos devido a backups semanais do sistema). Nosso
método de cluster off-line pode agrupar e relatar corretamente os alarmes resultantes,
enquanto os ACSs não têm esse recurso porque é difícil de implementar em tempo real.
Além disso, para identificar com segurança um padrão de alarme semanal, é necessário
observar pelo menos várias semanas de alarmes. Claramente, atrasar os resultados da
correlação por semanas anula o próprio objetivo da correlação de alarme em tempo real.
Da mesma forma, o processamento de atributos de alarme de texto livre (por exemplo, o
contexto, que armazena registros brutos de auditoria caro e, consequentemente, não é
feito pelos ACSs em tempo real. Por outro lado, nosso método de cluster off-line analisa
atributos de texto livre e, portanto, melhora os resultados.
Algoritmo de coloração e agrupamento de alarmes para análise de causa raiz

Já compreendemos que uma falha em um componente pode eventualmente afetar outros

componentes interligados. Portanto, o problema de interrupção do serviço pode ocorrer
nos sistemas de rede. A solução para esse problema é gerar um alarme, a fim de detectar
a falha e sua possível restauração. Além disso, o alarme deve ser processado em tempo
real, para evitar interrupções indesejadas do serviço. Para isso, muitos pesquisadores
apresentaram vários algoritmos para lidar com os alarmes. Tais métodos consomem
tempo, o que é uma grande desvantagem no gerenciamento de falhas. Para superar isso,
proporei aqui um método que compreende dois novos algoritmos, ou seja, Coloração de
Alarme e Agrupamento de Alarmes. No algoritmo de coloração de alarme, um esquema de
cores é usado para distinguir os alarmes e, posteriormente, esses alarmes são agrupados
com base em cores distintas. O método proposto é extensivamente simulado e comparado
com os métodos de agrupamento de alarmes existentes.
Depois, de estudar várias técnicas de Correlação de Alarmes para resolver a análise de
causa raiz, encontra-se os seguintes desafios:
É um grande desafio desenvolver uma aplicação que englobe para todos os sistemas e
que os monitore em tempo real
Um grande desafio para projetar um algoritmo de correlação de alarme para resolver o
problema de causa raiz, considerando qualquer outro fator.
É difícil projetar algum algoritmo aprimorado para resolver a análise de causa raiz e,
finalmente, mostramos a comparação na forma de gráfico, onde V representa um conjunto
de vértices e E representa um conjunto de arestas.

Solução proposta
Considere 𝐴 = {𝑎1 ,𝑎2 ,𝑎3 , … ,𝑎𝑛 } seja o
conjunto de alarmes gerados por
diferentes nós. Esses alarmes são
inseridos na Normalização de alarmes,
que é convertida em um formato
comum. Em seguida, o algoritmo de
coloração de alarme colore esses
alarmes com base no problema ou
grupo de problemas. Esses alarmes
coloridos são agrupados por algoritmos
de agrupamento de alarmes com base
na cor. Agora, o relatório é gerado, o
que ajuda o gerente a descobrir a causa raiz dos alarmes com muita facilidade. Mostramos
nossa análise para descobrir a causa raiz de um alarme.
Algoritmo proposto para resolver problemas de causa raiz
O algoritmo de coloração de alarme utiliza a entrada como conjunto de cores e endereço
da porta. Para cada alarme, ele atribui a cor com base no tipo de problema. O objetivo
principal é atribuir o número mínimo de cores para distinguir diferentes alarmes facilmente.
Em seguida, os alarmes coloridos são buscados como entrada no algoritmo de
agrupamento de alarmes que agrupa o conjunto de alarmes com base na cor, o que ajuda
o administrador da rede a conhecer a causa raiz de um alarme.
Suponha 𝑃 = {𝑝1 ,𝑝2 ,𝑝3 , … ,𝑝𝑛 } que seja o número n de endereços de problemas de
diferentes nós e C = 𝐶 = {1,2,3, … ,𝑙} o conjunto de l número de cores seja inserido e PC=
𝑃𝐶 = {𝑝1 1,𝑝2 2, … ,𝑝𝑛 𝑙} seja o conjunto de endereços de porta de cores recebidos como
saída do algoritmo de coloração de alarme. Os conjuntos de saída são inseridos no
algoritmo de agrupamento de alarmes; e posteriormente, G= 𝐺 = {𝑔1 ,𝑔2 , … ,𝑔𝑚 } é a saída.
ɸ